从 Git 到 Scion：AI 研发、大仓库与有效产出

2026 年 10 月，Anthropic 公开了内部版本控制系统 Scion：随着 AI 参与研发越来越多，公司把自己的 monorepo 从 Git 迁走了。monorepo 指把多个项目、服务和共享库放在同一个版本库里；它可以统一修改和依赖，也会把原本分散的规模压力集中起来。Anthropic 的工程文章随后引发了 Hacker News 上关于架构、成本和研发价值的讨论，让「Git 是否跟不上 AI」成为一个很容易站队的话题。

支持者看到的是，Agent 写代码的速度终于迫使基础设施升级了。怀疑者看到的是，AI 制造了大量代码和返工，又用更多 AI 去维护这些新增复杂度。

这两种解释都能讲通一部分现象。负载规模、系统性能与研发价值，需要分别找证据。系统设计和运行数据可以说明 Anthropic 遇到什么压力、Scion 如何应对；判断这些工作是否值得做，则需要把变更一路追踪到交付、质量和成本。

我更倾向于这样的判断：Anthropic 确实面对一种值得专门优化的工程负载，但公开资料还不足以判断其中有多少是有价值的增量研发，又有多少是 AI 引入的返工。Git 的取舍也没有因此失效。它仍然适合大量团队，只是超大仓库、持续在线的机器客户端和高频并发写入，让另一组取舍变得有吸引力。

以下资料核对至 2026 年 10 月 17 日。公司工程博客属于一手自述，能说明设计和报告的运行结果，不能自动视为独立审计；历史案例会保留其发表时间，避免把旧数字当作今天的现状。

The Register 的报道把这件事放进 AI 代码增长与基础设施压力的背景中，TechSpot 的报道则梳理了客户端、服务端与测试流程的变化。两篇报道的关键性能数字仍来自 Anthropic。它们帮助理解事件，但不能当成两次独立复测。评估设计还需要公开实现和既有工程经验，评估研发价值则需要另看实证研究。

先把三万次变更和两千五百万次 checkout 读准确

Anthropic 原文里最吸引注意力的数字，可以先压缩成这张表。

数字	对应的统计对象
2026 年 5 月约 2,500 次／天	当时的日均合并量
2026 年 9 月 9 日 30,401 次	图中标出的单日合并峰值
主干历史接近 100 GB	仓库历史的规模
压缩工作副本超过 25 GB	源码工作副本的规模
每天约 2,500 万次	CI 获取代码的 checkout，不包含开发环境、Agent 沙箱和研究任务

这些数字和图表来自原文的负载说明。其中「每天三万次」容易被转述成稳定日均，但图里的峰值与七日均线并不相同。把五月的平均值和九月的峰值直接相除，再称为生产力增长倍数，已经混用了统计口径。图中还经历了从 PR 到 Antique CR 的切换，计数单位是否始终等价也需要核对。PR 和 CR 都可以表示待审查、待合入的一组修改，拆分粒度却未必一致。

原文提到的每天超过 600 PB，是假设这些 checkout 都直接获取完整大副本时的估算。它表达了朴素方案不可承受，并不是 Anthropic 真实测得的日流量。公司此前已经使用了浅克隆、稀疏检出、按需取对象、内部镜像和种子快照。

另一个常见推导是：2,500 万除以 3 万约等于 833，所以平均每次修改需要失败重试 833 次。这个算式无法支持这样的结论。

首先，两组数字没有提供同一天、同一批变更的对应关系。其次，合并量主要是最终进入主干的变更，而 CI 还会检查尚未合并的候选版本。更关键的是，一次候选变更本来就可能触发许多独立任务，任务各自取代码，并不意味着前一个任务失败了。

CI 扇出示意。图中的任务和数量用于解释机制，不代表 Anthropic 的实际流水线配置。

例如，一项修改可能需要多个语言版本、操作系统、测试分片和构建目标共同验证。测试分片是把一个测试集合拆给多个任务并行执行；每个任务都可能准备自己的源码环境。作者在 Hacker News 的回应中也明确把大量 checkout 与测试和流水线分片联系起来。

三万次合并与两千五百万次 checkout 首先反映活动规模。它们既没有证明「有效研发增长了十几倍」，也没有证明「绝大多数都在返工」。要区分这两种情况，必须继续拆分活动来源。

外部讨论的分歧，分别在要求什么证据

Hacker News 的长讨论串里，扩展能力、研发成本、工程师职责和技术传承几条线交织在一起。下面挑的是能够检验的代表性论点，属于定性归纳，不代表评论区的意见比例。评论用来提出问题，技术事实仍要回到文档、实现或测量。

Git 的常规优化，究竟卡在了哪里

用户 nh2 希望看到对既有方案具体限制的说明，而不仅是「朴素做法不可行」。他关注的是「what existing Xs can’t do and why」——现有工具做不了什么、为什么做不了。

这是对选型论证的合理要求。完整副本乘以任务数，只能排除最昂贵的方案；要证明整体迁移划算，还应比较经过优化的 Git 方案在相同负载下的成本、长尾延迟与维护难度。

