听起来很好的规则，为什么实测反而更差？#

你有没有过这样的经历？在项目的 AGENTS.md 里加了一条自认为很精妙的规则，比如"优先使用已有的 helper 函数，不要重复造轮子"，然后信心满满地让 Codex 去干活。结果发现，Agent 的表现反而变差了。

这不是段子。一位独立开发者最近做了一个严谨的实验：让 Codex 用八轮迭代优化自己的 AGENTS.md，每轮都在真实的历史 PR 上跑评测。最终结果令人意外，在训练集上表现最好的那个版本，放到干净的留出集上反而出现了退步。

这个实验背后的方法论和发现，对每一个正在使用 AI 编程助手的团队都有参考价值。

为什么要认真对待 AGENTS.md？#

在 2026 年的开发工作流里，AGENTS.md 已经不是什么新鲜事物了。几乎每个使用 Codex 或 Claude Code 的团队都会维护一份这样的文件，告诉 Agent 项目的编码规范、架构约束和行为准则。

但大多数人对待 AGENTS.md 的方式是这样的：某天觉得 Agent 的行为不太对劲，于是加一条规则，写得很漂亮、很有道理，提交，然后祈祷 Agent 变聪明。

问题是，AGENTS.md、CLAUDE.md 这类共享指令文件不是普通的文档。它们是编码系统的运行时行为的一部分。改一行规则，就等于改了整个系统的行为逻辑。

那我们能不能像对待生产代码一样对待 AGENTS.md？不是凭感觉改，而是用数据说话？

实验设计：让 Codex 自己优化自己#

这位开发者的实验设计相当巧妙。

他给 Codex 下了一个目标：迭代优化 AGENTS.md，在基准测试上提升性能。测试用的是他自己项目 Stet.sh 的真实历史任务，一共 15 个 PR。其中 5 个用于训练（迭代调优），另外 10 个是干净的留出集（最终验证）。

模型配置是 Codex + GPT-5.5，中等推理强度。评分用 GPT-5.4 做自动评审，维度包括：

  • 测试通过率
  • 等价性（Agent 的补丁是否匹配人类 PR 的意图）
  • 代码评审质量（正确性、作用域、可维护性）
  • 足迹风险（Agent 比人类 PR 多触碰了多少代码）
  • Token 消耗和工具调用次数

每一轮迭代，Codex 提出一个新的 AGENTS.md 候选版本，在 5 个训练任务上跑评测，然后根据结果决定是推进还是回滚。

八轮迭代的戏剧性过程#

第一轮：听起来很对，实测很差#

Codex 的第一条候选规则是一个"路由规则"：先识别工作类型，编辑前陈述假设，读取正确的文档，把作用域当作正确性的一部分。

听起来很专业对吧？但它暴露了一个失败模式：Agent 把"小作用域"理解成了"可以忽略已命名的义务"。规则太抽象，Agent 走了捷径。

第二轮：义务台账的突破#

Codex 加了一个"义务台账"机制。编辑之前，Agent 必须列出所有已命名的行为、兼容性约束、文档、测试和非目标。报告之前，必须逐项标记为"已满足"“已遗漏"或"未检查”。

这个版本在训练集上表现亮眼：代码评审 +0.75，正确性 +0.60，可维护性 +1.00，简洁性 +0.64，一致性 +0.60，作用域纪律 +0.36。测试全过。

如果凭感觉判断，这个版本可以直接上线了。但评测数据说：方向正确，但不是干净的胜利，继续迭代。

第三轮到第六轮：直觉的陷阱#

接下来几轮暴露了一个关键洞察：更多流程不等于更好的纪律，有时候只是更多的仪式。

Codex 试了一个"优先使用已有工具"的规则，直觉上完全正确，评测却讨厌它。测试还是全过（这正是危险所在），但简洁性、一致性、鲁棒性、作用域纪律全部下降。

又试了一个更严格的版本：要求在编辑前必须精确定义所有者文件/函数和验证命令。听起来更严谨了。结果更差了。

