大跨径悬索桥的双塔与桥面在逆光中向远处延伸，钢缆呈弧线排布

瓶颈换了位置：写代码不再是瓶颈

Anthropic 工程博客 10 月 13 日的复盘开头就说透了：在他们那里，编码已经不是构建系统或做研究的瓶颈——Claude 能自己迭代研究循环、微优化复杂程序、从零搭起新服务。真正卡住的是为人类规模设计的开发者基础设施：版本控制、构建、CI。2026 年 5 月，他们日均合并约 2500 次代码变更；到 9 月超过 30000 次。他们判断这个增速不会放缓，因为「合并代码的潜在需求几乎无限」。

git 在这组数字前面为什么失效

git 是去中心化设计：每个克隆都是完整、自包含的仓库，离线也能算 diff、读历史、检出任意版本。对绝大多数仓库这是对的，但他们的 monorepo 已经不在这个设计空间里：仅主分支历史就接近 100 GB，压缩后的工作副本超过 25 GB；每天为 CI 做约 2500 万次代码检出，还没算开发环境、智能体沙箱和研究任务；按最朴素的方式拉取，每天要产生 600 PB 以上的 git 流量。浅克隆、稀疏检出、内部镜像、快照这些招他们全用过，峰值时维护着几百个内部 git 镜像，而随合并率上升，这套办法越来越难运营。

Scion 的五条设计原则

转折点来自一个观察：他们其实一直把 git 当中心化系统用（只留一份权威副本），客户端却几乎全是天然在线的智能体与任务——让 git 优秀的那些「支持离线、需要完整副本」的特性，正在拖后腿。于是他们照「客户端永远在线」重新设计：①客户端永远在线，数据按需向服务器取；②客户端与服务器不对称，历史、blame、提交、合并全在服务端做，客户端只留有界缓存；③一切水平可扩展，数据分布式存放，没有任何地方留完整副本，也没有 packfile 与仓库维护；④提交便宜、增量、无锁，工作单元是写前日志里的一条 changeset，成本只随改动大小增长；⑤工作副本可选、天生稀疏。他们参考了 Google Piper 与 Meta Sapling 的经验。

结果：基建占用小 200 倍，7 个工程师干完

除 Scion，同期他们还做了代码评审界面 Antique、代码搜索与细粒度权限系统。整套基建的 CPU 与内存占用只有过去 git 镜像方案的 200 分之一，CI 与研究任务的检出从分钟级降到秒级，仅 CI 一项就回收了 25% 的 CPU 容量，每层缓存命中率都在 99% 以上。人这边：7 个人、5 个月，还是在日合并量涨 10 倍的同时完成自研与全量迁移。文章里最扎眼的一句是：工程师的很大一部分工作是「对 Claude 说不」，因为智能体常为了迎合某个本不该成立的模式去破坏核心约束；审查方式也变了——每份变更仍由人过目，但看的是意图，而不是逐行读代码。另一条旧信念被推翻：在智能体规模下，合并队列本身没什么意义，于是他们把投入转到合并后与部署前的自动化测试。文章也自己划了边界：Scion 不是 git 的通用替代品，只对「几万工程师或一大群智能体疯狂写代码」的超大 monorepo 成立。

对做企业数字化、小团队的实际启发

三点。第一，「AI 提效」的下一段瓶颈多半不在模型，而在流程与工具链的承载力——产出速度一上去，评审、合并、CI、发布这些为人设计的环节会先塌。第二，小团队不必抄 Scion，但要抄它的取舍：让执行端尽量无状态、按需取数据，让成本随改动大小增长而不是随仓库大小增长。第三，把模型当盯盘的人用，成本极低：一个组件一个频道，只给它看这个组件的遥测与日志，比让它泛泛地「监控整个系统」有效得多。