PTT職涯區 / Soft_Job (軟體人)

[討論] 2025初的AI程式工具實際上會降生產力

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