[討論] 2025初的AI工具實際上會降生產力
看板: Soft_Job
作者: oopFoo (3d)
標題: [討論] 2025初的AI工具實際上會降生產力
時間: Fri Jul 11 15:04:05 2025
https://secondthoughts.ai/p/ai-coding-slowdown
ycombinator 的討論
https://news.ycombinator.com/item?id=44526912其實都是討論這篇，"衡量 2025 年初人工智慧對經驗豐富的開源開發人員生產力的影響 "。
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ycombinator 的討論
https://news.ycombinator.com/item?id=44522772full paper
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
看討論，蠻有趣，各種理由解釋或不信。
但這研究還蠻紮實的。16個人，246個任務。
很有趣的是，每個人都預估生產力有增加，包含開發者本身。開發者寫完後還是認為生產力有增加，但實際生產力是下降的。
個人是ai是有幫助的，但真的限定在某些非常特定情況。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.224.192.162 (臺灣) ※ 文章網址 ※ ※ 編輯: oopFoo (36.224.192.162 臺灣), 07/11/2025 15:05:56
推
NDark :
我覺得體感會聲稱增加生產力。
07/11 16:25
→
NDark :
來自於好像變輕鬆，不用動腦細胞，去刁那一個邏輯符號
07/11 16:27
→
NDark :
但有一情況是，速度快了之後剩下來的是更多的閒置時間
07/11 16:28
→
NDark :
或是更多的推倒重來的次數
07/11 16:28
→
NDark :
遊戲產業發生過工具革新，結果都是更高更大更久的案子
07/11 16:30
→
NDark :
因為工具越強大，越輕鬆，規劃的人反而越放鬆。
07/11 16:31
→
NDark :
如果應用在對於新創，本來就是不斷pivot轉向是好事。
07/11 16:32
推
NDark :
應用在一些大型案子難找的臭蟲也應該很有幫助
07/11 16:34
→
NDark :
但大多數的“一般”狀況，反覆消耗的時間可能剛好抵銷加速
07/11 16:35
推
NDark :
最後推論還是大PM全端時代，不只是工程師進化，而是連帶需
07/11 16:40
→
NDark :
求端的人都得改變工作模式。
07/11 16:40
→
oopFoo :
應該是，人都是樂觀的，所以我們評估都是樂觀的。看到ai
07/11 16:51
→
oopFoo :
產出程式碼，我們就覺得很有生產力。但實際解決任務的時間
07/11 16:51
→
oopFoo :
，就整體開發時間，其實不但沒變短反而變長。
07/11 16:52
→
oopFoo :
就我個人不科學的觀察，整體來講ai真的是幫倒忙。兩，三
07/11 16:55
→
oopFoo :
年的實驗經驗下來，對ai短期能夠大突破，沒有信心。
07/11 16:56
推
NDark :
一種猜測是，瓶頸不在生產就會跑到其他地方，結果還是卡在
07/11 17:00
→
NDark :
某個地方。（某個環節沒有一起更新，整體還是快不起來）
07/11 17:00
→
NDark :
大PM全端，腦機介面賽博飛升，選我正解
07/11 17:02
推
wei115 :
和AI一起搞半天，什麼都搞不出來，一怒之下自己寫，結果
07/11 17:19
→
wei115 :
一小時就完成惹
07/11 17:19
推
jack529 :
會不會其實根本不會用？或是沒用過無上限Claude
Code
07/11 18:08
→
FrAnKw :
我也覺得是不會用。Claude
code
真的很強
07/11 18:27
推
sunsamy :
樓上的圖是真實使用經驗,
目前對程式領域來講會浪費時間
07/11 18:41
推
Ekmund :
我覺得這跟prompt技巧和專案多大有很大關係
07/11 19:00
→
Ekmund :
有時得把東西講得詳細
再帶商務邏輯下去慢慢雕code
07/11 19:00
→
Ekmund :
可能
直接寫比較快...
07/11 19:00
→
oopFoo :
參與的人，prompt水準都很高。有的人cursor經驗很少，但
07/11 20:53
→
oopFoo :
screencast都有留下來研判，這不是問題。其實問題就是，需
07/11 21:00
→
oopFoo :
要一直reprompt，花太多時間在這。
07/11 21:02
→
oopFoo :
code複雜時，失敗率高。其實paper講很多，有興趣可以判讀
07/11 21:05
→
twistfist :
覺得這是做研究硬用吧，一般開發哪那麼頭鐵跟ai
耗
07/11 21:30
→
VL1003 :
看人，懂用
AI
的，會知道哪部份可以丟給
AI
處理效率更高
07/11 23:43
→
VL1003 :
，但一定有那種什麼東西都餵
AI，這也就算了，出來的東西
07/11 23:44
→
VL1003 :
還不驗證就想拿來用...
後面收尾就浪費一堆時間。
07/11 23:44
→
superpandal :
當然會
我不發表其它言論就是了
07/12 00:42
→
VScode :
同VL大看法
要知道AI的優勢跟劣勢
盡量擅用AI的優點
07/12 00:58
→
VScode :
讓它做一些重覆的無聊雜事
把時間拿來思考規劃
07/12 00:59
→
VScode :
如果什麼都要讓AI思考
那很容易只會得到一坨大便
07/12 00:59
→
dildoe :
如果IT越變越懶還是外包,歪包都大頭說的算確實perf沒多好
07/12 03:56
→
dildoe :
AI又不見得會幫你拆解問題跟做實驗
說能全取代是記者說的
07/12 03:58
→
dildoe :
有問題請去問記者
07/12 03:58
推
windmagic :
最近才經歷一個bug丟AI解不出來，但手動debug後20分鐘
07/12 05:28
→
windmagic :
就發現問題
07/12 05:28
推
devilkool :
我給AI產單元測試省我不少時間
07/12 23:29
推
acgotaku :
用了一陣子
roo
code
上
claude
4.5
→
acgotaku :
才是
AI
開發流的唯一解
但是實在是太貴了
07/12 23:48
→
acgotaku :
Cursor
用
Claude
到限流才會去使用
07/12 23:49
→
acgotaku :
Cursor
預設的128
k
token
對於中小專案還堪用
07/12 23:51
→
acgotaku :
大專案
+
非
Claude
的model
會改出一些很奇怪的東西
07/12 23:52
→
acgotaku :
用
AI
開發流，要一直在成本跟效能之間找平衡
07/12 23:56
推
lance70176 :
我覺得應該用今年五月開始的AI作為一個標準。
07/13 06:04
→
lance70176 :
那個時間點從開始每一家都進步非常多。
二三月時我給
07/13 06:04
→
lance70176 :
他開發不如自己寫
07/13 06:04
推
Romulus :
這個來源懷疑他們不會用……就……
07/13 06:27
→
oopFoo :
當初的期待是2x~20x的生產力，今天最好的狀況是1.1x甚至
07/13 08:10
→
oopFoo :
倒退。讓agent自己在我電腦胡搞，這個紅線我踩的很死，NO
07/13 08:12
→
oopFoo :
prompt，context
engineering，各種best
practices都試了
07/13 08:14
→
oopFoo :
這兩年，所謂的突破，我是沒看到，有進步，但實在有限，最
07/13 08:15
→
oopFoo :
大的進步是context
window大很多真的是比較好做事。
07/13 08:17
推
CRPKT :
其實每種專案領域適用
AI
的程度也不一樣
07/13 09:00
→
CRPKT :
有些部分我會用
AI，有些部分直接跳過
07/13 09:01
→
CRPKT :
對我來說自己肉身生產力的瓶頸是認知負荷
07/13 09:02
→
CRPKT :
AI
幫我幹掉細節，我只需要
review，我當日的天花板就上升
07/13 09:03
→
CRPKT :
再來就是
AI
產出的內容總是要在某個地方
review
07/13 09:04
→
CRPKT :
如果你資深，看一眼就知道問題，那產出當下就
review
最好
07/13 09:05
→
CRPKT :
再往後退就是用其他手段
QA，也是有人這樣做
07/13 09:06
→
CRPKT :
但要守得好也是要花很多心力建置測試體系
07/13 09:06
→
CRPKT :
如果都不
review
就是埋地雷，等它哪天炸給你看
07/13 09:07
推
CRPKT :
如果體感
AI
幫不上忙，那可能你工作內容真的
AI
扛不起來
07/13 09:09
→
CRPKT :
有聽過不少公司
AI
專門拿來寫
PoC
/
demo
的
07/13 09:10
推
NDark :
推
lance
,
我覺得也是進步迭代太快的緣故
07/13 10:51
→
NDark :
差一個月整個世界就不一樣
07/13 10:51
→
NDark :
很多公司都在拚下一個世代的開發方法
07/13 10:52
→
NDark :
而且生怕別人搶先
所以有甚麼料就趕快推出來搶市占了
07/13 10:52
推
alihue :
應該要細看：如果是複雜大系統，需求都沒有規格書，AI
對
07/13 10:54
→
alihue :
使用者下的promot
通常都在通靈
，AI
只能協助拼拼湊湊；
07/13 10:54
→
alihue :
如果是幾乎從0寫的，甚至有規格書，那AI
的幫助就會是倍
07/13 10:54
→
alihue :
數
07/13 10:54
推
O187 :
AI真能省時
但只能省簡單常寫的
07/13 11:33
→
O187 :
複雜到用文字難以形容的邏輯
我自己寫還快一點
07/13 11:33
推
hooll111 :
我覺得是大家還在摸索新的協作模式，現在都還是在現有的
07/13 13:20
→
hooll111 :
工作流程硬套AI
輔助
效率的枷鎖在人啊
07/13 13:20
推
TAKADO :
叫AI寫扣其實跟帶小開發團隊很像，下的指令與需求，會被怎
07/13 14:57
→
TAKADO :
麼解讀跟實作成跟規劃者預期的一樣，會是更優化，能夠一次
07/13 14:57
→
TAKADO :
到位還是得反覆調整，整個生產力差太多了。
07/13 14:57
推
lturtsamuel :
每個人都覺得自己很會用
ai，事實就是一堆人不會用，
07/13 20:13
→
lturtsamuel :
反而靠ai製造技術債的速度提升了好幾倍，你少數人再
07/13 20:14
→
lturtsamuel :
厲害根本解不掉
07/13 20:14
推
lturtsamuel :
ai現在最大的問題就是學不會偷懶
對它來說改十行跟改
07/13 20:18
→
lturtsamuel :
一行差不多
加上一段其實沒用處的
code
也差不多
人
07/13 20:18
→
lturtsamuel :
不把關整個程式庫的複雜度就不斷上升
07/13 20:18
→
acgotaku :
其實樓上這問題,也可以叫
AI
解決,
用
AI
去清理純人工
07/14 02:26
→
acgotaku :
舊專案,那種"前人做的就不要動"的
code
還更多
07/14 02:27
推
Boska :
光不用再寫測試跟文件爽到有剩
07/14 03:20
→
greenx :
ai還在進步
07/14 09:40
→
jen1121 :
目前把ai當提示符號比較妥當，當解決方式會被牽著鼻子走
07/24 23:46