Stanford 研究員 Yegor Denisov-Blanch 分享了一項為期兩年、橫跨 12 萬名開發者的研究成果，探討 AI 工具對軟體工程生產力的真實影響。研究發現使用 AI 的團隊中位數生產力提升約 10%，但頂尖團隊與落後團隊之間的差距正在擴大。關鍵發現是：AI 使用品質遠比使用量重要，程式碼庫的整潔度與 AI 帶來的生產力提升高度相關，而單純衡量 PR 數量等表面指標可能嚴重誤判 AI 的真實效益。

原影片連結：https://www.youtube.com/watch?v=JvosMkuNxF8

影片重點

• 使用 AI 的團隊中位數生產力提升約 10%，但團隊間差異極大
• AI 使用品質比使用量更重要，token 消耗量與生產力提升的相關性很低
• 程式碼庫整潔度（Environment Cleanliness Index）與 AI 生產力增益有 0.40 的 R² 相關性
• 乾淨的程式碼能放大 AI 的效益，而不受控的 AI 使用會加速技術債累積
• AI 工程實踐基準（AI Engineering Practices Benchmark）可偵測團隊如何使用 AI
• 衡量 AI ROI 應聚焦工程產出而非商業成果，需搭配主要指標與護欄指標
• 案例研究顯示：PR 數量增加 14%，但程式碼品質下降 9%，返工增加 2.5 倍
• 表面指標可能誤導決策，全面衡量才能看清 AI 採用的真實效果

詳細內容

[00:00] 研究背景與方法論

企業花費數百萬美元購買 AI 軟體工程工具，但這些工具在企業環境中究竟效果如何？為了回答這個問題，Stanford 團隊進行了一項為期兩年的研究，採用時間序列與橫斷面分析方法，透過 Git 歷史資料回溯分析多家企業的數據。

研究核心是一個機器學習模型，用來複製人類專家小組的評估結果。具體做法是：讓軟體工程師提交程式碼 commit，由 10 到 15 位獨立專家從實作時間、可維護性和複雜度等維度進行評估。團隊利用數百萬筆專家評估標籤訓練模型，使其能夠大規模部署，並且在對模型輸出有疑慮時，可隨時組建專家小組進行驗證。

[01:40] AI 生產力提升的差異與趨勢

研究團隊將 46 個使用 AI 的團隊與 46 個未使用 AI 的相似團隊進行配對，每季度測量淨生產力增益。截至當年七月，中位數生產力提升約為 10%。

然而值得注意的是，頂尖團隊與落後團隊之間的差距正在擴大。如果將這個趨勢投射到未來，可能出現「強者恆強」的馬太效應：成功的早期 AI 採用者持續累積優勢，而掙扎的團隊則進一步落後。這意味著企業領導者必須了解自己所屬的團隊位於哪個分群，才能及時調整策略。

[03:10] AI 使用品質比使用量更重要

研究團隊首先調查了什麼因素驅動頂尖團隊表現更好。第一個發現是 AI 使用量（以 token 消耗量衡量）與生產力提升的相關性相當鬆散，線性 R² 僅約 0.20。此外還出現了一個「死亡谷」效應：在每月約 1000 萬 token 的使用量附近，團隊的表現反而比使用較少 token 的團隊更差。結論是：AI 使用品質比使用量更為重要。

[04:05] 程式碼庫整潔度是關鍵因子

研究團隊進一步提出了「環境整潔度指數」（Environment Cleanliness Index），這是一個綜合評分，涵蓋測試、型別定義、文件、模組化程度和程式碼品質。該指數與 AI 帶來的生產力提升呈現 0.40 的 R² 相關性，這是相當不錯的結果。

研究用三種顏色來說明程式碼庫整潔度與 AI 效益的關係：綠色代表 AI 可以完成大部分工作，黃色代表 AI 可以輔助，紅色代表 AI 幾乎無用。乾淨的程式碼能放大 AI 的效益，這帶出三個重要啟示：

第一，乾淨的程式碼會放大 AI 的增益。第二，需要管理程式碼庫的熵（技術債），因為不受控地使用 AI 會加速熵的增長，降低整潔度。第三，工程師需要知道何時該用 AI、何時不該用——當 AI 產出被拒絕或需要大量改寫時，工程師會對 AI 失去信任，進而完全停止使用，形成惡性循環。

[06:50] AI 工程實踐基準

團隊開發了一個 AI 工程實踐基準（AI Engineering Practices Benchmark），可以掃描程式碼庫偵測 AI 使用的痕跡與模式，並基於每月 Git 歷史數據進行追蹤。

基準將 AI 使用分為五個等級：Level 0 是完全人工撰寫程式碼；Level 1 是個人使用，工程師未在團隊間分享 prompt；Level 2 是團隊使用，prompt 和規則在團隊間共享；Level 3 是 AI 自主執行特定任務但非完整工作流程；Level 4 則是 Agentic 編排，AI 運行整個流程。該工具將作為開源專案發布，可透過 SWEPR（Software Engineering Productivity Research）研究入口網站取得。

