程序员必看：AI 写 90% 代码，评审怎么做
Claude 写掉了 Claude Code 自己 90% 的代码。
看到这个数字，我第一反应不是惊叹，是另一个问题：那这些代码谁在 review？
Anthropic 前几天的长文回答了这个问题。答案是：没有取消评审，而是把"读代码"整体搬给机器，把人的时间挪到判断上。

第一件事：把问题问对
我们判断一个变更靠不靠谱，习惯问"有没有人认真读过"。
Anthropic 说这个提法太糙。该问的是：这次变更可能出什么问题？哪一关最适合拦住它？
问题一换，评审的时间点也变了——从"流程末端的闸门"，变成"写文档时的拼写检查"。

第二件事：六层防线，不是一道闸门
1️⃣ 开 PR 之前就自证：给 AI 一个能验证的东西（测试、构建、截图），要求它拿出输出，而不是说"我做完了"
2️⃣ 每个 PR 都有 AI 评审：对照整个仓库 + PR 声称的意图，问"解决了问题吗？符合系统吗？会破坏别的吗？"
3️⃣ 安全评审能直接拦住合并
4️⃣ 强制 CI：lint、类型检查、多平台测试、构建，一个 PR 几十项
5️⃣ 按风险分级的人工批准：低风险 0 人、中风险 1 人、高风险 2 人
6️⃣ 合并队列 + flag + 灰度
底下还兜着一层：快速回滚。

第三件事：评审必须收敛
他们的 AI 评审曾经一夜之间跑过 50 多轮，最后是作者手动叫停的。
回头一查 git blame：评审者反复指出的问题里，59% 是第一轮就已经存在的代码。它每轮只是在挖更多老 bug，不是发现新问题。
解法就四条：3 轮上限、只看新 diff、指出 bug 的类别（让作者一次修完同类）、不重复发同样的意见。
效果：一轮就通过的 PR 从 65% 涨到 78%。

第四件事：人还剩下什么
不是"人不用看了"，是人只在这几件事上出现：
- 决定要不要做（方向、品味、范围）
- 看高风险代码（计费、自动更新、CI）
- 看会被别人抄走的架构
- 读证据（测试输出、命令、截图），而不是点个通过
- 对结果负责

最后一条配着他们的团队惯例：你合的，你负责。

这句话能成立，靠的不是责任心，是四个前提：变更小、一切可逆、爆炸半径决定标准、回归暴露得快。

我最大的感受：大家会把注意力放在"AI 评审"上，但真正的杠杆不是它。是"可验证"和"可回滚"。

你们团队现在卡在哪一步？是没人愿意 review，还是 review 完了照样出事故？
评论区聊聊，我挑几个一起拆 👇