生成速度不等于交付速度：AI 编程效能的四层漏损

二

四层漏损：从模型吐字到财务报表，每一层都可能把收益漏掉

把「用 AI 写代码」到「业务因此变好」拆成四个环节，每一层都有自己的度量方式，上一层的收益不会自动传导到下一层。

第一层是生成速度——模型产出代码字符的原始速度。多数编码基准测的是这一层：给模型一个边界清晰的问题、一套可运行测试，看它多快给出通过测试的答案。这一层的进步是真实且可复现的，但它离「团队交付得更快」还有三层距离。

第二层是完成速度——开发者完成一个真实任务的总耗时，包含理解需求、生成、审查、修正、集成。GitHub Copilot 的受控实验测的是这一层：95 名参与者在边界清晰的 HTTP 服务器任务上，工具组比对照组快 55.8%[1]。Management Science 的研究也测这一层：4,867 名开发者的完成任务数平均提升约 26%[2]。而 METR 同样测这一层，得到的却是相反结果——16 名资深开发者在自己维护的、平均超过 100 万行代码的项目上处理 246 个真实任务，平均多花 19% 时间，95% 置信区间为变慢 2% 到 39%[3]。

同一层内部出现相反结果，原因在下一节详细展开。这里先说明第三层——交付速度：代码进入生产环境并保持稳定运行的速度。DORA 2025 年调查显示，AI 采用率提升与交付吞吐量增加、系统稳定性下降同时出现[4]。这不是说 AI 导致了不稳定，而是指出一个结构性事实：个人层面生成更多代码后，评审、测试与发布环节承受的负荷同步增加，若控制机制没有同步扩容，代码到达用户手中的速度不会线性提升。

第四层是业务价值——交付是否带来可归因的经营结果。本文诚实地指出：这一层几乎没有可信的公开证据。任何声称已经量化了「AI 编程提升了多少营收或利润」的说法，在现有公开文献中都缺少支撑。

三

METR 最有价值的发现，不是变慢 19%，而是开发者完成任务后仍然认为自己被加速了

METR 实验设计本身值得说明。研究者从项目真实问题列表中收集 246 个任务，覆盖缺陷修复、功能修改和维护工作，每个任务随机分配到「可以使用 AI」或「暂时不能使用」两种条件。完成标准来自真实项目：代码需要符合风格、测试、文档要求，能够提交给项目评审。两组提交的代码质量相近，研究者也没有发现参与者通过降低质量或挑选简单任务来制造结果[3]。这不是一次简陋的调查，而是一次严谨的随机对照实验。

真正值得记录的是实验前后的三个数字。实验开始前，参与者预计 AI 会让自己提速 24%。完成全部 246 个任务后，他们仍然认为工具带来了提速 20%。而实际计时显示的是变慢 19%[3]。

主观判断与实测结果相差约 43 个百分点，且这个裂口发生在完成任务之后——不是没有反馈的盲猜，而是亲手做完 246 个任务、清楚知道自己花了多久之后，判断依然系统性地偏向乐观。外部专家对实验结果的预测同样偏乐观[3]。

这个裂口的来源不难理解。生成过程会持续制造进展感：开发者输入要求后，屏幕很快出现函数、测试或补丁；手写代码则需要更长的安静思考。开发者容易记住「代码出现得多快」，却难以计入自己花在解释架构、等待响应、阅读补丁、纠正错误假设和补齐测试上的零散时间——这些时间分散、不显眼，却被 METR 的计时器完整记录了下来。

熟悉代码库反而提高了 AI 的相对成本。资深维护者知道哪些接口因历史兼容不能修改，哪些测试隐含着未写进文档的要求，也知道评审者会拒绝怎样的实现。模型缺少这些背景，开发者必须先把知识翻译成提示，再逐行判断输出是否违反仓库惯例——这个过程本身就是一项没有被算作「使用 AI」、却完全由 AI 引发的工作量。

