据 Anthropic 工程文章披露，其单体仓库的代码变更合并量，从 2026 年 5 月日均约 2500 次，升至 9 月日均超过 30000 次。按这两个近似数字计算，后者超过前者的 12 倍。公司还称，已经用五个月将这个仓库从 Git 完整迁移到自建版本控制系统 Scion。
来源：Simon Willison · AI 实践 · 《Redesigning source control at Anthropic》（网页截取于 2026年10月15日）
对技术负责人来说，最有用的问题是：Anthropic 究竟替换了什么，你的团队是否遇到了同一种瓶颈？ 合并量暴涨值得检查工程流程，但它本身还不能成为更换源码管理方案的理由。
先分清版本控制、评审和集成
日常开发中，我们很容易把拉代码、提评审、跑 CI、合入主干统称为 Git 流程。但这些环节承担的任务不同。
版本控制负责保存文件与历史、表达变更关系；代码评审负责检查和批准变更；集成流程则要把获批代码放到一起，完成验证并合入目标分支。评审排队三小时，和检出仓库耗时三分钟，需要处理的是两类问题。
Anthropic 这次确实替换了版本控制系统。工程文章明确写道，Scion 承接了其单体仓库；同期交付的还有代码评审界面 Antique、代码搜索、源码访问权限系统，以及管理和合入大量已评审代码的新机制。
所以，这也不是简单换一个 Git 客户端。它涉及源码存储与访问，以及围绕源码运转的一组工程系统。但文章所说的迁移范围是其单体仓库，不能扩大成 Anthropic 所有项目都已弃用 Git。
比合并量更关键的是每天 2500 万次检出
只看日均三万次合并，仍然很难判断 Git 为什么承压。工程文章给出的另一组数字更能说明问题：
- 主分支历史接近 100 GB。
- 压缩后的工作副本超过 25 GB。
- 仅 CI 每天就有约 2500 万次代码检出，尚未计入开发环境、Agent 沙箱和研究任务。
Anthropic 据此估算，如果直接采用朴素的完整获取方式，每天会产生超过 600 PB 的 Git 流量。这是特定获取方式下的估算，不是其实际网络流量。
这组负载把问题从"代码写得快"推进到了"代码如何被反复分发"。一次变更合入后，后续 CI 和任务需要取得相应版本；仓库越大、任务越多，源码获取和历史查询就越值得单独核算。
Anthropic 也没有跳过现有优化直接重写。按其披露，他们用过浅克隆、稀疏检出、按需获取对象的机制、内部镜像，以及放在对象存储中的仓库快照。高峰时，内部 Git 镜像达到数百个。
这些措施争取了时间，却带来了新的运维负担：合并速度上升后，快照在两次刷新之间离主干越来越远；部分克隆中依赖历史的 diff、blame 等操作，也需要更多维护工作。
问题因此具体了：在这个仓库和任务规模下，继续维护 Git 周边的分发设施，已经变得吃力。
Scion 改动了一个重要前提
Git 的完整克隆支持开发者在离线状态下查看历史、计算差异、切换版本。Anthropic 在文章中也认可，对绝大多数仓库，这是合适的设计。
但它描述的内部使用方式有明显差别：存在一份权威源码，几乎所有客户端都是天然在线的 Agent 和任务。于是 Scion 选择围绕始终可达的服务器设计客户端与协议，让客户端按需获取数据。
来源：Hacker News · 《Redesigning source control at Anthropic》（网页截取于 2026年10月15日）
这个取舍有明确的业务条件。既然主要使用者本来就在线，就可以降低对离线自足能力的优先级，重新安排客户端和服务器的职责。代价则是需要认真处理服务可用性、网络依赖和故障恢复。
Simon Willison 将 Scion 理解为接近 Subversion 路线的集中式源码管理再设计。这是他的技术判断；Anthropic 原文还提到借鉴 Google Piper 和 Meta Sapling 的经验。两者都不应被简化成"Git 已经落后"。
目前提供的工程正文在设计原则处截断，尚不足以评价 Scion 的完整架构、兼容性、性能收益和长期维护成本。Simon 的转述提到七人团队、五个月完成迁移，也不能据此算出普通团队自研的投入产出比。
同样，合并量统计没有给出变更大小、计数细则及自动生成变更占比。它能描述处理规模，不能直接代表代码质量或业务交付效率。Simon 在图表上标注模型公开发布日期，也明确提醒：公开发布时间不等于内部可用时间，不能凭时间重合认定某次模型发布造成了增长。
你的团队先查哪一段在等
我的判断是，普通团队应先优化现有流程；只有测量显示源码管理本身持续限制交付，才进入替换方案的评估。
先把一次变更从提交到合入的时间拆开：等待评审、等待 CI、执行测试、解决冲突、获取源码，各花了多久？看中位数，也看慢请求；区分人的开发环境与自动任务。
如果主要时间消耗在评审排队，更换版本控制系统缺少直接收益依据。如果 CI 反复下载相同内容，就先评估缓存、镜像、浅克隆和稀疏检出。如果测试本身占据绝大多数时间，应先检查测试选择与执行方式。
只有当这些优化仍无法满足需求，而且维护它们的成本持续上升，替换才有更充分的理由。届时需要拿出三类证据：
- 负载证据：仓库规模、检出频率、传输量、尾延迟，以及未来增长预期。
- 迁移证据：历史、权限、CI、开发工具如何衔接，失败后能否回退。
- 经营证据：节省多少等待和资源成本，谁负责长期维护、值班与恢复。
Anthropic 的案例值得研究，因为它给出了特殊负载和设计取舍之间的联系。它没有提供一条"日均合并超过多少次就该换 Git"的通用阈值。
先测清团队在哪里等待，再决定改哪一层。若瓶颈确实落在源码分发与版本访问上，且现有优化成本已经难以承受，自研或迁移才进入候选名单。否则，换掉 Git 很可能只是把原来的交付问题，叠加上一套新的基础设施责任。
参考资料：
- Anthropic：《Redesigning source control at Anthropic》，所提供工程正文节选。
- Simon Willison：《Redesigning source control at Anthropic》，2026 年 10 月 13 日。