第七轮：训练集上的最佳候选#

第七轮是最有希望的版本。它把义务规则变得更具体：先识别义务，再识别变更的所有者，然后确认验证路径，最后才动手编辑。

在 5 个训练任务上，它修复了基线版本错过的那个任务，足迹风险从 0.41 降到 0.31，Token 消耗也大幅下降。看起来是个赢家。

第八轮：留出集上的残酷真相#

然后，这个版本被放到了 10 个干净的留出任务上。

结果：测试全过（10/10），作用域纪律却退步了，Token 消耗反而上升了，代码评审的正确性下降了。

没有灾难性的崩溃，但足以说明：盲目上线是错误的决定。

“AGENTS.md 反转"现象#

这个实验揭示了一个被大多数人忽略的现象，我称之为"AGENTS.md 反转”。

一条指令变更可以让大部分任务变好，同时让一个可测量的子集变差。平均值在改善，但特定类型的任务在退步。

这就是为什么凭感觉编辑共享指令文件是危险的。失败模式不是"所有东西都变差了"，而是"足够多的东西变好了，以至于你忽略了那些被伤害的部分"。

在共享代码库上，这个问题尤其严重。你提交了 AGENTS.md 的变更，你自己的任务变好了。但你的同事不知道指令变了，他们的任务悄悄变差了。没有人会报 bug，因为 Agent 还是能通过测试、能提交补丁、在代码评审里看起来也没问题。

退步隐藏在跨任务分布的聚合行为里，而这个分布没有人测量过。

一个可复现的方法论框架#

这个实验最有价值的部分不是某个具体的发现，而是它提供了一个可复现的方法论：

有界循环（Bounded Loop）：

  1. 写一个假设（候选 AGENTS.md 规则）
  2. 在真实工作上测试（n=5 历史任务）
  3. 检查失败（质量分裂，不是测试失败）
  4. 修订规则（义务、所有者、验证路径）
  5. 跑留出集（干净的 n=10 切片）
  6. 验证声明（不要在混合证据上上线）

这个循环的精髓在于：不是让模型在真空中递归地让自己变得更聪明，而是一个有边界、有度量、有验证的迭代过程。

就像生产环境的灰度发布：一个变更可以通过 CI、通过端到端测试，但还是可能在生产中出问题。所以我们监控灰度发布，认真对待回退。

对日常开发的启示#

如果你正在维护团队的 AGENTS.md 或 CLAUDE.md，下次想加一条规则的时候，可以问自己这几个问题：

  • 这条规则应该改变什么行为？
  • 哪些真实任务能暴露这个行为变化？
  • 它是改善了行为，还是只改善了感觉？
  • 它让什么变差了？
  • 留出集同意这个变更吗？

最后一点尤其重要。大多数团队加规则的方式是"这听起来很对"，而不是"这在 10 个未见过的任务上提升了 3 个维度，没有在任何维度上退步"。

AI 原生团队和使用 AI 的团队之间的差距，不仅仅是使用模式的差异，更是如何度量和塑造共享上下文变更的能力差异。

我的看法#

这个实验最打动我的地方，不是某个具体的技术发现，而是一种工程态度。

在 AI 编程助手快速普及的今天，大多数人还在用"拍脑袋"的方式调优 Agent 的行为。加一条规则，感觉不错，就上线了。没有人去量，没有人去验证，没有人去跑留出集。

这就像在没有测试的代码库上写代码一样。短期看不出问题，长期一定会出问题。

好消息是，这个方法论的门槛并不高。你不需要什么特殊的工具，只需要一组历史任务、一个评分标准，和一个愿意花时间做实验的工程师。

坏消息是，大多数人不会这么做。因为"凭感觉加规则"太方便了，而"跑八轮迭代做评测"太麻烦了。

但正如这位开发者所说：真正有价值的不是那些听起来很好的规则，而是那些被数据验证过的规则。

参考来源： 本文基于 stet.sh 的实验文章进行原创分析和重写。