这项发现对企业的含义很直接：任何依赖团队自我报告「感觉更快了」的效果评估，都不可靠。不是因为员工在撒谎，而是因为生成速度带来的进展感，会系统性地掩盖审查与修正阶段消耗的时间——即使在计时数据摆在面前之后，这种偏差依然不会自动修正。

四

个人生成更多代码之后，瓶颈转移到评审、测试与发布

DORA 2025 年调查显示，90% 的技术从业者已在工作中使用 AI，超过 80% 认为生产率提高，但同时有 30% 对生成代码缺乏信任[4]。组织层面的分析进一步发现：AI 采用率提升约 25%，与吞吐量下降约 1.5%、稳定性下降约 7.2% 相关[4]。DORA 对此的解释是，AI 起到「放大器」的作用——高效的团队用它变得更高效，本就存在问题的系统会被放大暴露。

GitClear（一家销售代码质量分析工具的厂商）对 2.11 亿行代码变更的分析，从代码本身的形态变化为第三层提供了独立佐证——它不测「团队交付得快不快」，而是测代码进入代码库之后的形态变化，间接反映交付质量而非交付速度本身。复制粘贴代码占比从 2021 年的 8.3% 升至 2024 年的 12.3%，2024 年首次超过「移动」（即重构）代码的占比；同期重构相关的代码变更占比从约 25% 骤降至不足 10%；短期代码流失率（写完两周内又被修改或删除的代码）从 2020 年的 3.1% 升至 2024 年的 5.7%[5]。这组数据需要谨慎解读——GitClear 的商业模式是向企业销售代码质量分析工具，其研究客观上有动机去强调「代码质量下降」的叙事，这一点在引用时必须披露。但即便打这个折扣，数据本身描述的现象是可信的：生成更多代码与更少重构同时发生，这与 DORA 的组织层观察方向一致。

2026 年出现的另一份数据来自 DevOps 平台厂商 Opsera 对超过 25 万名开发者的分析，同样落在第三层，且呈现出与 GitClear 相似的分裂结构：AI 辅助工作流让「从提交任务到发起合并请求」（Time-to-PR）平均提速 48% 到 58%，但 AI 生成的合并请求，等待人工评审的时间反而是人工编写代码的 4.6 倍；同一份报告还记录到代码重复率从 10.5% 上升到 13.5%，每行代码的安全漏洞数量增加 15% 到 18%[6]。这组数字几乎是本文核心论点的一个缩影：提交端（第二层出口）明显更快，但评审端（进入第三层的入口）反而更慢——效率提升和信任下降，是同一个变化的两面，而不是两件互相矛盾的事。Opsera 自身销售的正是帮助企业管理这类交付流程的平台，这类厂商研究同样存在放大自身产品价值的动机，读者应与前文对 GitClear 的态度一致地保持审慎。

本文在写作时也检索了另一类数据——企业侧公开报告的 PR 周期改善案例，例如 GitHub Copilot 企业客户报告的合并请求周期从 9.6 天降至 2.4 天。这类数字通常来自厂商案例研究或客户证言，缺少对照组和方法论细节，本文认为它们可以作为「第三层收益确实存在」的方向性参考，但不适合作为量化基准引用，因此本文不把具体倍数写入正文比较，只在此处说明检索到了这类材料、以及本文为何选择不采信其精确数值。

把这些证据放在一起，一个结构性的解释浮现：开发者一天生成更多修改，评审者就要阅读更多陌生代码；测试环境和持续集成承受更多构建；发布团队需要处理更多变更组合。团队若缺少快速测试、清晰的代码所有权和小批量发布机制，个人节省的时间不会消失，而是转移给了下游同事，最终表现为评审排队、返工增加或线上故障。

