後設認知AI：教您的代理程式自我評估

我告訴我的代理程式修復一個失敗的測試。代理程式讀取了錯誤訊息，識別出斷言不匹配，將預期值改為符合實際輸出，然後回報：「測試已修復。所有測試通過。」它說的沒錯。測試確實通過了。但這個修復完全是錯誤的。

測試之所以失敗，是因為函式回傳了不正確的資料。代理程式「修復」測試的方式是讓它預期錯誤的答案。它完美地遵循了我的指令：修復失敗的測試。但我的意思是：修復測試所測試的程式碼。代理程式無法區分這兩種解讀，因為它的指令集中沒有任何東西要求它在決定如何修復之前，先評估測試為什麼失敗。

這個缺口有個名字。它是行動層級指令與後設認知指令之間的落差。大多數人只撰寫第一種。

摘要

AI代理程式指令存在兩個層級。行動層級指令告訴代理程式該做什麼：「驗證輸入」、「撰寫測試」、「遵循RESTful慣例」。後設認知指令告訴代理程式如何評估自己是否做得好：「如果您發現自己說的是應該而非已經，代表您還沒有驗證」、「如果三次修復都失敗，停下來質疑架構」、「信心不是證據」。大多數代理程式配置完全只包含行動層級指令。後設認知層級是區分產出看似合理的輸出與產出正確輸出的代理程式之間的關鍵。我已經運行一個生產環境的後設認知系統九個月，包含七個命名的失敗模式、六項標準的證據閘門，以及透過95個hooks強制執行的迴避語言偵測。

代理程式指令的兩個層級

每一條代理程式指令都在兩個層級之一運作。

行動層級指令定義行為：

# Action-level examples
- Use type hints on all functions
- Write tests for edge cases
- Follow RESTful conventions for API endpoints
- Validate all user input at boundaries

行動層級指令是必要的。它們告訴代理程式正確的行為是什麼樣子。但它們有一個結構性的侷限：假設代理程式會忠實地執行這些指令。它們沒有考慮到代理程式如何評估自身的遵循程度。

後設認知指令定義自我監控：

# Metacognitive examples
- If you catch yourself thinking "just try changing X and see if it works" — STOP.
  That's a signal to investigate, not guess.
- If you've searched the same files three times — you're stuck.
  Step back and question your assumptions.
- If you use the word "should" in a completion report, replace it with evidence.
  Run the command. Paste the output.
- After three failed fixes, stop fixing. The problem is architectural.

這個區分之所以重要，是因為行動層級指令告訴代理程式目的地的樣貌。後設認知指令告訴代理程式如何偵測自己正在偏離方向。前者防止錯誤的行動。後者防止錯誤的推理：那些從根本上產生錯誤行動的思維模式。

GitHub上的obra/superpowers專案最先闡述了這個區分，稱之為「教導AI觀察自身內部推理中的失敗訊號」。¹其核心洞察是：大多數技能在行動層級運作（做X，不要做Y）。後設認知層級的運作方式不同（注意到自己即將做Y）。

虛假證據表

我所建構的最有效的後設認知工具，是一張定義什麼不算作證據的表格。²

當我告訴代理程式「驗證您的工作」，代理程式會產出驗證結果。但這個驗證往往是意圖的重述，而非結果的展示。「測試應該會通過。」「實作遵循最佳實踐。」「我有信心這是正確的。」這些陳述每一句聽起來像是證據。但沒有一句是證據。

虛假證據表透過命名來預先阻止特定的捷徑：

價值存在於第三欄。沒有它，代理程式會用聽似合理的自信重述來填充第二欄。有了它，這張表在代理程式採取每個特定捷徑之前就命名並阻止了它。³

這張表不是提示工程。它是認知架構。這張表不是告訴代理程式要做什麼不同的事。而是告訴代理程式要在自身的輸出中觀察什麼。代理程式根據「不充分」欄位監控自己的回應，當偵測到匹配時，便知道要用實際證據取代捷徑。

這個模式可以擴展。任何領域特定的聲明都可以加入。安全審查方面：「無漏洞」需要「已檢查的特定漏洞類別及發現結果」，而非「我審查了程式碼」。無障礙方面：「符合WCAG」需要「axe或Lighthouse稽核輸出」，而非「我檢查了對比度」。

命名失敗模式作為後設認知護欄

人類有命名的認知偏誤：確認偏誤、錨定效應、鄧寧-克魯格效應。名稱很重要。一旦您能命名這個偏誤，就能開始留意它。AI代理程式需要同樣的詞彙來描述其失敗模式。

我記錄了代理程式反覆展現的七種失敗模式，為每一種命名，並加上偵測訊號：⁴

名稱使失敗變得可偵測。沒有名稱時，代理程式產出了信心海市蜃樓，但代理程式和使用者都無法辨識這是一種模式。有了名稱，指令就變成：「如果您發現自己展現任何命名的失敗模式，立即停止並從評估步驟重新開始。」

