代码一天合并3万次，Git先撑不住了

今年 5 月，Anthropic 平均每天往主仓库合并 2500 次代码改动。到 9 月，这个数字变成 3 万次以上，公司并没有为此多招几百名工程师，多出来的产能来自 Claude 写出来的代码。

结果先撑不住的不是模型，是 Git。

10 月 13 日，他们把这件事的答案公开了：一套自研的版本控制系统 Scion，五个月里把那个巨型单仓库从 git 整个迁走，同期上线的还有代码评审界面 Antique 和代码搜索。

断在每天 2500 万次检出上

先看他们当时面对的量级。主分支的历史接近 100 GB，压缩过的工作副本超过 25 GB；光是为了 CI 每天就要检出代码约 2500 万次，这还没算开发者本地环境、agent 沙箱和研究任务。按最笨的方式拉取，一天是 600 PB 的流量。

常规手段他们全用遍了：浅克隆、稀疏检出、promisor remote、内部 git 镜像（峰值时开了几百个）、放在对象存储里的仓库种子快照。这些办法各自买到过时间，但合并率一涨就漏。种子刷新一代，离主分支顶端就更远一截，而 diff、blame 这类依赖历史的操作要在一片半拉子的克隆上继续工作，维护成本越滚越高。

问题不在工程能力，在设计前提。Git 假设每个客户端都可能握着完整的一份仓库、而且可以离线工作，可他们那边的客户端几乎全是永远在线的 agent 和 CI 任务。去中心、人人可当服务器、断网也能算历史，这些让 git 成为标准的特性，在仓库涨到这个体积、合并涨到这个频率之后，反过来开始拖人。

Scion 把客户端和服务端拆开算

他们的做法是从头问一句：如果一开始就知道客户端永远在线，源控会是什么样？

客户端不再持有完整仓库，要用数据的时候向服务端取；服务端负责回答文件历史、算 blame、建提交、合并、变基，客户端只保留一个有限的对象缓存和磁盘上的工作副本。提交的单位也从 commit 换成 changeset，写前日志里的一条记录，不存整棵树，只存相对第一父提交变了哪些文件，文件内容用内容寻址的指针指向对象存储。这样接受一次改动的开销跟"改了多少"有关，跟"仓库多大"无关，也就不需要 packfile，更不用做仓库维护。

分支和标签这类指针被刻意压到最低，日常操作根本不碰它们；真要动一个 ref，那是对 Spanner 单行的 compare-and-swap，跟创建 changeset 分开走。

落到指标上：基础设施的 CPU 和内存占用降到原来镜像方案的 1/200，检出从分钟级变成秒级，单是 CI 这一项就省出 25% 的算力容量，每一层缓存的命中率都在 99% 以上。原来像每家分店都养一本完整字典，现在改成打电话问总店，只取你要查的那一页。

权限也顺着这个结构重做了一遍。仓库可以按目录授不同权限，最敏感的那部分代码单独收紧，而不用为此放弃单仓库；评审工具那边能表达更细的语义约束，把"只改了注释"和"改了判定逻辑"分开，让人的注意力落在真正要紧的改动上。

七个人五个月，靠的也是 Claude

做这套系统的团队是七个人。五个月里，除了 Scion 和 Antique，他们还写了半打相关系统，同期每天合并的改动量涨了十倍。按过去的经验，这种规模的源控迁移要一家公司花好几年、投更多工程师。

有个细节值得单独拎出来。git 到 Scion 的摄入管道，第一版是他们手写的原型，当时自己觉得挺不错；拿到内部早期模型的快照之后，他们把整条管道丢给它重写，没给额外指令，回来的是内存占用降到 1/20、速度快 4 倍的版本，而且原来那些关于摄入顺序和数据结构的隐式约定一条没破。

人的部分没被删掉，只是换成了另一种活。参与这个系统的工程师现在普遍认为 Claude 写代码比他们自己强，但系统之间怎么咬合、设计上要放弃什么、这套规模是不是必须，还是人给的判断。更常见的动作是拦：agent 会为了凑一个看起来合理的模式，顺手破坏本该守住的约束。迁移期间出现过好几个系统，为了回答"这次改动什么时候合进主分支"，去线性扫提交日志，而不是去问代码评审工具。

对抗式评审也会跑偏。有一次评审对某个内部服务过度不信任，结果 Claude 照着意见加了一堆防御性校验和复杂度，最后得靠人把它拉回正常水平。评审方式也跟着变：每个改动请求照样有人看，但人看的是意图，不再逐行读代码。

运维那头也有个挺具体的做法。他们给每个组件单独开一个挂着 Claude 的 Slack 频道，管它叫 superfan：一个盯 scion-daemon，一个盯 scion-cache，还有一个专门盯 Antique 的合并队列。这些频道接得到遥测和日志，干的事就是不停刷图表、找异常，官方说它能发现一些常规告警看不出来的细微问题。

两个容易看歪的地方

最流行的说法是：连 Anthropic 都让 AI 写全部代码了，工程师这行要没了。

这个说法有一部分是真的，数字硬得没法绕。6 月的技术报告里写，截至 5 月，Claude 写的代码占公司合并进生产代码库的行数的 80% 以上；10 月 16 日那份报告里，2025 年初到 2026 年之间，初级员工在技术部门的占比从 21% 降到 14%，初级技术岗在技术部门招聘里的占比从 27% 降到 9%。

可它解释不了一件事：谁决定敲什么。同一批材料里，写代码的人被描述成提供设计取舍、判断该不该做的人，而且还得负责把跑偏的实现拽回来。

写代码的边际成本掉到接近零以后，稀缺的东西换成了"值不值得做"和"做出来对不对"。这跟"没人写代码了"是两回事。

另一个被顺手读歪的是"这套东西该抄"。Anthropic 自己在文末写得很清楚：Scion 不是 git 的通用替代，它成立的前提是超大规模的单仓库加一群天天写代码的 agent，而且他们内部能烧的 token 远超任何正常公司的预算。