Scion 工程师 Nick 在回应磁盘布局与扩展问题时强调，大量需要源码的节点和快速增长的仓库，使 Git 的数据组织方式难以满足他们的运行需求。公开材料解释了内部为何不再继续扩展旧方案，但外部团队仍缺少在同等负载下复现选型比较所需的配置和数据。

系统能扩展，是否值得把活动继续扩大

用户 horsawlarway 认可设计值得研究，同时质疑经济收益。他的核心表述是「Lots of activity is not necessarily synonymous with productivity」，即活动多并不自动等于生产力高。在后续回应中，他继续追问模型调用、CI、代码与内部工具的成本，能否换来客户在意的价值。

这条质疑并不需要先证明 Scion 性能不好。即使源码分发已经很便宜，组织仍需要判断哪些任务值得进入研发队列。反过来，仅凭活动量大、融资多，也无法推定新增工作大多没有价值。能让双方真正接近答案的，是任务完成、使用结果、质量和总成本的关联数据。

AI 写得越快，领域判断越重要

用户 crakhamster01 对工程结果表示认可，却认为它凸显了领域知识的重要性。他关注的是工程师如何约束系统、拒绝不合适的实现，而非把「能生成代码」等同于「能独立完成架构选择」。

开发者 Simon Willison 在自己的评论中也把注意力放在对抗式审查上：他尝试让不同模型互相寻找问题，并认同这种审查可能促使系统过度设计，仍需要熟悉目标的人掌握取舍。这里的对抗式审查，是让另一轮评审主动寻找原方案的漏洞。

审查次数多，不一定代表质量同比例提高；如果模型不断迎合假想风险，设计会越来越复杂。评估 AI 协作，应同时看它发现了哪些真实问题，以及工程师为排除误报、限制复杂度付出了多少成本。

Git 为什么曾经是一个非常合适的答案

Git 于 2005 年诞生，背景是 Linux 内核开发与 BitKeeper 的免费使用关系终止。BitKeeper 本身也是分布式版本控制系统，不能把这段历史简化成「集中式工具不行，于是发明了分布式 Git」。Git 将速度、非线性开发和充分分布式作为明确目标，并要求能够处理 Linux 这类大型项目。

理解这段背景很有帮助：Git 需要支持分散在各处的开发者，各自拥有工作历史，通过不同维护者逐层集成。它没有要求所有人始终连接一家公司的内网服务，也没有把一个全球唯一的提交入口作为所有操作的前提。

快照、对象复用与内容寻址

从使用语义看，一个 Git commit 代表某一时刻的项目快照，并指向父提交。底层的对象模型用 blob 保存文件内容，用 tree 表示目录，用 commit 连接快照、父提交和提交元数据。这些对象通过内容计算出的标识来引用，称为内容寻址。

「保存快照」不等于「每次提交都复制一遍整个仓库」。未变化的文件对象可以复用；修改一个文件，会产生相应的新内容对象和受影响路径上的树对象，而不是把所有未变文件重新存一份。对象还可以通过 packfile 压缩打包。

也不能据此断言「每次 commit 都要重新对全仓库所有内容算哈希」。识别变化、构造新树、维护索引确实需要工作，但代价与具体命令、文件系统状态和优化机制有关。把所有开销都归结为哈希算法，会误判真正的瓶颈。

内容寻址带来一个很实用的性质：对象一旦确定，其内容就能被校验，也很适合复用和缓存。不过，内容正确、来源可信、操作获得授权，是三个不同问题。一个哈希不能证明谁批准了提交；提交签名、访问控制和审查流程各有自己的职责。

本地能力与分布式协作

对于一个完整克隆，开发者可以在本地查看历史、比较版本、创建提交和分支，很多工作无需等待网络。Git 官方把本地操作、完整性和分布式能力放在其核心特性中。

这让研发获得了相当大的自主性。远程平台暂时不可用时，本地工作仍能继续；组织也可以迁移托管平台、建立镜像、通过标准格式交换历史。对开源项目、跨组织协作、网络不稳定的环境，以及希望保留工具选择权的团队，这些能力有长期价值。

分支的创建成本较低，也让尝试方案和隔离未完成工作更方便。不过，分支创建便宜，不代表长期分叉的维护便宜。两条开发线持续改变同一组接口，最终仍要支付理解、合并和测试成本。我在之前的Git 多人协作文章里讨论过历史组织与集成方式；这次的规模问题，也离不开这些协作选择。

Git、代码托管平台与研发制度是不同层次

Git 管对象、历史、引用和版本操作。GitHub、GitLab 等平台还承担账号权限、代码审查、流水线调度、搜索、制品和界面。一个平台发生数据库拥塞或 CI 排队，并不能直接归因于 Git 对象模型。

再上一层是团队如何工作：是否允许长期开发分支，什么检查必须合并前完成，谁能批准敏感目录，如何发布和回滚。这些规则可以建立在 Git 上，也可以建立在另一套版本控制系统上。

把这三层分开，才能判断一次「替换 Git」到底替换了什么。只改服务端存储，保留客户端协议和现有审查流程，与连客户端、评审、搜索、CI 一起迁移，成本相差很大。

