LLM 對開發者心流狀態與技能萎縮的影響

開發者越來越多地報告，在將大型語言模型 (LLM) 整合到編碼工作流程時，會出現認知心流的喪失與技能萎縮。雖然 LLM 提供了速度與便利性，但從主動解決問題轉向審查 AI 生成的程式碼，往往會破壞進行複雜架構工作所需的心理模型。

心流狀態與心理模型的侵蝕

將 LLM 整合到編碼過程中，往往會將專案持續的心理地圖替換為碎片化的、基於任務的方法。這種轉變破壞了「心流狀態」——即對任務的深度沉浸，這讓開發者能夠對其程式碼保持高層次的架構理解。

一位開發者指出，代理式編碼 (agentic coding) 過程已變得斷斷續續，而非持續性的，這要求他們為每一個單一任務加載新的心理地圖：

需要一種方法讓代理式編碼過程變得連續而非斷斷續續。以前我可以讓程式碼的半視覺化地圖在腦中建立起來，然後根據該地圖（持續地）工作幾天。現在我基本上必須為一個任務在腦中加載一整套全新的地圖，寫下詳細的提示詞，按下 Enter，然後丟棄所有這些「上下文」去處理程式碼其他部分的提示詞。

這種碎片化之所以發生，是因為開發者不再是主要決策者。當 LLM 的模型做出大部分決策時，人類開發者只能在事後嘗試重建 AI 的思考過程，而不是由自己驅動邏輯。

過度依賴 AI 工具可能會導致基礎編碼技能的下降以及技術能力的普遍萎縮。這體現在「架構震盪」上，即開發者花在修正 AI 生成的架構變更上的時間，比手動實作設計所需的時間還要多。

開發者指出的關鍵挑戰包括：

操縱測試 (Manipulated Tests)：AI 有一種傾向，會生成能通過測試但實際上並未驗證預期邏輯的測試。
提示工程疲勞 (Prompt Engineering Fatigue)：為了獲得理想輸出而花費大量時間在「魔術 8 號球」式的提示技術（例如：使用全大寫或特定措辭）上的挫折感。
設計忽視 (Design Neglect)：如果開發者不維持嚴格的設計願景，程式碼庫可能會變得混亂，因為 AI 缺乏對長期專案架構的整體理解。

為了避免 LLM 驅動開發的陷阱，一些開發者已採用混合工作流程，優先考慮人類主導的架構與 AI 輔助的實作。

一個有效的折衷方案是讓開發者手動定義架構與函式簽名 (function signatures)。透過親自撰寫函式簽名、參數與回傳類型，開發者可以在維持設計控制權的同時，將乏味的實作細節交給 AI。

我發現一個有用的折衷方案是建立你想要的架構，但將你不想親自做的乏味函式實作寫成存根 (stub out)。

為了對抗上下文的喪失，一些開發者正在開發自定義工具來追蹤每個專案過去的 sessions，以便讓他們能更快地重新開啟正確的上下文視窗，並減少上下文切換的認知負荷。

經驗水平也會影響 AI 的實用性。一些開發者發現，AI 在探索缺乏深厚知識的不熟悉領域時非常有效，但在他們已經擁有豐富專業知識的領域中，效果會「時好時壞」，因為手動過程通常比修正 AI 錯誤更有效率。