理解債務：為什麼我們應該比模型更累

在代理式程式碼生成（agentic code generation）的時代，問題與解決方案之間的距離已縮短至僅需幾個提示詞（prompts）。對於許多開發者而言，這種效率伴隨著隱藏的成本：一種與自己交付的程式碼之間日益增長的疏離感。當 AI agent 處理實作時，開發者往往跳過了關鍵的內部處理過程——即傳統上在手寫程式碼時發生的短期、工作與長期記憶的綜合過程。

這種現象創造了一種「理解債務」（comprehension debt）。雖然生產力的外在跡象顯而易見——程式碼已寫好、測試通過、功能已交付——但系統的內部心理模型（mental model）卻是空洞的。正如 Vicki Boykis 所言，目前 AI 編碼工具的使用者體驗（UX）讓人聯想到老虎機：你拉動槓桿，然後獲得一個可運行的解決方案作為獎勵。這種循環與技能保留背道而馳，並可能導致普遍的「腦霧」，讓開發者覺得自己失去了對自身程式碼庫的控制權。

無摩擦編碼的認知成本

程式設計不僅僅是產生可執行文本的行為；它是一個深度理解的過程。手動實作功能時所涉及的摩擦——搜尋文件、與 bug 搏鬥、重構笨拙的方法——正是鞏固程式設計師基礎的關鍵。當這種摩擦被移除時，大腦便停止參與長期學習所需的、高強度的綜合過程。

這種轉變導致了開發者社群的分歧。有些人認為低階編碼技能的流失是自然的演進，類似於從組合語言（assembly）轉向高階語言。他們主張開發者的角色正在轉向產品管理、設計與高階編排（orchestration）。正如一位評論家所言，價值不在於寫程式碼的能力，而是在於讓問題「優雅地消失」的能力。

然而，其他人則警告這是一種危險的權衡。如果沒有對實作過程的深度理解，開發者將成為自己專案中的乘客，無法除錯複雜的邊緣案例（edge cases），也無法在模型提供的模式之外進行創新。風險不僅僅是技能萎縮，更是「品味」的退化以及批判生成輸出品質的能力。

重新引入刻意摩擦的策略

為了對抗理解債務，開發者開始實施「刻意摩擦」（deliberate friction）——旨在強迫大腦回到主動學習與綜合狀態的策略。

主動實作與審查

而非讓 agent 寫完整個功能，一些開發者正採用「人類優先」的方法：

• 手動初稿： 親手撰寫初始實作，僅將 agent 用於審查與批判。
• 手動整合： 對於 AI 建議的變更，逐行查看註解並手動輸入，而非直接接受整塊的 diff。
• 20 分鐘規則： 承諾在尋求 AI agent 協助之前，先花至少 20 分鐘與問題搏鬥。

將 AI 作為蘇格拉底式導師

與其將 LLM 作為實作引擎，不如將其重新定位為教學工具。這包括：

• 蘇格拉底式提問： 要求 agent 對開發者進行提問，詢問為何選擇特定方法或為何替代方案會失敗。
• 文件發現： 利用 AI 指向原始文件與學術論文，而非提供摘要式的答案。
• 概念深度探究： 利用 agent 解釋陌生的程式碼片段，或腦力激盪兩種競爭的架構方法，然後對兩者進行批判。

結構化參與

一些開發者發現，重構（refactoring）是重新獲得心理模型的強大方式。透過指示 agent 執行特定的、細粒度的重構——例如「將此 SQL 邏輯移至新文件」或「將這些測試參數化」——開發者仍然是系統結構的架構師，確保程式碼在腦中「留存」，即使他們沒有輸入每一個字元。

努力的悖論

AI 輔助開發的核心張力在於短期速度與長期能力之間的衝突。這些工具旨在最大化前者，往往以犧牲後者為代價。

"所有這些方法透過增加摩擦，在短期內抵消了 LLM 生成程式碼所帶來的所謂加速效果，然而，從長期來看，卻讓我更擅長使用該工具，因為它們鞏固了我自己的基礎，而非基礎模型的基礎。"

這為現代開發者提出了一個新的格言：我們應該比模型更累。如果 AI 正在做所有的重活，人類就沒有在成長。為了保持競爭力與能力，開發者必須自覺地選擇更難的路——那條充滿心理努力、深度閱讀與刻意掙扎的路——以確保 AI 僅作為能力的放大器，而非思考的替代品。