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

看板Soft_Job (軟體人)作者 (3d)時間2周前 (2025/07/11 15:04), 2周前編輯推噓24(24073)
留言97則, 26人參與, 2周前最新討論串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, 2周前 , 1F
我覺得體感會聲稱增加生產力。
07/11 16:25, 1F

07/11 16:27, 2周前 , 2F
來自於好像變輕鬆,不用動腦細胞,去刁那一個邏輯符號
07/11 16:27, 2F

07/11 16:28, 2周前 , 3F
但有一情況是,速度快了之後剩下來的是更多的閒置時間
07/11 16:28, 3F

07/11 16:28, 2周前 , 4F
或是更多的推倒重來的次數
07/11 16:28, 4F

07/11 16:30, 2周前 , 5F
遊戲產業發生過工具革新,結果都是更高更大更久的案子
07/11 16:30, 5F

07/11 16:31, 2周前 , 6F
因為工具越強大,越輕鬆,規劃的人反而越放鬆。
07/11 16:31, 6F

07/11 16:32, 2周前 , 7F
如果應用在對於新創,本來就是不斷pivot轉向是好事。
07/11 16:32, 7F

07/11 16:34, 2周前 , 8F
應用在一些大型案子難找的臭蟲也應該很有幫助
07/11 16:34, 8F

07/11 16:35, 2周前 , 9F
但大多數的“一般”狀況,反覆消耗的時間可能剛好抵銷加速
07/11 16:35, 9F

07/11 16:40, 2周前 , 10F
最後推論還是大PM全端時代,不只是工程師進化,而是連帶需
07/11 16:40, 10F

07/11 16:40, 2周前 , 11F
求端的人都得改變工作模式。
07/11 16:40, 11F

07/11 16:51, 2周前 , 12F
應該是,人都是樂觀的,所以我們評估都是樂觀的。看到ai
07/11 16:51, 12F

07/11 16:51, 2周前 , 13F
產出程式碼,我們就覺得很有生產力。但實際解決任務的時間
07/11 16:51, 13F

07/11 16:52, 2周前 , 14F
,就整體開發時間,其實不但沒變短反而變長。
07/11 16:52, 14F

07/11 16:55, 2周前 , 15F
就我個人不科學的觀察,整體來講ai真的是幫倒忙。兩,三
07/11 16:55, 15F

07/11 16:56, 2周前 , 16F
年的實驗經驗下來,對ai短期能夠大突破,沒有信心。
07/11 16:56, 16F

07/11 17:00, 2周前 , 17F
一種猜測是,瓶頸不在生產就會跑到其他地方,結果還是卡在
07/11 17:00, 17F

07/11 17:00, 2周前 , 18F
某個地方。(某個環節沒有一起更新,整體還是快不起來)
07/11 17:00, 18F

07/11 17:02, 2周前 , 19F
大PM全端,腦機介面賽博飛升,選我正解
07/11 17:02, 19F

07/11 17:19, 2周前 , 20F
和AI一起搞半天,什麼都搞不出來,一怒之下自己寫,結果
07/11 17:19, 20F

07/11 17:19, 2周前 , 21F
一小時就完成惹
07/11 17:19, 21F

07/11 18:08, 2周前 , 22F
會不會其實根本不會用?或是沒用過無上限Claude Code
07/11 18:08, 22F

07/11 18:27, 2周前 , 23F
我也覺得是不會用。Claude code 真的很強
07/11 18:27, 23F

07/11 18:34, 2周前 , 24F

07/11 18:41, 2周前 , 25F
樓上的圖是真實使用經驗, 目前對程式領域來講會浪費時間
07/11 18:41, 25F

07/11 19:00, 2周前 , 26F
我覺得這跟prompt技巧和專案多大有很大關係
07/11 19:00, 26F

07/11 19:00, 2周前 , 27F
有時得把東西講得詳細 再帶商務邏輯下去慢慢雕code
07/11 19:00, 27F

07/11 19:00, 2周前 , 28F
可能 直接寫比較快...
07/11 19:00, 28F

07/11 20:53, 2周前 , 29F
參與的人,prompt水準都很高。有的人cursor經驗很少,但
07/11 20:53, 29F

07/11 21:00, 2周前 , 30F
screencast都有留下來研判,這不是問題。其實問題就是,需
07/11 21:00, 30F

07/11 21:02, 2周前 , 31F
要一直reprompt,花太多時間在這。
07/11 21:02, 31F

07/11 21:05, 2周前 , 32F
code複雜時,失敗率高。其實paper講很多,有興趣可以判讀
07/11 21:05, 32F

