每天合并3万条代码，git 先扛不住了：Anthropic 花5个月自研了一套版本控制系统

问个问题：当 AI 帮你写代码之后，你公司开发流程里最先崩掉的是哪一环？

Anthropic 刚给出的答案是：git。

10 月 13 日，Anthropic 工程博客发了一篇长文，讲他们怎么在五个月里自研了一套叫 Scion 的版本控制系统，把整个 monorepo 从 git 上迁走。起因简单粗暴：今年 5 月他们每天合并约 2,500 个代码变更，到 9 月，这个数字变成了 30,000 多。9 月 9 日那天，单日合并 30,401 条。

文章里有句话值得抄下来："在 Anthropic，写代码已经不再是瓶颈。瓶颈变成了所有为人类规模打造的开发基础设施：版本控制、构建、CI。"

▲ Anthropic monorepo 每日合并量，1 月到 9 月。注意 8 月有个"安静周"，然后曲线直接起飞（图源：Anthropic 原文，下同）

这篇我读完很有感触，挑重点讲清楚三件事：git 到底怎么被压垮的，Scion 的设计有什么不一样，以及一个 7 人团队怎么用 Claude 在五个月里干完了过去要几年的活。

一、git 是怎么被压垮的

先看一组数字。Anthropic 的 monorepo，光主分支的历史就接近 100 GB，压缩后的工作副本超过 25 GB。每天仅 CI 就要做约 2,500 万次代码检出，还没算开发环境、agent 沙箱和研究任务。如果按 git 的常规方式拉取，一天就是超过 600 PB 的 git 流量。

600 PB，一天。

git 当然有大仓库的应对方案：浅克隆、稀疏检出、promisor remote，再加上镜像和快照种子这些业内标准操作。Anthropic 全都用了，高峰期内部跑了几百个 git 镜像。但镜像续命有极限：快照刷新之间离 main 的尖端越来越远，diff 和 blame 这类依赖历史的操作在残缺克隆上越来越难维护。说白了，补丁打到后来，维护补丁本身成了大工程。

▲ 传统 git 扩容方案：packfile 缓存、镜像副本、种子快照，层层续命

真正点醒他们的是一个观察：和大多数公司一样，Anthropic 其实是把 git 这个去中心化系统当中心化系统在用，只有一个权威副本。而且如今绝大多数"客户端"是 agent 和任务，它们永远在线。git 为离线、分布式场景设计的那些优点，在这个场景下全变成了累赘。

于是他们问了自己一个问题：如果从头设计一套版本控制，默认所有客户端永远在线，它会长什么样？

二、Scion 的六条设计原则

这就是 Scion 的起点。它不是拍脑袋重造轮子，Google 的 Piper 和 Meta 的 Sapling 这些超大 monorepo 的前人经验他们都研究了。核心原则六条：

1. 客户端永远在线。git 假设客户端会离线，所以得抱一份完整仓库。Scion 反过来，围绕"服务器永远可达"设计协议，客户端需要什么再取什么。

2. 客户端和服务器不对称。git 里每个客户端都能当完整服务器。Scion 里历史、blame、提交、合并、rebase 全在服务端做，客户端只维护一个有界的本地缓存、摆好磁盘上的文件、盯文件系统变化。客户端自己能算的东西很少，换来的好处是本地数据量小得多。

3. 一切皆 API。用 git 时，一个 CI 任务想问"这行最后是谁改的"，得自己维护一份本地仓库，或者指望平台特定的接口。Scion 把客户端用到的所有查询都开放成 API，很多任务根本不需要本地仓库。他们的自动 bisect 和 revert 流水线，没有这种廉价编程化访问根本跑不起来。

4. 一切必须水平扩展。git 镜像模式下，仓库一大过镜像的磁盘或内存就完了。Scion 的数据是分布式的，每个组件独立扩容，整个系统里不存在一份完整物化的仓库，连服务端也没有。没有 packfile，也就没有仓库维护这回事。

5. 提交必须便宜、增量、无锁。Scion 里每次提交、rebase、合并都在服务端发生，没有 push 这回事，但每个操作都得快：代价要跟变更的大小挂钩，不能跟仓库总大小挂钩。分支、标签这类 ref 被刻意弱化，因为"全局状态需要所有服务器达成一致"本身就是扩展性炸弹。