Git 的局限，什么时候会变成真正的成本

Git 擅长保存和交换代码历史，但一个通用工具不可能让所有负载都免费。大仓库尤其需要区分四个维度：内容体积、文件数量、历史增长速度，以及并发访问模式。

一个包含少量大文件的仓库，可能主要受网络和磁盘影响；一个包含数百万小文件的仓库，可能更受目录遍历、文件元数据和索引维护影响；一个改动极快的主干，会给镜像同步和缓存预热增加压力；大量短命 CI 容器，则可能反复支付冷启动与获取代码的成本。

这些问题可能同时存在。只知道「仓库 100 GB」，还不足以定位瓶颈，更不能确定应该拆仓库还是重写版本控制。

Git 并不强制所有客户端永远保存全量副本

Anthropic 用完整、自包含的克隆来概括 Git 的经典优势，但今天的 Git 已经有多种减少本地数据的方法。讨论时要把它们分清。

方法	主要缩小什么	需要注意什么
浅克隆	下载的提交历史深度	依赖较早历史的操作可能需要补取
部分克隆	先下载的对象集合	缺失对象按需获取，相关操作会依赖远程
稀疏检出	工作目录中展开的文件范围	单独使用不保证仓库对象下载也同步减少

部分克隆文档明确说明，仓库可以缺少某些 blob 或 tree，再从承诺提供这些对象的远端按需取回；它与浅克隆限制提交历史是不同维度。稀疏检出文档则主要描述工作目录的文件子集。

这些机制是否能解决实际负载，需要继续测量。它们能否可靠组合，服务器承担的协商和对象准备是否便宜，历史查询是否频繁触发补取，缓存和镜像是否跟得上主干，都会影响最终成本。

同样，git worktree 可以让同一台机器上的多个工作目录共享对象库，但不会自动让分散在成千上万台机器上的任务共享全部磁盘数据。选项本身与它能覆盖的部署范围，也需要对应起来。

分布式能力可能被在线机器很少使用

一个只存活几分钟的 CI 任务，通常只需要确定版本的少量输入，完成检查后就被销毁。为它准备一个具备广泛历史操作能力的环境，未必是最便宜的交付方式。

这里的成本来自能力与需求之间的距离。开发者需要完整历史，并不意味着每个测试任务也需要；Agent 需要读取几个文件，并不意味着必须先建立一个完整工作区。有些任务适合远程查询接口，有些需要真实文件系统，有些则只需要已经构建好的制品。

但不能从「服务端可以帮忙」继续推导成「所有协调问题都消失了」。允许大量提交并行创建，与让它们同时更新同一个主干引用，是不同事情。对象可以不可变、容易分发；决定谁成为最新主干，仍然需要明确的一致性和冲突处理规则。

版本控制的另一条边界是语义。两项修改没有碰到同一行，也可能互相破坏：一项改变接口约定，另一项仍按旧约定调用。Git 的文本合并成功，无法证明程序正确。换成 Scion，也不会让这种问题自动消失。

大公司早就面对过类似问题，只是答案并不相同

Google、Meta 和 Microsoft 的经验说明，大仓库的扩展压力早于生成式 AI。AI 可以放大这种压力，也可能改变客户端构成，但没有重新发明代码依赖、缓存、协作和一致性的基本问题。

图中摘取各案例的侧重点，不表示完整架构或性能排名。Meta 的派生索引由 Mononoke 提供，按需文件与 EdenFS 工作区有关；Microsoft 对应下文的 2017 年案例。

Google：统一主干要与构建、测试和权限一起设计

Google 在 2016 年发表的论文已经讨论了超大单仓库及其配套系统。2020 年出版的《Software Engineering at Google》在版本控制章节中介绍了 Piper：集中管理的版本控制服务，运行在分布式基础设施上。书中记录了每个工作日约六万到七万次提交，明确包含人类与半自动流程。

这个历史数字至少排除了一种过强推断：每天数万次提交，本身不必然意味着 AI 返工。它也不是 Anthropic 生产力的对照组。公司规模、变更粒度、自动化占比与研发任务都不同，而且这是书中当时的情况。

Google 的做法有几个相互配合的部分。版本控制章节强调统一的权威主干、尽量短的开发分叉、细粒度 OWNERS 审批，以及避免内部依赖长期存在多个相互竞争版本的 One-Version Rule。这里的「一个版本」主要约束内部源码依赖，不能理解成所有已部署服务和外部客户端瞬间同步升级。

主干开发也不意味着把未经验证的半成品直接暴露给用户。未完成的功能可以通过开关隔离；跨模块修改可以分阶段保持兼容；开发者仍然有待提交的工作副本。减少长期分支，是为了减少分歧积累，并不取消审查与测试。

另外两块配套能力尤其值得借鉴。

一块是构建。《Software Engineering at Google》的构建系统章节介绍了显式输入依赖、可复现的构建动作、远程缓存和远程执行。相同输入应能得到相同输出，缓存才可以安全复用；否则，缓存命中只是把旧错误传播得更快。

