小編精選 - 技術文章翻譯 · 09月09日

AI 讓你變成更懶的開發者了嗎？老實說。

你有沒有曾經想過，這種 AI vibe coding 會不會讓我們變懶了？最近還有誰在刷 LeetCode 呢？😅

我注意到，接受答案比起思考要容易，差距小到單次 accept 幾乎感覺不出來，但累積起來還是很可觀。之所以難以察覺，其中一個原因是，它即使沒有真的更快，感覺上也更快。

但我後來開始覺得，「懶」這個擔憂是對的，只是指錯了地方。懶其實有兩種，只有其中一種才是問題。

這裡我想先補一點背景，因為這不是我原創的，我也不是靠自己想通才得到這個結論。

懶惰，是我們有編譯器的原因

Perl 的創始人 Larry Wall，曾把懶惰列在程式設計師三大美德的第一位，而他的定義正好說明了整件事：「不惜花大功夫來減少整體能源消耗的品質。」大功夫。好的懶，不是什麼都不做，而是把工作移到更好的地方；某種程度上，這也正是編譯器存在的原因（有人厭倦了手寫同樣的組合語言，於是合理地決定讓機器來做這部分），也是我們整天依賴的每一種抽象化，其實都是某個人用對方式實踐懶惰的結果。

把這種苦差事交給模型，並不是什麼新鮮事。我寫過一百次的設定、我其實寫得出來但更不想寫的 regex、我可以倒背如流的 Dockerfile、還有我每個專案一開始都長得一模一樣的測試樣板：我都懂，而且我只是單純不想再打一遍，對此我完全沒有任何愧疚感（老實說，我反而會更擔心那種到了 2026 年，還堅持原則上逐字手打一切的開發者，而團隊其他人都已經下班了）。這不是跳過思考，這是思考完成之後，跳過重複輸入。

另一種懶，跳過的是理解

第二種懶，則是把理解本身外包出去。模型把東西寫出來，它可以跑、測試也都綠燈、PR 也被合併了，但在那整條鏈上，現在多了一段沒有人能解釋、也沒有人能修的程式碼。這種懶是會付出代價的，不是今天，而是壞掉的那一天；當值班的人在凌晨 2 點打開那個檔案，發現一個沒有人敢保證正確的函式時，代價就來了。

我能想到最小的例子，故意舉個例子：假設模型寫了一個在註冊時驗證電子郵件地址的 regex。如果那段我本來寫得出來，但我選擇不寫，那是第一種懶；如果我根本寫不出來，而它現在卻成了決定誰能拿到帳號的東西，那就是第二種懶。兩種情況下，都是同一個 diff 裡同一行上的同一段 regex。審查者看不出差別，CI 也看不出差別。兩種懶唯一不同的地方，只在我的腦袋裡。

好吧，但這不就是以前的 Stack Overflow 複製貼上問題，只是剪貼簿速度更快了嗎？大致上是的。而我認為，這正是它更糟的原因。Stack Overflow 會逼我去找答案、讀一串陌生人為此爭論的討論串（有時被接受的答案其實是錯的，而更好的答案可能在下面三則留言、票數只有十分之一），然後再把它改造成適合我的程式。那種摩擦，其實在默默做工。可是現在，建議直接就出現在我的檔案裡，還已經幫我縮排好了，而它完全沒有要求被理解。