Anthropic 代码审查推荐解读，代理时代怎么保住审查这道关

AI 写了公司九成的代码，谁来审查。这个问题并非假设，它是一家头部 AI 公司的现实，现实的极端程度超出多数团队的想象，他们自家编程工具的代码绝大部分由自家模型写，日均变更从两千五百次涨到三万次，逐行人工审查早就不可能。团队上周把内部解法写成博客公开，技术社区两百多分两百条讨论。我把原文与讨论核了一遍，核完的结论是流程图能直接贴墙上，这套流程对每个用代理写代码的团队都是现成参考。

他们的问题

先看现状有多极端。模型写了工具自身约九成代码，合并请求数四个月翻倍，更麻烦的是代理互审会死循环，一条请求一夜跑了五十多轮审查修复，越修越乱，乱到第二天人工来收拾的代价比从头写还高。对审查意见做溯源分析，六成的被标记问题在请求之前就存在，审了个寂寞，寂寞的审查比不审查更糟，因为它给了虚假的安全感。这些数字全部来自官方博客自称口径。

四层解法

流程分四层，层层设闸。请求前这一层，模型自跑测试构建与检查，全新上下文的子代理再审一遍差异，规范写在配置文件里，文件本身就是给后来代理的说明书。请求时，多代理并行找问题加一个校验代理投票，幸存意见按重要、建议、既有三分，误伤率就此降下来。安全审查独立跑且未过即阻断合并，安全这条线不给任何变通。审批按风险分级，低风险免人工，中风险一人复核，高风险两人复核，敏感目录永远要人。硬规矩是代理审批永不计入人工名额，名额这条线画死，出了事永远能找到一个人类负责。

合并后是防线。队列重跑检查，新功能按员工、尝鲜、稳定三档灰度，每周值班，一键回滚，回滚这个按钮的存在本身就是一种工程态度。改进环把每次事故变成每日跑的评测用例，坏经验不再靠老师傅的记性，记性会退休，评测用例不会。收敛手段防死循环，审查三轮封顶，只看差异，不重复报同类问题。

效果数字按自称转述，回滚率降超四成，有效审查评论占比从一成六升到五成四，一轮通过率从六成五升到七成八，需五轮以上的从百分之八点九降到百分之一点五。

社区吵什么

支持面集中在几条硬规矩，不让机器人审批顶替人工坑位这条被反复点赞，点赞的多是一线管理者，他们最清楚坑位被顶掉意味着什么。质疑面同样尖锐，有人认为 AI 写 AI 审是软件工程的慢性自杀，垃圾代码会自我繁殖，繁殖到某天系统复杂度超出所有人类理解范围。有用户抱怨模型会为一致性擅自重构，一个修 bug 的请求顺手改了三个文件的风格，审查负担不降反升。初级工程师的成长路径受冲击是讨论里最人文的一条，以前新人从审查别人的代码学起，这个梯子正在抽走，抽走之后用什么替代，没人给出答案。

作者的背景值得一提，第一作者在谷歌干了十四年管开发者工具，九月刚跳到这家公司做编程工具，文章带着大厂工程文化底子，底子扎实的文章读起来就是不一样，每个数字都有出处，每个取舍都有理由。

解决了什么需求

代理写码的团队迟早撞上同一堵墙，产量上去了审查跟不上。这套流程的可贵在于它跑在日产三万次变更上，属于活系统而非理论推演，四层结构与风险分级都可以直接抄。抄的时候记住两条底线，安全审查永远独立，人工名额永远不缩水，守住这两条，其余的按自家规模裁剪。

一句话收尾，代码产量翻了十倍，审查这道关还在，只是换了材料重修，修得比原来更结实。

来源

• 官方博客 https://claude.dev/blog/solving-code-review-at-anthropic/
• 社区讨论 https://news.ycombinator.com/item?id=50122951