这直接改变源码获取问题。如果一个任务的目标、依赖和输入可以准确确定，就有机会只传所需输入，或者直接复用已有构建结果。为了少 clone 几次而不梳理构建依赖，常常只能优化表面。反过来，错误地省略真实依赖，会让增量构建和测试选择产生漏检。

另一块是测试分层。持续集成章节说明，大规模系统难以把所有测试都塞进每次提交之前；需要兼顾快速、可靠的提交前检查与提交后检测、故障定位和回滚。书中也讨论了并发提交分别通过测试、组合后却出错的情况。

因此，合并后测试并非 Anthropic 独有的新发明。但这项历史经验也没有证明「可以拿掉所有提交前检查」。真正可迁移的是按风险组织验证：便宜而有区分力的检查尽早运行，较重的检查放到合适阶段，同时准备好阻断发布、定位和恢复机制。

Meta：客户端、服务端和文件系统分别扩展

Meta 的方案常被笼统称为 Sapling，但它实际包含几个职责不同的部分：Sapling 客户端、Mononoke 服务端，以及 EdenFS 虚拟文件系统。客户端交互、历史存储服务和工作目录文件获取，可以分别优化。

Mononoke 架构文档描述了一种值得关注的分工：使用统一的内部 changeset 模型，把不可变数据放入对象存储，并为历史遍历等查询派生相应数据。changeset 可以理解为系统内部表达一组版本修改的记录；派生数据则是为了更快回答某类查询而额外生成的索引或表示。

这带来的启发是，写入时的权威记录与读取时的高效表示未必必须完全一致。服务端可以提前计算、按需计算并缓存某些历史信息，客户端只获取自己真正使用的文件。代价也很明确：索引要维护，派生任务会失败，服务要扩容，缓存和权威存储要配合，运维复杂度并没有凭空消失。

「开源」与「拿来就能运营」也要分开。Sapling 项目说明 Mononoke、EdenFS 的公开版本主要供实验，尚不是面向外部使用者提供完整支持的成品。大公司内部有部署、监控、存储和权限环境，外部团队不能只按仓库里有没有代码来估计接入成本。

Scion 发布后，参与过 Mononoke 的工程师 Rain（sunshowers）在首篇评论中对比了派生数据等设计，提出署名方面的批评。他也明确表示，传播和借鉴设计本身符合开源工作的目的。Anthropic 后来补充了 Mononoke 与 Bonsai 模型的致谢，Rain 在后续文章中表示新增说明已经足够。

这位参与者的评论能够补充技术传承与署名的来龙去脉，也带有其作为原设计贡献者的立场。它没有证明 Scion 复用了哪些代码，更不能替代性能评估。把首次批评与后续回应一起保留，比只引用争议发生时最尖锐的一句更接近事情全貌。

Microsoft：保留 Git，通过虚拟化和代理改变成本

Microsoft 的 Windows 代码库提供了另一条路线。2017 年的迁移报告记录了约 350 万个文件、约 300 GB 的 Git 仓库。团队保留 Git，借助 GVFS 按需获取内容，并通过代理缓存改善跨地域和构建服务器的访问。

报告还提到一个容易被忽略的问题：按需读取的文件会逐渐累积，工作区越来越「完整」，性能也可能变差。优化于是继续向「操作代价更接近实际修改范围」推进。按需获取不是一次配置后就永远有效，长期使用的状态也会影响结果。

Microsoft 的案例展示了保留 Git 生态、优化底层成本的路线。今天 Git 的 Scalar 文档也将大仓库配置、部分获取、稀疏检出和后台维护组合起来。GVFS 是上述 2017 年案例中的方案，Scalar 是当前 Git 提供的大仓库管理工具，具体机制和适用环境需要分别核对。

Cursor 与 GitLab：Git 协议不要求服务器照搬客户端

2026 年 8 月，Cursor 介绍了保持 Git 接口的托管架构：把写入日志、对象存储与提供读取的 Git 副本分开处理。2026 年 10 月，GitLab 的相关设计说明则讨论了兼容 Git 的新后端与面向 Agent 的接口，当时仍处于私有测试阶段。

两者都是厂商自己的技术披露，其性能数字不宜与 Scion 直接横向排名。但它们共同展示了一种中间路线：保留 Git 协议和用户工作流，在服务端减少重复计算与数据搬运，再让某些机器任务直接调用更窄的接口。

这也是普通组织很值得保留的选择。接受某个设计思想，并不要求同时放弃已有的全部工具。

Anthropic 的思考：让在线服务承担更多版本控制工作

Scion 重新分配了客户端与服务端的职责：多数客户端持续在线，历史、blame、合并等工作更多由服务端回答；客户端保留有界缓存。内部以文件级 changeset、内容寻址对象和派生数据组织版本信息，并分层缓存。主干等引用仍通过单独的原子更新协调。

图左选取 Git 的完整克隆模型。Git 也支持部分克隆和服务端扩展；图右概括 Scion 的职责分配，省略具体存储、权限和缓存层级。