6. 工作副本是可选的，而且天生稀疏。一天几千万次检出的量级下，能不检出就不检出。要比对两个提交？直接问服务器要 diff。要写文件？很多写负载也纯走 API。真要落盘，稀疏检出只拿你点名的目录，虚拟化检出按需物化文件，读多少花多少。

三、核心数据结构：changeset 与"派生数据"

Scion 的基本单元叫 changeset，一条写前日志里的记录。git 的 commit 存一个指向整棵目录树的指针，changeset 不一样，它只存相对父节点改动的文件列表，加上指向压缩文件内容的内容寻址指针。所有 changeset 在服务端创建，全系统即时可见。

▲ 一个 Scion changeset 长这样。注意 author 是 Claude，committer 是 Scion，这已经是他们的日常

这个设计让摄入吞吐极高：不用接 packfile，不用加锁，不用跨服务器协调，也没有 ref 要挪动。ref 技术上支持，但移动一个 ref 只是对 Spanner 里一行数据做 compare-and-swap，和创建 changeset 完全解耦。

changeset 只记增量，自己回答不了"这行谁最后改的"这类问题。所以 Scion 在 changeset 之上构建"派生数据"：blame 结构、路径历史、提交图的跳表。每种派生数据都递归定义，一个 changeset 的值由它父节点的值算出来。这套机制带来三个自由度：想加新的派生数据类型随时加；每种数据可以选择急切计算还是按需再算；客户端看不到内部结构，底层怎么优化都不用动客户端。

四、取数架构：三层缓存，各层命中率 99%+

Scion 的取数协议和 git 有个根本分歧。git 的协商是"告诉服务器我有什么"，服务器算出你缺什么，打个 packfile 发你。Scion 反过来，客户端只声明"我要什么"：从根 tree 出发，查本地缺哪些 tree，递归地要，然后对 blob 重复一遍。

每个请求要的都是一个永不变化的具体对象，所以任何缓存都能应答，整个架构就是传统的分层缓存。稀疏和虚拟化检出甚至不需要专门支持，客户端不想要的 tree，它根本不开口。

▲ 三层架构：每台节点一个 scion-daemon，区域内 scion-cache 直接从内存流式发对象，最上游 scion-server 读 Spanner 和云存储

效果：每一层缓存命中率都超过 99%；Scion 基础设施的 CPU 和内存占用比原来那几百个 git 镜像小了 200 倍；CI 和研究任务的代码检出从分钟级变成秒级，快了两个数量级，光 CI 就省出 25% 的 CPU 容量。

五、日常操作快多少？一张图看懵

原文给了一组 git 对 scn（Scion 客户端）的中位耗时对比，我挑几个最夸张的：

开发者环境里，git status 从 3.9 秒变成 19 毫秒，快 207 倍；pull 从 87 秒变 3.5 秒，快 25 倍。

agent 环境更狠。新建 worktree 从 7.1 分钟变成 5.1 秒，快 84 倍。一个变更请求从头到尾花在版本控制上的总时间，从 34 分钟压到 3.7 分钟。按他们的 agent 规模折算，这一项每天省出约 11,000 个 agent 小时。

CI 侧，任务开头的检出从 175 秒变 22 秒、从 31 秒变 3.5 秒，折算下来每天分别省约 85,000 和 195,000 个机器小时。

▲ 灰条是 git，橙条是 scn。注意几个面板的时间轴单位都不一样，从秒到分钟

六、最 meta 的部分：用 Claude 造给 Claude 用的铲子

整个故事里最 meta 的一环：Scion 之所以必须存在，是因为 Claude 写代码太快；而 Scion 能五个月建成，也是因为 Claude。

7 个人的团队，五个月，交付了 Scion、代码评审工具 Antique、代码搜索、版本控制 IAM 系统等一整套东西，还完成了全量迁移。同一时期，全公司日合并量翻了 10 倍。年初至今，光 Scion 和 Antique 这两个代码库就吃进了 12,257 个变更。放过去，这种活是一个公司级别、以年计的工程。

▲ Scion 和 Antique 代码库的每周变更量。蓝色是迁移前的 git PR，橙色是迁移后的 Antique CR

有个例子我印象很深。年初他们手写了 git 到 Scion 的摄取管线原型，自我感觉良好。后来拿到 Claude Mythos Preview 的内部快照，让它整体重写，没给任何额外指示，出来的版本内存省 20 倍、速度快 4 倍，还保持了摄取顺序和数据结构上所有隐含的不变量。

