用 Codex 做代码审查：本地 /review、GitHub 审查与 AGENTS.md 审查规则

最后核验：2026-10-23

先看结论

Codex 的“代码审查”不是一个功能，而是三条通道，按你手里的东西选：

还没提交的本地改动：在 Codex 里输入 /review，选范围（和基线分支比、未提交的改动等），Codex 只汇报按优先级排序的发现，不改你的工作区；
已经开了的 pull request，想自己看：用桌面端的 Code Review 插件，读摘要、看改动、追问，再决定要不要把发现发给作者；
希望 GitHub 上自动或按需有“第二双眼睛”：在 PR 评论里写 @codex review，或打开 Automatic review。Codex 会像同事一样发一条标准的 GitHub 审查，并且只标出 P0 和 P1 问题。

想让审查更贴合你的仓库，不用改提示词，而是把约定写进 AGENTS.md 的 ## Code Review Rules。官方的建议是从两三条“审查者总要重复解释”的规则开始。

内容整理自 OpenAI 官方文档与官方博客，核验日期 2026-10-23。具体界面名称以你使用的客户端为准。

通道一：本地改动，用 /review

适用场景：改完代码、提交前，想让 Codex 先过一遍。

不同客户端的入口基本一致，输入 /review 即可：

桌面应用：在输入框里键入 /review，选 Review against a base branch 或 Review uncommitted changes。审查窗格需要项目在 Git 仓库里，不是的话应用会提示创建；
命令行：输入 /review 打开审查预设，Codex 启动一个专门的审查者读取所选 diff；
IDE 扩展：同样在输入框键入 /review，选项与应用相同。只有当打开的项目在 Git 仓库里，/review 才会出现。

怎么选范围

命令行的 /review 有四个范围：

Review against a base branch：找到合并基点，审查你的分支相对基线的 diff；
Review uncommitted changes：包含已暂存、未暂存和未跟踪的文件；
Review a commit：审查所选提交的确切改动；
Custom review instructions：按你提供的标准聚焦审查。

IDE 扩展只有前两项：与你选的分支比较，或审查工作区改动。

桌面应用的审查窗格默认显示 Unstaged，可以切到 Staged（Git 索引）、Commit（某次提交）、Branch（相对基线分支）或 Last turn（最近一轮助手的改动）。注意窗格反映的是整个 Git 仓库的状态，不只是 Codex 改过的部分：你自己改的、其他未提交的改动也在里面。

结果在哪里看

桌面应用里，发现以内联评论的形式出现在审查窗格。默认在当前对话里运行；在 Settings > General > Code review 里选 Detached，可以改为开一个单独的审查对话；
IDE 扩展里默认也在当前对话运行，把设置 chatgpt.reviewDelivery 设为 detached 就会另开审查对话；
命令行里，审查作为一个回合出现在对话记录里。想让审查用和当前会话不同的模型，在 config.toml 里设置 review_model。

如果你让 Codex 把发现的问题直接修掉，正常的沙箱与审批设置依然生效。

用内联评论把反馈说准

桌面应用的审查窗格支持在具体的行上留言，这通常是引导 Codex 改对的最快办法：

打开审查窗格；
鼠标移到要评论的行；
点出现的 + 按钮；
写下反馈并提交；
全部写完后，回到对话里发一条消息。

官方特别强调：Codex 把内联评论当作审查指引，所以留完评论后要再发一条明确意图的消息，例如：

Address the inline comments and keep the scope minimal.

在窗格里你还可以按整个 diff、单个文件或单个 hunk 暂存或还原，满意的先暂存，不要的还原。

通道二：pull request，用 Code Review 插件看

适用场景：PR 已经开了，你要先弄懂它改了什么，再决定怎么回复。

桌面应用内置 Code Review 插件，可以固定在侧边栏。基本流程：

打开侧边栏的 Code Review，按提示连接你的代码托管账号（用有目标仓库权限的账号）；
从侧边栏选 PR，或在搜索框里粘贴它的链接；
Summary 里读描述、活动、评论和检查结果；Changes 里看改动文件和评论。

官方的使用原则很实在：先描述期望的行为，再让 Codex 解释和排查，并要求给出证据。 官方示例是一个给问题看板加 Open 和 Closed 过滤器的 PR，期望 All 仍然是默认值，没有匹配项时显示空状态：