这组选择有很清楚的适用条件。机器客户端数量极多，网络和服务可用性可控，任务生命周期短，需求范围往往较窄。在这种环境下，让大量客户端分别准备历史和本地状态，可能不如集中提供一个可复用的查询结果。

例如，一个 Agent 只想知道某个文件的历史，不必先为整个工作区准备一套本地历史环境；一个测试任务只需要固定版本的输入，也没有必要获得任意版本的离线操作能力。把接口设计成符合任务需求的形状，可以同时减少传输量和无用准备工作。

但收益与代价是一起移动的。原来在本地就能完成的操作，现在更依赖远程服务的延迟和可用性。服务端要承担身份校验、租户或目录权限、热点查询、跨地域访问和故障恢复。缓存可以减少读取，不能代替可靠的权威数据和更新规则。

因此，「集中式」并不等于「只用一台机器」，「分布式存储」也不等于 Git 式的分布式协作。Piper、Mononoke 和 Scion 都可以在多台机器上运行，却把权威历史与访问控制集中到一个服务体系里。Git 的每个完整克隆则有更强的独立操作能力。这是两个不同维度。

性能改善能证明到哪一步

Anthropic 报告，相关镜像基础设施的 CPU、内存开销显著下降，并释放了约四分之一的 CI CPU 容量。

这支持一个有限而重要的判断：对于公司当时的环境，减少源码分发开销确实带来了可观收益。它无法直接证明 Scion 在所有操作上都比 Git 快同一个倍数，也无法证明整个研发流程的总成本按相同比例下降。

源码获取可能只是任务耗时的一部分。假设一个十分钟的任务花了一分钟准备代码，即使把这分钟完全消除，端到端也只少一分钟。如果准备代码占了大部分时间，优化才会显著改变整体等待。这是评估任何「快了几十倍」时都应补上的分母。

同时，按单位任务节约了计算资源，并不保证总资源消耗下降。更便宜的检查可能促使团队运行更多检查，更便宜的 Agent 环境可能促使团队尝试更多方案。新增尝试有可能带来价值，也有可能扩大浪费；需要另行评估。

合并速度提高以后，质量责任移到了哪里

Anthropic 坦言，团队未能有效复制依赖全局锁的合并队列方式，转而加强合并后、部署前测试。

合并队列通常试图把候选变更放到接近真实集成结果的状态下验证，再推进主干。但一个测试运行期间，主干可能继续前进；如何控制这种版本漂移，需要付出串行等待、重新测试或更复杂调度的成本。

在高吞吐环境中，把部分验证移到合并后，可能是合理取舍。不过，需要回答的质量问题也随之改变了：

• 主干出现不兼容组合后，多久能够发现并定位到变更？
• 部署是否只使用已经通过相应检查的确定版本？
• 撤销某个变更时，是否会破坏已经依赖它的后续变更？
• 哪些高风险修改仍应在合入之前被阻断？

合并可以很快，安全交付仍然需要一条可信的验证链。系统能自动修复冲突，有助于降低恢复成本；但恢复更快与缺陷更少不是同一个指标。修复过程也可能引入新的问题，应该计入整个变更链的成本。

尤其需要区分文本冲突和语义冲突。前者可能表现为同一行无法自动合并，后者则可能表现为两个看似独立的修改让接口、数据格式或运行假设不再一致。只报告「合并成功率」，不足以评价后者。

人工审查也需要明确检查对象与责任。批准任务意图、审查关键逻辑、逐行检查全部修改，是不同强度的保障。随着生成量增加，应观察高风险修改的审查覆盖、审查者发现问题的能力和实际投入时间；只有「经过人工审批」这一项状态，无法判断验证是否跟上了吞吐。

自研的账，不能只算最初写代码的时间

Anthropic 表示，七人团队在五个月内完成了 Scion 及配套系统的建设和迁移；同时说明，这套方案与内部评审、搜索和 CI 紧密耦合，并不适合作为通用 Git 替代品。

这个结果值得认真看待，但不能和「Linus 最初用几天写出 Git」直接比较。一个初始实现、一个迁移了真实大仓库并接入完整研发链的系统，完成标准不同。AI 可以帮助生成实现，历史设计经验、成熟存储服务、内部基础设施和工程判断同样发挥作用。

对考虑跟进的团队，更有用的是估计长期总成本：客户端适配、编辑器插件、审查和搜索接入、权限模型、审计、备份恢复、数据格式演进、值班，以及未来退出这套系统的代价。源码管理一旦成为关键基础设施，后续维护不会因为最初开发得很快而消失。

还有一个经济条件不能忽略。Anthropic 明确指出自己的内部 token 使用能力与普通企业不同，内部研发也承担测试模型能力的任务。同样一次探索，对模型公司可能同时产生产品研发和模型评估收益；对其他公司，可能只有前一项。复制架构之前，需要重新核算本组织的收益与成本。

大量活动，可能同时包含有效需求和无效工作

讨论 AI 研发时，容易把所有新增活动都放进同一个篮子。实际上，至少存在几种不同来源。

既定任务更快完成。相同范围、相近质量的功能，以更少的人力和等待完成。判断这类效率提升，需要保持任务和验收条件可比。

