让 Codex 参与代码审查：规则、流程与验收清单

先定责任：模型给意见，人做决定

把 Codex 当审查助手，而不是审批人。它可以指出可疑点、补充测试、解释改动影响，但“这个改动能不能上线”必须由人判断。一旦把合并权限交给模型，出问题的成本远高于省下的时间。

• 模型负责：逐行读 diff、找漏改、提测试缺口、检查错误处理与日志
• 人负责：需求是否正确、架构取舍、是否影响线上数据、是否合规
• 流程负责：小步提交、可回滚、CI 必须绿、关键路径双人复核

用 AGENTS.md 的 Code Review Rules 立规矩

Codex 每次运行都会读取指令链，其中项目级的 AGENTS.md 最适合放审查规则。官方推荐的做法是：把 ## Code Review Rules 写进管辖这段代码最近的 AGENTS.md——仓库级规则放根目录，服务级规则放嵌套目录。

## Code Review Rules

### 数据与统计

- 不要用“曝光后的行为”过滤实验组，包括转化和留存。
  安全路径：用分流或曝光时刻构建队列，把转化当作结果指标上报。

### 接口变更

- 修改公开 API 的响应字段时必须同步更新 `docs/api.md` 与类型定义。
  安全路径：新增字段而非改名，旧字段标记弃用后再移除。

规则要短、要具体：说清“要拦截的行为”和“安全的替代路径”，一条规则只讲一件事。格式、lint、类型检查这类能自动化的东西交给 CI，不要写进提示词浪费上下文。

让 Codex 读 diff 的提问模板

审查质量取决于你给的上下文。不要只说“看看这段代码有没有问题”，要说明关注点、约束和输出格式。下面这个模板可以直接改着用。

你是这次改动的 reviewer。只读，不要改文件。

背景：<这个改动要解决什么问题>
范围：只看 git diff 里改动的文件，不要扩展到无关模块
约束：<兼容性要求、性能预算、不能动的东西>

请按下面顺序输出：
1. 改动意图是否和背景一致（不一致就指出来）
2. 逐文件列出：漏改、边界条件、错误处理、日志与可观测性
3. 测试缺口：列出应该补但没补的用例
4. 风险等级：低/中/高，并给出一句话理由

不要给“整体不错”这类空话；没发现问题就说没发现。

拿到意见后，先自己判断哪些成立，再让 Codex 针对成立的那几条补测试或改代码。一次只处理一类问题，改完看 diff，避免它顺手重构了不相关的地方。

人工验收：测试、边界与回滚

1. 01

   先跑测试，再看代码

   CI 或本地测试是第一道闸门。模型说“没问题”但测试挂了，以测试为准。

2. 02

   对照 diff 看范围

   确认改动只落在声明的文件里。多出来的改动要么让它回退，要么单独提一个提交。

3. 03

   检查边界和错误路径

   空值、超时、重试、并发、权限，这些是模型最容易漏的地方，逐项确认。

4. 04

   确认可回滚

   改动是否附带迁移脚本、是否需要开关。不能回滚的改动不要和功能改动混在一个提交里。

git diff --stat
git diff
npm test
npm run lint

哪些判断不要交给模型

• 业务正确性：优惠券能不能叠加、退款规则怎么算，这些要产品和安全边界来定。
• 架构取舍：要不要拆服务、要不要引入新依赖，涉及长期成本，模型只能给参考。
• 安全与合规：密钥处理、个人信息范围、数据出境，必须以团队规范和法务意见为准。
• 线上影响评估：这次改动会不会打满数据库、会不会触发限流，需要真实的监控数据。
• 性能结论：模型可以指出可疑点，但“快了多少”必须靠压测和 profiling。

检查清单

• AGENTS.md 里有 ## Code Review Rules，且规则具体到行为和替代路径
• 审查提示词写明了背景、范围、约束和输出格式
• 先只读审查，再决定是否让它改代码
• 测试通过、diff 范围可控、改动可回滚
• 涉及业务规则、安全、架构的结论由人拍板
• 审查记录（意见和结论）留在 PR 里，方便回溯

做到这几条，Codex 能稳定帮你省下“第一遍通读 diff”的时间，而不会把风险带进主干。