AI 写代码写到 Git 崩溃：Anthropic 自研 Scion，把 5→9 月 12 倍的合并洪流装进新管子

2026 年 AI 编程圈最值得细读的一篇工程博客，可能不是关于某个新模型的。10 月 13 日，Anthropic 的工程师们摊牌了：他们亲手把 Git 换掉了。不是因为 Git 不好，而是因为 Claude 写代码写得太快，把 Git 的管道撑爆了。

先别急着觉得这是"大厂的凡尔赛"。这篇博客真正有分量的地方在于，它第一次用一家公司的真实生产数据，把 2026 年每个 vibe coder 迟早会撞上的那堵墙画了出来：当写代码的人从几百个工程师变成几千个不知疲倦的 agent，第一个崩掉的不是模型能力，而是版本控制、构建、CI 这些"为人机规模建造"的基础设施。Anthropic 只是因为用 Claude 写代码比全世界任何公司都多，所以第一个撞墙，也第一个被迫造出新墙。

而造墙的过程本身，就是这篇文章最妙的注脚：一个 7 人小团队，用了 5 个月，造出了替代 Git 的自研版本控制系统 Scion，外加全新的代码评审面 Antique，完成了整个 monorepo 的迁移。而帮他们造出 Scion 的，正是 Claude 自己。

一条陡峭到离谱的曲线：从每天 2500 次合并到 30000 次

先看数字。2026 年 5 月，Anthropic 的 monorepo 平均每天合并约 2500 次代码变更；到了 9 月，这个数字超过了每天 30000 次。9 月 9 日那天，单日合并 30,401 次，创下峰值。从 5 月到 9 月，四个月，12 倍。

12 倍是什么概念？Anthropic 在博客里给了几个更直观的刻度。主分支的历史记录 alone 就接近 100GB；一个压缩过的工作副本超过 25GB；每天光是 CI 就要做约 2500 万次代码 checkout——注意，这还只是 CI，还没算开发者本地环境、agent 沙箱和研究任务。如果按最朴素的方式去 fetch，这相当于每天超过 600PB 的 git 流量。600PB，写出来是 600,000TB，就为了每天把代码拉下来。

他们当然试过所有"标准答案"。shallow clone、sparse checkout、promisor remote 这些 git 原生工具用了；内部 git 镜像搭了，峰值时期跑了几百个；blob 存储里的仓库种子快照也备了。这些招数确实买到了时间，但随着合并率一路走高，维护成本开始指数级上升：种子快照离主分支尖端越来越远，diff、blame 这些依赖历史的操作在残缺 clone 上越来越难伺候。几百个镜像本身也成了一个需要"伺候"的庞然大物。

于是他们退后一步，问了一个第一性原理的问题：如果从一开始就假设"客户端永远在线"，版本控制应该长什么样？

Scion：把"客户端永远在线"当第一性原理

这个问题的答案，就是 Scion。Anthropic 的观察很毒辣：名义上大家都在用 git 的去中心化设计，实际上几乎所有公司都是把它当中心化系统用的——只有一个权威副本。而在 Anthropic，这个"实际上"还要再往前推一步：他们的客户端几乎全是 agent 和 CI 任务，这些客户端"按定义就是在线的"。Git 为离线工作设计的那些优雅特性——每个 clone 都是完整自包含仓库、本地能算 diff 能读 blame——在这种 workload 下，反而成了扩展的枷锁。

所以 Scion 在几个核心原则上和 git 反着来：

