生產力陷阱──AI 編程的 70% 魔咒
這是我的「BlogBlog 同樂會 - 2026 年 4 月」的投稿文章。本月主題是「生產力」！
AI 編程的 70% 魔咒，就是說當你用 AI 寫的專案進行到一定程度，通常是七成左右，你想要再往前推進的時候會變得很困難。你會發現你的 AI 助手開始卡關，老是修好一個 bug 又冒出兩個新的問題，讓你覺得一直在原地打轉，甚至越改越糟。
70% 魔咒成因
這個問題在推特上由 Peter Yang 提出之後，Google 的 工程師 Addy Osmani 寫了一篇洋洋灑灑的文章 分析這個 70% 魔咒的成因。他說，一般使用者利用 AI 助手寫程式的步驟大概是：
- 想到個點子或是有份草稿
- 叫 AI 助手生成初版程式
- 得到一個能跑的版本後繼續迭代
這聽起來就是 Vibe Coding 的步驟嘛！
但是，如果你像 Addy Osmani 一樣好好地觀察一名資深軟件工程師是怎麼用 AI 助手的，你會發現他不會對 AI 助手的建議照單全收，而會不斷地：
- 重構 AI 產生的程式碼
- 補上各種 edge case 和 error handling
- 質疑架構是否合理
等等……
總之，資深軟件工程師會一直「引導」和「約束」AI 的輸出。
雖然 AI 確實加速了實作過程，但真正讓程式碼可維護、可擴展的，還是工程師本身的專業判斷。
當我們忽略掉這些關鍵步驟而直接接受 AI 給出的答案，就會寫出表面完整但經不起考驗的程式碼。
唉，我把遊戲《逐夢星程：前傳》 都做好了才看到這篇真知灼見，早點看到 70% 魔咒的話我就不幹做遊戲的辛苦差事了 不是，而是一開始會更小心地檢查遊戲架構的基礎部分，搞不好會省下一個星期的 Debug 時間啊。
生產力陷阱
一開始用 AI 的時候，只要描述需求，甚至抄個看起來很厲害的的 Prompt ，就能魔法般地生成一個看起來很像那麼一回事的原型。哇，那一行行程式碼冒出來的時候簡直覺得自己生產力 MAX！
但是，當你想要加個新功能，或者是修一個 小 bug，很容易就會陷入類似的循環：
- 試著修一個小 bug，問AI 怎麼修
- AI 給了一個看起來合理的修改建議
- 但是這個修改引發了其他問題
- 叫 AI 修這個新問題
- 結果又冒出兩個新問題
- 無限循環……
生產力頓時從 MAX 降到鬼打牆的程度。
最絕望的是，如果你看不懂這堆程式碼，那你根本拆解不出真正的問題成因。
如果你能看懂，那也要花上好多精力去「看懂別人寫的程式碼」，雖然說你本來就是為了逃避看程式碼才用 AI 的！最後，一開始省下來的時間全都花在這裡了（可能還要花更多時間）。
所以說血淚教訓就是，就算有了 AI ，想要真的提升生產力，還有更重要的程式的品質，軟體工程學反而變得更重要了。
「咻」一下就把甚麼都弄好的魔法，十二點鐘一到就會消失呢。