经济性、风险与度量

区间，以及是什么在左右它

关于 AI 与开发速度的争论，靠四项随机研究撑着。它们的结果相差约 75 个百分点，但放在一起读，讲的是同一个机制，而不是四个各执一词的结论。

这种分散并不是噪声。收益来自绿地项目或标准化的工作，而且做这些工作的往往是经验较少的开发者：Peng 的受试者从零搭一个新服务器，Peng 和 Cui 也都发现经验较少的开发者获益最大。损失则来自专家在自己早已烂熟于心的大型代码库里干活——最可能的解释是，核验 AI 输出的成本吃掉了收益。Google 的企业任务落在两者之间。一项规模更小的银行实验也指向同一方向：ANZ 使用 Copilot 的一组完成任务快了 42.36%，但计时检验的样本量只有 22，而且用的是受试者自报的时间（ANZ Bank，T2）。所以效果取决于四件事。你做任何估算时，都应把它们当作调节变量：

• 任务类型。对着清晰规格写新代码，收益大；改动既有行为，收益小。
• 熟悉程度。开发者对代码越熟，助手能添的越少，它犯的错代价越高。
• 代码库成熟度。庞大、老旧、上下文厚重的仓库，留给提速的空间最小。
• 工具代际。每项研究测的都是当年的工具。一代工具上的结果，不会自动迁移到下一代。

按这些调节变量拆分结果的最大数据集并不是一项试验。斯坦福软件工程生产力研究组对 10 万多名工程师的 git 历史打分，并给出了自己的"参考性指引"（Orientative Guidelines）（Denisov-Blanch 演讲幻灯片，T3）。绿地、低复杂度的工作提升 +35–40%；绿地、高复杂度 +10–15%；棕地、低复杂度 +15–20%；棕地、高复杂度只有 +0–10%。同一份幻灯片里还有一张按语言流行度划分的矩阵，把 COBOL、Haskell、Elixir 这类小众语言的高复杂度任务放在 −5% 到 +5%。同一份幻灯片里另有一页标题，对同样四格给出了略有出入的数字（30–35%、10–15%、15–20%、5–10%）——这又是一个理由：只引用区间和作者自己的标签，绝不引用单一数字。

企业里的大多数工作都是棕地。如果你的也是，就从这张矩阵的右下角开始规划，而不是左上角。锯齿状前沿在单个任务的层面上描述的是同一个规律。

为什么干净的试验越来越少。METR 从 2025 年 8 月起尝试复做这项研究，招募了 57 名开发者、800 多个任务。"30% 到 50% 的开发者"表示，他们跳过了那些不想在没有 AI 的情况下做的任务，于是留在实验里的任务不再是公平样本。METR 的点估计偏向提速，但区间很宽（老受试者耗时 −18%，CI −38% 到 +9%；新受试者 −4%，CI −15% 到 +9%）。METR 自己的结论是，这批数据给出的是"一个不可靠的信号"（METR，2026 年 2 月，T1）。这并不是对 2025 年结果的反转。开发者如今已经拒绝脱离这些工具干活，这说明了他们感知到的价值，却无法精确说明测得的价值。你很难再拿到一项契合自己代码库的外部新试验；剩下的可信证据，是你自己的前后对比数据——要有足够多的运行次数和足够长的时间窗，才能看穿噪声（参见评测方差与统计功效）。

感知不等于测量

关于 AI 生产力，数量最多的数字——人们说它帮了自己多少——恰恰也最不可靠。METR 的开发者在研究开始前预测会提速 24%；做完任务之后，他们依然相信 AI 让自己快了约 20%。秒表给出的结果是慢了 19%。这是符号错了，不是四舍五入的误差，而且出自资深工程师对自己工作的判断。斯坦福研究组在另一个尺度上发现了同样的事：在 43 名工程师中，自评生产力与实测生产力的相关系数只有 r = 0.17，人们对自身生产力的判断平均偏差约 30 个百分位（幻灯片，T3，样本小）。与此同时，DORA 2025 年对 4,867 名受访者的调查发现，90% 的人在工作中使用 AI，超过 80% 的人相信它提高了自己的生产力（DORA 2025，调查）。