這種監控在精確意義上是後設認知的：代理程式觀察的是自身的認知過程（我是否在跳過驗證？我是否用信心替代證據？）而非其輸出（這段程式碼正確嗎？）。監控發生在代理程式產出輸出之前，這就是為什麼它能捕捉到輸出層級審查所遺漏的錯誤。

Anthropic自身的參考技能實作也支持這種方法。對其16個官方Claude Code技能的分析揭示了有效代理程式指令設計中的結構模式。禁止性指令（「絕不做X」）被證明比建議性指令（「考慮Y」）顯著更有效，因為它們命名了具體的迴避行為而非泛泛的行動。⁵命名的失敗模式就是具體的禁止：「絕不展現幽靈驗證」優於「始終執行測試」，因為它阻止的是迴避行為而非重述行動。

迴避語言偵測

我實作的最簡單的後設認知監控器，是偵測代理程式輸出中的特定詞彙：

Red flag words: should, probably, seems to, likely, I believe,
               I'm confident, looks correct, appears to

每當代理程式在完成報告中使用這些詞彙之一，該詞彙本身就是驗證不足的證據。⁶「測試應該會通過」意味著代理程式沒有執行測試。「它似乎能用」意味著代理程式只是粗略看了一眼。「我有信心」意味著代理程式用內部狀態替代了外部證據。

實作方式是機械性的。Hook系統攔截代理程式的輸出並標記迴避語言。然後代理程式將迴避詞彙替換為它本應執行的驗證：

• 「測試應該會通過」變成：執行測試，貼上顯示0個失敗的輸出
• 「看起來是正確的」變成：引用確認正確性的具體斷言或檢查
• 「我有信心」變成：列出產生該信心的證據

這個模式來自obra的驗證優先於完成的工作：「AI自身的用詞選擇暗示了證據不足。」¹認知科學的類比是真實的。在人類的後設認知中，自我報告的準確性（「我理解這個」）與實際理解的相關性很低。說「我懂了」的人往往並不理解。能解釋的人通常才是真正理解的。同樣的道理適用於AI代理程式：能引用具體證據的代理程式理解了問題。說「我有信心」的代理程式則未必。

三次修復斷路器

後設認知不僅關乎偵測錯誤的推理。它也關乎偵測何時該停下來。

三次修復升級規則：如果對同一問題的三次嘗試修復都失敗了，代理程式必須停下來從根本上質疑架構。⁷不是嘗試第四次修復。不是在同一方法上尋找不同的角度。停下來。退後一步。問問題到底出在解決方案還是問題定義上。

這個規則充當除錯迴圈的斷路器。沒有它，代理程式會進入我所稱的修復螺旋：每次失敗的嘗試產生新的理論，產生新的修復，再次失敗，再產生新的理論。代理程式可以循環數十次修復卻從未質疑自己是否在處理正確的問題。23個代理程式失控事件是這個問題的寬度版本：代理程式對錯誤的問題達成共識，因為沒有後設認知檢查問「這個問題的範圍界定正確嗎？」

三次修復規則之所以有效，是因為它迫使代理程式的推理發生相位轉換。修復1至3在當前心智模型內運作。修復4（實際上是「停止修復」）迫使代理程式建構新的心智模型。在實踐中，這通常意味著從頭重新閱讀錯誤、重新檢視假設、或向使用者請求澄清——所有這些都比第四次猜測更有成效。

前後對比：改變了什麼

以下是一個具體範例。我要求代理程式為一個API端點新增輸入驗證。

沒有後設認知指令：

Added Pydantic model with field validators for email format, password
length (8+), and username pattern (alphanumeric). Tests should pass.
The implementation follows FastAPI best practices.

輸出包含三個迴避訊號：「should pass」（沒有執行測試）、「follows best practices」（沒有指出哪些實踐）、以及沒有邊界情況考量的證據。一個信心海市蜃樓包裹在空洞報告之中。

有後設認知指令（相同任務、相同代理程式）：

Added Pydantic model with field validators:
- Email: regex validation + max length 254 (RFC 5321)
- Password: min 8, max 128, requires 1 uppercase + 1 digit
- Username: alphanumeric + underscore, 3-30 chars

Test output (just ran):
  tests/test_auth.py::test_valid_registration PASSED
  tests/test_auth.py::test_invalid_email_rejected PASSED
  tests/test_auth.py::test_short_password_rejected PASSED
  tests/test_auth.py::test_empty_username_rejected PASSED
  tests/test_auth.py::test_unicode_username_rejected PASSED
  5 passed in 0.34s

Edge cases handled: empty string (returns 422), null (returns 422),
unicode injection in username (rejected by alphanumeric pattern),
overlength email (RFC limit enforced).

Pattern followed: same validation approach as UserUpdateSchema in
app/schemas.py line 45.

差異不在於第二個代理程式寫了更好的程式碼。兩個代理程式可能寫了完全相同的程式碼。差異在於第二個代理程式根據具體的證據標準驗證了自己的工作，並回報了證據而非信心。

