Claude把git撑爆了！日合并涨到12倍，Anthropic 7人5个月换掉git

9 月 9 日，Anthropic 内部的代码仓库，一天合并了 30,401 次代码变更。

这个数字单看没什么感觉，我给你换算一下。一天 24 小时，平均不到 3 秒钟就有一次代码合进主干，不分白天黑夜，不休周末。而就在今年 5 月，这个数还只是日均 2,500 次左右。

四个月，变成了原来的十二倍。

然后，git 撑不住了。

Anthropic 前两天发了一篇工程博客，讲的就是这件事。他们用五个月时间，自己写了一套版本控制系统，叫 Scion，把整个 monorepo 从 git 上彻底迁走了。顺手还做了一个代码评审工具 Antique，外加代码搜索、权限系统一堆配套。

看完这篇博客，我脑子里冒出来的第一个念头是，AI 写代码这件事，最先撑不住的环节，根本不在写代码本身。

先简单聊聊 git 是个什么东西，不写代码的朋友可能不太熟。

git 是 2005 年 Linus Torvalds 为了管理 Linux 内核代码写的。当时 Linux 社区一直在用的商业版本控制工具 BitKeeper 收回了免费授权，Linus 一气之下自己动手，几个星期就把 git 的雏形搓了出来。它有一个很核心的设计，每个人电脑上都存着一份完整的仓库副本，所有历史记录、所有版本，全在你本地。你可以在飞机上断着网写代码、查历史、提交，落地了再同步。

这个设计在过去二十年简直完美。程序员是人，人会出差，会断网，会在咖啡馆里蹭不稳定的 Wi-Fi，git 把这些都照顾到了，所以它成了全世界的标准。

但 Anthropic 发现了一个很尴尬的事情。

他们仓库里干活的，绝大多数已经不是人了。是 Claude，是各种自动化任务，是 CI 流水线，是 agent 沙箱。这些东西有一个共同点，它们永远在线。没有一个 agent 会去坐飞机。

git 最引以为傲的离线能力，在 agent 面前一文不值，反而成了拖累。

具体有多拖累，博客里给了几个数字，离谱到有点好笑。他们主分支的历史记录将近 100GB，压缩后的一份工作副本超过 25GB。CI 每天要检出代码大约 2500 万次，这还没算开发环境和研究任务。如果每次都老老实实按 git 的方式去拉，每天的流量会超过 600PB。

600PB 一天。。。

当然他们不会真这么干，git 本身有浅克隆、稀疏检出这些办法，大公司也有内部镜像、仓库快照这些常规操作。Anthropic 全都用过，最高峰的时候同时跑着几百个内部 git 镜像来扛压力。但合并速度越涨越快，这些补丁就越来越难维持，快照刚刷新完就落后主干一大截。

这就像你家水龙头原来一天开十分钟，现在 24 小时全开到最大，你在水管上缠多少圈胶布都没用，管子本身就不是按这个水量设计的。

所以他们换了一根新管子。

Scion 的思路其实挺好理解的，就是承认现实。既然所有使用者都在线，那就没必要每个人都揣着一份完整仓库了。数据全放在服务器上，谁要什么就去拿什么，查历史、算差异、做合并，统统交给服务器。客户端只留一个小缓存，用到哪个文件才拉哪个文件。

换完之后效果非常夸张。整套基础设施占用的 CPU 和内存，只有原来那堆 git 镜像的两百分之一。CI 和研究任务检出代码，从几分钟缩短到几秒钟，光 CI 就省下了 25% 的 CPU 算力。

技术方案本身，还不是这篇博客最让我兴奋的部分，最让我兴奋的是藏在里面的一个循环。

把 git 撑爆的是 Claude，帮他们五个月造出替代品的，还是 Claude。

博客里讲了一个细节，特别有意思。今年早些时候，他们团队手写了第一版从 git 导入数据到 Scion 的管道，当时觉得写得挺好的。后来他们拿到了 Claude Mythos Preview 的早期内部版本，就让它把整个东西重写一遍，没给任何额外指示。重写出来的版本，内存占用少了 20 倍，速度快了 4 倍，而且原来那些隐含的约束条件，比如数据导入的顺序，全都保住了。

然后就是那个让我反应了好一会儿的数字，整个 Scion 加 Antique，再加上六七个配套系统，是 7 个人做的。五个月做完，并且完成了迁移，而这期间每天合并的代码量还涨了十倍。

7 个人，五个月，换掉一家 AI 公司的版本控制系统。

搁在以前，这种级别的迁移，一家公司得投入一大帮工程师，前前后后磨好几年。

聊到这里，很多人可能会担心，那工程师是不是要失业了。

博客里有一段话特别诚实。参与这个项目的所有工程师，现在都认为 Claude 写代码比他们自己写得好。注意，是所有人，而且是这些能自己造版本控制系统的人。

但他们的价值一点没少，只是工作内容变了。

这些工程师现在最重要的工作之一，是对 Claude 说「不」。

