新智元报道
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团队看来，「有没有人读过这段代码」是个不够精确的问题。
真正的问题应该是：
这次改动可能出什么错，如果出错应该由哪一道检查阻拦？
人工审查之前
AI先拿出验证结果
一次改动，要过六道检查，最后还有一张安全网。
第一关，在创建合并请求（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团队有条规矩：你合进去的代码，出了问题，通常由你来修。
点下批准之前，审查者得说清楚：这些检查验证了什么，还有哪些风险没有覆盖。
说不清，就别急着点通过，先补上必要的审查。
AI审查也会失灵
自动化审查，也会把自己卡住。
一个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变得健忘、开始重复，使用工具也变得反常。这个 bug直到4月10日才修复。
闲置后本应只清理一次旧推理，实际却每轮持续清理；红框标出误删内容。
官方4月23日的复盘承认：
这个改动穿过了多轮人工和自动审查，单元测试、端到端测试、内部试用全没拦住，光确认根因就花了一周多。
转折在复盘里。
团队用Code Review重审了出事的PR，在给足相关仓库上下文时，Opus 4.7找到了这个bug，Opus 4.6没找到。
这次回测说明，模型能力和上下文完整性，都会影响检出结果。于是他们让审查能引入更多仓库。
如今，每一次事故，都会变成一道考题。
团队把PR收集起来，由熟悉代码的工程师逐个确认其中的bug，整理成一套考题。
审查器每天对着这套考题跑分。每次调整提示词、工具或模型，也要用它检验效果：成绩没有提高，这次调整就不采用。
团队也没把话说满。
改动上线后，仍要靠开发者、值班人员结合数据看板发现异常。
根据回滚率等指标自动收紧审批的「熔断」机制，还没有建好。工程师们希望先补上这道保险，再让更多改动走零人审批。
审查难免漏检，发现和补救也要跟上。
一位Claude Code团队成员这样解释：放慢速度确实能少出错，但主要因为你什么都做得少了。所以他们更愿意把力气花在更快发现问题、更快修复上。
一个人用AI写代码
要验收什么
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至多一人介入，同时守住回滚率和事故率。
人的注意力，要更多地放在判断风险、确认检查是否充分，以及出错后如何补救上。
人可以不读每一行代码，但每一次上线，都必须有人负责。
参考资料：
https://claude.dev/blog/solving-code-review-at-anthropic/?utm_source=chatgpt.com
https://www.anthropic.com/research/april-23-postmortem?utm_source=chatgpt.com
https://x.com/bcherny/status/2007179861115511237
编辑：元宇
