用了 AI 反而更慢？METR 隨機對照實驗的殘酷真相

本文整理自《Latent Space: The AI Engineer Podcast》2026 年 2 月播出的單集。

{{< youtube 9QSm_mRGpN8 >}}

{{< spotify "episode/1gdGWVvbrHgxkDX4JnTBgE" >}}

{{< apple-podcast "tw/podcast/metrs-joel-becker-on-exponential-time-horizon-evals/id1674008350?i=1000751972505" >}}

---

每個人都說 AI 讓自己更快了，但數據怎麼說？

你大概聽過這樣的話：「自從開始用 AI，我的工作效率提升了好幾倍。」這類宣稱在軟體工程師的社群裡特別多。GitHub 說 Copilot 讓開發者快了 55%，各家新創的行銷頁面上動輒寫著 10 倍加速。如果你還沒有用 AI 輔助寫程式，你好像已經落後了一整個世代。

但有一個組織真的去做了科學實驗來驗證這件事，結果跟所有人的預期完全相反。METR（Model Evaluation and Threat Research）是一個獨立的 AI 安全研究組織，它在 2025 年初進行了第一個針對 AI 輔助程式設計的高品質隨機對照試驗（RCT）。結論很刺眼：AI 讓資深開發者的完成速度慢了 19%。不是快了 19%，是慢了。

METR 研究員 Joel Becker 最近在 Latent Space Podcast 上詳細討論了這項研究的發現、它的侷限、以及為什麼這個實驗現在幾乎不可能重做。Becker 在紐約大學拿了經濟學博士，這個背景讓他對實驗設計和因果推論有一種工程師圈子裡少見的嚴謹。他說出來的話往往不是科技圈想聽的，但正因為如此才值得仔細聽。

第一個高品質的 AI 生產力實驗

這項研究的設計很直接。找 16 位在成熟開源專案中有豐富經驗的開發者，平均每人在自己負責的專案上工作了五年。然後隨機將 246 個實際開發任務分配成兩組，一組允許使用 AI 工具，另一組不允許。主要使用的 AI 工具是搭配 Claude 3.5 和 3.7 Sonnet 的 Cursor Pro。數據收集從 2025 年 2 月持續到 6 月。

為什麼要用隨機分配？因為這是消除選擇偏差的唯一方法。如果讓開發者自己決定什麼時候用 AI、什麼時候不用，他們自然會在預期 AI 有幫助的任務上使用 AI，這樣你就分不清到底是 AI 真的有幫助，還是他們挑了 AI 本來就擅長的任務。隨機分配強制消除了這個問題。

另一個關鍵的設計決定是：研究對象是「在自己熟悉的、成熟的開源專案上工作的資深開發者」。這不是大學生做作業，也不是第一次接觸某個代碼庫的新手。這些是最了解自己專案的人，在最熟悉的環境中工作。METR 特別選擇了這個群體，因為他們想測量的是 AI 在「最有利的 demo 情境」之外是否仍然有效。畢竟，AI 的產品展示永遠是最理想的場景：乾淨的問題、明確的範圍、新手友好的代碼庫。真實世界往往相反。

慢了 19%，但自己覺得快了 20%

結果出來了：使用 AI 的那組平均慢了 19%（95% 信賴區間：慢了 2% 到慢了 39%）。這個數字已經夠讓人意外了，但更引人入勝的是感知和現實之間的落差。

在實驗開始前，開發者們預測 AI 會讓他們快 24%。這算是比較保守的估計了。外部的專家們，包括經濟學家和機器學習研究者，預測的加速幅度更大，高達 38% 到 39%。所有人都認為 AI 至少會帶來某種程度的加速。結果不是零加速，是負加速。

更有意思的是實驗結束後的主觀感受。開發者們經歷了實際的減速之後，被問到覺得 AI 對自己的速度有什麼影響，平均回答是「快了大約 20%」。他們實際上變慢了，但自己的感覺是變快了。這個感知和現實之間差了 39 個百分點的鴻溝，可能是整個研究中最具啟發性的發現。它暗示著，即使是直接經歷了 AI 工具影響的當事人，也無法準確判斷 AI 到底是在幫忙還是在拖後腿。

Becker 和他的共同作者們提出了幾個可能的解釋。AI 工具確實讓某些子任務變快了，比如寫出某段函式的初稿、產生測試的模板。但它同時引入了新的開銷：審核 AI 生成的程式碼是否正確、修正不符合專案標準的建議、以及在嘗試跟 AI 互動的過程中分散了注意力。對於已經非常熟悉自己代碼庫的資深開發者來說，這些摩擦成本有時超過了 AI 節省的時間。那些子任務的加速感受是真實的，但它們遮蔽了整體的減速事實。

為什麼 AI 提速宣稱被系統性高估

Becker 在 Latent Space 上指出了一個更結構性的問題：業界對 AI 提速的估計之所以經常被膨脹，不只是因為個案層面的感知偏差，而是因為整個測量方式就有系統性的偏誤。

