AI Skill跑通一次不算测试

你写了一份 SKILL.md，拿自己的例子跑了一遍，看到输出还不错，然后就发布了。这不叫测试——这叫演示。一个在演示中看起来很棒、但在混乱的真实场景中崩溃的 skill，比没有 skill 更糟糕，因为你已经构建了一个假定它能工作的workflow。

真正的失败模式是这样的：一次优秀、两次不可用的 skill，比普通 prompt 更差。普通 prompt 每次你都会重新读一遍，所以你能catch到糟糕的输出。但 skill 你会信任——这正是写它的意义——所以糟糕的输出就这么滑过去了。

衡量方差，而不是最好情况

在那些你不是为它设计的输入上多跑几次 skill。不是你写 trigger 时脑子里想的那个干净例子，而是真实用户实际发出的那种丑陋、歧义、半指定化的请求。如果输出质量在多次运行之间剧烈波动，你拥有的不是 skill，而是一张有漂亮营销的彩票。

一个可测试的 skill 需要的三样东西

1. 正确的输出的书面预期。不是"应该不错"——而是对正确结果的实际描述，要足够具体，让你自己（或别人）能拿一个真实输出去对照，得到两次相同的 yes/no 答案。如果你写不出来，说明你还不知道这个 skill 到底要做什么——这个问题应该在发布前发现，而不是发布后。

2. 至少一个对抗性案例。一个专门设计出来触发 skill 存在所要防止的那种失败的输入。如果 skill 的职责是"测试不通过就不提交"，那对抗性案例就是：agent 无法复现 bug 但有一个看起来合理的修复——正是规则最容易被合理化绕过的那个时刻。一个从未在被要求遵守它会感到不便的条件下测试过的 skill，根本没被测试过。

3. 一个 agent 在宣布完成前必须通过的检查。不是"我完成了任务"，而是一个可验证的主张——一个实际被演示过、而不是仅仅被断言过的 checklist 项。那些允许 agent 自我报告成功而无须证据的 skill，生产出的就是自我报告成功而无须证据的 agent。

为什么"在我的例子上工作了"是错误的门槛

你的例子是在你已经知道 skill 应该做什么之后写的。从构成上它就是最容易的情况。混乱的真实情况——歧义的措辞、缺失的上下文、你没想到的边界条件——才是真正决定 skill 能否在真实使用中存活下来的东西。要拿这个去测试，否则你就是在测试一个你动手脚让它通过的情况。

模型更新后重新测试，至少对重要的那些

Skill 编码了关于模型行为的假设——它有多字面地遵循指令、如何处理歧义、把什么视为隐含例外。当底层模型变化时，这些假设也会漂移。你不需要在每次更新后验证每个 skill，但那些你的 workflow 真正依赖的 skill 值得重新跑一遍，而不是耸耸肩了事。

如果你在构建打算依赖的 skill——为自己或交给别人——先写 eval 再写 polish pass。这是"一个你能信任的 skill"和"一个你在期盼的 skill"之间的区别。

Full write-up: https://agentkitworks.com/answers/how-to-test-agent-skills