Cognitive Debt 是什麼？想像你讓 AI 在下午完成原本要寫三天的付款功能：畫面能跑、測試是綠的、PR 也合併了。兩週後重複扣款，你卻回答不出資料先寫進哪裡、哪一步可能只成功一半，以及重試為什麼會再扣一次。你借到的是開發速度，欠下的則是對系統的理解。
2026 年 8 月，Ankur Sethi 提出「讓 AI 在對話中產生程式，再由人逐行重打」的做法，引發 Hacker News 超過 500 points、超過 430 則留言的討論。爭議的核心不是大家要不要用 AI，而是：鍵盤輸入真的等於理解嗎？如果不重打，又要拿什麼證明自己看懂了？
這篇專為會用 Claude Code、Codex、Copilot 或其他 AI 寫程式工具，卻不想把維護能力一起外包的讀者而寫。我們會先用白話回答 Cognitive Debt 是什麼、區分技術債與意圖債，再用一段會「重複扣款」的簡化程式，走完 Explain-back、執行追蹤、測試突變與 ADR／接手清單四道閘門。你不必把每一行重打一遍，但高風險程式必須留下可驗證的理解證據。
先說結論：Cognitive Debt 的還債單位是「理解證據」
🧠 記憶公式：Cognitive Debt ＝已交付的系統能力－團隊能解釋、預測、反證與接手的能力。
所以真正要量的不是 AI 寫了幾行，也不是人重打了幾行，而是關鍵行為是否有人能說清楚、跑給你看、故意弄壞並由測試抓住，最後交給另一個人維護。
這個判準比「我看過 diff」嚴格，卻比「所有程式都手動重打」省得多。它也保留 AI 的真正優勢：把樣板、語法與重複工作加速，再把省下的時間投入系統邊界、失敗路徑與驗證。
Cognitive Debt 是什麼？先和另外兩種債分開
截至 2026 年 8 月，軟體圈同時使用 cognitive debt、codebase cognitive debt 與 comprehension debt 等名稱，邊界仍在形成。本文採用一個方便驗收的工作定義：團隊目前知道的，低於安全修改系統所需要知道的。這和程式碼本身「好不好」不是同一題。
- 技術債住在程式與設計裡：重複邏輯、脆弱耦合或權宜架構，讓未來修改更慢、更容易出錯。團隊可能完全理解一段壞設計，仍然背著技術債。
- 意圖債住在外部知識裡：為什麼選這個方案、拒絕哪些替代案、哪些限制不可破，沒有被可靠留下。文件缺漏只是其中一部分；文件很多，卻沒寫決策理由，一樣會欠債。
- 認知債住在人與團隊的心智模型裡：程式也許乾淨、測試也會過，但負責的人無法預測狀態怎麼變、錯在哪裡或需求改動會撞到誰。
University of Victoria 教授 Margaret-Anne Storey 的 三種債模型把技術債放在 code、認知債放在人、intent debt 放在外化的知識；Thoughtworks 也在 2026 年 4 月把 codebase cognitive debt列為「Caution」訊號，描述實作與團隊共享理解之間日益擴大的落差。本文檢視的這些來源並未共用同一套量表，因此以下用操作性閘門驗收，不把它假裝成公認標準。
手動重打 AI 程式碼有用嗎？有摩擦，不等於有證明
Sethi 在引發討論的原文裡說，逐行輸入會迫使他放慢、查陌生 API、整理設計，並建立程式在檔案中的空間地圖。這是合理且誠實的個人工作法；但原文只自述已用了幾個月且「對他有效」，未提供比較組、標準化理解測驗或客觀維護指標。他寫的「大概 2 倍而不是 10 倍」也是個人估計，不能當成普遍生產力數字。
一項直接相關的證據來自 Anthropic 2026 年的 52 人隨機研究。參與者原本都固定使用 Python，但不熟悉 Trio；AI 組做完任務後的即時測驗平均 50%，手寫組 67%。在未預註冊的探索性分題分析中，這個樣本的最大落差出現在除錯題。不過 AI 組只平均快約兩分鐘，速度差異未達統計顯著；研究樣本小、任務短，也沒有回答長期維護會怎樣。
更關鍵的是，完整論文對 AI 組所做的探索性、非隨機子群分析中，手動輸入（n＝9）與直接貼上（n＝9）的測驗分數沒有明顯差異；混合輸入只有 4 人，論文沒有給出同等明確的結論。高分者比較常問概念、要求解釋、先產生再確認理解，或自己解掉錯誤；這些小群組只能顯示關聯，不能證明因果。換句話說，重打可以是一種有用的減速器，但現有結果不足以證明鍵盤輸入本身帶來理解優勢。
證據也不是單向悲觀。另一項 275 名初學者的隨機研究發現，使用 AI 的組別練習表現較好、挫折較低，但學習增益與程式理解沒有勝過不用 AI 的對照組。比較穩妥的結論是：在這些短期學習任務中，較好的當下表現未必伴隨較好的即時知識增益或程式理解；長期與真實維護情境仍未回答。
完整案例：這段「已通過測試」的付款程式哪裡危險？
下面是一段簡化的 JavaScript 示意。它先查發票是否付過，再扣款，最後把資料庫標成已付款。第一眼很合理，AI 也很容易替它補出漂亮的單元測試。
async function payInvoice(invoiceId, amount) {
if (await db.hasPayment(invoiceId)) return "already_paid";
await gateway.charge(amount);
await db.markPaid(invoiceId);
return "paid";
}正常路徑是 查詢 → 扣款 → 記錄 → 回傳。真正的洞藏在兩個 await 之間：刷卡成功後，如果資料庫暫時失敗，函式會拋錯，發票卻仍顯示未付款。系統重試時，hasPayment() 依然回傳 false，於是再扣一次。程式不是每次都錯，而是在特定時間點「只成功一半」；只測 happy path 很容易完全看不到。
這段示意刻意省略真實付款會處理的併發請求、供應商 idempotency key、交易狀態機、timeout 與補償流程。重點不是教你照抄付款碼，而是展示：能讀懂每一行語法，仍可能沒有整條失敗路徑的心智模型。
Cognitive Debt 的 4 道還債閘門
以下四道閘門是 AlphaLab 把程式理解研究、debugger 實驗、mutation testing 與 ADR 實務組合成的 evidence-informed workflow。它不是一套已被整體隨機實驗驗證的產業標準；價值在於把「我應該懂」改成可通過或退回的證據。
Gate 1｜Explain-back：關掉 AI，自己畫回資料流
痛點：讓 AI 再解釋一次，只能證明 AI 會生成解釋，不能證明你能獨立維護。2026 年一項針對 LLM 產生 assertion 的受控研究發現：資訊不足的 comment 相較精確 comment 會降低判斷準確率；相較完全沒有 comment，卻會提高參與者自信。
操作：先關掉聊天視窗，不看原答案，用三分鐘寫下 輸入 → 驗證 → 狀態變化 → 外部副作用 → 輸出，再補至少兩條 failure path 與一條不可破壞的 invariant（不變量）。付款例的 invariant 可以是：「同一張發票最多成功扣款一次。」
通過條件：一張資料流、兩條失敗路徑、一條 invariant，另一位維護者能沿著你的圖找到對應程式。只會逐行翻譯語法，卻說不出狀態與副作用，就先把變更退回理解階段。
Gate 2｜Predict → Trace：先押答案，再跑 debugger
痛點：程式跑出結果後，人很容易把結果合理化成「我本來就知道」。先預測，才能抓到你腦中的模型和真實執行之間哪裡分岔。
操作：替付款函式準備三個小案例，執行前先寫下「回傳值、資料庫狀態、扣款次數」：
- 新發票正常付款。
- 同一張發票再次呼叫。
- 扣款成功後，故意讓
db.markPaid()失敗，再重試一次。
接著在每個 await 前後設 breakpoint，或暫時記錄 invoiceId、步驟、外部呼叫結果與資料庫狀態；測試可先只跑最小範圍。若專案使用 Jest，可執行 npm test -- --runInBand payment；pytest 專案則可用 pytest -q -k payment。想把 trace 做成可回放的系統，可延伸看〈Agent Observability 完整教學〉與〈最小 Agent Harness 執行迴圈〉。
通過條件：三組預測全部和 trace 一致；若不一致，必須指出錯的是哪一個假設並更新圖與測試。一項 32 名初學者的程式理解研究觀察到，參與者常把自然語言描述的意圖誤當成程式真正輸出；這道閘門正是要把「它應該做什麼」和「它實際做什麼」拆開。
Gate 3｜Test Mutation：故意改壞假設，看測試會不會叫
痛點：100% line coverage 仍可能只證明每行跑過，沒有證明關鍵判斷被驗對。最直接的反問是：如果我把重要邏輯改壞，哪一個測試會失敗？
操作：先做一個可逆的小突變，例如把 hasPayment(invoiceId) 的條件反轉，或讓「資料庫寫入失敗後再重試」真的發生。相關測試必須由綠轉紅，還原程式後再回綠。JavaScript 專案想系統化執行，可依 Stryker 官方流程執行：
npm init stryker@latest
npx stryker run通過條件：至少一個和本次高風險假設直接相關的 mutant 被測試抓到；survived mutant 要嘛補測試，要嘛說明它為何不改變行為。不要追逐 100% mutation score；Microsoft 的 mutation testing 文件也建議把重點放在高風險或業務關鍵區域。這道閘門證明的是「測試看得見這個人造錯誤」，不是證明整套系統正確。
Gate 4｜Decision + Ownership：留下理由，也留下接手的人
痛點：今天的作者能解釋，不代表三個月後團隊仍知道為何要這樣設計。只寫「增加 idempotency」也不夠，因為下一個人不知道你排除了哪些方案、接受了什麼代價。
操作：只為高風險或長壽決策建立短 ADR，例如 docs/adr/004-payment-idempotency.md，至少寫五個核心欄位：Title / Status / Context / Decision / Consequences；再在理解清單留下 primary owner、backup reviewer、上次通過前三道閘門的日期，以及「需求、依賴或事故改變時重驗」。前述五欄採用 英國 GDS 建議的 ADR 摘要結構；owner、backup、通關日期與事件式重驗條件則是本文另加的理解清單。ADR 只保存決策脈絡，不等於完整架構文件。
通過條件：備援維護者不靠原作者，能用 ADR 說明選擇與代價，再完成 Gate 1 的 explain-back。若只有檔案沒有能接手的人，那是意圖被存下來了，認知債仍未還清。團隊若要把長期規則與交接資訊放進 AI 可讀的共同脈絡，可搭配〈Context Repo 是什麼〉。
不用全部重打：先按風險決定要過幾道閘門
要求每一段 CSS、一次性轉檔腳本與產生器樣板都過四關，會把驗證做成新官僚。比較實際的分流方式是看「錯了會傷到誰、會不會留下狀態、多久後還要改」：
- 低風險、可丟棄：原型、暫時分析、容易重生的樣板，抽樣做 Explain-back 與基本測試即可。
- 中風險、會長期維護：共用元件、資料轉換、API 整合，至少過 Explain-back、Predict → Trace 與針對關鍵分支的測試反證。
- 高風險、會改外部狀態：付款、權限、資料刪除、認證、併發、隱私或不可逆動作，四關全部過，並由 backup reviewer 實際接手一次。
大型 Repo 還要控制 blast radius 與回滾；這部分可接著讀〈Claude Code 大型 Repo 安全改版〉。若 AI Agent 會自己連續呼叫工具，先看〈Loop Engineering〉理解自主迴圈，再用〈AI Evals〉把高風險失敗變成可重跑的回歸案例。
如何量測 Cognitive Debt 是否真的下降？
不要再用 generated LOC、PR 數量或「看過幾行」當理解指標。建立一張高風險模組清單，每列只記四個 pass/fail 與證據連結：Explain / Predict / Falsify / Own。接著看：
Verified-understanding coverage ＝通過所有適用閘門的高風險模組 ÷ 高風險模組總數
這是工作儀表板，不是經驗證的心理量表；100% 也不表示每個人理解每一行。真正有價值的是沒通過的 debt item 有明確 owner、證據與重驗條件。就像〈Claude Code Token A/B Test〉用實測替代感覺，理解也要從「我覺得懂」變成能重現的行為。
最常見的 5 個還債失敗
- 把 AI 的解釋當成自己的理解：先由人 explain-back，再用程式、文件與 AI 交叉檢查。
- 只看 happy path：每個核心流程至少加入 boundary、dependency failure 與 retry。
- 把 coverage 或 mutation score 當品質真相：分數只能指出你測到了什麼，不能替你證明沒漏什麼。
- ADR 寫成會議逐字稿：一份只記一個重要決策，保留脈絡、選擇、後果與重審條件。
- 每段程式同樣嚴格：把時間集中在金流、權限、資料、併發與長期架構，才不會讓流程被團隊繞過。
Cognitive Debt 是什麼？8 個常見問題 FAQ
1. Cognitive Debt 有公認的單一分數嗎？
截至 2026 年 8 月，本文檢視的研究與產業來源採用不同定義與代理指標。因此本文用四個可觀察能力做團隊儀表板，不把它包裝成科學量表。
2. 測試全綠，不就代表可以維護嗎？
不等於。測試只覆蓋你選過的案例與 assertions；它能證明觀察到的行為，不能直接證明團隊知道為何如此、需求改變時該改哪裡。
3. 手動重打完全沒用嗎？
不是。對短小核心演算法、陌生語言或個人學習，重打能創造有用摩擦；但 Anthropic 的小型、非隨機子群分析沒有提供逐字輸入優於直接貼上的證據。主動提問、預測與自行解錯才是更直接可觀察的理解行為。
4. 初學者還能用 AI 寫程式嗎？
可以。把 AI 當教練：先問概念與限制、自己寫預測，再請它給反例或出題。現有短期研究不足以推論長期技能結果，所以不要把「作品已完成」直接當成「技能已形成」；每個任務至少留下一次不看答案的解釋或預測。
5. 每一位工程師都要懂每一行嗎？
不必。重點是每個高風險模組都有足夠的共享理解、primary owner 與 backup reviewer，而不是把整個 codebase 塞進每個人的腦袋。
6. 叫 AI 幫我畫流程圖，算通過 Explain-back 嗎？
不算。AI 可以在你完成初稿後當反方審查，但第一版必須由維護者不看答案產生，否則只是在驗收另一份 AI 輸出。
7. ADR 可以取代 code review 嗎？
不能。ADR 保存「為何這樣選」，review 檢查「這次怎麼改」；兩者再加上 trace 與測試，才覆蓋意圖、實作與行為。
8. 四道閘門多久跑一次？
跟著風險事件跑。高風險變更合併前執行；需求、不變量、關鍵依賴、owner 或事故學習改變時重驗。穩定模組不需要為了儀式每天重跑。
給新手的 5 個重點
- Cognitive Debt 量的是能力落差，不是 AI 產生的行數。
- 完成任務與理解系統可能脫鉤，但 AI 並非必然傷害學習。
- 手動重打是可選摩擦，不是唯一解，也不是還債的計量單位。
- 高風險程式要留下四種證據：能解釋、能預測、能反證、能換人接手。
- 把 AI 省下的時間重新投資在 failure paths、tests、trace 與 decision context。
📚 延伸閱讀：把理解變成一套工程系統
- 〈AI Agent Harness 是什麼〉：先建立模型、工具、狀態與控制迴圈的共同地圖。
- 〈AI Agent 三層架構〉：分清楚 Harness、Loop 與 Graph 的責任邊界。
- 〈AI Evals 是什麼〉：把真實失敗轉成可重跑、可阻擋回歸的案例。
- 〈Claude Code vs Codex〉：理解不同 AI 寫程式工作流如何影響本機操作、雲端委派與審查方式。
- AlphaLab 課程：把 AI 協作、Agent 與自動化能力整理成可反覆練習的完整路線。
結語：今天就替一個高風險模組還債
理解 Cognitive Debt 是什麼只是第一步；AI 讓寫程式變便宜之後，稀缺的不是更多程式，而是有人能對程式的行為負責。今天挑一個你最近讓 AI 大幅修改的高風險模組，關掉原對話，畫出資料流與兩條失敗路徑；再選三個小輸入預測結果，故意改壞一個關鍵假設，最後請另一個人用 ADR 接手。四關過了，你留下的就不只是能跑的 code，而是一套團隊仍然握得住的系統。