作者注：以 Addy Osmani 的“認知投降”與“理解債”觀點爲主線，整理一套 PR 合併前的自檢清單與 Prompt 模板，並對比 LobeHub 依賴驗收報告的審查思路，幫你按風險選擇審查強度。
如果你每天用 Claude Code、Cursor 或 Cline 交付代碼，可能已經有過這種體驗：Agent 幾分鐘交出一個幾百行的 PR，命名規範、結構清晰、測試全綠，於是你點了“批准”。幾周後有人問這段邏輯爲什麼這麼寫，你卻答不上來。本文圍繞 “讓 AI 出題考你”等可執行的檢查動作，幫你在不逐行審查的前提下，依然對自己批准的每一次改動負責。
這不是一篇勸你回到手寫代碼的文章。Claude Code 工程師 Addy Osmani 本人就明確表示，沒人要求工程師記住整個代碼庫；問題不在於讀不讀每一行，而在於你是否知道自己懂什麼、不懂什麼。
核心價值：讀完本文，你將理解“認知卸載、判斷讓渡、認知投降”的遞進過程，拿到一份可直接複製的合併前提問清單和 Prompt 模板，並學會按改動風險選擇審查強度。
別給 Agent 蓋章：理解債核心要點
據量子位報道（經 36 氪轉載），前 Google 工程師、現參與 Claude Code 工作的 Addy Osmani 發文討論了一個扎心的問題：AI 生成的東西越可靠，人類就越不認真檢查。他把這個過程拆成幾個遞進階段，並提出了兩種新型“債務”。需要說明的是，以下概念均來自媒體轉述，具體措辭請以 Addy 原文爲準。
| 概念 | 含義 | 典型表現 |
|---|---|---|
| 認知卸載 | 把具體工作交給 AI，但自己仍理解任務、能判斷結果 | 讓 Agent 寫樣板代碼，你清楚它在幹什麼 |
| 判斷讓渡 | AI 的答案逐漸成爲下一步工作的默認依據 | 第二次只掃兩眼，Agent 說什麼就按什麼推進 |
| 認知投降 | 連本該自己完成的判斷也交了出去 | “AI 說得肯定有道理”，測試全綠直接合並 |
| 理解債 | 代碼和系統複雜度增長，開發者的理解卻沒跟上 | 要改功能時沒人摸得清內部結構 |
| 意圖債 | 需求中沒說清的目標、限制和取捨被 AI 替你決定 | 自己沒想清楚要什麼，Agent 卻交出像樣的成品 |
認知投降與理解債的遞進過程詳解
認知投降不是一夜之間發生的。最初你只是“卸載”具體勞動，這本身並沒有問題，就像用編譯器而不手寫彙編。危險在於第二階段：當 Agent 的輸出連續幾次都靠譜，它的結論會悄悄變成你的默認前提，你開始跳過驗證。到了第三階段，“批准”按鈕變成了一枚印章，你的角色從工程師變成了蓋章員。
Addy 舉過一個很典型的例子：Agent 一口氣提交 600 行代碼，結構清晰、測試通過，開發者放心合併。但 Agent 可能在不起眼的地方改了事務處理順序，或者調整了某個邊界條件。這些改動當時不會報錯，等系統真出問題時，開發者才發現自己解釋不清代碼爲什麼這麼運行。這就是理解債的“利息”，它總在最不方便的時候到期。
意圖債則發生在更上游。現在的 Agent 太擅長補全需求了，哪怕你沒想明白，它也能交出一份看起來很合理的作品。問題在於，那些你沒說清的目標、範圍和取捨，已經被 AI 默默替你拍板了。意圖債和理解債往往疊加出現：你既不清楚自己當初要什麼，也不清楚 Agent 最終做了什麼。
償還理解債的 6 個方法
Addy 在長文中分享了不少實操建議。下面把它們整理成 6 個方法，並標註各自對應的是哪一種債務、在工作流的哪個環節使用。
| 方法 | 使用時機 | 主要償還 | 一句話動作 |
|---|---|---|---|
| 1. 讓 Agent 出題考你 | 大型改動完成後、合併前 | 理解債 | 先總結改動和原因，再出題，全對才合併 |
| 2. 動手前寫需求清單 | 寫 Prompt 之前 | 意圖債 | 寫清面向誰、解決什麼、不做什麼、完成標準 |
| 3. 追問未授權決定 | 長任務結束時 | 理解債、意圖債 | 問它做了哪些你沒授權的決定、依賴了哪些假設 |
| 4. 追問沒測什麼 | 看測試結果時 | 理解債 | 先看實際執行的測試和輸出，再讀 AI 總結 |
| 5. 保留原始材料 | 多 Agent 並行時 | 理解債 | 重要任務保留原始資料和驗證依據，審不過來就減並行 |
| 6. 定期離線練習 | 每週、每月 | 能力退化 | 每週一次不依賴 Agent 的編碼，每月盤點外包了哪些技能 |
讓 AI 出題考你：最核心的理解債檢查動作
這是整套方法裏最有意思的一招。Agent 完成一項大型修改後，先別急着點通過，而是讓它扮演考官：總結這次改了哪些地方、爲什麼這麼改，然後根據修改內容出幾道題，並立下規矩，只有全部答對才能合併。它的價值在於把“我大概看懂了”這種模糊感受，變成可檢驗的結果。答不上來的題，恰好就標出了你理解債的具體位置。
追問未授權決定與沒測什麼
長時間運行的任務裏，Agent 會自行選擇默認參數、調整實現範圍，甚至在需求衝突時做取捨。這些決定未必會寫進最後的總結，因爲它們“太自然了”。所以比起問一句“完成了嗎”，更有效的是追問：你做了哪些我沒明確授權的決定？哪些地方依賴了你自己的假設？還有什麼沒驗證？哪些改動可能影響其他功能？
測試也是同理。Addy 特別提醒，綠色測試只證明測試覆蓋到的條件通過了，邊界情況沒寫進測試，報告照樣可以很漂亮。正確順序是先看實際執行了哪些測試、返回了什麼結果，再去讀 AI 生成的總結。對於高風險修改，還可以讓另一個 Agent 從不同角度獨立找問題。
合併前自檢流程快速上手：別給 Agent 蓋章的 5 步
把上面的方法串起來，就是一套可以在每個 PR 合併前執行的流程。它不要求逐行審查，但要求你在每一步都留下“腦子轉過”的痕跡。
- 開工前寫預期：用自己的話寫下需求說明和你預期會發生什麼。如果連續調整兩輪 Prompt 仍不滿意，回頭重梳需求，而不是繼續堆提示詞。
- 要求交代決定：任務結束後，讓 Agent 列出未授權決定、假設和未驗證項。
- 覈對真實測試：看實際運行的測試命令和輸出，追問哪些邊界沒覆蓋。
- 讓 Agent 出題：基於本次 diff 出題自測，答錯的部分回到代碼裏讀清楚。
- 找一件漏檢的事：在 Agent 交卷後，主動找出至少一件它可能沒檢查到的事。
理解債自檢極簡 Prompt 示例
下面是最常用的“出題考我”Prompt，可以直接粘貼到 Claude Code、Cursor 或 Cline 的對話中使用：
在我合併這次改動之前，請先做兩件事：
1. 用不超過 10 條要點總結本次改了哪些文件、每處改動的原因。
2. 根據本次 diff 給我出 5 道題，重點覆蓋：事務/調用順序、
邊界條件、錯誤處理、對其他模塊的影響。
先只給題目，等我作答後再批改，並指出我答錯的地方對應哪段代碼。
規則：我沒有全部答對之前，不要建議合併。
查看完整的合併前提問 Prompt 模板
# 階段 A：開工前（償還意圖債，由我先填寫）
需求說明：
- 面向誰：
- 要解決的問題：
- 明確不做的事：
- 完成標準（做到什麼程度算完成）：
- 我預期的改動範圍和結果：
# 階段 B：任務結束後（請 Agent 逐條回答）
1. 你做了哪些我沒有明確授權的決定？請列出決定內容和理由。
2. 哪些地方依賴了你自己的假設？假設不成立時會發生什麼？
3. 還有哪些內容沒有驗證？
4. 哪些改動可能影響其他功能或模塊？
5. 你實際運行了哪些測試命令？請貼出原始輸出，而不是總結。
6. 哪些邊界情況沒有寫進測試？
# 階段 C：出題考覈（償還理解債）
請根據本次 diff 出 5 道題，先只給題目。
我作答後請批改，答錯的題請定位到具體代碼行。
我未全部答對前，不要建議合併。
# 階段 D：高風險改動追加（可交給另一個獨立會話）
請你作爲獨立審查者，不參考上一個會話的總結，
只基於原始需求和 diff，找出最可能出問題的 3 個地方。
🎯 使用建議：階段 A 一定要在開工前由你自己填寫，而不是讓 Agent 代寫。階段 D 建議新開會話，避免獨立審查者被前一個 Agent 的總結“帶節奏”，這也呼應了 Addy 關於多 Agent 傳話損耗的提醒。
合併前提問清單速查表
| 環節 | 必問問題 | 不合格信號 |
|---|---|---|
| 開工前 | 我能用自己的話說清需求和完成標準嗎？ | 寫不出“不做什麼” |
| 交付後 | Agent 做了哪些未授權決定？ | 回答“沒有”，但 diff 明顯超出範圍 |
| 測試 | 實際跑了哪些測試？沒測什麼？ | 只有總結，沒有原始輸出 |
| 考覈 | 出題我能全對嗎？ | 事務順序、邊界條件類題目答錯 |
| 收尾 | 我能找出一件它漏檢的事嗎？ | 一件都想不出來 |
讓 AI 出題考你 對比 驗收報告式審查
另一種截然不同的思路來自開源 Agent 協作平臺 LobeHub（GitHub 約 8.4 萬星）。據白鯨實驗室報道，該團隊自稱“已經幾乎不看代碼了”，核心看的是 Agent 的多模態驗收報告。他們使用自研並於今年 9 月開源的工具 Acceptance：Agent 交付前把需求拆成可直接觀察的檢查項，在真實產品裏逐項運行，配上截圖、錄屏和日誌，彙總成在線報告。人可以整體通過，也可以單獨退回某一項。
| 維度 | 讓 AI 出題考你 | 驗收報告式審查 |
|---|---|---|
| 關注對象 | 代碼內部邏輯、未授權決定、假設 | 產品外部可觀察行爲 |
| 證據形式 | 問答、批改結果 | 截圖、錄屏、日誌、命令記錄 |
| 能發現的問題 | 事務順序、邊界條件、隱性取捨 | 界面、交互、功能是否符合需求 |
| 容易漏掉的問題 | 你沒想到要出的題 | 不可見的內部邏輯與架構隱患 |
| 前提條件 | 開發者願意投入理解時間 | 需求能拆成可觀察檢查項，且有自動化執行環境 |
| 人的角色 | 理解並負責具體改動 | 定義驗收標準並做最終判斷 |
兩種審查思路的對標分析
驗收報告式審查的對標分析：驗收報告在可觀察行爲的驗證上效率很高，退回意見還能精確到單個檢查項。報道中的實測裏，審查者只退回了暗色背景一項，Agent 也只改了一行 CSS，其他文件未變。但它依賴需求能被拆成可觀察的檢查項，且報道同樣指出，更復雜的任務中安全、架構和最終質量仍需要人判斷，反饋回傳也還有需要人工處理的環節。“幾乎不看代碼”是團隊自述，未經獨立驗證。
出題考你的對標分析：出題考覈更擅長暴露事務順序、邊界條件這類“界面上看不出來”的問題，恰好覆蓋驗收報告的盲區。但它的上限取決於題目質量，也需要開發者真正投入理解時間。兩者並不互斥，更合理的做法是用驗收報告確認“做對了沒有”，用出題考覈確認“我懂不懂它爲什麼這麼做”。
按改動風險選擇理解債審查強度
不是每個 PR 都值得走完整流程。Addy 也提醒，當你生成的內容已經多到無法負責時，你做的就不再是審查，而是在賭它沒問題。下表給出一個按風險分級的參考，具體閾值需要結合團隊實際調整。
| 風險等級 | 典型改動 | 推薦審查強度 |
|---|---|---|
| 低 | 文案、樣式、獨立腳本、原型 | 驗收報告或手動點檢即可，記錄預期 |
| 中 | 普通業務功能、接口新增 | 追問未授權決定 + 覈對真實測試輸出 |
| 高 | 事務、權限、支付、數據遷移 | 完整 5 步流程 + 出題考覈 + 獨立 Agent 審查 |
| 超出負荷 | 多 Agent 並行產出、審不過來 | 補自動化檢查，或減少並行數量 |
💡 選擇建議：如果你所在團隊已經有成熟的自動化驗收，可以把出題考覈集中用在高風險改動上；如果沒有，至少在涉及數據一致性和權限的 PR 上堅持“答對才合併”。
常見問題 FAQ
Q1: 什麼是理解債？它和技術債有什麼區別？
理解債指代碼和系統複雜度不斷增長，而開發者對代碼的理解沒有同步增長。技術債通常是代碼本身質量不佳，理解債則可能發生在代碼質量不錯的情況下，問題出在“人不懂”，等到需要修改時才集中暴露。
Q2: 讓 AI 出題考你，和直接讓 AI 解釋代碼有什麼不同？
讓 AI 解釋，你是被動接收，很容易產生“看懂了”的錯覺。出題考覈要求你主動作答，答錯的地方會被定位到具體代碼，能把模糊的理解變成可檢驗的結果。
Q3: 別給 Agent 蓋章，是不是意味着要逐行審查 AI 代碼？
不是。據報道，Claude Code 團隊並不要求工程師記住整個代碼庫，需要修改某部分時會藉助 Claude 重新理解相關邏輯。關鍵前提是你清楚自己懂什麼、不懂什麼，並按風險決定審查深度。
Q4: 這套方法適合哪些開發場景？
主要適合以下場景：
– **長時間運行的 Agent 任務**：容易產生未授權決定，適合追問清單
– **涉及事務、邊界條件的後端改動**：適合出題考覈
– **多 Agent 並行開發**：適合保留原始材料並控制並行數
– **團隊協作的 Code Review**：可把提問清單寫進 PR 模板
Q5: 如何在 Claude Code、Cursor、Cline 中落地這套理解債自檢流程？
這套方法與具體工具無關，核心是 Prompt 和流程：
1. 把本文的完整 Prompt 模板保存爲團隊可複用的片段
2. 開工前手寫階段 A，任務結束後粘貼階段 B 和 C
3. 高風險改動新開獨立會話執行階段 D
也可以把“答對才合併”寫進團隊的 PR 檢查規範。
Q6: 這些方法有哪些已知限制？
需要客觀看待：
– **效果數據**：目前沒有公開數據證明這些方法能降低多少缺陷率或提升多少效率
– **時間成本**：完整流程會拉長合併週期，不適合所有 PR
– **題目盲區**：Agent 出題可能迴避它自己沒意識到的問題，所以“找一件漏檢的事”這一步不能省
– **來源說明**：Addy 觀點來自媒體轉述，原文措辭需自行覈實
Q7: 每週離線編碼練習真的有必要嗎？
Addy 的理由是長期不用的技能可能逐漸退化，偶爾脫離 Agent 獨立完成任務，能幫你校準真實水平。每月再盤點一次哪些技能已經交給 AI、哪些必須繼續掌握，成本不高但能防止認知投降悄悄發生。
別給 Agent 蓋章：理解債核心要點 Key Takeaways
- 認知投降是漸進的：從認知卸載到判斷讓渡，再到把判斷全部交出去
- 理解債在後面收利息：代碼越寫越快，不懂的部分會在修改時集中爆發
- 意圖債發生在上游：開工前自己寫需求清單，兩輪 Prompt 不滿意就重梳需求
- 出題考你是核心動作：讓 Agent 總結改動並出題，全部答對才合併
- 測試全綠不等於沒問題：先看實際執行的測試輸出，再追問沒測什麼
- 驗收報告與出題互補：前者驗證外部行爲，後者檢驗你對內部邏輯的理解
- 按風險分級審查：審不過來時補自動化或減少並行，別靠賭
總結
別給 Agent 蓋章的核心要點：
- 識別階段：警惕從“交給 AI 幹活”滑向“交給 AI 判斷”，理解債和意圖債都是這個過程的副產品
- 執行動作：開工寫預期，交付追問未授權決定和未測內容，合併前讓 AI 出題考你
- 分級取捨：低風險改動用驗收報告或點檢，高風險改動走完整流程並加獨立審查
AI 寫代碼的速度還會繼續提升，但爲改動負責的始終是批准它的人。下次點“批准”之前，不妨先讓 Agent 出 5 道題，看看自己能答對幾道。
📚 參考資料
- 量子位：Claude 工程師 Agent 大教程（36 氪轉載）：介紹 Addy Osmani 關於認知投降、理解債、意圖債的觀點與實操方法
- 鏈接：
36kr.com/p/4056027738116995 -
說明： 本文方法論主線的來源，屬於媒體轉述
-
Addy Osmani 原帖：報道中引用的原文出處
- 鏈接：
x.com/addyosmani/status/2117512471930167377 -
說明： 具體措辭請以原文爲準，鏈接需自行覈實
-
白鯨實驗室：一家 8 萬 Star 的 AI 公司，決定讓 AI 接管自己（36 氪轉載）：介紹 LobeHub 的主管 Agent 架構與 Acceptance 驗收報告實踐
- 鏈接：
36kr.com/p/4056040123945860 - 說明： 驗收報告式審查的對照來源，“幾乎不看代碼”爲團隊自述
作者: API易 技術團隊
