代码写太快，Git 崩溃了：Anthropic 派 7 个人，5 个月重造了套版本控制

先说个数字：今年 5 月，Anthropic 平均每天合并约 2500 次代码修改；到了 9 月，这个数字冲破了 3 万次。短短四个月，代码合并量涨了 12 倍以上。

据 InfoQ 报道，这波暴涨很大程度上是 Claude 这类 AI 编程助手带来的——它们能自己改代码、跑测试、反复优化，甚至从零把服务搭起来。可问题是：代码生产速度上去了，那套原本为人类工程师设计的开发基础设施，却彻底跟不上了。

瓶颈先卡在 Git 上

Anthropic 用的是"单体大仓库"（Monorepo），主分支历史接近 100GB，压缩后还能有 25GB。光持续集成（CI）系统，每天就要做约 2500 万次代码检出。要是还按传统 Git 的方式拉数据，每天可能产生超过 600PB 的传输量。

为了硬撑，他们此前已经用上浅克隆、稀疏检出、内部镜像、对象存储快照等各种优化手段，巅峰时期甚至维护着数百台 Git 镜像服务器——但代码合并量还在涨，这套方案越来越撑不住。

于是他们做了个相当激进的决定：干脆重新开发一套版本控制系统。

10 月 13 日，Anthropic 在官方工程博客披露了这件事：一个只有 7 名工程师的团队，在五个月内造出了名为 Scion 的新版本控制系统，并完成了整个大仓库的迁移，顺带还做了代码审查工具 Antique、代码搜索、权限管理等一系列配套系统。

思路：把活儿搬到服务器上

Git 之所以好用，靠的是"分布式"——每个人本地都存一份完整历史，断网也能干活。但 Anthropic 发现，现在大量代码操作其实是由"始终在线"的 AI 助手和自动化任务在跑，那每个客户端还需要扛下完整仓库历史吗？

Scion 的关键改动，就是把提交、合并、变基、历史查询这些主要操作，统统挪到服务器端完成。客户端只负责管本地缓存和工作目录。由于提交直接在服务器上创建，传统 Git 里的 push 步骤也省了。这样一来，版本控制的开销更多取决于"这次改了多少数据"，而不是"整个仓库有多大"。

配套地，他们还设计了分层缓存，每层命中率都超过 99%。成果是：基础设施的 CPU 和内存占用降到原来 Git 镜像方案的约 1/200，代码检出从分钟级缩短到秒级，光 CI 就省下约 25% 的算力。

不过要说明，这几个数字对应不同维度，不能简单理解成"Scion 所有操作都比 Git 快 200 倍"。

结尾有意思：Claude 既是病因，也是解药

更耐人寻味的是开发过程本身。官方举了个例子：Scion 早期的数据导入管线是工程师手写的，大家觉得已经挺快；后来他们让内部早期版模型重新实现一遍，结果新版本内存消耗降了 20 倍、速度快了 4 倍。团队成员坦言 Claude 写代码已经超过自己，但系统层面的设计取舍仍得靠人——工程师一项重要工作，反而是告诉 Claude"别这么干"。

当然，也不是全无隐忧。当合并量到了每天数万次，传统的"合并队列"几乎没法照搬，冲突可能要等合并之后才被发现。Anthropic 没披露新流程下的缺陷率、回滚率等数据，这套模式在质量上是否真比传统流程更优，暂时还没有定论。

来源：InfoQ《Claude写代码太快，Git扛不住了：Anthropic仅靠7人，5个月重造版本控制系统》

原文链接：https://www.infoq.cn/article/6iRATYfkqF7aITPaFR2R