AI輔助開發的代價：認知疲勞

經過三個月的AI輔助開發，我的生產力達到了前所未有的高度，但我也經歷了意想不到的精神疲憊。效率提升是真實的，從草圖到工作原型只需數小時而非數天。然而，有一個隱藏的成本常被忽視：這些工具從根本上改變了程式設計的認知負荷。我不再因糾結於實現細節而感到疲勞，而是因持續在架構和設計層面操作而精疲力竭。事實證明，擁有一個不知疲倦的編碼夥伴會帶來一種新的倦怠。

傳統的程式設計疲勞源於對細節的持續關注：與語法鬥爭、除錯晦澀的錯誤、或重複的實現工作。AI工具消除了大部分此類摩擦，但取而代之的是更微妙、更耗神的設計層面的決策疲勞。當你能在以往實現一個解決方案的時間內原型化三種不同方案時，你便不斷地做出架構決策：這應該是服務嗎？庫？簡單指令碼？錯誤處理呢？資料持久化？每個決策都會衍生更多決策，而AI隨時準備實現你選擇的任何方案。

瓶頸從“我能構建這個嗎？”轉變為“我應該構建這個嗎？以及如何構建？”這是更加沉重的認知負荷，且積累速度遠超預期。我發現自己需要休息，不是因為被問題卡住，而是因為大腦在高抽象層次思考太久而感到疲倦。這就像對大腦最高階功能進行間歇訓練。

最令人震驚的變化是你迅速撞上基本設計決策的速度。傳統開發中，你在實現、測試和擴充套件時才會發現更多架構問題。你有時間思考其影響，因為編寫程式碼本身需要時間。而AI輔助下，你立即遇到這些障礙。實現速度如此之快，以至於你在沒有充分考慮之前就面臨資料模型、API設計和系統邊界等問題。但還有更深層的現象：當人類編寫程式碼時，我們在工作中思考架構，做出小的調整，邊編碼邊重構，將架構決策體現在實現過程中。AI並非如此，或者說它至少在輸出中不傳達這類思考。結果是程式碼雖然能工作，但感覺架構扁平，僅實現了你的要求，卻缺乏人類實現過程中自然發生的細緻設計改進。你不得不做更多顯式的架構思考來彌補缺失。

需要審查的程式碼量激增，但這還不是最難的。真正挑戰在於事後無法追問AI的推理邏輯。人類程式設計師做出奇怪選擇時，你可以詢問原因；而AI這樣做時，其推理隱藏在更大的變更集中。嘗試在決策後就具體問題詢問AI，只會得到阿諛奉承的道歉：“很抱歉，那是個糟糕的選擇，讓我修復它。”但我不想要道歉，我想了解導致該實現的權衡。這在程式碼審查中創造了前所未有的盲點：你審查的是“什麼”，卻沒有“為什麼”的上下文，這使得評估方法是否穩健或只是碰巧能工作變得更加困難。因此測試紀律變得至關重要。如果AI不測試自己的程式碼（通常除非你明確要求，否則不會），那麼你就在正確性上盲目飛行。如果除錯緊正確的測試本可捕捉的微妙問題，效率優勢會迅速消失。

適應不是僅僅更好地使用工具，而是培養持續進行高層次思考的新心智。大腦需要時間在這方面變得更強。我開始更刻意地休息，尤其是在重大設計轉變之間。我會離開電腦以清除自己的心智上下文。這與清除AI對話上下文並非巧合——人和AI的思維都會因攜帶過多資訊而變得混亂。另一種適應是將AI用作設計探索的思考夥伴，而不僅僅是實現工具。我不會直接要求“構建這個”，而是花更多時間提問：缺少什麼？之前有什麼做法？有哪些權衡？AI實際上很擅長這類分析，這有助於前瞻性地完成架構思考。

這種實踐類似於工作方式的其他重大轉變。版本控制系統普及時，我們需養成提交和分支的新習慣；測試框架成熟時，我們需內化編寫可測試程式碼的特定模式。AI輔助開發是另一根本性轉變，需要構建新習慣和心智模型。疲勞是真實的，但也是暫時的。像任何新工作方式一樣，它需要練習才能變得自然。奇怪的是，這種疲憊與對可能性的真正興奮並存。我正在構建更有趣的東西，探索更多方法，釋出更精緻的原型，但也學會了以以前不需要的方式調整節奏。

我們仍處於理解AI如何改變程式設計實際體驗的早期階段。生產力提升備受關注，但認知轉變同樣重要，需要成功駕馭。能夠茁壯成長的開發者將是那些認識到這些工具不僅改變你能構建的東西——它們還改變你對構建的思考方式的人。AI放大了你的最高層次思考，這極其強大，但在精神上也非常消耗，我們仍在學習如何管理。適應期是值得的，但不要低估學習曲線，尤其是發生在你大腦內部的部分。給你的大腦時間發展這些新肌肉。工具會等待。