还有日常维护。Claude 会"顺手"找出一些专家要分析几天几周的优化，比如一个绕开索引的祖先查询算法问题，然后第二天再来一个。团队的评价是：Scion 是他们写过的测试最完备、防御最充分的代码库之一，连所有非平凡的基础设施交互都做了密封仿真，外加 fuzzing 和精细限流。

七、工程师没有贬值，但工作内容变了

这部分我觉得对普通开发者最有参考价值。

团队里说，所有参与工程师现在都承认 Claude 写代码比自己强。但工程师贡献了 AI 给不了的东西：对系统间高层组件的理解、对设计取舍的判断、对"要解决什么问题、要到什么规模"的把握。

还有一个频繁出现的职责，是对 Claude 说"不"。agent 有时会为了满足一个模式而违反系统核心约束。迁移期间就抓到好几个系统用线性扫提交日志的蛮力方式查"某变更何时合入 main"，而不是去问代码评审工具。Anthropic 内部大量使用对抗性评审，这招在很多方面极有效，但也容易近视：有一次评审对信任另一个内部服务过度防御，害得 Claude 加了一堆多余的校验和复杂度，得靠人把它拽回来。

团队仍然评审每一个变更请求，但看的是变更的意图，不再逐行读代码。

运维上也有新物种。他们用 Slack 频道养了一批叫"superfan"的 Claude 实例，每只只盯一个组件：scion-daemon 有专属 superfan，scion-cache 有，合并队列也有。它们能看遥测和日志，行为就像一个闲得发慌、只会刷图表找异常的老工程师。传统告警照跑，但 superfan 能发现那些让阈值告警显得"一维"的微妙新问题。

八、被一起改写的常识：merge queue 还成立吗？

这个项目逼着他们重新审视一批"为人类规模设计"的流程。最典型的是 merge queue：当一次测试跑完的时间里能合进去成百上千个变更，排队还有什么意义？业界标准的全局锁他们没法有效复刻，索性改投合并后、部署前的自动化测试。代价是并发变更会冲突，但 Claude 修冲突比人发现冲突还快。

CI 的定义本身都在晃。这是真问题，不是修辞。

九、为什么不开源，以及我的几点想法

很多人看完第一个问题肯定是：Scion 什么时候开源？答案是，不开。

理由很实在。Scion 只对真正的巨型 monorepo 有意义，受众是"数万工程师，或者成群结队疯狂写代码的 agent"。它和 git 分歧太大，要采用就得把开发生命周期整体迁移，配套的评审、搜索、CI 又高度定制。更何况 Anthropic 自己也承认，他们往内部 token 上砸的钱，别的公司不会也不想跟。

但他们预判，这类问题未来 6 到 12 个月会在更多公司出现，每家都自己硬扛一遍太浪费。所以最该做的是把思路公开：git 的服务端不必和客户端长一个样；代码托管平台可以提供 Scion 式的服务端 RPC，甚至跨平台标准化；协商协议和稀疏、浅克隆这些特性也可以组合得更好。文末特意致意了 git 社区，说希望和 GitHub、GitLab、开源社区一起过渡。

我的几点读后感：

第一，"AI 先吃掉的是自己家的基础设施"。写代码不再是瓶颈之后，瓶颈顺着工具链往下游走，版本控制只是第一个倒下的，构建、CI、评审都在排队。你公司今天觉得够用的流程，可能是按"人一天写几百行"设计的。

第二，7 个人 5 个月造一套 VCS，这个案例会被反复引用。它说明的还不是"AI 替代工程师"，而是小团队加 agent 的产能单位已经变了。以后评估一个 infra 项目的工期，得先问一句：这是人写的工期还是人机混合的工期。

第三，工程师的新核心技能正在浮出水面：系统设计、取舍判断，以及对 agent 说"不"的品味。逐行 code review 的时代在退场，审意图的时代来了。

600 PB 一天的假想流量是个警钟。AI 的产出是指数级的，而为人类规模打造的一切，都是线性的。这两条线相交的地方，就是下一个要重造的轮子。

参考：Anthropic Engineering, "Redesigning source control at Anthropic", 2026-10-13。文中全部数据与图表来自原文，图片版权归 Anthropic 所有。