AI 讓速度指標必然變好看——所以每個速度指標,我都配一個品質反向指標

導入 AI 之後,你的儀表板會全面變綠:PR 變多、commit 變密、部署變快、產 code 量翻倍。如果你拿這些數字向老闆報告成效,數字一定漂亮——問題是,這些指標在 AI 時代「必然」漂亮。它們量的正好是 AI 最擅長放大的東西:產出量。

漂亮不等於有成效。我把這叫產出量假象:速度指標單獨讀,量不出 AI 放大的到底是產出、還是缺陷。

AI 是放大器,不是修復器

DORA(Google Cloud 旗下、做了十幾年的軟體交付研究)在 2025 年的報告量到一組分裂的數據:AI 採用和交付吞吐正相關,和交付穩定性卻是負相關。同一批工具,讓團隊出貨更快,也讓更多變更出事。

這組分裂正好說明 AI 的性質:它放大團隊既有的體質,不修復它。有強自動化測試、快 feedback loop 這些控制系統的團隊,用 AI 之後同一批人變更強;沒有的團隊,變更量放大直接變成不穩定放大。放大器接在哪種體質上,結果天差地遠——而速度指標兩種情況下都會變好看,單看它你分不出自己是哪一種。

成對讀:DORA 四大指標早就是這個結構

分得出來的讀法,DORA 十年前就給了。它的四大指標刻意設計成兩組對照:

速度	品質反向
部署頻率(多久能上線一次)	變更失敗率(上線後多少比例出包)
變更前置時間(commit 到上線多久)	恢復時間(出事後多久修好)

成對結構本身就是洞見:速度指標永遠跟穩定指標一起讀,拆開讀任何一組都會被誤導。AI 時代只是把「拆開讀」的代價放大了。

套到 AI 導入的量測,我的配法:

• 部署頻率 配 變更失敗率
• PR 數 配 revert / 短期 churn 率(合進去多少,又吐回來多少)
• 產 code 量 配 資安漏洞數(產得快,漏洞也產得快嗎)
• 省下的工時 配 時間投去了哪(省下來的時間沒有指引,不會自動變成價值)

每一對的右邊,都是左邊那個數字最容易掩蓋的東西。

還有一層:指標之下,看 artifact 不看自陳

成對讀解決「指標層」的失真,但還有更底層的一種:問卷。問團隊「AI 用得如何」,自陳一定失真——研究已經量到過開發者自覺變快、實測反而變慢的例子。所以我的量測其實是兩層:

• 資料層:證據來自一手 artifact——git log、diff、session 軌跡。誰在用、用在哪、產出有沒有可驗證的變化,調紀錄,不辦問卷。
• 指標層:從 artifact 算出來的指標,速度配品質反向,成對讀。

兩層合起來,才擋得住 AI 時代最便宜的兩種自欺:自己說有效,和只給老闆看會變綠的那半邊儀表板。

量到取捨,代表順序反了

最後一個容易誤讀的地方:DORA 跨產業的長期發現是,速度和穩定不是取捨——頂尖團隊部署更頻繁、同時失敗率更低,因為快和穩同源:小批量變更、強自動化測試、快 feedback loop。

所以當你的成對指標量出「吞吐上升、穩定下降」,別急著結論「AI 就是快歸快但不穩」。那條負相關說的不是 AI 的本性,是你的順序:控制系統還沒蓋好,就先放大了產出量。修法不是把 AI 關小,是回頭把測試和 feedback loop 蓋起來——放大器沒有錯,錯的是接上去的時機。

速度指標會自己變好看,品質反向指標不會。後者才是你真正在管的東西。