以前不值得做的任务开始值得做。小范围体验改进、一次性迁移、更多测试覆盖、内部工具，都可能因为实现成本下降而进入待办范围。这会增加代码和检查次数，不必然是浪费。

探索范围扩大。同时尝试更多实现、训练实验或性能方案，最后只保留少数结果。如果某次尝试以合理成本排除了错误路线，就产生了信息价值，即使它的代码最终被放弃。需要记录的是实验问题、结果和后续决策。

任务拆得更细。原来一个 PR 包含十项修改，现在拆成十个 CR。计数可以增长十倍，交付范围却没有增长十倍。拆分本身可能改善审查和回滚，也可能增加调度开销。

质量缺陷引发修补。AI 误解需求、漏掉边界、使用错误接口，导致后续反复修改。这属于需要减少的返工，但不能仅凭「后来又改了这个文件」来确认。

并发协调产生额外工作。多个 Agent 重复解决同一任务、相互覆盖或不断跟随主干重做。单个 Agent 的答案可能各自合理，整个系统仍然可能低效。

还可能存在诱导活动增长的绩效目标：当团队把提交数、生成行数和 Agent 活跃度当成绩效，工具会越来越擅长增加这些数字。没有哪种版本控制可以替组织消除这种激励。

因此，有效需求与返工不是非此即彼。AI 可以在扩大可做任务范围的同时，引入新的错误和协调成本。最后应比较净收益，而不是要求每个中间步骤都能直接对应一个已上线功能。

目前有什么证据，能区分这几种解释

系统遥测记录发生了哪些操作，访谈和调查解释人们如何使用工具，对照实验则尝试估计工具造成的差异。它们回答的范围不同，需要分别读。

Anthropic 的负载解释：能说明为什么有代码，不能证明每项都值得

作者在 Hacker News 回应中列举了模型训练与服务、基础设施、研究、产品与 API 等工作。这些领域确实可能需要大量内部代码；一个公司面向用户的产品数量，也无法直接反推出其内部软件规模。

作者还承认多个 Agent 编排带来了不必要的冲突，需要改善协调。这是支持「部分额外活动可以避免」的一手材料，但没有提供占比。不能把「存在浪费」扩大成「大部分都在浪费」。

这两类回应需要一起读。前者提供合理需求的来源，后者提供协调开销的实例；它们都不足以量化最终交付价值。

内部研究：确实出现了新增任务，也确实出现了清理成本

Anthropic 在 2025 年 12 月发布的内部工作研究，基于当年 8 月的调查、访谈及 Claude 使用记录。调查中，员工估计部分 AI 辅助工作在没有 AI 时根本不会开展，报告的平均比例为 27%；访谈也提到调试、清理 AI 生成代码和理解不熟悉代码的成本。

这项研究同时支持两种机制：AI 扩大了工作范围，也制造了新的验证负担。27% 是参与者对工作范围的估计，不能转换成「27% 的提交有价值」，更不能倒推出「另外 73% 都是无效工作」。

它也不是对 2026 年 Scion 负载的随机审计。数据时间、模型、组织环境不同，而且问卷存在选择、回忆和主观判断的限制。员工感觉快了，不能替代同等任务的实际计时；描述新增任务，也不等于证明它们带来了足够收益。

企业随机实验：任务吞吐可以增加

Cui 等人的三家企业现场实验提供了正向证据。研究在 Microsoft、Accenture 和一家匿名的 Fortune 100 公司中随机分配编码助手使用权限，合并分析覆盖 4,867 位开发者，报告使用者完成任务的估计增幅约为 26.08%，标准误为 10.3 个百分点。较低经验群体的采用和收益更明显。

这支持 AI 编码助手能在特定企业环境里增加任务吞吐，但需要读清指标与估计对象。作者公开的工作论文版本把 pull request 作为工作单位，用其数量等记录衡量任务；26.08% 是针对工具使用者的估计，并非所有被分配权限的人都提高了同一个比例。这些记录也没有直接测量全部后续维护成本或业务收益。实验以当时的代码补全助手为主，与今天的自主 Agent 工作流还有距离。

它与后面的 METR 实验不构成简单的胜负关系。开发者经验、任务安排、工具形态和观察周期都不同。论文部分作者来自 Microsoft，数据也来自合作企业；随机分配增强了因果识别，作者背景与数据范围仍应透明说明。

METR：熟悉仓库里的任务未必提速

METR 的2025 年随机实验让 16 位熟悉自己开源仓库的开发者处理 246 项真实任务，随机允许或不允许使用当时的 AI 工具。允许 AI 的任务平均耗时反而增加了约 19%，而参与者仍倾向于认为 AI 帮助自己提速。

这是一项比主观满意度更直接的证据，但研究对象、熟悉程度、工具版本和任务类型都有边界。它不能被解释成所有开发者、所有任务、今天所有模型都会慢 19%，也不能直接套到 Anthropic 内部。

