Codex PR Review 实战：自动化评审配置与触发规则

Codex 的 GitHub PR 评审效果比我预想的要好。在开 PR 之前，我已经用多种方式审查过代码了，在 Claude 和 Codex 里都审过。我让主 agent 审过，也附加过另一个模型作为 subagent 审阅者，分两个阶段跑过。通过了所有这些审查的代码，还是会被 Codex 抓住，总有一两处漏网之鱼。

这篇指南讲如何开启它。开启之后会发生什么则是更大的话题，我放在最后再说。

配置本身只需要三步。

为仓库配置 Codex 云。需要安装 GitHub App 并授予仓库访问权限，而且你需要 push 或 admin 权限才能修改仓库设置。

在 Codex 设置中，为仓库开启 Code review。

想让每个 PR 都自动审查而不需要手动触发，也请开启 Automatic reviews。如果不开启，Codex 只会在你调用它的时候出现。

自动审查也意味着评审会在你打开 PR 的那一刻就落下。如果你不想在草稿阶段收集评论，那就保持关闭，等分支准备好再调用 Codex。

你可以在 PR 评论中调用它。

@codex review: review this PR

@codex security review: look at it from a security angle

@codex review for issues in the database migration: narrow where it looks

@codex fix the P1 issue: have Codex apply the fix itself

要把评审标准固化到仓库里，可以在 AGENTS.md 里加一个 ## Code Review Rules 小节，拆成 ### 条目。仓库级别的规则放在根目录的 AGENTS.md；只适用于某个服务的规则放在离那部分代码最近的 AGENTS.md 里。

还有一件事值得知道：Codex 只把 P0 和 P1 问题发到 GitHub。小问题不会露出来，所以一旦露出来通常都是有分量的。这也正是它难缠的地方。每条评论看起来都对。

配置只需要五分钟。剩下的才是难的部分。

开启之后会发生什么

Codex 严格从代码出发评判，提交评论的一方和修复代码的一方都被设计成会持续运作直到完成为止。如果没人介入，评审轮次会自行叠加。一个安全功能相关的 PR 经历了 209 轮评审对话才最终合并。

经历这个循环之后，我总结出四条应对原则：看评论时从产品行为出发理解，权衡影响时要考虑对用户的影响，动手之前先理解修复与现有代码的关系，如果它不是合并阻塞项，就建一个 issue 或者忽略它。这四条原则从何而来、为什么每条都成立，都在 209 AI Code Reviews: Accurate Is Not Necessary 这篇文章里。如果这篇指南帮你把评审功能开起来了，那篇就是接下来该读的文章。