写代码不再是瓶颈，存代码才是
2026 年 10 月 13 日，Anthropic 在官方工程博客发表《Redesigning source control at Anthropic》，宣布了一件在版本控制史上都算少见的事：他们把主代码仓库从 Git 上迁走了，换上了自研的版本控制系统 Scion。理由一点也不玄乎——Claude 写代码的速度，把为人类规模设计的 Git 基础设施逼穿了。
Anthropic 给出的数字（以下均为官方口径、Anthropic 自述，未经独立验证）是这样的：2026 年 5 月，公司平均每天合并约 2500 笔代码变更；到 9 月，这个数字超过 3 万笔。四个月，十二倍。原文里有一句话值得反复咀嚼：「合并代码的潜在需求几乎无限，我们每移除一个瓶颈，代码产量就会立刻再涨一截。」
换句话说，写代码这件事不再是瓶颈。瓶颈转移到了所有围绕人类规模设计的开发基础设施上：源码控制、构建、持续集成。这正是这篇文章值得所有写码之人认真读一遍的原因——它不是又一篇产品宣传，而是一个基础设施被自己的 AI 产出速度击穿之后，当事人亲手写下的完整事故报告与重建方案。
Git 是怎么被压垮的
先看规模。Anthropic 的仓库是这样的：仅 main 分支的历史就接近 100GB，一份压缩过的工作副本超过 25GB。而每天光是 CI 就要执行约 2500 万次代码检出——这还没算开发环境、agent 沙箱和研究作业。
按 Git 的原始协议天真地拉取，每天会产生超过 600PB 的流量。凤凰网科技在转述时给了一个直观的比喻：相当于每天在内网搬运 1.2 亿部 4K 电影。
Anthropic 不是没做过常规优化。稀疏检出、浅克隆这些业内标准手段他们都上了，巅峰时期内部维护着数百台 Git 镜像。但镜像同步的速度，依然赶不上 Claude 写码的速度——机器复制副本是线性的，agent 生产变更是指数的。
问题的根源在于 Git 的设计假设。Git 为「断网的人类」而设计：每个副本都是全量的、可离线工作的，这是它统治版本控制世界二十年的理由。但这对 AI agent 是灾难——Anthropic 的大多数「客户端」根本不是人，而是永远在线的 agent 和自动化作业，它们中的很多甚至根本不需要本地副本。为一个已经不存在的使用场景支付全量副本的成本，这笔账怎么算都不划算。
Scion 的三个反转
Scion 的前身有迹可循：Google 的 Piper、Meta 的 Sapling 都是超大规模单体仓版本控制的先例。Anthropic 明确说他们借鉴了这两者「来之不易的经验」，但 Scion 建立在一个完全不同的前提上——客户端始终在线。这个前提带来了三个根本性的反转。
第一个反转：从全量副本到小缓存。Git 客户端要拿着整个仓库才能干活，Scion 客户端只维护一个有界的本地对象缓存，历史查询、blame、提交、合并全部通过服务端 API 完成。很多自动化作业直接向服务器提问、直接要答案，根本不下载代码——检出从必需品变成了可选项。这是对 Git 时代最核心假设的颠覆：仓库的权威在服务端，客户端轻到可以随时丢弃。
第二个反转：changeset 替代 commit。Scion 的变更单元叫 changeset（变更集），存储的是相对于第一父提交的变更文件列表，加上指向 blob 存储中压缩内容的指针。changeset 在服务端创建，写入预写日志，创建之后瞬时处处可用，无锁、无跨服务器协调。提交的成本随变更本身的大小扩展，而不是随仓库的总体大小扩展——这在每天三万笔合并的负载下是生死攸关的区别。
第三个反转：虚拟化检出。按目录拉取，读哪一行流式传哪一行。整个系统里——包括服务端在内——不存在任何一份完整物化的仓库副本，数据全部水平分布，扩容就是加机器，不需要仓库维护、不需要打包整理。
三个反转指向同一个世界观：当客户端是 agent 而不是人，版本控制系统就该长成分布式服务，而不是分布式文件系统。
官方实测数字：1/200 的占用
Scion 上线后的实测数字（同样为官方口径）：CPU 和内存占用是原 Git 镜像设施的 1/200；三级缓存架构的每级命中率都超过 99%；CI 和研究作业的代码检出从几分钟降到几秒，快了两个数量级；仅 CI 一项，就为公司省出了 25% 的 CPU 容量。
这套架构分三层：节点级的 scion-daemon、区域级的 scion-cache、权威层的 scion-servers，三者响应相同的 RPC 接口。绝大多数请求在 daemon 和 cache 层就被消化掉，权威层只处理真正的写操作和缓存未命中。
还有一些不出现在性能图表里、但同样重要的改变。合并队列就是一例：当测试运行期间可能有成百上千笔变更落地，人类规模的全局合并队列锁就失去意义了。Anthropic 转向了合并后与部署前的自动化测试——并发变更确实可能冲突，但按照他们的说法，Claude 修复这些冲突的速度比人类发现冲突的速度还快。monorepo 的安全模型也重做了：支持仓库级的富访问控制，可以给单个目录设置权限来保护最敏感的代码，代码审查工具还能表达复杂的语义审批约束，把「只改了注释」和「改了核心逻辑」区分开，让人类审查者把精力花在真正要紧的变更上。
七个人、五个月，和一个经常被说「不」的 Claude
这套系统是七个人在五个月内做出来的。而且不是只做了一个版本控制系统：同期还交付了代码审查平台 Antique、代码搜索、源码控制 IAM 等一整套配套系统，并完成了整个 monorepo 从 Git 的完全迁移。迁移期间，每日合并量还在涨——又涨了十倍。
Anthropic 自己也承认，放在过去，这样一套系统的开发和部署通常要以年计，动用的工程师远不止七个人。
Claude 在其中的角色很微妙：它既是问题的制造者，也是解决方案的一部分。一个常被引用的例子是，团队早年手写了第一版 Git 到 Scion 的数据迁移管道，自认为不错——直到他们拿到早期内部模型 Claude Mythos Preview 的快照，让它重写整个管道。没有任何额外指令，产出的版本内存占用降为原来的 1/20，速度快 4 倍，还完整保留了数据摄取顺序和数据结构方面所有隐式的不变量约束。类似的意外之喜还有不少：Claude 顺手找到了祖先查询的一个算法优化，绕过了团队建的一个索引——专家本需要几天到几周的分析调优才能找到，「然后第二天它又这么干了一次」。
但工程师的价值没有归零，只是换了位置。Anthropic 的工程师自评，现在所有人都认为 Claude 写代码比自己好，但系统级的判断仍由人做。用他们自己的话说：「我们经常的工作是对 Claude 说不。」agent 有时会为了满足某个代码模式而破坏核心系统约束，比如多个系统曾试图线性读取提交日志来暴力查找变更何时落地，而不是去问代码审查工具；有时会针对假想中的威胁过度工程化，给内部服务加上过度的防御性验证。这些都需要人来拦。团队如今依然审查每一次变更请求，但审的不再是每一行代码，而是变更的意图。
还有一个细节颇能说明他们的运维思路：Anthropic 给系统的每个组件都配了一个专职监控的 Claude，起名叫「superfan」——scion-daemon 有一个，scion-cache 有一个，Antique 合并队列也有一个。这些 Claude 盯着遥测数据和日志，「像一个无所事事的老工程师一样不停刷新图表寻找异常」，能发现传统告警根本捕捉不到的细微问题。
边界必须说清楚：这绝不是 Git 的通用替代品
如果你看到这里已经想回去把公司的仓库也迁了，先停一下。Anthropic 在原文里写得非常明确：「Scion 绝非 Git 的通用替代品。」这套设计思路只适用于真正巨大的 monorepo——要么有数万名工程师，要么有大量 agent 在并行写码。普通规模的团队从中得到的只有启发，没有可搬走的东西。
而且 Scion 不开源，也没有发通用版本的计划。原因很实际：它与 Git 差异太大，迁移意味着代码审查、代码搜索、CI 整个开发生命周期全部重做；Anthropic 的内部配套高度定制，其他组织很难采纳。公司自己也点破了一层：他们为内部用途烧 token 的能力，远超任何其他企业愿意支付的水平——这套系统的玩法，本身就建立在别人难以复制的资源之上。
Anthropic 选择做的是分享设计思路，给 GitHub、GitLab 和开源社区提供参考：Git 服务端不必和客户端共享同一套架构，服务端 RPC 可以做得更全面、甚至跨平台标准化，negotiation 协议可以重新设计，稀疏与浅克制的特性也可以组合得更好。他们同时向 Git 社区致意——这个社区花了近二十年把平台扩展到支撑数百万开发者，Anthropic 的贡献范围要窄得多，只是分享了 agent 软件开发如何与这些系统交互的早期观察。他们预测，未来六到十二个月内，这类问题会在其他组织变得常见。
AI 写码把人类规模的基础设施逼穿了
把镜头拉远，这件事真正的信号不在 Scion 本身，而在它印证的趋势。
超大规模版本控制迁移是有历史坐标的：Google 的 Piper、Meta 的 Sapling，当年动用的是数十上百人的团队、数年的迭代迁移。Anthropic 用七个人、五个月做完了同量级的事——而且这五个月里每日合并量还涨了十倍。这不是 Anthropic 的工程师突然变强了，而是写代码这件事的经济学变了：当写码的成本趋近于零，围绕「写码很贵」设计的整条流水线都会过载。
AI 写码把最便宜的环节变得更便宜，于是压力全部涌向最贵的环节：存储、审查、测试、合并。Anthropic 的案例之所以值得逐字读，是因为它是第一个详细公开的样本，展示了当 agent 的产出速度超过人类规模基础设施的设计容量时会发生什么——而且整个故事里最耐人寻味的是 Claude 的三重身份：它制造了压力，参与了消化压力的工程建设，最后还顺手改写了「工程师」这个角色的日常——从逐行读代码的人，变成对 AI 说「不」的人。
对绝大多数团队来说，结论不是「Git 要死了」。Git 依然是世界的主流，Scion 的边界也划得清清楚楚。真正的结论是：当你的团队开始引入 agent 写码，瓶颈会从「写」转移到「管」。代码审查队列的长度、CI 的容量、合并工作流的吞吐、仓库权限的粒度——这些围绕人类速度设计的系统，随时可能成为下一个被逼穿的地方。Anthropic 只是先撞上了墙，然后把墙拆开来给大家看了一眼。至于其他组织的墙什么时候塌，他们给出的时间表是六到十二个月。可以用来验证的时间，不多了。