用对照评测精简Agent技能指令

Skill 里的规则很容易越积越多：模型漏了 await，就补一条；mock 错了对象，再补一段。可模型升级后，旧问题可能已经消失，补丁却一直留着。作者提出的办法是：用评测找出模型本来就会做的事，再验证哪些指令可以删掉。

这篇最有用的地方，是把「规则有没有用」拆成了效果、成本和模型差异三个问题。不过，提供的原文缺少几张关键表格，部分结论只能依据作者的文字描述判断。

怎么知道一条规则还在起作用

作者使用 claude plugin eval，让每个用例分别在启用插件和不启用插件时运行。后者提供基线：没有额外指令，模型自己能做到哪一步？

示例插件是 twd-ai，测试模型是 Opus 5.5，共 8 个用例，每个用例运行 3 次，所有运行使用同一个评判器。文中的 Δ 表示启用插件带来的评分差异，但原文没有给出具体计算公式。

作者把规则分成两类：

• 知识类规则告诉模型它缺少的信息，例如库的配置、项目约定、团队惯用的辅助函数。
• 纪律类规则提醒模型执行它已经知道的动作，例如先运行筛选后的测试、读取报告、不要修改应用代码。

前一类的价值通常更稳定，尤其是模型无法从公开训练资料中学到的内部约定。后一类则依赖模型自身能力，可能在升级后逐渐失去作用。

第三方组件替换用例就是例子：Skill 教模型用假组件替换真实组件，但相关公共 API 已经在 Opus 的训练数据里。作者报告，这个用例的 Δ 为 0。

另外，第 8 个用例检查 Skill 是否会介入不相关的请求，作者说明它的 Δ 始终为 0。它与其他用例的检查目的不同，不能看到零分差就直接判断规则冗余。

成本上涨，究竟是浪费还是必要开销

作者同时记录每次运行的费用和轮次。两个用例启用 Skill 后都更贵，却对应完全不同的判断。

组件替换用例的评分没有变化，费用增加了 57%，还多出 5 个轮次。就这个模型、这个用例而言，额外指令没有换来可见的质量收益。

库的初始化用例则不同：启用 Skill 后成本翻倍，但不启用时，模型会根据过时记忆完成错误配置。多花的钱是在购买正确结果。

只有结果质量相当，费用和轮次才适合直接比较。

这也是日常 AI 编程里容易忽略的问题。一次执行结束得快、账单低，并不能证明流程更好；它可能只是少做了必要步骤。反过来，指令更长、执行更久，也需要拿结果解释成本。

Opus 不需要的规则，Haiku 可能还需要

作者没有因为 Opus 的 Δ 为 0，就立刻删除组件替换说明。他又比较了其他模型，并报告：模型越小，这段 Skill 带来的帮助越大，Haiku 最需要它。

因此，删除标准必须覆盖实际支持的模型。

作者目前采用的流程是：当一个章节在所有受支持模型上的 Δ 都接近零时，把它列为删除候选；删除后重新运行整套评测，确认启用插件时的评分保持原有水平。如果下降，就恢复该章节，因为它可能发挥了原先分差没有揭示的作用。

这里有两道检查：先用基线筛选，再用删除实验确认。

作者把它称为反向 TDD：评测持续通过，Skill 越改越短。不过，「接近零」的阈值如何设定，原文没有说明。

我的判断

我认可这套思路：Skill 应该随着模型能力变化接受复查，历史上修过问题的规则，也需要证明今天仍然有用。尤其是同时支持多个模型的团队，不能用最强模型的表现替所有用户做决定。

但「知识类稳定、纪律类递减」更适合作为排查方向。公开库配置也可能被新模型学到，纪律类要求则可能在长任务或复杂上下文里继续发挥作用。

证据也有局限。原文提到的评分表、成本表和跨模型对照表没有出现在输入中，因此无法核对具体分数、波动或其他模型的收益幅度。每个用例运行 3 次提供了一些重复观察，但作者没有给出统计分析。这是一套有操作价值的经验方法，还不足以证明所有团队都能稳定节省相同比例的成本。

能拿来做什么

• 给团队现有 Skill 挑几项高频任务，例如库初始化、组件替换和测试执行，同时记录启用与停用时的正确性、费用和轮次，先建立基线。
• 整理前端或 Node 项目的指令时，标出哪些属于内部约定，哪些只是通用操作提醒，优先检查后者是否仍有收益。
• 如果团队同时使用 Opus 和 Haiku，就在两者上验证删除候选；删完重跑整套评测，评分下降便恢复对应章节。
• 保留不相关请求的用例，检查 Skill 会不会错误介入任务。它测试的是适用边界，不能仅凭 Δ 为 0 就把它删掉。