AI 做 PR Review：开发者的 5 倍速 review 工作流

谁需要这套流程

• 团队 leader / staff engineer，每天 review 5-10 个 PR
• 独立维护者，开源项目 PR 多但人手少
• 想给自己的 PR 自查的开发者

核心承诺：让 AI 做"第一道筛"——把明显问题 + 一致性问题先过一遍，人脑只看 AI 标出来的高价值地方。

不要做什么

• ❌ 让 AI 写 LGTM 然后 merge——AI 会把烂代码 review 通过
• ❌ 让 AI 决定合不合并——AI 只做建议，决策权在人
• ❌ 把 PR 全文丢给 ChatGPT 网页版让它"看看"——上下文不够，结论不可信

工作流：4 步法

Step 1 — 准备 review 上下文（2 min）

# 在 PR 分支
git fetch origin main
git diff main...HEAD > /tmp/pr.diff
git log main..HEAD --pretty=format:'%h %s%n%b' > /tmp/pr.commits

进入项目根，开 Claude Code 或 Cursor。

Step 2 — 让 AI 分类改动（5 min）

请分析本分支相对 main 的改动（git diff main...HEAD），按类型归类：

A. 业务逻辑改动（新功能 / bug 修复 / 行为变更）
B. 重构（不改行为）
C. 测试改动
D. 配置 / 依赖
E. 文档

输出 markdown 表格：类型 | 文件 | 改动摘要（1 句）

特别标出：
- 是否有"业务逻辑改动"但没有对应测试
- 是否有"重构"但行为可能被无意改变
- 是否有任何 secret / API key 出现在 diff 里

这一步的产出物极其有价值——你瞬间知道这个 PR 的盘子有多大、风险点在哪。

Step 3 — 深度审视（10-30 min）

针对 Step 2 标出的高风险项，挨个深问：

3.1 业务逻辑深查

对于改动【文件 X 第 Y-Z 行】，请回答：

1. 改动前的行为是什么？（读 git blame / git show HEAD~1）
2. 改动后的行为是什么？
3. 这两个行为的差异是否符合 commit message / PR description 的承诺？
4. 有没有 edge case 没考虑？（null / 空数组 / 极大值 / 并发）
5. 有没有可能影响其他调用方？

每条都要给确凿依据，不要"我觉得"。

3.2 一致性扫描

请扫描整个项目，看本 PR 的改动有没有"漏改"：

- 如果 PR 改了某个函数的签名，所有调用方都改了吗？
- 如果 PR 加了新的常量，类似的常量定义是否同步更新？
- 如果 PR 改了某个文件的 pattern，类似文件是否需要同样改？

逐条列出"可能漏改但 PR 里没改"的地方，给文件:行号。

这是 AI 比人类强的地方——人类做 PR review 容易盯着 diff 看，AI 会去看 diff 之外的地方。

3.3 测试 review

对于本 PR 中的测试改动 + 新增测试，请评估：

1. 测试是否真的覆盖了"业务逻辑改动"？还是只覆盖了 happy path？
2. 测试的断言是否够强？（不要只 assert 不抛异常）
3. 有没有"修测试让它通过"的痕迹（注释掉的 assert / 改宽容的 matcher）？
4. 哪些 edge case 没被测到？

输出：测试覆盖度评估 + 建议补的测试用例（伪代码）

3.4 风险与回滚

假设这个 PR 合并到生产后出了严重问题，回滚成本如何？

- 单纯 revert 这个 commit 能恢复吗？
- 有没有不可逆的改动（DB 迁移 / 数据格式变更 / 删了字段）？
- 有没有"客户端已经发了新版本，服务端不能简单回滚"的耦合？

如果回滚成本高，建议拆 PR 或加 feature flag。

Step 4 — 整合 review 反馈（5 min）

请整合前面 3.1-3.4 的所有发现，输出一份最终 review 评论，格式：

## ✅ 看起来没问题的部分
（简短列出）

## ⚠️ 需要 PR author 回应的问题
（每条带文件:行号 + 具体问题）

## 🛑 阻塞合并的问题
（如有，必须解决才能合）

## 💡 建议（非阻塞）
（可选优化）

语气专业、具体，不要客套话。

人工 review 这份 markdown——70% 的内容你直接 copy 到 PR 评论区。剩下 30% 自己再补充判断和上下文。

实战时间分配

对比纯人工 review 一个中型 PR（~500 行 diff）通常 60-90 min，省一半时间，且漏掉问题更少（AI 看的范围比人广）。

工具选择

• Claude Code ← 首选。能跑命令读 git history，做"全局一致性扫描"最强
• Cursor + @codebase ← 中型项目够用，便宜
• Augment ← 团队场景，原生集成 PR 流程
• ChatGPT 网页版 ← 不推荐，上下文不够

踩坑

1. 不要给 AI "PR description"作为唯一上下文

PR description 是作者自己写的，不一定准。让 AI 自己读 diff，不要被 description 带偏。

2. 警惕 AI 的"看起来 LGTM"

AI 倾向于温和。如果它说"看起来没问题"，强制让它给出 3 条具体担忧——总能挖出来。

3. 别完全替代人脑

AI 的 review 是第一道筛，不是终审。关键判断（架构是否合理 / 是否符合产品方向）只能人做。

4. 注意 token 预算

大 PR review 容易烧 $1-5。对小 PR（< 50 行）直接人脑 review，不值得开 AI。

Bonus：把这套做成 git hook

把 Step 2-3 写成一个 shell 脚本 + Claude Code prompt 文件，挂在 PR 创建/更新时自动跑：

# .github/hooks/pr-review.sh （示意）
#!/bin/bash
git diff main...HEAD > /tmp/pr.diff
claude-code --prompt-file=.github/hooks/review-prompt.md \
            --output-file=/tmp/review.md
gh pr comment $PR_NUMBER --body-file /tmp/review.md

完整 GitHub Actions 工作流即将整理上线。

继续阅读：陌生项目 onboarding 工作流、大型重构工作流。