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

这套流程解决什么问题

PR review 的时间大部分不花在「看懂 diff」上，而花在三个地方：判断改动盘子有多大、找出 diff 之外受影响的地方、把发现整理成作者能直接改的反馈。前两项恰恰是 AI 相对人类有结构性优势的地方——人做 review 容易盯着 diff 本身，而 AI 会顺手把整个代码库扫一遍。

所以这套流程的定位是**「AI 做第一道筛，人做终审」：AI 负责穷举与归类，人负责判断与决策。它不是要替代 reviewer，而是把 reviewer 的时间从「通读」转移到「判断」**。

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

2026-10-08 更新：本轮补充了「这套流程解决什么问题」引言、「五个常见误区」、「什么时候不要用这套流程」与结论四节，并把文末 GitHub Actions 从「即将上线」的占位改为可用的示意配置（含未实测声明）。四步法本身的步骤与提示词未作改动。

谁需要这套流程

• 团队 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。

五个常见误区

误区一：把 AI 的输出直接当 review 评论发出去。 Step 4 的产出必须经过人过一遍。AI 会编造看起来合理的担忧（「这里可能有并发问题」但根本没有并发），直接发出去会浪费作者时间，也会损害 reviewer 的信用。

误区二：只给 AI 看 diff，不给它跑命令的权限。 这套流程里最有价值的两步——「改动前的行为是什么」（3.1）与「有没有漏改」（3.2）——都要求 AI 能跑 git show / git blame 并读 diff 之外的文件。只贴 diff 进去，等于把 AI 降格成一个更贵的 linter。

误区三：用同一套提示词审所有 PR。 依赖升级、DB 迁移、纯重构、新功能——这四类 PR 该问的问题完全不同。建议把 Step 3 的四个子步骤做成可勾选的：依赖 PR 只跑 3.4，重构 PR 重点跑 3.2 与 3.3。全跑一遍既慢又产生大量噪音。

误区四：让 AI 看 PR description 并当真。 见上文踩坑 1。description 是作者的自我陈述，它的作用是「作者声称要做什么」，而不是「实际做了什么」。有效的用法恰恰是让 AI 拿 description 的承诺去对照 diff 的实际改动，找出两者不一致的地方——那往往是最该问的问题。

误区五：以为自动化就等于可以无人值守。 见下节。

什么时候不要用这套流程

• 小于 50 行的 PR：读一遍比开 AI 快，且 token 成本不划算。
• 纯配置 / 版本号改动：AI 扫不出人类看一眼就知道的东西，纯属浪费。
• 架构方向性争论：「这个设计对不对」这类问题 AI 只能给出看似中立的主流意见，不能替代团队的架构判断。
• 涉及安全边界的改动：AI 可以给线索，但权限、加密、鉴权相关的改动必须人来逐行确认——这类地方 AI 漏报的代价远大于误报。

结论与下一步

这套流程真正省时间的不是「AI 帮我读代码」，而是把 review 从「串行通读」变成「并行归类 + 定点深挖」。落地建议按下面三步走，别一次上全套：

1. 先用 Step 2 一个步骤（改动分类 + 三个特别标记）。这一步最便宜、最立竿见影，跑两周再决定要不要加 Step 3。
2. 给高风险 PR 加 Step 3 的 3.1 与 3.2。这两步的产出最实用，也最容易被验证——看它找出的「漏改」是不是真的漏了。
3. 最后再考虑自动化。自动化会把流程固化，流程没跑顺之前先固化是把自己锁死。

判断这套流程有没有生效的标准只有一个：reviewer 花在「通读 diff」上的时间是不是明显下降了。如果没有，说明提示词或步骤划分需要调，而不是工具不行。

Bonus：把这套做成 CI 里的自动 review

把 Step 2-3 写成一个脚本 + 提示词文件，在 PR 创建/更新时自动跑，把结果发到 PR 评论区。

下面是示意配置，本站未实测跑通——命令行参数（尤其是 --prompt-file / --output-file 这类）请以你所用工具的官方文档为准。Claude Code 的一次性调用通常用 claude -p "<prompt>"，把提示词用 $(cat ...) 或 heredoc 传入比依赖特定参数更稳：

#!/usr/bin/env bash
# .github/hooks/pr-review.sh（示意，未实测）
set -euo pipefail

git fetch origin main
git diff main...HEAD > /tmp/pr.diff

# 把提示词与 diff 拼在一起，交给一次性模式
{
  cat .github/hooks/review-prompt.md
  printf '\n\n----- DIFF -----\n'
  cat /tmp/pr.diff
} | claude -p > /tmp/review.md

gh pr comment "$PR_NUMBER" --body-file /tmp/review.md

配套的关键不是脚本，而是护栏。自动 review 上 CI 之前，先把这四件事定下来：

完整可运行的 GitHub Actions 工作流本站尚未整理发布（原「即将上线」为占位）。在此之前，建议先按上文「结论与下一步」的三步顺序手动跑顺，再考虑固化。

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