代码写得快，已经不算新闻。新闻是，代码快到把版本控制系统冲垮了。
2026年5月，Anthropic 平均每天合并约2500个代码变更。到了9月，这个数字超过30000。
几个月，增长10倍以上。
Claude 已经能自主迭代研究循环、微优化复杂程序、从零构建新服务。写代码的瓶颈消失了。麻烦转移到了下一层：源码控制、构建、CI，这些为人类尺度设计的基础设施，开始冒烟。
于是，Anthropic 干了一件很激进的事：5个月里，把 monorepo 从 git 迁到自研系统 Scion，同时上线 Antique 代码审查、代码搜索、源码控制 IAM 等配套。
Git没有输，但它背不动AI的流量了
老实讲，Git 没犯错，错的是它遇到的对手。
Git 的设计假设是，每个 clone 都是完整仓库，离线也能查历史、算 diff、做 blame。这让它成了行业标准。
但 Anthropic 的仓库已经长成了一个庞然大物。主分支历史接近100GB，压缩后的工作副本超过25GB。CI 每天要做约2500万次代码检出。 如果按朴素方式 fetch，一天会产生超过600PB的 git 流量。
这还只是 CI。没算开发者环境、agent 沙箱、研究任务。
他们先用补丁顶住：shallow clones、sparse checkouts、promisor remotes、内部 git mirrors、blob storage 里的 repo snapshots。高峰时，内部跑着几百个 git mirror。
能撑，但越来越难。镜像刷新跟不上主干，partial clone 的 diff 和 blame 也越来越难伺候。
问题出在设计假设。Git 假设客户端可能离线，需要自带完整仓库。可 Anthropic 的客户端，绝大多数是在线 agent 和在线任务。它们天生联网，却还要背着为离线准备的大包。
Scion的思路：别让客户端背仓库，让服务端回答问题
Scion 的第一原则很直接：客户端永远在线。
既然 agent 和 job 都在线，那就不要默认发完整仓库。客户端需要数据时，再向服务器要。服务器负责回答文件历史、blame、创建 commit、merge、rebase。客户端只保留有限对象缓存，摆好工作目录，监听文件变化，提供人机交互。
第二个变化是 API 化。过去，CI 或工具想知道某行代码是谁改的、两个 commit 有什么关系，往往要维护本地仓库，或者赌平台 API 支不支持。Scion 把这些查询都开放成 API。很多任务干脆不需要本地仓库。
第三是水平扩展。Scion 不把完整仓库塞进某一台机器。所有数据内容寻址，存下后不变，任何服务器都能缓存。没有 git packfiles，也就没有仓库维护。
第四是提交必须便宜。每次 commit、rebase、merge 都发生在服务端，成本只随变更大小增长，不随整个仓库膨胀。Scion 还刻意减少 refs，因为全局状态越多，扩展越麻烦。
第五是工作副本可选且稀疏。CI 只要 diff，就只问服务器要 diff。任务只要几个目录，就只拉几个目录。文件可以按需 materialize。
在数据结构上，Scion 用 changeset 作为工作单元。它记录相对父提交变化的文件列表，并指向压缩文件内容。服务端创建后，全局立刻可用。没有打包文件，没有锁，没有跨服务器协调。
为了回答 blame、路径历史、commit graph 这类问题，Scion 再从 changeset 生成 derived data。需要就算，不需要就不算。客户端看不到内部结构，服务端可以持续优化。
真正的收益，藏在缓存和少拉数据里
Scion 的客户端协议也和 git 不一样。它不告诉服务器自己已经有啥，只说现在要啥。从根树开始，缺哪个 tree 就递归要哪个，再要 blob。每个请求都是不可变对象，任何缓存都能回答。
这套架构像传统分层缓存。客户端连到本机 scion-daemon，daemon 服务整个节点；再往上是区域 scion-cache；最后才是权威 scion-server。缓存命中时，对象直接从内存流出，不用现场算 delta。
每层缓存命中率超过99%。 结果很直接：Scion 基础设施的 CPU 和内存占用，比之前 git mirror 体系小200倍。CI 和研究任务检出代码从分钟级降到秒级。仅 CI 就拿到25% CPU 容量收益。
这点我挺认同。很多 AI 编程工具还在卷生成速度，Anthropic 已经在卷生成之后怎么不塌。代码可以无限生成，系统不能无限崩溃。
反转来了：AI写代码更猛，工程师反而更难被替代
如果故事到这里，看起来像 AI 把工程师挤走。素材里最扎眼的反转恰恰相反。
Scion 和 Antique 的核心团队只有7个人。5个月里，他们一边迁移整个 monorepo，一边看着每日合并量增长10倍。过去，这种基础设施重写可能要更多工程师、数年迁移。
他们还遇到一个很戏剧化的案例。早期，团队手写了一版 git-to-Scion ingestion pipeline，自我感觉不错。拿到 Claude Mythos Preview 后，他们让 Claude 重写。没有额外指令，新版本内存消耗降到原来的1/20，速度快4倍，还保留了原有的隐式约束。
工程师承认，Claude 在写代码这件事上已经比他们强。但工程师没有变成旁观者。他们的角色变了：提供系统级理解，做设计取舍，决定哪些问题值得解决，以及什么时候该对 Claude 说不。
有意思的是，Agent 会为了一个不该存在的模式，违反核心系统约束。比如，有些系统会暴力线性读 commit log，去查某个变更什么时候合入主干，而不是问代码审查工具。对抗式审查也容易过火，Claude 会为了假想风险加一堆验证和复杂度。工程师得把它拉回来。
所以，代码审查也变了。团队成员仍然审查每个变更请求，但重点从逐行读代码，变成审查变更意图。
评论区不买账，但问题已经丢给整个行业
Anthropic 自己也很清楚，Scion 不适合普通团队。它只适合超大 monorepo，或者大量 agent 疯狂写代码的场景。它也很难直接开源，因为它和代码审查、搜索、CI 深度绑定，太定制。
但热门评论已经吵起来了。
如果代码变更无限增长，为什么还要版本控制？为什么不把软件当成一条永远流动的河？
为什么不先问一句，monorepo 是不是该拆？
每个大公司最终都会写自己的版本控制系统。
这些吐槽有情绪，但戳中了一个真问题：当 AI 把代码生产速度拉满，价值可能从多写代码，转向管住代码洪流。
Anthropic 也把话递给了 GitHub、GitLab 和开源社区。Git 服务端可以提供更完整的 RPC，协商协议可以改，sparse 和 shallow 能力可以更好地组合。Scion 未必是答案，但它提前踩进了一个所有开发者迟早会遇到的问题。
当写代码不再稀缺，稀缺的就变成了秩序。 AI 已经在每天合并几万个变更，人类工具链还准备按人一天提交几次来设计吗？
【锐评】：AI把代码写成了洪水，Anthropic只好先修水利；生成容易，防洪更难。
参考链接：
https://www.anthropic.com/engineering/redesigning-source-control