AI 一天合 3 万次代码，把 Git 逼到了极限！

admin@yesmiracle.net (万戈) — Thu, 15 Oct 2026 00:00:00 +0000

如果你今年一直在用 AI 写代码，可能已经隐约觉得哪儿不对劲：模型是越写越快，但你围着它搭的那套流程——提交、分支、CI、代码审查——越来越像一条堵住的下水道。代码像洪水往里灌，管道却还是二十年前为「人手敲键盘」设计的口径。

Anthropic 把这件事直接摊到了台面上。10 月 13 日，他们的工程博客发了一篇长文《Redesigning source control at Anthropic》。结论很硬：Git 扛不住他们的负载了，他们花五个月自研了一套版本控制系统，叫 Scion，把整个 monorepo 从 git 迁了过去。

我先说数字。因为这组数字，比任何形容词都有说服力。

先把数字摆上桌

2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码改动；
到了 9 月，这个数字超过 30,000 次——四个月翻了十倍出头；
主分支的历史本身就接近 100 GB，一份压缩后的工作副本超过 25 GB；
每天为 CI 做的代码 checkout 大约 2,500 万次，这还没算开发者环境、Agent 沙箱和研究任务；
如果按最朴素的方式拉取，光这一项每天就是 600 PB 以上的 git 流量；
为了扛住，他们一度同时运行着几百个内部 git 镜像。

我在 Hacker News 上把那条帖子翻了一遍，近千条评论里最扎心的一条，是有人把「100 GB 历史 + 25 GB 工作副本」贴出来后说：这已经不像是一个给人用的仓库了。

但比数字更关键的，是 Anthropic 工程师给出的那句判断：他们其实一直是在把 git 当中心化系统在用，只不过客户端全是永远在线的 Agent 和任务。

Git 没有错，错的是它被当成了中心系统

Git 是去中心化的。每个 clone 都是一个完整、自包含的仓库，能离线算 diff、读历史、跑 blame、checkout 任意版本。对绝大多数仓库来说，这是对的设计，也正是 git 能成为行业标准的理由。

问题在于，Anthropic 的负载已经不在这个设计空间里了。他们在文章里把因果关系讲得很清楚：让 git 优秀的那些性质——离线可用、每个副本都是全集——恰恰在仓库变大、客户端全是在线 Agent 的时候，从优点变成了拖累。

于是他们问了一个非常「AI 时代」的问题：如果我们从第一天起就假设客户端永远在线，版本控制会长成什么样？

这个问题值得每个人停下来想一秒。它不是「怎么把 git 调优」，而是「如果推倒重来会怎样」。Scion 的每一条设计，都是这个问题的直接推论。

更有意思的是，Anthropic 自己承认，这不是全新领域。超大规模 monorepo 是有前人的——Google 的 Piper、Meta 的 Sapling。他们是带着这些「前车之鉴」去建 Scion 的。这句话先记着，后面我要专门算一笔账。

Scion 的五条设计原则

Anthropic 把 Scion 的设计原则列成了五条，每一条都是对 git 某个假设的正面反驳。我把它翻译成人话，并补上「这跟 git 反在哪」：

一、客户端永远在线。 git 假设客户端会离线，所以必须持有完整副本。Scion 反过来，假设服务器永远可达，客户端要什么数据再去取。

二、客户端-服务端不对称。 在 git 里，每个客户端都有能力当一个完整的服务器；在 Scion 里，只有服务端能回答历史、blame、创建提交、做 merge 和 rebase。客户端只维护一个有界的内存对象缓存，把工作副本铺到磁盘上，监听文件变化——它自己几乎算不了什么。代价是客户端本地要存的东西少了一大截。

三、版本控制本身即服务。 git 里，一个 CI 任务想问「这行是谁最后改的」，得先维护一份本地仓库副本，或者祈祷某个厂商 API 恰好提供了答案。Scion 把客户端用的所有查询都做成了 API，很多任务干脆不需要本地仓库。Anthropic 说，他们的自动 bisect 和自动 revert 流水线，没有这种廉价、可编程的访问，根本跑不到现在的规模。

四、一切必须水平扩展。 几百个 git 镜像的时代，容量和磁盘/内存限制很快就顶到天花板。Scion 把仓库数据打散，每个组件独立扩展——任何地方都不存在一份完整物化的仓库副本，连服务端也没有。 没有 packfile（git 那种压缩对象包），也就不需要做仓库维护。

