看似加速，實則拖慢：AI 寫代碼讓開發者效率倒退19%

美國METR研究所完成了一項針對AI編程工具影響的實驗研究。他們發現，經驗豐富的開源開發者在使用AI編程工具時，完成任務的時間平均增長了19%。

這與開發者自己的感知完全相反。畢竟，參與研究的開發者普遍都相信，AI將提升他們的效率。

在任務開始前，他們預測AI能讓自己提速24%。可現實數據冷冷地指出：AI讓他們「看似飛快，實則拖慢」。

研究團隊通過隨機對照實驗（RCT），在真實環境中測試AI工具的使用效果。值得一提的是，這是目前公認的衡量因果關係最嚴格的方法。

實驗如何進行？

實驗共追蹤了16名高級開發者，這些開發者在各自的開源項目中完成了246個實際任務，任務涵蓋複雜模塊的開發與修復，工作負載真實而具體。

每個任務被隨機分配到兩個組：一組使用AI工具，另一組不使用。

AI組開發者主要使用的是Cursor Pro，集成了Claude 3.5和Claude 3.7 Sonnet等主流大模型。

開發者在整個過程中錄屏，並記錄完成每個任務所花費的時間。為了剔除任務難度差異的干擾，研究人員採用了統計方法，引入開發者對任務時間的預估值作為參考。

換句話說，他們不僅測量「花了多長時間」，還測量「比預期多了多少」。

最終結果顯示：AI用戶完成任務的平均用時比非AI用戶長出19%。

諷刺的是，哪怕在任務完成後，那些用過AI的開發者仍然堅信，自己「節省了20%的時間」。

即便現實已經反轉，他們依然覺得自己在加速。

研究者指出，這種「快感錯覺」可能來自AI協助下的新型流程分佈。研究結果表明，AI並沒有真正提升核心產出環節的效率，只是重新分配了注意力和勞動方式。

具體來說，當AI工具被啟用後，開發者在「主動編碼」上的時間反而減少了。

他們花了更多時間在提示設計、AI產出審查、等待響應、閑置，以及理解生成內容上。

研究顯示，開發者不是在寫代碼，而是在「與AI溝通如何寫代碼」。這種交互過程看起來很「充實」，但最終產出並不一定更快。

對新項目或快速原型開發，AI確實能提供幫助。但在面對成熟的大型項目，特別是開源社區中常見的、結構複雜、規則隱含、質量要求高的工程時，AI反而成為新的負擔。

它需要大量的補充說明、更頻繁的審查，甚至還會引發語義誤解。

開發者不再是在解決問題，而是在解釋問題、矯正AI、並試圖相信AI有幫助。

此外，開發者的「心理節奏」也發生了變化。他們頻繁切換任務：提示生成、回顧產出、人工修正、重覆嘗試，這種流程非常碎片化。

當一個人忙於各種小動作時，他自然會覺得自己很「快」。但數據不會說謊：他只是「動了很多」，並沒有「前進很遠」。

還有哪些發現？

METR的研究不僅揭示了AI工具在實際工作中的真實效率，還對目前主流AI評估體系提出了質疑。

他們指出，當前業界廣泛採用的基準測試，如SWE-Bench和RE-Bench，存在嚴重偏差。這些測試通常是人工設置的小型題目，情境孤立，完全不反映真實項目的複雜性。

開發者在其中只需解決一小段代碼問題，不用考慮上下文、不用和團隊協作，也沒有歷史遺留負擔。

這種測試環境高度理想化，與開源項目、企業代碼庫、或大型框架開發的日常工作完全不同。

於是，我們就得到了一個錯誤的結論：AI表現得非常強大。

而METR的隨機對照實驗，則是在現實中運行、在項目中嵌入、在流程中測量。研究人員將AI直接部署到開發者的真實任務中，不幹預流程，只記錄結果。

這是對「AI助力」的最直接檢驗。

而且，這種實驗還能揭示「感知偏差」：即人們在使用AI之後，對效果的主觀判斷如何偏離客觀現實。這才是真正有價值的測試方法。

所以，如果AI讓人「覺得自己更快」，卻「實際上更慢」，那麼其價值評估將被全面高估。

企業、教育機構、平台服務商，乃至政策製定者，都可能被誤導。

研究還暗示，AI工具的價值可能不是「提高效率」，而是「改造流程」。它改變了工作的節奏、重構了問題表達方式、干擾了注意力分配。

地址：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

本文來自微信公眾號「大數據文摘」，36氪經授權發佈。