管理者因此需要区分「开发者活动」与「稳定交付」这两件事。提示次数、生成代码行数、工具活跃率，只能说明员工在使用产品，说明不了系统是否变好。需求从提出到稳定上线的完整周期、评审等待时长、变更失败率、发布后缺陷密度，才能回答这个问题。AI 采用率达到很高水平，完全可能没有转化为任何经营收益——这正是第四层（业务价值）证据稀薄的原因之一：多数企业测量的仍然是第一层。

第四层并非完全空白，只是证据的性质和前三层不同。Anthropic 在其 2026 年经济指数报告中披露，公司内部超过 80% 的新增生产代码由 Claude 编写，人均代码产出量提升了约 8 倍；旗下产品 Claude Code 的年化收入到 2026 年 5 月已达到约 80 亿美元，日均提交量在此前八周内增长约 200%[7]。这些数字确实触及了「业务价值」——收入、市场份额、企业客户续约——但它们衡量的是模型厂商自身的商业成功，而不是「使用 AI 编程的企业，其经营指标因此改善了多少」。一家公司卖铲子卖得好，不等于淘金者都挖到了金子。本文认为，这类数据值得记录，但不能替代第四层本应回答的问题：企业自身的收入、成本或客户满意度，是否因为采用 AI 编程而发生了可归因的变化——这个问题在 2026 年的公开材料中，依然缺少具备对照组或严谨归因方法的答案。

五

反对这个框架的理由：四层之间可能不是互相独立的

四层漏损框架的价值在于消解表面矛盾，但它本身也有需要正视的弱点。

第一种反对意见：四层并非严格递进，而是互相影响的。第三层（交付速度）的稳定性下降，本身会反过来拖慢第二层——如果一个团队因为线上故障增多而不得不投入更多时间做事后修复，这些时间在下一轮测量里会被计入「任务完成时间」，从而人为拉低第二层的表观效率。METR 与 GitHub Copilot 实验的时间窗都较短，可能都没有充分捕捉到这种反馈。

第二种反对意见：任务难度和代码库成熟度这两个变量，比框架本身更能解释四项研究的分歧，把它们归入「层级不同」可能掩盖了更根本的原因。GitHub Copilot 与 Management Science 的样本更偏向边界清晰、可独立完成的任务；METR 的样本则是资深开发者在自己维护多年、平均超百万行的成熟代码库上工作。一个值得单独指出的反直觉现象是：METR 实验中越资深的开发者，使用 AI 后反而相对越慢——这与「AI 帮助新手更多、帮助专家较少」的一般预期一致，但也说明「层级」和「开发者资历／代码库成熟度」这两组变量在数据里是纠缠在一起的，本文的框架未能把它们完全分开。

第三种反对意见：模型代际差异被这个框架系统性低估了。METR 的早期实验使用的是 2025 年初的 Cursor Pro 与 Claude 3.5/3.7 Sonnet；同一机构 2025 年下半年用更新工具做的后续研究显示，原参与者子样本约有 18% 提速的迹象，新招募开发者约 4%，但两个估计的置信区间都跨过零，无法排除「没有效果」这一可能[3]。后续研究还遇到新的选择偏差——一些重度用户因为不愿意在部分任务中停用 AI 而拒绝参加，而他们恰好可能是收益最大的群体。这意味着，本文引用的「−19%」这个数字本身也有明确的保质期，不应被当作 AI 编程效率的稳定基准。

第四点值得单独说明，因为它是本文写作时能找到的、对「速度提升是真实的」这一判断支持力度最强的证据。METR 在传统的随机对照实验越来越难做（开发者对 AI 的依赖已经普遍到难以设立真正的对照组）之后，2026 年转而分析了大量 Claude Code 的真实使用记录，估算出的时间节省倍数落在 1.5 倍到 13 倍这个区间。METR 自己特别提醒，这很可能是一个偏高的上限——原因是「任务替代」（AI 让一些原本不会去做的任务变得值得做，这部分新增工作量会拉高表观倍数）和「任务选择」（开发者本来就倾向于把 AI 用在它最擅长的任务上）。同一时期一份自我报告调查也显示，技术岗从业者认为 AI 工具让自己工作的价值提升了 1.4 到 2 倍[8]。McKinsey 的研究则从任务类型给出了一个更细粒度的印证：常规编码任务的时间节省约 46%，复杂任务的节省则不到 10%[8]——这组数字没有推翻本文的框架，反而是本文观点的一个佐证：把「速度提升」按任务类型和证据来源拆开看，本身就比追问一个笼统的百分比更接近真相，这正是四层漏损框架想促成的思维方式。

