Anthropic 为何自建版本控制系统 Scion
Simon Willison7 小时前
代码变更规模推动系统重构
Anthropic 披露，2026年5月，公司平均每天合并约2500项代码变更；到9月，每日合并量已超过3万项。随着代码变更量快速增长，公司开发了版本控制系统 Scion，并从 Git 迁移到这一新系统。
与之配套的 Antique 是新的代码审查系统，两者承担不同职责，不应混为一谈。
压力不仅在合并次数，更在代码检出规模
Anthropic 给出的工作负载包括：
- 主分支的历史记录接近 100 GB。
- 一份压缩后的工作副本超过 25 GB。
- 仅持续集成（CI）每天就执行约 2500万次代码检出，尚未计入开发环境、智能体沙箱和研究任务。
- 如果采用朴素的全量拉取方式，每天产生的 Git 流量将超过 600 PB。
这里的600 PB是特定拉取方式下的估算，并非已经发生的实际流量。
新系统由一个 7人团队构建，从 Git 迁移的过程在 5个月内完成。
为什么不优先支持离线使用？
Scion 没有优先实现离线支持。工程师 Nick G 对此解释：Claude 是 Scion 使用量最大的用户，而且必须在线运行，因此离线能力并不是当时的重要需求。
这一取舍反映了系统的具体使用场景：当主要使用者是在线运行的 AI，功能优先级也会围绕这类工作负载调整，而不必完全沿用面向人类开发者的工具设计。
对抗式审查有效，但仍需工程师把关
Anthropic 还大量采用对抗式审查，让模型主动寻找设计或实现中的缺陷。
这种方法在许多方面很有效，但也可能陷入局部视角：模型可能为了应对假设性问题，不断增加系统复杂度。因此，经验丰富的工程师仍需引导 Claude，避免部分设计走向过度工程化。
不宜把模型发布与效率提升直接画等号
相关图表叠加了2026年部分模型的公开发布日期，但公开发布的时间并不等于 Anthropic 内部开始使用模型的时间。
因此，仅凭这些时间标记，不能认定某一模型直接导致了代码合并量增长。此外，合并次数也不等同于代码质量或交付价值，解读这些数字时需要区分指标本身与更广泛的工程成效。