Anthropic弃用Git：AI编码狂潮催生自研版本控制系统

一条来自YouTube的消息在开发者社区炸开了锅：Anthropic已将其主要代码库从Git迁移到自研的版本控制系统Scion。乍看像是标题党，但背后的数据让人无法忽视——当AI智能体每天提交数万次代码变更时，Git确实开始喘不过气了。

从2500到30000：AI把代码提交量推高了十倍

据该视频披露，Anthropic在5月份每天大约合并2500次代码变更，到9月份这个数字已经攀升到30000次以上，增幅超过十倍。这个量级的变化不是靠多招几百个工程师能解释的，它指向一个根本性的转变：写代码的主体正在从人类开发者扩展到AI智能体。

当AI智能体以这种规模持续生成和修改代码时，瓶颈就从“怎么写”转移到了“怎么管”。代码审查、合并冲突、构建排队、历史追溯——这些环节在传统Git工作流下都会随着提交频率的暴涨而迅速恶化。

“合并代码变更”通常指一次 Pull Request（或等价流程）被审查通过并合并进主干分支的事件，而非单次本地 commit。这两个指标的差异很关键：本地提交可以很廉价，而合并意味着经过了代码审查、CI 构建与冲突解决，是真正落到共享代码库上的变更。因此日合并量从 2500 涨到 30000，反映的是审查与集成环节的负载放大了十倍以上，而不只是提交次数的增长。这也是为什么文章强调瓶颈会集中在代码审查、合并冲突和构建排队上——这些恰恰是合并路径上的环节。

Scion不是Git杀手，而是为AI工作量身定做

Anthropic自研的Scion系统已经完成了主代码库的迁移。但视频特别强调了一个关键限定：Scion并非为取代Git而设计，它是针对Anthropic自身那种超大规模、AI驱动工程环境定制的内部基础设施。

换句话说，普通开发团队短期内不需要恐慌，也不必急着寻找“Git替代品”。Scion的出现更像是一个信号弹——当代码生产速度突破某个阈值时，通用工具会成为瓶颈，头部公司不得不向下造轮子。

从工程角度看，这个选择有其合理性。Git的分支模型和合并策略是为人类协作节奏设计的，面对AI智能体高频、细粒度、可能并发的代码修改，它在锁竞争、对象存储和审查流程上都会暴露短板。自研系统可以针对这些痛点做针对性优化，比如更细粒度的变更追踪或自动化的冲突预处理。

Git 采用分布式对象模型：每次提交都会生成指向文件快照的树对象，并以 SHA 哈希内容寻址存储，分支本质上只是指向某个提交的可变指针。这套设计的优势是离线可用、历史不可篡改、分支创建成本极低；代价是仓库体积随历史线性膨胀，超大仓库需要 partial clone、sparse checkout 等机制缓解，而合并冲突的解决仍高度依赖人工判断。当变更以高频、细粒度、并发的方式涌入时，锁竞争（如 ref 更新）、对象存储增长与人工审查队列会同时承压，这正是通用工具在极端规模下暴露短板的地方。

更大的故事：AI正在重塑软件工程的基础设施层

视频结尾点出了真正的主题：AI改变的不只是我们写代码的方式，还有支撑软件开发的工具、工作流和基础设施。这个判断值得认真对待。

过去几年，AI编程助手的主战场集中在代码生成质量上。但随着智能体开始承担成规模的代码修改任务，竞争焦点会向上游迁移——版本控制、CI/CD、代码审查、测试编排，这些“管道”环节都需要重新设计以适配AI的生产节奏。Anthropic的Scion是这个趋势下最早浮出水面的案例之一，但大概率不会是唯一一个。

CI/CD（持续集成/持续交付）指代码变更自动触发构建、测试并交付部署的流水线。它的吞吐能力通常以“并发构建数”和“单次流水线时长”衡量，在人类提交节奏下这些容量是按天/小时规划的。当合并频率提高一个数量级，流水线会出现排队积压，测试结果反馈延迟，进而拖慢整个合并链路——即使版本控制本身没问题，CI 也会成为新的塞子。因此基础设施的重设计不只发生在版本控制层，还包括测试选择（只跑受影响用例）、缓存复用与审查自动化等配套环节。

Git会死吗？短期内不会

回到标题提出的问题。Git不会因为Anthropic的一次内部迁移而消亡。它依然是全球绝大多数开源项目和企业的标准版本控制工具，生态成熟度和网络效应短期内无可撼动。

但“Git是否会被取代”本身可能就是个错误问题。更准确的问法是：当AI把代码变更量推高一个数量级后，现有的开发基础设施还能撑多久？Anthropic给出的答案是用脚投票——自己造一个。其他达到类似规模的组织，迟早要面对同样的选择题。

对于大多数开发者而言，这件事的现实意义在于提前关注AI工作流对版本控制策略的影响：分支管理是否需要调整、审查流程能否自动化、提交粒度是否还合理。工具的更替往往滞后于工作方式的变化，而工作方式已经在变了。