合并量涨十倍之后：Anthropic 用五个月换掉了 Git

先说结论：Anthropic 自己写代码这件事，已经不再卡在「写得慢」，而卡在「合进去之后整条链路扛不住」。据其工程博客（企业宣称），2026 年 5 月 monorepo 日均合并约 2500 次，到 9 月超过 3 万次；他们用五个月自研并迁完一套叫 Scion 的源码管理系统，替换了 Git。数字容易刷屏，真正值得带走的判断是：智能体产出越多，为人规模设计的源码管理、构建与持续集成，会先成为瓶颈——而且这家公司明确说，Scion 不会开源，也不适合一般团队当 Git 替代品。

发生了什么

据 Anthropic 工程博客（企业宣称，2026-10-13 发布、10-15 补充），他们把瓶颈概括成一句话：写代码不再是卡点，卡点变成了为人规模搭起来的开发基础设施——源码管理、构建、持续集成。Claude 能自主迭代研究循环、微优化复杂程序、从零搭新服务；于是他们最先撞上的，不是「模型会不会写」，而是「写出来之后往哪里放、怎么合、怎么查」。

规模数字也来自同一篇企业说明：主分支历史本身接近 100 GB，压缩后的工作副本超过 25 GB；仅持续集成一天约 2500 万次检出，若按朴素方式拉取，流量量级会被推到每天数百 PB。他们试过浅克隆、稀疏检出、内部镜像与快照种子——高峰时跑过数百个内部 Git 镜像——但合并速率继续涨时，镜像与种子越来越难维护。

于是他们做了 Scion：客户端默认在线、大量历史与合并算力放在服务端、变更以「changeset」写入预写日志，按相对父提交的文件列表存，而不是完整树指针；仓库数据可水平扩展，基础设施占用（CPU 与内存）据称比原先 Git 镜像方案小约 200 倍，持续集成与研究任务检出从分钟级降到秒级，持续集成一侧还报了约 25% 的 CPU 容量收益。同期还做了代码审查界面 Antique、代码搜索与源码权限体系。七人团队五个月迁完 monorepo——Anthropic 自己强调：Claude 既把他们推进这个困境，也加速了建造出路。

The New Stack 与 The Register 的报道（媒体报道）转述了同一组数字与时间线，并点出 Anthropic 的态度：预期其他大量使用 AI 写代码的组织，在未来约六到十二个月里会撞上同类压力；但 Scion 偏离 Git 太远，迁完整条开发生命周期成本太高，加之内部 token 开支远高于多数公司愿意承担的水平，因此不做公开版，只希望把思路交给 GitHub、GitLab 与开源社区，让一部分能力回到 Git 服务端。

为什么重要

把这件事当成「又一个自研工具」会看轻。它检验的是一件很具体的事：当智能体把产出速度抬高一个数量级，团队里哪一步最先撑不住。

第一步往往不是模型能力演示，而是合入与检出。Git 的强项是离线、完整副本、每个客户端都能当完整节点；Anthropic 的工作负载却是「几乎永远在线的智能体与任务」。设计前提一换，旧工具的优点就变成拖累。他们写得很直白：每去掉一个瓶颈，代码产出立刻再涨一截——需求几乎无限。

第二步是审查与回滚谁来做。同一篇说明里，参与建设的工程师普遍认为 Claude 写代码比自己更好；工程师的价值转向系统级取舍，以及频繁对智能体说「不行」——智能体为了凑出某种模式，会破坏本不该允许的系统约束。审查也从逐行读代码，更多变成核对变更意图。这不是职业会被替代的口号，而是分工在变：人接手的位置，从「亲手写完」移到「定边界、否坏设计、盯合并后的真实后果」。

第三步才轮到「别人能不能直接用」。答案目前是否定的。Scion 不是产品发布，是一家把内部推理额度花得很猛的公司，为自己的 monorepo 做的专用系统。The New Stack 把标题落到「你拿不到」上，是对的：读者若据此去等一个可下载的「AI 版 Git」，会等空。

同一周，Anthropic 还把面向 Team / Enterprise 的 Code Review 产品推到正式可用（企业宣称）：正式版强调审查更快（多数约 6–10 分钟）、可按仓库调 Quick / Standard / Deep；另据 Claude Code 团队同日介绍内部流程的文章（企业宣称），研究预览期间内部「有实质审查评论」的拉取请求占比从 16% 升到 54%。这是同一条瓶颈链的产品侧：写得快了，审查也必须加快——但它审查的是 GitHub 上的拉取请求，解决的是「看 diff」，不是「日合并三万次时的仓库物理结构」。两件事不要混成一个「已经替你重做完基础设施」的故事。

我们不知道什么

公开材料里仍有几块空白。

第一，3 万次日合并里，有多少是智能体直接落地、有多少是人改过再合，Anthropic 没有给出拆分；「Claude 写得多」是叙事主线，但缺少可复核的占比。

第二，迁完之后，合并冲突、错误合入、回滚频率有没有变好或变差，博客几乎没写；它强调的是吞吐、检出时延与基础设施体积，不是变更质量仪表盘。

第三，其他公司何时真的撞上同等压力，仍是预测。GitHub 曾公开谈过拉取请求与提交暴增带来的可用性压力（The Register 转述），但那不等于每家用了编程智能体的中小团队都要自研源码系统。多数仓库远小于「主分支历史近 100 GB、日检出千万级」这一档。

第四，Scion 与 Antique 的对外接口、安全边界、以及「对人说不」的具体规程，都没有可操作的公开手册。读者不能把工程博客当迁移指南。

接下来看什么

三件可核对的事，比再追一条「日合并又破纪录」更有用。

一看 Git 托管与开源社区有没有吸收「服务端不对称、API 可查历史、稀疏/按需检出更好组合」这类思路——Anthropic 自己把期望放在这里，而不是放在开源 Scion。

二看审查环节的完成率，而不是演示视频：Code Review 正式可用之后，有多少团队真正打开并设了月度花费上限；审查是缩短了人的等待，还是只是多了一层自动评论噪声。

三看构建与合并队列怎么改。Anthropic 写到，在智能体规模下，传统「全局锁住再合」的合并队列很难复刻，他们更多押在合入后、部署前的自动测试，并接受并发变更可能冲突——再让 Claude 去修。这等于承认：完成一件事的定义，从「一次干净合入」变成「冲突可自动收敛」。若其他团队也走这条路，人需要接手的位置会进一步后移到发布门禁与事故响应。

我们的看法：Scion 证明的是瓶颈转移，不是「Git 已死」或「人人该自研」。对在用编程智能体、企业自动化与开发工具的人，更稳妥的读法是——先量自己的合入量、检出耗时、审查排队与回滚成本；数字还在人的规模里，就不必赶时髦换底座；数字已经明显被智能体推着跑，再去问托管方要服务端能力与审查自动化，而不是把演示里的写码速度当成基础设施已经就绪。