从代理新闻中提炼的三个想法，变成了检查：我们引入到 harness 中的与放弃的

一周之内，有三个关于 AI 代理的想法在我读的每个渠道里流传。Karpathy 建议让模型像飞机手册那样写作。Google Research 发布了 Harness²，这是一个改进模型周围环境、而不是改进模型本身的框架。OpenAI 的工程师讲述了他们如何在两周内用代理删除了 80 万行死代码。三者都很好。但它们三者都以"在你的提示词里加一行神奇的话"的形式出现，而提示词恰恰是下一次调用时会漂移的东西。所以我们把它们引入了我们的开源配置 github.com/AnastasiyaW/codex-claude-code-config，并以检查的形式实现。下面是我们保留了什么、舍弃了什么，以及原因。

飞机手册：九十条规则里的两条

标准是 ASD-STE100，即简化技术英语（Simplified Technical English）。航空业使用它，是为了让机械师对每条指令只读到一种含义。10 月 2 日，Karpathy 给出了一个让模型输出更易读的方法排序：先是这种风格的文字，然后是图示，然后是交互式 HTML 页面，最后是定制的讲解视频。这个阶梯本身就很有用。大多数回答只需要第一级，架构改动需要第二级，而包含大量数字的比较才值得第三级。

"请严格按照 STE100 写作"这句话比看上去弱。完整的标准有一个约 900 词的受控词典，以及数十条规则。这部词典有版权，而且模型并不可靠地掌握它。如果要求严格遵循，你得到的是一种模仿：句子被切碎，但那并不是标准。

有两条规则承载了大部分价值，而且不需要词典：

• 一个概念，一个术语。 如果项目里说的是"worker"，那么每个句子都说"worker"。模型喜欢用同义词来求变化。于是技术读者得自己去判断"worker"、"handler"和"executor"是三个东西还是一个。
• 短句。 STE 将指令限制在 20 个词以内，描述限制在 25 个词以内。

我们把这两条做成了机械的检查。scripts/term_drift_check.py 读取项目词汇表，并对照它检查代理写出的内容。像 обработчик* 这样的术语表条目会匹配这个词的所有形式，因此这项检查对俄语同样适用。现有的 STE 检查工具做不到这一点，因为标准本身是为英语设计的。代码块、链接和注释会被跳过。退出码为 0 表示干净，1 表示有发现，2 表示检查无法运行。我们需要第三种状态，因为一个悄悄地什么都没检查的检查，比没有检查更糟。

第一个版本正好有这个问题。一位独立的审查者，也就是一个上下文全新的单独代理，找到了三种可以在什么都没检查的情况下得到绿色结果的方式：非 UTF-8 编码的文本、未闭合的代码块，以及没有同义词的词表，都会被判定为干净。第二位审查者又找到了五种。它们全部已修复，而自检现在包含必须失败的用例，因此失效的检测器不能悄无声息地通过。

Harness²：方法可用，自动修补器不用

Harness² 背后的想法很有力。模型权重保持不变。代理提议对其周围环境进行修改：系统提示词、记忆、工具指引、技能、脚本、插件。它在任务上运行这些修改，保留有帮助的部分，并把教训记住，供下一次使用。在三个专业工作基准上，一轮这样的过程使 GLM-5 和 Gemini 3.5 Flash 的成绩提升了最多 11.5 分。

我们没有照原样安装它。在它的 README 中，执行器在开放网络中运行，并且关闭了 Codex 沙箱；此外也没有针对留出任务的协议。对于一个会编辑自己规则的代理而言，这是主要风险：它会在见过的任务上变好，却悄悄地搞坏没见过的任务。

所以我们把这个方法作为一个边界清晰的小型试点来采用：

• 一组冻结的三到五个任务，外加至少一个未用于调优该改动的留出任务；
• 每个候选只做一项改动，使原因一目了然；
• 每个任务都有机械式的凭据，而不是对结果的意见；
• 只有在严格改善、且安全性或留出任务没有任何退步时，候选才会获胜；
• 实时 hook、权限和护栏从来不是试点的对象。

比较器读取两份凭据并给出裁决。它不运行代理，也不触碰实时配置。被接受的结果只是供审查的证据，而不是部署。

死代码：证据必须来自生产环境

OpenAI 的数字令人印象深刻：两周左右，超过 1,400 个已合并的 PR，删除了超过 80 万行。一个容器镜像缩小了 48%，CI 的中位时间从约十分钟降到四分半。让它成功的并不是提示词，而是流程。

删除代码是一类特殊的改动。当不可达的代码消失时，什么都不会失败。而如果你对它"不可达"的判断是错的，在生产环境出问题之前，也不会有任何失败。所以证明必须来自生产：遥测、实时的功能开关状态、每一个调用点（包括间接调用），以及负责人。审计是只读的。每次删除都是一个小型的草稿 PR，证据和推理写在描述里。紧急开关（killswitch）和安全保护从来不会因为代理的一句话而被删除。

我们把它作为一份参考资料加入了 refactoring-safely 技能。现在，当有人要求删除死代码或陈旧的功能开关时，该技能也会被触发。

代码中的注释：研究给出的结论略有不同

与此同时，我想检验一个我们已经在遵循的想法：如果代理既编写又阅读代码，那么大多数注释只会浪费上下文。我们从 10 月 15 日起就有这条规则，于是我去查找了相关的研究。结论比"注释是噪声"更有意思。

• 过时的注释会把生成的代码拉向旧的实现。
• 模型可能会更相信注释，而不是与之矛盾的代码。
• 缺少注释在我找到的研究中影响不大。
• 对非显而易见代码的正确注释确实有帮助：在一项针对遗留大型机代码的研究中，准确率从约 84% 提高到 90–96%。

这些样本都很小，而且我只读了其中两篇论文的摘要，所以对于确切数字应当谨慎对待。不过方向是清楚的：一条撒谎的注释，比没有注释更危险。因此我们在规则中加了一条要求。如果你修改了代码，就要在同一次提交中修改或删除紧挨着它的注释。只是复述代码的注释要删掉。原因、数字的来源，以及下一个代理否则会"修复"掉的那个陷阱，应当保留。

仓库中现在有什么

• docs/output-legibility.md：可读性阶梯和两条规则，附一句比"用 STE100 写作"更有效的提示词；
• scripts/term_drift_check.py：词表检查，附测试和自检；
• docs/harness-improvement-pilot.md 及其比较器：有边界的试点；
• refactoring-safely 技能中的 references/dead-code-sweep.md；
• rules/quality-code.md 中更新后的注释规则。

全部内容都在发布版 v2026.10.24 中，完整的改动列表在 UPDATES.md 里。代理可以直接从仓库中取它需要的东西：先看 CLAUDE.md 和 README.md，然后是 skills-lock.json 中列出的技能。

如果这里的某些内容为你省下了一天时间，在 GitHub 上点个星能帮助别人找到这个仓库。如果有什么出了问题，请提一个 issue：我们的大部分规则，一开始正是从那里来的。