用 Codex 做代码审查：每个发现都要说明怎样触发 - AIPlan

让 Codex 审查代码时，只说“帮我看看这次改动”，通常换来一串风格建议。把要求改成“每个发现都写清触发输入、期望行为和实际行为”，输出才会落到能改的地方。截至 2026 年 10 月 18 日核对，这套做法在 Codex 桌面版的 /review、CLI 和 IDE 扩展里都成立。 先选对比较范围，审查才有边界 在桌面版里输入 /review，会看到两个起步选项：Review against a base branch 和 Review uncommitted changes。CLI 的 /review 会展开四个预设，除了这两个，还有 Review a commit 和 Custom review instructions。选错范围是最常见的返工来源，拿 base 分支比较，会把同事上周合进来的 3 个提交一起审掉。 /review 只在当前项目位于 Git 仓库内时出现。项目还没初始化仓库，应用会先提示创建一个。如果你的代码放在共享目录而不是仓库里，审查面板根本打不开，先把 git init 和第一个提交做掉再谈审查。 桌面版的审查面板默认显示 Unstaged。旁边的切换项依次是 Staged、Commit、Branch 和 Last turn。Last turn 只看上一轮助手的改动，适合“刚让它改完，想确认有没有多改文件”的场景。Branch 才是对比基线的差异，日常审查用这个。 面板显示的是整个仓库状态 有一句说明容易被跳过：审查面板反映的是 Git 仓库状态，不只是 Codex 编辑过的内容。你手改的、别的工具生成的、还没提交的改动都会进来。在一个躺着 20 个未提交文件的仓库里直接跑审查，产出会被无关噪声淹没。 处理方法很土但有效，跑之前先 git status 看一眼。有无关改动就先 stash 或者单独提交，再审。这一步花 10 秒，能省掉后面从 30 条发现里挑 3 条的力气。 多仓库项目还有额外开关。当一个本地项目挂了多个不同 Git 仓库的文件夹，审查头部会出现仓库选择器，可以逐个仓库看增删行。选 Last turn 时选择器显示 All repos，其他范围只作用于当前选中的那个仓库。 把发现格式写进审查指令 Review with Codex 右边有一个齿轮，叫 Review instructions；同样的文本也能在 Settings > Code Review 里改。这段指令会对你之后用 Review with Codex 发起的所有仓库审查生效，不用每次重写。 可以直接抄这段： 先给 3 行以内的摘要。优先报行为变化、数据丢失、缺失的边界测试。 每个发现写四行：触发输入、期望行为、实际行为、涉及的文件与行。 没有具体触发条件的，不要写进发现列表。 最后一句是关键。默认情况下很容易给出“建议为这个函数加错误处理”这类没有触发条件的条目，读完之后你不知道该不该改。加上“没有具体触发条件的不要写”，发现数量会从 15 条掉到 4 条，但每条都能落地。 指令的生效时机也有边界：审查进行中修改指令，改动要等下一次审查才应用。想针对某一次改动提问，用那个 PR 的 chat，别去动全局指令。 用内联评论把范围压到行 审查面板支持行级评论。把鼠标移到目标行，点出现的 +，写完提交，然后回聊天里发一句话把意图说清楚。官方文档给的例子是 Address the inline comments and keep the scope minimal. 为什么要补这一句？因为内联评论本身被当作审查建议，不是执行命令。只说“处理评论”，模型可能顺手重构半个文件。加上保持范围最小，改动会收在评论覆盖的那几行里。 面板的操作粒度值得用起来。整份差异有 Stage all 和 Revert all；单个文件、单个 hunk 也能分别暂存或还原。审完发现 100 行改动里只有 12 行可用，按 hunk 挑比全盘接受安全得多。 别在审查阶段顺手让它改 Codex 的审查默认只报发现，不动工作区。这是个好默认值。一旦你说“把这些都修了”，沙箱和审批设置重新接管，它有权按当前权限改文件、跑命令。 稳妥的做法是分两次：第一次只要发现列表，自己判断哪些是真问题；第二次单开一个对话，把确认过的 2 到 3 条贴进去让它改。中间这步人工判断省不掉，审查模型也会误判，它可能把你有意保留的兼容分支报成缺陷。 团队环境里的 PR 审查 代码审查插件能显示 PR 的描述、改动文件、评论和检查状态。GitHub 的代码审查已经正式可用，GitLab 的合并请求支持还在预览阶段。仓库侧可以用 @codex review 触发云端审查，前提是装了 ChatGPT Codex 连接器、仓库权限配好、自动审查开着。 一个必须记住的边界：在聊天里审查 PR 不会自动发评论、不会批准、也不会合并。把评论发到 Summary 或 Changes 里会立刻同步到源码托管方，不等 Submit review。真正的决定要单独走 Submit review，选 Comment、Approve 或 Request changes。 Mark as viewed 用来标记已读文件，标记只对当前显示的修订版本有效。改动一推，标记就作废了。依赖堆叠的 PR 会在 Summary 里出现 Stack，可以从一个 PR 跳到相关的另一个看差异和评论。 小改动不值得开这一套 改动低于 30 行、只涉及一个函数、自己能一眼看完的，直接读 diff 更快。审查流程的价值在跨文件、跨模块的改动上：调用方改了没跟着改、错误分支没测试、接口返回结构变了但消费端没动，这三类问题肉眼最不容易发现。 如果你每周有 3 次以上这种跨模块改动，Plus 的 $20（按 1 美元 ≈ 6.69 元折算约 ¥133.80）就够用，审查本身不额外扣费；ChatGPT Plus 月卡 ¥115.50 是同一档订阅，换的是结算方式。云端自动审查和更大额度才需要看 Pro，用量差异在 Codex 额度不够用时先看任务怎么消耗。 下次审查前，把上面那四行模板存进 Review instructions，拿一次 30 行以上的真实改动跑一遍，看发现列表能不能压到 5 条以内。压不下去，说明指令还是太松，继续加约束条件。 参考资料资料核对日期：2026-10-17 • Code review • Codex CLI 延伸阅读• 用 Codex 修 bug：先验证原因，再动实现 • 让 Codex 写测试：先问这条测试能发现什么错误 • Codex 操作项目时，权限、密钥和命令范围怎样管理？ • 用 Codex 重做前端，先列清楚页面和交易流程