在 LLM 時代保持程式設計的樂趣

大型語言模型 (LLM) 的興起為開發者帶來了一個悖論：雖然生產力可能提高，但程式設計的內在樂趣——即透過程式碼表達思想的過程——往往被審查 AI 生成的「垃圾內容」這一枯燥任務所取代。為了避免 AI 倦怠和技術能力的退化，開發者必須從 AI 代理的「肉身代理人」轉變為將 LLM 作為規劃和研究的高槓桿支援工具。

「氛圍編碼」(Vibe Coding) 的風險與技能退化

過度依賴 LLM 生成的程式碼會導致程式碼庫和程式設計師認知能力的雙重退化。當開發者停止編寫程式碼，轉而依賴代理程式生成整個檔案時，他們冒著創造「LLM 荒原」的風險——這些程式碼庫對人類來說難以閱讀，且只能由其他代理程式維護。

除了程式碼庫之外，人類付出的代價是技能退化。正如社群成員所指出的，當將架構小型專案或在程式語言中進行深度思考的能力外包給 LLM 時，這些能力可能會迅速消失。

「我親眼見過這種情況發生在自己身上，突然間我在規劃一個非常小的專案架構時遇到了困難……我意識到，當我向 Claude 詢問一堆想法，然後根據我的經驗選擇最好的那個時，我正在鍛鍊那項技能。我並沒有鍛鍊從零開始構思解決方案的技能。」 — @handle

可持續的工作流程：以人為本的 AI 輔助

為了保持專業成長和個人樂趣，最有效的工作流程是共同規劃，但獨立編碼。在這種模式下，LLM 處理附帶的、無聊的和高容量的工作，而人類保留對實作的掌控權。

1. 用於規劃和記錄的 LLM

不要要求 LLM「構建此功能」，而應將其用作自然語言的記錄工具。使用它來：

• 將領域專家的對話轉換為可執行的待辦事項清單。
• 將測試結果整理成結構化的缺陷修復計畫。
• 在 Markdown 檔案中追蹤規劃項目，以避免上下文視窗遺失。

關鍵規則： 永遠不要讓 LLM 做出關鍵的架構決策。當它到達決策點時，強迫它向你尋求指導。

2. 用於研究和探索的 LLM

使用代理程式來收集資訊，但不要將其結果視為絕對事實。AI 研究的目標是消除「讓我幫你 Google」(Let Me Google That For You) 的摩擦，而不是取代開發者對領域的理解。

• 要求代理程式提供資源連結。
• 透過詢問代理程式具體是哪項資源支援該主張來驗證奇怪的提議；這通常會觸發模型發現自己的幻覺。
• 與搜尋引擎並行研究，以確保你對該領域的理解與代理程式相當，甚至更好。

3. 人類作為主要編碼者

拒絕「先規劃，再讓代理程式編碼」的誘惑。相反，讓 LLM 研究程式碼庫、識別必要的編輯點並警告你潛在的陷阱，但由你親自編寫實際的程式碼。這種方法提供了幾個優點：

• 所有權： 你始終了解程式碼庫的確切狀態。
• 早期檢測： 你可以在實作階段就識別出糟糕的計畫，而不是在代理程式花了一小時生成一個有缺陷的解決方案之後才發現。
• 技能維護： 你可以持續磨練你的程式設計能力。

實施自動化審查週期

為了確保品質，任何 LLM 產出的成品（包括計畫）在沒有經過自動化審查週期之前都不應被接受。這模仿了生成對抗網路 (GAN)，其中「生成器」代理產生工作，「判別器」代理進行審查。

此週期特別適用於：

• 程式碼審查： 使用單獨的代理程式來尋找你自己手寫程式碼中的錯誤或遺漏。
• 計畫驗證： 使用審查代理程式來發現邏輯漏洞（例如，一個計畫在第 2 步需要一個函數，但直到第 7 步才編寫）。

管理技術與心理限制

處理 Token 耗盡

Token 限制應被視為服務中斷，而不是購買不足。為了防止工作陷入停滯，請維護一份切實可行的待辦事項清單，以便在離線時進行。這確保了當「技術封建領主」限制你的存取權限時，你仍然可以獨立地持續創造價值。

避免「LLM 亂碼」

過度消耗 LLM 生成的文字可能會在心理上造成消耗。為了保護心理健康，請限制對原始 LLM 輸出的消耗，並優先考慮人與人之間關於高層願景和架構討論的溝通。避免將完全生成的 PR 內容發送給同事，因為這是工具輸出，而非真正的溝通。

對專業未來的展望

社群討論揭示了開發者在看待程式設計自動化方面的深刻分歧：

• 業餘愛好者觀點： 有人認為程式設計正從一種職業轉變為一種愛好，類似於鐵匠或製琴師——在經濟上不切實際，但在個人層面上卻令人滿足。
• 效率觀點： 另一些人則認為，主要目標是解決業務問題，如果 LLM 加快了該過程，那麼敲擊鍵盤的「工藝」只是一種不必要的感性依戀。
• 混合觀點： 許多人透過使用小型、快速的模型來處理常規任務（例如建立具有特定不變量的領域類別），同時牢牢掌握架構控制權以避免「代理群」帶來的開銷，從而獲得了成功。