Claude Code 团队公开了他们审代码的做法：代码大约九成由 Claude 写，六月到九月合并的修改翻了一倍多，需要撤回的比例反而降了四成多。 这期用一摞带洞的奶酪片讲这套做法：每道检查都会漏，叠起来就很难漏，底下还有一张网兜底。 片中回答五个问题：哪些修改还要人看，AI 审 AI 会不会没完，审查的 AI 漏了怎么办，人不读代码怎么懂代码，出了事算谁的。人不再逐行读代码，时间花在机器做不好的判断上。 视频1: 英文版 视频2: 中文版

--- 文稿 --- Claude Code 团队的九成代码都是 AI 写的，他们是怎么审查代码的？ 如果 AI 替你写作业，一天写一千份，老师批得过来吗？写代码的公司，现在就碰上了这件事。 Claude Code 是 Anthropic 做的编程助手。它自己的代码，大约九成是 Claude 写的。Anthropic 全公司的代码库，九月份一天要合并三万多次修改（五月份还是每天 2500 次左右）。靠人一行一行看，根本看不过来。 可 Claude Code 团队说，从六月到九月，他们合并的修改翻了一倍多，需要撤回的比例反而降了四成多。看的人少了，错反而少了。这是怎么做到的？ 【什么是代码审查】 先说程序员平时怎么防出错。改完代码，不能直接放进产品，要先交一份修改申请，英文叫 PR（Pull Request）。同事一行一行看，挑毛病，点了头才能合并。这叫代码审查。 就像作文交上去，老师批过，才能贴上墙。 合并以后才发现出了问题，就得把修改撤回来。撤回得越多，说明漏掉的错越多。 【一摞带洞的奶酪】 Claude Code 团队觉得，“有没有人读过代码”，这个问题问得太粗。更该问的是：这一次修改可能出什么错？哪一道检查最适合拦住它？ 可以把每一道检查想成一片带洞的奶酪。每一片都能挡住一些错，也都有洞，会漏掉一些。好几片叠起来，洞很难对齐，错误就很难一路穿过去。最底下再铺一张网，真漏下去了，也能很快捞回来。 这一摞奶酪里，大部分片是机器。人的时间最珍贵，它花在两头：一头是审代码，一头是出了事去救火。只省前一头，救火的时间涨上去，等于没省。所以他们盯着两个数：人花了多少时间，撤回和事故有没有变多。 【跟着一次修改走一遍】 从作者的电脑到用户手里，一次修改走的是一条流水线。前面那几片奶酪，就排在这条线上。 上流水线之前：自己先验。 代码还在自己电脑上，没有提交。Claude 写完代码，要自己跑测试、编译、做代码规范检查，把结果摆出来。光说一句“做好了”，不算数。然后再派一个新的 Claude，它没看过刚才的过程，单独审一遍，就像写完作文请一个没看过的同学挑错。 一提交，就上了流水线。 这条自动化的流水线英文叫 CI（持续集成）。从这以后，每提交一次新改动，机器都会自动从头查一遍，不用谁去点。线上依次是： - 自动检查： 代码规范、类型、在各个系统上跑测试，再编译、打包。红了一项，就不能合并。 - AI 审查： 好几个 AI 同时找问题，再由另一组 AI 投票，票数够了才算真问题，按严重程度排好贴出来。每一条意见都得回应：要么改掉，要么写清理由关掉。它刚在内部上线时，一百份申请里收到实质意见的，从 16 份涨到了 54 份。 - 安全审查： 单独再查一遍。两种审查里只要还有一条没处理，申请就合并不了。 - 按风险批准： 要不要人看、要几个人看，由一个分类器按风险来定，下面单独讲。 合并：排队，再查一遍。 申请先排进一个队列，轮到它时，拿最新的代码，把它放进去，所有检查再跑一遍。因为两份各自没问题的修改，凑在一起也可能出错。 合并以后： 打包、发布也由流水线自动来做，这后半段英文叫 CD（持续交付）。新功能也不马上给所有人用，先藏在开关后面。这个开关英文叫 feature flag（功能开关）：新代码已经装进了产品，开关关着，用户就碰不到它；开关是一项设置，打开关上都不用改代码，也不用重新发版。打开以后，先给 Anthropic 自己的员工用，再分批发：先发到最新版，稳定版晚一步跟上。就算有问题，碰到的也只是一小部分人。 最底下那张网：盯着，随时撤回。 发出去以后，作者和值班的人一直盯着。新功能出了问题，把开关一关，用户那边马上就看不到它了；哪个版本整个坏了，就撤回，退到上一个好的版本；问题小、看得清，也可以直接修好再发。 撤回为什么快？一是每次修改都切得小，撤的时候只退这一小块。二是撤回本身也是一次修改，走的还是这同一条流水线，检查、打包、发布全是机器在跑。所以大多数问题，几分钟就能撤掉。网铺得牢，上面的奶酪片才敢少让人看几眼。 【哪些修改还要人看？】 看风险。 - 改文档、改文案、藏在开关后面的新功能，风险低。自动审查和安全检查都通过，就不用人批。 - 普通的产品改动，或者碰到自动更新这类敏感地方的，要一个人批。 - 风险最高的代码，要两个人批。 档位由修改本身定，跟谁写的无关：一个分类器读完修改，给它定档。 还有两条规矩：AI 的批准，不算人的批准；谁让 AI 写的代码，谁就算一个审查人，要为它负责。 放回奶酪里看：风险越高，人这一片切得越厚。 【AI 审 AI，会不会没完没了？】 真发生过。有一份申请，一夜之间审了改、改了审，五十多轮，直到作者出手叫停。 他们一查，审查反复指出的问题，约 59% 是第一轮就已经在那儿的老代码。人看到一条鸡毛蒜皮的意见，几秒就跳过了；AI 却会老老实实去改，于是又多一轮审查。 后来他们定了规则： 1. 最多审三轮。 2. 三轮之后，请作者退一步，想想思路对不对。 3. 过了头几轮，只审新改的部分。 结果，一轮就通过的申请，从 65% 涨到了 78%；要五轮以上的，从 8.9% 降到了 1.5%。 【审查的 AI 漏了怎么办？】 他们把过去闯过祸的修改都收集起来，请熟悉那块代码的工程师，标出错在哪一行。这就成了一本错题本，审查的 AI 每天做一遍。 改提示词、换模型，分数涨了才留下，没涨就扔掉。每出一次事故，错题本就多一道题。 审查反复挑出同一个毛病，就去源头改：写进给 AI 看的说明文件，或者加一条自动检查，下次就不用再提醒。奶酪片上的洞，就这样一个个补上。 【人不读代码了，还怎么懂代码？】 代码审查还有一件事：让团队里的人都懂代码。机器读了大部分，人怎么学？ 团队里没有人把全部代码装在脑子里，他们也觉得没必要。想弄懂哪一块，就让 Claude 专门为那一块写一份讲解，几分钟就好，讲的就是代码现在的样子。 一行改文案的修改，逐行看也学不到什么。马上要动的那块代码，有一份讲解，能学到很多。 【出了事算谁的？】 团队的规矩是：你合并的，你负责。中小改动出了问题，通常由合并的人自己修。 这里的“负责”，不等于追究个人责任。让合并的人来修，是因为这次修改这个人最熟，修得最快。 事后复盘，不问是谁犯的错，只问一件事：这只虫，本该被哪一片奶酪拦住？找到那一片，再把那个洞补上。下次同样的错，就溜不过去了。 我的理解是，出了错不挨批，大家就不用藏着掖着，问题能更早摆到台面上。 敢这样做，还因为出错的代价被压得很小。修改切得小，好查也好撤；大多数错误，几分钟就能撤掉。 而且责任是大家一起担的。团队大多在公开频道里干活，谁都看得到别人在做什么，可以顺手接一把，也可以派一个 Agent 去补漏。 【你能用上什么】 你要是也在用 AI 写代码，有两件事现在就能做： 1. 给 AI 一份简短的说明（比如 `CLAUDE.md`），写清楚怎么跑测试、有哪些规则。 2. 交代码之前，在 Claude Code 里跑一下 `/code-review`。 这些数字都是他们自己公布的，也只是一个团队的做法。 【回到开头】 一天几万份作业，靠人一份份批，批不过来。他们叠了一摞奶酪片：每一片都会漏，叠起来就很难漏，底下还有网接着。 人不再逐行读代码，去做机器做不好的事：该不该做，危险的代码，架构，看懂证据，为结果负责。 他们的一位同事说，放慢速度确实能少出错，可那主要是因为你什么都做得少了。他们宁可更快地发现问题，更快地修好。 --- 资料来源： - Addy Osmani《How the Claude Code team does code review》（2026.10.15） - Anthropic《Redesigning source control at Anthropic》（2026.10）