07/11 21:30, 2周前 , 33F
覺得這是做研究硬用吧,一般開發哪那麼頭鐵跟ai 耗
07/11 21:30, 33F

07/11 23:43, 2周前 , 34F
看人,懂用 AI 的,會知道哪部份可以丟給 AI 處理效率更高
07/11 23:43, 34F

07/11 23:44, 2周前 , 35F
,但一定有那種什麼東西都餵 AI,這也就算了,出來的東西
07/11 23:44, 35F

07/11 23:44, 2周前 , 36F
還不驗證就想拿來用... 後面收尾就浪費一堆時間。
07/11 23:44, 36F

07/12 00:42, 2周前 , 37F
當然會 我不發表其它言論就是了
07/12 00:42, 37F

07/12 00:58, 2周前 , 38F
同VL大看法 要知道AI的優勢跟劣勢 盡量擅用AI的優點
07/12 00:58, 38F

07/12 00:59, 2周前 , 39F
讓它做一些重覆的無聊雜事 把時間拿來思考規劃
07/12 00:59, 39F

07/12 00:59, 2周前 , 40F
如果什麼都要讓AI思考 那很容易只會得到一坨大便
07/12 00:59, 40F

07/12 03:56, 2周前 , 41F
如果IT越變越懶還是外包,歪包都大頭說的算確實perf沒多好
07/12 03:56, 41F

07/12 03:58, 2周前 , 42F
AI又不見得會幫你拆解問題跟做實驗 說能全取代是記者說的
07/12 03:58, 42F

07/12 03:58, 2周前 , 43F
有問題請去問記者
07/12 03:58, 43F

07/12 05:28, 2周前 , 44F
最近才經歷一個bug丟AI解不出來,但手動debug後20分鐘
07/12 05:28, 44F

07/12 05:28, 2周前 , 45F
就發現問題
07/12 05:28, 45F

07/12 23:29, 2周前 , 46F
我給AI產單元測試省我不少時間
07/12 23:29, 46F

07/12 23:47, 2周前 , 47F
用了一陣子 roo code 上 claude 4.5 真心覺得 Claude
07/12 23:47, 47F

07/12 23:48, 2周前 , 48F
才是 AI 開發流的唯一解 但是實在是太貴了
07/12 23:48, 48F

07/12 23:49, 2周前 , 49F
Cursor 用 Claude 到限流才會去使用
07/12 23:49, 49F

07/12 23:51, 2周前 , 50F
Cursor 預設的128 k token 對於中小專案還堪用
07/12 23:51, 50F

07/12 23:52, 2周前 , 51F
大專案 + 非 Claude 的model 會改出一些很奇怪的東西
07/12 23:52, 51F

07/12 23:56, 2周前 , 52F
用 AI 開發流,要一直在成本跟效能之間找平衡
07/12 23:56, 52F

07/13 06:04, 2周前 , 53F
我覺得應該用今年五月開始的AI作為一個標準。
07/13 06:04, 53F

07/13 06:04, 2周前 , 54F
那個時間點從開始每一家都進步非常多。 二三月時我給
07/13 06:04, 54F

07/13 06:04, 2周前 , 55F
他開發不如自己寫
07/13 06:04, 55F

07/13 06:27, 2周前 , 56F
這個來源懷疑他們不會用……就……
07/13 06:27, 56F

07/13 08:10, 2周前 , 57F
當初的期待是2x~20x的生產力,今天最好的狀況是1.1x甚至
07/13 08:10, 57F

07/13 08:12, 2周前 , 58F
倒退。讓agent自己在我電腦胡搞,這個紅線我踩的很死,NO
07/13 08:12, 58F

07/13 08:14, 2周前 , 59F
prompt,context engineering,各種best practices都試了
07/13 08:14, 59F

07/13 08:15, 2周前 , 60F
這兩年,所謂的突破,我是沒看到,有進步,但實在有限,最
07/13 08:15, 60F

07/13 08:17, 2周前 , 61F
大的進步是context window大很多真的是比較好做事。
07/13 08:17, 61F

07/13 09:00, 2周前 , 62F
其實每種專案領域適用 AI 的程度也不一樣
07/13 09:00, 62F

07/13 09:01, 2周前 , 63F
有些部分我會用 AI,有些部分直接跳過
07/13 09:01, 63F

07/13 09:02, 2周前 , 64F
對我來說自己肉身生產力的瓶頸是認知負荷
07/13 09:02, 64F

07/13 09:03, 2周前 , 65F
AI 幫我幹掉細節,我只需要 review,我當日的天花板就上升
07/13 09:03, 65F

