评估 Skill

写完 Skill 不等于写好了。一个 Skill 至少要回答两个问题：

1. 该触发时会不会触发？
2. 触发后任务有没有做得更好？

前者是 description 的触发评估，后者是 Skill 的执行质量评估。只测其中一个都不够：会触发但做错，是噪音；做得好但触发不到，是摆设。

评估闭环

推荐把 Skill 当成一个可回归测试的能力包，而不是一次性 prompt：

真实任务失败
  ↓
抽取 eval case
  ↓
写 description 与 SOP
  ↓
跑触发评估
  ↓
跑执行质量评估
  ↓
观察 agent 轨迹
  ↓
修订 Skill

这也是 Anthropic 与 agentskills.io 都强调的现代姿势：从真实任务出发，用评估驱动内容，而不是先凭感觉写一份长文档。

一、触发评估

触发评估只关心一件事：agent 是否在正确的用户请求下加载这个 Skill。

建立两组 query

清单	目标	建议数量
should-trigger	这些请求应该触发 Skill	10–20 条
should-not-trigger	这些请求看起来相关，但不该触发	5–10 条

query 要尽量像真实用户说话：

[
  {
    "query": "老板发了个 pdf 合同，让我把里面所有金额条款汇总出来，文件在下载目录",
    "should_trigger": true
  },
  {
    "query": "帮我把这份 Word 导出成 PDF",
    "should_trigger": false
  }
]

不要只写抽象指令：

Extract PDF tables
Analyze file
Generate report

这些句子太干净，测不出真实触发问题。

观察是否触发

不同 agent 平台的观测方式不同，但判断标准相同：

• 触发了：agent 读取了对应 Skill 的 SKILL.md。
• 没触发：agent 直接用基础能力处理，没有加载 SKILL.md。

建议每条 query 跑 3 次以上，因为 agent 行为可能有随机性。可以记录触发率：

期望	通过标准	失败含义
should_trigger=true	触发率 > 0.5	description 太窄、关键词不足或隐式场景没覆盖
should_trigger=false	触发率 < 0.5	description 太宽、边界不清或声明过度

用失败 query 反向改 description

没通过的 query 是最有价值的素材：

• 漏触发：把用户真实说法中的关键词补回 description。
• 误触发：在 description 或正文约束里收窄边界。
• 不稳定触发：说明触发条件模糊，需要换成更明确的任务语言。

二、执行质量评估

触发只是第一关。真正重要的是：有 Skill 是否比没有 Skill 更好。

做 with / without 对照

每个 eval case 最好跑两组：

组别	说明
without_skill	不安装或不触发 Skill，让 agent 自行完成
with_skill	安装并触发 Skill，让 agent 按 SOP 执行

比较二者差异：

• 输出是否更准确？
• 步骤是否更稳定？
• 是否少走弯路？
• 是否减少重复解释？
• 是否更符合团队格式？
• 是否更少遗漏边界条件？

如果 with_skill 没有明显改善，说明 Skill 可能只是“把常识写长了”，还没有沉淀真正有价值的程序性知识。

设计断言

执行质量不要只靠感觉。为每条 eval 写出可检查的断言：

{
  "id": "pdf-contract-amounts",
  "prompt": "老板发了个 pdf 合同，让我汇总里面所有金额条款",
  "assertions": [
    "输出包含所有金额条款的表格",
    "每条金额都标注所在页码或章节",
    "未把付款期限误判为金额",
    "最后给出待人工复核项"
  ]
}

好的断言应当具体、可判定，而不是：

输出质量好
看起来专业
内容完整

三、常用指标

指标	关注点	适用阶段
触发率	该不该加载 Skill	description 调试
误触发率	是否过度加载 Skill	description 收敛
任务成功率	最终结果是否达标	执行质量评估
步骤遵守率	agent 是否按 SOP 做	正文结构评估
输出格式合规率	是否符合模板 / schema	模板型 Skill
人工返工率	用户还要改多少	团队落地评估
Token / 时间成本	收益是否抵得上开销	规模化治理

不必一开始全部自动化。先用 5–10 条代表性 case 手动跑通，比没有评估强很多。

四、观察 agent 轨迹

只看最终答案不够，还要看 agent 是怎么走到答案的：

• 是否真的读取了 SKILL.md？
• 是否按要求读取 references/？
• 是否在应该调用脚本时调用了 scripts/？
• 是否跳过了前置检查？
• 是否把示例当成真实数据？
• 是否在错误分支里自作主张？

这些轨迹能告诉你正文哪里写得不够明确。

五、什么时候修改哪一层

现象	优先修改
应该触发但没触发	description
不该触发却触发	description 的边界描述
触发后不读参考资料	SKILL.md 中引用 references 的条件
执行步骤顺序混乱	正文 SOP
输出格式不稳定	模板 / 示例 / assets
计算或转换经常错	封装脚本
遇到边界就失败	示例与 gotchas

六、发布前最低检查

发布或分享 Skill 前，至少完成：

• [ ] 5 条真实 should-trigger query 通过
• [ ] 3 条真实 should-not-trigger query 通过
• [ ] 2 条 with / without 对照能证明 Skill 有改善
• [ ] 至少 1 条边界 case 通过
• [ ] 至少 1 条错误 case 有合理处理
• [ ] 修改 description 后重新跑过触发评估
• [ ] 修改 SOP 后重新跑过执行质量评估

下一步

• 如果评估显示 agent 需要确定性操作，继续看 使用 scripts。
• 如果准备安装第三方 Skill 或团队共享，继续看 安全与信任模型。
• 如果主要面向 Codex 使用，继续看 Codex Skills。