Anthropic 因 AI 代码激增自研 Git 替代方案
Anthropic 工程团队披露，为应对 AI 辅助编程导致的代码合并量从日均 2500 次激增至 30000 次，他们构建了基于“Antique Change Requests”的自定义版本控制系统以替代传统 Git。该方案通过重构变更请求模型，解决了高并发下 Git 在大规模自动化提交场景中的性能瓶颈与协作冲突问题。
报道正文
Anthropic 重新设计源代码管理 (via) Anthropic 发布了一篇有趣的文章，阐述了他们为何以及如何构建自己的 Git 定制替代品。这一举措源于过去六个月中，其代码变更速率的急剧上升。
2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；截至 9 月，我们每天合并超过 30,000 次。
他们提供了一张展示这些变化的图表。我 让 Claude 修改了他们的图表（代码在此），添加了 2026 年各模型公开发布日期的标记：
这显示的是公开发布日期，而非模型供 Anthropic 内部使用的日期。我猜测，引入 Fable/Mythos 系列模型是编码速度提升的关键因素。
“Antique”是他们新的代码审查系统。源代码管理系统名为 Scion，在我看来，它像是 Subversion 那种集中式源代码管理的重新发明。
（更新：Anthropic 将 Google 的 Piper 和 Meta 的 Sapling 列为“现有技术”——看起来，“派生数据”这一核心概念深受 Mononoke（Sapling 的服务端组件）的影响。）
他们有一些相当极端的需求：
仅我们主分支的历史记录就接近 100 GB，而压缩后的工作副本超过 25 GB。每天我们为 CI 执行约 2500 万次代码检出，这还不包括开发者环境、Agent 沙箱和研究任务。如果采用朴素的方式获取，这将导致每天超过 600 PB 的 git 流量。
新系统由一个七人团队构建，从 Git 迁移的工作在五个月内完成。
当在 Hacker News 上被问及缺乏离线支持时，Scion 工程师 Nick G 回复道：
由于 Claude 是 Scion 最重的用户，且必然处于在线状态，因此这一点并不重要。
顺便提一下，我最近一直在自己的项目中尝试对抗性审查（adversarial review），即让模型试图找出缺陷（我经常让 Claude 和 GPT 互相博弈）。文章中的这段笔记反映了我对此的个人体验：
Anthropic 也广泛使用对抗性审查，虽然这在很多方面极其有效，但也可能存在视野局限，因此需要熟练的工程师引导 Claude，避免其针对假设性的担忧对系统的某些部分进行过度工程化。
发布于 2026 年 10 月 13 日 晚上 11 点