Claude Code九成代码由AI写，六层审查怎么兜底？
九成代码Al写，谁来审？ClaudeCode亮出6道关卡！
新智元报道
新智元报道
Claude Code 大约 90% 的代码，如今是 Claude 自己写的。
写代码的活儿交给了 AI，改动量随之猛涨。6月到9月，合进代码库的 PR 数量翻了一倍多。
放大到 Anthropic 整体来看，主代码库每天合并的改动在5月约为2500次，到9月已超过3万次。
代码堆成这样，人还看得过来吗？要是审查也一并交给 AI，它出了错又由谁来发现？
10月15日，Claude Code 团队把内部的代码审查流程公开了出来。按披露的说法，PR 数量翻倍的同时，需要回滚的 PR 占比反倒降了超过40%。
靠的是六层检查，再加一套发现快、回滚也快的兜底机制。
Claude Code团队给出的判断是，代码量到了这个地步，再指望逐行靠人看，已经走不通了。
审查并没有被砍掉。他们的做法是把读代码这件事大部分转给机器，让人从逐行过代码里退出来。
具体流程是：AI 写的代码在上线前先过测试，再接受 AI 审查和安全审查，最后依据风险高低判断要不要由人来点头。
在 Claude Code 团队看来，问「这段代码有没有人读过」本身就问偏了。该问的是另一件事：
这次改动可能出哪些错？真出错时，该由哪一道关卡把它拦下来？
一次改动得过六道检查关，末尾还设了一张安全网。
头一关设在创建合并请求（PR）之前。Claude 得把测试跑完、构建做完；改动牵涉界面时，还要截图跟设计稿比对。
然后另起一个子智能体，给它全新的上下文去审代码差异。它没参与写代码，任务就是专门挑毛病。官方把要求说得很死：Claude 必须把执行过的命令和输出摆出来，只回一句「测试全部通过」不作数。
普通开发者照样能学这一招：给 AI 派任务时，顺手把验收标准一并讲明白。
第二关才轮到 PR 上的 AI 审查。几个智能体同时找 bug，再由另一组投票核验，票数够了问题才会贴到 PR 上。至于只谈代码风格、诊断提示或代码清理的意见，会被直接过滤，发不到 PR 里。
这套审查 3月刚上线那会儿，拿到实质性审查意见的内部 PR 占比从 16% 升到了 54%。
第三关是安全审查。
团队内部有一套硬规矩：代码审查或安全审查提出的发现，只要还没关闭，PR 就进不了主干——要么把它修掉，要么把理由写清楚再关掉。
第四关是持续集成（CI）检查，覆盖代码规范、类型检查、各平台测试以及构建打包。哪怕改的只是一个普通命令行工具（CLI），在交到人手里审之前，也可能得先跑完几十项检查。
反复冒头的问题，会被沉淀成下一轮的检查依据。CLAUDE.md 用来记录项目约定，REVIEW.md 则告诉审查器该重点看什么、哪些地方可以跳过——这一回发现的问题，就成了下一回审查的经验。同一条意见被提到第三遍，就该把它写进规则里。
第五关是人工审批。这一关最关键，下一节会详细讲。
第六关是合并与发布。改动闯过前面几关之后，还得进合并队列排队。
轮到它时，系统会把它挪到主分支的最新版本上，所有检查重新再跑一遍。这一步要防的，就是「单看各自都没问题，合到一起却出了问题」。
而且合并完成之后，新功能也不会立刻推送给全部用户。
新功能先藏在功能开关后面，只对 Anthropic 内部员工开放。这批人天天高强度地用，撞上问题的速度往往比外部用户还早。
功能开关相当于一个总闸，既不用改代码，也不用重新发版，开关一拨就能决定功能是开还是关。
最后还有一层兜底。一旦出问题，第一件事就是把总闸拉下。
团队按周轮班值守，每次事故复盘都绕不开一个问题：这件事本该在哪一关被拦住？
审查并没有消失，只是变成了贯穿开发、合并、发布各个环节的一道道检查。
前四关全部通过之后，第五关按风险分级来定这次改动需要几个人批准。
文档、文案、仅内部可见的功能，以及藏在开关后面的新增改动，都算低风险，只要自动审查和安全检查过了，就可以不走人工审批。
普通的产品改动，以及缓存、自动更新器、系统提示词这类敏感区域，则需要一个人。
风险最高的代码，以及少数被指定的路径，得两个人一起看。
低风险改动看起来已经不用人管了？
其实没这么简单。改动落在哪个风险档，由改动自身决定：先由第一个分类器读代码、判定风险，第二个分类器再判断要不要额外走人工审批。
代码所有者标出的敏感路径，加上全部CI工作流文件，都必须有人审。
轻量审批通道同样设了门槛：只向仓库「可信作者」名单里的人开放，名单之外的人想走这条路，得再找一个人点头。
指挥AI写代码的那个人，自己就占一个审查者名额，也得像亲手敲下这些代码一样，对这次改动负责。
零人审批，不等于没人负责。
功能要不要做、架构合不合理，这些由人来定；现有检查能不能盖住这次的风险，同样要人来判断。
也正因如此，Claude Code团队立了一条规矩：你合进去的代码，日后出了问题，修的人通常也是你。
点批准之前，审查者要把话说清楚：这些检查验过了什么，哪些风险还悬着没覆盖。说不清，就先别点通过，把该补的审查补上。
自动化审查有时也会把自己拖进死循环。有个CLI项目的PR，一夜之间来回跑了五十多轮审查和修复，最后还是作者手动叫停。
一个小毛病，人一秒钟就能略过，AI却不会，它会认认真真去改，改完再提交，于是又触发一轮审查。
团队拿git blame回查，发现审查器反复标出的问题里，约59%是首轮审查之前就已经存在的老代码。新bug它很少抓到，每轮不过是多翻出几个旧的。
之后他们定下四条规矩：
满三轮仍未通过，就提醒作者先退一步、重新想方案；前几轮过后，只审新增的改动；同类问题一次说清；提过的毛病不再重复提。
效果很快就出来了。
内部PR里，经过一轮审查和修复就通过的占比从65%升到78%；要跑五轮及以上的，从8.9%降到1.5%；平均审查次数从2.08降到1.32。复审规则调整后，一轮审查和修复后的通过率同样是从65%升至78%，平均审查次数同样从2.08降至1.32。
审查这件事，一半功夫在挑毛病，一半功夫在知道什么时候收手。
多层审查就能高枕无忧？并非如此。
Anthropic自己就拿出过一个反面例子。3月26日，Claude Code上线了一项优化：会话闲置时间超过一小时，就清理一次旧的推理记录。
可一个bug让它在恢复对话后的每一轮都执行清理。Claude因此变得健忘、开始重复，调用工具也出现异常。这一问题直到4月10日才被修复。
原本闲置后只该清理一次旧推理，实际却每轮都在持续清理；红框标出的就是被误删的内容。
官方在4月23日的复盘里承认：
这项改动穿过了多轮人工和自动审查，单元测试、端到端测试、内部试用都没能拦住，仅确认根因就花了一周多。
复盘中出现了转折。
团队用Code Review重新审查了出事的PR，在给足相关仓库上下文的情况下，Opus 4.7找到了这个bug，Opus 4.6则没有找到。
这次回测表明，模型能力和上下文完整性都会影响检出结果。他们随后让审查机制能够引入更多仓库。
如今，每一次事故都成了一道考题。
团队将PR汇总到一起，请熟悉代码的工程师逐一确认其中的bug，再把这些bug做成一套考题。
审查器每天拿这套题来跑分。一旦调整了提示词、工具或者模型，同样要用它来验证：如果分数没涨，这次改动就不采纳。
不过团队并没有把话说死。
改动上线之后，还得靠开发者和值班人员盯着数据看板，才能发现哪里不对劲。
按照回滚率等指标自动收紧审批的「熔断」机制目前还没建起来。工程师们的想法是先把这个保险补上，再让更多改动走零人审批。
审查总归会有漏掉的时候，发现问题和补救措施也得跟上。
Claude Code团队的一位成员是这么解释的：放慢速度确实能少出错，但主要是因为你干的活也变少了。所以他们宁愿把精力放在更快找到问题、更快修好上面。
AI审查只负责提意见，最后拍板的还是你。
所以别一开始就想着「不用看」。先让 AI 每次交付时把三个问题答清楚。
头一个是，验证方式是什么？
具体跑了哪些检查、结果如何、还有哪些情况没覆盖到。
Claude Code 的创造者 Boris Cherny 讲过，给 Claude 一个能验证自己的办法，或许是最要紧的事。他估计，这么做能让最终结果的质量达到原来的 2 至 3 倍。
Boris Cherny 的建议是让 Claude 自己去验证工作，形成反馈循环；按他的估计，最终结果质量可以提升到 2—3 倍。
第二个问题，会影响哪里？
这次改动牵扯到哪些用户、哪些数据、哪些权限。
比如让 AI 给汇报工具加个共享功能，那就得问明白：链接谁点开能进，进去以后又能看到什么。
第三，出了错怎么撤回来？新功能能不能一键关掉，能不能退回上一版。
动手之前先提交存档，每次改动尽量做小。先保证能撤回，再谈少审。
这三个问题之外，还有三个习惯值得养成。
先换个“脑子”来做复审。写代码的那个会话，最容易对自己留下的bug睁一只眼闭一只眼。
可以另开一个会话，也可以让子智能体带着全新的上下文来复查；本地的 /code-review 和 /security-review 命令直接就能跑。
再给改动分个档。改文案、调样式这类，检查过了、实际效果也确认了，再合并；碰上登录、付款、删数据，关键逻辑就得人工细看，还得补上针对性的测试。
一开始宁可严一点，等验证和回滚流程都跑顺了，再慢慢减少对低风险改动的人工审查。
第三招：三轮还不过，就换思路。AI改了三轮仍原地打转，别急着催第四轮，先想想方案本身是不是就错了。
最关键的一条：AI说“通过”，不等于验收已经完成。代码是你让它写的，上线后出了什么结果，责任还是你的。
Claude Code团队想做到的，是多数PR最多一个人介入，同时把回滚率和事故率守住。
人的注意力，应该更多花在判断风险、确认检查够不够，以及出问题后怎么补救上。
代码不必逐行看，但每次上线都得有人担责。
参考资料：