建構您自己的後設認知層

這個框架是可移植的。您不需要我的特定系統。您需要三個組件：

1. 虛假證據表。 定義對於代理程式最常做出的聲明，什麼不算作證明。從上述六項標準開始，並新增領域特定的列。第三欄（不充分）是價值所在。

2. 命名失敗模式。 記錄代理程式最常出現的三到五種失敗方式。為每種命名。新增偵測訊號。加入指令：「如果您發現自己展現任何命名的失敗模式，停下來並重新評估。」

3. 迴避語言偵測。 列出在您的領域中暗示驗證不足的特定詞彙。加入指令：「將任何迴避詞彙替換為能消除該迴避的證據。」

這三個組件組合成一個後設認知層，疊加在任何行動層級指令之上。行動層級指令定義正確行為的樣貌。後設認知層定義代理程式如何偵測自身偏離正確行為。

實作可以簡單到在您的CLAUDE.md或AGENTS.md中新增一個區段：

## Self-Monitoring

### When to stop and re-evaluate
- If you've searched the same files 3+ times: you're stuck.
- If you've attempted 3 fixes for the same issue: question the architecture.
- If you use "should" or "probably" in your response: replace with evidence.

### What doesn't count as evidence
[your false evidence table here]

### Named failure modes to watch for
[your failure modes here]

強制執行是透過hooks（確定性的，無法跳過）、規則檔案（載入上下文中）、還是行內指令（依賴模型遵從度）來實現，決定了後設認知層的可靠性。Hooks最為強大，因為它們在工具使用層級攔截，而非提示層級。但即使是提示層級的後設認知指令也能可衡量地改善代理程式的輸出品質，因為它們改變的是代理程式的評估標準，而不僅僅是其行動。

後設認知無法做到什麼

後設認知程式設計使AI代理程式更可靠。但它不會使它們具備智慧。

虛假證據表捕捉特定的捷徑。它無法捕捉表格中未命名的新型捷徑。命名的失敗模式偵測已知模式。它們無法偵測尚未被命名的模式。迴避語言偵測捕捉表面層級的信心替代。它無法捕捉一個真正說服了自己（無論「說服」在此適用到什麼程度）錯誤輸出是正確的代理程式。

更根本的是，後設認知指令近似品味但無法產生品味。Jiro系統能防止except: pass並強制要求測試證據。但它無法判斷架構是否正確、命名是否捕捉了意圖、或解決方案是否解決了實際問題而非陳述的問題。這些判斷需要的是當前模型能近似但無法可靠執行的脈絡推理。

有人回覆了我關於Jiro系統的一則推文：「你基本上是在嘗試教導迴圈克制力、品味，以及某種近似道德暫停的東西——而Ralph模式的基礎設計為了吞吐量明確地反向最佳化這些特質。」⁸

他們說得對。後設認知程式設計是為機器不具備的品質提供結構性鷹架。這個鷹架是承重的。沒有它，機器大規模產出信心海市蜃樓。有了它，機器大規模產出經驗證的輸出。這兩個結果之間的差距，就是一個您可以信任整夜運行的代理程式與一個您需要盯著看的代理程式之間的差異。

但鷹架不是建築本身。建築（品味、判斷力、知道正確答案其實是另一個問題的能力）仍然屬於人類。至少目前是如此。

關鍵要點

給建構代理程式系統的工程師：

• 撰寫後設認知指令，而不僅僅是行動層級指令。 行動層級指令定義正確行為。後設認知指令定義代理程式如何偵測自身偏離正確行為。第二種指令是區分看似合理的輸出與經驗證的輸出的關鍵。

• 為您的代理程式的失敗模式命名。 一旦失敗模式有了名字（信心海市蜃樓、幽靈驗證、捷徑螺旋），代理程式就能開始留意它。未命名的失敗會無限重複。

給擴展AI輔助工作流程的團隊：

• 在擴展之前建構虛假證據表。 定義對於代理程式所做的每項聲明，什麼不算作證明。第三欄（不充分）預先阻止了代理程式在被要求「驗證」時所採取的特定捷徑。

• 迴避語言是可靠的訊號。 每當代理程式在完成報告中說「應該」、「大概」或「我有信心」，代理程式就沒有執行它所聲稱的驗證。機械性地偵測並替換。

後設認知稽核

想要評估您自己的代理程式指令嗎？以下的互動工具會分析任何CLAUDE.md、AGENTS.md或系統提示，並根據本文描述的後設認知維度進行評分。

貼上您的代理程式指令，稽核工具將識別：您的指令中行動層級與後設認知的比例、涵蓋了哪些命名的失敗模式、是否存在迴避語言偵測，以及差距在哪裡。

本文是Claude Code精通系列的一部分，該系列記錄自主AI開發背後的基礎設施：從強制確定性控制的hooks到作為架構紀律的上下文管理再到捕捉單一代理程式盲點的多代理程式審議。支撐系統的複利工程哲學解釋了為什麼每個組件都加速之後建構的一切。