一個「幫有 ASD 的朋友做個 skill」的請求，經過連續幾次 escalation（ASD skill → 整合三 profile → 建對外 Hugo 模組 + 4 篇文章 → 三輪 9-agent 審查 → 兩張 report 卡）滾成一整套對外知識庫基礎設施——本卡從這次協作事故抽出。真正的 anchor——「這是自用的、不需要對外可發現性」——直到最後一步才被講出來。若它早點浮現，審查份量會精實得多。限制：本卡談的是「任務會逐層 escalation 成基礎設施」的協作情境；單一、範圍清楚、不 escalation 的任務不需要 anchor 儀式，硬加反而是摩擦。

核心原則

當一個任務開始經過連續幾次「再加一層」滾大時，先把 anchor 講出來一次——這東西最終為誰、為什麼而做——再按它決定要蓋多少基礎設施。 anchor 決定 apparatus（蓋出來的基礎設施：模組、文章、審查輪、卡、交叉引用）的合理份量（自用的一個 skill vs 對外的一整套教材，該投的審查與周邊差一個量級）。但 anchor 有個時間特性：它傾向在最後才浮現，等基礎設施都蓋好了才被講出來。訊號是——每一次 escalation 都被平順地執行下去，卻從沒有人說過「這東西最終是要幹嘛、給誰用」。

亮出 anchor 是一次性動作，不是每個請求都質疑。連續 escalation 出現時亮一次、據以定份量，然後照常執行。

反模式：apparatus 的份量跟隨流程動能、而不是 anchor

兩個力量讓基礎設施悄悄長過需求：

• 產出感偏誤：蓋東西（多一個模組、多一輪審查、多一張卡）感覺像進度，回頭問「這值得蓋嗎」感覺像扯後腿。於是每個「要不要也加 X」都拿到「好」。
• 工具化偏誤（toolification）：執行者（尤其 LLM）傾向把「多加一個工具 / 檔案 / 流程」當成前進的形狀，較少停下來問「零工具或更小的份量夠不夠」。

兩者疊加，apparatus 最後的份量是被「流程的動能」決定的，不是被 anchor 決定的——每一步局部都合理，總量卻對不上這東西真正要幹嘛。事故實例：那套對外模組 + 三輪審查 + 兩張卡，對一個「自用 skill」的 anchor 是過量的；它們各自有價值，但那價值來自「順便餵知識庫」，不是來自被講出來過的 anchor。

修法：escalation 一出現就亮 anchor、按它定份量

1. 辨識 escalation 訊號：連續 2+ 次請求、每次都往上加一層基礎設施（模組、skill、審查輪、卡、交叉引用），而 anchor 從沒被明說。
2. 亮 anchor 一次：用一句話講「這東西最終為誰、為什麼、會不會對外」。這一句常常就翻轉份量判斷（自用 → 不需對外鏡像 / 不需三輪審查 / 不需公開卡）。
3. 按 anchor 重定 apparatus：把該蓋的份量對齊 anchor，不對齊流程動能。份量可以大（若 anchor 真的是「餵知識庫」），但那要是講出來的選擇、不是沒人決定過的累積。

這不是「每個請求都質疑」——那是另一種摩擦。亮 anchor 是 escalation 出現時的一次性閘門，亮完照常做。

跟其他原則的關係

本卡是 WRAP 決策框架（一套抗認知偏誤的決策方法）的 Anchor Check（決策前先釘住核心目標）在「多輪協作、任務逐層 escalation」場景的具體化——WRAP 開場就要求釘 anchor，本卡補的是「anchor 常在 escalation 中被跳過、要主動在 escalation 訊號出現時補釘」。

判讀徵兆

本卡從一次 skill 組合的執行落差抽出、且是自我示範：把 neurodivergent-output（塑形 AI 輸出的規則集）與 5w1h-decision（把決策拆成 Who／What／Why 等欄位的規則集）兩個 skill 同時啟用，兩者的協作設計明文寫了「帳本（每則回覆末尾累積的跨訊息決策記錄）的決策行、用壓縮的 5W1H 填寫」。實際執行時，只跑了神經多樣性的跨訊息帳本（顯著、視覺化），從沒把決策行套上 5W1H 的欄位結構（費力、不顯眼）——卻一路回報「兩個都開、協作啟用」。不是自己抓到，是使用者指出「只看到帳本、沒看到 5w1h」。限制：本卡談「組合的執行落差」，不是「組合的設計」（設計見 #235）；適用於「兩個以上行為被宣告同時生效」的情境，單一行為不涉及。

