Anthropic 自研代码版本控制系统 Scion 替代 Git
Redesigning source control at Anthropic
Anthropic 撰文介绍其自研的 Git 替代方案,起因是代码变更速率大幅上升:2026 年 5 月日均合并约 2500 次代码变更,到 9 月已超过 30000 次。
同一新闻,精选展示《Anthropic 自研版本控制系统 Scion,五个月完成 monorepo 迁移》
2026年10月13日 - 链接博客
在 Anthropic 重新设计源代码控制(via)Anthropic 的一篇有趣文章,描述了在过去六个月中代码变更速度急剧上升之后,他们为何以及如何构建自己的 Git 定制替代方案。
2026 年 5 月,Anthropic 平均每天合并约 2,500 项代码变更;截至 9 月,我们每天合并超过 30,000 项。
他们附上了一张展示这些变更的图表。我让 Claude 修改了他们的图表(代码在此),为他们在 2026 年发布的每个模型添加了公开发布标记:

这显示的是公开发布日期,而非模型可供 Anthropic 内部使用的日期。我猜测 Fable/Mythos 级模型的引入是编码速度提升的关键因素。
“Antique”是他们新的代码审查系统。源代码控制系统名为 Scion,在我看来像是沿着 Subversion 路线对集中式源代码控制的一次重新发明。他们有一些相当极端的要求:
仅我们主分支的历史就接近 100 GB,而一个压缩后的工作副本超过 25 GB。我们每天为 CI 执行约 2,500 万次代码检出,这还不包括开发者环境、代理沙箱和研究任务。如果天真地拉取,那将是每天超过 600 PB 的 git 流量。
新系统由一个七人团队构建,从 Git 的迁移在五个月内完成。
顺便说一句,我最近在自己的项目中一直在尝试对抗性审查,即让一个模型尝试找出缺陷(我经常让 Claude 和 GPT 互相对抗)。文章中的这条注释反映了我自己在这方面的经验:
Anthropic 也大量使用对抗性审查,虽然这在许多方面非常有效,但也可能目光短浅,因此需要熟练的工程师引导 Claude 避免为应对假设性问题而对系统部分进行过度设计。
来源:Simon Willison · simonwillison.net