2026 年 11 月 · 8 分钟阅读
体感快了两成、实测慢了一成九：差在口径，不在工具
关键定义
任务类（task class） 按“结果能不能被机器判定对错”划分的一组任务。可判定类有测试、schema、字数这类确定性闸门，对错不靠人讨论；不可判定类的验收依赖人的判断，同一个人两次看可能给出不同结论。两类任务的提效幅度不在一个量级。
体感提速与实测提速 体感提速来自对生成那一段的观察：想法到代码的时间确实变短了。实测提速来自整张工单的时钟：等待、阅读、复核、返工都算在内。两者之差不是情绪误差，是采样区间不同。
返工率 一张工单合入之后两周内被回滚、被同一处再改、或被后续修复引用的比例。它是唯一能把“变快了”和“变糙了”区分开的数，也是提速报告里最常被省掉的那一栏。
深夜的实验报告里有一行不起眼的说明。一位参与测试的工程师承认，有几个任务他没有提交。理由是那些任务 AI 两小时能做完，他自己手工要做二十小时，他不想在“不许用 AI”的那一半里碰上它们，所以干脆不报。这句话写在方法学部分，占不到两行，却是整份文件里最值得抄进会议纪要的一句。
报告出自 METR，一家专门用随机对照实验测量 AI 对开发者影响的机构。2025 年 7 月他们做了这样一件事：找 16 位长期维护开源项目的开发者，在自己熟悉的仓库里处理 246 个真实 issue，随机分两半，一半允许用 AI，一半不许。开工之前这些人预测 AI 能把效率提高 24%，收工之后他们相信自己提高了 20%。秒表记下来的数字是慢了 19%。
三组数字要放在一起才看得懂。24 和 20 说的是同一件事：人对自己速度的判断有稳定的偏差，而且这个偏差在干完活之后依然存在，没有被经历纠正。20 和负 19 说的是另一件事，它不是偏差的方向错了，是两边量的根本不是同一段东西。
人评估快慢时，注意力落在敲键盘之前那一段：想清楚要写什么，把代码敲出来。AI 确实把这一段压短了，压得明显，手感也真实。账本记的是另一段更长的时间：读懂现有约束、等工具返回、逐行读生成的东西、发现它在某个边界上错了、改回去、再找人复核。前一段变短，后一段变长，体感抓住的是变化，账本记的是总和。
2026 年 2 月 METR 放出后续实验，这次用的是 Claude Code 和 Codex 这类智能体工具，57 位开发者、143 个仓库、800 多个任务。回归的老参与者点估计是负 18%，置信区间从负 38% 到正 9%；新招的 47 人是负 4%，区间负 15% 到正 9%。两个区间都跨过零。METR 自己的措辞是，这份数据只能算很弱的信号。这里的记号容易读反：在 METR 的写法里负数表示减速，很多二手报道把负 18% 当成了 18% 的提速。
信号为什么弱，原因也写在同一份文件里。30% 到 50% 的开发者在实验中拒绝提交某些任务，因为他们不想在没有 AI 的条件下做。报酬从每小时 150 美元降到 50 美元，愿意留下来的人因此又换了一批。再加上同时开几个智能体让“一个任务花了多少墙钟时间”本身失去意义，对照组已经不成立了。
一个实验做不下去，通常被记在研究方法的失败栏里。这一次它更像一份部署报告。三成到五成的拒绝率说明，在真实的 backlog 里，人们已经在脑子里给任务分过类，而且分得比任何一份公开评测集都细：哪些任务交给 AI 是净赚，哪些是净赔，哪些交出去之后自己还得重做一遍。分类做完了，只是没有落在纸上。
这份清单的价值在于它是免费的、按你们自己的代码库校准过的、带着真实边界的任务分级。拿一个季度的工单，问每个经手人同一句话：这里哪些活你现在不愿意再手工做。答案会把任务分成两堆，而不是排成一张从很有效到没效果的连续谱。两堆就够了，预算和人员安排都只需要两堆。
别处的数字为什么方向相反
这个分野在别的数据里也对得上。DORA 的观察性研究给出过一个方向相反的关联：AI 采用率每提高 25%，交付吞吐下降 1.5%，稳定性下降 7.2%。这是相关不是因果，采用 AI 的团队往往同时在改别的流程，但方向本身值得记一笔。另一份 2026 年的证据综述整理了一个企业纵向案例，802 位开发者、196,212 个合入请求、跨度两年多，人均吞吐达到推行前的 2.09 倍，与此同时每位复核者承担的负载按比例上升。还有一组来自更干净的实验：微软研究院与 GitHub 在 2022 年做的随机对照实验里，一项边界清楚的 JavaScript 任务，允许用 Copilot 的一组快 55.8%。
三组数字不矛盾，它们的分歧是结构化的。同一个工具，在边界清楚、对错能自动判定的任务上给出两位数的提速；在边界模糊、要靠人判断的任务上给出零，甚至是负数。所以“AI 到底提效多少”这个问题本身缺一个前提。缺了“哪一类任务”这个前提，任何平均数测的都是任务配比，不是工具。
这也解释了同一份报告为什么会被两边引用。卖方拿 55.8% 说工具有效，买方拿负 19% 说工具没用，两边引的都是真数，只是各自的任务配比不同。要判断哪一个更接近你自己的情况，得先看你的工单里，可自动判定对错的那一类占多少。这个比例不写在任何报告里，只写在你自己的系统里。
这里还有一层偏置值得说，它决定了所有公开数字的形状：能被做成基准的任务，天生属于可判定类。一个任务要进入自动评分，先得有一个确定的答案，或者一个能跑起来的验证脚本。这个条件把边界模糊的任务挡在门外，于是基准里的任务分布，系统性地偏向 AI 最擅长的那些。厂商报告里那些漂亮数字不是造假，它们是在一个被筛过的任务分布上算出来的。你车间里的任务分布，没经过这道筛。
换的不是指标，是计量对象
多数公司的看板已经有很多数：构建次数、部署频率、平均合入时长。这些数在 AI 进来之后依然好看，因为它们记的是系统事件，不是工单。一张工单在等人复核的两天里，构建和部署都可能很健康。于是扩容的决定经常是在一堆绿色的图里做出的，而那些图从来没被设计来回答这次该不该扩大这个问题。
这个数在立项环节还会被用歪一次。立项书里写提效三成，预算按这个数批，第二年验收时发现兑现不了，项目被叫停，而不是被重新划定范围。被叫停的不是 AI，是一个用错单位写出来的承诺。同样的活换一个写法就成立：承诺覆盖哪一类任务、覆盖多少张工单、返工率不高于多少。这三个数可以被检验，也可以被推翻，而提效三成既不能被检验，也不能被推翻。
我们的判断是，度量单位要换。现在多数企业的口径是“每个开发者的产出”，这个口径把任务配比藏在了分母里，于是两个季度之间配比一变，数字就跟着变，谁也说不清是工具变好了还是活变简单了。换成“每张被接受的工单”，三个字段就够用：从开工到合入的周期，其中复核占用的时间，两周内出现返工的比率。前两个说明快慢，第三个说明这个快是不是真的。
返工率是唯一能证伪“我们变快了”的数，也是月会上最不好糊弄的那一个。周期可以靠压缩范围变短，复核时长可以靠减少深度变短，只有返工率会把这两笔账还回来：改回去的代码、同一处的第二次修改、上线后补的修复。一份提速报告如果没有返工率，它描述的是一次流量,不是一次改善。
还有一个顺序问题容易被跳过。当人均吞吐翻倍而复核容量不变时，多出来的产出不会消失，它会堆在复核队列里，让周期在中间某一段变长，同时让复核变成走过场。所以扩容的顺序是先量复核容量，再决定放开多少。这一点我们的判断很明确：没有复核余量的提速，只是把风险从生产端挪到了审查端。
复核容量可以算，不用靠感觉。设一个团队每周能认真读完一百个改动，人均吞吐翻倍意味着改动变成两百个，人不变，每个改动分到的时间就减半。数学上这叫服务能力不足，工程上它同时表现为两件事：队列变长，通过率上升。读得越快，越容易放过。两个指标一起看，才能分清是能力不够，还是标准在往下走。
我们自己的账怎么记
我们自己的内容流水线按这个口径分开记。每篇文章上线前要过一组确定性闸门：正文字数、标题与摘要的长度、SQLite 与静态 JSON 的字段一致性、文风 lint。这些能被机器判定，所以它们可测、可加速、可以放心交给无人值守的流程。判断力那一半没有闸门，我们不报它的速度，只报返工：哪篇重写了，哪篇撤了，哪篇上线三天后改了口径。两笔账分开记，才不会拿可测的那一半去证明不可测的那一半也快了。
分开记还有一个副作用值得说：它让“哪个环节该交给机器”变成一个可以讨论的问题，而不是立场问题。字数、长度、字段一致性交给脚本，判断哪篇值得写、结论站不站得住留给人。这条线一旦画出来，加机器的地方和加人的地方就都清楚了。
这条推论的边界
有个边界要说清楚，否则它容易被拿去当口号。实验里的负面结果绑定三个条件：开发者熟悉的大仓库、团队里没写下来的标准、2025 年初的工具。三个条件换掉任何一个，符号都可能翻过来，2026 年的智能体工具在这三个条件下的表现也确实比 2025 年好。所以真正稳的不是符号，是机制：提效的大小由任务的边界清晰度和可判定性决定。机制能预测新现象，符号不能。
实验里还有一个方向容易漏掉。同样的工具，对刚入行的人和对维护了十年仓库的人，效果不一样。前者缺的是把想法变成代码的速度，AI 正好补这一段；后者缺的是对既有约束的把握，AI 补不了，还会增加他要读的东西。所以“我们团队提效多少”这个问题，得先问人员结构，再问任务结构。两个结构都变了，任何跨公司的平均数都没有参照意义。
由此可以给出一个能被推翻的预测。如果提效由任务类决定，那么同一个团队在两个季度里，可自动判定对错的那一类任务周期会稳定下降，模糊的那一类会回到零附近，而混合口径的平均数字会随任务配比漂移，不随时间改善。检验方法不复杂：把上个季度的工单按“对错能不能自动判定”分成两栏，各抽二十个，比周期和返工。如果混合口径的数字确实随配比漂移，这套解释成立；如果两类任务同向改善，那就得去找别的机制。
本周能做完的三件事
第一，抽二十个已经结束的工单，逐个补三个数：周期、复核时长、两周内返工。没有这三个数，后面所有关于扩不扩容的讨论都只能靠感觉，而感觉在这场实验里已经被证明会偏三十九个百分点。
第二，把“没人愿意再手工做”的清单写下来，按人分开写，不要合并成一份。合并会把分歧抹掉，而分歧恰好是最贵的信号：两个人对同一个任务的判断不一样，说明这个任务的边界本身没写清楚，而边界没写清楚的任务，恰恰是 AI 最容易出错的那些。
第三，把下个季度的目标从“提速百分之多少”改成“某一类任务的返工率降到多少”。前者是结果，只能等；后者是约束，可以设计。
留给买家的一个问题是：你的提效数字，是按任务类分开算的，还是把可判定的和不可判定的混在一起算的？如果是后者，那么这个数字基本上在描述你的任务配比。而且它会在你真正扩大使用范围的那一天开始变差，因为新增的任务，往往是边界更模糊的那些。
参考来源
DORA, State of DevOps（AI 采用率提高 25% 对应吞吐下降 1.5%、稳定性下降 7.2%，观察性关联）
He et al. 企业纵向案例综述（802 位开发者、196,212 个合入请求，人均吞吐 2.09 倍，复核负载同比上升；综述按研究设计分层，第二手整理）
常见问题
为什么开发者的自评和实测差这么多+
因为两边采样的时间段不同。自评看的是从想法到代码这一段，AI 确实压短了；实测看的是整张工单，多出来的阅读、复核和返工都在这一段里，被自评忽略了。
METR 的实验到底有没有被推翻+
没有。2026 年 2 月的更新点估计是负 18%，置信区间从负 38% 到正 9%，方向没变，只是研究机构对数字的信任度下降了。很多报道把负 18% 读成了 18% 的提速，那是对记号读反了。
实验数据为什么变得不可靠+
因为三成到五成的参与者在拒绝提交某些任务，他们不愿意在没有 AI 的条件下做。愿意留在对照组的人因此不是随机样本，实验的比较基础被破坏了。
拒绝提交任务这件事为什么重要+
它说明工程师已经在脑子里完成了任务分级，而且分级依据是真实代码库和真实工单。这份分级没有被写下来，所以管理层看不到，但它比任何公开评测集都更贴近这家公司的情况。
企业该用哪个数字判断要不要扩大推广+
用每个任务类的每张被接受工单的周期、复核时长和两周返工率。三个数按任务类分开记，不要合并成一个平均提效百分比，合并会把任务配比的变化算成工具的变化。
返工率为什么要看两周+
太短会把正常的后续修改算成返工，太长会把问题混进别的迭代里。两周是一个能覆盖绝大多数回滚和补丁、又不至于把新需求算进来的窗口。
拿你自己的执行日志跑一遍
交一份脱敏的近 30 天 agent 执行日志，48 小时内拿到八行表：八项技术项每项一行，每格带分子、分母和判据，缺口按是否要改 schema 排序。前三单 ¥8,000。