从 58% 到 98%：Codex Code Review 用一份 AGENTS.md 补上 AI 代码审查的最大短板 https://developers.openai.com/blog/custom-code-review-rules-for-codex
代码产量在暴涨，但审查能力没有同步增长
OpenAI 内部的周 PR 量自去年 Q4 以来翻了一倍以上，客户侧趋势类似。代码写得越快，code review 就越容易成为新的瓶颈。
更麻烦的是，有一类问题从 diff 本身根本看不出来。典型例子：把一个响应字段或事件名重命名，代码能编译、看起来是常规清理，但会悄悄破坏仍依赖旧契约的下游客户端。这类知识（"为什么这个字段不能动"）传统上只存在于少数资深 reviewer 的脑子里--而恰恰是新贡献者和 coding agent 最缺这种历史上下文。
核心机制：把 reviewer 的隐性知识写进 AGENTS.md
新能力允许团队在 AGENTS.md 里写下简短、有作用域的审查规则，Codex Code Review 会在审查时应用与改动文件相关的规则，并在 finding 中引用规则出处。这样解释不用在每个 PR 里重复一遍，而是常驻在它所约束的代码旁边。
OpenAI 给的真实案例很有代表性：Codex app-server 有一个标记为 experimental 的内部通知 rawResponseItem/completed，但 Codex Cloud 已经在消费它。仓库规则明确写了"即使是 experimental，rawResponseItem/* 也是需要保护的集成面"。假如有人把 wire name 从 completed 改成 done，编译通过、diff 看似无害，但下游会静默失联--规则让 Codex 能抓住这类改动，并给出安全替代方案（保留旧名，或增加向后兼容的新事件）。
值得注意的定位判断：规则是对测试和 linter 的补充，不是替代。能确定性表达的检查（格式、机械规范）留给 CI；规则用来承载难以编码的"判断类"知识--兼容性要求、数据边界（比如客户数据不能进日志）是最好的起点。
评测数据与四个维度
在包含已知规则违规和安全反例的评测集里，带规则的审查召回了 98% 的目标 finding，基线只有 58.3%。这个提升幅度说明：模型不缺发现问题的能力，缺的是"该看什么"的上下文。
但作者刻意强调"找到违规只是一半"，评测围绕四个维度组织，这个框架本身值得借鉴： · Coverage（覆盖）：diff 很杂、多条规则竞争注意力时，还能不能抓住目标违规 · Restraint（克制）：干净的改动和合理例外，会不会被误报制造噪音 · Retention（保持）：加了规则后，规则之外的普通 bug 还能不能照常发现 · Actionability（可操作性）：每个 finding 是否指明依据的规则、位置和优先级
其中 Restraint 和 Retention 是最容易被忽视的：内部实测发现宽泛的指令很容易制造噪音--规则会被套到每个"沾边"的改动上。
怎么写好规则（方法论精华）
- 从"有后果且不显眼"的不变量开始。选 reviewer 反复解释的那条检查。判断标准很干脆：如果删掉这条规则不会改变审查结果，就不要写。
- 作用域对齐代码。仓库级规则放根目录，服务级规则放对应目录的嵌套 AGENTS.md。窄作用域减少规则间的注意力竞争，也让归属清晰。