你让一群永不休息的助手同时改一份巨型文档，麻烦很快就不再是“写得够不够快”，而是文件怎么分发、修改如何核对、不同版本怎样合在一起。Anthropic称，Claude生成代码的速度已经让类似问题落到软件研发中：过去围绕人类工作节奏设计的代码仓库、构建系统和CI，开始成为瓶颈。为此，它用五个月自研版本控制系统Scion，并把整个monorepo从Git迁了过去。
这里的数字和效果均来自Anthropic官方工程博客，尚无第三方审计；官方原文材料也在技术部分末尾截断。
先被压垮的，不是写代码
版本控制会记录每次代码修改及其差异，方便团队审查、合并和回退。代码仓库则不只是存文件的网盘，还承载提交历史、分支和评审流程。monorepo指把大量项目代码集中在同一个仓库里。
据Anthropic披露，2026年5月，公司平均每天合并约2500个代码变更；到9月，这一数字超过3万个。它将增长归因于Claude能够自主推进研究循环、微调复杂程序，并从零构建服务。不过，这种因果关系和能力描述都来自公司自述。
压力最直观地落在代码分发上。Anthropic称，其monorepo仅主分支历史就接近100 GB，压缩后的工作副本仍超过25 GB。CI——代码改动后自动编译、测试和检查的流水线——每天大约执行2500万次代码checkout，也就是取出某个版本供任务使用；这还没有计算开发环境、Agent沙箱和研究任务。若每次都以朴素方式获取代码，理论流量会超过600 PB/天。这个数字是反事实估算，并非真实消耗。
Git的优点，在这里成了负担
Git按离线协作设计。每个完整克隆都能在断网时查看历史、比较差异、追查某行代码由谁修改，并切换到任意版本。对绝大多数仓库，这是很合适的设计。
Anthropic的问题是，它的大多数“开发者”其实是始终联网的Agent和自动任务。公司起初没有立刻放弃Git，而是采用浅克隆、稀疏检出、对象存储快照等办法，只取仓库的一部分；高峰期还运行数百个内部Git镜像。官方称，随着合并速度上升，快照更容易落后于主分支，维护局部仓库中的历史查询也越来越费力。
Scion因此换了一个前提：客户端始终在线，不必随身带着完整仓库。服务器集中处理历史查询、提交创建、合并和rebase——把一组改动重新接到新版代码之上；客户端只保留容量受限的缓存，负责把工作文件放到磁盘并监控变化。像去图书馆查资料：Git倾向于让每个人带走一整套馆藏，Scion则让中央服务保管资料，客户端用到哪页再取哪页。
Scion还把版本控制查询开放为API——供程序直接调用的接口。CI或内部工具想知道“谁最后改了这一行”“两个提交是什么关系”，不一定再维护本地仓库。Anthropic称，自动二分定位问题和自动回退流水线因此才能低成本运行。
重做的不只是一套仓库
同一五个月里，Anthropic还上线了代码评审工具Antique、代码搜索、源码控制IAM系统——管理谁能访问和操作哪些代码的权限机制——以及处理大量已评审代码的新办法。据Anthropic Engineering披露，Scion的CPU和内存占用约为旧镜像体系的二百分之一，并为CI节省约四分之一的算力容量。
这件事值得关注，不只因为Anthropic替换了Git。更关键的变化是：当Agent持续制造改动，研发系统的稀缺资源可能从“谁来写代码”转向“如何分发、测试、审查和落地代码”。多个Agent同时修改相近位置时，还会产生合并冲突，即系统无法自动判断该保留哪一版。产量越高，协调压力越容易被放大。
局限与未知
- 所有规模、性能和迁移结果均来自Anthropic单一信源，没有公开仓库、监控数据或第三方审计佐证。
- 官方称增长短期不会放缓、代码需求近乎无限，这属于预测和宣传性判断，缺少可复核指标。
- 现有材料没有完整披露Scion的故障表现、迁移代价、安全边界，以及放弃离线能力带来的实际限制。Anthropic也承认自身负载很特殊，多数组织近期未必会遇到同等问题。