• 客户端永远在线。不再假设客户端需要离线工作，协议围绕"服务器永远可达"设计，客户端需要数据时再去取。
• 客户端-服务端不对称。git 里每个客户端都能当服务器；在 Scion 里，查文件历史、算 blame、创建提交、做 merge 和 rebase，全是服务端的事。客户端只维护一个有界的本地对象缓存、把工作副本文件铺到磁盘上、监听文件系统变化。它自己几乎算不了什么，作为交换，它需要的本地数据少得多。
• 版本控制能力全部暴露成 API。git 时代，一个 CI 任务想问"这行代码最后是谁改的"，得先维护一份本地仓库，或者指望厂商 API 恰好有这个接口。在 Scion 里，客户端用的所有查询都有 API，很多任务根本不需要本地仓库——Anthropic 内部的自动 bisect 和 revert 流水线，没有这种廉价的程序化访问根本跑不起来。
• 一切水平扩展。仓库数据是分布式的，每个组件独立扩展；连服务器上都没有一份完整物化的仓库。没有 packfile（git 那种压缩对象包），所以也不需要仓库维护。
• 提交必须便宜、增量、无锁。Scion 里没有 push 的概念，提交、rebase、merge 都在服务端发生。工作单元叫 changeset，本质是 write-ahead log 里的一个条目：不像 git commit 存一个 tree 指针，changeset 存的是相对首父提交变化的文件列表，加上指向 blob 存储里压缩内容的 content-addressed 指针。创建一个提交的成本只和变更大小有关，和仓库总大小无关。
• 工作副本是可选的，默认稀疏。CI 任务要一个 diff，可以直接问服务端要，连 checkout 都省了。真需要文件落盘时，sparse checkout 只拉客户端要的目录，virtualized checkout 按需物化文件——"客户端只为它真正读到的东西付费"。

Scion 的工作单元 changeset：只记录相对父提交变化的文件列表与压缩内容的寻址指针，blame、路径历史等均为按需计算的派生数据。图源：Anthropic 工程博客。

工程实现上，Scion 是一套分层缓存架构：客户端经 socket 连本机的 scion-daemon，daemon 从本区域的 scion-cache 内存流式拉取对象，缓存缺失才回源到读 Spanner 和云存储的 scion-server。每一层的缓存命中率都在 99% 以上，且都不需要长生命周期的状态，扩容很容易。效果数字相当惊人：Scion 基础设施的 CPU/内存开销只有旧 git 镜像方案的二百分之一；checkout 从分钟级降到秒级，快了两个数量级；光是 CI 一项，就释放出了 25% 的 CPU 容量。

Scion 的 checkout 架构：scion-daemon、scion-cache、scion-server 三层，对象全部内容寻址、不可变，任意缓存都可应答。图源：Anthropic 工程博客。

7 个人、5 个月，还有 Claude 自己

数字之外，这篇博客最值得玩味的是"谁造的"和"怎么造的"。Scion 加 Antique（新的代码评审面），外加代码搜索、细粒度的源码 IAM 系统、大批量合入 reviewed 代码的新机制——全部出自一个 7 人团队，5 个月，从 git 全仓迁移完成。

而最妙的细节藏在"我们学到了什么"一节。今年早些时候，团队手写了 git-to-Scion 数据导入管线的第一版原型，自觉良好。直到他们拿到了 Claude Mythropic Preview 的内部版本（对，就是以他们自家模型命名的那个内部版本），让它把整个管线重写一遍——零额外指令。结果：内存占用降到原来的二十分之一，速度快了 4 倍，所有关于导入顺序和数据结构的隐式不变量一个没丢。

品一品这个闭环：Claude 写代码的速度把 Git 写崩了；然后 Claude 又帮 7 个人在 5 个月里写出了替代 Git 的系统。博客里那句"Claude 写代码的能力既是把我们逼到这个境地的原因，也是我们能快速造出高质量可扩展系统的手段"，不是修辞，是字面意义上的事实。这可能是 2026 年关于"AI 写代码"最诚实的一份田野报告：它没有停留在"AI 让程序员更快了"的浅层叙事，而是展示了当 AI 真的成为代码生产主力之后，整个工程栈会被倒逼成什么样。

"编码不再是瓶颈"——这句话值得逐字读

博客开头有一段话，我建议每个做 vibe coding 的人都读三遍。Anthropic 写道：在他们那里，编码已经不再是构建系统或做研究的瓶颈——Claude 能够自主迭代研究循环、微优化复杂程序、从零构建新服务，速度和规模前所未见。现在的瓶颈，是"全部为人类规模建造的开发者基础设施：版本控制、构建和 CI"。

