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

模块 2026-10-19.boundary.1；整理 2026-10-19；证据状态 active
把补全、熟悉仓库维护、审查返工放回各自条件，才能决定本团队试点什么。
现今编辑解释，不是历史快照；实际覆盖比例未知。


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

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


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

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个百分点。这是任务越界的背景反例，不能当作软件维护成绩。这些研究的人群、任务、工具和指标不同，不能相减或平均成统一效率。案例中的条件比较保留正向、负向和受限结果。
来源：[METR早期2025开发效率RCT](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)
来源：[METR后续研究设计修正](https://metr.org/blog/2026-02-24-uplift-update/)
来源：[开发者三项现场实验（正式期刊版本）](https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535)
来源：[咨询工作的锯齿边界（正式期刊版本）](https://pubsonline.informs.org/doi/10.1287/orsc.2025.21838)

## 试点怎样改变你的判断

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

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


## 读懂比较所需的词

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

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


## 公开问题里的接收断点

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

对自己的维护工作，先说明问题仍存在，再生成候选、做回归、响应审阅并记录实际接收；这条组织顺序是编辑方法，论文没有逐步验证本仓库。
来源：[AI参与修复PR的接收与未合并原因（v1）](https://arxiv.org/html/2602.00164v1)

## Pro V2修订是评测版本变化

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

不要只问测试是否全绿，还要检查空补丁是否会失败、参考补丁能否通过、待测补丁能否在干净环境复验；这些是验收方法参考，不是本案例完成率。
来源：[SWE-Bench Pro V2协议修订](https://labs.scale.com/leaderboard/swe_bench_pro_public_v2?tab=full)

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

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

原有案例与场景边界保留；新材料不改变已记录的现场实验结果，也不替代人的最终接收。
来源：[Harness²：用执行对照改进运行方法](https://arxiv.org/html/2610.14224v1)

## 案例中的条件比较
- [C03案例中的条件比较](/changes?task=C03&domain=computing&at=2026-10#phase-conditions)

## 回到具体任务
- [熟悉项目维护：先看完整交付，再看生成速度](/changes?task=C03&domain=computing&at=2026-10)

## 版本、日期与原文定位
- [METR早期2025开发效率RCT](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)；引用版本公开2025-07-10；阅读2026-10-14；页面标示发布日期或固定预印本v1页首日期；Methodology；Core Result；FAQ；16位熟悉所维护仓库的开发者/246任务；不代表所有程序员
- [METR后续研究设计修正](https://metr.org/blog/2026-02-24-uplift-update/)；引用版本公开2026-02-24；阅读2026-10-14；页面标示发布日期或固定预印本v1页首日期；首段及Wider adoption/Details of the productivity study；选择、支付和并行计时问题导致结果仅弱证据；不能据此计算可靠趋势
- [开发者三项现场实验（正式期刊版本）](https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535)；引用版本公开2026-02-27；阅读2026-10-15；本次引用期刊Published Online；机构记录已有2025年6月公开摘要；Abstract；Article Information / Published Online；Microsoft Research对应记录；复用现站FS071同一研究；4,867开发者，完成任务数指标，不是耗时/质量；正式版本日不是首次披露日
- [咨询工作的锯齿边界（正式期刊版本）](https://pubsonline.informs.org/doi/10.1287/orsc.2025.21838)；引用版本公开2026-03-11；阅读2026-10-15；本次引用期刊Published Online；已有较早工作论文，不称2026新能力；Published Online；Abstract；§4.2 Figure 5/Table 7；§6 Discussion（19个百分点）；与旧E18同一研究家族；咨询任务仅作背景，不是软件维护或财报直接证据；正式发表不是首次公开
- [AI参与修复PR的接收与未合并原因（v1）](https://arxiv.org/html/2602.00164v1)；引用版本公开2026-01-29；阅读2026-10-16；固定v1 arXiv摘要页标2026-01-29提交；§2.1–2.3；表1；§3.2 R1/R2例子；样本非随机分配代理；65%分母含开放PR；未合并不全是技术失败
- [SWE-Bench Pro V2协议修订](https://labs.scale.com/leaderboard/swe_bench_pro_public_v2?tab=full)；引用版本公开2026-09-22；阅读2026-10-16；页面明确标修订日期，不视为原始SWE-Bench Pro首次公开日；Update September 22, 2026，任务筛选与隔离重新评分；发布方自述修订，本轮未独立复跑；V1/V2分母与协议不同
- [Harness²：用执行对照改进运行方法](https://arxiv.org/html/2610.14224v1)；引用版本公开2026-10-09；阅读2026-10-19；arXiv固定v1公开日期；§2.1–2.3；§3.1；§4；作者研究，本站未复现；行为对照不能验证正确性，多次运行和编辑器成本需计入。