一天合并3万次代码：AI没先取代程序员，先压垮了Git
展开
这两天有一条消息，被大多数人当成了「程序员的圈子新闻」划过去了。Anthropic 在 10 月 13 日发了一篇工程博客，说他们把整个 monorepo 从 Git 迁走了，换成一套自研的版本控制系统，叫 Scion。听起来像是一次内部基建升级。但真正值得琢磨的，是文章开篇那句话：随着我们每天的合并量增长超过十倍，版本控制成了我们最大的开发瓶颈。——不是写代码，不是想方案，是版本控制。
一家把大模型做到世界顶尖的公司，最卡脖子的地方，居然是二十年前就已被认为「解决了」的环节。它顺带回答了一个被争论三年的问题：AI 究竟是在帮人写代码，还是在改写整个软件生产体系？
一、先看数字：从 2500 到 30000，四个月翻了 12 倍把官方口径的几个数字排在一起，图景就出来了。2026 年 5 月，Anthropic 的日均代码合并量大约是 2500 次；到 2026 年 9 月，这个数字变成了 超过 30000 次。四个月，增长超过十倍。如果按 5 月到 9 月的口径直接算，30000 ÷ 2500 = 12 倍，官方措辞是「more than tenfold」，留了保守余地。
更关键的不是总量，是构成。早在 5 月，合并进 Anthropic 代码库的代码里，已有 超过 80% 由 Claude 撰写。而在 2025 年 2 月 Claude Code 进入研究预览之前，这个比例还是个位数。换句话说，从「人写、AI 偶尔帮忙」到「AI 写、人偶尔改」，Anthropic 只用了一年半。
落到个体身上同样惊人：2026 年二季度，Anthropic 一位典型工程师每天合并的代码量，是 2024 年同期的 8 倍；有员工的说法是，自己已经差不多 5 个月没有动手写过代码了。
这句话很容易被解读成「程序员失业」，但 Anthropic 自己在文章里给了更准确的注脚：瓶颈已经从写代码，转移到了人类规模下建起来的那一整套开发基础设施——版本控制、构建、CI。写代码的产能被 AI 解开了封印，结果第一个被挤爆的，是下游那条为人类节奏设计的管道。
二、Git 到底撑不住了什么要理解 Scion 为什么必须存在，得先看 Git 在 Anthropic 面对的是什么样的体量。他们主分支的历史体积接近 100 GB，压缩后的工作副本也超过 25 GB。每天为了跑 CI，要执行大约 2500 万次 代码 checkout——这还没算开发环境、agent 沙箱和研究任务。
如果按 Git 朴素的方式去拉取，这些 checkout 对应的是每天超过 600 PB 的 git 流量。为了扛住这个量，Anthropic 在峰值时运维着数百个内部 git 镜像，同时还用上了浅克隆、稀疏检出、promisor remotes 和 blob 存储里的快照种子。
更深层的冲突在设计假设上。Git 是分布式的，它的核心承诺是：每一次克隆都是一个完整、自包含的仓库，可以离线算 diff、读历史、查 blame、切任意版本。这个特性为人类离线工作而生，非常优雅。可 Anthropic 的现实是——他们其实一直把 Git 当集中式系统用，只有一个权威副本，而几乎全部客户端都是 agent 和 job，它们按定义就永远在线。
为离线准备的完整副本能力，在在线场景下反而成了纯粹的负担：CI 任务或者内部工具想问仓库一个问题（比如「谁最后改了这一行」「两个 commit 是什么关系」），就不得不先在本地维护一份仓库拷贝。Git 设计中最引以为傲的那部分，正在主动拖垮他们扩展的能力。
三、Scion 怎么改：一次彻底的前提重置Anthropic 没有去调 Git 的参数，而是回到原点重问了一句：如果从第一天起就假定客户端永远在线、且绝大多数客户端是 AI，版本控制该长什么样？
第一条是客户端永远在线。协议围绕一个始终可达的服务端设计，客户端只在需要时去取数据。第二条是客户端与服务端彻底不对称：服务端负责重活——回答文件历史和 blame、创建 commit、执行 merge 和 rebase；客户端只维护一个有上限的本地对象缓存，把文件铺到磁盘、监听文件系统变化，给人一个顺手的交互层。
第三条在工作单元上动了刀。Scion 的最小单位叫 changeset，本质是预写式日志里的一条记录：它不像 Git commit 那样存一棵树的指针，而是存「相对 first parent 变了哪些文件」的清单，外加内容寻址指针。它在服务端创建，即刻全局可见。
配套的还有一个 derived data 机制。单个 changeset 回答不了「谁最后改过这行」，所以 Scion 额外派生出文件 blame、路径历史、commit 图跳表等结构并全部递归定义——某个 changeset 上的值，由其 parent 上的值计算得出——因此可以选择提前算还是延后算，也能在不改客户端的前提下优化内部结构。
第四条最关键：一切内容寻址，一切水平可扩展。数据一旦存下永不改变，任何服务器都能直接缓存而不必互相核对；仓库数据被打散分布，每个组件独立伸缩，服务端也不存在任何完整物化的仓库副本。没有 packfile，就不需要仓库维护。拉取协议也不再协商「客户端已有什么」，而是只对真正想要的 tree 和 blob 发起请求，全程不可变对象，任何缓存都能应答。
配套的运维后果同样说明问题。工业界标准的「合并队列加全局仓库锁」在 agent 规模下失效了，他们的替代方案是把自动化测试放到合并之后、部署之前。冲突依然存在，但原话是：Claude 修这些冲突的速度，通常比人类发现它们的速度还快。
四、7 个人、5 个月：AI 既是病因，也是药方如果说上面是技术问题，那接下来的部分是这篇博客真正的冲击所在。Scion 和它的配套代码审查工具 Antique，以及另外半打相关系统，是由7 个人的团队建起来的，并且在5 个月内完成了整个 monorepo 的迁移。而在这五个月里，每天合并的代码量还涨了十倍。
而 AI 在其中的角色是双重的。最直观的一个例子：他们年初手写了第一版 git 到 Scion 的摄取管道原型，自认为写得不错。直到拿到 Claude Mythos Preview 的早期内部快照，让模型重写整个管道——结果是内存占用少 20 倍、速度快 4 倍，同时完整保留了摄取顺序和数据结构上那些隐含的不变量。
落到系统层面的收益同样具体：Scion 的基础设施占用比此前的 git 镜像方案小 200 倍；CI 和研究任务的 checkout 快了约两个数量级，从分钟级进入秒级；单 CI 一项就拿到 25% 的 CPU 容量红利；缓存链路每层命中率都超过 99%。
五、被改写的不是岗位，是判断的分工这篇博客最耐读的部分，是关于工程师角色变化的那几段。参与这个系统的工程师们现在一致认为：Claude 写代码比他们强。但他们的价值并没有消失，而是挪到了上游——对跨系统的高层组件的理解、设计层面的取舍判断，以及决定「我们到底要解决什么问题、做到什么规模」。
有一句话非常直白：我们经常发现，工程师的作用是对 Claude 说「不」。原因是 Agent 有时会为了满足某个本就不该存在的模式，去违反系统的核心约束。迁移过程中就有多个系统绕远路——靠线性读取 commit 日志去暴力查「某个改动何时合进主干」，而不是直接问代码审查工具。这类问题，只有懂全局的人能拦下来。
于是审查的方式本身也变了：团队成员依然审查每一次改动请求，但看的是「意图」，而不是逐行读代码。还有个质量红利很说明问题：正因为 Claude 能以远超人类的速度写海量代码，Scion 反而成了他们测试最充分、防御最严密的代码库之一。官方还提到一个回溯结论：若对每次改动都做自动审查，大约能捕获 三分之一 与历史事故相关的 bug。
六、映射到投资：钱不在 Git 里，在 Token 里讲到这里，必须泼一盆冷水：Scion 是自研内部工具，Anthropic 并不打算把它拿出去卖。所以这条新闻不构成任何「版本控制概念」的直接业绩锚点。谁要是因为这篇博客去炒软件工具股，方向就错了。
但它是一枚非常清晰的产业信号弹，因为它量化了一件事：Agent 规模化运行，会把 Token 消耗放大到什么程度。一个资深工程师全年写代码，产出是肉眼可见的天花板；一个能自主拆解任务、循环调用工具、反复自我修正的 Agent，它的 token 消耗没有这个上限。Anthropic 自己的判断是——合并代码的潜在需求近乎无限，每消除一个瓶颈，代码产出就立刻再涨一轮。
这一点在国内的测算里得到了呼应。IDC 与浪潮信息联合发布的《2026 年中国人工智能计算力发展评估报告》判断，智能体正以乘数效应推动 Token 消耗激增，并给出一组被反复引用的斜率：2026 年中国智能算力规模预计达 2576.5 EFLOPS，同比增长 87.9%，2030 年进一步到 10524.3 EFLOPS，2025–2030 年复合增速由上版预测的 46.2% 上修至 50.3%。
增速的口径差异更能说明问题。有券商通信团队引述该报告时提到，2026—2030 年中国活跃智能体数量复合增长率预计约 151.2%，而 Token 消耗量的复合增长率高达 3499.3%。两个数字差出一个数量级以上，这正是一个 Agent 会反复推理、反复试错的直接体现：国内日均 Token 调用量已从 2024 年初的约 1000 亿次，增至 2026 年 3 月的约 140 万亿次。
把两侧线索接起来，逻辑链就通了：Agent 工程化落地 → 单次任务 Token 消耗数量级放大 → 推理侧算力需求持续高位 → 落到硬件与基础设施订单。与传统训练的脉冲式特征不同，Agentic AI 的消耗更具持续性。供给侧也有印证：公开报道提到 2026 年国产 AI 芯片需求约 400 万颗、实际交付约 300 万颗，存在百万级缺口，整体算力呈「高端紧张、低端宽松」的结构性错配。
所以这条新闻的映射索并不难找：不该去找「版本控制」，而应盯住 Token 通胀这条受益链上的持续推理承载环节。这也和近期机构对 A 股科技硬件的判断趋于一致——以三季报能否兑现景气为锚，关注拥挤度已明显回落、但产业订单仍在的环节。（此处仅为产业逻辑梳理，不构成投资建议，不涉及个股推荐与点位预测。）
七、三个必须保持清醒的点第一，代码行数不等于软件质量。报道方在给出 30000 这个数字时就提醒过，行数衡量的是产出体量，并不能据此判定软件是否更好，合并量暴涨也可能意味着冗余在膨胀。同一天还有个耐人寻味的对照：有研究者公开批评某项「更快的傅里叶变换」成果在渐近意义上成立、常数因子却大到天文数字，属于典型的「银河算法」——纸面上更快，真实规模下永远用不上。 benchmark 上的漂亮数字与真实工程收益之间的那道缝，正是这一轮最容易忽略的风险。
第二，瓶颈只会转移，不会消失。Anthropic 原话写了：潜在需求近乎无限，每移走一个瓶颈就立刻带来新一轮增长。今天是版本控制，明天可能是构建系统、测试用例维护、或者是「当几百上千个改动在测试跑的过程中就已经合并了，CI 到底意味着什么」这类根本性的定义问题。工具链的每一层都会被重新问一遍。
第三，实验室里的极致，不等同于你我的明天。Anthropic 是最激进使用自家产品的公司之一，7 人 5 个月换地基，是能力也是特权。对绝大多数企业而言，门槛从来不是模型够不够强，而是身份、日志、隔离、数据驻留这些上线前的合规要求。这条曲线不能简单外推到全行业。
把这些放在一起看，这篇工程博客真正告诉我们的，其实是一句很朴素的话：AI 对软件行业的改写，不是从「替代谁」开始的，而是从把为人类节奏设计的每一层基础设施挨个压垮开始的。谁先把自己的基础设施按「客户端是机器」重新设计一遍，谁才可能在下一轮里跑得动。
风险提示：以上内容仅为基于公开信息的产业逻辑梳理，不构成投资建议，不推荐个股、不预测点位。数据以原始发布方口径为准。股市有风险，投资需谨慎。
数据来源：Anthropic 官方工程博客（2026-10-13）；TokenPost 报道；IDC×浪潮信息《2026年中国人工智能计算力发展评估报告》；券商通信团队公开研究（2026-10-12）。时效截至 2026-10-14。
一家把大模型做到世界顶尖的公司，最卡脖子的地方，居然是二十年前就已被认为「解决了」的环节。它顺带回答了一个被争论三年的问题：AI 究竟是在帮人写代码，还是在改写整个软件生产体系？
一、先看数字：从 2500 到 30000，四个月翻了 12 倍把官方口径的几个数字排在一起，图景就出来了。2026 年 5 月，Anthropic 的日均代码合并量大约是 2500 次；到 2026 年 9 月，这个数字变成了 超过 30000 次。四个月，增长超过十倍。如果按 5 月到 9 月的口径直接算，30000 ÷ 2500 = 12 倍，官方措辞是「more than tenfold」，留了保守余地。
更关键的不是总量，是构成。早在 5 月，合并进 Anthropic 代码库的代码里，已有 超过 80% 由 Claude 撰写。而在 2025 年 2 月 Claude Code 进入研究预览之前，这个比例还是个位数。换句话说，从「人写、AI 偶尔帮忙」到「AI 写、人偶尔改」，Anthropic 只用了一年半。
落到个体身上同样惊人：2026 年二季度，Anthropic 一位典型工程师每天合并的代码量，是 2024 年同期的 8 倍；有员工的说法是，自己已经差不多 5 个月没有动手写过代码了。
这句话很容易被解读成「程序员失业」，但 Anthropic 自己在文章里给了更准确的注脚：瓶颈已经从写代码，转移到了人类规模下建起来的那一整套开发基础设施——版本控制、构建、CI。写代码的产能被 AI 解开了封印，结果第一个被挤爆的，是下游那条为人类节奏设计的管道。
二、Git 到底撑不住了什么要理解 Scion 为什么必须存在，得先看 Git 在 Anthropic 面对的是什么样的体量。他们主分支的历史体积接近 100 GB，压缩后的工作副本也超过 25 GB。每天为了跑 CI，要执行大约 2500 万次 代码 checkout——这还没算开发环境、agent 沙箱和研究任务。
如果按 Git 朴素的方式去拉取，这些 checkout 对应的是每天超过 600 PB 的 git 流量。为了扛住这个量，Anthropic 在峰值时运维着数百个内部 git 镜像，同时还用上了浅克隆、稀疏检出、promisor remotes 和 blob 存储里的快照种子。
更深层的冲突在设计假设上。Git 是分布式的，它的核心承诺是：每一次克隆都是一个完整、自包含的仓库，可以离线算 diff、读历史、查 blame、切任意版本。这个特性为人类离线工作而生，非常优雅。可 Anthropic 的现实是——他们其实一直把 Git 当集中式系统用，只有一个权威副本，而几乎全部客户端都是 agent 和 job，它们按定义就永远在线。
为离线准备的完整副本能力，在在线场景下反而成了纯粹的负担：CI 任务或者内部工具想问仓库一个问题（比如「谁最后改了这一行」「两个 commit 是什么关系」），就不得不先在本地维护一份仓库拷贝。Git 设计中最引以为傲的那部分，正在主动拖垮他们扩展的能力。
三、Scion 怎么改：一次彻底的前提重置Anthropic 没有去调 Git 的参数，而是回到原点重问了一句：如果从第一天起就假定客户端永远在线、且绝大多数客户端是 AI，版本控制该长什么样？
第一条是客户端永远在线。协议围绕一个始终可达的服务端设计，客户端只在需要时去取数据。第二条是客户端与服务端彻底不对称：服务端负责重活——回答文件历史和 blame、创建 commit、执行 merge 和 rebase；客户端只维护一个有上限的本地对象缓存，把文件铺到磁盘、监听文件系统变化，给人一个顺手的交互层。
第三条在工作单元上动了刀。Scion 的最小单位叫 changeset，本质是预写式日志里的一条记录：它不像 Git commit 那样存一棵树的指针，而是存「相对 first parent 变了哪些文件」的清单，外加内容寻址指针。它在服务端创建，即刻全局可见。
配套的还有一个 derived data 机制。单个 changeset 回答不了「谁最后改过这行」，所以 Scion 额外派生出文件 blame、路径历史、commit 图跳表等结构并全部递归定义——某个 changeset 上的值，由其 parent 上的值计算得出——因此可以选择提前算还是延后算，也能在不改客户端的前提下优化内部结构。
第四条最关键：一切内容寻址，一切水平可扩展。数据一旦存下永不改变，任何服务器都能直接缓存而不必互相核对；仓库数据被打散分布，每个组件独立伸缩，服务端也不存在任何完整物化的仓库副本。没有 packfile，就不需要仓库维护。拉取协议也不再协商「客户端已有什么」，而是只对真正想要的 tree 和 blob 发起请求，全程不可变对象，任何缓存都能应答。
配套的运维后果同样说明问题。工业界标准的「合并队列加全局仓库锁」在 agent 规模下失效了，他们的替代方案是把自动化测试放到合并之后、部署之前。冲突依然存在，但原话是：Claude 修这些冲突的速度，通常比人类发现它们的速度还快。
四、7 个人、5 个月：AI 既是病因，也是药方如果说上面是技术问题，那接下来的部分是这篇博客真正的冲击所在。Scion 和它的配套代码审查工具 Antique，以及另外半打相关系统，是由7 个人的团队建起来的，并且在5 个月内完成了整个 monorepo 的迁移。而在这五个月里，每天合并的代码量还涨了十倍。
而 AI 在其中的角色是双重的。最直观的一个例子：他们年初手写了第一版 git 到 Scion 的摄取管道原型，自认为写得不错。直到拿到 Claude Mythos Preview 的早期内部快照，让模型重写整个管道——结果是内存占用少 20 倍、速度快 4 倍，同时完整保留了摄取顺序和数据结构上那些隐含的不变量。
落到系统层面的收益同样具体：Scion 的基础设施占用比此前的 git 镜像方案小 200 倍；CI 和研究任务的 checkout 快了约两个数量级，从分钟级进入秒级；单 CI 一项就拿到 25% 的 CPU 容量红利；缓存链路每层命中率都超过 99%。
五、被改写的不是岗位，是判断的分工这篇博客最耐读的部分，是关于工程师角色变化的那几段。参与这个系统的工程师们现在一致认为：Claude 写代码比他们强。但他们的价值并没有消失，而是挪到了上游——对跨系统的高层组件的理解、设计层面的取舍判断，以及决定「我们到底要解决什么问题、做到什么规模」。
有一句话非常直白：我们经常发现，工程师的作用是对 Claude 说「不」。原因是 Agent 有时会为了满足某个本就不该存在的模式，去违反系统的核心约束。迁移过程中就有多个系统绕远路——靠线性读取 commit 日志去暴力查「某个改动何时合进主干」，而不是直接问代码审查工具。这类问题，只有懂全局的人能拦下来。
于是审查的方式本身也变了：团队成员依然审查每一次改动请求，但看的是「意图」，而不是逐行读代码。还有个质量红利很说明问题：正因为 Claude 能以远超人类的速度写海量代码，Scion 反而成了他们测试最充分、防御最严密的代码库之一。官方还提到一个回溯结论：若对每次改动都做自动审查，大约能捕获 三分之一 与历史事故相关的 bug。
六、映射到投资：钱不在 Git 里，在 Token 里讲到这里，必须泼一盆冷水：Scion 是自研内部工具，Anthropic 并不打算把它拿出去卖。所以这条新闻不构成任何「版本控制概念」的直接业绩锚点。谁要是因为这篇博客去炒软件工具股，方向就错了。
但它是一枚非常清晰的产业信号弹，因为它量化了一件事：Agent 规模化运行，会把 Token 消耗放大到什么程度。一个资深工程师全年写代码，产出是肉眼可见的天花板；一个能自主拆解任务、循环调用工具、反复自我修正的 Agent，它的 token 消耗没有这个上限。Anthropic 自己的判断是——合并代码的潜在需求近乎无限，每消除一个瓶颈，代码产出就立刻再涨一轮。
这一点在国内的测算里得到了呼应。IDC 与浪潮信息联合发布的《2026 年中国人工智能计算力发展评估报告》判断，智能体正以乘数效应推动 Token 消耗激增，并给出一组被反复引用的斜率：2026 年中国智能算力规模预计达 2576.5 EFLOPS，同比增长 87.9%，2030 年进一步到 10524.3 EFLOPS，2025–2030 年复合增速由上版预测的 46.2% 上修至 50.3%。
增速的口径差异更能说明问题。有券商通信团队引述该报告时提到，2026—2030 年中国活跃智能体数量复合增长率预计约 151.2%，而 Token 消耗量的复合增长率高达 3499.3%。两个数字差出一个数量级以上，这正是一个 Agent 会反复推理、反复试错的直接体现：国内日均 Token 调用量已从 2024 年初的约 1000 亿次，增至 2026 年 3 月的约 140 万亿次。
把两侧线索接起来，逻辑链就通了：Agent 工程化落地 → 单次任务 Token 消耗数量级放大 → 推理侧算力需求持续高位 → 落到硬件与基础设施订单。与传统训练的脉冲式特征不同，Agentic AI 的消耗更具持续性。供给侧也有印证：公开报道提到 2026 年国产 AI 芯片需求约 400 万颗、实际交付约 300 万颗，存在百万级缺口，整体算力呈「高端紧张、低端宽松」的结构性错配。
所以这条新闻的映射索并不难找：不该去找「版本控制」，而应盯住 Token 通胀这条受益链上的持续推理承载环节。这也和近期机构对 A 股科技硬件的判断趋于一致——以三季报能否兑现景气为锚，关注拥挤度已明显回落、但产业订单仍在的环节。（此处仅为产业逻辑梳理，不构成投资建议，不涉及个股推荐与点位预测。）
七、三个必须保持清醒的点第一，代码行数不等于软件质量。报道方在给出 30000 这个数字时就提醒过，行数衡量的是产出体量，并不能据此判定软件是否更好，合并量暴涨也可能意味着冗余在膨胀。同一天还有个耐人寻味的对照：有研究者公开批评某项「更快的傅里叶变换」成果在渐近意义上成立、常数因子却大到天文数字，属于典型的「银河算法」——纸面上更快，真实规模下永远用不上。 benchmark 上的漂亮数字与真实工程收益之间的那道缝，正是这一轮最容易忽略的风险。
第二，瓶颈只会转移，不会消失。Anthropic 原话写了：潜在需求近乎无限，每移走一个瓶颈就立刻带来新一轮增长。今天是版本控制，明天可能是构建系统、测试用例维护、或者是「当几百上千个改动在测试跑的过程中就已经合并了，CI 到底意味着什么」这类根本性的定义问题。工具链的每一层都会被重新问一遍。
第三，实验室里的极致，不等同于你我的明天。Anthropic 是最激进使用自家产品的公司之一，7 人 5 个月换地基，是能力也是特权。对绝大多数企业而言，门槛从来不是模型够不够强，而是身份、日志、隔离、数据驻留这些上线前的合规要求。这条曲线不能简单外推到全行业。
把这些放在一起看，这篇工程博客真正告诉我们的，其实是一句很朴素的话：AI 对软件行业的改写，不是从「替代谁」开始的，而是从把为人类节奏设计的每一层基础设施挨个压垮开始的。谁先把自己的基础设施按「客户端是机器」重新设计一遍，谁才可能在下一轮里跑得动。
风险提示：以上内容仅为基于公开信息的产业逻辑梳理，不构成投资建议，不推荐个股、不预测点位。数据以原始发布方口径为准。股市有风险，投资需谨慎。
数据来源：Anthropic 官方工程博客（2026-10-13）；TokenPost 报道；IDC×浪潮信息《2026年中国人工智能计算力发展评估报告》；券商通信团队公开研究（2026-10-12）。时效截至 2026-10-14。
话题与分类：
主题股票：
主题概念：
声明：遵守相关法律法规，所发内容承担法律责任，倡导理性交流，远离非法证券活动，共建和谐交流环境！