当代码的产量不再受打字速度限制，瓶颈就转移到每一个为"人"设计的环节。合并请求的洪流不会自己变慢，只会冲垮下一个最弱的环节。

这句话把 2026 年的工程现实说透了。过去十年，开发者基础设施的默认假设是：提交代码的是人，人一天写几百行代码，人需要睡觉、开会、review。整个工具链——分支模型、PR 流程、CI 分钟数、review 队列——都是按这个假设调优的。而 agent 把"代码产量"这个变量直接乘了十几倍，假设崩了，工具链就得重调。Anthropic 的原话更狠：合并代码的潜在需求"实际上是无限的"，每拆掉一个瓶颈，代码产量就再上一个台阶。这不是一个会收敛的问题，这是一个会不断把天花板顶高的过程。

值得注意的是，Anthropic 也承认自己是极端样本：他们用 Claude 写软件的比例远超其他公司，所以总是第一个看到"为人类规模建造的工具"在哪里先 strained。但他们判断，其他用 AI 编程工具的组织，迟早会撞上同样的压力点。这篇博客就是提前把撞墙报告发出来。

对 vibe coder 意味着什么：你的下一堵墙在哪里

好，回到我们这些不在 Anthropic 上班的人。这件事和你有什么关系？直接关系是：你今天用 agent 写代码觉得爽，是因为你的"合并率"还很低。但把曲线拉长看——你今天一个人指挥 3 个 agent 并行写代码，明年可能是 30 个 agent 同时改 30 个分支，后年可能是一个 agent 集群 7×24 地重构你的整个代码库。PR 队列、CI 分钟数、review 人力、冲突解决，这些瓶颈会一层一层浮现。Anthropic 的今天，就是高强度 vibe coder 的明年。

有三条判断，现在就可以借鉴到你的工作流里：

• 稀疏思维：别给 agent 整个仓库。Scion 的核心洞察之一是，agent 大多数时候不需要完整仓库。给 agent 最小必要的上下文，既是省 token，也是省 infra。monorepo 里只检出要改的目录；CI 里能调 API 查 diff/blame，就别完整 clone。你的 .gitignore 和 sparse-checkout 配置，值得按"读者是 agent"重新审视一遍。
• 把"问仓库问题"和"改仓库"分开。很多自动化任务（自动 bisect、自动 revert、变更影响分析）需要的只是对仓库的"只读查询"，Scion 把它们做成了廉价 API。你在自己的 CI 里也可以贯彻这个思路：别为了查一行 blame 就拉整个仓库，用 GitHub API、用 shallow fetch、用稀疏检出。
• 为 agent 设计流程，而不是把 agent 塞进给人设计的流程。分支策略、合入节奏、review 机制，默认都是按"几个坐班的人"设计的。当提交者变成"在线、并发、不睡觉的 agent 群体"时，保护分支规则、required review 人数、CI 触发策略都值得重想。Anthropic 造 Antique（新评审面）的动机就在于此：旧的评审面是给人看的，新的要能吞下每天 3 万次变更。

再往大看一层：版本控制可能是第一个被重构的，但不会是最后一个。构建系统、CI、代码评审、issue 跟踪、文档——整个"为人机规模"建造的工具链，都会在 agent 的并发量面前被重新估值。2026 年下半年到 2027 年，我们很可能会看到一波"agent 原生开发者基础设施"的创业和重构潮。Scion 目前没有开源，但它的设计原则已经写在博客里了——client-server 不对称、changeset 增量提交、API 优先、稀疏工作副本。照着思路抄，不犯法；等着别人抄完，自己就成了被优化掉的那个"人类规模假设"。

Git 不会死。Anthropic 自己也说了，对绝大多数仓库，git 的去中心化设计依然是对的。但"默认用 git"这个默认选项，第一次出现了裂缝。裂缝的另一边，是 agent 规模的新大陆——而 Anthropic 已经用 7 个人、5 个月、每天 3 万次合并，先过去探了路，还把路书免费发了出来。这份路书，值得每个认真做 vibe coding 的人读一遍。