Linux Foundation：把节省的时间与转移的成本一起算

核心判断：AI 可以让一个贡献者更快交出代码，也可能让接收代码的人承担更多检查工作。判断是否真正提效，应该把提交、审核、返工、上线后的维护放在同一张账上。

这份调查具体说明了什么

原稿已提到两组并存的结果：不同任务的自报时间节省为 19%—52%；维护者估计收到的 PR 中约 25% 是低质量 AI 生成贡献，大项目约为 31%。官方新闻稿还指出，高复杂度任务中有 21% 的受访者报告使用 AI 反而耗时更多。这些数据描述的是不同任务、角色和受访者的经验，不能相减成一个“AI 净生产率”。官方调查摘要

2026-10-26 补核报告第 29 页：调查于 2026 年 4—6 月进行，经 Linux Foundation 及合作伙伴渠道发放，合格样本为 234 人。第 10 页 Figure 2 的 PR 质量估计实际有 111 名答题者。“25%”是这组受访者对其接收 PR 的比例估计的平均值，不能写成“抽查全部开源 PR 后确认四分之一不合格”。报告 PDF，Figure 2 与 Methodology

为什么写得更快，项目却未必交得更快

以下是编辑解释。假设一条流程原来是“写作或开发 → 同行检查 → 交付”。AI 压缩了第一段，提交量可能随之增加；如果检查能力没有增加，队列会堆积。检查者还要辨认似是而非的解释、补齐缺失测试、追问作者是否理解改动。瓶颈因此会转到审核端。调查支持关注这种风险，但没有计算整个开源生态的净损益。

用一个纯演示例子理解：过去写一份分析花 100 分钟、核对花 20 分钟；现在生成花 30 分钟，核对与返工却花 70 分钟。第一步快了 70%，完整交付只从 120 分钟降到 100 分钟。如果一次生成了十份，接收者的工作量还可能增加。这不是调查实测值，而是说明为什么要把流程总耗时与单步耗时分开。

放到你的 Agent 与报告工作里

可以为一次交付记录四个数：生成耗时、人工核验耗时、返工次数、最终可用成果数。比如报告 Agent 生成了 50 条洞察，要检查的不是“50 条是否写完”，而是每条能否追溯到数据、统计分母是否一致、是否重复、是否真的支撑业务决策。

一个实用验收方式是：提交时随附来源、测试或计算过程，并说明哪些结论仍待判断；审核者用同一套口径检查。这样才有机会让生成者节省的时间，变成整个团队获得的时间。

哪些结论仍不能下

这是问卷，不是随机对照实验。自报耗时容易受记忆、工具熟练度和任务选择影响；主动参加调查的人也未必代表所有开发者。更不能用开源项目的比例直接推算公司团队、营销分析或你的个人效率。对你最有价值的做法，是把这份研究作为提出测量问题的起点，再用自己两三周的真实交付记录验证。

十二分钟顺序：4 分钟看执行摘要，记下“个人提速与审核负担并存”；4 分钟看 Figure 2 与第 29 页样本说明；最后 4 分钟选一个现有工作流，补上生成、核验、返工三栏。读完应能回答：节省发生在哪一段，新增负担由谁承担？