原文里最传神的是：两个 agent 一夜 review 了五十多轮，最后作者叫停。人类暂时保住了一个岗位：你俩先别聊了。

curious which layer is actually the net at the bottom, production canaries and typed contracts, or just another human gate. if the writer and the reviewer share the same model family the cheese holes line up and stacking mostly adds latency, so wondering whether one checker is deliberately on a different stack

奶酪片这个比喻一下就懂了，视频也讲得清楚。先收藏，回头照着给自己的项目也叠两层检查

用一摞带洞的奶酪片来比喻，好有意思😄

这个就很离谱了，撤回率降了4层

九成 AI 写的代码还要叠三层检查才敢合 那一成人类估计全在擦屁股🤣

瑞士奶酪那段说透了，我们这边互审超3轮就手动掐

奶酪片这个讲法还能做成一个小练习：给同一个 bug，先让读者猜单元测试、AI 审查、灰度发布各能挡住什么。再揭晓它在哪一层漏过去，比只记住“多审几遍”更容易学会怎么补检查。

笑死，AI 审 AI 卡了一夜，回头一查快六成是第一轮就在的老毛病，人扫一眼就跳过的东西它非得改完

九成 AI 写、六月到九月合并量翻一倍多、撤回比例掉四成多——这组数比「AI 写得动」更硬。多层检查叠起来还漏，底下再加网兜底。agent 写速抬起来之后，审查分档和撤回率才是真正的产能上限。

