Claude如何修复自己的代码：Anthropic内部审查流程揭秘

当AI智能体写代码的速度远超人类审查能力时，代码评审这件事本身就必须被重写。Anthropic的Claude Code团队在自家仓库里经历的变化，给所有工程团队提供了一份难得的样本：从每秒堆积的PR到用Agent审查Agent，他们摸索出了一套把人类注意力留给真正关键问题的流程。

一个被逼出来的改变

据视频中引用Anthropic团队的说法，Claude目前撰写了Claude Code自身约90%的代码。这一比例在一年前约为85%，而随着模型能力提升，团队内部的合并PR数量从6月到9月翻了一倍多，同期需要回滚的PR占比却下降了超过40%。

更具冲击力的数字来自Anthropic的主仓库：每天落地的代码变更从5月的2500次增长到9月的超过3万次。在这样的量级下，逐行人工审查已经不只是困难，而是不可能。团队给出的判断很直接——他们把大部分代码阅读工作交给了机器，把人类时间用在只有人类才能解决的问题上。

重构代码审查的目标

Claude Code团队把代码审查拆成两个目标：一是在合并前发现并修复问题，二是在团队中建立对代码库的共享理解。视频作者认为后者长期被低估——读同事的diff是理解系统如何拼合起来的方式。

但团队坦承，他们并没有一个正式流程来保证第二部分。团队里没有人对Claude Code保持完整的心智模型。替代方案是：需要理解某块代码时，直接让Claude为那个切片写一份解释文档，几分钟内就能拿到反映当前状态的说明。看一份模块级别的解释，远比逐行阅读PDF式的trivial变更更有价值。

从「有人读过吗」到「哪一层能抓住它」

团队提出一个关键转变：不再问「有没有人类读过这段代码」，而是问「这个改动可能出什么问题，自动化检查还是人类检查是抓住它的正确工具」。

视频作者对此深有共鸣。他表示，在T3 Chat和T3 Code上线的回归问题中，无论自己是否review过代码，都不是在代码审查环节能发现的。如今的缺陷类型，靠长时间盯着代码找不出来。

说个细节作者的一个观点：大多数Agent现在的代码审查能力已经超过大多数人类。如果在你自己的代码库上不是这样，问题出在代码库本身。

分层防御：从本地验证到合并队列

Claude Code团队的典型改动要经过多层审查。

第一层：PR存在之前就完成验证

大部分审查发生在PR创建之前。团队给Claude提供可运行的验证对象，比如测试、构建产物、与设计稿对比的截图，要求它展示输出而不是声称完成。随后由一个子Agent在全新上下文中审查diff。

作者补充了自己的做法：用T3 OS为每个线程分配独立窗口，让Agent启动Electron开发服务器、录制变更演示视频并附在PR里。他还加入预置的假模型选择，让Agent可以跑完整端到端测试而不消耗额外token。

据Boris（Claude Code的原始作者）的估计，给Agent提供验证手段能让最终结果提升两到三倍。

第二层：AI审查与安检

每个PR先经过Claude Code审查：并行启动多个Agent搜寻bug，用验证器对发现投票，按严重程度排序。随后是独立的安全检查pass，再由分类器判断风险等级，决定需要零人、一人还是两人审批。

团队公布了一组数据：review研究预览上线后，内部获得实质性审查评论的PR占比从16%升至54%。超过一千行的PR大多能发现issue，小PR多数干净返回。

验证器投票（Verifier Voting） 是让多个并行运行的Agent对同一候选缺陷进行独立判断，再以多数票决定该发现是否可信的一种降噪机制。它的价值在于大模型审查存在较高的假阳性：单次判断容易把风格偏好或误读当成bug。并行化加投票能用推理成本换取准确率，也天然适配可横向扩展的Agent架构。代价是token开销上升，且当多个Agent共享同一模型偏见时，投票并不能纠正系统性误判，因此仍需按严重程度排序，把人类注意力留给高风险发现。

安全审查pass与风险分类器 通常指在功能审查之后单独运行的一轮检查，重点是权限提升、命令注入、密钥泄漏、依赖引入等安全维度，与逻辑正确性审查关注点不同，分离运行可避免互相干扰。随后由分类器根据改动涉及的文件、规模、敏感模块等信号给出风险等级，把审批路由到不同人力量级。分类器本身应保持保守：宁可把改动升级为人工审批，也不要把高风险变更误判为低风险而直接放行。

第三层：风险分层审批

低风险变更在CI全绿时可以直接合并，中等风险需要一人，高风险至少两人。审批看的是风险等级，不是指定某个具体reviewer。

一个重要的边界：只有仓库信任列表中的作者才能走轻量路径，Agent的批准永远不能替代人类的批准位。

第四层：合并队列与灰度发布

变更先进合并队列，再藏于功能开关后供内部使用，随后逐步放量。问题出现时快速修复或回滚。团队强调最后一层才是关键：失败应影响尽可能少的人，回滚成本尽可能低。

