技能评测器：原理解析

评测器看起来是一个工具，背后其实是一条精心设计的流水线。理解它的运作方式，能帮你更聪明地使用它，也能在结果不如预期时快速定位问题。

双轨并行：对照实验的思路

每个测试用例会启动两个完全独立的 Agent。一个读了你的 Skill 再执行任务（实验组），一个什么辅助信息都没有直接上手（对照组）。两个 Agent 互不知道对方的存在，接到的 prompt 完全一样。这种设计借鉴了科学实验中的对照组思路：只有把“有 Skill”和“没有 Skill”放在同等条件下比较，才能看出 Skill 真正带来了多少提升，而不是被“这次 prompt 写得好”或“模型今天状态好”这些噪音干扰。

如果你是在改进一个已有的 Skill，对照组会换成旧版本。这样你看到的不是“有没有”的差别，而是“新版比旧版好了多少”。

三层评分机制

评分不是简单地看“输出像不像预期”。Grader Agent 的工作分三层：

第一层是断言检查。每条断言是一个可验证的判断条件（比如“输出包含日期字段”），Grader 在执行记录和输出文件中搜索证据，找到就 PASS，找不到就 FAIL。能用脚本验证的断言，它会写代码来跑，比肉眼检查更可靠。

第二层是隐含声明提取。输出里可能有一些“看起来对但没人验证”的说法，比如“表单共有 12 个字段”。Grader 会把这些声明挑出来逐一核实，帮你发现断言没覆盖到的盲区。

第三层是断言本身的质量审查。一条总是通过的断言可能毫无区分力（比如“输出是一个文件”），一条重要的结果却没有任何断言在检查。Grader 会标记这些情况，帮你在下一轮迭代中完善测试标准。

两类 Skill，两种测试目的

理解评测器的工作方式，还需要知道 Skill 本身的类型会影响你关注的重点。能力提升型 Skill 帮 Claude 做它本来做不好的事（比如 PDF 精准定位），随着模型进化，这类 Skill 有一天可能不再必要——当基线组的通过率追上 Skill 组时，就是那个信号。编码偏好型 Skill 编排你团队的固定流程（比如用特定标准审核合同），它们更持久，但价值取决于是否忠实地执行了你的流程。评测帮你持续验证这种“忠实度”。

统计聚合：从个例到全局

单次测试的结果可能受随机性影响。聚合脚本把多次运行的数据汇总成统计量——均值、标准差、最小值、最大值。标准差特别重要：如果某个测试用例的通过率方差很大（比如三次跑了 100%、50%、0%），说明要么用例本身不稳定，要么 Skill 在某些条件下会失灵。Analyzer Agent 会专门扫描这类异常模式，在报告的备注区域指出来。

Eval Viewer：人机协作的交接点

自动化评分能发现客观问题，但“这个回复的语气好不好”“图表配色是否舒服”这类主观判断只有人能做。Eval Viewer 就是这个交接点：机器先做完能做的事（跑测试、打分、统计），然后把结果整齐地摆在你面前，让你用人类的判断力做最后的裁决。

Viewer 是一个自包含的 HTML 页面，不需要安装任何依赖。它的后端是一个 Python 标准库写的 HTTP 服务器，每次刷新都会重新扫描工作目录，所以你可以一边等测试跑完一边刷新看新结果。你的批注实时保存，提交后生成 feedback.json，Claude 读取后进入下一轮改进。

描述优化：让 Claude 在该用的时候用

Skill 的 description 字段是 Claude 决定“要不要调用这个 Skill”的唯一依据。描述优化模块的工作原理是一个典型的“评测-改进”循环：先用 claude -p 模拟真实用户查询，看 Claude 会不会调用这个 Skill；然后用 AI 分析哪些查询判断错了、为什么错了，提出改写方案；再测试、再改写。

为了防止“训练集上表现好但实际场景不行”的过拟合问题，系统会把测试查询按 60:40 分成训练集和验证集，最终按验证集的得分选出最佳描述。每轮迭代的结果会实时更新到一个 HTML 报告页面，你可以随时查看进度。

从评测到规格说明：未来的方向

今天的 SKILL.md 是一份详细的“实施计划”，告诉 Claude 具体怎么做每一步。但随着模型能力的提升，“Skill”和“规格说明”之间的界限正在模糊。评测框架已经在描述“Skill 应该做到什么”——有一天，这份描述本身可能就是 Skill，模型自己来想办法做到。评测不会过时，因为无论 Skill 的形态怎么变，“验证它是否真的做到了”这件事永远需要。