大家好，我是鲁工。
现在已经快2026年年底了，市面上基本上没有古法编程的团队了吧？可能还有个别编程非遗老师傅，还在坚持古法和手搓代码，但在Vibe Coding与AI浪潮下，古法编程逐渐式微已是不争的事实。
但是Vibe Coding一时爽，Code Review火葬场。相信很多Vibe大师都有这个体会。AI分分钟干大几千行代码，人工根本看不过来。我知道肯定有人尝试过通篇Review AI写的代码，但到最后基本都会放弃。
AI写代码，最大的痛苦就是人脑跟不上AI产能。特别是同时推进多个项目时，人工Review名存实亡，以前还会挨个文件翻diff，后来连diff都翻不完，看着测试跑通就放行了。“能跑就行”现在似乎已经成为大家的共识。
到了大团队里，这种割裂更严重。Anthropic主仓库每天合入的代码变更，从今年5月的2500个涨到9月的30000个以上，四个月翻了12倍。放到国内研发团队看，很多组上了AI写代码，评审却还卡在老规矩上，要求每个PR找两个高级开发逐行看完签字，代码生成只要几分钟，排队等审批反而成了最大的瓶颈。
那么Anthropic是怎么破局的？前两天他们工程团队发了一篇技术长文，作者是Osmani、Lunt和Qing Wang，专门聊了这个所有重度用AI写代码的人都很头疼的问题：当Claude写了Claude Code自身约90%的代码，团队怎么把代码审过来？
https://claude.dev/blog/solving-code-review-at-anthropic/
文章里举了个例子。在Claude Code仓库里，有个CLI的PR，写代码的Agent和审代码的Agent在夜里来回拉锯了50多轮，一个提意见、一个改代码，直到第二天早上作者起床后发现这俩一直在左右互搏，无奈只能手动停掉。
为了彻底解决这类问题，他们先把Code Review的衡量标准换了。过去默认问有没有人读过这段代码，现在改问这处改动可能出什么问题，哪道检查最容易拦住它。
思路也很简单，把读代码的活大面积交给机器，人的精力省下来只盯高风险的地方。定下的目标也很直接：绝大多数PR合入时，最多只需要一个人类介入（甚至可以是提PR的作者自己），同时线上回滚率和事故率不能上涨。今年6月到9月，Claude Code仓库合入的PR数翻了一倍多，上线回滚率反而下降了40%以上。
低风险PR直接免掉人工审批
既然不让人逐行看代码了，怎么保证上线不炸？Anthropic搞了一套瑞士奶酪式的六层防线，最底下再垫一层快速回滚。单拎出哪一层都可能漏掉bug，但六层筛子叠在一起，能漏到生产环境的问题就很少了。
这套流程看下来，最值得国内开发团队借鉴的，是怎么把检查尽量往前提，以及怎么大胆给人工审批减负。
很多人用AI写完代码，顺手就提了PR，等于把擦屁股的活全甩给了Reviewer。但在Claude Code团队，大头工作在提PR之前就已经在作者自己电脑上干完了。
代码改完，作者必须先让Claude自己跑一遍测试、跑通构建，要是改了前端界面，还得截图去跟设计稿做比对。光嘴上说"改好了"不算数，必须把终端跑出来的真实日志贴上去当证据。接着再新开一个干净上下文的Subagent专门来挑刺，顺手跑几个抓bug和精简代码的内部Skills。
Claude Code创始人Cherny给过一个估算，光让模型自检这一步，代码质量就能拉高2到3倍。
用过AI审代码的朋友肯定遇到过另一种烦心事，就是AI老揪着某类鸡毛蒜皮的问题没完没了地唠叨。大概就是一份代码，即使是Opus 5.5或者Fable 5.1写出来的，你拿任何一个国产模型去review，它也总能挑出些无关紧要的刺来。
Claude团队的做法是，一旦发现AI审查员在哪类问题上总翻车，直接去源头改仓库里的CLAUDE.md和REVIEW.md。因为每次审查都会加载CLAUDE.md，所以大仓库里写得非常简短，审查员还会顺手标出那些让CLAUDE.md描述过时的代码改动。
各个模块负责人自己写的REVIEW.md也很接地气。写得好的REVIEW.md都很短，直接用大白话告诉AI在我这一亩三分地里什么叫"出事了"，比如文档模块就一句话叫"它在撒谎"（it lies），配置模块就叫"它指错了路"（it misroutes）。文件里还会明确限制细节挑刺的数量、列出直接跳过的目录，要求报错必须给出文件名和行号当证据，没问题就痛快闭嘴说无需修改。
等代码真正提了PR，第一道堵门的是多Agent自动审查。今年3月我在《Claude Code近期两大实用更新：/loop和Code Review》里聊过它的预览版，现在它已经在Team和Enterprise计划里正式上线了，平时在本地敲个/code-review也能跑轻量版。上线后，他们内部PR拿到实质性评论的比例直接从16%涨到了54%。
它的运作逻辑很像专家会诊。后台先由几个Agent分头找bug，找到之后不能直接发出来吓人，得先交由另一组验证Agent投票，多数点头认可这是个真bug，才会贴到PR下面。以前最烦人的纯代码风格挑刺，他们做完A/B测试发现纯属耽误工夫，直接一刀砍掉了。留下来的评论也会标清楚到底是严重问题、顺手改的小毛病，还是老代码里本来就有的坑，省得提PR的人替前人背锅。
等上面这一整套bug审查、安全扫描（/security-review）和几十项CI检查全跑绿了，才轮到真人的环节。这时候他们做了一个国内很多团队不敢想的决定：需不需要人来审，只看这次改动本身有多大风险，不看代码是人写的还是AI写的。
他们把PR按风险分成了低、中、高三档。要是平时改个文档、换句文案、做个纯内部小工具，或者代码严严实实藏在特性开关后面，统统算低风险。只要你是团队里受信任的熟手，机器检查全绿之后，连一个额外的同事审批都不需要，直接就能合入主干。
只有碰了常规产品逻辑，或者动到缓存、自动更新器这种敏感部位，才算中风险，找1个人看看就行。最核心的高危代码和CI配置算高风险，老老实实找2个人点头放行才行。
当然，口子放得这么开，锅必须背明白。哪怕代码一行没动全是Agent写的，谁给Agent下的指令，谁就是第一责任人，算作法定审查员之一。Agent点再多赞也不能顶替人类的审批名额，而且只要中途Agent又推了新commit，或者有人手动解过合并冲突，前面的审批立马作废，得老老实实重跑一遍。
代码合进去之后，也是先挂着特性开关给内部员工吃狗粮，真要在生产环境出问题，不用重新部署发版，后台直接把开关一关就能秒级回滚。不过他们也在博客里很实在地交了个底，目前这套机制还差一个自动熔断器，理想情况下如果哪天回滚率突然抬头，系统应该自动收紧审批门槛。内部工程师也明确表态，得先把这个保险丝装上，才敢把更多代码放进零人工审批通道。
两个Agent通宵互搏50轮，逼出了四条收敛规矩
前面提到那个两个Agent通宵拉锯50多轮的事故，背后暴露了一个很棘手的工程问题。如果提PR的是个人，看到AI提了一条不痛不痒的细节建议，划过去不理就行了。但要是提PR的也是个Agent，它看到一条评论就会老老实实去改代码、推新commit，新commit一推又触发新一轮AI审查，俩Agent就这么在夜里没完没了地循环下去。
Claude Code团队事后复盘查出来的结果很有意思。他们拿git blame去查了审查Agent反复揪着不放的那些代码行，发现里面足足有59%在第一轮审查时就已经存在了。也就是说，审查Agent很少在新打的补丁里抓到新bug，只是每多跑一轮，就从老代码里多翻出几个以前漏掉的陈年旧账。
摸清这个毛病之后，他们立了四条死规矩来给AI强行刹车。首先是最多只审3轮，超过3轮还过不了就直接封顶停掉，让人退后一步重新审视整体方案，别在死胡同里硬改。其次是前几轮过后只准看新增的diff，不准再翻老代码的旧账。报错的时候还得按bug类型打包归类，方便作者一次性修完同类问题，而且发过的意见绝不许车轱辘话来回说。至于老代码里那些存量问题，单独丢给半夜定时跑的审查Agent去慢慢扫，别卡在日常发版的脖子上。
这几招下去效果立竿见影。内部PR审一轮就能过的比例从65%提到了78%，需要来回拉锯5轮以上的硬骨头从8.9%压到了1.5%，平均1.32轮就能搞定。
为了防止审查Agent改着改着变傻，他们还搞了个错题本机制，把每次线上事故和代码回滚都做成了评测集（eval）。
每次只要有漏网之鱼引起线上故障，就找熟悉那块业务的工程师确认bug位置，塞进回归评测集里天天跑分。以后不管谁想改审查员的提示词、换工具还是升级底层模型，都得先拿历史上所有踩过的坑考一遍，分数涨了才准保留。
人工只Review关键地方
看到这儿肯定有人要问，以前做Code Review还有一个很重要的作用是帮团队成员熟悉代码库，现在代码全让机器读了，人岂不是两眼一抹黑？
Claude Code团队给出的回答非常实在：他们团队里，没有任何一个人脑子里装着整个Claude Code的完整心智模型，而且他们觉得根本没人需要装。
仔细想想真是这么回事，天天盯着别人改一行文案、调一个参数的diff逐行看，根本学不到什么系统架构。在他们团队，准备动手改某个模块之前，直接让Claude针对那块代码当天的最新现状写一份局部切片说明（explainer），几分钟就能摸清来龙去脉，复杂的逻辑还能让Claude顺手画个可视化小组件（artifact）辅助理解。
再加上大家平时都在公开的Slack频道里协作，AI写代码的成本又极低，哪怕有人在讨论串早期提出完全不同的方向，作者直接把PR关掉推倒重来，一点都不会觉得心疼。
把繁琐枯燥的找茬活交给机器之后，工程师的脑子终于可以省下来，只盯机器干不好的五件事。第一件是决定这个功能到底该不该做，他们内部有个早就解决了审查排队问题的团队，到现在只要遇到跨团队提过来的PR，依然坚持人工审一遍，目的就一个，先问一句"咱们真有必要做这个吗"。
除此之外，高危和兜底的活也依然握在手里。计费、自动更新器和CI配置这些一旦出事就是大雷的高危代码，必须由人来把关；那些会被整个代码库到处抄作业的架构模式，也得由人来审。到了准备合入的阶段，人类主要负责核查测试输出、命令返回值和截图这些实打实的证据，如果谁说不出自动检查会漏掉什么，那就老老实实人工深审，最后再由人类为上线后的结果兜底。
博客最后引用了一位内部同事的原话，特别适合送给现在还在死磕人工逐行看diff的团队："放慢速度确实能降低错误率，但那主要是因为你什么都少干了。我们更愿意在发现和修复问题上变得更快。"
本文首发于微信公众号「AI编程实验室」，阅读原文