健康经济学指标

第 75 个主题，共 91 个· 人工智能加速

AI与开发者生产力 (AI Developer Productivity)

衡量AI编程辅助对工程产出究竟带来了什么影响的一组指标：建议采纳率、对照研究中的提速幅度、PR吞吐量以及代码留存率。相关证据基础存在真实的相互矛盾之处——这恰好使其成为效力（efficacy）与实效（effectiveness）之辨的绝佳案例，而这正是健康经济学一直以来专门用来处理此类问题的方法论。

为何重要

两项被引用最多的对照研究得出了截然相反的结论：

  • Peng等，2023年（GitHub Copilot随机对照试验）：在一项从零开始搭建HTTP服务器的任务中，使用Copilot的开发者速度提升了55.8%（1小时11分钟 vs. 2小时41分钟，n=95）。
  • METR 2025年随机对照试验：在自己维护的成熟代码库上工作的资深开源开发者，使用2025年初的AI工具时反而慢了19%（16名开发者，246项任务）——但他们自己却认为速度提升了20%。

这两项研究都是严谨的研究。矛盾本身就是发现：绿地任务（greenfield task）上的效力并不能迁移为成熟代码库上的实效，而主观感受到的收益也不能替代实测收益。医学界对这两种现象早有命名（解释性试验 vs. 实用性试验；安慰剂问题），也早有一套处理机制。

计算方法

采纳率     = 被采纳的建议数 / 展示的建议数
            （GitHub遥测数据平均约30%；因语言而异：SQL 45%，Python 35%，JS 28%）
留存率     = 存活至合并的AI代码 / 被采纳的AI代码（据报告约88%）
提速幅度   = (t_对照组 − t_AI组) / t_对照组（仅可由对照比较得出）
吞吐量变化 = 每名开发者每周合并PR数的变化Δ（GitHub/埃森哲实地数据：+8.7%）

价值模型   = 开发者人数 × 节省时间 × 全成本时薪 × 利用率因子
            ——每一项都需要本地实测；参见sensitivity-analysis.md中的
            龙卷风图，其中"节省时间"这一项的影响力压倒其余所有参数之和

实例演算

一家拥有500名开发者的机构，通过设置恰当的对照组（匹配团队、为期3个月、预先登记指标）试点某AI助手：

试点结果：PR周期时间 −18%；已合并PR数 +6%；变更失败率（CFR）不变；
          自报节省时间为每天45分钟；任务级实测约为每天15分钟

按实测数值计价：500 × 0.25小时 × 220天 × £60 × 0.6利用率
                ≈ 每年£990,000的产能（非现金释放型）
成本：500 × £39/月 × 12 ≈ 每年£234,000
净产能比约为4:1——足以获得资助，即便只是自报收益的三分之一。

主观感受与实测数值之间3倍的差距，正是METR研究结论在现实场景中的体现；若按自报数据编制预算，收益线将被夸大三倍。

与软件工程的关联

面向任何评估AI工具的团队，健康经济学可以直接移植过来的做法是：开展实用性试验（用你自己的代码库、你自己的工程师、真实的工单——而非供应商的演示任务）；将采纳率视为代理指标而非结果本身（从开发者的视角看，它相当于建议的阳性预测值——高采纳率而低留存率就是"过度诊断"）；每一次吞吐量提升都要配合稳定性检查（DORA 2025年报告：AI提升吞吐量的同时会损害稳定性——一项带有副作用的干预措施需要做净收益分析，参见DORA指标）；并如实地将该收益归类为产能收益（参见现金释放型与非现金释放型）。

常见陷阱

  • 供应商研究的生搬硬套：将绿地场景下的随机对照试验数据套用到存量代码库的工作中——这正是METR研究所揭示的典型错误。
  • 将自我报告当作实测：这20个百分点的认知偏差，是该领域文献中已知的最大偏差之一。
  • 活动量虚增：更多的PR和更多的代码属于"活动"（Activity），并非结果（参见SPACE框架）；须配合返工率与变更失败率一并考察。
  • 忽视学习曲线：第2周的测量数据会因新奇效应而在任一方向上失真；应在稳态下测量（参见时间跨度）。

来源