五、提交必须廉价、增量、无锁。 在 git 里你先在本地提交，再 push 去共享。在 Scion 里，每次提交、rebase、merge 都发生在服务端，没有「push」这个概念，但每个操作都必须足够快。创建提交并更新其下游数据结构的成本，必须随改动大小扩展，而不是随整个仓库的大小扩展——否则服务端跟不上。还有一个反直觉的点：Scion 刻意不鼓励 ref（分支、tag 这类指向提交的指针），除了 main 和发布分支之外基本不用——因为「每个服务端都必须达成一致的全局状态」，本身就是个迟早要爆的扩展难题。

这五条里，第四条和第五条是最容易被忽略、但其实最狠的。因为它们不是「优化」，而是把 git 赖以成名的东西直接删掉了。

拆到数据级：changeset 和 derived data

原则是一层，Scion 真正的骨头在数据结构里。

在 Scion 里，工作单元不叫 commit，叫 changeset——它是 write-ahead log（预写日志）里的一条记录。它存的差不多是你在 git commit 里会看到的东西，但有一个关键差别：git 的 commit 存的是指向整棵 tree 的指针，而 changeset 只存「相对第一个父提交有哪些文件变了」的清单，外加指向 blob 存储里压缩文件内容的、内容寻址的指针。changeset 在服务端创建，立刻在所有地方可见。

这么做的好处是吞吐：没有 packfile 要接收，没有锁，没有跨服务端协调，也没有 ref 要挪动。

但 changeset 只记「变了什么」，单靠它回答不了「这行谁最后改的」「哪些提交动过这个文件」。所以 Scion 要从 changeset 再构建一批数据结构：专门给 blame 用的、给 path history 用的，以及给提交图用的 skip list。凡是「不属于 changeset 本身」的东西，他们统称为 derived data（派生数据），并用一套通用机制统一计算。每种派生数据都是递归定义的——一个 changeset 上的取值，由它各个父提交上的取值算出来。

这套设计有三个好处：想加一种新派生数据来加速某个操作，很容易；每种数据都能选「立即算」还是「推迟算」，不用就不物化；客户端看不到这些结构的内部，所以优化它们不影响客户端。Anthropic 说他们后来加过很多次派生数据，比如做 copy detection、做基于路径的文件搜索的新索引。

读到这里，如果你在企业级系统里待过，大概率会升起一种似曾相识感。先按住，第三节我们回来说。

架构：三层缓存，把基础设施缩了 200 倍

Scion 的部署形态不复杂：一小组 scion-server 提供版本控制 API，所有数据内容寻址（一块数据存下就不再变），因此任何服务器都能缓存它而无需跟别人核对——于是服务器可以水平扩展，彼此几乎不协调，本质上是「一群还能现场算派生数据、并把结果写回 Spanner 的大缓存」。

客户端侧走的是分层缓存：

scion-daemon：每个节点上一个，为整台机器缓存对象。大多数节点都要访问这个 monorepo，同节点上的任务复用同一批对象。每个 daemon 从一个周期性刷新的快照起步，然后只跟本区域的缓存服务器说话。
scion-cache：区域缓存，直接从内存里以 daemon 即将消费的磁盘格式流式吐对象，不做 delta 压缩、不算缺失对象。
scion-server：权威源，缓存缺失时去读 Spanner 或对象存储。

这三层响应完全相同的 RPC，所以客户端根本不需要知道缓存拓扑。但 Anthropic 严格强制分层，为的是隔离故障域——不能让一个区域缓存的故障顺着上游把整个系统拖垮。

这套架构的协议设计也值得说一句，因为它跟 git 是反的。Scion 的协商不告诉服务端「客户端已经有什么」，而是只针对客户端想要的那些 tree 和 blob 来谈：从根 tree 出发，客户端查本地库缺哪些 tree，递归请求，再对 blob 重复一遍。每个请求要的都是一个永远不变的、具体的对象，所以任何缓存都能应答——整个流程很像经典的多级缓存。它也是可恢复的，因为没有那个动辄几个 GB 的 packfile 响应。稀疏 checkout、甚至虚拟化 checkout（文件按需物化）都不需要特殊支持，客户端不想要的东西不去请求就行。

结果是一串很硬的数字：每一层缓存的命中率都超过 99%，且不需要长生命周期状态，扩容容易。Scion 基础设施的 CPU 和内存占用，比之前的 git 镜像体系小了 200 倍。 CI 和研究任务的代码 checkout 快了两个数量级——从「分钟级」变「秒级」。光 CI 就省出 25% 的 CPU 容量。

这张表才是重点：五个系统，一条共同的路

写到这里，如果只看 Anthropic 这一家，你会以为这是个孤例。它恰恰不是。

