Skill 如何测试与迭代

系列入口：如何使用 Agent。前置：写第一个 Skill。

一、Skill 有两类独立的「对错」

测试一个 Skill，要把两件事分开看，因为它们会分别出问题：

1. 触发对不对：该用它的时候调用了吗？不该用的时候误触发了吗？这由 description 决定。
2. 执行好不好：触发之后，它产出的步骤和结果正确吗、稳定吗？这由指令和资源文件决定。

新手往往只看第二层（跑了一次结果还行就收工），忽略了触发层。结果在真实使用中，它要么该用时没反应，要么动不动就插进来。这两层要分别测、分别调。

二、第一步：建一个正反用例集

为 Skill 准备两组测试输入，写下来固定成集合（这样每次改动都能重跑）：

• 正例（应该触发）：用不同说法表达同一意图，比如「我准备提交了」「帮我 commit」「提交前帮我看看」——覆盖用户真实的多种措辞。
• 反例（不该触发）：相似但意图不同的任务，比如「解释这个函数」「重构这个模块」「帮我新建分支」——它们和目标场景有部分重叠，最容易误触发。
• 边界例：模糊两可的情况，用来观察它的判断倾向。

用例不需要多，初期 8~12 条（正负各半）就很有效，关键是代表性强、能复用。

三、第二步：量化两类指标

跑完用例集，记录：

指标	定义	目标
触发准确率	正例中正确触发的比例	接近 100%
误触发率	反例中被错误调用的比例	接近 0
产出质量	触发后结果是否正确、完整、格式稳定	稳定可接受

不用追求一次全绿，第一轮能看清「问题集中在触发还是执行」就达到目的。

四、第三步：对症调优

• 正例没触发：说明 description 场景写窄了，把这种说法/场景补进描述。
• 反例被误触发：说明描述太宽泛，收紧边界，必要时写明「不适用于 X」。
• 触发对但结果差：问题在指令或资源文件——步骤不清就细化，易错环节就补示例，可程序化的动作改成脚本。

一次只改一处，再跑用例，才能确定是哪处改动起了作用，避免越调越乱。

五、第四步：回归与版本管理

Skill 也是资产，值得像代码一样管理：

1. 改完重跑整个用例集做回归，确认新改动没破坏原本正确的情况。
2. 保留稳定版本，Skill 纳入 git，每次实质改动写清变更点（改了描述还是指令、为什么）。
3. 用真实任务持续校准：日常使用中每遇到一次「该触发没触发/误触发」，就把它加成一条新用例。用例集越滚越全，Skill 越来越稳。

一个轻量的做法是在 Skill 目录放一个 tests/cases.md 记录用例和历史结果，改动时对照，团队协作时也能共享同一套评估口径。

总结

把 Skill 当代码测：建正反用例集、分别量化触发准确率和产出质量、一次改一处对症调优、改完回归并纳入版本管理——再把真实使用中的每次失误补成新用例，Skill 就会在迭代中越来越可靠。