Codex 本地 /review 怎么用？审查未提交改动、分支与提交的完整流程

先说结论：/review 是提交前的独立第二遍检查

Codex 的 /review 可以审查相对基准分支的改动、当前未提交改动、指定提交，或按自定义关注点检查代码。官方说明中，Codex 会启动专门的审查流程，读取选定 diff 并给出按优先级排列的问题，而不会为了完成审查去修改当前工作树。

它最适合放在“功能已写完、测试已跑过、准备提交或开 PR”这个节点。先让实现任务结束，再单独启动审查，可以减少同一个上下文只验证自己结论的偏差。审查结果仍需要开发者复核，不能替代测试、CI、人工批准或安全审计。

一、运行 /review 前先确认 Git 状态

/review 只会在打开的项目位于 Git 仓库时出现。开始前先确认仓库、当前分支、基准分支和最新提交是否正确，再查看 git status，避免把临时文件、无关格式化或其他人的未提交改动一起纳入审查。

官方说明指出，未提交范围会包括已暂存、未暂存和未跟踪文件。因此“只改了三个文件”的主观判断可能不准确。对大型仓库，先清理无关生成物、确认依赖锁文件变化，再运行审查，更容易获得可执行的结果。

二、怎样选择四种审查范围

审查基准分支适合模拟 Pull Request，Codex 会根据所选基准比较当前分支；审查未提交改动适合提交前检查工作树；审查单个提交适合复查已经形成的原子变更；自定义审查则适合明确要求关注认证、并发、数据库迁移、兼容性或性能。

范围越准确，审查噪音越低。不要在一个包含多种目的的大 diff 里只说“看看有没有问题”。可以写成：审查未提交改动，重点检查权限边界、失败回滚、空值处理和日志中是否泄露敏感信息，并忽略纯格式变化。

三、在 Codex 中审查未提交改动的步骤

第一步，在目标 Git 仓库中打开 Codex；第二步，运行测试、lint、类型检查或项目规定的验证命令；第三步，在编辑器输入 /review；第四步，选择“审查未提交的更改”；第五步，补充业务背景和重点风险，等待 Codex 返回分级发现。

收到结果后，不要一次接受所有建议。逐条核对文件、行号、触发条件和影响，先处理高严重度且证据明确的问题。若建议与业务约束冲突，应补充约束后重新评估，而不是为了清空列表机械修改。

四、怎样把审查标准写进仓库

通用要求可以写进项目的 AGENTS.md，例如必须运行哪些测试、禁止修改哪些目录、兼容哪些运行环境。团队还可以维护 code_review.md，并从 AGENTS.md 引用，让 Codex 在不同开发者和不同任务中使用一致的审查标准。

规则应优先覆盖自动化工具难以判断但出错成本高的问题，例如租户隔离、权限提升、审计日志、数据不变量和向后兼容。格式化、lint、类型错误等确定性问题继续交给 CI，不要用大量机械规则淹没真正的重要发现。

五、修复后为什么还要再跑一次

修复一个问题可能引入新的分支、遗漏测试或改变错误处理。完成修改后，应重新运行相关测试，再次执行 /review，确认原问题已经消失且没有新增高优先级发现。对数据库、权限或网络边界改动，最好再做一次更窄的专项审查。

审查完成并不代表代码一定正确。提交前仍需检查最终 diff、确认没有密钥和临时日志、验证文档与迁移脚本，并让合适的负责人批准。高风险变更应结合安全工具、威胁建模和人工安全评估。

六、常见误区与改进方法

误区一是把 /review 当成自动修复命令；它主要报告发现，不应默认改工作树。误区二是审查范围不清，导致把整个仓库历史问题混入当前任务。误区三是只看是否“通过”，却没有验证每条发现的真实触发路径。

更稳妥的做法是小批量提交、在提示中描述预期行为、保留可复现步骤，并让测试与审查互相补充。站内更多 Codex 工作流可访问 https://gptupcn.com/codex/ ，但命令和界面应以当前 Codex 官方文档与客户端显示为准。

七、一个可复用的提交前审查模板

可以在运行 /review 前补充一段固定上下文：这次改动解决什么问题、预期不改变什么行为、关键入口和失败路径在哪里、已经运行哪些测试。随后要求优先报告会导致数据错误、权限绕过、崩溃或兼容性回退的问题，并为每条发现说明触发条件和受影响文件。

例如：审查当前未提交改动。目标是为订单查询增加超时重试，但不得重复扣款或改变已有错误码。重点检查幂等性、并发请求、日志中的敏感数据、超时后的资源释放和测试覆盖；纯格式差异不需要报告。这样的提示比一句“检查代码”更容易得到与业务相关的结果。

若审查的是分支，应先确认本地已获取最新基准分支，再选择正确的 base。若审查单个提交，应确认该提交没有依赖尚未包含的前置改动。多仓库项目还要检查当前审查面板对应哪个仓库，避免只看到了前端 diff，却遗漏服务端或共享库的配套变化。

把最终结论记录在 Pull Request 或提交说明中：哪些发现已经修复、哪些属于已知风险、哪些由测试或监控覆盖。这样后续维护者能理解为什么接受当前实现，也能在相似变更出现时复用审查重点，而不是每次从零开始。

最后再做一次人工快速巡检：从用户入口走完主流程，检查错误提示是否可理解，确认新增配置有默认值，核对部署环境中的依赖与数据库迁移顺序，并查看监控是否能够捕获预期失败。对于网络请求、支付、权限和文件写入等高风险路径，至少准备一个失败用例和一个回滚方案。这样可以把静态 diff 中看不出的运行时问题纳入发布判断。

结语

高质量代码审查的关键不是多出一份报告，而是范围清楚、标准明确、发现可复核。把 /review 固定在提交前和修复后两个节点，再配合测试与团队规则，Codex 才能真正成为可靠的第二双眼睛。