组织层面的数字远低于这种信念。Sundar Pichai 说，Google 全公司因 AI 带来的"工程速度"提升"目前是 10%"，同时承认这是"很难的度量"，且没有给出定义（Lex Fridman 播客文字稿，2025 年 6 月，T4）。贝恩报告称，"使用 AI 助手的团队获得 10% 到 15% 的生产力提升"（Bain，2025，T3；页面没有说明这个数字的依据）。规模最大的遥测序列来自 DX，数字还要更低（见下框）。跳出软件团队，丹麦关于整体劳动力市场的行政数据发现，"对收入和登记工时的影响是精确的零"，"排除了 ChatGPT 发布两年后影响超过 2% 的可能"（Humlum & Vestergaard，NBER，T1）。这是劳动力市场的结论，不是交付的结论，但它提醒我们：个人省下的时间，不一定会体现在总体结果里。

人们感觉自己快了多少，与实际多交付了多少，这之间的落差正是零碎的时间节省一文讨论的主题：任务内部省下的几分钟，很少会变成多交付的完整任务。这也是成熟度模型的规则不接受没有可观察证据的自我定级的原因。对你的商业论证来说，规则很简单：自报能告诉你大家喜不喜欢一个工具，却不能告诉你该不该为它付钱。

产量不等于价值："AI 写了百分之多少的代码"

高管汇报里被引用最多的 AI 数字——AI 写了多大比例的代码——没有定义、无法审计，也不衡量客户真正拿到的任何东西。

追踪一家公司的序列，就能看到定义在挪动。2024 年 10 月，Google 说（Alphabet 2024 年第三季度财报电话会，T4）"Google 超过四分之一的新代码由 AI 生成，再经工程师评审和接受"。2025 年 4 月："签入的代码中有 25% 涉及人们接受 AI 建议的方案……这个数字现在已远超 30%"（Alphabet 2025 年第一季度财报电话会，T4）。2026 年 4 月："Google 现在 75% 的新代码由 AI 生成并经工程师批准，去年秋天还是 50%"（Google Cloud Next 2026，T4）。"由 AI 生成"（generated by AI）、"涉及人们接受 AI 建议的方案"（involves people accepting AI-suggested solutions）和"由 AI 生成并经批准"（AI-generated and approved）是三个不同的分子。没有一次表述说明一行代码怎样才算 AI 写的。

同一位 CEO 自己就做过这种区分。2025 年 6 月，他刚提到"大约 30% 的代码现在用到了 AI 生成的建议，或者随便怎么说"，就把工程速度称为"最重要的指标"，给出 10% 的数字，并说这"不同于……'现在有多少百分比的代码由 AI 编写'这类统计"（播客文字稿，T4）。Google 此后没有公布更新的速度数字（截至 2026 年 10 月）。其他公司同样含糊：

• Microsoft。据 The Register 报道，Satya Nadella 说："我们某些项目里，如今仓库中也许 20% 到 30% 的代码大概都是由软件写的"（2025 年 4 月，T4，二手来源）。注意其中的限定词："也许"、"某些项目"、"大概"。
• Coinbase。其平台负责人说："我们现在接近 100% 的代码，大概在 95% 到 100% 之间，是由 LLM 编写或在 LLM 协助下编写的"（by or with LLMs），而核心密码学代码仍主要由人编写，并由资深密码学家逐行检查（Cointelegraph，2026 年 7 月，T4）。"编写或协助编写"覆盖了从自动补全到无人值守智能体的一切。
• DX 的季度报告。AI 编写的代码占比先是 22%（2025 年第四季度），然后是 27.4%（2026 年第一季度），再到 52.7%（2026 年第二季度），均为 T3。其中 27.4% 的定义是"未经人工大幅重写或修改而合并"的代码，测量方式是"直接询问开发者"。第二季度的新闻稿拿 52.7% 去比"两个季度前的 24%"，而不是 DX 当时公布的 22%；媒体报道还称 DX 在此期间重建了方法。三个数字、至少两种方法：这不是一个序列。

即便定义固定下来，这个占比数的也是投入，不是结果。开发者接受的建议多了，它就上升，不管交付有没有更快、故障有没有更少。瓶颈一章里有一个试点：拉取请求增加了 13.6%，有效产出只增加 1%，返工却增至 2.6 倍。用代码占比来衡量，这个试点会被判为成功。由此得出两条规则：永远不要把"AI 写了百分之多少的代码"写进商业论证或成功标准；也永远不要拿一家公司的数字去比另一家的——它们量的根本不是同一样东西。

伪装成测量的反事实

公开记录里最大的那些"节省"数字并不是测量。它们是对从未发生的工作的估算，乘上一个数量，再用过去时说出来。

