AI到底有沒有提升產出，沒人真正知道：量產出，別量使用量

問題是什麼

公司逼著大家用AI，然後用使用量來衡量結果：多少個席位、多少次提示、程式碼建議被採納的比例是多少。麻煩在於，使用量不等於產出。用得多並不保證工作變好，而在強制之下，使用量指標恰恰是最容易灌水的地方。管理者看著儀表板上的藍線往上爬，就相信一切順利，可真正的問題，也就是團隊的成果有沒有變好，卻無人回答。

證據直指這種錯覺。一項涵蓋約6,000名高階主管的NBER調查顯示，超過80%的企業感受不到AI對生產力的明顯影響。開發一側的遙測更為嚴峻。Faros AI追蹤了2.2萬名開發者兩年，發現雖然75%的人使用AI工具，多數組織卻量不出績效提升；吞吐量上升了66%，但事故與缺陷上升得更快：每個合併PR引發生產事故的機率同比翻了三倍多，人均缺陷增加了54%。使用量上升、品質下降，就在同一段時間裡同時發生。管理者正是在這中間矇著眼睛做判斷。

為什麼是現在

眼下兩股潮流疊在一起。一是AI強制推行已成主流。越是由上而下逼著用，越渴求一套衡量真實效果而非單純使用量的辦法。二是現有工具的盲區。工程領域已經有量測：Faros AI與DX的DX Core 4，從git與PR遙測中讀取吞吐量與品質。但仍有兩處空白。第一，這些工具大多依然在報告使用量與吞吐量，很難在因果上分辨某個人是否真因AI而變好。第二，業務、客服、營運、行銷、法務這類沒有git日誌的知識工作，幾乎沒有對應工具。強制落在所有這些職能上，量測卻止步於工程團隊。

flowchart LR
  A[導入前基準<br/>每人的產出與品質] --> C[因果量測<br/>保留組·分階段推行]
  B[使用AI後的產出<br/>速度·返工·錯誤率] --> C
  C --> D[每人的真實提升<br/>品質校正後的差值]
  D --> E[給管理者的誠實訊號<br/>產出而非使用量]

怎麼構建

從一個產出看得見的職能開始，做窄。以客服為例，產出就是解決時長、二次諮詢率與品檢評分。關鍵有三點。第一，為每個人留下導入前的基準。第二，做因果量測：用有人先開、有人後開的分階段推行，或者保留組，從中取出真實的改善量，而非相關性。第三，用品質做校正：如果變快了但返工、錯誤或事故增加了，就把這部分損失從產出中扣掉。由此得出的每人差值，安靜地交給管理者。要把存取權限與呈現方式收窄，讓它被當成輔導訊號，而非監控。

收入用團隊或按席位訂閱比較自然。想降低落地初期的抵觸，就不要第一天就給人排名。先畫一張團隊層級的地圖，展示哪類工作AI真正見效、在哪裡空轉。個人排名等信任建立之後再說。

成功條件

兩個條件要同時成立。第一，你得能為每個職能定義一套抗刷、經過品質校正的產出指標。指標一旦鬆散，這個工具最終也會淪為又一塊使用量儀表板。第二，組織得能接受「這次強制沒起作用」的誠實訊號。把「沒效果」甩到推動AI的高階主管面前，在政治上很不舒服，缺了容忍這種不適的文化，工具就會被塞進抽屜。跨過這兩關的團隊，才能剝掉使用量的遊戲，第一次為AI究竟在哪裡真正讓工作變好而定價。接下來只剩一個問題：在我們團隊裡，AI此刻真正改善的工作，有幾項。