Anthropic 自研版本控制 Scion：AI 写代码后小团队该先改什么
开发实践
要点 2026 年 5 到 9 月，日合并约 2,500 到 30,000+。自研 Scion，但不是通用场景下的 Git 替代品。
原文页面标题与导语截图。来源：Anthropic，2026-10-13
我是 Evan，独立开发者，平时做开源工具，写代码的活越来越多交给 AI。读完 Anthropic 这篇《Redesigning source control at Anthropic》，我最大的感受不是“又一家大厂自研了个系统”，而是：代码不再稀缺之后，卡脖子的地方换了。原文开头就把话挑明了：
"The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI."（译：现在的瓶颈，是所有按人类规模搭建的开发基础设施：版本控制、构建和 CI。）
所以这篇不劝你换工具。我想回答的是：Anthropic 被逼着重做的那些环节里，哪些做法小团队今天在 Git 上就能用，哪些别学。
原文图注：2026 年 1 月至 9 月，每天合并进 monorepo 的改动数。来源：Anthropic，2026-10-13
2026 年 5 到 9 月的日合并量，原文是这么写的：
"In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day."（译：2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码改动；到 9 月，每天合并超过 30,000 次。）
做出 Scion 的时间和人数，原文是这么写的：
"In order to support this growth, we built Scion, an in-house version control system, and fully migrated our monorepo from git in five months."（译：为了撑住这波增长，我们做了自研版本控制 Scion，并在 5 个月内把 monorepo 从 Git 迁完。）
"A team of seven people built both Scion and Antique (our code review tool, which we could easily write a whole other blog post about), not to mention half a dozen related systems, and fully migrated to them in five months."（译：一个 7 人团队做出了 Scion 和 Antique（他们的代码审查工具，够单独再写一篇），外加五六个相关系统，并在 5 个月内迁完。）
AI 写代码之后，为什么 Git 会扛不住？
先说清楚：扛不住的是 Anthropic 那种体量，不是你的仓库。原文给的数字是这样的：
- 主分支历史“almost 100 GB”（接近 100 GB），压缩后的工作副本“over 25 GB”（超过 25 GB）；
- 光 CI 每天就有“on the order of 25 million code checkouts”（约 2,500 万次检出），这还没算开发环境、Agent 沙箱和研究任务；
- 如果每次都老老实实拉一遍，“that would be over 600 PB of git traffic per day”（译：每天的 Git 流量会超过 600 PB）。
Git 本身有浅克隆、稀疏检出、promisor remote 这些“只拿一部分”的工具，大仓库也有内部镜像、放在对象存储里的快照（seeds）这类常规招数。Anthropic 说这些他们全用过：
"at our peak, we operated several hundred internal git mirrors to deal with the load."（译：最高峰时，我们运维着几百个内部 Git 镜像来扛负载。）
这些办法争取了时间，但合并速度越快越难维护：seeds 在两次刷新之间离 main 的最新提交越来越远；diff、blame 这类依赖历史的操作，要在部分克隆上保持可用，也越来越费劲。
原文在这里放了一张“扩展 Git 检出的典型架构”图，说明镜像加对象存储快照的扩容方式，见 Growing our monorepo。
关键的一步反思是：他们和大多数公司一样，其实是把 Git 当中心化系统用——只有一份权威副本，而几乎所有客户端都是 Agent 和任务，天然在线。Git 为离线、分布式工作设计的优点，反而成了扩展的阻力。
Scion 的四条设计原则，用白话怎么理解？
Anthropic Scion 的设计，原文列了好几条原则，我挑和小团队最相关的四条，用白话讲：
1. 客户端永远在线。 Git 假设你可能断网，所以每个克隆都得是完整仓库。Scion 反过来，假设服务器永远连得上，客户端用到什么数据再取什么。
2. 计算放服务端，客户端只留有限缓存。 文件历史、blame、创建提交、合并、变基都在服务端做；客户端只维护“a bounded local object cache”（一个有上限的本地对象缓存），负责把文件摆到磁盘上、监听文件变化。客户端自己算不了多少，但本地需要的数据少得多。而且客户端用到的查询都开放成 API，原文说很多任务因此“don’t need a local repository at all”（根本不需要本地仓库）。
3. 工作副本是可选的，默认稀疏、虚拟化。 比如 CI 要拿某个提交和它 merge base 之间的 diff，直接问服务器就行，不用检出。真要文件落盘时，协议以稀疏检出（只拿你要的目录）和虚拟化检出（按需物化文件）为中心，“the client only pays for what it actually reads”（译：客户端只为实际读到的内容付费）。
4. 提交要便宜、增量、无锁。 所有提交、变基、合并都在服务器上发生，所以没有 push 这一步，但每个操作都得快：
"The cost of creating a commit and updating its downstream data structures has to scale with the size of the change, not the overall size of the repo"（译：创建一个提交并更新其下游数据结构的成本，必须随改动大小增长，而不是随整个仓库的大小增长。）
落到数据结构上，Scion 的基本单位叫 changeset：不像 Git 提交那样指向整棵树，而是只记录相对第一个父提交变了哪些文件，加上指向对象存储里压缩内容的内容寻址指针。blame、路径历史这些查询需要的结构，统一当作“派生数据”另外计算。
changeset 的结构示意图在原文 Data structures。
原文图注：Scion 的检出架构。来源：Anthropic，2026-10-13
Scion 比 Git 快多少？
原文给出的效果，我原样列出：
- 基础设施的 CPU 和内存需求比之前的 Git 镜像体系“200x smaller”（小 200 倍）；
- CI 和研究任务检出快了“two orders of magnitude faster (in seconds rather than minutes)”（两个数量级，从几分钟变成几秒）；
- “CI alone realized a 25% CPU capacity win”（光 CI 就省出了 25% 的 CPU 容量）；
- 缓存体系每一层“maintains a cache hit rate of over 99%”（命中率都在 99% 以上）。
原文图注：在原生 Scion 仓库上观察到的性能提升。来源：Anthropic，2026-10-13
这些数字很亮眼，但对小团队来说，真正值得抄的是背后的思路：能不要的数据就别搬，能问的就别算。
AI 写的代码，人还需要审查吗？
需要，但审法变了。代码产量上来以后，人工审查很容易成为新的卡点，也就是常说的 AI code review bottleneck。这是原文里我觉得最有价值的一段。
团队的工程师都认为 Claude 写代码比自己强，但原文说：
"Very often, we found that the role of the engineers was to tell Claude “no.”"（译：我们常常发现，工程师的角色就是对 Claude 说“不”。）
原因是 Agent 有时会为了迎合一个本就不该允许的模式，违反系统的核心约束。原文举的例子：迁移期间有好几个系统想知道某个改动是什么时候合进 main 的，做法是线性地把提交日志读一遍去暴力查找，而不是去问代码审查工具。
第二个坑是对抗式审查。Anthropic 大量使用 adversarial review，原文承认它在很多方面非常有效，但也可能“myopic”（短视）。例子是：有一次审查对“是否信任另一个内部服务”过度防御，结果 Claude 加了过多的校验和复杂度，需要有经验的工程师把它拉回来，别为假想的问题过度设计。
第三，审查方式本身变了：
"Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code."（译：团队成员仍然审查这个系统的每一个变更请求，但现在看的是改动的意图，而不是逐行读代码。）
原文还提到一个例子：他们早期手写了 git 到 Scion 的摄取管线原型，自认为不错，直到拿到 Claude Mythos Preview 的一个内部早期快照，让它整体重写，“with no further instructions”（没有给更多指示），产出的版本内存少用 20 倍、快 4 倍，同时保留了摄取顺序和数据结构上的所有隐含不变量。
Scion 和 Antique 代码库每周合并改动的图在原文 What we learned building Scion。
小团队怎么在 Git 上用 Scion 的思路？
下面每一条，我都先写原文怎么说，再写我给小团队的建议。请注意区分：前者是 Anthropic 的做法，后者是我的建议，不是原文内容。
a. CI 能用 API 问的，就别克隆
原文出处：
"With Scion, all of the source control queries the client uses are also exposed via API, so in many cases jobs don’t need a local repository at all."（译：在 Scion 里，客户端用到的所有版本控制查询也都通过 API 开放，所以很多情况下任务根本不需要本地仓库。）
建议： 回头看看你的 CI 和脚本，有多少 git clone 只是为了问一个问题：最近谁改过这个文件、这个 PR 改了哪些路径、某个 tag 指向哪个提交。这类问题很多代码托管平台的 API 就能答，没必要拉整个仓库。
非克隆不可时，用 Git 自带的 sparse checkout 和部分克隆，只拿需要的那部分：
# 只拉提交和树，文件内容按需下载；并且只检出顶层文件
git clone --filter=blob:none --sparse https://github.com/you/repo.git
cd repo
git sparse-checkout set packages/api docs
# 只需要最新一份代码时（例如构建产物），用浅克隆
git clone --depth=1 https://github.com/you/repo.git注意：浅克隆和部分克隆上的 blame、长历史 diff 会变慢或受限，这正是原文说 Anthropic 维护起来越来越费劲的地方。所以要按任务选：只构建用 --depth=1，要看历史用 --filter=blob:none。
b. 把系统硬约束写给 Agent，审 AI 代码先看意图
原文出处：
"Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place."（译：Agent 有时会为了满足一个本就不该被允许的模式，违反系统的核心约束。）
建议： 小团队没有那么多资深工程师在旁边说“不”，那就把“不”提前写下来。在仓库根目录的 AGENTS.md（或你用的 Agent 读取的说明文件）里列出禁止的模式，例如：
## 硬约束（禁止）
- 不要通过遍历 git log 推算合并时间，用发布记录 / PR API 查询
- 不要在 handler 里直接访问数据库，必须经过 repository 层
- 不要新增依赖，除非在 PR 描述里说明理由审 PR 时，先问三个问题：这个改动想解决什么、为什么用这个方案、有没有碰到上面的约束。意图对了再看细节。这是我从原文“看意图而不是逐行读”推出来的做法，不是 Anthropic 给的清单。
c. 对抗式审查要有边界
原文出处：原文说对抗式审查“can also be myopic”（也可能短视），曾因对另一内部服务过度防御，导致 Claude 加了过多校验和复杂度。
建议： 如果你让一个 Agent 审另一个 Agent 的代码，给审查方写明边界，例如：“信任边界：内部服务 X 的返回值视为可信，不要求额外校验；只报告有现实触发路径的问题，假想风险单独列为‘可选’。”再规定审查意见必须分“必须改 / 可选”两级，作者只强制处理前者。
d. 让一个 Agent 只盯一个组件：superfans
原文出处：他们建了 Slack 频道，让 Claude 执着地只关注某一个组件的健康，称之为“superfans”，有 scion-daemon superfan、scion-cache superfan、Antique 合并队列 superfan 等。
"They have access to our telemetry and logs, and act like an experienced engineer who has nothing better to do than to refresh charts and look for anything strange."（译：它们能访问我们的遥测和日志，表现得像一个没别的事可做、只会刷新图表找异常的资深工程师。）
原文同时说，传统告警他们也都保留着。
建议： 小团队可以从一个组件开始：给一个 Agent 只读权限，只看某个服务（比如你的 API 或队列 worker）的日志和监控，定时让它写一段“今天有什么不对劲”的总结发到一个专门频道。不要一上来让它看全部系统，也别拿它替代告警。
e. 合并队列的全局锁，还必要吗？
原文出处：
"We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing."（译：我们没能有效复制合并队列上“全局仓库锁”这一行业标准做法，于是转而投入合并后、部署前的自动化测试。）
原文承认这意味着并发改动可能冲突，但“Claude can typically fix these conflicts faster than humans can even identify them”（Claude 修冲突通常比人发现冲突还快）。
建议： 小团队别直接照搬“取消合并前测试”。更稳的做法是先量一下：PR 在队列里排队的时间，和真正因并发出问题的次数，各是多少。如果排队成了主要等待，而冲突很少，可以考虑把一部分慢测试挪到合并后、部署前的环节，部署前那道关必须留着。
Scion 能替代 Git 吗？哪些地方不该学？
Anthropic 自己的 monorepo 已经从 Git 迁走。Scion 不是通用场景的 Git 替代品，这是原文自己说的：
"Scion is by no means a suitable replacement for git for general use."（译：Scion 绝不是一个适合通用场景的 Git 替代品。）
原文说，这些概念只对真正巨大的 monorepo 才有意义，要么有上万名工程师，要么有成群的 Agent 在大量写代码。还有几点不该学：
- token 预算。 原文说 Anthropic 内部能花的 token“far exceeds what any other business would realistically want to spend”（远超任何其他公司实际愿意花的量）。对抗式审查、superfans 都要花 token，小团队要算账。
- 自研整套工具链。 Scion 和 Git 差别很大，需要自己的代码审查、代码搜索和 CI，原文说内部这些组件高度定制，别的组织很难采用。
但也别觉得事不关己。原文预计这类问题“will become more commonplace over the next six to 12 months”（会在未来 6 到 12 个月里变得更常见）。他们给的方向是：把 Scion 最成功的部分用到 Git 上，“without departing from the overall model”（不脱离 Git 的整体模型），比如 Git 服务端不必和客户端一个工作方式，平台可以提供更完整的服务端 RPC。
对我们来说，结论很简单：继续用 Git，但别再默认每个任务都要一份完整仓库，也别再默认 AI 写的每一行都要人逐行读。先从 CI 里那几个只为问一个问题而克隆的步骤改起。
来源
- Anthropic Engineering，Nick G. and the source control team，《Redesigning source control at Anthropic》，发布于 2026-10-13：https://www.anthropic.com/engineering/redesigning-source-control
- 文中截图均取自该原文页面，来源：Anthropic，2026-10-13。