合并队列（Merge Queue） 是CI系统在真正合并前维护的待合并队列。它会把每个PR与队列中位于其前的改动临时组合，在合并后的目标分支状态下重跑必需检查，确保测试针对的是真实的合并结果而非过时的基线。这在每日数万次变更的仓库里尤其关键：主干移动极快，逐个PR基于旧状态验证几乎必然出现语义冲突。合并队列把冲突与失败挡在主干之外，让回滚粒度更小、定位更快，也是支撑高风险自动化合并的前置条件。

功能开关与灰度发布 是把代码部署与功能启用的解耦手段：变更先以关闭状态进入主干，再按内部用户、小比例流量、逐步放量的顺序打开。配合一键回滚，故障影响面可被限制在最小人群，且回滚无需反向合并代码，只需关闭开关。这一层常被视为分层防御中成本最低、收益最高的一环，因为其余各层都只能降低出错概率，而它决定出错后要付出多大代价。

让审查循环收敛

分层审查有一个副作用：每一层都可能给diff添加不必要的内容。作者提到见过本该五十行的改动被bloat到八百甚至两千行，因为中间的Agent把每一层的反馈都纳入了。

轮次上限与评分机制

Claude Code团队发现，在对reviewer反复标记的代码做git blame时，约60%是reviewer第一轮就见过、一直留在那儿的代码——reviewer很少发现新bug。他们引入三轮上限，超过就让作者退后重新考虑方案。改动后，一轮审查加修复就通过的PR增加了13%，需要五轮以上的PR从9%降到1.5%，平均通过轮次从2.08降到1.32。

作者尝试了另一种方案：让review Agent给1到10的分数，用分数阈值而非评论条数决定是否继续。一个只有一条评论但评分6分的PR，比有二十条无关紧要nit的PR更该修。

他也付出了代价：一个本该简单的改动在council review里跑了四天，PR涨到八万行代码。Anthropic也遇到过超过五十轮审查的CL。他的反思是：审查必须收敛，必须能结束。

审查循环收敛 是Agent参与审查后新出现的问题：审查者提出意见、作者修改、审查者再审查，每一轮都可能引入新改动并触发新意见，形成正反馈膨胀。常见的工程手段包括设置最大轮次、设定评分阈值、要求审查者只标记阻断性问题，以及在超过上限时强制作者重写方案而非继续打补丁。衡量收敛是否有效的指标通常是平均通过轮次、一轮通过率与超长轮次PR占比。设计时应把“何时停止审查”视为流程的一等参数，而不是临时的兜底规则。

人类该守在哪里

机器接管大部分阅读后，人的位置被重新定义：决定这件事值不值得做，把握方向、品味和范围；审查高风险代码如计费、自动更新、CI工作流；审查设定模式、会被他人复制的架构决策；读证据而非读代码——测试输出、命令返回、截图、审查发现。

如果无法说清自动化检查会漏掉什么，就应该要求一次真正的审查，而不是快速放行。

归属原则被反复强调：谁提的PR谁负责，代码由谁生成不影响这一条。谁prompt的，谁就是责任人。

跨团队共享上下文

Claude Code团队的应对方式是：不追求有人掌握全部代码，而是让需要理解时能快速获得解释。团队还依靠开放的Slack频道让成员看到彼此在构建什么，反馈也来自不拥有该代码的人。

作者对此很认同，他希望T3 Code也能解决团队协作与可见性的问题。

ReviewMD与Agent指令文件（如ClaudeMD） 是团队把重复出现的审查意见沉淀为可复用规则的载体，让Agent在后续审查中自动应用。但这类文件本质是给模型的提示说明，容易堆叠成冗长的行为约束，且无法修正代码结构本身的缺陷。更稳妥的做法是把规则分层：能通过类型系统、接口约束、测试覆盖解决的，优先在代码层解决；只能在流程层拦截的，写成lint或CI检查；最后才落到指令文件。这样规则才有可验证的执行位置，而不是依赖模型每次都忠实遵守。

值得借鉴的落地清单

视频最后整理了可以直接迁移的做法：

• PR之前：给Agent可运行的检查；本地跑审查与安全检查skill；把重复出现的审查评论沉淀到ReviewMD；优先修代码，再修lint，最后才动Agent指令文件。
• PR之中：CI必须拦；PR模板写清如何测试、风险是什么、如何撤销；接一个AI reviewer；开启自动安全审查并要求所有thread resolved；按风险匹配审查力度；设置审查轮次上限。
• 合并之后：使用合并队列、功能开关、内部先行、灰度发布、一键回滚；把事故和回滚转成eval集；re-score reviewer以验证改动是否真的有效。

作者对其中一条建议提出明确反对：Anthropic建议审查漏掉问题时把修复放进ClaudeMD或skill里。他认为顺序应反过来——能改代码结构就先改，改不了再加检查，检查也堵不住才去动指令文件。「不要不停地给模型进门前的说明书，而要把房间本身变得更好走。」

结语

这套流程的核心不是让AI替代人类审查，而是把人类注意力从「逐行确认」转移到「判断方向、承担归属、处理真正新的问题」。作者也点出一个反向风险：如果解决方案只是放慢速度，那并没有真正解决问题——减速降低错误率，往往只是因为做的事情变少了。真正要做的是更快地发现和修复问题。