用AI后，维护任务为什么不一定更省时？

先看完整交付，而不是一段代码

生成候选代码只是工作中的一步。熟悉项目的维护还包括理解隐含约定、保持原行为、审查错误路径、处理回归。决定是否接收补丁和记录完整人时，是本案例的方法建议，不是论文给你的团队做出的收益承诺。

公开研究为什么不能取一个平均数

METR早期实验让16名经验开发者处理自己长期维护仓库中的246个真实问题，逐题随机允许或禁止AI；主要工具为Cursor搭配Claude 3.5/3.7。按真实PR质量门槛交付时，允许AI的任务耗时增加19%，95%区间为+2%至+39%。这支持关注理解、审查与返工，不能代表所有开发者。

三项企业开发实验随机提供代码补全工具访问，合计4,867名开发者，合并估计的完成任务数增加26.08%，标准误为10.3%。它衡量产出数量，不能读成省时26.08%；质量、利润和熟悉仓库维护的净收益也不能直接由该摘要推出。

METR后续的两组耗时估计为−18%与−4%，区间都跨零。AI普及后，参与者可能不愿接受无AI任务，报酬变化也改变参与选择；并行代理和等待时处理其他任务，使活动人时与总历时难以统一。研究者因此认为无法可靠估计当前收益，不能把这些点估计连成通用加速曲线。

咨询研究中的范围外任务，AI两组相较控制组的合并正确解概率低约19个百分点。这是任务越界的背景反例，不能当作软件维护成绩。这些研究的人群、任务、工具和指标不同，不能相减或平均成统一效率。案例中的条件比较保留正向、负向和受限结果。

试点怎样改变你的判断

先选一个可回滚的问题，固定工作量与质量门槛，保留人的独立流程作为基线。记录准备、提示、审查、返工、接管人时及全部尝试。

若目标修复与原行为都通过，且完整人时可控，再评估是否扩大范围；若审查返工抵消收益，减少委派也可以是合理结果。小样本不能给出职业自动化率。

读懂比较所需的词

随机实验：研究中随机分配工具访问等处理条件；不代表同一任务在不同年份重测。标准误与来源置信区间是不同表达，未给区间时不自行编造。

完成任务数是产出数量；完成时间是耗时。两者都还需要质量和完整流程条件，才能用于你自己的试点。

公开问题里的接收断点

PR研究§3.2举出Orleans中JsonValue序列化异常：一个修复PR关闭，因为另一个System.Text.Json支持改动已解决问题。这个例子支持开工前查重复与接收状态，不能证明被关闭补丁技术上失败。

对自己的维护工作，先说明问题仍存在，再生成候选、做回归、响应审阅并记录实际接收；这条组织顺序是编辑方法，论文没有逐步验证本仓库。

Pro V2修订是评测版本变化

旧catalog C01/E01已有9月22日Pro V2记录，本轮把它接到维护解释。发布方缩减题集并修订说明与验证环境，因此新旧分数不直接连线当能力增幅。

不要只问测试是否全绿，还要检查空补丁是否会失败、参考补丁能否通过、待测补丁能否在干净环境复验；这些是验收方法参考，不是本案例完成率。

本轮方法补充：证据支持到哪里

Harness²用任务内执行对照选择运行系统改动；对C03只提供相邻方法启示。比较时固定任务、模型和预算，并检查回归与完整人时；本站未复现其效果。

原有案例与场景边界保留；新材料不改变已记录的现场实验结果，也不替代人的最终接收。