Anthropic 用 Claude 换掉了 git：七个人五个月做出自研版本控制，以及团队用 Claude 写代码的几条经验

Anthropic 工程博客 2026 年 10 月 13 日发了一篇长文，讲他们为什么、又是怎么把内部的代码仓库从 git 迁到一个自己写的版本控制系统 Scion 上的。

先说结论：

• 瓶颈换了地方。 Claude 写代码太快，2026 年 5 月 Anthropic 平均每天合并约 2,500 个代码改动，9 月超过 3 万个。为人的速度设计的开发基础设施（版本控制、构建、CI）成了最慢的一环。
• 七个人，五个月。 他们做出了 Scion，把整个 monorepo 从 git 迁了过去，同时还做了代码评审工具 Antique、代码搜索、权限系统等。这期间每天合并的改动量又涨了 10 倍。参与的工程师都认为 Claude 写代码已经比自己强。
• 对用 Claude Code 的团队最有用的是经验那部分： 工程师的主要作用变成了对 Claude 说“不”，挡住它违反系统核心约束的做法；对抗式评审有效，但容易把系统设计得过度复杂；每个改动仍然有人审，但审的是意图，不再逐行读。

Scion 本身不开源，文章也明说它不适合一般团队拿来替代 git。这篇整理文章的内容，最后一节是本站的看法，标明了。

git 为什么撑不住了

文章先承认他们的情况很特殊：Anthropic 用 Claude 写软件的量远超几乎所有公司，所以往往最先碰到为人设计的工具撑不住的地方。几个数字：

	规模
主分支的历史	接近 100 GB
压缩后的一份工作副本	超过 25 GB
CI 每天检出代码的次数	约 2,500 万次，还不算开发环境、代理沙箱和研究任务
如果每次都完整拉取	每天超过 600 PB 的 git 流量

git 是分布式的：每个克隆都是一份完整的仓库，离线也能看历史、算差异。对绝大多数仓库这是对的设计。他们用遍了 git 处理大仓库的办法：浅克隆、稀疏检出、按需拉取、内部镜像、存在对象存储里的仓库快照，最多时运营着几百个内部 git 镜像。合并速度越快，这些办法越难维持：快照离主分支越来越远，在部分克隆上维持 blame、diff 这类依赖历史的操作越来越费劲。

他们注意到一件事：和大多数公司一样，他们其实是把 git 当成集中式系统用的，只有一份权威副本；而几乎所有的客户端都是代理和任务，天生在线。git 为离线、分布式工作做的设计，反而成了规模的障碍。于是问题变成：如果从一开始就假设客户端永远在线，版本控制该长什么样？

Scion 的设计思路

大仓库的版本控制有前人做过，比如 Google 的 Piper 和 Meta 的 Sapling，Scion 借鉴了它们的经验。五条原则：

原则	意思
客户端永远在线	不要求客户端有完整的仓库，需要什么数据再取
服务器干重活	查历史和 blame、创建提交、合并、rebase 都在服务器上做。客户端只有一个有上限的本地缓存，自己几乎算不了什么，换来的是本地需要的数据少得多
一切都能横向扩展	数据分布存储，哪里都没有一份完整展开的仓库，服务器上也没有；没有 git 的打包文件，也就不需要仓库维护
提交便宜、增量、无锁	提交、rebase、合并都在服务器上发生，没有“推送”这一步；成本只和改动的大小有关，和仓库多大无关。分支、标签这类需要所有服务器达成一致的全局状态尽量少用
工作副本可有可无，天生稀疏	很多 CI 任务只需要问服务器要一个 diff，根本不检出；要检出也只取用到的目录，文件读到才下载

文章强调服务器端接口的价值：用 git 时，一个 CI 任务想知道“这一行最后是谁改的”“两个提交是什么关系”，要么自己维护一份仓库，要么指望托管平台的接口刚好有。Scion 把客户端用的所有查询都开放成接口，很多任务就不需要本地仓库了。他们的自动二分查找和自动回滚流程，没有这种便宜的程序化访问就做不到这个规模。

效果：

• 基础设施的 CPU 和内存占用，是原来 git 镜像的 1/200。
• CI 和研究任务检出代码快了两个数量级，从几分钟变成几秒；光 CI 就省下 25% 的 CPU。
• 各层缓存的命中率都在 99% 以上。

用 Claude 做这件事的经验

这是文章里对一般团队最有用的部分。

