登录
2026 年 10 月 13 日，Anthropic 发布工程博客《Redesigning source control at Anthropic》，确认公司已把内部单体仓库从 Git 完整迁到自研版本控制系统 Scion，全程用了五个月。 直接触发迁移的是代码产量的陡增：今年 5 月，公司日均合并约 2500 次代码变更，到 9 月已超过 3 万次，达到原来的 12 倍。 更值得注意的是建造方式——团队没有扩编，靠 7 个人加 Claude 主导写码，五个月内建出系统并完成全量迁移。知乎知乎知乎
Git 是怎么“不够用”的？按 Anthropic 列出的数字：monorepo 仅 main 分支历史就近 100 GB，压缩后的工作副本超过 25 GB，仅 CI 每天就要做约 2500 万次代码检出，若按老方式天真拉取，每天会制造超过 600 PB 的 Git 流量。 这之前，浅克隆、稀疏检出、内部镜像这些标准手段他们全用过，高峰期运营着数百个内部 Git 镜像，但补丁撑的时间一短再短，最后只能重建。 更关键的判断是用法变了：他们其实早就把 Git 当中心化系统在用——只有一份权威副本，客户端几乎全是永远在线的 agent 与任务，Git 的分布式离线特性反而成了扩展负担。知乎知乎知乎
Scion 就是按这个前提反着造的，Git 最核心的本地能力被整体上移到了服务端。 数据以 changeset（写前日志中的一条变更）为单位组织，blame、路径历史这类结构作为“派生数据”在服务端由父变更递归算出；请求经过节点守护进程、区域缓存、权威服务器三层，每一层缓存命中率超过 99%。 迁移后的账面：基础设施的 CPU 与内存消耗降为原先 Git 镜像集群的约两百分之一，CI 代码检出从几分钟缩短到几秒。知乎知乎IT之家
但把它读成“Git 时代终结”就跑偏了。Anthropic 自己在博客里说得明白：对绝大多数仓库，Git 这种每个克隆都是完整仓库的设计仍是正确设计，也是它成为标准的重要原因。 36氪的解读同样克制：这次替换，并不是因为 Git 已经过时。知乎36氪
这条路线也不是从零发明，官方博客承认了先行者——Google 的 Piper 和 Meta 的 Sapling，并说 Scion 是带着它们的教训建的。 争议很快出现：有前 Meta 工程师发帖称，Scion 的“派生数据”机制与 Meta 2017 年为 Mononoke 打造的架构高度相似而文中未提，这属于社区单方观察，Anthropic 未公开回应。 路线观感上的反弹也存在：当年 Linus Torvalds 写 Git，正是为了摆脱商业中心化系统的授权卡脖子。 而在 Anthropic 的叙事里，中心化早已是既成事实，Scion 只是让实现方式对齐了现实。知乎微博知乎
这则内部工程故事真正的信号是瓶颈在移动：当“写代码”本身不再受限，构建、CI、合并队列、代码评审正依次被推向下一个瓶颈。他们的应对是重写合并语义——放弃传统合并队列的全局锁，转投合并后与部署前的自动化测试，因为 Claude 修并发冲突往往比人发现冲突还快。 Anthropic 预判这类规模问题会在未来 6 到 12 个月内更普遍；注意，这是公司单方面的预期，不是行业统计。知乎知乎
对大多数团队，启示不是“自研”，而是一次压力测试预演：如果日合并量突然翻十倍，仓库历史体积、检出等待、CI 排队和评审周转，哪个先撑不住？仓库还在 GB 量级、日合并几十次的团队，Git 依然是最优解——这则热榜的价值不在换工具，而在提前检查你的流水线，能不能承接 AI 正在生产出来的产量。
