為什麼AI輔助開發比想象中更令人疲憊

AI輔助開發的承諾是讓開發者的工作變得更輕鬆。某種程度上確實如此，但許多開發者卻在經歷後LLM時代的倦怠和疲憊。這在一定程度上源於組織不切實際的期望——它們被AI炒作和錯失恐懼症衝昏了頭腦。然而，還有一個更深層的問題，根植於人機互動（HCI）心理學。

從HCI視角看使用者行為，我們會想到“模式”。模式不僅是介面的狀態，更是使用者的狀態。想象一下使用專案管理應用的人：瀏覽看板時處於閱讀模式，建立任務時處於輸入模式，審查隊友任務時處於評估模式。同一應用，同一螢幕，卻對應三種不同的認知狀態。每種狀態動用不同的心智資源，在不同模式間切換正是讓工作感覺多樣而不是單調的原因。

軟體開發歷來也存在這類模式：規劃、實施和整合。規劃是最耗認知的模式，需要同時考慮多個因素、權衡取捨並做出影響後續所有步驟的決策。實施是將解決方案變為現實的過程，寫程式碼、除錯、測試——它提供了一個認知重置的機會。在規劃的壓力之後，投入構建的流程中，透過頻繁的小成功積累動力。整合則是質量控制，包括程式碼審查和合並，它提供了認知反饋和自我反思的空間。

AI輔助開發不僅改變了開發者在每種模式上花費的時間比例，還改變了模式本身的性質和壓力。規劃：由於AI能在幾分鐘內實現功能，組織期望更多產出，導致規劃量激增。開發者被迫以前所未有的速度進行最耗認知的工作，無法透過模式轉換得到休息。實施：構建的心流被壓縮為“提示、等待、審查”。提示本身是一種規劃，等待是死時間，審查是整合。真正的構建被AI取代，留下的只是監督，這無法提供同樣的恢復性收益。整合：審查AI程式碼失去了反思性，因為那不是你的工作。從他人審查中學習的機會也減少了，因為AI程式碼沒有意圖。整合變成了審計而非對話，開發者花在整合上的時間比以往更多，造成了瓶頸壓力。

最終，開發者剩下大約一個半模式：規劃和整合都被放大和扭曲，實施被自動化壓縮。這種“單一模式倦怠”表現為持續在最高要求的模式下工作，缺乏恢復和反思。長期影響有三方面：技能（透過構建學習的機會減少）、動力（自然工作節奏的破壞導致疲勞和冷漠）和質量（驗證沒有構建背景變得更困難且不可靠，容易遺漏問題）。

我們需要有意識地重建認知基礎設施。也許開發者應該為自己保留某些實施工作，不是因為AI做不了，而是需要認知收益。團隊需要重新思考健康的工作流程，保護實施時間，並將AI程式碼積壓視為需要關注的訊號。關鍵在於承認問題：如果你感覺工作更累了，即使效率更高，這並非想象。AI輔助開發可以比我們以為的更令人疲憊。透過教育、創新和指導，我們可以建立更好的基礎設施，但首先行業必須正視這個問題。