九成代码AI写，谁来审？Claude Code亮出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团队看来，「有没有人读过这段代码」是个不够精确的问题。 真正的问题应该是： 这次改动可能出什么错，如果出错应该由哪一道检查阻拦？ 人工审查之前 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每次交付都回答三个问题。 第一，怎么