第一個偏誤是選擇偏差。當人們自行決定何時使用 AI 時，他們會自然地把 AI 用在預期效果最大的任務上。然後他們報告「AI 讓我在這些任務上快了多少」，但沒有人統計那些 AI 幫不上忙、所以根本沒用 AI 的任務。只看有選擇性地使用 AI 的場景，當然會高估 AI 的整體影響。這就像一個基金經理只報告他賺錢的交易，你看到的勝率自然是 100%。

第二個偏誤跟邊際價值有關。AI 讓你可以做一些你以前不會做的事情：多寫幾個測試、多重構一段程式碼、多加一些文件註解。但這些「多做的事」之所以之前沒做，往往是因為它們不夠重要。你的 to-do list 上排在最下面的項目，邊際價值本來就低。Becker 的原話是：「對 AI 提速的樂觀估計，在某種程度上被我們在論文中記錄的現象膨脹了：人們對提速的預期往往過於樂觀。」

第三個問題是現代工作模式的變化。在 2025 年初做實驗的時候，開發者的工作方式還比較傳統，一次處理一個任務。但到了 2026 年，越來越多工程師開始用 AI agent 同時處理多個任務。你派一個 agent 去做任務 A，同時自己或另一個 agent 處理任務 B。這種多工模式讓單一任務的「提速」變得不太有意義，因為真正的效率提升可能來自併發能力，而不是單一任務的完成速度。METR 的 RCT 設計是基於單一任務的隨機分配，這個框架越來越難捕捉到現代工作流程的真實樣貌。

這個實驗現在做不了了

也許最令人不安的發現不在資料本身，而在實驗設計的崩壞過程中。METR 在 2025 年 8 月啟動了第二輪研究，這次規模更大：57 位開發者（10 位回歸的、47 位新加入的），每小時 50 美元的報酬。但他們很快發現了一個致命的問題。

30% 到 50% 的開發者拒絕提交他們不想在「禁止使用 AI」條件下做的任務。也就是說，如果一個任務被隨機分配到不能用 AI 的組別，而開發者覺得沒有 AI 做這個任務很痛苦，他們就直接不做了。這種系統性的退出嚴重扭曲了樣本：留下來的任務都是那些「有沒有 AI 都差不多」的低難度任務，恰好是 AI 提速效果最小的一批。

更極端的是，有些開發者根本拒絕在任何情況下不使用 AI 工具工作。即使每小時給 50 美元也不行。AI 已經成為他們工作流程中不可或缺的一部分，要求他們不用 AI，就像要求一個習慣了自動排檔的人回去開手排車上班一樣。不是做不到，而是為什麼要這樣折磨自己？

這個現象本身就是一個極有價值的資料點。它說明 AI 工具的採用，至少在某些開發者群體中，已經到了一個臨界點：不用 AI 不再是一個可接受的實驗條件。但諷刺的是，這個事實同時讓我們失去了用最嚴格的科學方法來測量 AI 實際影響的能力。你想知道 AI 到底有沒有用，但受試者拒絕在沒有 AI 的情況下被觀察。METR 已經公開承認了這個困境，宣布正在重新設計實驗方法，轉向更短期的密集實驗、觀察性數據分析和固定任務設計。

科學測量 vs 行銷敘事

Latent Space 的主持人 Swyx 在節目中做了一個直率的觀察：「人們對 agent 表現的宣稱，目前的狀態是非常不科學的，更多是軼事性的，有時候還受到行銷意圖的影響。」這句話精準地描述了 AI 生產力論述的現狀。大量的「AI 讓我快了 X 倍」宣稱，來自個人軼事、來自公司的行銷材料、來自沒有控制組的前後對比。真正做了嚴格實驗的組織屈指可數，而目前唯一的高品質 RCT 結果是「變慢了」。

這不代表 AI 永遠不會提升生產力。模型確實在快速進步。Becker 自己就觀察到，他認識的一些最頂尖的工程師已經從挑剔地使用 AI 轉變到幾乎不自己寫一行程式碼。隨著 Opus 4.5 這類新模型的出現，METR 的 Time Horizon 指標顯示 AI 能可靠完成的任務難度正在指數成長。結果會改變，幾乎是確定的事。

但改變需要被證明，不是被宣稱。Becker 提出了一個他認為更有意義的評測方式：不只看 AI 生成的程式碼能不能通過單元測試，而是看那些程式碼會不會真的被合併進主分支。通過測試是一回事，程式碼有沒有遵循代碼庫的規範、有沒有加上適當的測試、有沒有跟其他元件正確整合，這些才是一段程式碼在生產環境中到底有沒有用的標準。在 AI 生產力的衡量上，我們需要的不是更多軼事，而是更多像 METR 這樣的組織，用科學方法去測量那些大家假裝已經知道答案的問題。