Anthropic重新设计源代码控制系统

Anthropic 正在用 Claude 写代码，写着写着发现瓶颈不在模型身上了，而在给人类工程师设计的那套开发基础设施上。今年 5 月，这家公司平均每天合并约 2500 次代码变更；到 9 月，这个数字涨到了每天超过 3 万次。Git 扛不住了。 问题的根源在于 Git 的设计哲学。Git 是分布式的，每个克隆都是一份完整、自包含的仓库，可以离线计算 diff、读取历史、checkout 任意版本。对绝大多数项目来说这是优点，但 Anthropic 的 monorepo 主分支历史接近 100 GB，压缩后的工作副本超过 25 GB，每天仅 CI 就要执行约 2500 万次代码 checkout——如果天真地全量拉取，每天会产生超过 600 PB 的 Git 流量。他们试过所有标准解法：浅克隆、稀疏检出、promisor remote、内部镜像、blob 存储快照。高峰期他们维护着几百个内部 Git 镜像来分摊负载，但这只是买时间。随着合并频率继续攀升，快照越来越偏离主分支最新状态，diff 和 blame 这类依赖历史的功能在部分克隆上越来越难维护。 于是 Anthropic 做了一个更彻底的决定：自己写一套版本控制系统。他们花了五个月时间构建了 Scion，并将整个 monorepo 从 Git 完整迁移过去。同期还交付了代码审查界面 Antique、代码搜索、源码控制 IAM 系统，以及大规模已审代码的管理和落地机制。Scion 的核心设计思路是：既然几乎所有客户端都是始终在线的 agent 和任务，那就没必要为了分布式离线场景牺牲可扩展性。换句话说，他们从第一天起就假设 agent 永远在线，重新设计了源码控制的底层假设。 这件事对跨境电商和 AI 从业者的启示在于：当 AI 写代码的速度远超人类审查和合并的速度时，真正的瓶颈会从模型能力转移到工程基础设施上。Anthropic 自己也承认，他们只是因为用 Claude 写代码的比例远高于其他公司，所以最先撞上这堵墙。但按照当前 AI 编程工具的普及速度，其他重度使用 AI 编码的团队遇到类似压力点只是时间问题。Scion 目前是 Anthropic 内部系统，没有开源计划，但这篇工程博客透露出的信号很明确：为人类规模设计的开发工具链，正在成为 AI 时代生产力的新天花板。