ce-retune

为新模型重新调优语料库

语料库在新模型上的表现变差，首先是测量问题，其次才是写作问题：重写看起来有问题的内容，会得到一份看似合理的修复清单，却无法知道其中任何一项是否真的有用。

目标： 语料库在目标模型上的实测表现达到任何更改之前登记的门槛，回归问题得到消除，且每项消除都能追溯到具体更改。

完成标准： 达到门槛，或报告本次运行无法支持的具体结论。测试套件全绿不代表完成：它只能证明没有东西被破坏，不能证明行为有所改善。

非目标： 减少字数。精简与性能优化是共享同一语料库的独立项目；这里只以其中一个项目的结果为准。报告完成情况，而不是字数。

阶段 0：测量门槛——先检查这一项

如果无法观察行为，这项技能就无法运行。检查以下三项，并指出缺少的项目：

1. 运行存档或可生成存档的测试框架——包含工具调用跟踪、终止标记、Token 计数和最终消息的逐次运行日志。
2. 构建版本选择器——测试框架可以将一次运行指向语料库的特定源代码检出版本（例如 --plugin-dir 风格的覆盖选项、可配置的技能路径或环境变量），以便在同一运行器下比较两个构建版本。
3. 语料库实际端到端执行的可重复任务。

如果缺少任何一项，请停止并说明原因，指出需要构建什么。不要退而求其次，改做静态审查并将其当作重新调优：审查可以指出哪些内容看起来可以删减，却无法判断删减是否有帮助。只做审查是合理的需求，但它属于另一项请求。

继续之前，说明目标模型和找到的测试框架。

各阶段

这些阶段按顺序执行，每个阶段都会注明启动前必须阅读的参考资料。派发任何阶段前，请先阅读 references/workflow-shapes.md：编排方式错误是最常见的失败原因。按文件所有权互不重叠的方式分派任务，绝不要按条目分派。条目会跨越多个文件，共享同一文件的 Agent 会覆盖彼此的编辑。

在评估是否达到已登记的门槛或解读结果之前，请先阅读 references/noise-floor.md。

1. 先挖掘历史记录，再花费一次运行 — references/baseline-mining.md。历史运行是免费的基线，规模通常大于当前任何负担得起的实验。
2. 确定噪声底线 — references/noise-floor.md。让测试框架对语料库的两个相同副本运行；两边使用相同的提交。出现的任何差异都是后续每项主张都必须超越的底线。现在就以书面形式登记门槛，且必须在任何变更出现之前。 看过结果后才选定的门槛不算门槛。
3. 以对抗性方式审查语料库 — references/corpus-audit.md。每项技能由一个 Agent 提议删减，另一个 Agent 则反其道而行，维护现有文案。两轮审查必须使用相互独立的上下文。 如果宿主没有办法将它们作为独立 Agent 运行，请将此报告为阻塞问题并停止审查——不要在同一个上下文中同时争辩双方观点，再把结果说成是一次审查。
4. 分轮精准删减，每个 Agent 处理一个问题 — references/cut-passes.md；如果症状是停滞、停止，或运行结束时还提到未完成的工作，则还需阅读 references/halt-taxonomy.md。无论删减哪一类内容，每轮都受两条规则约束。绝不要为了让测试套件通过而修改测试：测试所固定的字符串若被删除，这是需要报告的发现，不是弱化测试的理由。而且并非每次停止都是敌人。 某些工作流的目的就是停止并询问；这正是产品设计。处理停止之前，先根据实际需要响应的一方对每次停止进行分类。references/halt-taxonomy.md 提供了用于判断的检查项，因此删减任何停止行为前都要先阅读。
5. 测量，然后让失败决定下一项修复 — 再次阅读 references/cut-passes.md，了解每个失败位置意味着什么，以及如何审查仪器从未进入的阶段。重复第 4 和第 5 步，直到达到已登记的门槛。然后停止；达到门槛就算完成。同时报告仍未测量的内容：达到门槛绝不意味着覆盖了实际未覆盖的内容。
6. 交付 — references/cut-passes.md 说明提交和总结必须保留的内容。