Anthropic 10 月 13 日发布工程复盘，披露公司用五个月时间，把整个单体仓库从 git 迁到了自研的版本控制系统 Scion，同期还做了一套代码评审工具 Antique。核心团队只有 7 个人。
起因是代码合并量。2026 年 5 月，Anthropic 的单体仓库日均合并约 2500 次；到 9 月，这个数字超过了 3 万次。复盘里写道：
“As our merges per day grew more than tenfold, source control became our biggest development bottleneck.” 日均合并量涨了十倍以上，源代码管理成了我们最大的开发瓶颈。
写代码本身不再卡脖子，卡住的是源代码管理、构建和 CI。
git 撑不住的地方
Anthropic 列了几组数：主干历史接近 100 GB，压缩后的工作副本超过 25 GB，CI 每天大约做 2500 万次代码检出。如果每次都老老实实拉一遍，每天的 git 流量会超过 600 PB。高峰期公司跑着几百个内部 git 镜像，合并一快，镜像和预置快照就越来越难维护。
复盘给的根本原因是设计目标对不上。git 为离线、分布式的人类协作而生，每个人手里一份完整仓库；Anthropic 现在的主要客户端是一直在线的智能体和自动化任务。
Scion 的思路因此反过来：历史、blame、提交、合并、变基全放在服务端，客户端只留有限的本地缓存和工作副本，数据按需取。提交在服务端完成，成本跟改动大小有关，跟仓库总大小无关。分支只保留主干和发布分支，移动一个分支指针，就是对数据库里一行记录做一次比较并交换。客户端走本地守护进程、分层缓存、最后才到服务器，各层缓存命中率超过 99%。
算一笔账
拿复盘里的数字粗算：600 PB 除以 2500 万次检出，每次约 24 GB，和”工作副本超过 25 GB”基本对得上，说明 600 PB 这个数是按”每次全量拉取”估出来的上限。
3 万次合并分到 24 小时，平均每分钟 20 次出头。按 git 的推送模型，每次推送前都要先和远端同步，这个频率下冲突重试会把队列堵住。Scion 把合并挪到服务端，省掉了推送这一步，Anthropic 同时放弃了全局合并锁，改靠合并后、部署前的自动化测试兜底，并发改动撞车时交给 Claude 修。
换来的结果，按公司口径：Scion 基础设施的 CPU 和内存占用比原来的 git 镜像集群少约 200 倍；CI 和研究任务的检出从分钟级降到秒级；光 CI 一项就腾出约 25% 的 CPU 容量。
Claude 在里面干了什么
迁移本身也用了模型。早期手写的 git 到 Scion 导入流水线，交给 Claude Mythos Preview 重写后，内存占用降到原来的 1/20，速度快了约 4 倍。复盘称 Claude 还找出了一些算法层面的优化，写了大量测试、模拟和模糊测试；工程师的工作变成把住设计意图、否掉不合理的方案、审查改动的意图而不逐行读代码。
Antique 的细节复盘没有展开，只提到它能给审批设语义规则，把只改注释的提交和动了敏感逻辑的提交分开，让人工评审集中在后者。
Scion 不开源。Anthropic 的说法很直接：“Scion is by no means a suitable replacement for git for general use.” 内部组件定制程度太高，没法打包给别家用。它希望 GitHub、GitLab 和开源社区借鉴服务端 RPC、稀疏检出这些思路去改 git。谷歌的 Piper、Meta 开源的 Sapling 走过类似的路，区别在于这次推动重写的压力来自 AI 写出来的代码量。
参考来源：CocoLoop、Anthropic 工程博客；日均合并量、检出次数、资源占用倍数均为 Anthropic 自报口径，单次检出体积为编辑据其数字粗算。