Anthropic 日合并量五个月涨十倍，瓶颈落到评审与合并

今年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；到 9 月，这个数字超过 3 万。五个月里翻上去的是产出，挪走的是约束：卡住他们的不再是写不出代码，而是评审、合并和 CI 这一圈为人设计的基础设施。这个位移对买方有一个直接后果——评估智能体产能时要问的，不是模型多强，而是每一步放行有没有留下可读的证据。

他们自己把数字链报了出来

数字来自 Anthropic 工程博客 10 月 13 日的一篇文章，署名是源码控制团队的七个人。他们把合并量按月排开：2026 年 5 月日均约 2,500 次，9 月日均超过 3 万次。这是公司自己的口径，不是第三方统计，但它的单位是时间——时间比满意度调查更容易被核对。

为了扛住这个量，他们把整个 monorepo 从 git 迁到了自建的版本控制系统，内部代号 Scion，用了五个月。迁完之后的规模读数是：主分支历史约 100 GB，压缩后的工作副本超过 25 GB；CI 每天要做约 2,500 万次 checkout；按朴素抓取折算，每天 600 PB 以上的 git 流量；高峰期同时跑过数百个内部 git 镜像。

他们还顺手补了三样东西：一套代码评审界面、一套代码搜索、以及源码控制里的身份与权限管理。这三样恰好落在人在这条管道上停留的位置——读改动、找历史、决定谁能推。

这些数字描述的其实不是模型变强，而是产出流过去之后，管道自己变成了要解决的问题。

他们自己也是这么定性的：编码已经不再是构建系统或做研究的瓶颈，现在的瓶颈是为人的尺度设计的开发者基础设施，也就是源码控制、构建和 CI。文章末尾留了一句自我限定，说这个工作负载并不常见，多数组织短期内不会遇到同样的问题。

为什么卡点必然落在评审这一类环节

一次代码变更要进入主干，得穿过三道闸门：有人读它，有人判定它能不能进，机器再按规则放行一次。生成的成本降下来之后，约束就漂到了这三道闸门上，因为它们的容量都不跟产出同速增长。

人一天能认真读的改动是有限的，这个上限由注意力而不是工具决定。评审的判据要么写在文档里，要么只存在于资深工程师的脑子里，前者更新慢，后者不可复制，一旦这个人休假，闸门就只剩流程。CI 的时间预算来自机器配额，扩它要花钱、要走采购周期，还要有人维护。

把这三句话合起来，十倍这个形状就有了由来：产出可以指数上升，放行只能线性上升。两者的差额不会凭空消失，它会堆在队列里，变成等待时间、变成合并冲突、变成先合进去再说的例外。

由此可以给出一条可检验的预测：智能体产码比例越高的团队，最先坏掉的不会是编辑器或者模型额度，而是评审队列和 CI 时长。这条预测什么时候会被推翻？当某一段放行环节的输出变成了机器可判定的条件，而不是人的判断。

三道闸门分别归谁负责

闸门的位置决定责任归谁，而这一点经常被混在一起谈。读改动归写代码的团队自己，容量问题落到工程经理的排期上；判定能不能进主干归评审人，判据最终要落到架构或技术标准上；机器放行那一层归平台团队，CI 时长是他们的服务指标；而这次通行凭什么被允许这条记录，谁都不愿意让别人替自己写。

分不清责任有个典型症状：评审变慢就先加人，CI 变慢就先加机器。两类开支都不小，队列长度却纹丝不动，因为闸门数量没变、判据没变，只是每道门里的人和机器变多了，沟通成本跟着涨。

更可执行的拆法是按输出来定人：谁的输出是一份可执行的判定，谁就对这个环节负责。评审如果产出一份写下来的判据——这一版为什么通过、怎么验证的——评审人对此负责；流水线如果能产出一条硬门禁，平台团队对这条门禁的误报率负责。

换到采购上，问题的主语变了

对 AI 应用负责人和数字转型负责人来说，这个位移把选型问卷的第一题换掉了。原来的第一题是用哪个模型，现在更值得问的是哪一段被装上了表。

两者不是同一类问题。前者比的是生成质量，后者比的是产出经过管道时，每一步能不能被读到、能不能重放、能不能在半年后调出当时凭什么放行。

具体到动作，可以向供应方问四个问题：这次变更的放行条件写在哪一份文件里；谁签字，依据是什么；流水线里有几条硬性门禁，各自拦下什么类型的改动；如果半年后有人问第三个版本凭什么进主干，多久能调出答案。

这四个问题背后是一张可以照着填的清单：变更标识能不能从需求追到线上；每次放行的判据是可执行的文件，还是口头约定；门禁失败时的处理人是谁；放行记录存在哪里、保存多久；谁能改判据，改的时候留下什么；跨平台的做法是否一致。这张清单不需要新工具就能开始填，填不出来的空格就是当下的风险位置。

它们都不是安全审计题，它们是产能题。答不出来的组织，产能上限由评审队列的长度决定，而不是由它买了多少模型额度决定。

我们自己的验收方式

