Anthropic：日合并从 2500 涨到 3 万后，7 人用 Claude 五个月换掉 Git

· Simon Willison · 日刊 2026-10-14 · 来源 ↗

Simon Willison 转述 Anthropic：Claude 把写代码的瓶颈换成源码系统。7 人五个月自建 Scion，CI 检出从分钟级降到秒级，基础设施缩小约 200 倍。

结论

Simon Willison 转述的是 Anthropic 工程团队一篇很具体的应用故事，不是再讲一遍「换个更强模型」。Claude 已经能自己迭代研究循环、微优化程序、从零搭服务，写代码不再是瓶颈；卡住的是按人的节奏设计的源码系统、构建和 CI（持续集成：每次改动自动检出代码、跑测试）。Anthropic 原文 写：2026 年 5 月每天大约合并 2500 次改动，9 月超过 3 万。7 个人用 Claude 五个月自建了 Scion（内部源码系统）和 Antique（代码评审界面），并把单体仓库从 Git 迁完。Claude 既制造了这个量，也帮他们把替代系统造出来。

要点

  • 量一上来，先坏的是「每人一份完整仓库」。 Git 的设计是：每个克隆都是完整副本，离线也能算 diff、看历史和 blame（逐行追溯谁改过）。Anthropic 的 main 历史大约 100 GB，压缩后的工作副本超过 25 GB。光 CI 每天大约 2500 万 次检出；按完整拉取估算，每天会超过 600 PB 流量。他们高峰时跑过几百个内部 Git 镜像，才把时间买下来。Nick G. 在 Hacker News 上回应「为何不做离线」：Claude 是 Scion 最重的用户，而且必须在线，离线就不是优先项。

  • 他们改的不是 Git 命令，是「谁在用源码系统」。 几乎所有客户端都是 Agent 和在线任务。Scion 按「客户端永远在线」来设计：提交、合并、变基、查历史都在服务器做；客户端只保留有上限的对象缓存、按需铺工作副本。CI 若只要「这次改动相对合并基线的 diff」，可以直接问服务器，不必先检出整仓。工作副本按需、稀疏，只付实际读到的目录。

  • 人定约束，Claude 写实现；对抗式评审要人把关。 工程师现在觉得 Claude 写代码比自己强，但仍要看清系统之间怎么接、规模要到哪、哪些模式绝不允许。常见角色是对 Claude 说「不」：有的迁移脚本不去问评审工具，而是线性扫提交日志去猜何时合进 main。Anthropic 大量用对抗式评审（再派一个模型专门找漏洞）。Simon 自己也在项目里这么用，感觉对得上原文：它很有效，但也会短视，人要把 Claude 从「为假想风险过度设计」里拉回来。团队仍审每一张变更单，看的是意图，不是逐行读完。

  • 验收看时间和机器，不看「我们换了源码系统」。 迁完后，Scion 的 CPU / 内存大约是旧 Git 镜像体系的 1/200；CI 和研究任务检出快两个数量级，从分钟级到秒级；仅 CI 就省下大约 25% CPU。早期用内部的 Claude Mythos Preview 重写 Git→Scion 导入管线，几乎没加指令，内存降到大约 1/20、速度快大约 4 倍，还保住了导入顺序和数据结构上的隐含约定。

  • Agent 规模下，合并队列那把「全球锁」不一定还成立。 测试还在跑时，可能已有几百甚至上千次改动合进去。他们复制不了「合入前锁住整个仓库」，于是把力气放在合入后、部署前的自动测试。并发改动会冲突，但 Claude 修冲突往往比人先发现还快。运维上，他们用 Claude Tag 在 Slack 频道里盯单个组件（daemon、缓存、Antique 合并队列），叫这些 Claude superfan：能看遥测和日志，专门刷新图表找异常。传统告警仍在，superfan 补的是告警看不出的新问题。

怎么做

面向仓库已经变大、CI 变慢、Agent 一天能开许多 PR 的 junior：不必自建一套 Git。Anthropic 也写明 Scion 不适合一般项目。先把同一组问题挡一遍。

  1. 先量瓶颈，再谈换工具。 记下：完整克隆要多久、CI 有多少任务其实只要一份 diff、合并队列要等多久、镜像或种子包离 main 尖端有多远。数字不大，就继续用 Git。

  2. 只问源码系统一个问题的任务，不要先检出整仓。 比如「这两次提交什么关系」「某行谁改的」「相对合并基线的 diff」。能走 GitHub / GitLab API 或现成的稀疏 / 浅克隆，就不要每条 CI 都拉完整历史。

  3. 人写清约束，Agent 写代码。 在指令里写死：合并时间问评审工具、不要扫整段日志；不要为假想的不信任加一层又一层校验。Review 时先问「这次想解决什么、破坏了哪条约束」，再决定要不要展开 diff。

  4. 对抗式评审指定范围。 让第二个模型找「这个 diff 在空输入、失败路径、并发时会怎样」，不要让它自由发挥「还可能有哪些安全问题」。后一种最容易把简单改动做成过度设计。

  5. 合并队列按真实并发改，不要死守全球锁。 若 Agent 的 PR 已经叠在测试窗口里，把必须阻断发布的检查留在合入后、部署前；小冲突交给 Agent 修，发布仍由人放行。

  6. 给每个关键组件安排一个「只看健康」的 Agent。 接入已有的日志和看板，专门找「今天和平时哪里不一样」。告警仍保留；Agent 负责发现告警规则还没写到的漂移。

关键图表

Anthropic 单体仓库每日合并数：Simon 在原文图上标出 2026 年各模型公开发布日 Simon 改过的原文图：2026 年 5 月大约每天 2500 次合并，9 月超过 3 万。标记的是公开发布日，不是 Anthropic 内部开始用模型的日期；他猜测 Fable / Mythos 一类模型是速度上去的关键