Claude 写代码的速度，把 Git 搞崩了。
这不是夸张。Anthropic 在 10 月 13 日发布了一篇工程博客（原文），标题很朴素——《Redesigning Source Control at Anthropic》——但开头第一句就足以让每个用 Git 的开发者停下来：
2026 年 5 月，Anthropic 每天合并约 2,500 次代码变更；到 9 月，这个数字超过了 30,000。
四个月，12 倍增长。推动这个数字的主要力量不是团队扩张，而是 Claude——Anthropic 自家的 AI 编码智能体。
当 AI 以机器速度生产代码时，一套为人类协作设计了近 20 年的版本控制系统，开始从内部瓦解。
数字有多离谱
先看几组 Anthropic 公布的数据：
- 主分支历史接近 100 GB，压缩后的工作副本超过 25 GB
- 每天仅 CI（持续集成）就执行约 2,500 万次代码检出，还不算开发环境、Agent 沙盒和研究任务
- 如果每次检出都走传统的 Git 拉取，每天的网络流量将超过 600 PB
600 PB 是什么概念？全球互联网每天传输的数据量大约在数百 EB 级别。一个公司的代码仓库，差点吃掉全球网络带宽的可观份额。
Anthropic 不是没有尝试过标准方案。浅克隆、稀疏检出、promisor remote——Git 生态里所有应对超大仓库的技巧，他们都用了。高峰期，内部运行着数百个 Git 镜像来分担负载。
但这些补丁越来越难以维持。镜像和主分支之间的同步延迟越来越大，diff 和 blame 这些依赖历史的功能在部分克隆上频繁出问题。
用他们自己的话说："编码不再是瓶颈。瓶颈是所有为人类规模建造的开发者基础设施。"
Git 的设计假设被 AI 推翻了
问题的根源不在 Git 本身，而在它的设计假设。
Git 是一个去中心化系统：每个克隆都是完整的、自包含的仓库，可以离线计算 diff、阅读历史、检出任何版本。这个设计对于绝大多数仓库来说是完美的，也是 Git 成为标准的原因。
但在 Anthropic 的场景里，几乎所有"客户端"都是 AI Agent 和自动化任务——它们天生就是在线的。
Git 为离线协作提供的强大能力（本地提交、分布式同步、离线历史查询），在 Agent 时代反而成了负担。每个 Agent 都要维护一份完整的仓库副本，而这个副本每天要跟着 30,000 次合并更新。
Anthropic 意识到了这个矛盾：他们实际上是在把 Git 当作一个中心化系统在用（只有一份权威副本），但 Git 的架构让每个客户端都具备成为完整服务器的能力。这个能力在 Agent 场景下毫无用处，却带来了巨大的存储和带宽开销。
他们问了一个简单的问题：如果从一开始就为"客户端永远在线"设计版本控制，会是什么样子？
答案就是 Scion。
Scion：为 Agent 时代重造版本控制
Scion 的核心设计原则，每一条都直指 Git 的"人类假设"：
客户端永远在线。 Scion 的客户端和协议围绕"服务器随时可达"设计，需要数据时才去拉取，不维护完整的本地仓库。
客户端-服务器不对称。 Git 中每个客户端都能当服务器。Scion 中，服务器负责历史查询、blame、提交、合并、rebase；客户端只负责维护有限的本地缓存、管理磁盘上的工作副本、监控文件变化。
工作副本是可选的。 这是最激进的改变。在 Scion 中，很多任务根本不需要把代码检出到磁盘。CI 任务可以直接向服务器查询两个 commit 之间的 diff，写入操作也可以完全通过 API 完成。确实需要文件时，采用虚拟化检出——按需加载，读多少付多少。
一切可以水平扩展。 Scion 中没有完整的仓库副本，即使在服务器上也没有。数据是分布式的，每个组件独立扩展，不需要 Git 那样的 packfile 维护。
提交廉价、增量、无锁。 Scion 的基本单元是 changeset（变更集），记录相对于父节点的文件变更列表，创建成本与变更大小成正比，与仓库总大小无关。
这些改变带来的效果是立竿见影的：
| 指标 | Git（旧） | Scion（新） |
|---|---|---|
| CPU 和内存占用 | 基准（数百个镜像） | 1/200 |
| CI 检出时间 | 分钟级 | 秒级 |
| CI CPU 容余 | 紧张 | 释放 25% |
（数据来源：Anthropic 工程博客，2026-10-13）
7 个人，5 个月，Claude 也参与了
最值得关注的不是 Scion 的技术设计，而是它的建造过程。
整个项目——Scion（版本控制）、Antique（代码评审）、代码搜索、权限管理系统——由一个 7 人团队在 5 个月内完成。与此同时，每日代码合并量还在持续攀升 10 倍。
Anthropic 在博客中写道："参与这个系统的每一位工程师，现在都认为 Claude 的编码能力超过了他们自己。"
但工程师并没有失业。他们的角色转向了两件事：系统级设计和说"不"。
一个具体例子：早期的 Git-to-Scion 数据迁移管道主要是人写的。当 Claude Mythos Preview 的早期内部版本可用后，团队让它重写整个管道。在没有额外指令的情况下，Claude 产出的版本内存使用降低了 20 倍，速度快了 4 倍，同时保持了所有关于导入顺序和数据结构的隐含约束。
另一个例子：Claude 的对抗性评审（让模型互相找茬）在很多方面极其有效，但也很容易短视——工程师需要把 Claude 从"为假设性问题过度工程化"的倾向中拉回来。
用 The Register 引用的一句话概括："很多时候，工程师的角色就是对 Claude 说'不'。"
不是给你的，但你会遇到同样的问题
Anthropic 在博客结尾做了明确的"免责声明"：Scion 不是 Git 的替代品，不适合大多数组织。
它只在一种场景下有意义：超大 monorepo，成千上万的工程师，或者——像 Anthropic 这样——成群结队的 Agent 在疯狂写代码。而且 Scion 与 Git 差异太大，采用它意味着整个开发生态的迁移。
但 Anthropic 做了一个关键判断：
我们预计这类问题在未来 6 到 12 个月内会变得普遍。让每家使用 Git 的公司单独面对同样的挑战，是对工程资源的低效利用。
这句话值得所有工程团队认真对待。
2026 年，AI 编码工具的渗透率已经不是早期采用者的问题。根据哈佛大学最近一份覆盖 718 家企业的研究（我们之前分析过），到 2026 年 3 月，95% 的样本企业已经引入了 AI 编码智能体。
虽然绝大多数企业的代码量远达不到 Anthropic 的级别，但方向是一致的：AI 生成代码的速度在指数增长，而你的 CI/CD、代码评审、版本控制基础设施还是为人类协作设计的。
Anthropic 给出的建议不是"都来用 Scion"，而是把 Scion 的思想反哺回 Git 生态：Git 服务器不必和 Git 客户端工作方式一样；Git 平台可以提供更全面的服务端 API；稀疏检出和浅克隆可以更好地组合。他们明确表示希望与 GitHub、GitLab 和开源社区合作。
一个时代的注脚
回头看这件事，有一个耐人寻味的细节。
Git 诞生于 2005 年，Linus Torvalds 为了管理 Linux 内核的开发而创建它。那个时代的协作模式是：几百个开发者，离线工作，偶尔同步。
20 年后，代码的主要生产者变成了 AI。每天 30,000 次合并，每次合并背后可能是一个 Agent 在几分钟内完成的任务。Git 的每一个设计决策——完整的本地副本、离线优先、去中心化——都在这个新场景下从优势变成了负债。
Anthropic 用 Scion 证明的不是"Git 过时了"（Git 对 99% 的项目仍然是正确选择），而是一个更深层的道理：当生产代码的主体从人变成 AI，整个软件工程基础设施都需要重新审视。
版本控制只是第一个。构建系统、CI/CD、代码评审、项目管理——这些为人类节奏设计的工具，都会在 AI 代码洪流面前陆续暴露出裂缝。
Anthropic 是第一个撞到这面墙的公司，但不会是最后一个。