一個有趣的案例是：同一家公司的兩個業務單位擁有完全相同的 AI 工具存取權，但採用率和使用方式截然不同。左側的業務單位約有 40% 的工作使用 AI，而右側的單位則明顯落後。這說明光有 AI 工具的存取權並不足夠，領導者需要了解工程師「如何」使用 AI，而不僅是「是否」在使用。

[09:45] 衡量 AI 投資回報率的框架

理想情況下，我們應該直接衡量商業成果（營收、淨收入留存率等），但從「給予 AI 工具」到「商業成果」之間有太多雜訊和混淆變數（銷售執行、總體環境、產品策略等），因此研究建議聚焦於工程產出指標。

這個方法有幾個前提假設需要注意：首先，假設產品團隊能將增加的產能導向有價值的方向；其次，假設工程是價值創造的有意義瓶頸；最後，雖然 AI 仍然很新，代理指標不完美，但有衡量總比沒有好——在 AI 競賽中會有贏家和輸家，進步比完美更重要。

[11:40] 使用量衡量：存取導向 vs. 使用量導向

衡量 AI ROI 需要兩部分：使用量測量和工程產出測量。使用量的衡量方式分為兩種：存取導向（Access-based）是看何時給予工具存取權，可設立先導組與對照組比較，但這種方式雜訊較大；使用量導向（Usage-based）是透過 AI 編碼助手的 API 遙測數據來精確了解誰在使用、在哪裡使用，這是黃金標準。

需要注意的是，不同廠商的 API 粒度不同——像 GitHub Copilot 會聚合數據，而 Cursor 提供更細緻的資料。一個重要的要點是：可以利用 Git 歷史回溯性地衡量 AI 的影響，不需要現在才設置實驗等待六個月。

[13:15] 工程產出指標框架

研究提出的框架使用主要指標（Primary Metric）和護欄指標（Guardrail Metrics）。主要指標是工程產出——不是程式碼行數、不是 PR 數量、也不是 DORA 指標，而是基於複製專家小組的機器學習模型。護欄指標分為三類：返工與重構、品質技術與風險、人員與 DevOps。

重要的是，護欄指標本身不是生產力指標，不應被最大化，而應維持在健康水準。目標是在維持護欄指標健康的同時，盡可能提升主要指標。

[15:00] 案例研究：表面指標的陷阱

研究團隊與一家大型企業合作，選取一個 350 人的團隊，測量其在五月份採用 AI 前後各四個月的表現。

PR 數量：增加了 14%。表面上看起來很棒。

程式碼品質：品質（以可維護性衡量，0-10 分）在採用 AI 前相當穩定一致，但採用後出現兩個問題——品質下降了 9%，且波動變得更加劇烈。

工程產出：使用團隊自研的工程產出指標（分為返工、重構、新增和移除四類），AI 的使用帶來兩個效果——返工增加了 2.5 倍（非常糟糕），而有效產出幾乎沒有變化。

[18:00] 結論與行動建議

案例研究的總結令人警醒：PR 增加 14%（無法定論，更多 PR 不等於更好）、程式碼品質下降 9%（有問題）、有效產出沒有顯著增加、返工大幅增加。這個 AI 採用的 ROI 可能是負數。

如果這家公司只看 PR 數量，他們會以為自己做得很好，宣稱生產力提升了 14%，計算出節省了數百萬美元的成本，並認為這足以抵銷 AI 授權費用。但事實可能恰恰相反。

不過，這並不意味著應該放棄 AI。AI 是一個將改變工程師工作方式的工具，企業應該利用這些數據來理解自己做錯了什麼、如何改進。如果您對類似的洞察感興趣，可以透過 softwareengineeringproductivity.stanford.edu 加入他們的研究計畫。

我的想法

這項研究最令人震撼的發現是「返工增加 2.5 倍」——這意味著 AI 生成的程式碼雖然快速，但可能在後續需要大量修改，抵消了原本的效率提升。這與許多開發者的直覺體驗一致：AI 工具讓你寫程式碼的速度更快了，但 debug 和修正的時間也相應增加。

「環境整潔度指數」的概念特別有價值。它暗示了一個反直覺的策略：在全面導入 AI 工具之前，或許應該先投資整理現有程式碼庫——提高測試覆蓋率、完善型別定義、改善模組化。這可能比直接購買更多 AI 授權能帶來更好的回報。

對於正在評估 AI 工具的工程團隊領導者，這項研究提供了一個實用的提醒：不要僅用 PR 數量或 token 消耗量來衡量 AI 的價值。建立一套包含品質、返工率和有效產出的綜合指標體系，才能避免自欺欺人式的「虛假繁榮」。同時也要注意，AI 的使用方式是可以教育和引導的——Level 1（個人使用）和 Level 2（團隊共享）之間的差異，可能就是你的團隊是否能真正受益於 AI 的關鍵。