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