Claude 写代码太快，Anthropic 干脆把 Git 换掉了

Claude写代码太快，Anthropic先把Git干掉了 — woshipm.com · 15 小时前 · ⚙️ 工程

AI 智能体大规模参与开发后，版本控制基础设施反而成了整条工具链上最先崩溃的一环。Anthropic 工程团队在官方博文中完整复盘了这次危机与应对：随着 Claude 在内部承担越来越多的自主工程任务，其核心单体大仓的每日代码合并量在短短四个月内暴涨逾十倍，从 2026 年 5 月的约 2,500 次一路冲到 9 月突破 30,000 次，9 月 9 日当天更是录得 30,401 次的峰值纪录。合并洪流的背后是沉重的物理代价：主分支历史体积逼近 100 GB，压缩后的工作副本仍超过 25 GB；仅 CI 流水线每天就要执行 2,500 万次代码检出，若按 Git 原生方式拉取全量数据，每日网络流量将超过 600 PB。团队先后尝试了浅克隆、稀疏检出、对象存储快照种子等社区方案，高峰期甚至维护了数百台专用 Git 镜像服务器，但镜像节点被磁盘与内存吞吐逼到极限，快照与主干的差距越拉越大，冷启动耗时成倍增长，稀疏环境下的 diff 和 blame 频繁报错。工程师们最终意识到，Git 诞生于二十年前，其设计预设是开发者可能随时离线工作，因此每个本地克隆都必须自包含、节点地位对等；而如今的使用者绝大多数是云端常驻、网络始终可达的智能体、沙箱和流水线，用对等离线拓扑硬扛高并发在线负载，崩溃只是时间问题。作为对策，Anthropic 借鉴 Google Piper 与 Meta Sapling 的经验，用 7 名工程师、耗时 5 个月自研了名为 Scion 的新一代版本控制系统，并完成了核心大仓从 Git 的全量迁移。Scion 的核心思路是客户端永远在线、端云深度非对称：服务端统一承担历史查询、blame、rebase、merge 等重计算，客户端则做到极度轻量，不再冗余存储全量数据。文章的结论是，当机器取代人类成为代码的主要生产者，为人类手速和离线习惯设计的工具范式必须被重新发明。

核心信息

• 合并量数据是整个事件最直观的证据：2026 年 5 月，Anthropic 单体大仓日均合并约 2,500 次代码变更；到同年 9 月，单日合并量突破 30,000 次，9 月 9 日创下 30,401 次的峰值，四个月增长超过十倍。团队还发现合并需求几乎没有上限，基建每消除一个瓶颈，智能体产出的代码量就立刻迎来新一轮爆发，这意味着容量规划不能再按人类增长曲线外推。
• 基础设施承受的压力已达到荒谬量级：主分支历史接近 100 GB，压缩后工作副本仍超过 25 GB；每天仅 CI 流水线就执行 2,500 万次代码检出，尚未计入工程师开发机、Agent 沙箱和研究任务；若按 Git 原生方式全量拉取，每日将产生超过 600 PB 的网络流量，远超常规骨干网的承受能力。
• 团队在迁移前把 Git 社区现成的补救手段用了个遍，包括浅克隆、稀疏检出、基于云对象存储的快照种子，峰值时期维护了数百台专用镜像服务器。但镜像被单机磁盘容量和内存吞吐顶到上限，快照与主干差距扩大导致节点冷启动拉取耗时成倍暴增，稀疏克隆环境下 diff 与 blame 频繁崩溃，运维成本持续指数级攀升。
• 替代方案 Scion（寓意幼苗与新生代）由 7 人团队在 5 个月内完成开发并完成全仓迁移，设计上借鉴了 Google Piper 和 Meta Sapling。其六大设计原则中最关键的两条是：客户端永远在线，假定服务端始终可达、按需读取而非本地冗余全量数据；端云深度非对称，把文件历史、blame、rebase、merge 等重计算全部放到服务端，客户端工具 scn 保持极轻量。

💡 为什么值得读: 它用一手数据和完整复盘证明了一件反直觉的事：AI 编程的第一个被压垮的瓶颈不在推理和算力，而在最不起眼的版本控制基础设施上。

✍️ 小编看法: 这篇复盘最值得玩味的地方，不是 Anthropic 又秀了一次工程肌肉，而是它无意间公布了一个行业拐点的坐标：版本控制这个二十年没被认真挑战过的地基，被自家产品的工作负载压塌了。以往我们谈 AI 编程的瓶颈，讨论的都停留在代码质量、推理成本、评测基准，几乎没人想过瓶颈会先出现在最无聊的基建层。这其实是一个非常典型的信号——真正的范式切换，往往不是从应用层开始的，而是从被压垮的底层工具倒逼出来的。值得警惕的是文中那句轻描淡写的观察：合并需求「见不到底」，拆掉一个卡点产出立刻翻倍。这说明扩容式修补注定失败，因为需求函数本身就是无限的，只有改变架构的复杂度常数才有意义。但被多数读者忽略的代价至少有两个：一是 5 个月、7 个人做成这件事，前提是 Anthropic 对工作负载有极端深入的理解，还能说服全公司承担迁移风险，这种组织条件绝大多数公司并不具备；二是自研系统意味着脱离 Git 生态，周边工具链、招聘技能、开源协作都要重新适配，这些隐性成本博文里不会写。对普通团队而言，现在急着跟风自研大可不必，但有两件事值得立刻做：重新审视自己仓库的 CI 检出策略和镜像成本，以及关注 Scion 是否会像内部工具外溢的历史先例那样开源或商业化。下一步最值得观察的，是 GitHub、GitLab 这些平台方如何回应——如果智能体负载成为普遍现象，托管平台的服务端架构改造会是比任何新编辑器都更大的市场。

🏷️ version control, Git, Anthropic, AI coding

本文由 AI 辅助生成，内容为原文摘要与编辑点评，原文版权归原作者所有，欢迎点击上方链接阅读完整内容。

---