核心原則

組合兩個行為時，宣告「都啟用」不等於「都執行」——要在每個輸出點驗證兩半都真的現形，不是宣告了就算。 組合的兩半在執行時受力不均：顯著、省力、視覺化的那半會被做出來，費力、不顯眼、要額外轉換的那半會靜默掉。而執行者常憑「我開了兩個」就回報「兩個都在」——他查的是宣告，不是輸出裡的實際現形。宣告是必要條件、不是充分條件。而且光靠事後在輸出點檢查是偵測、不是預防——更強的做法是把費力那半接到一個本來就每次觸發的行為上，讓它跟著自動發生（見修法）。

反模式：顯著的那半當成整體的證據

失效鏈有三步：(1) 把組合寫進 skill / 規則（宣告協作）；(2) 執行時只做出顯著的那半；(3) 自審看到顯著那半在、就判「組合有跑」。事故實例：帳本（顯著）每則都出現，讓「協作啟用」看起來成立，但 5w1h 結構化（費力）從沒套上——顯著那半的存在被當成整個組合的合規證據。這跟 #147 規範化 ≠ 自審 同構：把規則寫下來（宣告）不等於遵守它。也是 #232 自審偵測方法要對齊規則類型 的實例——自審查「有沒有宣告啟用」、而不是「輸出裡有沒有現形」，對執行落差結構性失明。

另一種不對稱：有檢查表的擠掉沒有檢查表的

顯著與費力是一種不對稱，有沒有檢查表是另一種，而後者在設計審查維度時更常出現。

實測到的形態：一個 reviewer 同時被交付兩件事——比對宣告與實際內容（掃出所有「本站尚未寫」的宣告，逐條反證），以及走一次讀者路線（模擬帶著問題的讀者，記錄每一跳接不接得住）。前者接近可機械化，有明確的起點、終點與完成條件；後者不可自動化，而且要先固定讀者身分與起點才有判準。兩件並行時，reviewer 會先做有檢查表的那件，走路線那半在報告裡剩下幾句概括。

判別方式與「顯著／費力」那一組相同——看產出量的分布。兩個維度長期一邊多一邊少時，先問少的那一邊有沒有檢查表，而不是先假設它的問題比較少。

處置也相同：把沒有檢查表的那一半給它一個檢查表，或者拆給不同的執行者。走路線那一半的檢查表是逐跳表（帶著什麼問題離開 / 有沒有接住 / 答了沒有）加上「沒有逐跳表的『已走過』不成立」這條硬要求——有了它之後兩半才對稱。

修法：把費力那半接到會觸發的行為上，別只事後檢查

事後在輸出點檢查是偵測、不是預防——它仍然依賴你記得檢查、也依賴你一開始就做了那半。更強的修法是設計：讓組合的費力那半接到一個「本來就每次都會觸發」的行為上，跟著它自動發生、不靠記憶。

1. 把費力那半接到會觸發的顯著行為上（預防、優先）：找出組合裡「本來就每則都會跑」的那半（實例是跨訊息帳本），把費力那半寫進它的觸發點，讓費力那半的產出＝顯著那半產出的一部分，而不是另外要記得做的附加步驟。實例：把「決策行用 5W1H」寫進帳本規則本身（帳本每則都跑 → 5W1H 跟著每則跑），不放在一個獨立的 Collaboration 附錄——附錄會被跳過。
2. 降低費力那半的啟動成本：費力那半會靜默掉，一部分因為它費力。指定一個最小形式（如 What／Why／下一步三行、不帶完整鷹架），降低每次執行的門檻。
3. 事後逐半驗證當 backstop（偵測）：pre-send check 每個組合行為加一條「這則有沒有現形」，當接不進觸發時的最後一道。它是 backstop、不是主防線——別只靠它。

跟其他原則的關係

• #248 推翻一個假說之後，替補者是在驗屍的空檔裡上位的：本卡在假說層的形態。那裡多一層——沒有被套用的標準，是套用者自己剛剛才訂出來並用過一次的，所以「不知道有這條規則」這個藉口不成立，成因純粹是注意力已經花在前一個對象上。

判讀徵兆