METR 在 2026 年 2 月的后续说明中又强调，新一轮测量受到参与选择与并行工作计时等问题影响，无法可靠给出新的统一提速幅度。开发者不愿意回到无 AI 条件，会改变谁愿意参加实验；多个 Agent 同时运行，也让「人坐在任务前多久」不再完整代表任务成本。

这个后续结果同样需要保留。只引用早期的减速数字，却省略后来测量条件与模型变化，会把一项有边界的实证研究变成过度概括。

从写代码到发版，收益会沿流程衰减

另一项更贴近 Agent 时代的材料，是 Demirer、Musolff 与 Yang 的 NBER 工作论文《Writing Code vs. Shipping Code》，以下按 2026 年 9 月修订版摘要。作者结合超过 50 万名 GitHub 开发者的活动与 AI 使用遥测，采用匹配事件研究，观察工具采用前后的变化，并与相近开发者比较。

按论文摘要中的点估计重绘，数值见绘图数据。图中未展示置信区间；这些是不同指标的累计效应估计，不是同一批代码逐步转化的比例。

这项结果支持一种具体担忧：上游编码活动增加以后，收益会受到集成、验证和其他下游环节的限制，不能按提交数的增幅直接估计交付增幅。发布次数本身也不衡量版本质量或用户收益。作者还报告，在所研究的软件市场中，新应用数量增长，并未伴随总使用量增长。

但它不是随机实验，也不是 Anthropic 内部审计。匹配和事件研究能改善比较，仍需依赖识别假设；工作论文的结论也可能随版本演进。作者也披露了部分研究者与 Microsoft 的有偿顾问关系。更不能把 240% 与 30% 的差距换算成「87.5% 的代码都是废物」：分母、统计对象不同，未发版的活动还可能包含合理探索、内部工具和后续准备。

这项研究与企业随机实验、METR 研究合起来，更支持按环境、任务和产出层级分别评估，而不是寻找一个适用于所有研发活动的「AI 提效倍数」。

更大的活动量与更好的交付，可以朝不同方向变化

DORA 在 2026 年对 AI 研发张力的讨论中，总结了 AI 采用与交付吞吐、稳定性之间并不完全一致的关系。这类研究提示应同时看速度和质量，但它讨论的是统计关联，不能据此认定某家公司因为 AI 而增加了事故。

METR 后来还从任务替代与价值测量的角度指出，只测旧任务的完成速度，可能漏掉 AI 让人转向新任务的收益。这对解释代码量增长很重要：任务集合在变，单纯做前后计数比较会混入范围变化。

这些材料合起来，能够说明为什么需要更细的测量；它们并没有给出 Anthropic 的实际返工率。目前公开资料中，还看不到把那三万次合并完整关联到需求、候选修订、部署、缺陷和后续修复的分析。

真要判断效率，需要怎样的数据

最有区分力的证据，是把同一个任务从提出到交付串起来。只拿 Git 日志做代码行数统计，很难完成这件事。

第一层：把 checkout 分解到具体触发原因

需要记录候选版本、任务类型、触发原因、是否重试、缓存状态、实际获取字节数，以及排队和准备代码的时间。这样才可以区分：必要测试分片、多个候选版本、基础设施失败重试、业务测试失败后的再运行，以及可以被取消的过期任务。

同时看总量与单位量。checkout 总数可以因为测试覆盖扩大而增长，但每个成功构建获取的字节数可能下降；反过来，单次下载很小，也可能因为无用任务暴增而使总成本上升。

这里最有用的优化指标通常是每个有效检查结果的成本、候选变更得到可信反馈的时间，以及过期任务消耗的资源。单独追求最少的 checkout，可能通过减少必要验证来制造一个漂亮数字。

第二层：以任务为单位追踪返工

给需求或实验保留稳定标识，把多个 Agent 会话、候选修改、合并记录和修复串在一起。修订原因也应该分开：需求变化、评审建议、缺陷修复、合并适配、探索失败和基础设施失败，不宜统统叫「返工」。

可以观察首次达到验收条件的时间、候选修订次数、人工审查分钟数、缺陷导致的重开率，以及上线后一定时间内的回滚和修复。对于研究任务，则应观察实验是否回答了问题、结果能否复现、是否影响了后续决策。

代码在 30 天内被改掉，可以是一个抽样信号，却不是自动判定无效的标准。需求真的变了、一次合理实验结束了、临时兼容代码完成使命了，都会导致删除。大量代码长期保留，也不代表它创造了价值。

更可靠的办法，是分层抽样，让不了解生成方式的评审者根据上下文判断修改目的与结果。自动分类可以辅助扩大样本，但需要人工检查误判，避免用另一个 AI 的标签代替证据。

第三层：比较相近任务的净交付结果

最有说服力的比较，需要尽可能保持任务类型、难度、验收条件和人员经验相近。条件允许时，可以随机分配 AI 使用方式；不能随机时，也应采用分阶段推广、匹配任务等设计，并说明仍存在的偏差。

时间要分成几个部分：人实际投入的时间，任务从开始到可用的日历时间，以及机器运行时间。并行 Agent 可能缩短日历时间，却提高机器成本；人在等待时可以去做别的事，因此也不能把所有 Agent 运行时长都算成人工工时。