算一算，就能看出这个标题数字是怎么搭起来的。以下是示意性算术，假设一个开发者年约有 250 个工作日。4,500 个开发者年约等于 1,125,000 个开发者日；除以人工升级"通常"需要的 50 个开发者日，约为 22,500 个应用，与 AWS 文章所说的"数以万计"相符。所以这个标题数字，本质上就是已升级应用的数量乘以估算的人工成本。每次升级耗费的"几个小时"并没有以任何公开的方式扣除，那 21% 需要修改的自动生成代码评审所花的工程师时间也没有。整段说法里唯一听上去像测量的比率——79%——没有分母。拿案例研究一章里的五个问题（谁测的、对照什么基线、样本和时间窗多大、"成功"算的是什么、AI 实际持有什么权限）去问一遍，它有四个答不上来。

记录更完整的案例也有同样的结构，只是程度轻一些：

• Airbnb 在六周内迁移了近 3,500 个 React 测试文件，对照的是一年半的人工估算（Airbnb 技术博客，T3）。六周是测出来的，一年半是估出来的。
• Uber 称其 uReview 机器人"每周节省约 1,500 小时，相当于每年近 39 个开发者年"。输入有两个：一项内部基准称，第二位人工评审者每次提交需要 10 分钟；以及每周"超过 10,000 次提交"（Uber Engineering，T3）。文章没有给出乘法过程；10,000 × 10 分钟约为 1,670 小时，所以公布的 1,500 小时经过了某种未说明的调整。提交次数是数出来的，每次提交省下 10 分钟是估出来的。
• 麦肯锡在 2025 年发表了一项对近 300 名高管的调查，其中 100 人评估了影响。它报告称，表现最佳者在生产力、客户体验和上市时间上获得了"16% 到 30% 的提升"，在软件质量上提升 31–45%（McKinsey）。这些结果由同一批受访者自评，而"表现最佳者"就是按这些结果划出的前五分之一。比较是循环的，所以它报告的差距有一部分是定义本身造出来的。作为结果证据，它属于 T4。

反事实仍然能告诉你一个组织认为价值在哪里。但它应该放在你计划里的"假设"一栏，而不是"证据"一栏：问清楚哪部分是测出来的，哪部分是乘出来的。本站的衡量 ROI一页讲了如何建立这些说法所缺的基线。

它要花多少钱

从按席位到按 token。让 AI 编码显得便宜的固定席位价正在退场，原因是自主度。GitHub 于 2026 年 6 月 1 日把 Copilot 从高级请求计费改为基于 token 的"AI Credits"。它给出的理由是："智能体式使用正在成为默认，它带来了显著更高的算力和推理需求。"用量现在"按 token 消耗计算，包括输入、输出和缓存 token"，而且"Copilot 代码评审也会消耗 GitHub Actions 分钟数"（GitHub changelog，2026 年 4 月）。席位价格不变，Business 每用户 19 美元、Enterprise 每用户 39 美元，每档现在都包含等额美元的 credits（截至 2026 年 4 月）。超出额度后，成本随智能体干的活儿一起增长：你委派得越多，付得越多。本站的定价模型一页比较了各种方案。

Gartner 预测，"到 2028 年，由于大语言模型（LLM）token 消耗上升以及向按用量计费许可模式的转变，AI 编码成本将超过开发者的平均薪资"；其分析师还补充说，"大多数组织仍缺乏有效衡量成本与业务影响的成熟度和框架"（Gartner，2026 年 6 月）。这是预测，不是测量；第二句话更有用。

评审是那条不会缩小的成本线。token 价格也许会降，但人工评审的分钟数不会跟着降，而智能体的产出还会制造更多评审。在 dotnet/runtime 中，已合并的智能体拉取请求平均有 16.5 条评论，人类的是 12.4 条——这里统计的是所有类型的评论，包括智能体自己的回复和机器人消息（Microsoft .NET 团队，T2）。同一个团队坦率交代了这项十个月研究漏掉了什么：它"没有分析使用 CCA 的算力成本，也没有分析 CCA 的 PR 消耗的 CI 资源"，并补充说"这些都是实实在在的成本"。AI 评审把一部分工作转移到 token 上，但合并仍要由人批准。本站的人工评审的成本一页解释了为什么生成变便宜后这条线会占大头，瓶颈一章则展示了队伍在哪里排起来。

