Claude Code团队把代码评审交给机器：合并量翻倍，回滚比例反降四成

代码评审的重心从人工逐行阅读转向机器先行筛查，人类时间集中到只有人能做的判断上。 此前评审是代码写完后在拉取请求末端设的一道关卡，需要同事逐行阅读；如今评审像写作时的拼写检查一样持续进行，多数改动在被要求人看之前已由Claude评审并修复至少一轮。 6月至9月，Claude Code代码库合并的拉取请求数量翻倍以上，同时需要回滚的比例下降超过40%。

每个拉取请求在人类查看前都会得到一次Claude评审，它对照整个仓库和该请求声明的意图，判断改动是否解决问题、是否契合系统、是否破坏其他部分。 研究预览版上线时，内部拉取请求中获得实质性评审意见的比例从16%升到54%；超过1000行的大改动多数能查出问题，小改动多数干净返回。 多个智能体同时查找缺陷，再由另一组智能体对每条发现投票，只有足够多成员认可才发布；仅涉及风格、诊断或清理的发现被丢弃，这些过滤在团队自己的拉取请求上做过A/B测试。

人类批准的数量由改动本身的风险等级决定，而不是由作者决定。 文档、文案等低风险改动在自动评审和安全检查通过后无需人类批准；普通产品改动以及缓存、自动更新器、系统提示等敏感区域需要一人；最高风险代码和固定路径需要两人。 一个分类器读取改动并判定风险等级，第二个分类器判断该改动是否在等级之外仍需另一人；只有仓库信任名单上的作者走较轻路径，智能体的批准永远不能替代人类批准。

这套流程针对Claude Code自身的仓库，包括命令行工具、桌面与网页应用和移动应用，作者是Anthropic内部团队。它衡量的是人类批准数、人类评论数和拉取请求等待人类的时间，并以回滚率和事故率作为护栏。文中给出的采用步骤面向愿意让智能体提交拉取请求的团队，从单个仓库开始，先调优REVIEW.md数周再扩大范围。

团队尚未设置断路器，无法在回滚或事故指标上升时自动收紧批准要求，工程师希望在更多代码走向零人工合并之前补上。评审收敛仍是问题：一个命令行拉取请求曾在一夜之间经历五十多轮评审与修复，作者才叫停；对评审反复标记的代码做git blame显示约59%是评审首轮就已存在的旧代码。团队也承认，机器承担大部分阅读后，如何让成员理解代码库还没有正式流程。