透過手動重新輸入 LLM 生成的程式碼來防止認知債務

AI 輔助編碼中的認知債務問題

允許大型語言模型 (LLMs) 自動生成並將大量程式碼塊插入專案中，會造成「認知債務」——一種開發者不再從根本上理解其軟體是如何構建的狀態。雖然 AI 助手可以加速開發中的「無聊部分」，但從編寫程式碼轉變為僅僅審查 AI 生成的 pull requests，往往會導致深度理解力的喪失以及對系統碎片化的心理模型。

審查 AI 生成的程式碼通常是一個令人不滿意的過程，其特點是必須仔細研究過度防禦性、註釋不良或存在細微錯誤的邏輯。對於個人專案而言，創作的過程與結果同樣寶貴，這種從創作者到審查者的轉變，剝奪了開發的樂趣，並因產出作者無法完全理解的軟體而面臨專業失職的風險。

解決方案：手動重新輸入

為了對抗認知債務，Ankur Sethi 採用了一種工作流，禁止 LLM 直接修改專案檔案。相反，LLM 會在聊天介面中提出修改建議，然後由開發者手動將這些修改輸入到編輯器中。

實施策略

Sethi 使用特定的系統指令來強制執行此界限，以規範 AI agent 的行為：

我想要理解進入這個專案的每一行程式碼。除非我明確要求，否則絕不要創建、編輯、移動、重新命名或刪除專案檔案。相反，請在聊天中向我展示所有建議的修改，以便我可以手動輸入它們。

除非我明確要求該操作，否則不要執行會修改專案檔案、安裝依賴項或更改 repository 狀態的命令。相反，請在聊天中向我展示這些命令，以便我可以手動執行它們。

我是一名經驗豐富的開發者。除非明確要求，否則不要解釋語法、API、程式設計概念或實作細節。

手動輸入的優點

雖然這種方法降低了從 AI 獲得的速度增益（從潛在的「10x」增長降至大約「2x」），但它提供了幾個關鍵的認知優勢：

• 心理模型構建： 輸入每一行程式碼會迫使開發者建立程式碼庫的空間地圖，確切地知道功能所在的位置。
• 幻覺檢測： 強制的減速使得更容易發現不良的設計選擇或 AI 幻覺，而這些在快速瀏覽或 diff review 時可能會被漏掉。
• 主動學習： 這個過程反映了傳統的學習方法——例如從教科書中輸入範例——其中轉錄的行為會鼓勵開發者停下來研究不熟悉的 API 或演算法。
• 自定義： 開發者可以在輸入的時侯，即時進行重構、重新組織並根據自己的品味調整程式碼。

社群觀點與反對意見

該提案在開發者之間引起了顯著的辯論，揭示了重視深度理解與將編碼視為高階編排任務的人之間的分歧。

支持論點

許多經驗豐富的開發者指出，這種「慢速編碼」的習慣在 LLM 時代之前就很常見。

"Back in the days of Stack Exchange I would always type out manually whatever answer I found to make sure I understood WTF I was adding to the system." — @bandrami

其他人引用了「生成效應」，認為與被動閱讀相比，產出文本（即使是透過複製）的行為能提高知識保留度。

批判性觀點

批評者認為，重新輸入是實際推理的低效替代品，且如果邏輯並非由開發者本人發起，則無法防止認知債務。

• 被動消費： 有些人認為重新輸入僅僅是「按圖填色」，而真正的學習需要主動構建意義，而非轉錄語法正確但「語義空洞」的回答。
• 抽象層級轉移： 一些開發者認為產業正在向更高層級的抽象邁進，在這種情況下，「逐行」理解變得不再那麼關鍵，而引導 AI agent 的能力變得更重要。
• 效率低下： 批評者指出，如果開發者必須思考到足以重新輸入並修正 AI 程式碼的程度，那他們大可以從頭開始編寫程式碼，完全不需要 LLM。

其他緩解策略

為了平衡速度與理解力，提出了幾種替代策略：

• 腳手架構建： 使用 LLM 生成僅高層級的結構（類別、介面、函數簽名），然後手動實作邏輯。
• 測試驅動 AI： 要求 LLM 先寫測試（Red tests），然後手動實作程式碼以使這些測試通過。
• 混合方法： 使用 LLM 進行研究與學習，但對於實際的實作，保持嚴格的「不使用 agentic-coding」規則，以保留「編碼品味」。