只有预算、没有结果。按用量计费却不设团队级预算，很快就会出问题。据援引 The Information 的媒体报道，Uber 在大约 4 月就用完了 2026 年全年的 AI 预算，主因是 Claude Code。这些报道称，工程师采用率从 32% 升至 84%；关于人均花费，各篇报道的数字不一，且都无法追溯到 Uber 自己的来源，因此本书不予转述。据报道，随后还设了按工程师计的 token 上限。其 COO 表示，很难把更多 token 与更多有用的功能联系起来（Quartz，2026）。

DX 的汇总数据在 500 多家组织中呈现出同样的形状。AI 季度支出中位数在一年内从约 1,500 美元涨到 44,000 美元（科技行业"接近 28 倍"；未说明统计单位），而 DX 的"创新比率"维持"在约 57–58%"（DX，2026 年 7 月，T3）。取方向，不取量级：支出涨了一个数量级以上，DX 跟踪的结果指标却纹丝不动。

算例：每次合并变更的成本。没有任何组织公布过包含人工评审时间的"每次合并的智能体变更成本"。.NET 团队明确没算算力；唯一一项公开的合并成本实验——Insight 的那项——没算人工评审。所以你只能自己算。公式很简单：

cost per merged change =
    ( agent tokens
    + CI minutes x CI rate
    + AI review
    + reviewer minutes x loaded rate
    + rework )
  / merged changes

公开的输入能给你一个起始区间。在 Insight 的实验中，一个真实功能（RFC 8628 设备授权流程）用 23 种模型与运行框架的组合构建了 29 次，以一个 AI 评审器和一个包含 38 个测试的判据作为门禁。达到可合并状态的成本从 2.59 美元到 33.38 美元不等，耗时从 26 分钟到约 3 小时。同一个模型下，仅更换运行框架就让成本变动约 2.5 倍。成本按 token 乘以公开费率计算，评审者是一个模型，所以这个数字里没有任何人工评审时间（Insight，2026 年 7 月，T3，单一功能）。至于分母，合并率远低于 100%：在 dotnet/runtime 中开出的 878 个智能体拉取请求里，已合并或已关闭的那些有 67.9% 被合并，而 Microsoft 自家工程师是 87.1%。

下面把公式填上数。这是示意性算术，不是任何组织的数据：token 成本和 AI 评审取自公开区间之内，CI 成本、评审时长、全成本费率和返工都是假设，你应当换成自己的数字。

Per 100 agent PRs attempted                    USD
  agent tokens    100 x $20                  2,000
  CI              100 x $3                     300
  AI review       100 x $20                  2,000
  human review    100 x 30 min at $100/h     5,000
  rework          10 follow-ups x $93          930
                                            ------
  total                                     10,230
  merged (67.9% of 100)                         68
  cost per merged change                      $150

Same, token cost halved (better harness):     $134
Same, human review minutes halved:            $110

在这些假设下，人工评审约占总成本的一半，把评审时间减半省下的钱，是把 token 支出减半的两倍多。你的数字会不一样——这正是要点所在。在弄清自己流水线里哪条线占大头之前，你不知道该投在更便宜的模型、更好的运行框架上，还是投在更少、更小的拉取请求上。第 14 章《90 天试点》以这个模型作为成本基线。

它带来什么风险

成本会出现在账单上，风险不会，所以风险很少进入商业论证。眼下有三类风险值得定价。第 12 章《安全、权限与爆炸半径》会深入展开，包括记录在案的每一起破坏性智能体事故背后的权限风险。

代码本身。智能体时代最有力的数字来自独立研究。在开源仓库的 186 个真实功能需求上，一个基于 SWE-Agent 和 Claude 4 Sonnet 的智能体配置，产出的代码 57% 能正常工作，但只有 11.8% 是安全的（SusVibes，ICML 2026，T1）。厂商数据在方向上一致。Veracode 2026 年的排行榜称，安全通过率"停滞在 56%"，而语法几乎总能通过。推理模型得分 56%，其他模型 51%；大、中、小模型分别为 53%、51% 和 51%；专为编码调优的模型并不比通用模型好（Veracode，2026 年 7 月，T3）。换句话说，约 44% 涉及安全的输出仍然不合格，而更大的模型、专门调优编码的模型都解决不了。

评审者本身也是风险的一部分。斯坦福的一项对照研究发现，使用 AI 助手的受试者"写出的代码明显更不安全"，却"更倾向于相信自己写的代码是安全的"（Perry 等，T1，47 名受试者，使用 codex-davinci-002）。因此，作者的信心不是安全的证据。这正是安全扫描应作为流水线里的门禁、而不是靠评审者在脑子里把关的原因。

