透過手動重新輸入 LLM 生成的程式碼來避免認知負債

Ankur Sethi 在個人專案中避免認知負債的方法是，要求 LLM 在聊天中生成程式碼，然後自己手動輸入每一行，而不是讓模型直接編輯檔案。

使用 LLM 時的認知負債問題

使用 LLM 一次性生成整個功能，會讓作者感到不滿與迷失，審查 AI 生成的 Pull Request 也毫無樂趣。他擔心整個產業正在累積認知負債，這將很快需要償還。

我擔心軟體產業正在承擔大量認知負債，我們很快就得償還。總有一天，我們將不再理解我們數位基礎設施的大部分組成方式。我或許無法個人改變整個產業的走向，但我至少可以確保我完全理解我所發布的軟體。否則就是專業上的失職。

手動重新輸入的工作流程

作者明確指示 LLM 只在聊天中顯示建議的修改與指令，絕不直接修改程式庫。

我希望理解進入此專案的每一行程式碼。除非我明確要求，否則請勿建立、編輯、移動、重新命名或刪除專案檔案。請將每一個建議的修改顯示在聊天中，讓我手動輸入。

請勿執行會修改專案檔案、安裝相依性或改變程式庫狀態的指令，除非我明確要求。請將這些指令顯示在聊天中，讓我手動執行。

我是經驗豐富的開發者。除非我特別要求，否則請勿解釋語法、API、程式設計概念或實作細節。

透過手動輸入每一行程式碼，他能建立對程式碼如何融入現有程式碼庫的心理模型，可查閱不熟悉的 API，並偵測幻覺或不良的設計選擇。

當我手動將 LLM 生成的每一行程式碼輸入編輯器時，我會逐步建立對其運作方式與如何融入我現有程式碼庫的心理模型。如果我不理解某個 API 或演算法，我可以暫停並查閱資料，或直接請 LLM 解釋。

手動輸入程式碼迫使自己放慢節奏，這意味著我更有可能發現 LLM 可能產生的幻覺或不良設計選擇。我可以在輸入過程中清理程式碼，重新組織、重構、加入註解，並根據自己的風格進行調整。

此工作流程也建立了程式碼庫的空間地圖，使未來的修改與提示 LLM 變得更容易。

手動輸入的優點

作者發現此方法比完全委託給 LLM 慢（僅有約 2 倍加速，而非 10 倍），但他更重視深入理解，而非純粹的生產力。

以這種方式使用 LLM，讓我比完全不使用 LLM 時更快，但我仍然比那些願意讓機器替他們思考的人慢。我不是快 10 倍，大概只有 2 倍。但我失去的速度，換來的是對程式碼更深層的理解。

他將此做法類比於傳統建議：學習程式設計時，手動輸入書籍或論壇中的範例。

手動將 LLM 生成的程式碼輸入我的程式碼庫，感覺就像是完全相同的學習過程。這或許不是與 LLM 協作最有效率的方式，但我更重視理解，而非生產力。

社群反應

Hacker News 上的留言者表達了多樣的看法，從支持到批評，並提出替代策略。

支持或類似做法

@wahern: "昨天是好建議，今天是好建議，明天也是好建議。……手動輸入程式碼能給你時間與空間去思考整體圖像。"
@bandrami: "順帶一提，回憶起 Stack Exchange 的年代，我總是手動輸入找到的答案，以確保我理解自己正在系統中加入什麼東西。"
@andai: "Zed Shaw 的方法！"
@FailMore: 提到使用 SmallDocs 來保持與 LLM 產生的程式碼接觸。
@sltr: 引用「生成效應」作為手動輸入能提升知識保留的原因。
@twoquestions: "這正是我現在學習 Electron 的方式，我基本上讓 Opus 為我寫一份教學，來開發我想要的應用程式，並在過程中修改各個部分。"

對此方法的批評

@npras1: "手動重新輸入 LLM 生成的程式碼是大錯特錯。但對於仍然手動輸入程式碼、不交給 LLM 來做的做法，我則是大力贊成。只是這程式碼必須是你大腦產生的。"
@estebarb: 引用 arxiv 論文："當學生將這些輸出當作自己推理或批判性參與的替代品時，學習過程會被根本性地破壞。真正的學習需要主動建構意義、整合知識，並反思性地參與內容。"
@f311a: "這聽起來一點都不有趣。最好還是用手動編碼來進行你的副專案。你會學到更多。重新輸入程式碼對學習來說效率極低。這就像試圖重新輸入微積分解答——你不會從中學到東西。"
@petcat: "這只是個悲慘的『按圖施工』職業，因為人們懶得為自己的專業工作或程式設計愛好進行創造性思考。"
@a2128: "作為一個曾經會抄別人作業、從網路上抄報告、用答案卡完成作業的人，我可以告訴你，這種策略早已被證明會累積認知負債，而非防止它。"

替代建議

@smegma2: "這似乎是一個還不錯的解決方案，但何不試試相反的做法？先手動寫出程式碼的骨架與整體結構（類別、介面、函數簽章），再讓 LLM 填入內容。"
@reacweb: "在小專案中用 LLM 生成程式碼，然後手動複製到你的大專案中。"
@overthenexttwod: 主張將思考外包給 LLM 會產生比自己寫程式碼更弱的心理模型，並建議將 LLM 視為可引導的獨立代理，而非生產力加速器。
@jruz: 描述降級到 20 美元方案，並只提問而不讓 LLM 寫程式碼。

結論

作者的手動重新輸入方法旨在保留理解力的同時，仍能從 LLM 協助處理枯燥任務中獲益。Hacker News 的討論顯示，此技術被一些人視為傳統『手動輸入學習』的現代演進，而另一些人則認為效率低下或不必要，建議應親自寫程式碼，並僅在審查、架構或問答時使用 LLM。

透過手動重新輸入 LLM 生成的程式碼來避免認知負債 – 來自 Hacker News 討論的洞見