8.0
热点
AI SCORE
编程提效2026-10-14 02:36
AI 写码的回报取决于审查与反馈
dev.to · AI#代码审查#研发效能#AI 编程
Editor brief · 编辑速览
文章引用 Faros AI 的遥测研究：高 AI 采用团队合并的 PR 增加 98%，审查时间也增加 91%。作者结合多类研究讨论工具账单之外的成本，强调测试与快速反馈决定代码增产能否转化为收益。
你的 AI 编程成本不断上涨，而围绕按用量计费的讨论，又让明年的开支更难预估。工程负责人反复在问两个问题：这笔钱最终会不会和雇一名工程师一样多？我们到底从中得到了什么？
Faros AI 在 2025 年的一项遥测研究中发现，AI 采用程度高的团队合并的 pull request（PR）多了 98%，但 PR review 时间也增加了 91% [1]。
AI 编程账单只占工程师薪酬的一小部分；真正决定回报的是 review。如果没有扎实的测试和快速反馈，更多代码就会变成更不稳定的系统。为了看清钱花在了哪里，我们跟踪 Acme Inc 的一次变更：一个 Agent 用一下午写出了“从队列中重试失败的银行卡付款”功能。
我们查阅了供应商的遥测研究、DORA 的调查、三项实地实验和从业者调查，只保留能够从来源中逐字引用的数据，并明确指出哪些供应商在销售度量或 review 工具。
按每名工程师计算，AI 编程账单并不大，尽管大部分担忧都集中在这张账单上。Anthropic 公布的企业使用其编程 Agent 的数据 [2]，以及 DX 对席位费加 token 支出的总成本估算 [3]，都表明每名工程师每月的开支不算高。
Levels.fyi 的 2025 年报告显示，美国软件工程师的年度总薪酬约为 22.6 万美元 [4]。以此为参照，按供应商平均费用区间的上限计算，一年的费用只略高于薪酬的 1%；按 DX 区间的上限计算，一年的费用约占 3%。
美国工程师每获得 1 美元薪酬，其中对应的每名工程师年度 AI 编程支出 [4]：
这是我们基于总薪酬做的计算，而非包含所有附加支出的雇佣总成本，因此实际占比还会更低。供应商给出的是汇总数据，没有披露样本量，所以这两个占比都只能视为粗略估算；即便如此，这张账单也远未接近雇用一个人的成本。
目前我们还没有太纠结成本，因为我们正在摸索这些工具的最佳实践。但这也导致一些开发者大幅超出预算，所以我们可能会开始设置支出上限。
匿名受访者，CTO，美国小型公司 [5]
支出上限可能会到来，少数重度用户也可能让你吃一惊。不过，在 Acme，付款重试这次变更消耗的 token，在月度账单上几乎可以忽略不计。按照我们以完整工作年为基础的计算，以供应商公布的平均费用 [2] 使用 Agent 一整天，花费还不到按 Levels.fyi 数据 [4] 计算的工程师一小时薪酬。
这笔开支买来了更多代码，但它能推动公司交付的证据，远没有仪表盘呈现得那么充分。在一项覆盖一万多名开发者的遥测研究中，Faros AI 发现，团队行为上的改善汇总到公司层面后，并没有按比例扩大 [1]。DX 在 400 多家组织中发现，PR 吞吐量增幅的中位数为 7.76% [3]：提升确实存在，但幅度有限。
LinearB 的 2026 年基准数据指出了无效产出的问题：AI 生成的 pull request 被接受的比例远低于人工编写的 pull request [6]。始终没有合并的代码消耗了 review 时间，却没有交付任何东西。
AI 生成的 pull request 有 32.7% 被接受，人工编写的 pull request 则有 84.4% 被接受。
LinearB 基准数据 [6]
很难让我们的 CFO 持续支持对这些工具的投入，因为生产力收益一直难以得到确凿证明。
匿名受访者，CTO，体育科技公司 [5]
并非所有研究都得出了相同结论。DORA 的 2025 年调查发现，AI 采用程度与交付吞吐量呈正相关 [7]；下文关于测试的部分会介绍，DORA 认为回报取决于什么。
回到 Acme，Agent 在当天下午就提交了付款重试 PR，仪表盘上因此多了一个 pull request，尽管此时还没有交付任何东西。
额外产出卡在了 review 环节。Faros AI 的数据显示，PR 的平均规模增大了 154% [1]，review 时间也随之增加。
Faros AI 中 AI 采用程度高的团队与采用程度低的团队对比 [1]：
在 LinearB 的另一组数据中，AI pull request 在有人开始处理之前，要多等到原来的 4.6 倍时间；不过，一旦有人接手，review 速度会快到原来的 2 倍 [6]。Addy Osmani 曾在 Google 领导开发者体验工作超过 14 年，后来成为 Google Cloud AI 的总监 [8]。他在 2026 年 1 月的一篇文章中指出了这个瓶颈。
当产出增长的速度超过验证能力的增长速度时，review 就会成为限制吞吐量的环节。
Addy Osmani，Google Cloud AI 前总监 [9]
与你的公司规模相近的企业，也出现了 PR 数量增长：Synthesia 的 118 名工程师在 2025 年 11 月全面采用 AI 编程工具 [10]。其 CTO Peter Hill 告诉 IEEE Spectrum，pull request 数量同比增长了 120% [10]。他给出了进入 review 的数量，却没有给出处理这些 PR 所花的工时。
Faros AI 产品营销负责人 Naomi Lurie 认为，资深工程师承担了 review 负担，因为他们能够发现 AI 犯下的那些隐蔽错误 [11]。Cui 及其同事在 Microsoft 的实验中记录了开发者的资历。他们发现，AI 助手显著提高了新入职员工和初级开发者的任务完成量，但对资深、任职时间较长的开发者没有显著作用 [12]。如果这些 PR 交给资深工程师 review，初级工程师增加的产出就会变成资深工程师增加的 review 工作；这是我们的解读，并非这两项研究实际测量过的结果。
这些成本都不会出现在账单上，我们找到的研究也没有为它们定价。你可以自己算：拿一小时 Staff Engineer 的成本，与 Agent 的整项 token 支出对比。在 Acme，付款重试 PR 的规模远大于这次变更实际所需。它等了好几天，才落到唯一熟悉付款流程的那位 Staff Engineer 手上，而她带的初级工程师也在不断往她的待处理队列里塞 PR。
在 AI 采用程度高的情况下，更多 pull request 无人查看就被合并，而 DORA 发现，AI 采用程度与更不稳定的交付相关。Faros AI 的 2026 年报告发现，在 AI 采用程度高的情况下，完全未经 review 就合并的 PR 多了 31% [11]。Faros 没有说明，这指的是合并数量还是合并占比。按照我们的理解，每次未经 review 的合并，都可能把成本从今天的 reviewer 转移给处理下一次事故的人。
完全未经 review 就被合并的 pull request 多了 31%。
Faros AI 遥测数据，AI 采用程度高与低的对比 [11]
DORA 的 2025 年调查发现，AI 采用程度与交付稳定性仍然呈负相关 [7]。DORA 报告了这种关联，但没有说明其成因。
GitClear 对变更代码行的分析显示了一个更长期的趋势：在 AI 工具普及的这些年里，重构所占的比例下降了 [13]。时间上与 AI 采用相吻合，但 GitClear 并未证明是 AI 导致了这一变化。
2021 年，变更代码行中有 25% 属于重构；到 2024 年，这一比例已低于 10%。
GitClear，多个 repo 的变更代码行数据 [13]
证据并不一致。Jellyfish 考察了 bug 工单和回退操作，没有发现它们与 AI 采用程度之间存在显著关联 [14]。这些研究以不同方式衡量不同的事情，我们还不知道为什么结果会有差异。
在 Acme，迫于截止期限，付款重试 PR 的第二轮 review 被草草放行。一个重试循环在周五向少数客户重复扣了款。返工和事故处理，也都是这次变更成本的一部分。
DORA 的 2025 年报告指出，如果没有扎实的自动化测试、成熟的版本控制和快速反馈循环，更多变更就会导致不稳定 [7]。DORA 的这一结论来自调查，而非受控试验。
DORA 还指出，最大的回报来自内部平台、清晰的工作流程和目标一致的团队，而非工具本身 [7]。
Jellyfish 的 Nicholas Arcolano 负责这家销售工程度量工具的供应商的研究工作。在一场介绍公司数据的演讲中，他根据团队代码分散在各个 repo 中的情况，对团队进行了比较。
真正有意思的是这种高度分散的情况。在这里，AI 采用程度与 PR 吞吐量基本没有相关性。实际上，确实存在的那一点微弱趋势，还是略微负向的。
Nicholas Arcolano，Jellyfish 研究负责人 [14]
看待收益幅度时要谨慎。三家公司的实地实验汇总后发现，完成的任务量增加了 26.08%，标准误为 10.3%，因此真实收益可能很小 [12]。
因此，要在真正决定回报的环节衡量回报。一家供应商把这个单位指标定义为：某一时期内包含所有相关支出的 AI 总成本，除以已经合并且保留下来的 PR 数量。所谓保留下来，是指在一个代码变动观察窗口内，没有被回退或大幅重写 [15]。把 review 工时也计入这项成本；我们的下一篇文章会详细拆解这个指标。
Acme 在 review 之前设置了变更规模限制和测试关卡，并为 Agent PR 规定了接手时限。它开始用包含 review 工时在内的全部 AI 成本，除以合并后持续保留的变更数量。现在，付款重试变更到达那位 Staff Engineer 手上时，规模小、经过测试，而且没有延误。
在一个拥有 20 到 150 名工程师的团队里，稀缺的是少数能够判断一次变更是否安全的人的判断力。根据我们对证据的解读，代码变便宜带来的所有收益，都受限于这种判断能够多快地应用到变更上。在 Acme，熟悉付款流程的那位 Staff Engineer，在任何 Agent 出现之前就是瓶颈；Agent 只是让她面前的队列更长了。
AI 让编写代码变得便宜，但验证仍然迟迟跟不上，于是成本转移到了那个没人单独开账单的环节。DORA 用的词是“放大器”：AI 会放大高绩效团队的优势，也会放大表现不佳团队的运转问题 [16]。证据表明，一个缺少良好测试、又不把变更控制在小规模的团队，会变得更忙、更不稳定，却不会更快。
因此，预算问题更多取决于你如何设计 review 和测试，而不是席位费和 token 费用。账单是最容易看懂的部分，也是最不值得投入管理精力的部分。
算上 review，你上一次合并的变更花了多少钱？
最初发表于 kaas.team。
如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。