作者:
xephon 2025-07-16 09:11:00https://www.bnext.com.tw/article/83885/ai-productivity-drop
AI變豬隊友?資深軟體工程師用Cursor「工作效率降19%」:背後原因是?導入AI錯了嗎?
2025.07.15
資料來源:METR、路透社
責任編輯:李先泰
內文:
重點一:2025年初AI工具讓資深開源開發者生產力下降19%,顛覆普遍預期。
重點二:研究採用嚴謹隨機對照試驗(RCT),直接測量AI在真實軟體開發情境的影響。
重點三:研究結果與AI基準測試及開發者主觀經驗存在顯著差異,凸顯評估AI效益需多元視
角。
生成式AI近年有越來越「聰明」的趨勢,不少企業甚至因為導入AI而縮減組織人員規模。但
對於公司行號來說,真的只要「無腦導入AI」,就可以讓生產力大躍升嗎?答案可能沒這麼
簡單。
7月10日,一項由非營利研究機構METR(Model Evaluation & Threat Research)主導的研
究顯示,2025年初問世的AI工具,包括Cursor Pro與Claude 3.5/3.7 Sonnet等前沿模型,
實際應用於資深開源開發者日常開發工作時,非但未能提升生產力,反而導致效率平均下降
19%。
這份研究的隨機對照試驗(Randomized Controlled Trial, RCT)結果,狠狠打臉產業普遍
認為「AI將大幅加速軟體開發」的主流觀點。白話來說,就是強制相對資深的老手工程師使
用AI,反而可能拖累他們的工作速度。
https://i.meee.com.tw/f063wYI.jpg
Y軸代表「使用 AI 後的時間變化」。可以發現,當開發者實際使用 AI 工具(來完成任務
時,所需時間反而增加了 19%。
問題是,為什麼有如此反直覺的結果?是在使用AI的過程中,出了什麼差錯嗎?
拖累老手工程師的5大潛在原因
為深入分析AI工具對軟體開發生產力的實際影響,研究團隊招募了16位長期參與大型開源專
案(平均22,000顆GitHub星、百萬行程式碼)的資深開發者,針對246個專案真實議題(如
錯誤修復、功能開發、程式碼重構),隨機分配為「允許使用AI」與「禁止使用AI」兩組。
開發者可自由選擇AI工具(主要為Cursor Pro搭配Claude 3.5/3.7 Sonnet)。同時,開發
者在執行任務時全程錄影,並自行回報所需的總實作時間,並比較同一批開發者在「無AI輔
助」下完成任務的時間差異,並排除潛在實驗偏誤。
受試者在實驗前普遍認為,AI能讓他們加快24%進度,即使在實驗過後,仍普遍認為允許使
用AI可讓實作時間縮短20%。但研究數據卻顯示,實際上允許使用AI反而讓完成時間增加了1
9%。 也就是說,這些軟體工程老手在使用AI工具時,反而變慢了。
根據研究結果,這些老手「被AI拖累」的原因有以下五點:
1. AI工具使用流程增加額外步驟 :開發者在與AI互動、理解AI回應、驗證建議內容時,會
花費額外時間。
2. AI建議需反覆修正 :AI產生的程式碼或建議往往不完全符合專案需求,開發者需多次修
改、整合或重寫。
3. 高品質標準下AI表現有限 :在大型、成熟的開源專案中,對程式碼品質、測試、文件等
要求高,AI生成內容較難一次達標,需人工補足。
4. 隱含需求難以明確傳達給AI :專案中有許多隱性規範或背景知識,AI難以完全掌握,導
致開發者需花時間解釋或修正。
5. 學習與適應成本 :即使開發者已有AI工具經驗,仍需適應新工具或新工作流程,短期內
可能降低效率。
要說明的是,參與者雖有AI經驗,但其實多數僅使用Cursor數十小時經驗而已。 因此可以
說,有經驗老手若還不太熟悉使用AI編程工具如Cursor,在他們熟悉的領域內,其實不用AI
的效率反而更好。
因此可以說,現在企業普遍認為「導入AI必能提升生產力」的假設,其實有待商榷。
https://i.meee.com.tw/xX1Hjvg.jpg
研究顯示,對於自己越熟悉的問題,資深開發者的速度反而被 AI 拖得越慢。他們也回報說
,正是因為自己太有經驗,導致 AI 很難真正幫上忙。
結論:無腦導入AI可能弊大於利
總結來說,這項研究的最大發現是,即使已經是程式開發老手,光是嘗試使用所謂Vibe Cod
ing工具本身就一種全新的技能,這種與AI協作進行軟體開發的實作,相較以往是具顛覆性
的,企業主在導入相關AI工具時仍需考量團隊及專案得適切性,否則很可能只是搞的團隊人
仰馬翻,甚至錯估導入AI的成效,最可怕的是誤殺忠良,讓有能力的工程師被誤會「不懂AI
」。
但不要誤會了。這份研究是針對「老手工程師」對於「使用AI工具」的評估,因此無法代表
所有開發者或不同類型專案。同時,研究僅針對開發者在自己熟悉的專案中處理真實議題,
故結果也不適用於新手、跨領域協作或陌生專案等情境。
另外值得注意的是,部分開發者獲知實驗結果後反映,使用AI工具讓開發過程更有趣或更具
互動性,即使未提升效率,仍願意持續嘗試,為未來更強大的AI系統做準備。
看到這邊,還認為AI是效率萬靈藥嗎?如果是,你可能需要好好想想。
心得:
這篇研究蠻有趣的,不知道跟大家體感差多少
我朋友的公司是強力導入AI開發後
宣稱已達到工程師效率提升30%
但他們沒有把產品上市時間縮短30%
是用減少10%工程師跟多做20%事情來達成
具體怎麼算的可能只有高管知道了
或許對於資深工程師來說,寫code比寫prompt 更快吧,尤其這次實驗的是他們熟悉的專案
作者:
s8911090 (一腳踏出門外)
2025-07-16 09:45:00METR從名字看就不像會客觀研究的
作者:
fake01 (假面超人)
2025-07-16 09:49:00有感,工程師會使用AI來進行function的重構,會讓code變得較難閱讀,當在審視PR的時候,需要較多的時間來理解重構後的內容是否有達成需求以及範蓋邊界條件
以前資深RD只需要講個幾句沒重點的就有初階RD幫你通靈完成需求現在你需要鉅細靡遺的對著AI講出需求哪個比較快不用比吧?
資深工程師開課介紹各種AI用法的收入應該可以提升30%
作者: hobnob (hobnob) 2025-07-16 12:06:00
笑死,s說的通靈真的有感
作者:
ma721 (UndeadJ)
2025-07-16 13:07:00用幾十小時也叫老手
作者:
Ekmund (是一隻小叔)
2025-07-16 17:09:00不就前幾天oopFoo貼的?
作者:
neo5277 (I am an agent of chaos)
2025-07-16 17:37:00這些都是溝通問題啊.....
作者:
oopFoo (3d)
2025-07-16 17:50:00原因,理由都是推測。這個實驗重點是,每個參與人員,做完後,自我評估工作效率是+20%+,但實際是-19%。我不會說ai泡沫要破滅,但確實最近有點消風。
開課噱海囉 但免費資源很多啦 而且一直變變變 沒必要FOMO
作者:
gino0717 (gino0717)
2025-07-16 20:22:00覺得AI能做就跑去摸魚了 實際效率下降十九趴
作者:
NDark (溺於黑暗)
2025-07-16 20:46:00我覺得蠻多持平之聲都很中肯對於自己比較不擅長的領域AI會幫忙很大譬如說我不會寫宣傳文 AI可以幫我寫出情緒價值滿滿的文章對於我不熟的資訊類其他工作也表現得不錯因為我有基礎的知識知道該怎麼跟AI互動會得到最好結果但是對於我已經做了十年的工作 短時間很難直接套用AI就算改變工作方式套了AI產量變10倍這時候碰到非生產的其他瓶頸幾乎是100%如果不妥協硬推下去那一定是偷懶或是接案或是離職創業之路
作者:
bitcch (必可取)
2025-07-16 22:09:00![]()
" target="_blank" rel="noreferrer noopener nofollow">
![]()
AI在"抽象"方面表現不錯,像藝術跟唬爛表現不錯但是要求"精確"的事,如寫程式卻是"抽象"化了所以像code review沒意外的話也會蠻唬爛的除非本身就用Lint tool輸出的結果然後用LLM講述給你聽但那本身就是Lint tool的功勞, 不是AI的功勞
作者: lin80673 (supremas) 2025-07-17 00:54:00
有時候多問幾次LLM就開始產生幻覺,一直給我無效的Code
作者:
yueayase (scrya)
2025-07-17 02:00:00這樣老闆應該會火掉這些用AI效率變差的工程師吧?
大project需求要講精確太難了最好用就是臨時要寫個script或tool
作者: rereterry (rereterry) 2025-07-17 10:54:00
幫忙直接撰寫驗證部分其實滿有幫助的,瞬間幫你配置好好,直接複製貼上就行了,其他的,只能說還是容易唬爛,需要重複檢查
作者: jhjhs33504 ( ) 2025-07-17 18:56:00
大project需求要講精確的難度可能會比寫好rust還高喔~
作者:
acgotaku (otaku)
2025-07-17 19:00:00Cursor 想棄坑了 一直搞限速 降速 寧願去充值 Claude
作者:
xephon 2025-07-18 00:42:00需求叫PM寫
作者:
louner (louner)
2025-07-18 06:54:00用來寫一些單純但需要查查找找的snippet非常方便 大多一次就過 最起碼讓他寫再改而不是全部自己寫省了我不少精力上層想推只是裁員的藉口而已 但若真的能節省大量人力也不見得是壞事 因為創業門檻會降低就工作複雜程度來看 AI更能取代的應該是管理職 PM這類非IC類型工作 但沒人會灑錢資助這類研究 原因大家都知道
作者:
acgotaku (otaku)
2025-07-18 14:09:00cursor 在翻陳年老扣沒文件 叫他解釋某單元怎麼實作怎麼呼叫 他的回傳值長怎樣 給個範例 還是超級好用
作者:
NDark (溺於黑暗)
2025-07-18 17:06:00推樓上,老工程師的經驗說會受到挑戰
作者:
wulouise (在線上!=在電腦前)
2025-07-18 20:46:00cursor可以畫function內flow chart嗎?
作者: guanting886 (Guanting) 2025-07-18 21:31:00
現在ai 已經進步到你丟給他obfuscate過的code他還有辦法解回來了 看沒文件的程式碼應該他蠻會猜的 至少縮短你通靈時間
作者:
WWIII (東邪西毒)
2025-07-18 22:21:00一直寫需求就是pm的工作 當然不習慣
作者:
Romulus (Säubern Mode)
2025-07-19 01:16:00我最近才用Claude和Gemini Pro瘋狂通靈失敗 都在胡說八道這研究是以老手寫熟悉的前提 這邊現在AI價值不高是真的寫的人越不懂AI價值就越高 都懂了直接寫code就好找AI幹嘛
作者:
sowulo ( )
2025-07-19 20:03:00有時候一直反覆修正的時候都在想這個時間自己寫早就寫完了不過也確實人都不一定完全懂需求了 再多轉一手給AI勢必會再偏差更多 只能說還有一段路要走不管是人類如何使用AI或是AI本身
作者: xoyo (xoxox) 2025-07-19 21:18:00
現在的 AI 就是 Junior 甚至不到
作者:
Obama19 (^_^)
2025-07-19 23:20:00高手都改用claude code了 研究總是落後一步
假設原本開發工作100分鐘 使用 AI 可省 30分鐘但因為要做新的精美投影片 來宣稱 AI 加速的效果來回多花了半小時
每次跟AI講,你這個地方錯了,只會回:抱歉!您說的是對的,我再幫您...有夠狗腿
作者:
strlen (strlen)
2025-07-21 18:03:00很多人以為自己寫的code bug少喔 呵呵呵 是不是太看得起自己啊人類遲早要輸的 大神就少數 絕大多數工程師 又慢 又粗心bug滿天飛 寫測試唉唉叫 改個設計推拖拉 有沒有這種人?滿地都是 不要再騙自己了 你可能不是 但你同事呢 呵軟體最強的那幾間 通通都在推AI 你以為你是誰啊 笑死你公司的程式品質有那幾間巨頭好喔 說出來我笑笑同樣兩人份需求 要你帶一個一年以下的Jr跟給你無限次數的claude AI 想也知道哪個比較輕鬆 帶人多痛苦啊還工作效率降19%勒 不然來比 一個資深用AI 一個資深帶Jr來看看效率差多少結果帶Jr的 Jr也全都用AI寫給你 哈哈哈哈
jr 會學習啊 你公司差只找得到糞 jr 怪誰 不培育 jr等老鳥都退了公司產品直接關起來?如果真的追求極限效率 根據這篇的研究就是不要用ai也不要找jr 叫老鳥自幹
太難評量了,AI也是需要調教的,開箱即用結果真的爛
回wulouise:現在AI可以從spec生出mermaid語法 算嗎?
作者: qmailtw (愛八卦的主管滾遠點) 2025-08-09 13:12:00
我拿 cursor 當高級 grep. 結果是不是亂掰? 一看就知道。我基本上不用 ai 生 code, 但幫我讀 code 能省下不少時間。