我们自己的运行方式是把完成写成可执行的检查。一个改动的完成判据不是模型说做完了，而是一串命令跑出来是什么：构建必须通过，验证脚本必须输出通过，线上页面必须真的换成新内容，结构化数据必须存在。模型的自述不算完成条件。

这套办法看着笨，但它换来一个可核对的位置。任何一次已完成的声明，都能被另一个不写代码的人用同样的命令重跑一遍；跑不通，声明就不成立。这也是我们判断产能读数该来自放行环节、而不是生成环节的原因。

它的能力边界也要说清楚：这套检查只回答这一步凭什么被放行，不承诺别的东西。它不是监控，也不保证在动作发生的那一刻把它拦住——发现问题的时间和能把记录交出去的时间，本来就是两件事。

给自己量一次，只需要三个数

想判断自己有没有这个问题，不需要新工具，先算三个数。一周里有多少次变更进入主干；这一周评审环节的平均等待时间；同一周流水线的平均时长，以及它重跑了多少次。三个数放在同一张表上，就能看出产出增速和放行增速是不是同一条曲线。

第二步看分布，不要只看均值：等待时间的中位数和 p90 差多少。中位数两小时、p90 三十小时，说明少数变更被卡了很久，而那些往往是最难、最重要的改动——它们最不容易一次通过，也最容易被队列反复推迟。

第三步回答一个问题：如果把产码量提高一倍，哪一个数会先坏。答案通常不是模型额度不够，而是上面三个数里的某一个。找出那一个，就找到了下一步该投人的地方。

评审变慢的成本，最后花在哪一行

评审和 CI 变慢，账面上不会立刻出现一行叫这个名字的成本。它出现在别的地方：交付周期变长、发布窗口被占用、更容易为了赶时间而放行没有验证的改动，以及同一个季度里被反复推迟的那几条最重要的改动。

把这些加总有个笨办法：把等待时间换算成人力。一次评审平均多等一天，乘上排队中的改动数，再乘上每个改动背后等它的人，得到的就是一周里被锁住的工时。这个数通常比 CI 的机器账单更大——机器账单在报表上看得见，等待看不见。

这也解释了为什么先加机器、先加人常常不解决问题：机器和人作用于闸门内部的执行速度，而队列的长度由闸门数量与判据决定。判据不清楚，闸门再快，放行还是得一次一次重新讨论。

还有一层组织后果：当等待变成常态，团队会发展出自己的绕过方式——把一个改动拆成几个小提交、在评审前先私下对齐、或者把改动塞进已经批准的那一批里。这些做法短期有效，长期会让判据更模糊，因为绕过本身不留下记录。

放行条件写清楚之后，产能会怎么变

这里有一个反直觉的推论：放行条件写得足够清楚时，产码量上升不一定会让评审变慢。能被自动验证的改动不占用人的注意力，只有少数真正需要判断的改动才排队。反过来，如果每一次放行都要人来判断，那么产量每上升一档，队列就跟着长一档，多买模型额度只是把队列变得更长。

三个数的方向比它们的精度重要。如果放行增速明显低于产出增速，而且等待时间的中位数与 p90 的差距在扩大，那么模型换到哪一代，交付速度都不会有实质变化。

对买方来说，这三个数还有一个用处：它们是谈判材料。拿着等待时间的中位数和 p90 去找供应商，问的问题会变成闸门能不能被自动验证，而不是模型能不能再快一点——前者有上限，后者没有。

别把这个个例当成趋势

有三处需要收住。第一，Anthropic 自己声明这个工作负载不寻常，公开的自我限定是不认为多数组织近期会遇到同样的问题；引用时不能把一家公司的经验直接当成行业读数。

第二，600 PB 是他们按朴素抓取折算的自家口径，不是行业统计；五个月十倍说的是他们自己的合并量，不是市场总共产出了多少代码。把公司读数当行业事实，是这类文章最常见的失真方式。

第三，多数企业的卡点可能还停在更前面一步：评审的判据没有人维护，或者根本没有人定义过什么算通过。在这种组织里，先扩产码量只会让队列更长，不会让交付更快。

换句话说，可迁移的不是那个十倍，而是约束位置会漂移这件事本身。产出翻十倍的时候，先去看管道上哪一段还只有人、没有表。

我们的判断

我们的判断是：当智能体开始承担产码，评估产能的问题已经从模型多强，变成了放行环节有没有可执行的条件。模型评测分数衡量的是生成能力，它测不到管道的容量，因此也无法预测一个团队能交付多少。

由此有三条明天就能做的事。挑一条流水线，把什么算通过从口头标准改写成别人也能跑的检查；给评审结论定判据，明确谁签、签什么、签名留下什么记录；把放行记录接到变更本身，让半年后的提问能顺着一次改动查到当时的依据。

留给买家的问题是：如果明天你们的合并量翻十倍，先坏的是哪一步？如果答案只能说到应该会有点乱，那说明放行条件还没有被写下来——那正是该先动手的地方。

参考来源

Anthropic 工程博客《Redesigning source control》，2026-10-13（本文全部外部数字均出自该文正文，属公司自述口径）