關於AI輔助程式設計的十二種錯誤評估方式

假設下週你的經理要求你證明公司簽約的AI編碼工具物有所值。你會衡量生成的程式碼行數還是關閉的工單？或者你會傳送調查問卷詢問開發者是否感覺更有效率？每種方法都有不同的缺陷，下文將解釋原因。

注意：本文討論的是人們如何評估AI，而非LLM輔助編碼本身；稍加改寫，這些批評也適用於敏捷開發、測試驅動開發等其他實踐的主張。如果我在過去二十年中學到了什麼，那就是如果我們願意讓人文科學領域的同行教我們如何正確研究這類問題，軟體工程今天會進步得多。

計算生成的程式碼行數：代理指標用於衡量難以直接測量的概念，程式碼行數是最古老的之一。LLM生成更多程式碼，但不一定帶來更好的結果：團隊在採用LLM工具後每位開發者的程式碼行數增加40%，衡量的是冗長而非生產力。刪除2000行混亂邏輯並用200行整潔程式碼替代，是看似損失的改進。更多程式碼也意味著更多閱讀、維護和除錯的工作，而AI對此未來負擔的貢獻並未體現在行數中。

計時人工任務：一項被廣泛引用的研究發現，使用GitHub Copilot的開發者完成任務的速度比不使用的快55%。任務是在90分鐘內從頭開始用JavaScript實現HTTP伺服器，開發者當天沒有其他義務。真正的軟體開發涉及瀏覽未編寫的龐大程式碼庫、理解描述模糊的工單需求、與同事協調、參加會議。在綠色場玩具任務上的速度無法預測這些任務的速度。一項針對有經驗的開源開發者的隨機對照試驗發現，結果與參與者自我預測相反：使用AI工具使任務完成時間增加了19%。

前後對比無對照組：你從1月開始使用LLM；到6月，拉取請求交付更快，所以工具一定有效，對嗎？但1月到6月之間你招聘了12名工程師，重構了CI管道，並更換了雲提供商。沒有未採用工具的對照組，你無法分離LLM的效果與同期發生的其他變化。內部有效性需要可信的反事實，即知道否則會發生什麼的方法。

詢問開發者是否感覺更有效率：諸如“87%的開發者報告使用AI工具後感覺更有效率”的調查結果常被引用為工具有效的證據，但有三點使得自我報告具有系統性誤導：霍桑效應（知道被觀察時工作方式不同）、新奇效應（新工具因新奇而感覺更快，但感覺通常在幾周內消退）、社會期望偏差（受訪者傾向於說調查想聽的話，尤其是管理層選擇了工具時）。

計算提交、拉取請求和工單數量：2023年，麥肯錫提議使用提交、拉取請求、程式碼審查等活動數量來衡量個人開發者生產力。古德哈特定律指出，當一個指標成為目標時，它就不再是好指標。當開發者知道提交數量被追蹤時，他們會進行更多、更小的提交；當工單數量被追蹤時，工單被拆分。數字改善，但基礎工作並未改善。活動不是產出，產出不是價值。

僅衡量簡單的一半：LLM使程式碼生成更快，這一半容易衡量。另一半更難：審查LLM生成程式碼正確性的時間、除錯錯誤建議的時間、看似合理但不安全的程式碼引入的安全漏洞、以及來自忽略周圍設計只解決直接問題的建議的技術債務。對GitHub Copilot程式碼的研究發現，相當一部分生成程式碼包含安全漏洞，且時間壓力下的開發者接受不安全建議的比例更高。2025年對五個主要LLM的評估發現，沒有一個能生成符合行業安全標準的Web應用程式程式碼。一項對30多萬個AI撰寫提交的大規模分析發現，超過15%引入至少一個質量問題，其中近四分之一長期存在於程式碼庫中。只衡量上升的輸入而忽略同樣上升的成本，不是衡量，而是營銷。

將採用率視為成功指標：“我們在工程部門實現了90%的AI工具採用率”是採購結果，而非生產力結果。採用率衡量工具是否安裝和開啟，不說明建議是否有用、開發者是否不加思考地接受、或接受的建議是否正確。高採用率加上低建議質量，會導致團隊花時間管理工具而非受益於工具。對IBM企業AI編碼助手的研究發現，雖然工具通常提供淨生產力提升，但這些收益並非在使用者群中均勻分佈。但採用率比收益更容易衡量，這正是它被報告的原因。

比較志願者與非志願者：比較選擇使用LLM的開發者與未使用的開發者的研究，比較的是兩個不同群體，而非兩種條件。早期採用者與晚期採用者和非採用者在直接預測生產力的方面存在差異：他們更有實驗動機，更適應新工具，更可能是高績效者。選擇偏差意味著任何觀察到的群體差異可能是人的特性而非工具的特性。這是行業AI生產力報告中最常見的設計缺陷，因為它是最便宜的研究。一項為期兩年的大型IT組織Copilot使用縱向研究發現，使用工具的開發者即使在使用前也一直比非使用者更活躍。

衡量個體而非系統：個體編碼速度是最容易衡量的，因此被衡量。但如果AI工具幫助開發者編寫程式碼快30%，而團隊從工單到生產的時間沒有變化，那麼瓶頸不是編寫程式碼。生成更多程式碼也意味著更多程式碼需要審查：如果AI增加程式碼量而不增加審查能力，週期時間可能惡化。一項針對專業開發者的實證研究發現，雖然AI工具提高了經驗較少的貢獻者的輸出，但高階開發者的生產力下降了19%，因為他們吸收了AI生成程式碼帶來的6.5%的程式碼審查負載增加。最佳化管道的一個階段而忽略其他階段，是偽裝成生產力研究的系統思維失敗。

在新奇期間衡量：一項為期四周的研究發現生產力提升，只是發現了四周的生產力提升。新奇效應是真實的：開發者在初始階段對新工具更投入，這相對於長期基線會誇大觀察到的表現。真正重要的效果會在數月而非數週內顯現，包括因任務委託給AI導致的技能萎縮、錯誤建議積累的技術債務、或團隊協作方式的變化。旨在檢測短期收益的研究，並不能告訴你研究結束後會發生什麼。對807個採用Cursor的開源倉庫的分析正好發現了這種模式：採用帶來了大量但短暫的開發速度提升，同時伴隨著程式碼複雜性和靜態分析警告的顯著且持續的上升。

將建議接受率視為質量訊號：LLM編碼助手通常報告其建議被開發者接受的分數，更高的接受率被視為工具有用的證據。接受率衡量生成的程式碼看起來是否足夠合理以至於開發者按下Tab鍵；它不衡量程式碼是否正確、安全或可維護。時間壓力下的開發者接受更多建議，包括不安全的，因此緊迫的截止日期使接受率因完全錯誤的原因而上升。一項對400名開發者的企業研究發現平均接受率為33%，同時伴隨高開發者滿意度，但沒有跟蹤接受程式碼的正確性或安全性。一個獎勵看起來足夠好的指標，並不是獎勵真正好的指標。

將AI與無工具比較：將AI輔助開發者與使用無工具的對照組比較的研究，選擇了實踐中不存在的基線。沒有LLM助手的開發者會使用文件、同事以及他們原本用於思考問題的時間。相關問題是LLM工具是否優於開發者已有的替代方案，而這種比較很少進行。選擇弱基線使任何工具看起來不錯，但這並不使工具變得有用。

我衷心感謝多年來花時間向我解釋這些內容的所有人。我所寫的任何錯誤或過度簡化都完全是我的責任。