用 Codex 做代码审查、Git 和 PR 闭环

代码审查不是让 Codex 总结改了什么，而是要求它找出会在特定条件下造成错误、安全问题、数据损坏或兼容性回归的差异。审查质量首先取决于 diff 范围是否正确。

第一步：确认审查范围

先查看仓库状态：

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

常用 CLI 范围：

# 审查未提交修改，包括 staged、unstaged 和 untracked
codex review --uncommitted

# 审查当前分支相对 main 的变化
codex review --base main

# 审查一个指定提交
codex review --commit <commit-sha>

在桌面应用中可使用 /review，选择未提交修改或相对基线分支。审查面板反映整个 Git 工作树，不只显示 Codex 自己改的内容。

第二步：给审查一个明确重点

通用高价值提示：

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

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

按领域增加重点，例如支付检查金额、币种、幂等和回调；前端检查状态同步、可访问性和请求竞态。

第三步：核实每条发现

对每条发现问四个问题：

1. 触发条件在真实代码中能到达吗？
2. 是否已经被上游校验、类型或数据库约束阻止？
3. 影响是用户可见错误，还是仅理论可能？
4. 建议修复会不会引入更大兼容问题？

可以让 Codex继续举证：

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

无法证明的发现标为待确认，不要机械全部应用。

第四步：按优先级处理

可使用以下实用分级：

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

一次审查发现十几个“风格问题”通常不如两个能稳定复现的 P1 有价值。

第五步：修复后重新验证

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

运行原验证命令后再次执行同一审查范围，确认问题消失且没有产生新回归。

第六步：精确暂存

先检查：

git diff
git diff --check

只暂存当前逻辑单元涉及的文件：

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

工作树中存在其他任务修改时，不要使用 git add .。暂存后再次检查 staged diff，确保提交内容和标题能够一一对应。

处理 GitHub Pull Request

桌面应用要显示 PR 上下文，通常需要安装并登录 GitHub CLI：

gh auth status

在 PR 分支打开项目后，可以读取评论、查看 diff、让 Codex处理指定反馈，再由你决定暂存、提交和推送。

如果仓库已启用 Codex GitHub 代码审查，也可以在 PR 评论：

@codex review

或增加重点：

@codex review for authorization bypasses and data consistency issues

自动审查和外部写操作取决于仓库授权、套餐和组织策略。不要假设本地 API Key 登录自动拥有 GitHub 云端审查能力。

给 Codex 的行级反馈

桌面应用审查面板支持把评论附到具体行。高质量评论写清预期：

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

留下行级评论后，再发送总指令：“处理刚才的行级评论，保持其他差异不变”。

常见失败

审错基线

功能分支可能不是从 main 创建。先用 Git 记录或 PR 信息确认真正基线。

只看最后一轮修改

最终交付要看整个工作树或分支 diff，不能只看 Codex 最后一轮。

发现没有触发条件

要求调用链、输入和失败示例。没有证据的推测不应阻塞合并。

修审查问题时扩大范围

一次只处理已确认问题，重新看 diff。重构建议另开任务。

完成门槛

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

下一步

代码准备完成后，继续学习 更新文档并准备发布。

事实来源

• Codex 代码审查
• Codex GitHub 代码审查