【科技實測】2025 最新研究:AI 編程工具翻車?資深開發者用 Claude + Cursor 效率竟下滑 19%

AI 編程工具翻車實測!METR 發現資深開發者用 Claude + Cursor 反而效率下滑 19%,結果與預期大逆轉。

【科技實測】2025 最新研究:AI 編程工具翻車?資深開發者用 Claude + Cursor 效率竟下滑 19%

METR 在 2025 年 7 月 10 日發布了一份話題性十足的研究報告——Measuring the Impact of Early‑2025 AI on Experienced Open‑Source Developer Productivity》,這是目前最接近「真實使用情境」的 AI 工具實測之一,參與者全是 GitHub 星數爆表、程式碼貢獻數以百萬計的開源大神。

結果卻狠狠顛覆大家的期待。

使用 AI 開發時間反而變慢

核心發現

  • 對象:16 位資深開源開發者(平均貢獻 22k+ star、程式碼行數達數百萬行),各自挑選 246 個真實 issue,平均每人處理約 15 個任務,隨機分配為「可用 AI 協助」或「不可用」兩組。
  • 結果:使用 AI(以 Cursor Pro 搭配 Claude 3.5/3.7 為主)反而使完成時間 延長 19%,效果與開發者原先預期(縮短 24%)完全相悖。即使實際延長,開發者仍誤以為自己變快了 20%。

為何會變慢?

研究指出以下幾個主

1. 審查時間增加:AI 建議「大致正確」,但需額外修改與確認,反而拖慢節奏。

2. 高熟悉度反作用:參與者都非常熟悉手上的程式庫,真人勝過 AI 的即時生成。

3. 學習曲線:多位開發者首次使用 Cursor,缺乏足夠熟練度。唯一有超過 50 小時 Cursor 經驗者,反而獲得速度提昇

4. 心理錯覺:搭配 AI 做事更輕鬆,但並不代表更快,這種「感覺快」的認知偏差也被大規模自我報告所掩蓋

社群觀點摘錄

來自 Reddit、Hacker News 等開發者社群的直接摘錄如下:

“Developers thought they were 20% faster with AI tools, but they were actually 19% slower…” (Reddit)

「開發者原以為用 AI 工具會讓自己快 20%,結果實際上竟然慢了 19%……」

“A quarter of the participants saw increased performance, 3/4 saw reduced performance... positive speedup for the one developer who has more than 50 hours of Cursor experience.” (Hacker News)

「只有四分之一的參與者表現有提升,四分之三的效率反而下降……唯一提升效率的,是那位使用 Cursor 超過 50 小時的開發者。」

“The big attention grabbing statistics is that Developers expected AI to make them 20% faster and it actually made them 20% slower... the AI was not as proficient as a highly proficient human doing a complex task they are familiar with.” (Reddit)

「最吸睛的數據就是:開發者原本預期 AI 會讓他們變快 20%,結果實際上卻讓他們慢了 20%……AI 還是比不上熟練開發者處理自己熟悉任務的能力。」

對於 AI 開發工具的啟示

對資深/熟悉領域的開發者

目前的 AI 編碼工具對於高度熟悉的任務,短期內不僅沒有助速,反而拖慢進度這與 benchmark 測試的結果大相逕庭。

對新手或非熟悉領域者

先前研究指出:AI 在熟悉度低的任務或 junior 開發者中,仍有機會提升效率

心智預期與實際速度差距

開發者容易產生認知偏誤,誤以為工具提升效率,但實際效果相反,這提醒我們在衡量 AI 成效時必須有客觀數據佐證,而非依據主觀感受。

長期趨勢觀察

METR 表示將延續此研究模式,隨 AI 工具的快速進化,持續追蹤影響力。

結論建議

  1. 不論是企業還是開源專案,在 AI 工具導入初期應設計客觀的效果衡量機制,而非單靠印象或自評。
  2. 有素材的開發者:若已有 Cursor 類 AI 工具使用經驗,可能取得效率優勢。建議投入 >50 小時正式導入流程前先做內部熟練與實驗。
  3. 新手或跨領域場景:AI 工具可加速學習與定位問題,但也需要評估對複雜任務的支持程度。
  4. 工具開發者:需要優化 AI 建議的精準性,減少開發者額外審查與修正成本。

此份研究在目前是對 AI 編碼工具在真實且高度熟悉環境中的首次 RCT 實驗,提供相當關鍵的反思與方向。

如果你喜歡我們提供的資訊,記得訂閱下方AI郵報電子報,每周必知5件AI大事絕不錯過!!

Source

Read more

【PwC Insight Hub】從限電停工到數智韌性:製造業如何用 AI 建立不被中斷的工廠?

【PwC Insight Hub】從限電停工到數智韌性:製造業如何用 AI 建立不被中斷的工廠?

2021 年 9 月 26 日晚上十點,新竹某電子廠的供應鏈主管收到一則訊息。 「昆山廠因為限電政策,明早六點起全面停工,復工時間未定。」 他盯著螢幕,第一時間想的不是「損失多少」,而是:「我有哪些料會斷?」手上有二十幾家上游供應商,十幾條產線同時在跑。有些物料是昆山獨家供應,有些雖有備援,但不確定是否能即時補上。更麻煩的是,他不知道這些料「現在在哪」——有些剛出貨、有些卡在倉庫、有些根本不知道生產了沒。 他打開 ERP 想查庫存,但畫面跳出來的是三天前的帳面數字。實際還有多少?夠撐幾天?哪些訂單會延遲?沒有人能給出答案。 他開始打電話。先是打給昆山供應商,沒人接。再打備援廠商,對方說「要查一下」,然後就是漫長等待。天快亮時,資料才逐一湊齊,而產線,已經開始缺料。 那一晚,台灣有數十位供應鏈主管在做著同樣的事。盯著通訊軟體、查貨況、發郵件、

為什麼 Google 敢向 NVIDIA 叫板?Ironwood TPU 開火,Nvidia 霸主地位首現裂痕

為什麼 Google 敢向 NVIDIA 叫板?Ironwood TPU 開火,Nvidia 霸主地位首現裂痕

Google Cloud 悄悄把 Ironwood TPU(第七代)切到 GA(General Availability),沒有大張旗鼓的 keynote,也沒有找一堆 KOL 排隊喊「mind blown」,就是默默地在控制台把價格表亮出來,然後把 9,216 顆晶片的 pod 直接掛網。這種「我做好了,你自己來玩」的態度,我給滿分。 Ironwood TPU * 單顆 Ironwood 比 Trillium 快 4.2 倍(FP8) * 單 pod 9,216 顆 → 42.5 ExaFLOPS * HBM 容量與頻寬直接翻倍