健康經濟學指標

第 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周的測量資料會因新奇效應而在任一方向上失真；應在穩態下測量（參見時間跨度）。

來源