Hacker News 上 Anthropic 官方发了篇长文，吐槽现在的开发工具根本跟不上 AI 写代码的速度。原文作者直接摊牌：Git 已经扛不住了，他们花了五个月自己写了个新系统 Scion，把整个代码库全迁过去了。
这事给所有狂推 AI 编程的团队敲了警钟。你以为 AI 提效是好事，结果代码产出量暴增，直接把底层的版本控制和 CI 流程给撑爆了。工具链不升级，AI 写得越快，系统崩得越惨。
- 发生了什么：Anthropic 因为 Claude 写代码太快，每天代码合并量从两千五飙到三万次，原有 Git 基础设施直接瘫痪。
- 真相是什么：Git 是为人类离线工作设计的，面对每天两千五百万次 CI 检出和 600PB 的流量，去中心化架构成了致命拖累。
- 影响是什么：Anthropic 自研了 Scion 系统，全面转向客户端永远在线、服务端集中计算的架构，彻底抛弃了传统的 Git 模式。
讲真，看到 Anthropic 官方在 Hacker News 上倒苦水，我还是挺惊讶的。毕竟在大家印象里，他们家 Claude 写代码已经是天花板级别了。但原文作者直接揭开了一块遮羞布：coding 早就不是瓶颈了，现在卡脖子的是那些为“人类规模”设计的开发基础设施。
数据摆在这，2026年5月，Anthropic 平均每天合并大概 2500 次代码。到了9月，这个数字直接飙到了每天超过 30000 次。而且他们明确表示，这根本不是上限，只要移除瓶颈，代码产出量还会无限涨。
这就苦了底层的 Git 了。原文提到，他们主分支的历史记录快 100GB 了，压缩后的工作副本超 25GB。每天 CI 要执行大约 2500 万次代码检出。如果按 Git 原生方式拉取，每天的 Git 流量会超过 600PB。为了扛住这个量，他们之前搞了几百个内部 Git 镜像，还用了各种浅克隆、稀疏检出。但随着合并率飙升，这些补丁方案越来越难维护，镜像里的种子数据也越来越落后于主干。
最后他们顿悟了：Git 是个去中心化系统，假设客户端会离线工作。但 Anthropic 现在的客户端基本都是永远在线的 AI agent 和自动化任务。Git 那些优秀的离线特性，反而成了规模化的绊脚石。
所以 Scion 的诞生，其实是对“AI 时代开发范式”的一次彻底重构。原文里提到了几个核心原则，说白了就是把 Git 的逻辑全翻了过来。
首先是客户端永远在线且不对称。Git 里每个客户端都能当服务器，但在 Scion 里，服务器负责算历史、做合并、搞 rebase。客户端只负责缓存和展示文件。客户端自己算不了什么，但换来的是本地数据量极小。
其次是全面源码控制服务。以前 CI 任务想问个问题，得在本地留个仓库副本。现在 Scion 把所有查询都通过 API 暴露出来，任务根本不需要本地仓库。这就让自动化的 bisect 和 revert 管道变得极其轻量。
最狠的是提交便宜且无锁，工作副本可选。在 Git 里你得先本地 commit 再 push。在 Scion 里，所有操作都在服务端瞬间完成。而且因为 monorepo 太大，Scion 默认就是稀疏检出，甚至支持虚拟化检出，CI 任务需要 diff 直接找服务端要，连文件都不用下载到本地。
这其实揭示了一个隐藏的真相：当代码生产的主力从人类变成 AI agent 时，我们过去引以为傲的“分布式版本控制”理念，可能已经过时了。AI 不需要离线看代码，也不需要本地完整的 git history，它们只需要一个永远在线、响应极快、能直接通过 API 调用的中心节点。
这事对普通公司有什么影响？你可能觉得，我们每天合并几百次代码，离三万次差得远，不用操心。但换个角度看，如果你团队正在大规模引入 AI 编程工具，这种“基础设施被撑爆”的危机迟早会来。
这里给大家一个AI 编程时代的工具链评估框架。当你发现 AI 提效后，CI 跑不动了、代码审查跟不上了，别急着去优化 AI 的 prompt，先检查你的版本控制和 CI 架构。
第一，评估你的 monorepo 规模。如果你的单仓库体积超过 10GB，且每天检出次数过万，传统的 Git 镜像方案就会失效。这时候你需要考虑引入专为大型 monorepo 设计的工具。
参考大型 monorepo 方案：Piper )
Sapling
第二，检查你的 CI 流程是否过度依赖本地仓库。如果每个 CI 任务都要完整 clone 一次代码，赶紧改成按需拉取或者稀疏检出。把计算逻辑上移到服务端，让 CI 节点变成纯粹的无状态执行器。
第三，重新审视代码审查流程。AI 写的代码量大，靠人类逐行看根本不现实。你需要像 Anthropic 搞 Antique 那样，建立一套专门针对 AI 生成代码的审查界面和自动化拦截机制。
不过，别看着 Anthropic 自研了 Scion 就脑子一热也要自己造轮子。原文明确说了，他们是因为 workload 极其特殊才这么干的。对于 99% 的公司来说，自研版本控制系统是个巨大的坑。
这里必须提醒几个盲目跟风自研的失败条件。首先，你的 AI 代码产出量如果没有达到每天数千次合并的级别，自研带来的收益根本覆盖不了研发成本。其次，Scion 强依赖“客户端永远在线”的假设，如果你的团队有大量需要离线开发的场景，或者网络环境不稳定，这种强中心化的架构会让开发者痛不欲生。最后，放弃 Git 意味着你要放弃整个开源生态的工具链支持，所有的 IDE 插件、第三方 CI 工具都要重新适配，这个隐性成本极高。
所以，正确的姿势是：先用现成的企业级方案把 monorepo 的坑填上，把 CI 流程改成按需拉取。等你的 AI 代码产出量真的到了让现有方案都绝望的地步，再去考虑自研。
看完想聊两句？
你们团队现在用 AI 写代码，最卡在哪个环节？是 CI 太慢还是代码审查看不过来？
