AI進(jìn)化成編程怪物后，這或許是很多程序員/科研人的日常。

但是，用了AI，寫代碼一定更快了嗎？

METR（Model Evaluation & Threat Research）研究發(fā)現(xiàn)，如果你夠強(qiáng)、對代碼庫夠熟悉，AI工具反而會給你拖后腿！

他們進(jìn)行了一系列嚴(yán)謹(jǐn)?shù)碾S機(jī)對照試驗(yàn)（RCT），結(jié)果驚人——

哪怕是寫過百萬行代碼的萬星repo大佬，使用AI工具時(shí)，干同樣的任務(wù)，也會多花「19%」的時(shí)間！

更令人「細(xì)思恐極」的是，開發(fā)者完全意識不到AI在拖他們的后腿！

實(shí)驗(yàn)前，他們平均預(yù)計(jì)AI能提升效率24%。

即便在明明白白看到「變慢」的實(shí)驗(yàn)結(jié)果后，他們還是認(rèn)為AI讓他們快了20%。

METR把所有的實(shí)驗(yàn)設(shè)計(jì)和結(jié)果都放在了論文中：

論文鏈接：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

這項(xiàng)研究是怎么顛覆我們對AI寫代碼的幻

想的？

「變快」是幻覺：AI讓開發(fā)者慢了19%

具體而言，METR把研究限制在了「資深開發(fā)者」和他們熟悉的「大型、成熟開源代碼庫」這個(gè)范圍里。

為了測量AI工具在現(xiàn)實(shí)中的開發(fā)影響，METR招募了16位長期活躍于大型開源項(xiàng)目的資深開發(fā)者。

「資深」二字可不是說說而已，他們?nèi)司?00萬+行代碼，維護(hù)的GitHub項(xiàng)目有22k+顆星。

這些開發(fā)者真刀真槍上陣，從他們?nèi)粘９ぷ髁髦惺占?46個(gè)真實(shí)有價(jià)值的問題。

這些問題包括bug修復(fù)、新功能開發(fā)和重構(gòu)任務(wù)等，大概長下面這樣??

METR將每個(gè)任務(wù)隨機(jī)分配「允許使用AI」或「不允許使用AI」的對照實(shí)驗(yàn)組中。

在「允許」組中，開發(fā)者可以使用任何AI工具（主要是Cursor Pro搭配Claude 3.5/3.7 Sonnet等前沿模型）。

在「不允許」組中，他們不得借助生成式AI。

實(shí)驗(yàn)選擇的每個(gè)任務(wù)平均耗時(shí)2小時(shí)。完成任務(wù)的同時(shí)，開發(fā)者需要錄屏，并自報(bào)所用總時(shí)間。

隨后，METR計(jì)算一個(gè)相對變化率，來衡量用不用AI的時(shí)間影響。

不過，開發(fā)者們也不白干活，METR按每小時(shí)150美元給他們付「工資」。

這筆高時(shí)薪開得很值，METR分析實(shí)驗(yàn)結(jié)果后發(fā)現(xiàn)了驚人的結(jié)論：

當(dāng)開發(fā)者可以使用AI工具時(shí)，他們完成任務(wù)的平均時(shí)間反而增長了19%！ 

而且，從下圖可以看出，使用AI寫代碼，全流程都被拖慢了！

這么明顯的變慢打破了所有人的預(yù)期。

更令人震驚的是，開發(fā)者完全感覺不到！

在實(shí)驗(yàn)前，他們預(yù)計(jì)AI能提升效率24%；但從下圖可以清晰看出，使用AI后，開發(fā)者用時(shí)顯著增加。

然而，即便在親身體驗(yàn)「變慢」后，他們?nèi)哉J(rèn)為AI「感覺上」讓他們快了20%！

不過，METR非常嚴(yán)謹(jǐn)，聲明實(shí)驗(yàn)僅研究特定開發(fā)者與項(xiàng)目，不代表整個(gè)軟件開發(fā)行業(yè)，更不能推廣到非軟件類任務(wù)（如法律、寫作、設(shè)計(jì)等）。

基準(zhǔn)測試、用戶體驗(yàn)，都錯(cuò)哪了？

為確保嚴(yán)謹(jǐn)，METR反復(fù)審查了自己的實(shí)驗(yàn)設(shè)計(jì)。

他們嚴(yán)格遵守實(shí)驗(yàn)分配規(guī)則，沒有在AI組更頻繁放棄難題，使用的AI也確實(shí)都是最強(qiáng)代碼模型。

