代码审查要回答“这个改动在什么条件下让用户得到错误结果”，而不是复述改了几行。本页操作本地仓库；GitHub PR 自动审查需要额外集成配置，不能从本地命令成功推导它已经启用。
先选唯一审查范围
先运行 git status --short 和 git diff --stat，知道当前有哪些未提交内容。在 Codex 交互界面输入 /review，按界面选择未提交修改、相对基础分支或某次提交。
终端路线可以选以下一条，不要一起执行当成同一次审查：
codex review --uncommitted
codex review --base main
前一条包括暂存、未暂存和未跟踪的改动；后一条要求本地存在正确的 main 基线，远端分支过期会影响比较。当前文档说明 --uncommitted、--base、--commit 和自定义提示目标互斥，不要机械拼在同一命令中。所装版本不接受参数时先看 codex review --help。
如果仓库已有很多无关改动，先明确本轮文件范围或使用独立分支/副本。不能为了“让审查干净”清掉别人尚未完成的工作。
用一个已知回归检查审查质量
以下是教学 diff。需求规定订单金额达到 200 元免运费，金额使用整数分：
export function shippingFee(totalCents) {
- return totalCents >= 20000 ? 0 : 1000;
+ return totalCents > 20000 ? 0 : 1000;
}
给 Codex 一并提供需求：“20000 分应免运费；19999 分收 1000 分；20001 分免运费”。要求只读审查，不立即改代码。
一个合格发现应包含：恰好 20000 分时，新条件返回 1000，用户会多付运费；位置是比较符所在行；应补 20000 的边界测试。这里判定成立有明确输入和结果，不需要猜用户流量或编造财务损失数字。
在 Node.js 20+ 的空目录中，保存以下 review-demo.test.mjs 可验证样本：
import test from 'node:test';
import assert from 'node:assert/strict';
function shippingFee(totalCents) {
return totalCents > 20000 ? 0 : 1000;
}
test('达到门槛免运费', () => {
assert.equal(shippingFee(20000), 0);
});
test('低于门槛收费', () => {
assert.equal(shippingFee(19999), 1000);
});
test('超过门槛免运费', () => {
assert.equal(shippingFee(20001), 0);
});
运行 node --test review-demo.test.mjs，教学预期是边界项失败、另外两项通过。修回 >= 后三项应通过。这个测试验证本例逻辑，不代表你的支付系统完整验证。
发现应怎样排序
优先列能造成数据损坏、越权、业务错误或明显回归的问题；严重程度还要看触发概率、影响范围和是否可恢复。变量名、空行等风格意见不要挤在真实缺陷之前。
交付格式可以这样约束：
对每个确认发现给出：文件行号、触发条件、旧/新结果、用户影响和验证证据。
不要把缺少信息自动判成 Bug；未能确认的假设单独列。
审查结束后列出没有运行的检查。不要自动修改或提交。
对照一个只改注释、不改条件的干净 diff，审查应允许“没有确认缺陷”。不能为了凑三条建议把正确代码说成错误。
审查结果与修复结果分开
Codex 没报告问题，不证明没有缺陷；它没执行测试，也不能写“测试通过”。先人工核对最高风险发现，确认后再授权修复对应范围，并运行相关业务测试。
如果只看到一个文件却怀疑权限或重试规则，应继续找调用方、中间件和已有契约。缺少当前文件中的检查，并不必然意味着整个请求链没有检查。审查的价值在于可靠发现，不能靠可能性数量衡量。
资料来源
- Codex 命令参考
2026-10-11 核对 review 目标参数互斥。
- Codex CLI
核对交互式 /review。
下一步
继续阅读与你当前问题相关的教程：
