新模型上技能语料表现退化时…

当一份 skill 语料在新模型上行为退化时，先量化基线、噪声底线和上线标准，再对抗式审计并小步删减，直到越过预先注册的 bar。

适用场景

解决思路

1. 先过 Phase 0 测量门禁，逐项确认三样东西存在并指出缺哪一项：(1) 一份 run archive，或能产出它的 harness——每次运行的日志需带 tool-call trace、终止标记、token 计数和最终消息；(2) 一个 build selector——harness 能把一次运行指向语料的某个源码 checkout（`--plugin-dir` 式覆盖、可配置的 skills 路径、环境变量），使两个 build 能在同一个 runner 下对比；(3) 一个语料真正端到端执行的可重复任务。
2. 三项中任何一项缺失就停下来并说明缺什么、需要建什么；不要退回静态审计并把它当作 retuning 汇报——审计只能说什么看起来可删，永远说不出删了有没有用；只做审计是合法的需求，但那是另一个请求。
3. 继续之前先说明目标模型和你找到的 harness。
4. 派发任何 phase 之前先读 `references/workflow-shapes.md`——orchestration shape 选错是最常见的失败。
5. 按不相交的文件所有权 fan out，绝不要按条目分派——条目会跨文件，共享同一个文件的 agent 会互相覆盖编辑。
6. Phase 1：在花掉一次运行之前先挖 archive（`references/baseline-mining.md`）——历史运行是免费的基线，通常比现在付得起的任何实验都大。
7. Phase 2：建立噪声底线（`references/noise-floor.md`）——用 harness 跑两份完全相同的语料副本，两边同一个 commit；出现的任何差异就是此后每一个结论都必须越过的底线。
8. 在任何改动存在之前，现在就以书面形式注册 bar。看到结果之后才挑的 bar 不算 bar。
9. Phase 3：对抗式审计语料（`references/corpus-audit.md`）——每个 skill 由一个 agent 提出删减，另一个 agent 做相反的事、为现有文字辩护。这两遍必须在互相独立的上下文中进行。
10. 如果宿主没有把两遍作为独立 agent 运行的办法，就把它报告为 blocker 并停止审计——不要在同一个上下文里替双方辩论，然后把结果当作审计交付。
11. Phase 4：以外科手术式的小步删减，每个 agent 只处理一个问题（`references/cut-passes.md`）；当症状是卡住、停摆，或运行结束时点名了它没做的工作时，用 `references/halt-taxonomy.md`。
12. 永远不要为了让测试套件变绿而改测试——测试所钉住的字符串被移除是一个要汇报的 finding，不是要削弱的测试。
13. 不是每一次停止都是敌人：有些 workflow 的存在就是为了停下来提问，那正是产品本身；动任何 stop 之前，先按「另一边实际上是谁」给每个 stop 分类。
14. 在删减任何 stop 之前，先读 `references/halt-taxonomy.md` 里做判定的 screen。
15. Phase 5：测量，然后让失败来挑选下一个修复（`references/cut-passes.md`）——那里也说明每个失败点意味着什么，以及如何审计仪器从未进入的那些 phase。
16. 循环 Phase 4 和 Phase 5，直到已注册的 bar 被越过，然后停止；bar 越过即完成。同时汇报哪些东西始终未被测量：bar 越过从不意味着它并不具备的覆盖面。
17. Phase 6：发布（ship）——`references/cut-passes.md` 载明 commit 和书面总结必须保留什么。
18. 按此判定完成：bar 被越过，或运行报告出它无法支持的那个具体论断。测试套件全绿不算完成——它只证明没有东西坏掉，不证明行为变好了。
19. 不要以字数缩减为目标——精简和性能是共享同一份语料的两个独立项目，这里的结果只是其中一个。汇报完成情况，而不是字数。

适用边界 · 注意事项

• 没有可 A/B 两个 build 的基准 harness 时（缺 run archive、缺 build selector、缺可重复任务），本技能无法运行，应停下并说明要建什么。
• 只想做静态审计（只看什么看起来可删）时——那是另一个请求，不能当作 retuning。
• 目标只是减少字数、让语料更精简时——精简与性能是两个不同项目，字数不是本技能的结果。