案例 01 · 提 PR 前先让它审一遍

什么场景

功能写完了，测试也过了，但你心里知道有几处是赶出来的。 提上去之前想先过一遍，又不想麻烦同事——这时候让 Codex 先审一次。

它审得比人快，也比人耐心；但它不知道你们团队的历史包袱， 所以它的结论要过你这一道。

在什么权限下跑

只读就够。 审查不改工作树——这是 /review 的设计： Codex 启动一个专用审查器，读所选的差异，报告按优先级排列的结果，不动你的工作树。

保险起见可以显式限死：

codex --sandbox read-only

怎么跑

先确认状态：

git status
git diff --stat        # 心里有数：这次动了多少

进 Codex 之后输入：

/review

会让你选范围：

• 对照基准分支审查——看这个分支相对 main 的全部改动，适合提 PR 前
• 审查未提交的更改——看你现在手上还没提交的东西，适合提交前

/review 只在 Git 仓库里出现

项目不是 Git 仓库的话这个命令不会显示。桌面应用的审查窗格也一样， 会直接提示你创建一个。

想审得更有针对性

/review 是通用预设。如果你知道风险在哪，直接说会更准：

审查当前分支相对 main 的改动，重点看三件事：
1. src/payment/ 下新加的重试逻辑会不会造成重复扣款
2. 有没有把错误吞掉只打日志的地方
3. 新加的两个依赖，许可证和体积

不要提格式和命名问题，那些 lint 会管。
每条结论给出文件和行号，并说清楚在什么输入下会出问题。

最后两句很关键：排除掉 CI 已经管的东西，让它把注意力放在机器查不出来的地方； 要求给出触发条件，能立刻筛掉一半的「理论上可能有问题」。

结果怎么读

审查发现会以内联评论的形式显示在审查窗格里，并按优先级排列。

审查窗格反映的是你 Git 仓库的状态，不只是 Codex 改的东西—— 里面包括它的改动、你自己的改动，以及仓库里任何其他未提交的改动。 默认显示未暂存的更改；已暂存看 Git 索引，提交看选中的提交， 分支看与基准分支的差异，上一轮看助手最近一轮改了什么。

在窗格里：点文件名一般会在你选的编辑器里打开； 点文件名所在的背景区域展开/折叠差异；Cmd + 点击某一行直接跳到那一行。

让它顺手改掉

觉得某条结论成立，可以直接让它改。但注意： 如果你让 Codex 应用它提出的修复，你原有的沙盒和审批设置仍然适用。 也就是说前面用 --sandbox read-only 的话，它改不了——得先放开权限。

我的做法是分两步：先只读审完，把结论过一遍， 挑出真要改的，再切到 workspace-write 让它改这几条。 一次审一次改分开，比让它边审边改可控得多。

几个用得上的设置

审查用不同的模型。 config.toml 里的 review_model 可以让审查用一个跟当前会话不一样的模型：

review_model = "gpt-5.6"

把审查开成独立聊天。 默认审查在当前聊天里跑，会占掉主线程的上下文。 桌面应用：设置 → 常规 → 代码审查 → 独立。 IDE 扩展：把 chatgpt.reviewDelivery 设成 detached。

长会话里这个开关值得打开——审查产生的输出量很大， 留在主线程里就是 快速上手 06 说的那种上下文污染。

处理 PR 上的评论

如果 Codex 有你仓库的 GitHub 访问权限，而且当前项目在 PR 分支上， 桌面应用可以在应用内处理 PR 反馈：侧边栏显示 PR 上下文和审查者的意见， 审查窗格把评论和差异并排显示。

前提是装了 GitHub CLI 并登录：

gh auth login

gh 没装或没通过身份验证的话，PR 详情就不会出现在侧边栏和审查窗格里。

完整流程：在 PR 分支上打开审查窗格 → 看 PR 上下文、评论、改动的文件 → 让 Codex 针对某条具体评论修 → 在窗格里检查生成的差异 → 暂存、提交、推送。

容易翻车的地方

把审查结果当结论。 它不知道那段看起来很怪的代码是三年前为了绕某个线上问题写的。 每条结论自己判断一次。

让它边审边改。 改了之后 diff 就变了，你分不清哪些是原本的问题、哪些是它新引入的。 审完再改。

范围给太大。 「审一下这个仓库」会得到一堆泛泛而谈。 限定到分支差异或某几个目录，结论质量差别很大。

相关官方文档

• 代码审查
• 在 GitHub 中使用 Codex
• 开发者设置（官方页面，本站未镜像）
• 安全审查