Claude 既是问题的来源，也是解决的办法。 他们开始做 Scion 时，Claude Mythos Preview 和 Claude Tag 刚好在内部可用。一个例子：从 git 导入数据到 Scion 的流水线，第一版主要是人手写的，他们觉得写得不错。拿到 Mythos Preview 的早期内部版本后，让它把整个流水线重写一遍，没有给别的指示，它写出的版本内存占用是原来的 1/20，速度快 4 倍，导入顺序和数据结构上那些没写出来的约束也都保住了。

工程师的价值没有变少，但工作变了。 参与的工程师都认为 Claude 写代码比自己强。工程师提供的是对系统之间关系的理解、设计上的取舍，以及想解决什么问题、要达到什么规模的判断。

很多时候工程师的作用是对 Claude 说“不”。 代理有时为了套用一个本来就不该允许的模式，会违反系统的核心约束。迁移期间这种情况尤其多，例子是好几个系统想知道“某个改动什么时候合进主分支”，办法是从头逐条读提交日志，而不是去问代码评审工具。

对抗式评审很有效，但会近视。 Anthropic 大量使用对抗式评审（让一个 Claude 专门挑另一个的毛病）。它的问题是会为了假想的风险过度防御：有一次评审对另一个内部服务过于不信任，结果 Claude 加了一堆多余的校验和复杂度。这需要有经验的工程师把它拉回来。

每个改动仍然有人审，但审的是意图。 团队成员审每一个改动请求，但看的是这个改动想做什么，不再逐行读代码。

测试和防御反而做得更足了。 因为 Claude 写代码快，即使时间很紧，他们也为每一种遇到过的基础设施和版本控制交互做了密闭的模拟环境，还有模糊测试和精细的限流。文章说 Scion 是他们做过的测试最充分、防御最好的代码库之一。Claude 还顺手找到过一些大的优化，比如祖先查询漏用了一个索引，换成专家可能要分析调优好几天甚至几周。

安全按目录来管。 Scion 支持给单个目录设权限，保护最敏感的代码，又不失去 monorepo 的好处。代码评审工具能表达语义上的约束，比如区分只改注释的改动和改敏感逻辑的改动，让人把注意力放在最要紧的改动上。

运维交给“铁杆粉丝”。 团队大量使用 Claude Tag（Slack 里的 Claude）。他们给每个组件开一个 Slack 频道，让一个 Claude 只盯着这一个组件的健康状况，能看遥测和日志，像一个没别的事可干、一直刷图表找异常的资深工程师。传统的告警照样有，但这些 Claude 能发现告警发现不了的细微问题。

为人设计的流程要重新想。 合并队列在代理的规模下就不太合理了：测试还在跑，可能已经有几百上千个改动合进去了，CI 是什么意思？他们做不到业界常见的“合并队列上一把全局锁”，改成投入合并之后、部署之前的自动测试。这意味着同时合进去的改动可能冲突，但 Claude 修冲突通常比人发现冲突还快。

对别的团队意味着什么

文章自己的说法很克制：

• Scion 不是 git 的通用替代品，只对真正巨大的 monorepo 有意义：几万名工程师，或者成群结队写代码的代理。
• Anthropic 内部能花的 token 远超一般公司愿意花的，这么做一方面是自己的需要，一方面也是测试 Claude 的能力。
• Scion 和 git 差别很大，要迁就得把整个开发流程都迁过去，还需要配套的代码评审、代码搜索和 CI，所以很难做成别人能用的产品。
• 但他们预计未来 6 到 12 个月，这类问题会越来越常见。他们希望 git 平台借鉴 Scion 的思路，而不必脱离 git：git 服务器不必和客户端一样工作；托管平台可以提供完整的服务端接口；拉取时的协商协议可以改；稀疏和浅克隆的各种功能可以组合得更好。

本站的看法：能直接借鉴的几件事

下面是本站的整理，不是文章原话。绝大多数团队离“每天合并 3 万个改动”很远，但用 Claude Code 的团队已经能碰到其中几件事：

• 把系统的核心约束写下来。 文章里 Claude 违反的往往是“没写出来的规矩”。这类约束写进项目的 CLAUDE.md，比每次审出来再改省事，见《CLAUDE.md 怎么写》。
• 审 PR 时先看意图。 让 Claude 在 PR 里写清楚改了什么、为什么、风险在哪，审的人先判断方向对不对，见《提交之前让 Claude Code 先审一遍》。
• 让 Claude 审 Claude 时，说清楚信任边界。 否则评审会对内部服务、内部输入过度防御，把代码改得越来越复杂。
• 大仓库先让 Claude 只看手上那块。 稀疏检出和按目录的规矩，见《大仓库和 monorepo 里用 Claude Code》。

参考

• Redesigning source control at Anthropic（Anthropic 工程博客，2026-10-13，作者是 Anthropic 的版本控制团队）