AI 生產力的隱形成本：應對 AI 倦怠的興起
AI 生產力的隱形成本：應對 AI 倦怠的興起
AI 輔助工程的承諾很簡單：機器處理乏味的部份，讓人類專注於軟體開發中具備創意且有成就感的面向。然而，隨著這些工具變得無處不在，一個不同的現實正在浮現。工程師並非工作量減少，反而發現自己工作得更努力、更快，且感到比以往任何時更加疲憊。
這種被稱為「AI 倦怠」的現象，不僅僅是關於工作量的大小；它關乎工作認知性質的根本轉變。當我們從「編寫」程式碼轉向「審查」AI 生成的程式碼時，我們是用一種沉思、具備創意的過程，去換取一個高強度的監督角色。
生產力陷阱：為什麼更快並不代表更容易
表面上看，AI 提高了效率。使用 LLM 的工程師可能在兩小時內完成原本手動編碼需要四小時的任務。然而，這兩小時的「強度」顯著更高。
手動編碼通常是一場「受控的馬拉松」。它涉及分散式的智力投入——規劃、打字、重新思考架構，以及增量測試。相比之下，AI 輔助編碼是一場高強度的認知鍛鍊。工程師將時間花在提示、引導與除錯 AI 的輸出——這些任務需要持續且警覺的監督。
這創造了一個危險的循環：
- 增加強度： 每小時工作的心理負荷增加。
- 缺乏成就感： 因為任務「完成得很輕鬆」（儘管存在認知壓力），工程師不會感到同樣的完成感或所有權感。
- 數量螺旋： 為了補償缺乏成就感，工程師通常會立即投入下一個任務，實際上在相同的時間範圍內將工作量翻倍或翻了三倍。
工藝與情境的侵蝕
除了即時的疲勞之外，以 AI 為主的流程正在改變軟體工程師的專業身份。
失去直覺
當代理（agent）處理實作時，工程師不再需要將專案的架構與邊緣案例（edge cases）記在腦海中。這種情境的「提取」意味著透過沉浸所建立的直覺——在錯誤發生前發現 Bug 或識別出會導致技術債的捷徑的能力——正在慢慢被侵蝕。正如一位社群成員所言：「編寫程式碼很慢，但你會理解你所建立的東西。審查 AI 程式碼很快，但你正在累積盲點。」
被動思考的消亡
傳統的問題解決依賴於大量的潛意識處理——那些在散步或洗澡時發生的「啊哈！」時刻。AI 將規劃階段壓縮成與模型之間快速的來回互動。透過在人類還沒來機會將各點連結起來之前就填補了沉默，AI 經常導致非最佳的決策，而這些決策之後必須重新處理，進而增加了挫折感與疲勞感。
審查瓶頸
AI 可以在幾秒鐘內生成數千行程式碼，但人類審查這些程式碼的能力是恆定的。這創造了一個巨大的瓶頸，通常將不成比例的風險與認知負荷推向資深工程師，他們必須在平庸且由 AI 生成的貢獻浪潮中維持系統的穩定性。
永續 AI 工作流程的策略
為了避免倦怠，工程師必須有意識地遠離「在每一刻都極大化生產力」的心態。目標是在利用工具力量的同時，恢復對工藝的樂趣。
1. 奪回你的工藝
- 保護「工藝時段」： 投入特定的時間或任務，禁止使用 AI。利用這些窗口重新連結與編碼這種觸感良好、安靜的過程。
- 避免在熱情專案中使用 AI： 將個人專案作為手動編碼的避風港，以維持你的技能與對過程的熱愛。
- 使用「詢問」模式： 使用 LLM 進行導航與建議，而非實作。讓 AI 成為顧問，而非作者。
2. 優化工作流程
規劃更多，審查更少： 在生成任何一行程式碼之前，花更多時間在規劃階段以確保邏輯正確。這可以減少「提示-失敗-重複」這種令人疲憊的循環。
拆解任務： 抵制生成大量程式碼塊的衝動。將任務拆解成較小、可測試的片段，可以減少審查過程的心理負荷。
避免並行處理： 不要同時承接多個 AI 密集型任務。生成的便利性會創造一種虛假的容量感，導致心理壓力。
3. 建立硬性邊界
- 記錄時數與設定限制： 因為 AI 可以讓工作感覺像是一場衝刺，很容易迷失時間。設定嚴格的工作時數，即使你正處於功能開發的中途，也要停止工作。
- 承認成就： 記錄「勝利日誌」並展示你的成果。既然 AI 可能會削弱所有權感，你必須有意識地提醒自己，你在引導工具達成成功結果中所提供的價值。
結論：職業的演進
軟體工程是正在經歷一場「無聲的職業變革」。角色正在從建造者（craftsman）轉向編排者（orchestrator）。雖然這種轉變是不可避免的，但它不一定要讓人精疲力竭。
透過將 AI 作為協作者而非思考的替代品，並透過優先考慮心理健康而非原始產出，工程師可以應對這場轉變，而不會失去對領域的熱情或好奇心。隨著產業演進，最有價值的技能將不再是生成最多程式碼的能力，本身，而是確保程式碼正確、永續且具備意義的能力，以及維持判斷力、直覺與能量的能力。