供应链。模型会编造包名。在 16 个模型的 576,000 个样本中，幻觉包名的比例"商业模型至少 5.2%，开源模型 21.7%"（Spracklen 等，USENIX Security 2025，T1）。更危险的发现是这些编造会重复出现："43% 的幻觉包名在全部 10 次查询中都重复出现"。攻击者可以预测并抢注它们。2026 年一项单作者的复现研究在五个较新模型上测得的比例更低，为 4.62% 到 6.10%，但仍有 127 个名字被五个模型一模一样地编造出来（Churilov，未经同行评审）。一份依赖允许清单的成本，比一次事故低得多。

法律状况（截至 2026 年 10 月；详见附录 B《监管与许可现状》）：

• 2026 年 9 月 16 日，在 Doe v. GitHub 案中，第九巡回上诉法院驳回了基于 DMCA §1202(b) 的"输出"理论。Copilot 和 Codex 并没有"移除或篡改"版权管理信息；它们"而是创造了从未包含这些信息的新作品"。两项违约请求"仍在审理中"（判决书）。
• 美国版权局 2025 年 1 月的报告认为，仅凭提示词，用户对 AI 输出的控制不足以使其成为作者（copyright.gov；措辞来自二手摘要）。对于一个大部分由智能体编写的代码库，所有权是一个需要交给法律顾问的开放问题。
• 欧盟《人工智能法》附件三第 4(b) 点，把在工作关系中用于"监测和评估人员的表现与行为"的系统列为高风险（附件三），适用日期已推迟到 2027 年 12 月 2 日。一个给单个开发者打分的 AI 仪表盘可能落入其中。这是本书的推断，有待法律审查，并非定论。

本站的智能体产出的知识产权与版权一页跟踪细节。

把这些风险作为成本项来定价，而不是脚注：对每个智能体变更做静态分析、密钥扫描、依赖允许清单，以及它们带来的评审工时。本站的智能体错误的成本一页讲了如何估算。

一套解读厂商数字的规则

你拿到的大多数数字，在某个狭窄的意义上为真，在你需要的意义上却没用。解决办法是一套解读规则，每次都以同样的方式执行，对你喜欢的厂商也不例外。

1. 给每个数字定级。一个来源的等级，取"谁测的"与"怎么测的"中较低的那一项。T1 是有明确方法的独立测量；T2 是组织测量自己的系统，并给出分母；T3 是方法单薄的遥测或报告；T4 是说法。名气大不能把一个数字从 T4 里捞出来。
2. 厂商谈自家产品的数字，一律装框。可以从中学习，但绝不让它承担论证，无论厂商是谁。
3. 对汇总遥测，只取方向，不取量级。Faros、LinearB 和 Jellyfish 一致认为 AI 带来了更多、更大的拉取请求。它们对评审时间是升是降意见不一，可能是因为等待时间和实际评审时间朝相反方向变化（瓶颈一章对此做了调和）。它们一致的地方，相信符号；不要按百分比做计划。
4. 一份报告只用一种表述，也不要拼接。Faros 2026 年的报告在一处说评审时间中位数 +441.5%，在另一处说"5 倍"（Faros，2026 年 4 月，T3）。挑一个。它的下一份报告说每个拉取请求对应的事故"只上升了 14.5%"，而上一份报告是 +242.7%（Faros，2026 年 9 月，T3）。这是两份时间窗不同、基线未说明的报告，不是趋势。永远不要把不同厂商、不同时间窗或不同定义的数字合成一个数。
5. 找到分母和定义。"接受"、"有用"、"已处理"和"已解决"是不同的指标，而且常常由模型计算。第 7 章《代码评审》给出了一套术语。如果你找不到一个百分比是"谁的百分比"，就丢掉它。
6. 优先采信公布自己坏数字的来源。.NET 团队披露其智能体的拉取请求合并率为 67.9%，而 Microsoft 自家工程师为 87.1%——这是你可以拿来校准的数字，恰恰因为一家厂商本有理由不公布它。

本站的如何读基准测试一页把同样的纪律用在模型评测上。智能体回撤是一次度量失败一文认为，令人失望的部署往往从一开始就缺了这套规则。第 17 章《衡量成功与何时回退》会把这套规则变成一组指标：每个阶段一个流动指标配一个稳定性指标，并在试点开始前写好回退触发条件。