适用人群：经常做 Pull Request 审查、维护多模块代码库，或总在评审中重复提醒“这个字段不能改”“这类数据不能记日志”的团队。
核心结论：好的 Codex 审查规则不是把编码规范全部复制进 AGENTS.md，而是记录“仅看 diff 很难推出、但违反后代价很大”的不变量，同时告诉审查者什么是安全改法。
为什么普通提示不够
一次代码修改可能编译通过、测试全绿，却仍然破坏旧客户端依赖的 JSON 字段，或把不该暴露的业务数据写入日志。这些知识往往只在老成员记忆里，新同事和编程智能体都不会凭空知道。
OpenAI 官方建议把这类简洁、有作用域的审查指南写进 AGENTS.md。Codex Code Review 能将适用于当前改动的规则用于审查，并在问题中指向相关指南。规则因此不再是“希望每个人都读过”的文档，而是审查上下文的一部分。
先挑对规则，再考虑怎么写
最适合写入的内容通常有三类：
- 兼容性不变量。 例如对外响应字段、事件名、数据库枚举值不能直接改名；必须保留旧值，或经过明确的双写与迁移期。
- 数据与安全边界。 例如请求日志不得输出密钥、会话标识或客户原文；如需排障，仅记录可枚举状态和脱敏关联 ID。
- 跨模块业务约束。 例如一个状态变更必须同时更新审计记录，或某个公共模块改动必须运行下游契约测试。
格式化、命名和可机械判定的规则应继续交给 linter、类型检查和 CI。如果一条指令删掉也不会改变审查结果，就不必占用规则上下文。
用“不变量 + 风险 + 安全路径”写每条规则
下面是一个泛化示例：
```markdown
Code Review Rules
Public API compatibility
- Treat published response fields and event names as compatibility surfaces.
- Do not rename or remove them in place; preserve the old form or add a
backward-compatible migration path and contract tests.
Sensitive logging
- Do not log credentials, session identifiers, or customer payloads.
- For diagnostics, log an allowlisted status code and a redacted correlation ID.
```
这个写法比“注意兼容性”更有用，因为它同时回答了三个问题：哪些对象受保护，什么改动会出错，作者如何修正。尽量描述结果和边界，不要绑定随时可能改名的内部函数。
按目录分层，避免全局噪声
仓库根目录的 AGENTS.md 只放全局不变量，例如禁止泄露敏感数据、公共 API 需要向后兼容。只对某个服务有效的规则，放到对应目录的 AGENTS.md。这样修改前端时不会被后端协议细节干扰，审查者也更容易找到规则的所有者。
不要一次迁移几十页规范。先选两三条团队近期重复说明过的高代价问题，用一个典型 PR 验证。如果干净改动频繁被误报，就缩小作用域、补充例外或删掉噪声规则。
一次可回滚的落地演练
- 从过去一个月的审查评论中，挑出两条重复出现且非显而易见的问题。
- 按上述结构写入适用目录的
AGENTS.md，在单独分支提交，不同时修改业务代码。 - 在 Git 项目中输入
/review，选择基准分支、未提交改动或指定 commit。官方文档说明，这个审查会返回按优先级排列的可执行问题，不会自动修改工作树。 - 用一个“应报告”和一个“不应报告”的改动验证覆盖率与克制度，记录误报原因。
- 如果规则产生噪声，回滚该文档提交，或改成更窄的目录规则；不需要改动产品代码。
审查结果仍需要人来验收
规则可以把团队经验带入审查，但不等于正确性证明。对每个发现，至少核对它是否指向具体改动、是否说清影响、是否给出安全路径。修复后还要运行契约测试、静态检查或最小回归；不要用“Codex 没报错”代替工程验收。
最后，把 AGENTS.md 当成代码审查产品来维护：有所有者、有反例、有定期清理。这样它才是可执行的团队记忆，而不是又一份逐渐过时的长文档。