一天夜里，Anthropic 内部一个 PR 被 AI 连着审了 50 多轮。一个 AI 写代码，另一个 AI 挑毛病，你来我往折腾了一整夜，最后是作者本人受不了叫了停。知乎微博
这不是段子，是 Claude Code 团队在官方博客里亲口曝出的翻车现场。
10 月 15 日，团队发了一篇《Claude Code 团队如何做代码审查》。它把那个所有人都想问的问题摊开了：Claude Code 自己约 90% 的代码是 Claude 写的。那这代码到底谁来审？知乎知乎微博
数据挺吓人：6 到 9 月，合并的 PR 数量翻倍，回滚率反而降了 40% 以上。Anthropic 主仓库每天落地的变更，从 5 月的约 2500 个涨到 9 月的超 3 万个。人工逐行审？物理上不可能。知乎微博知乎
他们的答案就一句话：把「读代码」交给机器，人只做机器做不了的事。微博
PR 打开之前，审查已经过了一遍
Claude 先自查：跑测试、跑构建，UI 改动还要截图跟设计稿对比。关键要求是必须交出证据，不能嘴上说「我改好了」。之后另一个子智能体在全新上下文里重读 diff，避免自己给自己打分。微博知乎
PR 打开之后，一群 AI 投票
多个智能体并行找 bug，再由一个独立小组对每条发现投票，共识够了才发布，纯风格类挑剔直接丢弃。每条问题都有标签：Important、Nit（小挑剔）、Pre-existing（老问题，不赖你）。而且每条都必须回应：要么修，要么给理由。很多修复是智能体夜里干完的，作者早上来上班，PR 已经又过了一轮。知乎
人干嘛？只管风险
分类器给变更定风险等级——看的是变更本身，不是作者资历。文档类低风险改动可以零人工合并，敏感路径和 CI 配置必须有人读，智能体的审批不算人工审批。谁指挥的 AI，谁就为代码负责，「就像代码是他亲手敲的一样」。微博知乎
那个 50 轮的翻车现场
团队事后 git blame 查了一遍，发现 AI 审查器反复标记的代码里，约 59% 是审查前就存在的老代码。它不是在发现新 bug，是每轮多翻点旧账。于是他们给审查轮数设了上限：审查必须收敛，不能俩 AI 无限互卷。知乎微博
这套机制普通人也能用上：/code-review 是本地轻量版，安全审查有开源的 GitHub Action 和 /security-review 命令。内测后，收到实质性评论的 PR 占比从 16% 涨到 54%。他们甚至把每次线上事故都变成「审查测试题」，每天拿审查器做一遍。微博知乎
别急着跪
这些数据全是 Anthropic 自己公布的，回滚率降低不等于软件质量必然更高。而且 AI 审查器有共同盲区——模型同源，犯错方式也一样。Meta 的新论文正好从反面佐证：让两家不同的编码代理互审（比如 Claude Code 和 Codex），比给单个代理加预算更能抓出无声 bug，完全正确的补丁比例从 45.8% 提到 62.5%。知乎微博
知乎那个问题下有个高赞回答说到了点子上：开发者的工作，正在从写代码、读代码，变成定义需求、设计验证、识别风险、为交付负责。知乎
「有没有人读过代码？」已经不是好问题了。真正的问题是：这个变更该由哪种检查来抓问题，以及漏过去之后，能不能快速回滚。知乎