博客里举的例子很具体。迁移过程中，好几个系统想知道某个改动是什么时候合进主干的，Claude 写出来的办法是去一行一行硬翻提交记录，而正确做法是直接问代码评审工具。还有一次，Anthropic 内部常用的对抗式评审太过谨慎，觉得另一个内部服务不可信，结果 Claude 就往系统里塞了一堆没必要的校验，把复杂度堆了上去。

这些都需要有经验的工程师站出来拦住。现在团队成员依然会审查系统的每一个改动，只是审查方式变了，看的是这个改动的意图对不对，不再逐行去读代码。

如果你也经常用 Claude Code 或者 Codex，大概会对这个变化有点感觉。读代码的时间越来越少，花在琢磨「它为什么要这么改」上的时间越来越多。一开始难免心虚，总觉得没一行行看过就不踏实，可活儿越堆越多，你迟早得接受，真正需要你的地方，是那几个它会走偏的岔路口。

而且 Claude 写得多，还带来了一个意想不到的好处。博客里说，因为 Claude 能以远超人类的速度写出海量代码，Scion 反而成了他们做过的测试最充分、防护最严密的代码库之一。在那么紧的工期里，他们给每一种遇到过的基础设施交互都做了封闭的模拟测试，还上了模糊测试和复杂的限流。搁在以前，这些都属于「时间允许的话再补」的东西，大部分团队最后都没时间补。

巧的是，同一周 Google 也发了一篇博客，正好能和这事对上。

Google 的工程师让 Gemini 4 Argon 在 ADK 这个 20 万行的 Python 代码库上无人值守跑了 11 个小时，从晚上 9 点 11 分一直跑到第二天早上 8 点 19 分。它最后提了 6 项优化，经过人工评审，只合并了 2 项。

更有意思的是其中一个细节。Argon 改完之后，开源仓库里的 16,892 个单元测试全部通过，看起来完美。结果 Google 内部有 25 个测试目标直接挂了，因为那些测试恰好 patch 了被它挪走的几个导入。

测试全过，不代表没问题。AI 能把活干得又快又漂亮，但它看不到的那些隐性约束，还是得靠人。剩下那 4 项被拒的优化也很说明问题，Google 自己的评价是，模型会想出一些他们自己想不到的创意方案，但有些创意撞上了框架绝不能破坏兼容性的规矩。点子是好点子，只是不知道哪些线不能碰。

AI 越能干，人的判断力反而越值钱，只是这份判断力从「写对」挪到了「拦住」。

回到水管这件事，Anthropic 其实还说了一句更狠的话。

他们说，合并代码的潜在需求几乎是无限的，每移除一个瓶颈，代码量就会立刻再涨一截。

所以 git 只是第一根爆掉的管子。说起来也挺有意思，二十一年前 git 的诞生，就是因为旧工具不够用了，Linus 自己造了一根新管子。二十一年后，轮到 git 自己被换掉，原因还是一样的。

博客最后一部分写得特别坦诚，说这个项目逼着他们重新审视所有按人类速度设计的流程。比如合并队列，传统做法是给仓库加一把全局锁，大家排队一个一个合。可是当几百甚至上千个改动在测试跑着的时候同时合进去，排队这件事本身就不成立了，连 CI 该怎么定义都得重新想。他们最后的选择是放弃全局锁，把测试挪到合并之后、部署之前，改动冲突了就让 Claude 去修，反正它修得比人发现得还快。

我一直觉得，大家聊 AI 编程，聊的都是水龙头。哪个模型写代码更快，哪个工具补全更准，哪家的 agent 能连续跑更久。

但很少有人去看水管。

代码写出来之后要合并、要评审、要测试、要部署、要监控，这一整条链路上的每一个环节，都是过去几十年按人的速度一点点搭起来的。人一天能写几百行，评审能看几十个改动，这些假设被刻进了工具里，刻进了流程里，刻进了团队的分工里。

现在水龙头被拧到了以前的十几倍。

那些我们习以为常的管子，会一根接一根地爆。

当然我也得说句公道话，Anthropic 自己也承认，他们的情况非常特殊。他们用 Claude 写代码的程度远超几乎所有公司，能花在内部的 token 也远远超过一般企业愿意花的量。Scion 不适合拿去替代通用的 git，他们也没打算开源一个通用版本，Scion 只对超大规模、有成群 agent 在疯狂写代码的仓库才有意义。

所以如果你现在用 Cursor 或者 Claude Code 写写项目，完全不用担心 git 明天就不够用。

但他们给了一个时间预判，同类问题在未来 6 到 12 个月内会变得越来越常见。

如果你是团队负责人，现在就可以回头看看自己的流水线。代码评审是不是已经开始排长队了，CI 是不是越来越慢了，合并冲突是不是越来越多了。这些都是水管在发出声音。

很多年前我们总担心的是，水龙头里能不能出水，担心 AI 写的代码能不能跑、靠不靠谱。

现在水来了，而且大得吓人。

接下来要操心的，是家里的管子。

谢谢你看我的文章，我们，下次再见。

/ 作者：青玉白露