衡量有用的進展

先定義結果，再選指標

AI 工具可以快速產生程式碼。有用結果則是以所需品質，完成滿足使用者需求的變更。這是兩種不同衡量方式。

生成行數、接受的建議和代理程式執行次數，描述的是活動。它們有助於了解工具使用情況，卻不能證明服務改善，或團隊更早交付了有用工作。

先提出一個問題，例如：「這個工作流程能減少完成小型維護任務的總投入嗎？」收集結果前，先定義完成條件，納入必要測試、審查和文件。

以虛構報表篩選變更為例。不使用 AI 時，實作需要 60 分鐘，審查需要 10 分鐘。使用 AI 後，實作需要 30 分鐘，審查需要 45 分鐘。

實作變快了，但這些階段的實測投入從 70 分鐘增加到 75 分鐘。兩組結果都未包含準備、後續修正，或發布後缺陷。應清楚保留這些限制。

這些數字用來示範計算，不是研究結果，也不是對團隊的預測。審查增加，可能反映 diff 更大、程式碼不熟悉，或需求缺漏。改變工具政策前，先調查原因。

投入衡量人員實際花在工作上的時間；經過時間則包含等待。代理程式執行檢查時，開發者可以處理其他任務。不要重複計算同一段人力時間，也要記錄變更等待審查或環境的時間。

工作流程可能降低投入，卻沒有縮短交付時間。例如，核准佇列可能決定完成日期。節省的投入仍可能有價值，但組織需要另外決定如何運用。

詢問開發者，工作流程是否幫助理解系統及保持專注。將回答視為使用經驗資料，不要把覺得變快，換算成已驗證的改善百分比。

METR 在 2025 年初的一項特定研究中，觀察到有經驗的開放原始碼開發者速度變慢。研究沒有確立對所有開發者或任務的效果。其 2026 年 2 月更新，說明了後續實驗中的選擇效應和測量問題。

有用的啟示在於衡量方式。工具版本、任務選擇、品質要求和參與者行為，都可能改變結果。不要把某個歷史百分比，當成 AI 開發永遠適用的規則。

DORA 的 2025 年研究，也提醒讀者注意工具所處的組織環境。團隊需要有效開發實務，才能將工具能力轉化為有用交付結果。

使用有代表性的任務與相同完成標準。記錄模型和工具版本，納入失敗嘗試及審查投入。比較多項任務，不要只挑最佳展示。

回報結果範圍與主要限制。如果某項變更減少投入卻增加缺陷，應先調查再擴大使用。如果結果不一致，就將建議限縮到已有有用證據的任務類型。

好的衡量結果支持具體的下一項決定，不必證明 AI 在所有情況下都好或都不好。