Skill-creator 更新解读：用 Evals 与基准测试把 Skills 做成可验证资产
很多团队已经在用 SKILL.md 沉淀流程，但一个长期问题始终存在：你知道它“能跑”，却很难证明它“稳定可用”。Anthropic 这次对 skill-creator 的更新，最关键的不是再帮你多写几个 Skill，而是第一次把 Skill 作者真正拉进了软件治理语境。
如果回头看团队里大多数 Skill 的维护方式，问题其实很统一：改完之后只能靠体感判断，模型升级后也只能靠日常使用慢慢发现回归，描述文本写得太宽还是太窄，往往要等线上误触发之后才知道。
Anthropic 这次补的，正好是这几个缺口：
- 用 evals 验证 Skill 在给定输入下是否真的达标
- 用 benchmark 持续记录通过率、耗时和 token 消耗
- 用多代理并行评测减少上下文串扰
- 用 comparator agents 做盲测式 A/B 比较
- 用描述调优降低误触发和漏触发
这些能力放在一起，改变的不是写作体验，而是决策方式。以前很多结论是“感觉这版更稳”，现在终于能开始回答“到底稳了多少、值不值得继续维护”。
原文把 Skill 分成两类，这个分类我觉得非常实用，因为它直接决定了评测问题怎么问。
第一类是 capability uplift。这类 Skill 主要在补底模短板，或者把某类任务做得更稳定。它们最怕的不是坏掉，而是随着模型进步逐渐失去必要性。所以评测重点应该是：开不开 Skill，结果差距还剩多少；如果底模已经能稳定通过 evals，这个 Skill 可能就从资产变成了负担。
第二类是 encoded preference。这类 Skill 不一定比底模“更强”，但它把团队的流程偏好写死了，比如 NDA 审核顺序、指定数据源、固定输出结构。这类 Skill 更关心流程保真度，而不是纯能力提升。评测问题也应该变成：它有没有按团队要求执行，引用有没有跑偏，输出结构是不是还守住了。
这个区分很重要。否则你很容易拿“能力增强型”的标准去评“流程偏好型”Skill，最后得出一堆不成立的结论。
我更愿意把这次更新理解成一套最小治理闭环。
第一层是基线。没有“无 Skill”或“旧版本 Skill”的对照组，就谈不上提升。很多看似合理的改动，实际只是把说明写得更长、成本拉得更高。
第二层是回归。模型和基础设施在变，Skill 今天能跑，不代表下个月还稳定。benchmark 的价值，就是把这种漂移尽早暴露出来，而不是等线上使用自己撞见。
第三层是触发。原文专门强调 description precision，这点很对。生产环境里很多 Skill 的问题甚至不在输出质量，而在根本没在该触发的时候触发。描述过宽会误触发，过窄会漏触发，Skill 越多，这个问题越严重。
第四层才是成本。通过率如果是靠明显更高的 token 和耗时换来的，那这版 Skill 也未必成立。Skill 最终要跑在真实工作流里，不是只在演示里赢一轮。
这次我最认同的另一个点，是多代理评测和 comparator agents 的组合。顺序跑 evals 很慢，而且长上下文还会互相污染；并行代理则把每个测试隔离到独立上下文里，既提速，也减少了噪声。
comparator agents 的价值也很直接：让“Skill A vs Skill B”或者“有 Skill vs 无 Skill”的比较尽量不受先验影响。很多时候我们会高估一版写得更复杂的 Skill，只因为它“看起来更完整”。盲测能把这种错觉压下去。
如果现在要把这套能力真正落进团队流程，我会先做四件事：
- 给每个核心 Skill 建一组小而稳定的 evals，先覆盖主路径和高风险边界。
- 每次改 Skill 必须同时跑对照组，避免靠印象决定去留。
- 把触发描述也纳入评测，而不是只盯输出。
- 对
capability uplift类 Skill 定期跑“无 Skill 基线”，确认它是不是还值得存在。
这也是我读完后最明确的判断：Skill 的上限不再只看你会不会写 SKILL.md，而开始取决于你有没有办法验证它、比较它、淘汰它。真正能长期积累的，未必是 Skill 文本本身，而是围绕它建立起来的 evals 和 benchmark。
这次 skill-creator 更新，真正把 Agent Skills 往前推了一步：从“可写”推进到“可测、可比、可治理”。
如果你现在已经在团队里推广 Skills，最值得先补的不是更多模板，而是一套能回答这句话的机制：这次修改，到底让 Skill 变好了多少。