Anthropic 说，内部每天合并的代码改动四个月里涨了十多倍，git 成了最大的瓶颈，七个人用五个月自研了一套叫 Scion 的版本控制把它换掉。这些数字目前只有 Anthropic 自己的说法。
Anthropic 10 月 13 日发的工程博客，开头就写：在 Anthropic，写代码已经不是做系统、做研究的瓶颈了。
同一篇文章往后翻，讲到参与这个项目的工程师在干什么，又写：很多时候，工程师的角色是对 Claude 说「不」。
Claude 写代码快到让公司的开发基础设施成了瓶颈，他们又用 Claude 在五个月里造了一套新的。人在这个过程里，很多时候是负责拦住 Claude 的那一方。
◇ ◇ ◇
2,500 到 30,000
按博客的说法，Anthropic 的大仓库（monorepo，全公司代码放在一个仓库里）在 2026 年 5 月平均每天合并约 2,500 个代码改动，到 9 月超过 30,000。
两根柱子对比，5 月约 2,500 次每天，9 月 30,000 次以上
他们还写了仓库本身有多大：main 分支的历史接近 100 GB，压缩后的一份工作副本超过 25 GB；光是 CI 每天就要检出代码约 2,500 万次，还不算开发环境、agent 沙箱和研究任务。如果每次都不加优化地全量拉取，一天会超过 600 PB。为了扛住，他们最多时在内部跑了几百个 git 镜像。这几个数里我会盯着 2,500 万次检出看：来取代码的主要是 CI 和 agent。
有人从博客那张图上把数据读了出来。scaling01 的估算是：日合并量翻一倍的时间，从 1 到 5 月的 67 天，缩短到 5 到 7 月的 41 天，再到 8、9 月的 20 天；周末合并的占比从约 7% 涨到约 18%。这些数是从图上量出来的，官方没有给。周末占比翻了一倍多，说明周末在提交代码的，多半不是人。
以上数字全部来自 Anthropic 一家。SecondSource 在简报里专门标注，合并次数没有任何外部测量。600 PB 也是一个假设值，HN 上已经有人指出这一点。
◇ ◇ ◇
git 的默认假设，碰上了永远在线的 agent
git 能成为标准，很大原因是它的设计：每一份克隆都是完整的仓库，断网也能看历史、看 diff、切任何版本。
打个比方，git 像给每个员工发一整套百科全书，出差到没网的地方也能翻。员工几十个人时这很好用；可当「员工」变成几万个随时开、随时关的 agent 和 CI 任务，每个都要先搬一整套 25 GB 的书，书一天还要更新三万次，光发书就能把仓库压垮。
左边每个 agent 都扛着一整份仓库副本，右边一群轻量客户端向中间的服务器要文件
Anthropic 的判断是，他们其实一直把 git 当成集中式系统在用：只有一份权威副本，而几乎所有客户端都是天生在线的 agent 和任务。git 为离线设计的那部分，反倒成了扩容的负担。于是他们问自己：如果从一开始就假设 agent 永远在线，版本控制该长什么样？
◇ ◇ ◇
Scion 换掉的几条假设
他们给新系统定了几条原则，参考了 Google 的 Piper 和 Meta 的 Sapling 这两套大仓库系统。换成大白话：
后面三行都从前两行推出来，客户端不存完整仓库，提交在服务器上做，其余跟着变。
落到架构上是三层缓存：每台机器一个 scion-daemon，每个区域一组 scion-cache，最上面是权威的 scion-server。我很喜欢其中一个设计。所有数据按内容寻址，存进去就不再变。东西永远不变，任何一层就都能放心缓存，不用互相确认，这和 CDN 缓存图片是一个道理。
从下到上三层：scion-daemon、scion-cache、scion-server，最上面是 Spanner，旁边标着命中率 99%+
博客给的效果：每一层缓存命中率都在 99% 以上；整套 Scion 基础设施用的 CPU 和内存，比原来那几百个 git 镜像小 200 倍；CI 和研究任务检出代码从几分钟变成几秒，光 CI 就省出了 25% 的 CPU 算力。
Simon Willison 读完的评价是：听起来像把 Subversion 那种集中式版本控制重新发明了一遍。我觉得这话没说错。git 打败 SVN，很大一部分原因是人会离线；写代码的主力换成不会离线的程序，这条理由就弱了很多。
◇ ◇ ◇
七个人，五个月
做 Scion 的团队一共 7 个人。五个月里，他们做了 Scion 和代码审查工具 Antique，外加半打相关系统，把整个大仓库从 git 迁了过去；同一段时间，每天的合并量涨了 10 倍。博客说，放在过去，这种迁移要很多工程师、好几年。7 个人、流量边迁边涨十倍，这比前面那些性能倍数更有说服力，因为它说的是 Claude 到底替人干了多少活。
博客里举了一个例子。今年早些时候，团队基本靠手写做出了第一版「git 导入 Scion」的流水线，自己觉得写得不错。后来内部拿到 Claude Mythos Preview 的早期版本，让它把整条流水线重写一遍，没给别的指示。新版本内存少用 20 倍，速度快 4 倍，原来那些关于导入顺序和数据结构的隐含约束都保住了。
作者之一在 HN 上补充说，迁移期间两套系统并行，这条导入流水线循环跑了好几个月，所以快 4 倍是真省了事。
博客还写，参与项目的工程师现在都认为 Claude 写代码比自己强。这是 Anthropic 员工评价自家模型，听听就好；下一节说明，他们并没有因此闲下来。
◇ ◇ ◇
工程师在干什么
博客说，工程师提供的是对系统之间关系和设计取舍的理解，而且「很多时候，工程师的角色是对 Claude 说不」。他们举了两种情况。
一种是 agent 有时会为了迁就一个本不该被允许的模式，去违反系统的核心约束。迁移时这种事尤其多：好几个系统想知道某个改动什么时候合进 main，做法是从头到尾线性扫一遍提交日志，没有去问代码审查工具。我的理解是，这种写法小仓库里能跑，到每天几万次合并就扛不住。
另一种来自对抗式审查，也就是让另一个 Claude 专门挑毛病。这招大体很有效，但有时会钻牛角尖。有一次审查对另一个内部服务过分不信任，结果 Claude 加了一堆多余的校验，系统变复杂了，要靠人把它拉回来。
一位工程师举着写着「不」的牌子，挡在一叠 Claude 生成的改动前面，旁边一个放大镜标着「审意图」
他们的审查方式也跟着变了。每个改动仍然有人审，审的是这个改动想干什么，逐行读代码已经读不过来。
用 Claude Code 做过稍大一点项目的人，多半都碰到过这两种情况：AI 为了「能跑」绕开你定好的边界，或者 AI 审 AI 时越审越保守，代码越堆越厚。Anthropic 内部也躲不开，他们的办法很朴素，就是人得清楚哪些约束不能碰，在它越界时拦下来。
◇ ◇ ◇
合并锁做不成，改让 Claude 盯盘
合并队列的做法，比 Scion 本身更出乎我意料。行业惯例是给仓库上一把全局锁，改动排队、测过再合，保证主干永远是绿的。Anthropic 说，在 agent 的规模下，他们没能有效复制这套做法：测试还没跑完，可能已经有几百上千个改动合进去了。他们改成合并之后、部署之前跑自动测试。代价是并发的改动会互相冲突，博客的说法是，Claude 修冲突通常比人发现冲突还快。
另一个做法他们叫「superfan」。团队在 Slack 里开了几个频道，每个频道让一个 Claude 死盯一个组件：有专盯 scion-daemon 的，有专盯 scion-cache 的，有专盯 Antique 合并队列的。这些 Claude 能看遥测和日志，博客的形容是，像一个闲得没事、一直刷图表找异常的资深工程师。他们也有传统告警，但博客说，superfan 能发现一些细微又新鲜的问题，相比之下告警显得太单一。
三个 Slack 风格的频道卡片，分别写着 scion-daemon、scion-cache、Antique merge queue，每个里面一个小机器人盯着折线图
superfan 门槛很低，普通团队也能抄：一个能看日志的 Claude、一个专属频道，再给它划一块只归它管的地盘就行。
◇ ◇ ◇
反对的声音
HN 上这篇的讨论有 900 多条评论，质疑不少。
用户 amluto 觉得 30,000 次合并摊到每个员工头上并不算多，他怀疑 Anthropic 的问题其实在于很多改动牵扯面太大、太乱，再加上 git clone 太慢；他也不想要「每次提交都必须上服务器」的设计，在本地攒一堆小提交、整理好再推，是 git 和 jj 的核心价值。作者 nickg-anthropic 回复说，本地缓冲不是做不了，但那样客户端就得学会服务器会的所有事；Claude 是 Scion 最重的用户，而它必然在线，所以这件事不重要。
还有人担心别的公司会跟风，觉得自己也得造一个。这点 Anthropic 自己说得很直白：Scion 绝不适合拿来替代一般场景下的 git，只有真正巨大的仓库，要么几万工程师、要么成群的 agent 在疯狂写代码，才用得上；Anthropic 内部花在 token 上的钱，也远超一般公司愿意花的量。他们说 Scion 很难做成别的公司能用的形式，没有计划公开，想做的是和 GitHub、GitLab 和开源社区合作，把有用的部分带回 git。
他们给了一个时间判断：接下来 6 到 12 个月，这类问题会变得更常见。
◇ ◇ ◇
拿来对照自己的流程
大多数读者这辈子都不用自己造版本控制系统。已经在用 Claude Code、Codex 这类工具写代码的，可以拿自己的流程对一对这几条。
- ◆
看看瓶颈挪到哪了。代码写得快了以后，卡住你的可能是测试跑得慢、部署要手动、审查排不过来。把一天里「等」的时间记下来，比再换一个更强的模型管用。 - ◆
把不能碰的约束写成检查。Anthropic 的工程师要一次次对 Claude 说不。个人项目里，这类规则光写进 CLAUDE.md容易被忽略，能写成测试或提交前检查的就写成检查。Geoffrey Huntley 前两天分享过一个做法：agent 总绕开他的诊断库，他没去改 AGENTS.md，而是写了个 pre-commit hook，发现直接调用就让提交失败，并提示 agent 改用诊断库。 - ◆
先审意图。改动多到读不过来时，先问这个改动要解决什么、有没有越过哪条边界，再决定要不要细看代码。 - ◆
给一个 Claude 一块专属地盘。让它只盯一个服务的日志或一个页面的报错，比让一个 Claude 什么都管更容易看出问题。 - ◆
留意 AI 审 AI 的过度防御。让 Claude 挑毛病时，它可能为了不存在的风险加一堆校验。看到改动越来越厚，停下来问一句：这个防的是真实发生过的问题吗？
30,000 这个数没人能核，Scion 你也用不上。这篇博客的用处在于，它把 AI 写代码以后人在干什么，写到了具体的系统和频道上。