程序员小枫同学

Appearance

用 Codex 做 Code Review、Git 暂存和 PR 闭环 ​

嘿，朋友们！小枫今天聊聊怎么用 Codex 做代码审查这档子事。

我刚开始用 AI 审代码的时候踩过一个坑：把整个文件丢给 Codex，让它「帮我看看有什么问题」，结果返回一堆「变量名可以更语义化」「建议拆成小函数」——听起来头头是道，实际上一个真正的 bug 都没抓到。后来我才明白，让 AI 总结你改了什么根本没意义——代码审查真正的价值在于让它盯住那些会在特定条件下触发错误、安全漏洞、数据损坏或者兼容性回归的差异。而这个事情能做成啥样，第一关就是 diff 范围对不对。

第一步：把审查范围搞对 ​

别一上来就审，先看一眼仓库到底处于什么状态：

bash
git status --short --branch
git diff --stat
git diff --cached --stat

这几条命令花不了十秒钟，但能帮你避免一个经典翻车——审了半天发现审的是别人 branch 的代码，或者漏掉了 staged 的那部分改动。

常用的 CLI 范围长这样：

bash
# 审查未提交修改，包括 staged、unstaged 和 untracked
codex review --uncommitted
bash
# 审查当前分支相对 main 的变化
codex review --base main
bash
# 审查一个指定提交
codex review --commit <commit-sha>

如果你用的是桌面应用，直接用 /review 命令就行，选「未提交修改」或者挑一个基线分支。有一点值得留意：审查面板反映的是整个 Git 工作树，不单单是 Codex 自己改过的那部分内容。

第二步：给审查一个明确的关注点 ​

光有范围还不够，你得告诉 Codex 眼睛往哪看。我一般会用下面这个提示模板，感觉覆盖面已经够用了：

text
重点检查：
- 真实逻辑错误和边界条件；
- 权限绕过、敏感数据泄漏和不安全默认值；
- 数据损坏、重复写入、事务和幂等性；
- 公开 API、配置和旧数据兼容；
- 并发、时序、资源释放和错误处理；
- 测试是否漏掉改动带来的关键风险。

每条发现必须包含文件、位置、触发条件、影响和建议方向。不要报告纯格式偏好或没有触发路径的猜测。

按业务领域再加点料会更准。比如做支付的就盯紧金额计算、币种、幂等和回调；做前端的就重点看状态同步、可访问性和请求竞态。这个自己调一调，效果差很多。

第三步：逐条核实，别盲信 ​

这是我最想强调的一步。Codex 有时候会「过度热心」——发现一个潜在问题就列出来，但其实那条路径在真实代码里根本走不到。

我以前犯过一个错：Codex 指出某个字段可能为 nil，建议加空值检查。我二话不说就加了，结果上游函数明明有 guard clause，那个 nil 路径是 dead code。后来同事 review 的时候问：「你这个检查的触发条件是什么？」我当场愣住。

所以现在我对每条发现都追问四个问题：

  1. 触发条件在真实代码中能到达吗？
  2. 是不是已经被上游校验、类型系统或者数据库约束挡住了？
  3. 影响是用户真的会碰到，还是仅存在于理论上？
  4. 建议的修法会不会引入更大的兼容问题？

拿不准的时候，继续让 Codex 举证：

text
对发现 2，沿真实调用方证明未校验输入能够到达这里，并给出最小失败示例。只调查，不修改。

证明不了的发现就标成「待确认」，别机械地全盘接受。宁可留一条去问同事，也别闷头改出一个更难排查的问题。

第四步：按优先级动手 ​

我自己用的分级很朴素，跟大多数团队差不太多：

  • P0：会造成严重安全、数据或生产事故，必须阻止发布；
  • P1：常见条件下导致核心功能错误，合并前修掉；
  • P2：特定条件下的真实问题，建议修或者明确接受风险；
  • P3：低风险改进，别让它阻塞当前目标。

说句实在话，一次审查冒出十几个「变量命名可以优化」这种 P3 级别的建议，远不如两三个能稳定复现的 P1 来得有价值。抓住真正会炸的，风格问题以后再说。

第五步：修复后重新验证 ​

修完别直接合，再跑一遍审查确认问题真的消失了：

text
只修复已确认的发现 1 和 3。保持当前任务范围，不处理 P3 建议。为每个修复补最小回归测试，运行相关测试和构建，然后重新审查这些差异。

实际操作就是：跑原来那套验证命令，再执行同一个审查范围，看问题还在不在、有没有搞出新回归。

第六步：精确暂存，别一把梭 ​

提交之前先扫一眼：

bash
git diff
git diff --check

然后只暂存当前这个逻辑单元涉及的文件：

bash
git add path/to/file path/to/test
git diff --cached

这里有个我自己踩过的坑：工作树里同时改了两个不相关的功能，图省事来了个 git add .，结果提交信息根本没法写——到底是哪个功能的改动？后来每次暂存完我都会再看一眼 git diff --cached，确保暂存内容和提交标题能对上号。

处理 GitHub Pull Request ​

桌面应用要展示 PR 上下文的话，一般需要先装好 GitHub CLI 并登录：

bash
gh auth status

在 PR 分支上打开项目后，能读评论、看 diff、让 Codex 处理指定的反馈，然后你自己决定暂存、提交和推送的节奏。

如果仓库已经开了 Codex GitHub 代码审查功能，还能直接在 PR 评论里召唤：

text
@codex review

或者加个侧重点：

text
@codex review for authorization bypasses and data consistency issues

不过有一点要心里有数：自动审查和外部写操作取决于仓库的授权、套餐和组织策略。本地 API Key 能登录，不代表 GitHub 云端审查能力就自动开通了——这个我之前也搞混过。

给 Codex 留行级反馈 ​

桌面应用的审查面板支持把评论挂在具体行上，这比泛泛地说「这里有问题」高效太多了。高质量的评论把预期写清楚：

text
这里不能把缺失 tenantId 当成全局查询。请复用上方权限拒绝路径，并补一个无 tenantId 时返回 403 的测试。

留完行级评论后，再发一条总指令：「处理刚才的行级评论，保持其他差异不变」。Codex 就知道只动你标记的地方。

常见翻车现场 ​

审错基线 ​

功能分支不一定是从 main 拉的。先翻一下 Git 记录或者 PR 信息，把真正的基线确认清楚。

只看最后一轮修改 ​

最终交付要看整个工作树或者分支 diff，不能只盯 Codex 最后一轮改的东西。我因为这个漏掉过一个手动改的文件，教训深刻。

发现没有触发条件 ​

别不好意思追问——要调用链、要输入、要失败示例。没有证据的推测不该阻塞合并。

修审查问题时顺手扩大范围 ​

一次只处理已确认的问题，改完重新看 diff。重构灵感先记下来另开任务，不然 scope creep 一来就收不住了。

完成门槛 ​

  • [ ] 审查范围与目标分支一致。
  • [ ] 每条阻塞发现都有真实触发路径和影响。
  • [ ] 修复包含验证或回归测试。
  • [ ] staged diff 只包含当前逻辑单元。
  • [ ] 未经明确要求没有提交、推送或发布。

下一步 ​

代码准备好之后，接着看 更新文档并准备发布。

事实来源 ​