Appearance
AI 编程到底有没有提效：从研究数字到团队净收益
系列第 14 篇
核心问题：为什么研究结论会相反，团队怎样测出哪些任务真正受益
最后核验：2026-07-20
对应视频：第 11 集《AI 编程到底有没有提效：从研究数字到团队净收益》
关于 AI 编程，可以同时找到“快 55%”“慢 19%”“采用率 84%”“不信任高于信任”等数字。它们并不必然互相否定：有的测一小时固定任务，有的测资深开发者在熟悉仓库中的真实 Issue，有的调查主观使用和信任，有的观察组织交付系统。人、任务、工具、时间、成功标准不同，结果当然不同。
团队真正需要回答的也不是“AI 平均有没有用”，而是：在我们的仓库、任务类别、工程基础和治理成本下，哪种工作方式提高净交付价值？实现时间减少，如果换来更多等待、Review 和返工，未必提效；同样，单个任务没有更快，如果 Agent 并行完成原本不会做的测试和文档，也可能创造价值。
阅读路线：先看全局，再进入机制
视频版先展示整章地图，再逐层展开。博客沿用同一判断顺序，但保留更多机制、案例、失败模式和生产边界：
- 研究与范围：把 GitHub、METR、DORA 和 Stack Overflow 放回样本、任务、年代与测量方式。
- 净收益模型：同时计算实现、等待、Review、返工、质量、成本和新增能力。
- 团队试点：用任务分类、人工基线、失败样本和延迟质量窗口建立证据。
- 成熟度与趋势：让权限、异步和并行扩张服从工程基础与持续复测。
这四步不是目录装饰，而是一条决策链：研究与范围 → 净收益模型 → 团队试点 → 成熟度与趋势。阅读后面的案例时，可以随时回到这条链判断当前问题发生在哪一层。
真实问题：为什么一个漂亮的效率百分比无法指导采购和流程
假设固定实验让 95 名开发者写同一个 JavaScript HTTP Server，容易随机分组和计时，却不能代表复杂 Brownfield；资深维护者在自己的百万行仓库处理真实 Issue，外部效度更高，却样本小、任务选择复杂；问卷覆盖数万人，但测的是感知和报告，不是因果速度；组织调查能看到交付环境，却难隔离单一工具效果。
把任何单一数字直接写进 ROI，会忽略工具代际变化、学习曲线、任务选择和质量。更可靠的做法是先理解证据类型，再用自己的历史基线做按任务分层试点，同时记录人工时间、等待、审查、返工、质量和成本。
机制：把研究放回各自时间与场景
GitHub 早期实验招募 95 名专业开发者，随机分组完成同一 JavaScript HTTP Server 任务，使用 Copilot 的组平均快 55%，平均约 1 小时 11 分，对照组约 2 小时 41 分。这是边界清晰的因果实验，证明特定版本、特定短任务中补全工具能显著帮助；它没有测长期 Agent、熟悉大仓库、Review 和上线。
METR 早期 2025 RCT 招募 16 名有经验的开源开发者，在自己长期贡献的大型仓库中处理 246 个真实 Issue。允许使用当时 AI 工具时，完成时间反而增加 19%。参与者事前预计会快 24%，显示感知与实测存在差异。研究方明确不支持把结果外推到新手、陌生仓库或后来工具。
METR 2026-02 更新认为早期 2026 的工具“很可能”比早期 2025 带来更大加速，但新实验受到严重选择效应：不愿在禁用 AI 条件工作的开发者和高收益任务退出样本，多 Agent 并发也让时间测量不可靠。原参与者子集中心估计约加速 18%，新参与者约加速 4%，置信区间都跨越无效果；研究方因此调整实验设计，并称数据只提供很弱的幅度证据。这里不能挑一个中心值宣布“已证明快 18%”。
DORA 2025 将 AI 描述为放大器：回报不仅来自工具，还取决于组织底层系统；Stack Overflow 2025 调查显示 84% 受访者正在或计划使用开发 AI，51% 职业开发者每日使用，同时 46% 主动不信任其准确性，信任者为 33%。高采用和低信任可以共存：开发者愿意使用，但仍知道输出需要验证。
四种证据回答的是不同问题
基准测试能大规模比较模型在固定题目上的能力，重复性强，却把需求、环境和协作简化；随机固定实验较能推断因果，但场景窄；真实任务研究接近工作，难以控制任务选择、熟悉度和并行；自我报告覆盖广、能看到使用意愿和痛点，却受记忆与感知偏差影响。
组织观察还多一层：AI 使用可能与团队能力、管理投入和工程基础共同变化。高绩效团队更早采用工具，也更可能有快速 CI，不能把相关性全部解释为 AI 因果。
阅读研究时至少检查：研究日期与工具代际；参与者经验；熟悉还是陌生仓库；任务长度与类型；是否随机；允许哪些工具和 Agent；时间是否包含等待、Review 与失败；质量如何评估；是否存在任务或参与者选择；置信区间和研究者自己的外推限制。
净收益不等于生成速度
可以用一个不追求会计精度的模型讨论：
text
净交付收益
= 节省的人工实现时间
+ 新增完成的有价值工作
+ 缩短关键路径带来的价值
- Agent 运行与排队等待
- Prompt、环境和任务准备
- Review、理解与修正
- 错误返工、事故与机会成本
- 模型、云环境和工具费用“新增完成的工作”很重要。Agent 可能没有让核心功能更快，却让团队补齐测试、迁移说明和多平台验证。这不是速度指标能完全捕获的。反过来，Agent 五分钟生成 800 行代码，但 Reviewer 两小时才理解并删除一半，生成速度没有转化为净收益。
不同角色成本不能简单相抵。等待 Agent 时开发者可能并行做其他任务，墙钟时间与主动时间要分开；但多任务切换也有认知成本。Cloud Agent 可以降低主动等待，却增加异步交接和审查。团队要同时记录 elapsed time 和 active human time。
团队指标必须覆盖速度、质量、成本和体验
按任务记录从可执行契约到合并的 Lead Time、开发者主动投入、Agent 等待；首次 CI 通过率、Review 循环和返工；合并后缺陷、回滚、安全问题和支持负担；Token、云环境、工具订阅与 Reviewer 时间。再加入开发者体验：是否减少机械工作、是否增加认知疲劳、是否愿意继续使用。
DORA 指标如变更 Lead Time、部署频率、变更失败率和恢复时间可以观察系统结果，但单个小试点未必有足够样本。任务级指标用于快速学习，团队级指标用于防止局部优化破坏整体。不要为了提高 PR 数把工作切得不自然，也不要让 Agent 生成更多提交来制造活跃度。
质量要有延迟窗口。合并时测试绿不代表一个月后没有运维成本；至少跟踪回滚、线上缺陷、用户报告和维护者返工。AI 生成代码若扩大体积和复杂度，短期速度可能在后期偿还。
为什么代码行数、接受率和 PR 数会误导
代码行数鼓励更大 Diff，而优秀修改往往更小；补全接受率只说明建议被暂时采用，不说明它最终保留、通过测试和创造业务价值；PR 数忽略任务大小和审查负担；Prompt 数可能奖励低效反复。
更接近价值的单位是“满足验收并通过门禁的任务”，再按类型、复杂度和风险分组。即使如此，也不能只比数量，因为团队可能把容易任务交给 AI、困难任务留给人，形成选择偏差。使用历史上相似任务、随机或交叉设计，至少记录任务分配规则。
指标也会改变行为。一旦“AI 代码占比”成为目标，开发者会把不适合的任务交给模型；一旦“首次通过率”成为唯一门槛，可能避开有价值的困难任务。指标组合和定性复盘比单一排行榜健康。
一个可信的团队试点怎样设计
第一步选 2～4 类常见任务，例如小缺陷、测试补齐、局部功能、文档迁移，不从“整个项目”开始。第二步从历史数据建立人工基线，或者让同一批开发者交叉处理相似任务。第三步固定工具版本、权限和基本培训，避免把不会使用工具当作能力结论。
第四步预先定义成功：验收、必跑检查、Review 和质量窗口。第五步记录全成本和失败，不只收集成功案例。第六步按任务类别比较分布和置信程度，而不是求一个全团队平均数。最后决定扩大、保留辅助模式、改进上下文，或停止某类使用。
一个 6～8 周试点比一天 Hackathon 更能观察学习曲线和维护后果。样本不足时不要伪装统计显著，可以报告方向、范围和具体失败模式。将结论写成“在我们当前 Java 服务的小型缺陷中，Agent 降低主动实现时间，但 Review 增加；净 Lead Time 下降”比“效率提升 30%”更可行动。
试点还要记录未完成和放弃任务。只统计合并成功的 Agent PR 会产生幸存者偏差；被人接管、超时、方向错误和未进入 Review 的任务同样是成本。
AI 更像工程系统的放大器
需求清晰、架构可读、构建快速、测试可信、环境可重建、Review 有容量的团队，Agent 能快速读取反馈并小步收敛；隐性规则、脆弱测试、慢 CI、权限混乱的团队，Agent 会更快生成大 Diff、等待错误反馈并制造返工。
这解释了为什么购买同一工具的团队结果不同。模型能力只是一个因子，Harness、上下文、工具、仓库质量、任务契约和治理共同决定产出。投资 AI 时也要投资测试速度、开发环境、模块边界和文档，否则 Agent 只会遇到和人相同的系统阻力。
放大器不是说 AI 永远让坏团队更坏。它也能帮助补文档和测试，但这类基础治理本身需要优先目标和 Owner。让 Agent 无边界“顺便改善代码库”通常会扩大 Diff，而不是系统性还债。
团队成熟度来自反馈闭环，不来自席位数量
辅助阶段使用补全、解释和局部生成，人逐段接受；闭环阶段让本地 Agent 搜索、编辑、测试和 Review 小任务；委托阶段使用云环境和异步 PR，任务契约与交接成熟；平台化阶段统一 Rules、Skills、MCP、权限、观测和效能度量。
每阶段的升级条件不是“模型更新了”，而是下一阶段的风险控制已经成立。没有快速测试时，不宜大量异步委托；没有身份和审计时，不宜接生产工具；没有 Review 容量时，多 Agent 只会堆积候选改动。
成熟团队也会保留低自治路径。架构决策、事故指挥和高风险业务可能始终以人主导，Agent 只研究或验证。成熟度是能按任务选择控制级别，而不是所有任务自动化程度最高。
2026 之后的趋势：竞争点从生成转向可控交付
从当前产品和研究可见六条方向：Agent 在后台执行更长任务；多个隔离环境并行；浏览器、测试和 Review 提供更强自验证；MCP、AGENTS.md 等开放接口降低工具和规则迁移成本；组织平台强化身份、审计、成本和政策；人类工作上移到问题定义、规格、架构、评审和责任判断。
长任务能力提升会让“完成一个 Issue”的基准更接近真实工作，但环境和选择效应也更复杂；多 Agent 让单个任务计时失真，需要衡量组合价值和人的主动时间；更强自验证能降低部分 Review，但模型生成的测试仍需防共同误解。
教程和团队方法应该强调稳定概念：任务契约、最小上下文、工具反馈、权限边界和证据链。产品入口、套餐和模型排名变化快，流程能力更耐久。任何 2026 结论都应标注核验日期，并在采购或发布前重新验证。
失败模式
失败一：选择一个支持立场的研究数字
先比较人、任务、工具、日期和成功定义，保留研究者自己的外推限制。
失败二：只统计成功的 Agent 任务
超时、放弃、被人接管和未合并都是成本。按进入试点的全部任务计数。
失败三：把自我感知当实际速度
感知影响采用和体验，但可能与计时不同。主动时间、墙钟时间与问卷一起看。
失败四：只测编码，不测 Review 与维护
实现加速可能转移成本。记录审查、返工、线上缺陷和后续维护窗口。
失败五：以代码量和 PR 数设目标
这些指标鼓励体积而非价值。使用验收任务和系统质量作为核心。
失败六：全团队一次性推广
不同任务收益分布不同。小范围、分类型试点，再按证据扩展。
失败七：忽视工具和流程持续变化
2025 的结果不能直接代表 2026，也不能用一次试点永久定论。保留版本和日期，定期复测。
生产边界
效能实验不能以降低安全和质量门禁换取速度。试点与对照应遵守相同验收、Review 和发布政策，否则比较的是不同质量标准。开发者监测还涉及隐私和劳动关系，收集 Prompt、时间与行为数据前明确目的、最小范围、访问和保留期。
本文数字来自各机构原始页面，最后核验于 2026-07-20；它们描述各自研究，不构成对具体产品采购收益的保证。METR 2026 更新尤其强调选择效应和测时问题，不应把探索性中心估计包装为确定结论。
实践清单
- [ ] 阅读研究时检查日期、参与者、任务、工具和成功定义。
- [ ] 区分基准、固定实验、真实任务、调查和组织观察。
- [ ] 计算实现、等待、审查、返工、质量和工具的净成本。
- [ ] 同时记录墙钟时间和开发者主动时间。
- [ ] 按任务类别建立历史基线，避免只看全团队平均。
- [ ] 将失败、超时、接管和未合并任务纳入样本。
- [ ] 使用相同质量与安全门禁比较有无 AI。
- [ ] 跟踪合并后缺陷、回滚和维护，而非只看首次 CI。
- [ ] 让推广速度服从测试、Review、权限与观测成熟度。
- [ ] 为工具版本、研究数据和团队结论标注核验日期。
读完之后，你应该能完成什么
- 能识别研究结论能够外推到哪里。
- 能区分生成速度、主动时间和完整交付收益。
- 能设计一个可逆的团队对照试点。
- 能用速度、质量、成本和体验共同决定扩张或停止。
如果只能复述概念，却不能完成上述动作，说明还没有把内容转化成工程能力；可以回到对应机制图、失败模式和实践清单重新核对。
小结
“AI 编程有没有提效”没有脱离场景的单一答案。早期固定实验证明某些短任务能显著加速，真实熟悉仓库研究曾观察到减速，2026 数据提示能力改善却受到选择和并行测量干扰，组织调查则显示高采用与审慎信任并存。团队应停止争夺一个平均百分比，转而建立自己的任务分类、证据链和净收益模型：速度、质量、成本、体验同时成立，才是真正的工程提效。