Walk me through this pull request. Focus on the default filter and what
happens when there are no matching issues. All should remain the default.

接着要证据：

Show me the code path and tests for the no-matches case. Explain what is
covered and what still needs verification.

然后对照 diff 和测试检查 Codex 引用的内容，而不是直接采信它的结论。

全局的审查偏好

点 Review with Codex 旁边的 Review instructions 齿轮，或在 Settings > Code Review 里，可以写一份适用于你所有审查的标准和汇报格式，官方示例：

Start with a short summary. Prioritize behavior changes, data loss, and
missing edge-case tests. For each finding, explain the triggering input,
expected behavior, and actual behavior. Use our team's concise review style.

这份指令适用于你通过 Review with Codex 发起的审查，跨仓库生效。某一个 PR 的具体问题，用该 PR 的对话来问。

反馈给作者之前

在对话里审查 PR，不会自动发评论、批准或合并，哪些发现要分享由你决定；
想把已验证的疑点变成评论，让 Codex 起草，并要求“只保留为草稿”，发之前先核对其中的文件和行号引用；
在 Summary 或 Changes 里直接发评论，会立刻发给代码托管方，不会等 Submit review；
Submit review 才能选 Comment、Approve 或 Request changes 并提交，提交前再核对一次你选的决定和评论；
如果你是作者，回到自己的 PR，让 Codex 处理具体反馈，然后检查改动并跑相关测试；批准或合并之前，再看一遍最新版本、检查结果和未处理的反馈。

另外，CI 失败时可以在 Checks 里点 Fix，把失败的检查附到对话里；它只准备消息、不会直接发送，你检查或补充提示词后再发。官方提醒：可用的诊断信息取决于检查的提供方，第三方 CI 只能用它汇报给 GitHub 的状态和输出。

通道三：GitHub 上的 @codex review

适用场景：希望每个 PR 都有一遍“高信号”的审查，或者随时点名要一次。

启用

开始前需要：一个已连接 Codex 的 GitHub 仓库，能打开 Codex 代码审查设置，以及（如果希望 Codex 遵守仓库约定的审查规则）一份 AGENTS.md。配置自动审查还需要该仓库的 GitHub push 或 admin 权限：

把 GitHub 仓库连接到 Codex；
打开 Codex 的代码审查设置；
选择仓库，在 Review code 下打开 Automatic review。

手动请求

在 PR 评论里写：

@codex review

等 Codex 用 👀 作出反应，再发出审查。一次性的侧重点可以直接写进评论：

@codex review for issues in the database migration

GitHub 上只会标出 P0 和 P1 问题，目的是让审查评论聚焦在高优先级风险上。

自动审查

在 Codex 设置的 Personal preferences 里打开 Automatic review，再用 Review trigger 选择什么时候运行。它对已开启代码审查的仓库生效，不需要每次写 @codex review 评论。官方还说明：自动审查的评论会同时出现在 GitHub 和桌面端的 Code Review 里；这类云端审查与你在 PR 对话里发起的审查是分开的。

审查之后：让它修

审查发出后，可以在同一个 PR 里继续评论：

@codex fix the P1 issue

Codex 会以该 PR 为上下文启动云端对话，在有权限时可以把修复推回分支。对 @codex 提到任何不是 review 的内容，也会这样启动，比如 @codex fix the CI failures。

官方另有一个处于研究预览的 Security Review，用于更深入的安全审查，手动触发用 @codex security review。需要时参见官方的 Security Review 说明，这里不展开。

Codex 没反应时

官方的排查顺序：

确认已在 Codex 设置里为这个仓库打开代码审查；
确认 PR 所在仓库已经连接到 Codex；
触发词要写对，就是 @codex review；
自动审查没触发时，同时检查仓库设置里的 Automatic review 和 Personal preferences，并确认 PR 事件与你的触发设置匹配。

让审查贴合你的仓库：Code Review Rules

Codex 会在仓库里找 AGENTS.md，并遵循其中适用的代码审查规则。做法是：在离被约束代码最近的那个 AGENTS.md 里加一个 ## Code Review Rules 章节，需要分组时用 ### 小标题。官方示例：实验报表服务要避免用“曝光后行为”去筛选对照组：

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

