前言¶
2026 年 8 月 4 日，開發者 Ankur Sethi 在個人博客發表文章《Prevent cognitive debt by manually retyping LLM-generated code》，主張通過手動逐行重打 AI 生成的代碼來避免「認知債務」。該文在 Hacker News 獲得 409 分、348 條評論，評論區幾乎對半分裂——一方認爲這是對「Vibe Coding」的必要糾偏，另一方則質疑：這不就是「複製粘貼加了額外步驟」嗎？
Sethi 本人是資深開發者，仍在個人項目中使用 Claude Code、Cursor 等編碼助手。他的問題很具體：Agent 一次性生成功能固然快，但會讓自己對代碼庫「迷失方向」；而逐行審查 AI 提交的數百行 PR 又枯燥到難以忍受。於是他想出了一條「效率極低、略顯滑稽」的中間路線——讓 Agent 只展示改動，不直接寫文件，由自己手動敲進編輯器。
這篇文章梳理 Sethi 的核心主張、HN 上的主要爭議，以及評論區更被廣泛接受的替代做法，供你在 2026 年的 AI 編程工作流裏做取捨參考。
什麼是「認知債務」¶
Sethi 用 Cognitive Debt（認知債務） 來類比技術債務：當你把理解某段代碼的責任完全交給 LLM，代碼雖然跑起來了，但你對它的心智模型是空的——出了問題無法獨立調試，改需求時不知道從哪裏下手，最終只能回到聊天窗口問 AI「這段是幹什麼的」。
他在文中舉了一個典型場景：給個人網站加 Django 標籤功能，查文檔很無聊，但他仍然想理解解決方案是怎麼工作的。「問題無聊」不等於「可以把理解外包給機器」。
這與 2026 年行業主流形成張力：機器人提 PR，人類做 Review——Sethi 承認這種模式存在，但他不願意在個人項目裏扮演「AI 代碼審計員」。個人項目的樂趣在於過程，而不只是交付結果；對着幾百行過度防禦、註釋混亂、 暗藏錯誤的 AI 代碼做 Review，對他來說既不 fun，也積累認知債務。
Sethi 的工作流：Agent 只說不寫¶
Sethi 的解法可以概括爲：LLM 當參謀，手當執行器。他在各項目的 Agent 配置文件（類似 AGENTS.md）裏寫了三條硬規則：
- 禁止 Agent 直接改文件——不得創建、編輯、移動、重命名或刪除項目文件，除非他明確要求。
- 改動與命令只在聊天裏展示——Agent 把每一處 proposed edit 和 shell 命令輸出到對話，由他手動執行。
- 跳過基礎教學——他是 experienced developer，不需要 Agent 解釋語法或 API，除非主動提問。
實際流程如下：
需求描述 → Agent 在聊天中生成代碼片段 / diff 建議
→ 開發者逐行手動敲入編輯器
→ 遇到不懂的 API 或算法，停下來查文檔或追問 LLM
→ 順手重構、加註釋、調整風格
Sethi 坦言，這套流程比不用 AI 快大約 2 倍，但遠達不到 Agent 全權代勞宣稱的「10 倍」。他主動用速度換理解——「I value comprehension over productivity（我重視理解勝過生產力）」。他說已實踐數月，效果良好。
他還把這套做法類比爲學編程時的老經驗：看書記例題要手敲一遍，看博客抄代碼要改寫成自己的項目結構。手動輸入迫使大腦慢下來，更容易發現幻覺、錯誤 API 調用或糟糕設計；同時建立代碼庫的「空間地圖」——知道每個功能在哪，下次改哪裏不用問 AI。
HN 上的激烈爭論¶
HN 討論的核心分歧不在「要不要理解代碼」——幾乎所有人都同意理解很重要——而在手動重打是否是達成理解的正確機制。
支持方：摩擦帶來覺察¶
支持者認爲，重打創造了一個強制暫停點：你必須處理每一個字符，更容易注意到變量名不合理、假設有誤、或調用了不認識的 API。相比「讀 diff → 一鍵 Accept」，機械輸入至少不會完全跳過細節。有人回憶從雜誌學編程的年代：「這基本就是我當年從 BYTE 雜誌抄代碼的方式。」
Sethi 還強調，慢下來有助於捕獲幻覺——LLM 生成的代碼表面能跑，但可能用了不存在的方法或錯誤的庫版本；快速粘貼時這些細節容易被忽略。
反對方：重打 ≠ 生成，可能是「clerical theatre」¶
HN 高贊批評直指機制本身。一條代表性評論寫道：
如果你的流程是：認真想 → 讓 LLM 寫 → 讀 LLM 寫的 → 再想一遍 → 重打 → 再修——效率增益在哪？乾脆去掉 LLM，還省 token。
批評者指出：重打已審查過的代碼，認知活動與自己設計並實現完全不同。學生抄課堂筆記時也會進入「自動打字」模式，記憶留存幾乎爲零。重打可能只是把 copy-paste 換成了 copy-retype，並沒有增加真正的理解深度。
還有人認爲 Sethi 真正想要的是「comprehension（理解）」，但選了「retyping（重打）」這個非必要的手段——理解可以通過其他方式達成，不必逐字符 transcription。
更深層的問題：Review 夠嗎？¶
評論區另一個 recurring 擔憂是：讀 diff 和能獨立調試是兩回事。就像學外語——你能讀懂句子，不代表能自己說出來。六週後收到 bug 報告，被動 Review 時「看懂了」的代碼，未必能幫你定位問題，尤其在沒有 AI 輔助的凌晨三點。
這一點對團隊更有現實意義：不少 Tech Lead 反映，新人用 AI 快速交付 ticket，但數月後仍缺乏本該通過手動追 bug 積累的基礎直覺——這與 Sethi 個人項目的認知債務是不同層面的問題。
評論區更被廣泛接受的替代方案¶
即便批評 Sethi 的具體方法，HN 線程裏仍浮現出若干共識度更高的做法：
1. 先規劃，再委託
讓 Agent 先輸出實現計劃（plan），人類審閱、修改計劃，確認「what should happen」後再讓 Agent 寫代碼。決策權留在人這邊，字符輸入可以委託。
2. Chat-only Review，理解後再粘貼
Agent 在聊天裏展示 diff，你仔細閱讀、提問、確認理解後再粘貼——跳過機械重打，但保留「我搞懂了才入庫」的門檻。
3. Design-first 委託
架構、函數簽名、數據流由自己寫；Agent 只填 implementation 細節。維護性最關鍵的部分留在人腦裏。
4. 把 AI 當 Rubber Duck
實現前先問「有沒有遺漏的設計問題」，比寫完幾百行再 Review 便宜得多。
5. 嚴格限制 scope
一次只要單文件、小範圍改動，Review 負擔接近審查同事的小 PR，而非審計 1000 行 drop。
6. 測試作爲 ground truth
先寫 failing test，再讓 Agent 修 bug——正確性由測試驗證，不完全依賴人工讀代碼。
7. 按 stakes 匹配摩擦
沒人主張重打 boilerplate 或測試腳手架；爭議集中在需要長期維護、出了問題你得扛的核心業務代碼。Disposable 代碼或測試覆蓋充分的代碼，速度優先更合理。
一套可落地的 AGENTS.md 參考¶
若你認同 Sethi「Agent 不直接改文件」的框架，但不想逐行重打，可以折中配置 Agent 規則。以下基於 Sethi 原文整理，可按項目裁剪：
## Agent 協作規則
- 理解優先：我需要理解項目中每一行代碼。除非我明確要求，否則不要創建、編輯、移動、重命名或刪除任何文件。
- 改動展示：所有 proposed edit 和會修改倉庫狀態的命令，只在對話中展示，由我手動執行。
- 簡潔輸出：我是有經驗的開發者，默認不要解釋基礎語法或 API，除非我追問。
- 小步提交：每次建議的改動範圍儘量小，便於我 Review 和理解。
配合實踐：每合併一段 AI 生成的代碼前，用兩句話向自己解釋「這段做什麼、爲什麼這樣寫」——若做不到，說明認知債務已經產生，需要停下來搞懂再入庫。
小結：機制可爭議，警覺不可少¶
Sethi 的「逐行重打」是一種極端的個人實踐，HN 對其機制的質疑是成立的——mindless transcription 不等於 deep comprehension。但他指出的問題——AI 全權代勞會在代碼庫中積累認知債務，在凌晨 incident 或安全審計時集中爆發——很難被反駁。
對你而言，不必二選一：
- 個人 side project、需要長期維護的模塊：可以借鑑 Sethi 的「Agent 只說不寫 + 強制慢下來」，重打只是選項之一，「理解後再入庫」纔是核心。
- 團隊生產環境：更現實的路徑是 plan-first、小 scope PR、測試驅動、以及 Review 時追問「why this approach」，而非要求每人重打每一行。
- 判斷是否欠債的簡單標準：Review 時若無法脫離聊天日誌解釋自己的 PR，債務已經在那裏了。
2026 年的 AI 編程工具設計目標，是消除摩擦。Sethi 與 HN 這場爭論真正提出的問題是：在哪些地方，你故意把摩擦加回來——以及用什麼方式加，才既保理解又不淪爲低效表演。
參考來源
- Ankur Sethi, Prevent cognitive debt by manually retyping LLM-generated code
- Should You Manually Retype LLM-Generated Code? The HN Debate（HN 409 分 / 348 評論討論梳理）