并且，有AI和無AI組提交的PR（Push Request）質(zhì)量也沒什么大差別。

既然實(shí)驗(yàn)設(shè)計(jì)沒問題，那在AI寫代碼這件事上，為何benchmark和用戶體驗(yàn)都錯(cuò)了？

METR對實(shí)驗(yàn)結(jié)果進(jìn)行了進(jìn)一步的分析。

首先是更細(xì)粒度的思考過程分析：

細(xì)細(xì)看了這些大佬開發(fā)者的屏幕錄像后，METR發(fā)現(xiàn)，允許使用AI時(shí)，開發(fā)者在主動編碼以及搜索/閱讀信息上的時(shí)間減少了。

相對應(yīng)的，開發(fā)者將更多時(shí)間花在了與AI 交互（如編寫提示）、審查AI輸出的結(jié)果，以及「干等」上。

METR進(jìn)一步設(shè)想了20個(gè)可能導(dǎo)致變慢的因素，發(fā)現(xiàn)其中有5個(gè)可能對結(jié)果有顯著貢獻(xiàn)：

一方面，開發(fā)者對項(xiàng)目已經(jīng)非常熟悉，遠(yuǎn)超和團(tuán)隊(duì)沒有默契的AI；另一方面，他們對 AI 效能有點(diǎn)過度樂觀。

另外，項(xiàng)目本身也很復(fù)雜，導(dǎo)致AI寫得快但寫得爛，開發(fā)者還要花很多時(shí)間調(diào)試。

最后，METR發(fā)現(xiàn)，這項(xiàng)研究與此前觀點(diǎn)的矛盾似乎來源于任務(wù)的定義和區(qū)分。

對AI是否「能干活」這一問題，數(shù)據(jù)來源不同，得出的結(jié)論可能完全不同。

RCT實(shí)驗(yàn)聚焦的是「現(xiàn)實(shí)開發(fā)流程中是否真的更快」，基準(zhǔn)測試關(guān)心「模型在任務(wù)標(biāo)準(zhǔn)下能打幾分」，而用戶主要反饋「AI用起來爽不爽」的主觀感受。

換句話說，結(jié)論不一樣，是因?yàn)楸揪驮诨卮鸩煌瑔栴}。

關(guān)心的是「日常提效」，還是「攻堅(jiān)能力」，換換使用場景，答案可能完全不同。

每一種方法評估的都只是任務(wù)空間的子集，組合起來，或許才能客觀認(rèn)識AI編程的真實(shí)戰(zhàn)力。

上崗兩眼懵？AI編程不能只會刷分

METR的RCT實(shí)驗(yàn)提醒我們，別被AI基準(zhǔn)測試的高分嚇到了。

那些所謂的「智能體測評」「編程大賽」，看起來挺能打，實(shí)則可能離真實(shí)開發(fā)差得遠(yuǎn)。

在不需要背景、不需要理解上下文、不涉及實(shí)際部署的測試任務(wù)中訓(xùn)出來的AI，未必能趕上人類開發(fā)者的表現(xiàn)；

我們不能低估AI的能力，更不能過度樂觀，覺得AI能輕松接管開發(fā)。

未來，用戶對AI編程工具的期待不只是「刷分」。

我們想看的是，AI是否真的能把軟件開發(fā)推進(jìn)得更快、更好？

一旦AI真能做到這一點(diǎn)，那就意味著AI能夠「無限賦能」自身的進(jìn)化。

聽起來很酷，但也任重道遠(yuǎn)。

如何評估AI參與真實(shí)開發(fā)部署的能力？如何設(shè)立監(jiān)督護(hù)城河，保證項(xiàng)目安全？

METR打算繼續(xù)設(shè)計(jì)實(shí)驗(yàn)，觀察AI開發(fā)的真實(shí)實(shí)力。

他們表示，想要集結(jié)更多開發(fā)者、AI編程用戶的力量，一起繼續(xù)搞實(shí)驗(yàn)，看AI到底行不行。

不過，不管AI編程拖后腿的證據(jù)有多「實(shí)錘」，

研究中的大多數(shù)參與者，甚至研究作者本人，都并不介意被GPT之流拖一拖后腿。

面對一張白紙從零開始，或是對著一篇草稿進(jìn)行編輯，即使前者更快，大家想必也都會選擇后者。

畢竟，「奴役」AI寫代碼，雖然沒法更「快了」，但一定更「快樂」。