给 Claude Skill 做 A/B 测试：9 个技能跑完，有 1 个反而把代码写坏了

作者给自研 TypeScript 库 mini-fp 写了 9 个 Agent Skill，但读一遍觉得没问题，不等于模型真的照着写。他做了 skill-be 工具，用「有技能 / 无技能」对照跑评测，结果平均分从 22% 提到 96%，同时揪出一个让代码变差的 validate 技能。

为什么要给 Skill 做对照实验

• SKILL.md 本质是用英文写的程序，模型负责执行，它同样会有 bug；但大多数技能没有测试，只能靠人读一遍觉得「说得对」。
• 作者维护 mini-fp（含 Option、Either、Try、Validate 的 TypeScript 库），写了 9 个 Skill 教 Claude 使用它。模型几乎没见过这个库，技能要教的东西很多。
• 手工试几次无法区分「技能起作用」和「模型随机性」，所以需要可重复的对照实验。

skill-be 的评测方法

• 每个技能配若干 scenario：一段像真实需求的任务提示（不点名 API），加一组「好答案应满足」的 criteria。
• 同一任务跑两遍：只给任务（baseline）和任务前附上 SKILL.md 全文；每版跑 3 次。
• 由第二个模型当 grader，对每条 criterion 判 YES/NO；因为 LLM 打分有噪声，每个答案评 3 次取多数。
• 判定 NOT READY 的规则：带技能仍为 0%、critical 场景带技能反而更低、或答案生成/评分失败。失败时进程退出码为 1，可接入 CI 卡发布。

全量结果：平均值好看，细节才说明问题

• 规模：9 个技能、46 个 scenario、139 条 criteria；Claude Sonnet 5.5 写代码、Claude Haiku 5.5 打分，共 276 个答案、828 次评分，约 38 分钟。
• 平均 criterion 得分从 22% 升到 96%，111 条被改善。
• 25 条在无技能时就已经 100%，说明模型本来就会；其中一部分是评测本身写错——有个 prompt 直接写了「Use sequenceValidate」，baseline 自然也用了。
• 1 条被技能弄差，正是 validate 技能被判 NOT READY 的原因。

那个把代码写坏的技能

• 场景是 Express + Prisma 注册路由：同步校验 email 和 password，异步检查邮箱是否已被占用，一次性汇总所有错误，成功则 create 并返回 201，否则 422。
• 带技能后，「把异步错误和同步错误一起累积」从 0% 升到 100%，说明技能确实被用上了。
• 但「不基于 isValid()/isInvalid() 分支、不 unwrap()」从 100% 掉到 0%：三次回答全部写成 isInvalid() 判断加 unwrapInvalid()/unwrap()，而这正是 mini-fp 想替掉的写法。
• 根因：技能只教了怎么构造 Validate，没教怎么把它变成响应。模型走到技能覆盖不到的地方，就退回自己最熟悉的模式。技能里每句话都对，缺的是一个示例，而缺示例在读的时候看不出来。

修复与写技能的建议

• skill-be 的 triage 命令会重新生成答案、评分并推测原因，这次它判断是技能缺口：matchAsync 只在技能里出现过一行，没有成功保存和返回错误的示例。
• 修复是 SKILL.md 里加 17 行：一段以 matchAsync 收尾的简短配方，并在 gotchas 里写明「要把 Validate 变成响应或最终值，用 match/matchAsync，不要 isValid() + unwrap()」。下一轮三条 criterion 全部 100%。
• 写技能的四条经验：一定要和无技能的 baseline 对比；逐条看 criterion 而不是只看平均分；把流程最后一步写出来（作者觉得显而易见，恰恰最容易漏）；prompt 里不要出现 API 名，否则测不出技能是否让模型主动去用。
• 对分数存疑时去看原始答案：skill-be run --html 会输出包含每个答案和每次评分回复的页面，可以自己复核 grader。