90% 的代码是 AI 写的，审查怎么办：Claude Code 团队的六层流水线
Claude Code 团队公开了自己的代码审查流程：90% 的代码由 Claude 写，合并 PR 数量翻倍、回滚率却降了 40%。他们没有砍掉审查，而是把阅读搬到机器上，按风险分级保留人类审批——以及那些只有人才能做的决定。
Claude Code 团队这周写了篇博客，公开了他们内部的代码审查流程。开头就甩了一个数字：仓库里大概 90% 的代码是 Claude 写的。从 6 月到 9 月，合并的 PR 数量翻了一倍多，需要回滚的比例反而降了 40% 以上。HN 评论区的第一反应是算另一笔账：如果每行代码都靠人工逐行读，这么快的速度根本审查不过来。我请来老朋友陆维舟——之前在大厂带过平台工程，管过上千人规模的代码评审 infra，现在自己折腾 AI 编程工具。聊聊"人还审不审代码"这个问题，到底被他们改造成了什么样。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 维舟，先确认一个前提。文章说 Anthropic 单体仓库每天落地的变更，从 5 月的 2500 个涨到 9 月的 3 万个。评论区有人直接说不信："30 thousand changes merged per day? no." 你信吗？
陆维舟： 信的，但要理解它是什么东西。这个数字里绝大部分是 AI agent 产生的中小改动——修个配置、改个文案、挪一行类型。关键在第二句：PR 翻倍、回滚下降 40%。这说明他们把"不出事"从靠人盯，换成了靠流程托。如果回滚率同步涨，那这个 3 万就是灾难。
小听： 文章里我最喜欢的一句话是：问"人看没看代码"，是在用一个不精确的代理指标代替真正的问题——"这处改动可能出什么事，哪一层检查（人工或自动）最该去抓它？"这句话戳中你了吗？
陆维舟： 戳中了。这是对审查的重新定义。传统审查把审查当成路尽头的关卡：写完代码、开 PR、等同事。现在他们把它做成了拼写检查——写的时候就连续运行。大部分改动在人类被要求看之前，已经被 Claude 审过至少一轮，常规错误在那之前就修掉了。省下来的人类注意力，只花在更高层的问题上。
小听： 具体拆一下。他们讲了六层：PR 之前的自验证、每个 PR 的 AI 评审、可拦截的安全评审、自动检查、按风险分级的人类批准、合并队列加灰度，最后是快速回滚。哪一层你觉得是普通团队最该抄的？
陆维舟： 第一层。他们有个习惯我觉得是精髓：给 Claude 一个能跑的东西——测试、构建、或者拿设计图对比的截图——让它"展示输出"而不是"说做完了"。然后再用一个带着全新上下文的子 agent 去看 diff。这来自他们那份最佳实践指南。Boris Cherny 管这叫"给 Claude 验证自己工作的方式"，他估计这能把最终结果提升两到三倍。小团队抄不起六层，但"要求 agent 拿出可验证的证据"这条，今天就能用。
审查从路尽头的关卡，变成了路上的拼写检查。
小听： 第二层有个细节：AI 评审的每条发现，要先经过其他 agent 的投票，足够多票认为是真问题才发给人。评论区有人担心误报多了会怎样——agent 作者收到 nit 会老老实实再提交一轮，人收到 nit 一眼就划过去了。误报成本在 agent 时代变高了。
陆维舟： 他们自己也被这事咬过。有一处我印象很深：一个 CLI 的 PR，一个 agent 作者和一个 agent 评审者来回打了五十多轮，整整一夜，最后是作者自己叫停的。他们去 git blame 查，发现评审者 59% 的时间在翻旧账——标的都是第一轮之后就存在的老问题，根本不是新 bug。从那以后他们立了三条规矩：三轮封顶，之后让作者停下来重新想方案；重审只看 diff；标出 bug 的类别，让作者一次性修掉整类问题。这叫"审查必须收敛"，agent 和 agent 之间是会无限内耗的。
小听： 人类审批那一层也挺狠：按风险分级。低风险（文档、文案、flag 后面的增量改动）自动检查全绿就不用人；中风险一人；高风险两人。而且"改动定级别，不看作者是谁"——一个分类器读改动定风险等级，另一个分类器判断这处改动要不要额外加人。连可信作者名单都有。
陆维舟： 对，而且有几条硬线：agent 的批准永远不算人类的名额；自动评审可以放行低风险改动，但填不了"需要人"的那个坑；一次批准只管一个 commit，agent 又推了新提交或者有人手动解了冲突，批准作废重来。最妙的是"谁指挥 agent，谁就是 reviewer 之一"——你让 agent 写的 PR，你本人算作要求的审批人之一，跟你自己手敲的代码一个待遇。权责对等写得很死。
小听： 评论区最辣的质疑是关于安全的："安全评审的发现可以用'误报'的理由关掉"——有人担心，关键发现被随手 dismiss 掉，回滚率好看的同时，安全漏洞可能在悄悄变多。你怎么看？
陆维舟： 这是个真问题，他们自己也留了口子。文章里承认：现在还没有"熔断器"——当回滚和事故指标波动时自动收紧审批的东西。工程师们说，在更多代码走向"零人类合并"之前，他们想要这个。所以这套流程的诚实之处在于，它把没解决的部分也写出来了：检测和回滚是最后一层，flag 可以不开 deploy 就关掉，有 on-call 轮值，但"自动收紧"还没做。回滚率降 40% 是成绩单，不是免检证明。
小听： 还有一个评论我觉得代表了很多人的心态："我还是改不掉逐行审代码的习惯，总能看到冗余、重复、过度设计的架构，不看觉得不负责。"这是不是说明，这套东西只适合 Anthropic 这种体量？
陆维舟： 恰恰相反，我觉得这句话暴露了传统审查的第二个职能——文章里也提了：审查不只是抓 bug，还是团队共享上下文的方式。读同事的 diff 是你理解代码库怎么拼起来的主要途径。如果机器把阅读全拿走了，人对系统的理解会断层。他们现在的做法是：夜里让评审 agent 去扫存量代码，提前抓老 bug；但"要不要做这个功能""这个架构会不会被后人抄错"这类决定，明确留在人手里。逐行审的习惯可以放，但"读证据"的习惯不能放——测试输出、跑了什么命令、截图、评审者的发现，看不懂这些会漏掉什么，就别点那个快速批准。
小听： 最后问个扎心的。评论区有人用 Pangram 测了这篇文章，说好几段被识别为 100% AI 写作。连讲代码审查的文章本身都是 AI 写的，这讽刺吗？
陆维舟： 我倒觉得这是他们想证明的闭环：重点从来不是"谁写的"，而是"哪一层检查对它负责"。人写的烂代码和 AI 写的烂代码，在六层流水线面前是平等的——都会被同一套机器读、同一套投票筛、同一个风险分类器定级。真正的问题永远是：出事的时候，谁拥有这个结果。他们的答案是人。这句话对所有用 AI 写代码的团队都成立：你可以把阅读外包出去，但不能把 ownership 外包出去。
这篇文章最值得带走的不是六层这个数字，而是一个换位：别再问"人看没看"，去问"哪一层在为什么负责"。审查的稀缺资源从来不是机器算力，是人的时间和注意力——而注意力最该花的地方，是机器最不擅长的那几个决定：做不做、敢不敢、以及出事了谁负责。本文观点仅代表访谈角色设定，原始讨论见参考链接。