本文认为，这四种反对与补充意见都成立，但都不足以推翻框架本身的用途——它们说明的是「四层之间的边界比本文描述的更模糊、更动态」，而不是「四层漏损这件事不存在」。对企业而言，实际含义是：不要把任何单一研究的数字当作自己团队的预期基准，任务类型、代码库成熟度、开发者资历和工具版本都会让结果发生实质性偏移。

六

企业应该测量交付与返工，而不是生成量

基于以上分析，企业自建测量体系时，有三件事值得优先做。

第一，从真实任务开始计时，一直计到代码稳定上线，而不是止步于「生成」这一刻。可以从一个团队、两到四周的范围开始：先按缺陷修复、测试补充、常规功能、架构修改划分任务类型，再在同类任务中比较不同工具或使用方式。每个任务记录理解问题、生成、人工编码、审查、流水线、返工这几个阶段各自消耗的时间，而不是只记录「生成用了多久」。

第二，不要相信团队的自我报告，尤其是「感觉更快了」这类判断。 METR 的发现说明，即使在亲手完成任务、有实测数据摆在面前之后，开发者的主观感知依然可能与结果相差四十个百分点以上。可以让员工同时记录感知提速，管理者随后把感受与实际计时对照——但不能仅凭感受下结论。

第三，把测量对象从「开发者活动」转移到「稳定交付」。提示次数、生成代码行数、工具活跃率，说明不了系统是否变好；需求从提出到稳定上线的周期、评审等待时长、变更失败率、发布后缺陷密度，才是真正需要跟踪的指标。分析时还要区分人员与上下文——新人处理陌生代码库时，模型提供的解释和示例，收益可能高于资深维护者在熟悉模块上得到的收益；把两类人混成一个平均数，会同时低估培训价值、高估审查成本。

把以上三件事落成一个团队可以在两周内跑起来的自测流程，大致是这样一个顺序：

1. 选定一类近期高频出现、边界相对清楚的任务（例如某类缺陷修复），拉出最近两到四周内该类任务的清单，作为基线样本；
2. 为每个任务记录五个时间戳：任务提出、开始生成/编码、提交评审、评审通过、稳定上线（无需额外工具，用现有的工单和代码托管系统时间戳即可拼出这五段）；
3. 同时让完成任务的工程师自评一次「感觉比不用 AI 快多少」，与后续算出的实际耗时并排放在同一张表里，不要相互修正；
4. 按新人/资深、任务类型（缺陷修复 vs 新功能 vs 架构改动）分组统计，而不是只看一个团队平均数；
5. 把评审等待时长、变更失败率（上线后需要紧急修复的比例）单独列出来，作为第三层指标，不要和「生成用了多久」混在一张表里；
6. 两到四周后回看这张表，问一个问题：如果只看「提交评审前」的耗时，结论是什么；如果看到「稳定上线」为止，结论有没有变化——这两个答案之间的差距，就是本文说的第二层到第三层的漏损。

METR 实验最值得企业借鉴的，不是任何一个具体数字，而是它的方法本身：把开发者自己的真实任务随机分配到两种工作条件下，并且愿意接受一个与直觉相反的结果。模型和工具会持续迭代，任何单次测量得到的效率数字都有保质期。真正有价值的，是企业建立一套能够持续复测的口径——从需求提出到代码稳定上线的完整链路，而不是任何一层单独的速度。