一句话总结
一段 200 行、能编译、过 CI、读起来还很顺的 AI diff，是现代代码库里风险最高的产物——因为所有表面信号都在喊”快合并”。审 AI 补丁要按固定顺序：先看删除，再看重命名，最后才看新逻辑，然后把 AI 声称修好的测试在 main 和分支上各跑一遍。预算大致是每 30 行有效 diff 花 1 分钟。工具辅助审查（GitHub Copilot code review、Cursor 的 diff 面板、让 Claude Code 自评）可以当第二遍，但绝不能当唯一一遍。
为什么 AI diff 要换一种读法
人写 200 行补丁时，bug 集中在他亲手敲的那些行。agent 写的时候，bug 集中在它删掉或挪走、却没真正看懂的那些行——而这恰恰是你的眼睛会跳过去的地方。agent 会很自然地把一个 if (err) return 守卫删掉，理由是”happy path 更干净”；会把它从没见过对应测试的时区处理悄悄回退；会把鉴权检查下沉一层，看着没问题，实际已经不覆盖公开路由了。
解法是反着你的直觉来。大多数人从上往下读，一下子就被新代码的意图吸住。审 AI 补丁要在注意力还充足的时候，先看最没意思的那部分。
这篇适合所有审 AI PR 的人——不管作者是同事、是 agent，还是一小时前的你自己。最尴尬的 AI 改动几乎都是在”自审”这一关漏出去的，因为人会默认自己还记得当时要的是什么。
开始前准备
- 把分支 pull 到本地。 不要只在 GitHub 网页上审——你得能跑
git log、git blame和测试，才有办法去证伪任何东西。 - 要一份像样的描述。 “我让 Claude 修了那个 bug”不算描述，直接退回。好的 AI PR 会写清楚：出错的行为、根因、改法。
- 把复现摆在面前。 如果没有补丁声称修好的失败测试或复现步骤，第一个要问的就是 agent 到底在解什么。
- 关掉 diff 折叠（编辑器或 GitHub 视图里都关）。折叠的区域正是无声删除藏身的地方。
阅读顺序，一步步来
- 先看删除。 找红色最多的文件。AI agent 经常把它没看懂的分支、错误处理、整段 feature flag 悄悄删掉。
- 其次看重命名。
git log --follow和git diff -M能识别真重命名。有时 agent 是”删掉再新建”一个文件，blame 历史会丢，一次标着”重命名”的提交里可能藏着行为变更。 - 最后看新逻辑。 新代码读起来最爽，也最容易点头放行。留到你状态最好、最挑剔的时候再看。
- 把声称修好的测试在两边各跑一遍。 checkout 到
main，确认它失败；checkout 到分支，确认它通过。agent 有时会改 assertion、让它去匹配错误输出，以此”修好”测试。 git log <branch> --not main看每一个 commit。一个标着”fix typo”却动了业务逻辑的 commit，是恐慌修复的标志，值得再看一眼。
60 秒快速 sanity 脚本
把这段放进 shell，快速扫一遍 AI 补丁：
git fetch origin
git diff --stat origin/main...HEAD | sort -k3 -n -r | head # 大文件排在前
git log origin/main..HEAD --oneline # 分支上的每个 commit
git diff origin/main...HEAD -- '*.test.*' '*spec*' # 只看测试改动
git diff origin/main...HEAD | grep -E '^-' | head -40 # 只看删除如果最后一行显示删掉了 try、catch、if (err) 或 return——先停下，回去把上下文读清楚，别看别的。
如果 agent 把一处改动伪装成”格式化”，就把真实变更逼出来：
git diff -w origin/main...HEAD # 忽略空白，看到底改了什么
git diff --word-diff origin/main...HEAD # 行内逐词 diff
git diff --ws-error-highlight=all origin/main...HEAD # 标出偷偷塞进来的空白改动git diff -w 是区分”真逻辑变更”和”我把整个文件重新缩进了 300 行”最快的办法。完整选项见 git-diff 官方文档。
AI 经常错、人通常不会错的几件事
- 因为”happy path 更干净”而无声删除
if (err) return。 - off-by-one 被当作”代码清晰度”提交：
<悄悄变成<=。 - 时区处理回退到系统默认，因为 agent 没看到那个 TZ 测试。
- 鉴权检查下沉一层，看着对、其实已经不再守护公开路由。
- 测试里原本打真实（且有意为之）接口的网络调用被 mock 掉了。
- 顺序敏感的配置被”重构”打乱——Express middleware、Webpack loader、Vite 插件。
把 AI 审查工具当第二遍用（截至 2026 年 6 月）
先让工具扫一遍，再做上面那遍人工审查。把工具的输出当成”需要重点看的位置清单”，而不是结论。
| 工具 | 跑在哪 | 擅长什么 | 费用提示（2026 年 6 月） |
|---|---|---|---|
| GitHub Copilot code review | PR 上，GitHub 里 | 抓 bug、安全隐患、风格；Low 档快，Medium 档把复杂/跨服务改动转给更强推理模型 | 按 AI Credits 计费；私有仓库自 2026 年 6 月 1 日 起每次审查消耗你套餐里的 Actions 分钟（公开仓库仍免费） |
| Cursor | 编辑器里，提交前 | 多文件 agent 改动的并排 diff 面板，每处改动落地前你逐个 inline 确认 | Pro 每月 $20（年付约 $16）；可跑 Sonnet 4.6、Opus 4.7、GPT-5.5、Gemini 3.1 Pro |
| Claude Code | 终端 / IDE 里 | 让它自评 diff、逐条解释每处删除；尤其擅长找出它自己刚删掉的守卫 | 含在 Claude Pro 每月 $20 里（年付 $17） |
用 AI 审查器有两条铁律：
- 当第二意见，绝不当唯一意见。 写出 bug 的那个模型，最不可能标出这个 bug。GitHub 的 agent 审查甚至会把建议直接交回 coding agent 去开一个修复 PR——方便归方便，合并的责任仍在你身上。
- 如果测试也是 AI 写的，读测试 diff 要加倍怀疑。 至少确认有一条测试在断言一个 agent 不可能从你的 prompt 里推出来的具体值。一条只检查”返回了点什么”的测试，什么都证明不了。
如果你要在一个新仓库上搭 agent 审查流程，先用 Cursor 做编辑器级那一遍、用你的 Claude Code 工作流 做终端那一遍，确认无误之后再考虑让任何东西自动合并。
完整工作流
删除 → 重命名 → 新代码 → 在 main 和分支上分别跑那个声称修好的测试
→ 看 git log 有没有惊奇 commit → 工具扫一遍 → approve 或退回200 行的补丁应该花 5–10 分钟。超过就说明 PR 太大，要求拆分。另外，AI PR 宁可退回，也别带着 comment 就 approve：agent 一轮就能免费把所有 nit 改好，没理由揣着已知问题去合并。
FAQ
- CI 绿了就能信吗？ 算必要不充分。CI 抓的是你已经写过测试的回归；AI 的失败模式往往活在这些覆盖之外。
- 审一个 PR 多久合理？ 大致每 30 行有效 diff 用 1 分钟。明显更大就该拆成可审的小块。
- 如果测试也是 AI 写的呢？ 用加倍的怀疑读测试 diff。至少确认有一条 assertion 在断言一个 agent 不可能从 prompt 里推断出的具体值。
- 能让 AI 审自己的 diff 吗？ 当第二意见可以，当唯一意见绝不行。它经常恰好漏掉自己刚做错的那件事。
- 现在用 GitHub Copilot code review 要花钱吗？ 自 2026 年 6 月 1 日起按 AI Credits 计费，私有仓库每次审查会消耗你套餐里的 GitHub Actions 分钟；公开仓库的审查仍免费。详见 GitHub 定价页。
- 超大生成文件（lockfile、schema）怎么办？ 折叠着看，但抽查 agent 声称改了的那些版本号是不是真的变了。