仓库级规则放根目录的 AGENTS.md，服务级规则放嵌套文件，比如 services/experiment_reporting/AGENTS.md。Codex 会为每个被改的文件应用根目录和覆盖它的更具体的规则，所以无关的改动不必带上某个服务的上下文。

官方总结的写法原则

聚焦有后果、与仓库相关的行为：写明要标出的兼容性约束、数据边界或不安全的副作用，以及为什么重要；
写出安全路径或例外：给足上下文，让 Codex 能区分真问题和正常行为；
范围小而持久：描述结果而不是容易变的函数名，把规则放在它约束的代码附近；
机械检查留给 CI：格式化、lint 等确定性检查不要写进审查规则；
官方博客补充：删掉这条规则不会改变审查结果的话，就别写。

官方博客给的真实例子很能说明问题：Codex 的 app-server 有一个标为实验性的内部通知 rawResponseItem/completed，但 Codex Cloud 已经在使用。仓库的审查规则把 rawResponseItem/* 明确列为要保留的集成面。如果某次“清理”把它改成 rawResponseItem/done，代码能编译，但监听旧通知的客户端会收不到事件，这正是 diff 里看不出来、有规则才能拦住的那类问题。

OpenAI 在官方博客里还给出了自己评测的数字：在他们的主评测集里，带规则的变体找回了所需自定义发现的 98%，对照组基线是 58.3%。这是 OpenAI 自己的评测结果，你仓库的效果需要自己验证，下一节给出验证办法。

用三个 PR 验证规则有没有用

官方建议：先加两三条规则，然后开一个有代表性的 PR，用 @codex review 请求审查，再根据发现和反馈调整，对产生噪音的规则收窄或删除。官方博客给的测试方法是各试一次：

一个应该触发这条规则的改动；
一个安全的反例（符合规则的例外）；
一个无关的改动。

确认第一个产生有用的发现，另外两个没有制造噪音，再继续打磨。

官方也强调：审查规则只是引导 Codex，不替代测试、分支保护和必需的审批。

常见坑

以下几条来自官方文档里的提醒，编者按使用场景做了归纳：

把审查当作批准：对话里的审查不会发评论、批准或合并，Codex 的发现也可能出错，要对照 diff、预期行为和测试再决定；
在 GitHub 上期待它报所有问题：GitHub 评论只标 P0 和 P1，小问题请靠 lint、测试和人工审查；
留了内联评论却没发消息：评论只是指引，要再发一条消息说明意图；
直接发评论以为会等 Submit review：在 Summary 或 Changes 里发的评论会立刻送出；
规则写太多太宽：宽泛的规则容易制造噪音，从两三条有后果、有安全路径的规则开始；
把格式、命名风格写进审查规则：这类确定性检查更适合放进 CI。

自查清单

要审的是本地未提交的改动，还是已经开了的 PR？选对通道。
本地审查用的是哪个范围？是否包含了你想审的内容（比如未跟踪的文件）？
对话里的审查发现，有没有对照 diff 和测试确认过再采纳？
GitHub 上有没有为这个仓库打开代码审查？@codex review 的触发词有没有写对？
AGENTS.md 的审查规则是否限定在两三条、写明安全路径？
有没有用“应触发、安全反例、无关改动”三个 PR 验证过？
格式化和 lint 这类机械检查，是不是留在了 CI？

下一步读什么

AGENTS.md 怎么写才有用：审查规则就写在这份文件里，先把整体写法打好
codex exec 入门：把 Codex 接进脚本与 CI：用官方 GitHub Action 在流水线里做 PR 审查，是另一条自定义程度更高的路线
用 git worktree 并行跑多个 Codex 任务：多个任务并行产出改动后，审查窗格里怎么看

官方来源

Code review：本地 /review、审查窗格、Code Review 插件与反馈流程
Use Codex in GitHub：@codex review、自动审查、## Code Review Rules、排查
Custom Code Review rules for Codex：审查规则的写法与评测说明（OpenAI 官方博客）
Codex 代码审查设置：启用仓库与自动审查的入口

核验日期：2026-10-23。