Codex 代码审查：选择 diff，逐条验证发现的问题
使用 Codex 审查分支和未提交改动，发起 GitHub PR review，并在合并前把问题转成可复现检查。
最近更新: 2026-09-20
Codex review 需要明确的 diff，也需要验证发现的方法。2026 年 9 月 20 日，我们核对了官方 review 文档和本地 CLI help 中的命令。本文提供工作流，不提供缺陷检出率的实测结论。
先选清楚审查范围
官方代码审查指南 说明了 /review，以及相对 base branch、未提交改动、指定 commit 等范围。选择之前，检查是否混入了无关的本地修改。
本地 CLI 的 codex review --help 也提供以下非交互形式。执行前，先核对你的安装版本：
codex review --help
codex review --uncommitted
codex review --base main
后两条命令按场景选择，把 main 替换为真实目标分支。未提交范围包含 staged、unstaged 和 untracked 文件。Review 可能向配置的服务发送仓库上下文，请使用获准处理这些代码的项目和账号。
| 场景 | 选择范围 | 保留证据 |
|---|---|---|
| 工作尚未提交 | 未提交改动 | 当前 diff 和未跟踪文件列表 |
| 功能分支准备完成 | 真实目标分支 | Base 与 head 的 commit 标识 |
| 调查单次变更 | 指定 commit | Commit 标识和问题位置 |
审查进行时，避免同时编辑同一批文件。Head 变化后，记录新版本，重新审查受影响的改动。
给 reviewer 一个具体的失败条件
建议请求同时描述行为与后果：
审查所选 diff，暂时不要修改文件。
重点检查：一个已登录用户能否修改另一个用户的记录。
每条问题提供文件和行号、触发请求、预期行为、实际行为，
以及代码中的证据。
区分已确认缺陷和需要更多上下文的问题。
把示例边界换成项目真实的不变量。“找到所有 bug”缺少可观察的终点。聚焦的 review 更容易验收，代价是可能漏掉其他类型的问题；仍需保留更广的检查和人工审阅。
在 GitHub PR 中请求审查
官方 GitHub 集成指南 要求为仓库配置 Codex cloud，并能访问 review 设置。启用仓库审查后，可以在 PR 评论中发送：
@codex review
也可以在 Codex 设置中配置自动审查。核实 review 是否针对预期变更完成；发出评论不代表审查完成。具体可用性和账号设置，以链接中的官方指南为准。
把每条发现转成证据
打开引用的代码，沿着相关调用方检查。为报告的行为构造最小请求或测试。以上述 ownership 为例，需要两个不同用户，以及属于其中一人的记录。只让 owner 成功修改自己的记录，不能证明用户之间的隔离有效。
为每条发现记录一种处置：已复现、有证据证伪、上下文不足尚未解决。缺少信息时先补齐，不要因为评论语气肯定就直接改代码。
确认缺陷后，先添加能在旧行为上失败的检查，再修复并重跑。保留最初的触发场景，让最后的检查确实覆盖原问题。Benchmark 指南 可以帮助固定输入和初始状态。
把重复检查写到代码附近
对于 GitHub review，OpenAI 文档说明了适用 AGENTS.md 中的 Code Review Rules 章节。项目指令指南 提供了让规则可以验证的写法。
多用户应用的示例规则可以是：修改记录之前必须验证 ownership，已授权的管理员操作需要明确例外。这是编辑示例；采用之前，应对照项目真实的授权模型检查。
合并之前还欠哪些证据
零 findings 仍然留下几个问题：关键代码是否进入审查范围，测试是否执行，依赖服务是否可用？保存一份简短发布记录，包含被审查的 commit、问题处置、检查结果和剩余缺口。新的改动使证据失效时，再发起 review。