Codex怎么审查本地代码？review范围、Git差异与误报核对

让AI“检查代码有没有问题”时，如果没有说清范围，可能只看了最近一轮改动，漏掉已暂存的部分。Codex本地review可以基于Git差异输出问题。本教程用一个新增筛选功能的练习仓库，说明如何确定审查对象、验证发现，再决定修复，适合提交前做一次有边界的自查。

第一步：打开正确的Git项目

官方说明本地审查面板要求项目位于Git仓库，/review也只在Git项目中出现。先确认当前文件夹和分支，再查看工作区是否包含自己的未提交修改。非Git资料文件可通过上传或已安装来源插件提供给ChatGPT Work，但不能因此认为已经获得完整仓库历史。

本地review与Code Review插件中的PR审查分工不同：前者读当前检出的Git变化，后者展示远端PR的描述、文件、评论和检查。本教程不需要先建立PR，也不要求开通自动云审查。练习前保存文件，避免编辑器中未保存的内容与磁盘差异不一致。

第二步：选对审查范围

在Codex输入框键入/review，按目标选择Review against a base branch或Review uncommitted changes。前者针对与基准分支的差异，后者看工作区未提交变化。开始前写明基准分支和预期行为，别把自己记忆中的main默认当成仓库真实存在的基准。

面板默认显示Unstaged，可切换Staged、Commit、Branch或Last turn。Last turn只对应最近助手一轮，不能代替整个分支；Staged只代表索引。多仓库项目还要检查顶部仓库选择器，保证正在查看目标仓库，而不是名字类似的另一个目录。

第三步：把业务预期写成可复现条件

请只审查本次筛选功能的Git差异，不修改文件。预期：默认仍显示全部记录；切到已关闭只显示关闭项；零条匹配时显示空状态。重点找可复现的行为错误。每条发现写触发输入、预期、实际代码路径、文件位置和需要补充的验证。无法证实的担忧单列为待核实。

Codex会报告优先排序的发现，而本地review本身不会修改工作区。不要为了得到更多结论无限扩展范围。先让它指出具体分支条件和调用路径，再查看关联测试；如果模型只说“可能为空”，继续要求说明哪个输入实际会传入空值。

第四步：逐条核对证据和测试

点击发现查看对应差异，确认文件与行位置仍属于当前版本。用一组有记录和一组零记录的练习数据观察结果，并检查已有测试是否覆盖这些条件。若代码已经在上游调用处处理了空值，就把这条发现重新评估，不应把所有AI输出直接转成修复任务。

对第二条发现做反证检查：沿调用链确认输入能否到达该分支，列出现有保护条件和相关测试。如果不能复现，请撤回该判断；如果可以，给出最小复现步骤。保持只读，不提交、不推送，也不改测试来迎合结论。

第五步：修复后重新核对最终差异

确认问题后再明确要求修改相应文件，运行能覆盖触发条件的测试，回看最终Git差异是否出现无关变化。审查面板显示整个仓库状态，可能同时包含用户和其他工具修改，所以不要批量回退不认识的文件。先辨认归属，再处理具体行。

若转到PR协作，聊天里完成审查不会自动批准或合并；在Summary或Changes发布评论却会立即发送到来源平台。先保留草稿并核对位置。完成标准是范围清楚、发现可复现、修复有验证，且没有把“没有发现”当成对所有代码的完整保证。

官方资料

资料核对日期：2026年10月30日。

• OpenAI：Code Review与本地Git审查