Skill 的评价与优化

一个 Skill 写完的时候,看起来总是对的。结构清晰、边界明确、示例充分——然后它在第三次真实调用里给出了完全偏离预期的结果。问题不在写作质量,在于我评价它的方式从一开始就错了。

CORE IDEA

Skill 的评价对象不应该是文本本身,而应该是它对 Agent 行为产生的稳定增益。一个读起来平庸但每次都生效的 Skill,好过一篇读起来完美、偶尔生效的杰作。

为什么文本评价不可靠

文本层面的评价——完整性、清晰度、格式——有一个共同的盲区:它们假设”人读起来合理”等于”模型执行时稳定”。这个假设在两个地方断裂。

第一,模型的注意力分配和人的阅读顺序无关。你精心铺垫的上下文,可能被它直接跳过;你放在末尾的一句约束,反而可能成为主导指令。第二,文本评价是静态的,而 Skill 的失效几乎都是分布式的:在十类输入里生效九类,在第十类上稳定地错。只看文本,永远发现不了第十类。

行为评价的最小闭环

把 Skill 当作工程资产,意味着它需要测试。我在用的闭环只有三步:

固定一组任务样本。10—20 个真实任务,覆盖预期生效的典型场景和至少两类边界场景。样本不需要多,需要真。
对照运行。同一批任务,分别在有无 Skill 的条件下运行,比较输出。评价指标只有两个:目标行为的出现率,和非目标行为的抑制率。
小步修改,增量重跑。每次只改一处,只重跑受影响的样本。

// eval-pipeline.ts
interface EvalTrace {
  task: string;
  withSkill: boolean;
  targetHit: boolean;
  sideEffects: string[];
}

function evaluateSkillDelta(baseline: EvalTrace[], tuned: EvalTrace[]): number {
  const delta = tuned.filter((t) => t.targetHit).length - baseline.filter((b) => b.targetHit).length;
  return delta / baseline.length;
}

ENGINEERING DECISION

这里选择增量验证,而不是完整重跑测试集,因为目标是降低高频小修改的反馈成本。完整重跑留给每周一次的回归。

FAILED ATTEMPT / 02

最初我试图用另一个模型给 Skill 文本打分。分数很漂亮,和真实任务表现的相关性接近零。评价一个行为的唯一方式,是观察行为。

适用边界

这套方法假设 Skill 的目标行为是可观察、可二分的。对于”让输出更有洞察力”这类模糊目标,行为评价退化为人工判断,样本量就得翻倍——这时候先别评价,先回去把目标写具体。

一个系统真正变得可靠,往往不是因为它学会了做更多事情,而是因为它开始知道哪些事情不该做。Skill 也一样:评价的最终目的,是删掉那些听起来正确、实际上在污染行为的部分。