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先拿出验证结果
一次改动要过六道检查，最后还有一张安全网。
第一关：合并请求之前。 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。
审查的本事，一半在找问题，一半在知道何时收手。
多层审查，是不是就万无一失？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倍。
第二，会影响哪里？ 改动涉及哪些用户、数据和权限。让AI给汇报工具加一个共享功能，就得问清楚：链接谁能打开，打开后能看到什么。
第三，出错怎么撤回？ 能不能一键关掉新功能、退回上一版？动手前先提交存档，每次改动尽量小。先能撤回，再谈少审。
除了这三个问题，再养成三个习惯。
第一，换个「脑子」复审。 写代码的会话最容易对自己的bug视而不见。开一个新会话，或者让子智能体用全新上下文复审，本地的/code-review和/security-review命令也能直接跑。
第二，给改动分档。 改文案、调样式，检查通过、实际效果确认后再合并；涉及登录、付款、删除数据，就要人工细查关键逻辑，并补上针对性测试。先严一点，等验证和回滚流程跑顺了，再逐步减少低风险改动的人工审查。
第三，三轮不过就换思路。 AI改了三轮还在原地打转，别催它第四轮，先问问方案本身是不是错了。
最重要的一点：AI说「通过」，不等于你已经完成验收。代码是你让它写的，上线后的结果，也得由你负责。
Claude Code团队的目标，是让多数PR至多一人介入，同时守住回滚率和事故率。人的注意力，要更多地放在判断风险、确认检查是否充分，以及出错后如何补救上。
人可以不读每一行代码，但每一次上线，都必须有人负责。
参考资料：
发表于 4 小时前
|
查看: 9|
回复: 0
/1 