07/13 09:04, 2周前 , 66F
再來就是 AI 產出的內容總是要在某個地方 review
07/13 09:04, 66F

07/13 09:05, 2周前 , 67F
如果你資深,看一眼就知道問題,那產出當下就 review 最好
07/13 09:05, 67F

07/13 09:06, 2周前 , 68F
再往後退就是用其他手段 QA,也是有人這樣做
07/13 09:06, 68F

07/13 09:06, 2周前 , 69F
但要守得好也是要花很多心力建置測試體系
07/13 09:06, 69F

07/13 09:07, 2周前 , 70F
如果都不 review 就是埋地雷,等它哪天炸給你看
07/13 09:07, 70F

07/13 09:09, 2周前 , 71F
如果體感 AI 幫不上忙,那可能你工作內容真的 AI 扛不起來
07/13 09:09, 71F

07/13 09:10, 2周前 , 72F
有聽過不少公司 AI 專門拿來寫 PoC / demo 的
07/13 09:10, 72F

07/13 10:51, 2周前 , 73F
推 lance , 我覺得也是進步迭代太快的緣故
07/13 10:51, 73F

07/13 10:51, 2周前 , 74F
差一個月整個世界就不一樣
07/13 10:51, 74F

07/13 10:52, 2周前 , 75F
很多公司都在拚下一個世代的開發方法
07/13 10:52, 75F

07/13 10:52, 2周前 , 76F
而且生怕別人搶先 所以有甚麼料就趕快推出來搶市占了
07/13 10:52, 76F

07/13 10:54, 2周前 , 77F
應該要細看:如果是複雜大系統,需求都沒有規格書,AI 對
07/13 10:54, 77F

07/13 10:54, 2周前 , 78F
使用者下的promot 通常都在通靈 ,AI 只能協助拼拼湊湊;
07/13 10:54, 78F

07/13 10:54, 2周前 , 79F
如果是幾乎從0寫的,甚至有規格書,那AI 的幫助就會是倍
07/13 10:54, 79F

07/13 10:54, 2周前 , 80F
07/13 10:54, 80F

07/13 11:33, 2周前 , 81F
AI真能省時 但只能省簡單常寫的
07/13 11:33, 81F

07/13 11:33, 2周前 , 82F
複雜到用文字難以形容的邏輯 我自己寫還快一點
07/13 11:33, 82F

07/13 13:20, 2周前 , 83F
我覺得是大家還在摸索新的協作模式,現在都還是在現有的
07/13 13:20, 83F

07/13 13:20, 2周前 , 84F
工作流程硬套AI 輔助 效率的枷鎖在人啊
07/13 13:20, 84F

07/13 14:57, 2周前 , 85F
叫AI寫扣其實跟帶小開發團隊很像,下的指令與需求,會被怎
07/13 14:57, 85F

07/13 14:57, 2周前 , 86F
麼解讀跟實作成跟規劃者預期的一樣,會是更優化,能夠一次
07/13 14:57, 86F

07/13 14:57, 2周前 , 87F
到位還是得反覆調整,整個生產力差太多了。
07/13 14:57, 87F

07/13 20:13, 2周前 , 88F
每個人都覺得自己很會用 ai,事實就是一堆人不會用,
07/13 20:13, 88F

07/13 20:14, 2周前 , 89F
反而靠ai製造技術債的速度提升了好幾倍,你少數人再
07/13 20:14, 89F

07/13 20:14, 2周前 , 90F
厲害根本解不掉
07/13 20:14, 90F

07/13 20:18, 2周前 , 91F
ai現在最大的問題就是學不會偷懶 對它來說改十行跟改
07/13 20:18, 91F

07/13 20:18, 2周前 , 92F
一行差不多 加上一段其實沒用處的 code 也差不多 人
07/13 20:18, 92F

07/13 20:18, 2周前 , 93F
不把關整個程式庫的複雜度就不斷上升
07/13 20:18, 93F

07/14 02:26, 2周前 , 94F
其實樓上這問題,也可以叫 AI 解決, 用 AI 去清理純人工
07/14 02:26, 94F

07/14 02:27, 2周前 , 95F
舊專案,那種"前人做的就不要動"的 code 還更多
07/14 02:27, 95F

07/14 03:20, 2周前 , 96F
光不用再寫測試跟文件爽到有剩
07/14 03:20, 96F

07/14 09:40, 2周前 , 97F
ai還在進步
07/14 09:40, 97F
文章代碼(AID): #1eSBTkWl (Soft_Job)
文章代碼(AID): #1eSBTkWl (Soft_Job)