Anthropic 的 Scion 有明确的前人；同一时期，Cursor 的工程师 Vicent Martí 也写了一篇《Git at any scale》，讲他们怎么把 git 托管重写了一遍。我把这几条路线摆在一起，你会发现它们在解同一个方程——只是各自的答案长得不一样：

系统	数据模型	客户端角色	存储与一致性	为谁设计
Git	对象 DAG（packfile）	完整仓库，自己就能当服务器	本地 + 中心托管（GitHub Spokes 类：packfile 复制 + 3PC 共识）	离线分布式的人类协作
Anthropic Scion	changeset（WAL）+ derived data	有界缓存，几乎不算，只管工作副本	Spanner + 内容寻址 blob，无 packfile，无需仓库维护	永远在线的 Agent + 海量 CI
Meta Mononoke + Sapling	服务端 derived data（2017–18）	Mercurial 系客户端	服务端集中，派生数据递归计算	超大规模服务端 monorepo
Google Piper / SrcFS	中心化服务端 monorepo	薄客户端	中心服务端 + 文件系统	公司内部超大 monorepo
Cursor Continuity	WAL（S3 对象存储）	任一节点都可以是主	S3 上的 CAS + rendezvous hashing，无状态	Agent 生成的海量小仓库

这张表里藏着一条很清晰的路线图：大家正在从「每个客户端都是一份完整仓库」，倒向「服务端持有真相、派生数据和索引都在服务端算，客户端只剩下一个薄薄的壳」。

Cursor 那篇里有一段我觉得特别能说明问题。他们的分析是：git 的 packfile 设计，从根上就没为「服务端」考虑过——packfile 是个为了方便本地机器读写而设计的二进制格式，对象的物理排布跟逻辑 DAG 毫无对应关系，读一个对象既要走图上的逻辑跳转，又要走磁盘上的物理跳转。这种「gigabytes 级别的随机游走」，在本地 NVMe 上还行，一放到网络文件系统上就崩。所以 GitHub 当年试过分布式文件系统、试过 NFS、试过 DRBD，最后全栽了，退回到「应用层复制」的 Spokes，也就是把仓库当作**宠物（pet）而不是牛（cattle）**来伺候——因为盘上的仓库是共识的真相来源，每一份都很重要，一份坏了就等于一份没了。

Cursor 的解法是 Continuity：把写前日志（WAL）放到 S3 对象存储里当唯一真相来源，盘上的仓库退化成「热缓存」——哪台机器上有都行，没有就从 WAL 物化回来。没有路由表，没有关系型数据库要运维，没有选主，任意节点都能当主，靠 S3 上的一个原子 CAS 保证正确。这套东西听起来比 Scion 更「去中心化」，但实际上做的是同一件事：把真相从客户端/本地盘搬到服务端，把一致性交给一个够可靠、够便宜的集中存储。

两个团队，两种截然不同的技术栈（Spanner vs S3），最后收敛到同一条路上。这不是巧合。

最辣的一层：Claude 设计的系统，几乎复刻了七年前的 Mononoke

现在我们回来算前面记的那笔账。

Anthropic 的文章里，Scion 的「derived data」被讲得像是他们（或者说 Claude）的新发明。但 Meta 的工程师 sunshowers——Mononoke 的作者之一——在文章发出的第二天写了一篇短文，标题直白到不留情面：《Anthropic’s Scion is heavily inspired by Mononoke》。

他把两张截图并排贴了出来：一张是 Anthropic 描述 Scion 用「derived data」加速 blame，一张是他自己 2022 年在 Oxide 应聘材料里描述 Mononoke 用「derived data」加速 blame。两段话的措辞几乎可以逐字对上。

他的原话是：「模仿的程度远远超出了『英雄所见略同』。Sapling 只被感谢了一句『前车之鉴』，而 Mononoke 一个字都没提——这已经接近抄袭了。」

我得在这里把话说清楚：这是 sunshowers 的单方说法，Anthropic 没有回应，我也无法独立核实「谁先想到」这件事。但即便把这句指控打个折，剩下的事实也足够说明问题——Mononoke 是开源的，它躺在每一个大模型的训练集里。sunshowers 说得很到位：「LLM 会越来越重地索引既有设计。你去问 Opus 或 GPT 关于前述技术，它们会立刻指出跟 Mononoke 的相似之处。」

我觉得这才是整件事里最值得琢磨、也最容易被忽略的一层。它跟版本控制本身没关系，它是关于**「当 AI 开始设计系统，技术传承这件事还怎么运作」**。

