git 可能是软件行业最成功的基础设施。过去二十年，它几乎没有对手：开源项目用它，商业公司用它，一个人写脚本用它，几千人的大团队也用它。它的设计哲学甚至成了一种默认答案——离线可用、完全去中心、每个客户端都是完整的仓库副本。质疑 git，在很长一段时间里约等于质疑常识。
上周 Anthropic 发了一篇工程博客，宣布他们把整个 monorepo 从 git 迁走了。迁到他们自己花五个月造的版本控制系统 Scion 上。配套一起换掉的还有代码评审工具（Antique）、代码搜索、权限系统——整条源码管理链路，全部重写。
这不是又一个大厂造轮子的故事。值得你花时间读完的原因是：他们换掉 git 的理由，跟性能无关，跟功能无关，而是 git 的三个基本假设，在 AI 写代码的时代同时不成立了。
先失控的是数字
看 Anthropic 自己给的数据。2026 年 5 月，他们平均每天往主仓库合并 2,500 次代码变更——这个数字已经不低，谷歌级别的节奏。到 9 月，这个数字变成了 30,000 次。四个月，十二倍。
谁在提交这些代码？Claude。Anthropic 内部用 Claude 写软件的强度远超其他任何公司，他们的工程师说，合并代码的潜在需求几乎是无限的——每拆掉一个瓶颈，提交量就立刻再涨一截，看不到放缓的迹象。
30,000 次日合并落在 git 上是什么样子？他们的 main 分支历史接近 100GB，压缩后的工作副本超过 25GB。CI 系统每天要做大约 2,500 万次代码 checkout——还没算开发环境、agent 沙箱和研究任务。如果按 git 的方式天真地拉取，那意味着每天超过 600PB 的 git 流量。
他们当然没有天真地拉取。git 生态里所有给巨型仓库续命的手段他们都用过：浅克隆、稀疏检出、promisor remote、内部镜像、仓库快照。峰值时期，他们运维着几百个内部 git 镜像。这些手段为他们争取了时间，但随着合并速度继续涨，运维镜像本身变成了新的瓶颈——快照离 main 的最新提交越来越远，依赖历史信息的操作（diff、blame）在残缺克隆上越来越难维持。
然后他们停下来，问了一个更根本的问题。
git 的三个假设
git 之所以长成今天的样子，是因为它被设计来服务一种特定的工作方式：开发者是人，人会离线，分布在全球各地，每个人都可能在飞机火车上改代码，所以每个客户端都必须是一个能自给自足的完整仓库——本地算 diff、本地翻历史、本地 blame，全都不依赖网络。
这个设计在人类的尺度上几乎完美。但 Anthropic 发现自己的使用方式早就不是这样了：他们和大多数公司一样，其实把 git 当成一个中心化的系统在用——只有一份权威副本。更关键的是，绝大多数访问仓库的客户端根本不是人，是 agent 和 CI 任务。这些东西按定义就是永远在线的。
一个永远在线的客户端，背着一整套为离线设计的本地副本机制，结果就是：git 那些让它伟大的特性，恰恰在系统地妨碍它扩展。为离线准备的完整副本，意味着每次 checkout 都要搬运海量数据；为去中心准备的分布式协商，意味着服务器要做大量无意义的协调；为人类操作频率准备的存储格式（packfile），在每天几万次提交面前需要持续的维护性压缩。
于是他们反着问：如果从一开始就假设客户端是 agent、永远在线，源码管理应该长什么样？
Scion：把 git 反着设计
Scion 的每一条核心原则，几乎都是 git 的镜像。
客户端永远在线。不假设离线，不为离线准备任何东西，需要数据时现取。
客户端和服务器是不对称的。git 里每个客户端都能当服务器；Scion 里服务器回答所有问题——文件历史、blame、提交、合并、变基，全在服务端做。客户端只维护一个有界的本地缓存、把文件摆到磁盘上、监听文件系统变化。它自己几乎什么都算不了，代价是本地需要的数据量少得多。
版本控制即 API。用 git 的时候，一个 CI 任务如果想知道「这一行最后是谁改的」，它得自己在本地维护一份仓库副本。Scion 把客户端用的所有查询都开放成 API，于是大多数任务根本不需要本地仓库。他们内部的自动二分定位和自动回滚流水线，离开这种廉价可编程的访问就不可能跑起来。
提交必须廉价、增量、无锁。git 是本地提交再推送；Scion 里提交、变基、合并全发生在服务器上，没有推送这个动作。一次提交的代价只随这次改动的大小走，不随仓库总体积走——否则服务器跟不上。分支和标签这类全局引用被刻意弱化，因为「所有服务器都要达成一致的全局状态」本身就是一个 looming 的扩展性问题。
工作副本是可选的，并且默认稀疏。每天几千万次 checkout 的体量下，能不检出就不检出：CI 要某个提交和合并基点的 diff，直接问服务器要；很多写入负载也完全走 API，文件根本不落盘。非检出不可的时候，也只检出声明需要的目录，文件按需虚拟化。
整套系统的实现也贯彻同一个思路：变更集只记录改了什么，blame、路径历史这些「派生数据」用统一的递归机制从变更集算出来，想加新的索引就加，客户端完全无感；所有数据内容寻址、写入后不再变化，所以任何服务器都可以随便缓存，服务器群本质上就是一群会算派生数据的大缓存，横向扩就行。
值得一提的还有效率账：迁移后光是 CI 一项就省下了 25% 的 CPU 容量。
比系统更有意思的是建造过程
Scion 这个故事里，真正值得多看两眼的是建造过程本身。
七个人，五个月，造了 Scion、Antique 评审工具、代码搜索、权限系统，外加六七个相关系统，同时完成全量迁移——而且是在日合并量翻十倍的炮火中完成的。放在过去，这种量级的源码管理系统迁移，任何公司都得按年规划、动用几十上百人的团队。
怎么做到的？答案绕回了故事开头：Claude 写代码的能力既是把他们推进这个坑里的原因，也是他们能从坑里爬出来的工具。Scion 项目启动的时间点，恰好赶上 Claude 内部两个新版本可用，开发速度被实实在在地抬了一档。
但更有信息量的是工程师在这个过程中扮演的角色。参与项目的工程师现在全都承认 Claude 写代码比自己强。他们的价值不在写代码了，在两个地方。
一个是高层判断：系统之间怎么连接、设计上怎么取舍、目标规模定在哪。这些没有正确答案的问题，agent 答不了。
另一个是说不行。博客里的原话：工程师的角色经常是告诉 Claude “no”。agent 会为了满足一个本不该存在的模式而违反系统的核心约束——迁移过程中反复出现的事故形态是：某个系统想知道一个变更是什么时候合进 main 的，正确做法是去问评审工具，但 agent 的选择是暴力地把提交日志从头到尾线性扫一遍。对抗性评审也一样，有效但短视，工程师得把 Claude 从「为了假想中的担忧而过度设计」里拽回来。
评审的方式也变了。团队仍然审查每一个变更请求，但看的是变更的意图，不再逐行读代码。
被换掉的从来不只是 git
Anthropic 自己在博客里写得很克制：他们分享这些只是给面临同类挑战的团队一个参考，明确说了 Scion 绝不是 git 的通用替代品，也说了他们预计短期内没多少组织会遇到这种规模的问题。
这个克制是诚实的。但「短期内没多少组织会遇到」和「这个方向不成立」是两回事。日合并 30,000 次确实还很遥远，可顺着同样的逻辑往回看，被击穿的远不止源码管理。
git 的三个假设——写代码的是人、人会离线、提交频率在人类范围内——是过去五十年几乎所有开发工具的隐含地基。IDE 假设敲代码的是人，一次改一个文件；代码评审假设逐行读的人来得及看完每个变更；CI 假设一天跑几百上千次构建已经很频繁；甚至 git 工作流本身——feature branch、pull request、merge review——都是按人类协作的节奏设计的流水线。
这些假设现在在同一条船上。当你的团队里一半提交来自 agent，评审逐行读代码这件事就先死了；当 agent 一天产出几十个变更请求，pull request 的队列礼仪就跟着死了；当构建次数从几百涨到几万，CI 的计费模型和排队策略也得跟着改。git 只是第一个被体量压垮的，不是唯一一个。
我们自己最近的经历是个微缩版：工作室的 AI 助手在终端里越装越多，每个工具都要单独配模型、单独盯额度，一个月下来发现配置管理和账单追踪比写代码本身还费劲——这就是「为人类单独使用设计的工具，在 agent 成群的场景下开始漏水」的日常版本。于是我们给所有助手套了一个网关统一管（上期写的就是这件事）。Anthropic 在源码管理上做的事，和这个在结构上完全一样：工具没变，使用工具的规模和主体变了，于是工具本身必须重做。
接下来轮到谁
顺着「为人类设计」这个筛子往下捋，候选清单很长。文档工具假设阅读速度是人的速度；项目管理软件假设任务粒度按天按周排；监控告警假设看仪表盘的是值班的人，告警频率以人的反应时间为上限；数据库管理台假设执行查询的人知道自己要什么。
这些假设不一定都会被击穿，但每一个都值得重新检查一遍：它的设计里有多少成分是在照顾人的局限——人的记忆、人的反应速度、人的注意力窗口——而这些成分在 agent 成为主要使用者之后，会从资产变成负债。
Anthropic 用七个人五个月的时间证明了另一件事：重造这些工具的门槛，正在被 AI 自己拆掉。过去「重写基础设施」是大厂的奢侈品，现在它是七个人的季度项目。工具的更替速度会跟上需求的速度——这大概是 Scion 这个故事里，对不处在日合并三万次体量的普通团队来说，最实际的一条信息。
git 不会被取代，至少短期不会。但它「默认答案」的时代结束了。下一个十年里，软件开发工具链的每一环都会被拿出来重新问一遍同一个问题：这个设计里，有多少是为了人？如果答案是「大部分都是」，那它迟早会遇到自己的 Scion 时刻。
原文：Redesigning source control at Anthropic（Anthropic 官方工程博客，2026-10-13）