该说不说，老师的视频做的真好啊😭

撤回率降四成，是审得严了还是每次改得少了。

九成代码 AI 写，回滚率还降了四成，这数据挺反直觉的。奶酪片这个比喻好懂，每层都漏，叠起来就不漏了

感谢分享，正头疼AI产出的代码应该如何验收。

奶酪片叠起来那段，关键不在每一片多严，是洞错开。AI审AI最怕的恰恰是同款洞对齐，同一套盲点互相放行。撤回率降四成，倒是比合并量翻倍更有说服力。

这种视频是怎么生成的呢

瑞士奶酪模型用在 code review 上挺贴切的，不过我最好奇的是第五个问题——出了事算谁的。工具链再完善，最后签字的那个人的责任并没有被稀释，只是从"逐行读"变成了"为整个审查体系的设计负责"。这个心智转换其实比工具本身更难，很多团队卡在这一步。

撤回率降四成这个数挺关键，好奇他们怎么划定哪些修改必须人看：是按目录风险分级，还是让审查的 AI 自己打风险分？我们小团队现在是碰鉴权和计费的目录强制人审，其余 AI 过两轮。

九成 AI 写，返工还少了四成——这结果是真反直觉

瑞士奶酪模型本来就是医疗安全领域的老工具，James Reason 提出的，医院一直用它分析用药差错。放到"AI 写、AI 审"上特别贴切。 我做医疗设备嵌入式的体会是：关键不是叠几层，而是每层的"洞"不能长在同一个位置。AI 审 AI 算一层，但它和写代码的模型往往有相同的盲区。医疗器械软件按 IEC 62304 分级，最高风险的 C 类改动，人审和可追溯这一层省不掉。 好奇他们是怎么界定"哪些修改必须人看"的？

“奶酪片叠加”这个比喻很到位：关键数据是合并量翻倍的同时，撤回率还降了四成多，说明瓶颈已从“写代码”转到“分层审查+兜底”。想追问：当人不逐行读代码后，新人对代码库的理解会不会出现断层？团队用什么方式补这一课？

能制作片子是真的好方便啊 可以把信息和评论都放在一起

所以还是整个AI研发的环境要先ready，ci，cd，才能使用AI 编程工具实现提PR就能AI自动研发了吧。关键就是搭建出这套环境了

一人工作室的真实版瑞士奶酪：我同时开着 PRD、剪辑软件和客服，三层都漏，最后靠客户那句"先这样吧"兜底。

哈哈，我也发了一篇

电力现场更怕这事 模型把调度逻辑编圆了 面试官还跟着点头 你们那张兜底网 实际拦下过几次翻车

九成代码都是 Claude 写的，撤回率反而降了四成多。人没被省掉，是从写代码挪到了守最后那张网。

叠检查最怕每层都在查同一类问题，漏的还是同一个地方。权限、数据库迁移这种不可逆的改动单独拎出来让人看，其余的再交给 AI 互审。

哥，你的视频有工作流或者 skill 吗，看起来效果真不错

奶酪片这个比喻好懂。详情页、客服回复其实也能这么叠，一个模型写一个模型挑刺，人最后只扫敏感词

ClaudeDevs 昨天发的 Code Review 正式版，管理员能按仓库选 Quick、Standard、Deep 三档。官推只写了 Team 和 Enterprise，个人订阅暂时轮不到