成本则至少包括模型调用、CI 和基础设施、人工审查、缺陷修复，以及后续维护。一个粗略但有用的比较思路是：

每个达到同等验收条件的任务成本 = 人力投入 + 模型与运行资源 + 验证、修复和后续维护成本。

这份成本清单应覆盖从生成到维护的过程。难以货币化的交付速度、学习收益和业务结果，可以分别列出，再做决策。

第四层：单独评估新增工作的价值

对「以前不会做、现在可以做」的任务，用旧任务提速实验无法完整评估。需要先问这项新工作带来了什么：减少客服问题、降低运行成本、提高测试发现能力、缩短研究迭代，还是只是增加了内部工具数量。

研究探索也应有预算和停止条件。允许失败，有助于获得信息；没有明确问题、持续生成相近方案、无人使用结果，则更接近无效消耗。

最终可以用这样的证据组合来提高判断把握：

观察到的现象	更支持哪一种解释
相近任务更快通过验收，审查与缺陷成本未明显上升	既定研发需求获得了效率收益
新增任务有使用结果、实验结论或可核验收益	可做工作范围扩大并产生价值
修订链反复围绕同一错误，人工审查负担明显增加	生成质量导致的返工增加
重复任务、互相覆盖、过期流水线占用大量资源	编排和协调效率不足
只有提交数和代码量增长，质量与交付数据缺失	目前无法判断净收益

这张表表达的是证据方向，不是机械判定公式。同一个团队，甚至同一个任务，都可能同时出现其中几种现象。

普通团队如何吸收这些经验

大公司的实践最值得借鉴的部分，是识别成本和分配职责的方式。是否自研版本控制，应该排在测量之后。

先查清代码获取为什么慢

把一次 CI 或 Agent 任务拆成排队、拉取对象、展开文件、安装依赖、构建、测试几个阶段。分别看冷缓存与热缓存，既看中位数，也看长尾延迟。只优化 Git，可能碰不到真正耗时的依赖安装；只增加镜像，也可能解决不了工作目录里数百万文件的开销。

再检查仓库内容和生命周期。大型二进制、生成文件、重复依赖和无用历史是否应该进入源码仓库？是否能用合适的制品存储管理？历史重写会影响协作者，不能把它当成无成本清理操作。

减少重复任务，再减少每项任务搬运的数据

对于快速变化的候选版本，及时取消已经失去意义的流水线；对于重复任务，先改编排与任务分配。让多个 Agent 有明确的修改范围和验收条件，往往比单纯让版本库接受更多写入更有效。

随后根据实际需求选择浅克隆、部分克隆、稀疏检出、本地共享缓存或区域镜像。需要较早历史的任务不能盲目浅克隆；需要真实全仓分析的任务也不能错误裁剪输入。缓存应围绕不可变版本和内容组织，避免让不同任务误用可变工作区里的残留状态。

把构建和质量体系补齐

梳理依赖、提高构建可复现性，再考虑远程缓存和执行。测试选择要能解释为什么只跑这些检查；权限、审查、部署阻断和恢复机制也要对应风险。让 AI 更快生成代码时，验证能力往往更早成为限制。

如果开始采用合并后验证，应先明确可部署版本如何选定、故障如何定位，以及主干恢复的责任。不要因为某家公司能迅速修复，就假设本团队也拥有相同恢复能力。

最后再评估托管后端或版本控制迁移

当测量表明，现有 Git 方案及其优化仍无法满足成本或延迟要求，可以比较兼容 Git 的托管架构、窄接口的源码服务，以及更深的自研或迁移方案。

评估至少要覆盖真实仓库形态、冷启动、并发读写、长尾延迟、权限、故障恢复和退出路径。厂商公布的吞吐数字，只有在对象大小、缓存、提交形态和一致性要求接近时才有参考价值。

拆仓库也应基于组织和依赖边界。它可能降低单仓规模，却会增加跨仓修改、版本发布和依赖协调成本。选择 monorepo 还是多仓库，需要比较这些成本与团队边界是否匹配。

对 Scion 更值得保留的判断

Scion 展示了一件有现实意义的事：当源码访问的主要使用者变成大量短命、持续在线的机器，版本控制的默认职责可以重新分配。客户端未必需要保存同样多的数据，服务端可以承担更多查询和派生计算，研发平台也可以提供比 clone 更贴近任务的接口。

Google、Meta、Microsoft，以及仍保留 Git 接口的新架构，说明这种调整有长期积累，也存在多条路线。Anthropic 把这些思路放到了 AI 研发的高活动负载里，给出了值得研究的实例；它没有提供一条适用于所有团队的迁移指令。

至于三万次合并、两千五百万次 checkout，严谨的判断目前仍应停在这里：基础设施压力有具体的机制和一手材料支持，活动的价值构成尚缺少公开分解。把每次读代码变得便宜，是清楚的工程收益；证明新增代码值得生成，还需要交付、质量、使用结果和长期成本的证据。

AI 让更多尝试成为可能以后，工程团队需要同时做好两件事：让必要的尝试更便宜，也让没有价值的尝试更早停止。