这篇讲什么
PR 被人评审打回，多数情况栽在同三件事上：缺测试、违反约定、顺手带的副作用。Codex 抓这三类问题大约只需要你去倒咖啡的时间——前提是你给它的是”团队真实约定”，不是”互联网通用最佳实践”。这篇给你那份 brief 模板、能产出可执行 finding（不是吐槽情绪）的 review prompt、以及让 Codex 当”不知疲倦的预审员”而不是橡皮图章的人机交接模式。
这篇适合谁看
PR 协作的团队、没有 reviewer 的单干者、收到一堆”能编译但感觉不对”PR 的 tech lead。约定漂移但没人有空写下来的快速演进代码库尤其受益。
什么时候适合用
任何要交人类审的 PR 之前。先跑 Codex，剩余问题给人。极小 PR（20 行以内）跳过，开销大于价值；生产 hotfix 也跳过，速度优先。
开始前准备
- 写 / 更新
AGENTS.md或CONTRIBUTING.md，列团队真实约定：命名、错误处理、测试规则、“绝不这么写”模式。不写 Codex 默认套互联网平均建议。 - 仓库 CI 在 base 分支上是绿的。脏基线会污染 Codex 噪声。
- 想清”必修” vs “建议” vs “可有可无”。Codex 不会给权重，你给。
具体步骤
- 在 Codex 里打开 PR 或分支。给一条带显式分类的 review prompt：
对照 AGENTS.md 的约定评审这个 diff。
按三类报告：
1. 必修 — bug、安全问题、违反约定、缺关键测试。
2. 重要 — 性能回退、漏边界情况、风格不一致。
3. 建议 — 可读性、命名、文档缺口。
每条 finding 都标"文件 + 行号"。指不到具体位置的不要列。- 让 Codex 审。输出应是带引用的分类列表。给你一大段散文就是 prompt 太空——按分类重提一次。
- 自己 triage findings。和你的品味 / 上下文冲突的就反驳。Codex 有时是错的，分类让分歧显式。
- 接受的”必修”在交给人审前修掉。“重要”修或标注。“建议”批量留给后续。
- 需要补测试时让 Codex 提：“
auth.ts这个改动，提 3 个单测：无效 token、过期 token、缺 claims。” 合理的就实现。 - 提交给人 reviewer 时附一句：“Codex 已预审；遗留事项在 PR 评论里。“省时间也让对方知道你读过。
第一次实操怎么跑
- 找一个刚合的 PR，用上面的 prompt 让 Codex 审一遍。
- 对比它的 findings 和当时人审说的。重合处告诉你 Codex 稳定能抓什么。
- 两边的漏标下来。Codex 漏微妙业务逻辑 bug，人漏枯燥的约定漂移。两个组合才赢。
- 下一个真实 PR 先跑 Codex，调整你对每类 finding 的信任度。
完成后检查
- 每条 finding 都标了文件和行号？“对错误处理的关注”没引用不算 finding。
- 必修真的是必修？是品味或风格的要降级。
- Codex 漏了明显问题吗？漏了就是约定文档缺这条，加进去。
- 人 reviewer 时间真省了吗？还要花 1 小时就是 prompt 或约定文档要改。
怎么复用这套流程
- review prompt 存成片段，每个 PR 同一条。
AGENTS.md当文档维护：reviewer 任何时候说”我们不这么干”，就加规则。- 跟踪你最常忽略哪类 findings——那是”品味不是约定”，从 prompt 里删掉。
- 季度跑一次刚合的 PR，验证 Codex 还在抓你想要的。
建议的操作流程
diff 就绪 → 带分类 prompt 的 Codex review → triage → 修必修、标重要、批量建议 → 带 Codex 笔记交人 reviewer。
容易踩的坑
- 把 Codex 审当终审。它会漏只有”带上下文的人”才能抓的业务逻辑 bug。
- 完全跳过人审。Codex 是预审，不是决策者。
- 没约定文档。没有 Codex 套通用建议，可能和你团队的选择冲突。
- 让 Codex 自己提 + 自己合修复，不经人审。findings 可以，自动合不行。
- 不分类。40 条扁平 finding 会瘫痪人 reviewer。
- 永远忽略”建议”项。季度批量做一次清理 PR，否则变成技术债。
FAQ
- Codex 审一次多久？: 典型 PR 2-10 分钟，看 diff 大小和测试数。
- 能审 draft PR 吗？: 能，而且通常应该。早反馈比晚反馈便宜。
- 能取代 lint 和 type check 吗？: 不能。lint 和类型抓语法层问题，Codex 抓约定和逻辑。两个都跑。
- 安全审查呢？: Codex 能抓常见安全模式，但敏感代码路径不能替代专门的安全 review。