很多开发者开始认真使用Codex以后，都会慢慢做一件事：

给项目写AGENTS.md。

一开始可能只有几条：

不要修改某个目录。

提交前必须运行测试。

保持现有API兼容。

不要新增不必要的依赖。

后来项目越来越复杂，规则也越来越多。

十几条。

几十条。

甚至开始把：

项目架构、代码规范、测试要求、目录说明、命名规则、兼容要求、数据库约束……

全部写进去。

按道理说，给Codex的信息越完整，它应该越不容易犯错。

但实际使用一段时间以后，很多人反而会遇到一个很奇怪的问题：

AGENTS.md明明写得越来越详细，为什么Codex还是会漏掉里面的规则？

甚至更让人困惑的是：

有些规则它明明遵守了很多次。

换一个任务，却突然像没看到一样。

于是很多人的解决办法是：

继续加规则。

漏了一次测试要求，就再强调一次测试。

改错了目录，就把“禁止修改”写得更醒目。

最后AGENTS.md越来越长。

但Codex并没有按照同样的比例越来越稳定。

问题到底出在哪里？

真正的原因可能不是：

规则写得还不够多。

而是：

当规则越来越多以后，Agent真正需要解决的问题已经从“有没有规则”，变成了“当前任务到底应该调用哪些规则”。

---

一、AGENTS.md真正解决的，不是“让Codex记住更多东西”

很多人会把AGENTS.md理解成：

给Codex准备的一本项目说明书。

于是很自然地认为：

说明书越详细越好。

但Agent执行任务时，并不是单纯把AGENTS.md背下来，再机械地按照每一条规则执行。

它面对的是一个动态任务。

比如你让Codex：

修复用户头像上传失败的问题。

此时它真正需要组合的信息可能包括：

用户这一次提出的目标；

上传模块当前实现；

Repository里的相关代码；

AGENTS.md里的项目约束；

测试和工具执行结果；

任务过程中刚刚发现的新信息。

也就是说，AGENTS.md只是整个Context的一部分。

真正的问题不是：

“Codex有没有看到这条规则？”

而是：

“在当前任务里，这条规则的重要性够不够高、相关性够不够强，能不能进入Agent当前的决策过程？”

这两件事完全不同。

---

二、规则越多以后，真正增加的是“规则竞争”

假设一个项目只有5条规则：

1. 不修改数据库Schema；
2. API保持向后兼容；
3. 修改后运行测试；
4. 不新增第三方依赖；
5. 使用现有组件。

现在让Codex修改一个接口。

其中：

API兼容、测试、不新增依赖，

明显和当前任务有关。

Agent需要处理的规则关系很简单。

但如果AGENTS.md里有100条规则呢？

里面同时包括：

CSS规范；

React组件规范；

数据库规范；

API规范；

日志规范；

测试规范；

文件命名；

移动端要求；

国际化；

性能要求；

部署要求……

此时问题发生变化。

不是信息不足。

而是：

大量规则开始争夺Agent的注意力。

真正与当前任务相关的，也许还是那5条。

剩下95条虽然没有错，但对当前任务没有直接价值。

这就出现了一个很重要的机制：

Context增加，并不等于有效Context同比增加。

真正决定Agent执行质量的，不只是“给了多少信息”，而是：

有效信号在全部信息里的密度。

所以AGENTS.md越长，不一定越强。

有时候反而会出现：

规则数量增加了，但规则信号密度下降了。

---

三、为什么最重要的规则也可能被漏掉？

这里还要继续往下挖一层。

因为不同规则的性质其实完全不同。

比如：

“使用TypeScript。”

这是全局规则。

几乎所有任务都适用。

但：

“修改支付Webhook时，不允许改变事件幂等逻辑。”

这是局部规则。

它可能极其重要。

但只有碰到支付Webhook时才应该被激活。

还有一种：

“修改数据库Migration之前，先检查旧版本客户端兼容性。”

这实际上已经不是普通代码风格。

而是一个带触发条件的规则。

所以一个成熟的AGENTS.md真正需要表达的不只是：

规则是什么。

还应该让Agent容易判断：

什么时候这条规则才重要。

如果所有规则都平铺在一起：

重要规则和普通规则一样；

全局规则和局部规则一样；

必须遵守和建议遵守也一样，

Agent就需要自己从大量文字中推断优先级。

规则越多，这个判断成本越高。

所以很多AGENTS.md真正缺的不是更多内容。

而是：

规则层级。

---

四、判断自己的AGENTS.md有没有开始失效，看“规则命中率”

这里可以给自己建立一个很简单的自测指标：

规则命中率

这不是OpenAI官方指标，而是我们用来判断AGENTS.md质量的一个方法。

