Anthropic 把 Git 扔了！7 人 5 个月自研 Scion，日合并代码从 2500 暴涨到 3 万次
内容提要
Anthropic因AI写代码速度激增导致Git不堪重负，遂自研版本控制系统Scion。其核心设计为服务端承担计算、客户端极瘦、内容寻址、无锁提交，使基础设施需求缩小200倍，检出速度提升两个数量级。Scion多由Claude编写，7人团队5个月完成迁移。文章指出，当写代码成本趋近于零，版本控制、CI等为人类速度设计的环节将依次成为瓶颈。
延伸解读
Scion 的适用边界：并非通用替代品
Anthropic 明确表示 Scion 不是 Git 的通用替代品，它只对拥有数万名工程师或大批智能体高频写代码的超大 monorepo 有意义。Scion 不打算对外提供，且与 Git 差异巨大，需要配套的代码评审、搜索和 CI 工具，内部版本高度定制。因此，对于大多数团队而言，直接迁移到 Scion 并不可行，但可以借鉴其设计思路。
与 Piper、Sapling 的对比：超大规模单仓库的三种路径
文章将 Scion 与 Google 的 Piper 和 Meta 的 Sapling 并列。Piper 是中心化系统，底层用 Bigtable 后迁 Spanner，其“云端客户端”让本地副本极小，平均不到 10 个文件。Sapling 可扩展且对用户友好，客户端兼容 Git 仓库。Scion 则面向“永远在线的智能体”，采用变更集加派生数据，以服务端为核心。三者都针对超大规模单仓库，但 Scion 的新意在于主要写代码的是 AI。
工程师角色的转变：从写代码到定设计与说不
在 Anthropic 的实践中，工程师的工作重心已从编写代码转向理解跨系统的高层组件、做设计取舍，并经常对 Claude 说“不”。团队依然评审每一个变更请求，但关注的是意图而非逐行代码。此外，合并队列等为人类速度设计的流程在智能体规模下需要重新思考，例如他们未能复制全局锁，转而投入合并后与部署前的自动化测试。
对多数团队的启示：提前识别人类速度瓶颈
文章指出，当写代码成本趋近于零，版本控制、构建、CI、合并队列、代码评审等为人类速度设计的环节会依次成为瓶颈。Anthropic 预测这类问题将在未来 6 到 12 个月内变得更普遍。对多数团队来说，今天未必需要自研 Scion，但值得提前思考：CI 有多少时间花在拉代码上？仓库工具链是否默认人类速度？当 Agent 数量翻 10 倍，哪一环会先垮？
Q&A
Anthropic 为什么要放弃 Git 自研 Scion？
因为 AI 写代码速度激增，Anthropic 每天合并的代码变更从 2026 年 5 月的约 2500 次暴涨到 9 月的 3 万次以上，Git 在这种负载下彻底过载。Git 的去中心化、离线可用设计在客户端永远在线的智能体时代反而成了负担，因此 Anthropic 用 5 个月时间由 7 人团队自研了版本控制系统 Scion 并完成迁移。
Scion 的核心设计原则有哪些？
Scion 有六条设计原则：1. 客户端永远在线；2. 客户端与服务端不对称，历史查询、提交、合并等全由服务端完成；3. 提供完整源码服务并通过 API 暴露，支撑大量新应用；4. 一切必须水平扩展，数据分布式存储，不存在完整物化的仓库；5. 提交廉价、增量、无锁，提交和合并全在服务端发生；6. 工作副本可选且天生稀疏。
Scion 相比 Git 带来了哪些性能提升？
Scion 使基础设施的 CPU 和内存需求比之前的 Git 镜像体系缩小 200 倍，CI 与研究任务检出代码快两个数量级，从分钟级降到秒级，仅 CI 一项就节省 25% 的 CPU 容量。每一层缓存命中率超过 99%，客户端和缓存都不再需要做仓库维护。
Scion 是如何处理提交和合并的？
在 Scion 中，提交、变基、合并全在服务端发生，没有 push 这回事。创建提交的成本只跟改动大小有关，跟仓库总量无关。提交的基本单位是“变更集”，是写前日志中的条目，存储相对于第一个父节点发生变化的文件列表及内容寻址指针。变更集在服务端创建后立刻全局可用，没有 packfile、没有锁、没有跨服务器协调。
Claude 在 Scion 的开发中扮演了什么角色？
Claude 既是问题的制造者也是解决方案的建造者。Scion 本身大部分由 Claude 编写。团队让 Claude Mythos Preview 重写“Git 到 Scion”的摄取管线，结果内存占用降低 20 倍，速度提升 4 倍，同时保留了所有隐含不变量。7 人团队在 5 个月内不仅做了 Scion，还做了代码评审工具 Antique 及另外半打相关系统，并完成全量迁移。
Scion 是 Git 的通用替代品吗？Anthropic 会开源吗？
不是。Scion 只对“数万名工程师或大批智能体高频写代码”的超大 monorepo 有意义，不是 Git 的通用替代品。Anthropic 明确表示不打算对外提供，因为它与 Git 差异巨大，需要配套的代码评审、搜索和 CI，且内部版本高度定制。但 Anthropic 希望把经验反哺给 Git 生态，包括服务端与客户端不同构、提供完整服务端 RPC、改进协商协议等。
Anthropic 认为 AI 时代软件开发的下一个瓶颈是什么？
Anthropic 认为当写代码的成本趋近于零，整个软件开发生命周期里所有为人类速度设计的环节都会依次变成瓶颈。版本控制是第一个，构建、CI、合并队列、代码评审都排在后面。官方预测这类问题将在未来 6 到 12 个月内变得更普遍。
