一天合并 3 万次代码——这是 Anthropic 现在主仓库的状态；五个月前，这个数字是 2,500 次。主分支历史接近 100GB，压缩后的工作副本超过 25GB，光是为了跑 CI，他们每天要签出代码约 2,500 万次。
如果你所在的团队也在用 AI 写代码，这条曲线的下一段可能轮到你自己：先撑不住的不是模型，是 Git、CI 和代码审查。
官方给出的哪些数字是普通团队也会撞上的预警线，以及他们的做法里哪些能借、哪些千万别照抄。 官方给的时间线很直白：2026 年 5 月平均每天合并约 2,500 次代码变更，到 9 月超过 30,000 次，官方自己的说法是「涨了十倍以上」。他们的解释是，写代码不再是瓶颈，为人手规模设计的开发者基础设施才是——源代码管理首当其冲。
具体压力落在三个地方：主分支历史接近 100GB，压缩后的工作副本超过 25GB；CI 每天要做约 2,500 万次签出（还不算开发者环境、Agent 沙箱和研究任务）；如果按最朴素的方式拉全量，一天会超过 600PB 的 git 流量。


峰值时运维过几百个内部 git 镜像，再配合浅克隆、稀疏签出、快照种子。这些办法在合并率继续上涨之后失效了——种子离主分支尖端越来越远，依赖历史的操作（diff、blame）在部分克隆上越来越难维持。 Anthropic 的判断是：公司其实一直把 git 当集中式系统用，但几乎所有客户端都是在线运行的 Agent 和作业，而 git 为「离线、每个克隆都是完整仓库」做的设计，恰好成了规模瓶颈。于是他们重做了服务端（内部叫 Scion），核心改动有两条：客户端不再持有完整仓库，blame、历史查询、提交、合并、变基都由服务端回答；仓库数据分布式存放，任何地方都不存在一份完整副本，也没有 packfile，因此不需要仓库维护。
官方给出的结果是：每一层缓存命中率都在 99% 以上；整套基础设施的 CPU 与内存占用是过去镜像方案的 1/200；CI 和研究任务的签出从分钟级变成秒级（官方称快两个数量级），仅 CI 一项就回收了 25% 的 CPU 容量。做这件事的团队是 7 个人，同时交付了 Scion、代码审查工具 Antique 和迁移。
他们早期的 git→Scion 摄取管线是手写的原型，后来交给内部早期的 Claude Mythos Preview 重写，官方称在没有任何额外指令的情况下，新版本内存占用降到 1/20、速度快 4 倍，同时保持了下游数据结构的隐式约束。 能借的思路只有一句：git 服务端不必和 git 客户端长成一样。官方建议其他团队可以往这些方向走——把服务端做成提供能力的 RPC 层（谁最后改了这一行、两个提交什么关系都直接问服务端），让 job 不必再养一份本地仓库；把稀疏签出和虚拟签出做成协议的中心，而不是补丁。
Scion 不是 git 的通用替代品，只有「真正巨大的 monorepo、上万工程师或成群 Agent 高频写代码」时才成立；他们能烧的 token 远超其他公司现实上愿意花的预算；而且这套东西很难对外提供，因为要连带迁移代码审查、代码搜索和 CI，内部版本高度定制。
还有一个反面细节：他们放弃了业界惯用的全局仓库锁，改用合并后与发布前测试，于是并发变更会真的冲突——官方说这些冲突通常由 Claude 修得比人快。 第一，全部数字都来自 Anthropic 自家工程博客，没有第三方复现、没有独立压测，也没有说明迁移期间的回归。第二，「Claude 修冲突」「让 Claude 盯着某个组件的健康度」这类做法是他们的内部实践，人少的团队直接照搬只会多出一层没人维护的东西。第三，换版本控制的成本不在工具本身，而在它周边——审查、搜索、CI 三件套都要重做，这也是官方说自己不适合对外提供的原因。
如果你的团队一天合并几百到几千次，这条新闻的正确用法不是「自研一套版本控制」，而是把它当一条预警线：当你开始靠堆镜像和快照种子来维持签出速度、种子越来越跟不上主分支的时候，问题已经不在 CI 配置，而在版本控制的服务端形态——先考虑稀疏签出、服务端侧的历史查询 API 和仓库拆分，别一上来就换系统。