过去二十年，一个工程师复用别人的设计，通常是因为他读过那篇论文、看过那套代码、或者跟那个人共事过——引用是一种默认的职业习惯，也是一条可追溯的脉络。现在这条脉络断了：模型把所有人的设计一次性吞进肚子里，吐出来的时候光滑、自洽、看不出出处，而且你不会去追问「这个点子你是从哪儿学来的」，因为输出看起来是崭新的。

sunshowers 的结论很扎心：「向前人致敬，现在比以往任何时候都更容易，也比以往任何时候都更重要。再也没有借口了。」

我不确定 Anthropic 是不是成心不提 Mononoke，我也没兴趣替谁定罪。但我确信一件事：在 AI 生成设计的时代，「引用前置技术」不再是学术礼貌问题，而是整个行业的技术记忆问题。 如果每一代新系统都是「AI 从既有设计里重排」出来的、而没人愿意溯源，那积累下来的知识会以肉眼看不见的速度流失——因为你以为你在建新东西，其实你在无意识地重走老路，且没意识到前面已经有人踩过坑。

这跟我们有什么关系

先把冷水泼上：Scion 不是 git 的通用替代品，Anthropic 自己反复强调这一点。它只对「真·超大 monorepo + 成千上万工程师或一群疯狂写代码的 Agent」才有意义。而且 Anthropic 很坦率地承认，他们愿意为内部用途烧掉的 token 量，超过任何一家现实中的公司愿意花的钱——他们做这个，一半是为自己，一半是拿它当 Claude 能力的试验场。Monorepo 到不了那个规模的公司，照搬 Scion 大概率是自残。

还有一层「厂商叙事」得打折。这篇文章的署名者是 Anthropic 的工程团队，他们一边在讲一段真实的基础设施故事，一边在证明自己那套「无限 token 内部自用」的投入是合理的。文章中那些最漂亮的数字（200x、两个数量级、25% CPU），都是他们自己报的，没有第三方审计。所以正确的读法是：方向可信，绝对值存疑。

但即便如此，里面有三件事对我们是有用的：

第一，瓶颈的位置正在转移。 这句话 Anthropic 写得很清楚：以前写代码是瓶颈，现在写代码不是了。瓶颈变成了「为人类规模设计的开发者基础设施」——版本控制、构建、CI。你自己的团队如果也在大量用 Agent，早或晚会在某个环节上撞到这堵墙，而且通常不是最显眼的那个环节。

第二，「为 Agent 重写基础设施」这个品类，刚刚有了第一个旗舰案例。 上一次我们聊过，多 Agent 时代的「操作层」正在长成一个独立品类——《94 位顶级工程师，只有 8 位还在逐行读 Agent 的代码》。Scion 是同一件事在更底层的一次发生：当 Agent 变成一等公民客户端，那些隐含假设「客户端是人、人偶尔离线、人读得完代码」的系统，都得被重新审一遍。

第三，Anthropic 给出的「对外建议」其实比 Scion 本身更有价值。 他们说得很实在：与其每家都从头造一个 Scion，不如把其中最有价值的思路回填进 git——git 服务端不必和 git 客户端用同一套工作方式；平台可以提供像 Scion 那样的服务端 RPC，甚至可以跨 forge 标准化，让 git 客户端学着去谈；协商协议也不一定非得是今天这个样子。也就是说，下一波机会不在「再写一个 git」，而在「让 git 的服务端长出 Agent 需要的形状」。

写在最后

Anthropic 这篇文章，表面上讲的是「我们换掉了 git」，实际上讲的是一件更普遍的事：AI 写代码的速度，正在倒逼整个软件工程的基础设施换代。

我觉得值得盯紧的有这么几件事：

一是六到十二个月内，多少公司会真的撞上同款瓶颈。Anthropic 押注「不会太久」，但到底是三家、三十家还是三百家，直接决定了这波基础设施换代是「几个大厂的自嗨」还是「一个新品类」。

二是 git 服务端会不会真的标准化出一层 Agent 友好的 RPC。如果 GitHub、GitLab 跟进，影响面就不是一家公司的内部工具了。

三是那个 AI 时代的新问题——当设计和它的出处被模型抹平时，「引用前置技术」会不会变成一种被制度化的要求。这题现在没人答得上来，但它迟早会成为技术史怎么书写的问题。

至于我自己的一个判断：很多人会把 Scion 读成「Anthropic 又炫了一次肌肉」。我读到的是另一层——当一个技术栈的护城河开始从「代码」转向「你有没有那个规模去逼出真实需求」时，先撞墙的人反而拿到了话语权。 Anthropic 不是在证明自己会写版本控制系统，它是在用「全球最疯狂的代码合并量」当入场券，给整套开发基础设施定一个新的默认形状。这比开源一个项目难复制得多。

Mononoke on AI博士 万戈