七个人五个月，把 Git 换掉了：一天三万次合并之后

5 月每天合并约 2500 次代码变更，9 月这个数字变成 30000 次以上。四个月，十倍以上。

一组数字能说明这个变化有多不寻常：一支七个人的团队，五个月时间，把公司整个单体仓库从 Git 搬到了自己写的版本控制系统上。搬运期间，代码合并量又涨了十倍。

这件事的主角不是 Git，也不是某个新模型。它是一份工程博客里那张从 1 月画到 9 月的折线图，以及图上那个几乎垂直上升的尾部。

🔧 瓶颈换了位置

Anthropic 把这件事写在 10 月 13 日的工程博客里，标题是《重新设计源码控制》。开篇的判断很直接：在他们公司，写代码已经不再是系统的瓶颈或者研究的瓶颈。瓶颈转移到了为人类规模设计的开发者基础设施上，也就是源码控制、构建和持续集成。

支撑这个判断的是仓库的体量。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB。仅持续集成一项，每天要做约 2500 万次代码检出。如果按朴素方式直接取数据，每天的 Git 流量会超过 600 PB。内部 Git 镜像在峰值时铺到了数百个，这个数字本身也是压力的读数。

600 PB 是个容易被读过去的数字。1 PB 大约是 1000 TB，换成人能感知的尺度，一台 16 TB 的硬盘装满，需要 37500 台才够一天的量。而这还只是检出这一项。

他们试过常规的缓解手段：浅层克隆与稀疏检出这两种下载部分仓库的方式，加上内部 Git 镜像，还有 Blob 存储快照。这些办法都换来了时间，代价是随着合并率上升，运维难度也跟着上升。预构建的副本会跟主分支漂移，diff 和 blame 这类工具在部分克隆上会直接坏掉。

关键在于使用方式的改变，而不是代码量的改变。Git 是去中心化设计，每个克隆都是一份完整仓库，能离线工作。而 Anthropic 的客户端几乎全是智能体和自动化作业，它们按定义就是在线的。为离线工作设计的能力，在这个场景里变成了负担。

🏗️ 七个人的五个月

Scion 的设计借鉴了 Google 的 Piper 与 Meta 的 Sapling，四条原则写得很清楚：客户端始终在线；客户端与服务器不对称，服务器负责回答历史查询、blame、提交创建与合并，客户端只维护一个有界的本地对象缓存；所有源码控制能力通过 API 暴露，作业不再需要本地仓库就能查询，这样自动二分查找和回滚流水线才在规模上成为可能；以及水平可扩展。

它把 Git 里那个叫 commit 的东西换掉了。工作单元叫 changeset，是预写日志里的一条记录，存的是相对第一父节点发生变化的文件列表，加上指向 blob 存储中压缩内容的指针。

这里有个容易被忽略的细节：changeset 在服务器端创建，并且即时在所有位置可用。Git 的 commit 是本地对象，推送是显式动作；Scion 没有可推的东西。这个差异是后面所有性能数字的来源。

三层缓存结构分别是节点级的 scion-daemon，区域级的 scion-cache，以及权威的 scion-server。三者响应同一套 RPC，但严格分层以隔离故障域。Anthropic 称每一层的缓存命中率都在 99% 以上。

拿到的东西：

• 相比原有 Git 镜像基础设施，CPU 与内存需求缩小到 1/200
• CI 与研究作业的检出速度快两个数量级，从数分钟变成数秒
• 仅 CI 一项就获得 25% 的 CPU 容量余量

🔁 一个关于闭环的细节

迁移工作本身也有 Claude 参与。Anthropic 提到一个例子：Claude Mythos Preview 的一个早期内部快照重写了原本手写的 Git-to-Scion 导入管线，在没有进一步指令的情况下产出了一个内存占用少 20 倍、速度快 4 倍的版本，同时保住了导入顺序与数据结构相关的全部隐式不变量。

闭环在这里合上了：Claude 写代码的速度把原有工具推到了瓶颈，然后用来解决瓶颈的工具里，有一部分也是 Claude 写的。

Anthropic 对人的角色给了一个坦白说法。他们的工程师现在会把 Claude 评价为比自己更好的代码写作者，但工作内容变了。团队成员仍然审查每一个变更请求，只是审查的对象从每一行代码变成了变更的意图。博客里写道，很多时候他们的工作是对 Claude 说「不」，比如当智能体违反了核心系统约束，或者把方案做得过度复杂。

这句话的分量不在礼貌层面。过度工程是一个只有懂系统的人才能拦下来的问题类型，而它恰好是智能体最容易犯的错。

⚖️ 它不适合你

Anthropic 自己划清了边界，说 Scion 绝不是一个适合通用场景的 Git 替代品。它为超大型单体仓库加上成群智能体的场景设计，依赖定制的代码审查、代码搜索和持续集成。Scion 不会公开发布。

Anthropic 的表述是想把设计思路分享给 GitHub、GitLab 这样的托管平台以及开源社区，建议 Git 平台可以吸收 Scion 的服务端思路，比如更全面的服务端 RPC，以及组合更好的稀疏与浅层特性，同时不必放弃 Git 的整体模型。博客里也承认，Git 社区过去近二十年为扩展这个平台所做的工作值得致意。

对于大多数离每天三万次合并还很远的团队，Git 依旧是标准工具。

不过 Anthropic 预测，随着 AI 编码工具铺开，同类问题会在未来六到十二个月内出现在更多组织里。

📌 值得盯的是什么

Anthropic 的判断是「潜在的对合并代码的需求实际上是无限的」。按这个说法，消除每一个瓶颈都会立即引发代码产出量的进一步增加。

这构成了一个不太舒服的循环：写代码变快，基础设施成为瓶颈，重建基础设施，重建过程中产出更多代码，下一个瓶颈出现在别处。九月的另一份复盘给出了同方向的证据，那次是持续集成：任务量在六个月里达到原来的 25 倍，团队三次临时补救分别维持了 70 天、29 天和不到一天，最后由一名工程师用三周重构了测试选择服务。

值得盯的有两处。第一是六个月到十二个月内，是否真有其他组织公开宣布类似迁移。第二是像 scion-cache 这种区域缓存层，在跨区域故障时会怎样。99% 命中率意味着大约 1% 的请求要打到权威服务器，那 1% 的尾延迟决定了系统会不会在一次区域故障时被上游压垮。博客没有给出这条链路的延迟分布。

另一处是那次合并队列锁的取消。他们放弃了全局合并队列锁，改成合并后与部署前测试，代价是允许并发变更产生冲突，前提是 Claude 通常能很快修好。Willison 在 Hacker News 上的转述把 Scion 比作某种中心化的版本控制系统。这个设计选择的前提是「修复冲突的成本足够低」，而这个前提成立与否，取决于智能体修 bug 的实际能力。