定义很简单：

一次具体任务中，AGENTS.md里的规则有多少真正和当前任务有关？

比如你的AGENTS.md有50条规则。

一次API修改真正相关的是：

接口兼容；

错误处理；

测试；

日志；

依赖要求。

一共5条。

那么当前任务的有效规则大概只有：

5 / 50。

真正需要关注的不是这个数字必须达到多少。

而是一个趋势：

如果每次任务都只有极少数规则真正有用，那么AGENTS.md可能已经从：

高密度项目约束

慢慢变成：

大型项目资料库。

资料没有错。

但Agent每次都要重新从里面找重点。

这时候继续增加规则，收益就会越来越低。

---

五、先别换模型，先把AGENTS.md从“规则仓库”改成“规则路由”

所以遇到Codex不遵守AGENTS.md，第一反应不应该是：

模型不够强。

也不要马上继续加几十条规则。

先重新整理规则。

第一层：真正全局的规则

只保留几条所有任务都必须遵守的东西。

例如：

必须运行测试；

不能泄露Secrets；

保持公共API兼容；

不要无关重构。

这些规则应该短，而且明确。

第二层：按任务范围拆规则

Frontend有Frontend规则。

Backend有Backend规则。

Database有Database规则。

Security有Security规则。

不要让修改一个CSS的任务，也携带一整套数据库Migration说明。

第三层：给关键规则增加触发条件

不要只写：

注意兼容性。

而应该更具体：

修改Public API时，必须保持现有Response字段兼容。

不要只写：

注意安全。

而是：

修改认证、权限、Token或用户输入处理时，必须检查权限边界和输入验证。

这样Agent更容易知道：

什么时候应该把这条规则提高优先级。

---

六、规则命中率高，Plus通常已经足够

现在再看Plus和Pro。

如果你的项目是：

个人项目或中小型Repository；

规则数量并不多；

任务边界比较清晰；

AGENTS.md经过整理以后，大多数任务只需要少量明确规则；

Codex偶尔漏规则，但不需要频繁处理非常复杂的Repository Context，

那么你的问题通常不是：

需要更高套餐。

而是：

需要更好的规则组织方式。

这时候先把AGENTS.md做短、做准、做分层。

Plus配合清晰的项目规则和任务边界，通常已经能够覆盖大量日常开发。

换句话说：

规则命中率高，说明你的Agent不需要每次从大量Context里重新找重点。

这种使用方式更接近Plus。

---

七、规则命中率低，而且项目规则本身就很复杂，Pro才开始有意义

但另一种项目完全不同。

比如：

大型Repository；

多个服务；

多套技术栈；

大量历史兼容要求；

不同目录存在完全不同的开发规则；

每天都有大量跨模块任务。

这时候你即使已经把规则分层了，Agent仍然需要持续处理：

大量Repository Context；

复杂任务；

长时间执行；

多轮修改和验证。

也就是说：

问题已经不只是“AGENTS.md写得不好”。

而是：

项目本身就存在大量真实约束。

这种情况下，规则命中率可能天然比小项目低。

因为一次任务本身就可能同时涉及：

API；

Database；

Security；

Testing；

Compatibility。

如果这种高Context任务只是偶尔发生，没必要因此改变套餐。

但如果每天大量任务都是这种状态，那么你的使用方式已经从：

普通Coding辅助

变成：

持续处理复杂Repository。

这时候Pro更高的使用强度和更长、更复杂的Codex工作流才开始真正匹配。

---

最后：AGENTS.md真正重要的不是“写了多少”，而是“Agent什么时候知道该用哪条”

很多人优化Codex的第一阶段是：

给它更多Context。

但再往后一步，会发现真正重要的是：

给它更有效的Context。

AGENTS.md不是越长越专业。

规则也不是越多越安全。

真正好的项目规则应该让Codex快速判断：

现在是什么任务？

哪些规则和它有关？

哪几条绝对不能违反？

什么结果才算完成？

所以以后如果Codex又漏了一条AGENTS.md规则，先别急着再往文件里补一句。

先问自己：

这条规则是所有任务都需要，还是只有特定条件下才需要？

如果是后者，就应该让它拥有更明确的作用范围和触发条件。

最后判断Plus还是Pro，也可以回到同一个指标：

规则命中率。

项目简单、有效规则集中、Context容易控制：

Plus通常够用。

项目本身就有大量真实约束，而且高Context任务已经成为日常：

Pro才开始更符合这种工作强度。

所以真正成熟的AGENTS.md，不是一本越来越厚的“Codex说明书”。

而更像一套路由系统：

让正确的规则，在正确的任务里出现。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。