本卡的論述基於 1 個 case（dart Stream 事故 的 review 過程跑 4 輪後仍漏 catch 4 類字句層問題）抽出來的假說。具體限制：

• 樣本量極小：「multi-pass review framework 顆粒度盲點」這個結論基於 1 次 review、不是多次跨主題 review 觀察到的 systematic pattern。可能是這個 reviewer（我）有特定盲點、不是 framework 本身的問題
• 三機制有效性未驗證：keyword bank / reader simulation / self-criticism 三機制是 proposed mechanisms、未實際跑下一篇文章驗證能 catch 之前漏掉的問題類型
• 「reader simulation 由同 reviewer 執行」的根本質疑沒解決：拿掉 code block 重讀、聽起來合理、但同一個人是否真能模擬「沒看過 code 的讀者視角」是疑問——記憶不會因為 code block 隱藏而消失。本卡提的修法是 partial fix、不是 root cause solution
• 「同一 reviewer 跑多輪 catch 高度相同」是直覺論述：沒有實證、是直覺推論
• 跟其他卡互相 cross-link 形成迴圈論證：本卡引 #110 / #111 / #113、但這幾張卡都源自同次事件、互相驗證有 selection bias 風險

讀者使用本卡時、把它當「從一次 review 失誤抽出的盲點假說」、不當「驗證過的 review framework 升級方案」。三機制是 starting point、有效性需要後續案例累積驗證。

核心原則

Multi-pass review 用「規則 frame」掃描、有效抓「結構性違反」（規則順序、論述結構、邊界段缺失）、但這次 case 顯示對「字句層的具體訊號」覆蓋不足——同個規則底下有大量具體訊號、reviewer 用記憶 sweep 容易漏掉一部分（這次 1 個 case 觀察、是否 systematic 有待累積）。

關鍵差異是「規則理解」vs「具體訊號比對」：

• 規則理解：reviewer 知道「正向陳述優先」這條規則
• 具體訊號比對：reviewer 要逐句檢查所有可能違反該規則的具體句型

抽象規則 → 具體訊號的轉譯沒做完整、就會 systematic miss 一整類字句層問題。

為什麼「規則 frame」抓不到字句層問題

問題 1：抽象規則沒展開成具體訊號清單

每條規則有大量可能的違反句型——例如「規則五：最重要的話優先說」可能違反句型：

reviewer 用「規則五」這個 frame 掃描、靠記憶找「這段有沒有違反規則五」——多半只 catch「觀察先 / 定義後」這個明顯 case、漏 catch 廢話前綴跟否定先行。

問題 2：缺乏 grep keyword bank

字句層問題有大量可 grep 的具體詞——但 reviewer 沒有 keyword bank、靠肉眼掃。例如：

每輪 review 用 grep 比對固定 keyword list、不靠 reviewer 記憶——能消除「靠記憶找違規」的 systematic miss。

問題 3：reviewer 自我審查的視角盲點

reviewer 讀自己寫的東西、會自動 fill in 上下文、感受不到讀者的真實閱讀體驗。例如：

• 「事件 payload 第二段帶了 X」——reviewer 寫的時候腦中有 code、知道「第二段」是什麼、感覺通順
• 讀者讀的時候沒有 code 在腦中、「第二段」是空的 reference、卡住

這個視角差異是 multi-pass review 的結構性盲點——同一個 reviewer 跑多輪、視角始終是寫作者視角、不是讀者視角。

問題 4：Multi-pass 缺 self-criticism 輪

每輪 review 都是 forward checking（這篇對齊規則嗎？）、沒做 backward critique（規則本身在這個情境是否夠細？有沒有 miss 的 frame？）。

如果規則框架本身不夠細、跑再多輪都掃不到 frame 之外的問題。

多面向：四類 missed 問題的分類

這次跑完 4 輪 multi-pass review、漏 catch 的 4 類問題：

Miss 類型 1：口語修辭（規則七 / 規則五的字句層子場景）

漏 catch 的具體訊號:「一輩子只能 listen 一次」「碰巧能用」「立刻撞牆」「啊原來」「炸了」

為什麼漏：「規則七：機會成本語氣」掃了「應該/必須/不行」、沒掃「一輩子/碰巧/撞牆」這類修辭詞。修辭詞跟絕對主義詞屬於不同 keyword set、reviewer 沒同時掃。

修法：建立「口語修辭 keyword bank」、輪 4「術語精度」加掃。

Miss 類型 2：地區漂移（規則四「術語」的子場景）

漏 catch 的具體訊號：「副屏」（中國用語、繁中應該用「副螢幕」）

為什麼漏：輪 4「術語檢查」聚焦在「中文 / 原文錨點」、沒掃「繁中 / 簡中漂移」。reviewer 預設「讀者地區」是台灣、但沒 explicit 用 keyword bank 比對。

修法：建立「地區用語對齊 keyword bank」（屏 / 默認 / 質量 / 視頻 / 文件 / 函數 / 介面 / 內存）、輪 4 加掃。

Miss 類型 3：依賴 code 論述（規則二商業邏輯先於 CASE 的延伸）

漏 catch 的具體訊號：「事件 payload 第二段帶了 X」「就好 / 就能」

為什麼漏：規則二被理解成「H2 後加商業邏輯導引」、沒延伸到「論述本身不依賴 code」。reviewer 寫的時候腦中有 code、感受不到「依賴 code」的閱讀體驗。

修法：加「reader simulation」frame——拿掉所有 code block、再讀一次論述、看是否仍能理解。

Miss 類型 4：廢話前綴 + 否定先行（規則五 + 規則六的字句層子場景）

漏 catch 的具體訊號：「下次看到 X 時、不要先想 Y」這類 hortative 結尾段

為什麼漏：規則五「最重要的話優先說」被理解成「核心原則先 / 例子後」、沒延伸到「廢話前綴 wrapper 句子」。規則六「正向陳述」被理解成「反例段落補正向錨點」、沒延伸到「『不是 A 而是 B』結構」。

修法：建立「廢話前綴 + 否定先行 keyword bank」、輪 5 加掃。

修補 multi-pass review 框架的三個機制

機制 1：Keyword bank（具體訊號清單）

每條規則展開成可 grep 的 keyword list、每輪 review 用 grep 比對、不靠 reviewer 記憶。

範例 keyword bank（節選）：

 1口語修辭：
 2  一輩子 / 永遠 / 碰巧 / 剛好 / 撞牆 / 炸 / 鎖死 / 啊原來 / 沒事 / 乾淨
 3
 4廢話前綴 / 否定先行：
 5  下次看到 / 下次寫 / 下次面對 / 下次遇到 / 不要先 / 不是 X 而是 Y
 6
 7地區漂移（繁中讀者）：
 8  屏 / 默認 / 質量 / 視頻 / 文件（當 file）/ 函數 / 接口 / 內存 / 視頻
 9
10依賴 code 訊號：
11  那個 / 這個 / 剛才的 / 上面的 / 第 X 段 / 就好 / 就能 / 就行

每篇文章 review 時跑這些 grep、把 hit 列出來、決定保留或修補。

機制 2：Reader simulation 輪

加一輪「假設讀者沒有上下文、能不能讀懂這段論述」、嘗試換視角。具體做法：

• 拿掉所有 code block 後重讀：論述是否 self-contained？
• 跳到段落中間直接讀：不依賴前文、能不能 parse？
• 隨機抽段給陌生讀者讀：cold-read 能不能拿到關鍵資訊？

已知限制：同一 reviewer 即使拿掉 code block、記憶仍在、無法完全模擬「沒看過 code 的讀者視角」。這個機制是 partial fix——能 catch 部分上下文依賴、但不是 root cause solution。最終解法仍需引入外部讀者反饋（cold-read by 真實讀者）。

機制 3：Self-criticism 輪

加一輪「我這份規則本身在這個情境是否夠細、有沒有 miss 的 frame？」、強迫 reviewer 反向審視框架本身。具體 prompt：

• 「我跑的 N 輪、catch 的問題類型有哪些？」
• 「同個規則底下、還有哪些可能違反句型沒被掃到？」
• 「如果讀者報告 X 類問題、是哪輪該 catch 但沒 catch？」
• 「framework 本身是否有 known blind spot？」

self-criticism 輪不是「再跑一次規則 frame」、是「檢視 frame 本身的覆蓋度」。

為什麼這些機制不能被「再仔細一輪」取代

「再仔細一輪」的同 frame 盲點

reviewer 跑同一個 frame 兩次、catch 的東西多半高度相同——因為視角、知識、注意力分配相同。（這是直覺論述、未做受控實驗驗證；但跟「換 frame」的設計動機一致——multi-pass 的核心就是「同 frame 重看 catch 不到新問題」）Multi-pass review 的核心是「每輪換 frame」、不是「同 frame 多跑幾次」。

但換 frame ≠ 換規則——reviewer 可能換規則但用同樣的視角、同樣的記憶 sweep、catch 的東西相同。要真正換 frame、需要：

• 換工具：keyword bank 取代肉眼掃（機制 1）
• 換視角：模擬讀者取代 reviewer 視角（機制 2）
• 換層次：審視 framework 取代套用 framework（機制 3）

三個機制各自處理「同一 reviewer 跑多輪仍 miss」的不同來源。

Hindsight 視角的反向印證

#110 設計檢討用當下三軸論證、不依賴 hindsight 的核心議題是「事後諸葛論述」會混淆「設計缺陷 vs 需求演化」。同樣的 hindsight 風險也存在於 review 流程：

• Hindsight 視角：「讀者反饋了 → 補進規則」——把規則當成「事故後補的 patch」
• 當下三軸視角：「framework 本身是否夠細到 catch 這類問題？」——把 framework 當成預設工具、用 self-criticism 反向審視

兩種視角的差別跟 #110 的差別同骨：前者依賴結局（讀者反饋）、後者用當下框架審視（self-criticism）。

識別訊號：什麼時候你的 review framework 不夠細

訊號 1：讀者反饋的問題類型在 framework 裡找不到對應 frame

讀者指出「廢話前綴」問題、reviewer 翻 framework 找對應 frame——找到「規則五最重要的話優先說」、但這條規則沒展開到「廢話前綴」這個具體子場景。

修法：把問題類型加進 framework 的 keyword bank、下次同類問題能被 grep catch。

訊號 2：跑了 N 輪、相同類型的問題仍重複出現

字句層問題（口語修辭、地區漂移）跑了 4 輪 review 仍漏——表示 framework 沒 catch 這個層次。

修法：加 keyword bank（機制 1）、不靠 reviewer 記憶。

訊號 3：reviewer 自我審查感覺通順、讀者反映卡住

「事件 payload 第二段」對 reviewer 通順、對讀者卡住——視角差異。

修法：加 reader simulation 輪（機制 2）。

訊號 4：相同 framework 跑不同主題、catch 的問題類型差異不大

framework 不會自我批判——跑 100 篇文章、catch 的都是 framework 內的 frame、framework 外的問題永遠看不見。

修法：加 self-criticism 輪（機制 3）、定期審視 framework 本身的覆蓋度。

何時不需要這些補強機制

「multi-pass review 需要 keyword bank + reader simulation + self-criticism」這條原則在 production 教學文章 / 設計檢討文章成立、但有合理例外：

判讀：寫之前自問「這篇文章的讀者群有多大？字句層問題擴散的代價有多高？」——大 / 高 → 嚴格用三機制；小 / 低 → 可放寬。

跟其他抽象層原則的關係

判讀徵兆

核心原則：multi-pass review 用「規則 frame」掃描有效抓結構性違反、抓不到字句層具體訊號。要 catch 字句層、需要把規則展開成 keyword bank、加 reader simulation 視角、加 self-criticism 反向審視 framework 本身——三個機制各自處理同 reviewer 跑多輪仍 miss 的不同來源。

Self-case：本卡的觸發來源

本卡的觸發是修 Dart StreamController：single-subscription vs broadcast 的事故實錄 時、跑了 4 輪 multi-pass review 後仍漏 catch 4 類字句層問題、由讀者點出。

讀者反饋的問題類型：

1. 口語化修辭（「一輩子只能 listen 一次」「立刻撞牆」「啊原來」「碰巧能用」）
2. 地區用語漂移（「副屏」是中國用語、台灣用「副螢幕」）
3. 依賴 code 論述（「事件 payload 第二段帶了」預設讀者看過 code）
4. 廢話前綴 + 否定先行（「下次看到 X 時、不要先想 Y、先問 Z」）

這 4 類問題對應的 frame 在 framework 裡都有（規則七機會成本、輪 4 術語、規則二商業邏輯、規則五最重要的話優先說）——但都沒展開到具體訊號層、所以 reviewer 跑了 4 輪都漏 catch。

對應本卡：framework 的覆蓋度盲點不能靠「再仔細一輪」修補——同一 reviewer 跑同 framework 多輪、catch 的東西高度相同。要真正擴大覆蓋度、需要 keyword bank（換工具）+ reader simulation（換視角）+ self-criticism（換層次）三個機制。

對 multi-pass review framework 的修補方向：把這 4 類問題加進對應 frame 的 keyword bank、加 reader simulation 輪當輪 8、加 self-criticism 輪當輪 9（或在每輪結尾加 self-criticism 子段）。

字句層 review 有兩個獨立步驟：偵測（這句有沒有命中可疑訊號）跟判定（這個命中是不是違規）。keyword bank 解的是偵測、判定仍是一個獨立的語意認知步驟。 reviewer 拿到 grep 命中後、傾向把它合理化成「這個 case 可以接受」而放行 — 偵測成功、判定失敗、違規一樣留在稿件裡。

#114 把字句層 review 的失敗歸到偵測層（沒 keyword bank、靠記憶 sweep）。本卡補它沒覆蓋的另一層：就算 grep 命中、reviewer 仍可能判錯。命中只是候選、不是判決。

情境

寫作規範「正向陳述優先」（主要敘述用正向句建立概念、反例只做對照）的 review、跑 grep 不[行可是要能]|無法|沒[做有]|而非|而不是。這個 bank 會命中兩類完全不同的句子：

• 建立概念的否定：「高階函式不是『用了比較高級』、而是特定場景的自然解」 — 用否定當核心概念的開場、違反正向陳述。
• 反例對照的否定：「對照反例：假設一個只有單一布林設定的 controller…既沒有共用流程、也沒有開放的變化點」 — 在明示的反例段落裡、否定是對照本身、規範允許。

兩者 grep 命中長得一樣、語意角色相反。reviewer 掃命中清單時、若用「這裡有對照意味、應該算反例」的寬鬆預設、會把第一類也放行 —— 這正是本卡的 case：grep 命中了「不是…而是」、被判成「正向對照修辭、OK」、由讀者再次 feedback 才 catch。

另有一類問題連命中都沒有：訴諸群體的安撫贅語（「很多人卡在…」「大家都會搞混…」）。這類句子沒有固定關鍵詞（「很多人 / 大家 / 不少開發者 / 初學時」表面形式發散）、keyword bank 結構上抓不到、只能靠語意 pass。

理想做法

否定句構命中後、用「概念位置」判定、不用「有沒有對照意味」判定

判別問題從「這句有對照意味嗎」（太寬、幾乎都 yes）換成 「這個否定在建立核心概念、還是在明示的反例段落裡做對照」：

關鍵修法是正向直述 B：「X 不是 A、而是 B」→「X 是 B」、把 A 的排除留給上下文或反例段。把「不是 A」翻成「而非 A」只是換個負向詞、仍違規。

這條判定準則剛好夾在兩張既有卡之間：#94 警告「別過度刪對照（刪掉承擔 reasoning 的 Y 會讓結論空降）」、正向陳述優先要求「別保留建立概念的否定」。判別線就是上表的「概念位置」—— 概念開場的否定該刪、反例段落的對照該留。

沒有關鍵詞的贅語、靠 reader-simulation 補

訴諸群體的安撫贅語抓不到固定關鍵詞、改用「換視角」pass：假裝讀者、問每一句「這句給了新資訊、還是只在安撫我（讓我覺得不是只有自己不會）」。教學文的責任是把概念講清楚、不是安撫讀者情緒 —— 安撫句一律刪、保留有教學價值的聚焦（「要分清什麼」）。

沒這樣做的麻煩

規範掃描器顯示「乾淨」、違規仍在

跑完 grep、把命中逐條判成「可接受」、回報「字句層 clean」 —— 這個 clean 是 judgment 放水的結果、不是真的沒違規。比「沒跑 grep」更危險：沒跑還知道沒查、跑完誤判會產生「已經查過」的虛假信心。

違規類型有系統性偏移

被合理化放行的是特定一類（建立概念的否定句構），有系統性偏移。同一個寬鬆預設會在每篇文章放行同一類違規 —— 跨稿件累積成 systematic miss、跟 #114 的偵測層 systematic miss 同構、只是發生在判定層。

keyword bank 越長、judgment 放水越隱形

bank 補得越完整、命中越多、reviewer 越依賴「快速掃過命中清單」、每條停留判定的時間越短、越容易用寬鬆預設批次放行。偵測能力提升反而稀釋判定品質 —— 兩層要分開要求、不能假設「有 bank 就會判對」。

跟其他抽象層原則的關係

• #114 Multi-pass review 的 frame 顆粒度盲點：#114 解偵測層（把規則展開成 keyword bank、不靠記憶 sweep）。本卡是它的下一層 —— 就算 bank 命中、判定仍可能放水。#114 的 keyword bank 範例已收「不是 A 而是 B」、但收進 bank 只保證命中、不保證判對；本卡補「命中後怎麼判」。訴諸群體贅語則是 #114 bank 該補的新 coverage（無固定關鍵詞、靠 reader-simulation）。
• #94 正向改寫要保留對照論據、不能空降結論：#94 跟本卡是同一判定軸的兩極。#94 防「過度刪 —— 刪掉承擔 reasoning 的對照 Y、結論變空降」；本卡防「過度留 —— 保留建立概念的否定、用『這是對照』當藉口」。兩卡合起來才是完整判定準則：以「概念位置」區分該刪（概念開場）還是該留（反例段落 / reasoning 對照）。
• #147 規範化跟自審是兩種認知任務：#147 講「立了規範 ≠ 能在自己稿件辨識實例」。本卡是更細一層 —— 連 grep 命中（自審的最強形式、已經指到具體句子）都可能因判定放水而失效。#147 的三層機制（grep / checklist / reviewer in-stream）裡、本卡聚焦 grep 那層的「命中之後」缺口。
• #82 字面攔截 vs 行為精修：grep 命中是字面層攔截、看不到那個否定承擔的是「建立概念」還是「反例對照」 —— 需要 behavioral pass（讀者讀到這句、是拿到正向概念還是被否定句卡住）才能判。本卡是 #82 在「字句層 review 判定」的具體實例。

判讀徵兆

適用範圍與邊界

• 適用：正向陳述優先這類「同一訊號命中、語意角色相反」的字句層規範 review；AI 輔助寫作的 self-review（最容易在判定層放水）；keyword bank 已建立、但 review 回報品質仍不穩的情境。
• 不適用：偵測本身就漏（關鍵詞不在 bank）的問題 —— 那是 #114 的偵測層、先補 bank 再談判定。
• 邊界：判定收緊 ≠ 一律刪否定。明示反例段落的對照（#94 的 reasoning Y）該留；判別線是「概念位置」、不是「有沒有否定詞」。收太緊會退回 #94 警告的「空降斷言」。

Self-case：本卡的觸發來源

本卡觸發於 review 為什麼這個場景適合用高階函式 時。流程是先跑 3 個 frame 的 multi-round review + 字句層 grep keyword bank：

1. grep 命中了核心議題句「高階函式不是『用了比較高級』、而是特定場景的自然解」跟小節開場「不是『能用就用』、而是…三個特徵」。
2. 我把這些命中判成「正向對照修辭、OK」、回報「字句層大致乾淨」。
3. 讀者 feedback 指出這仍違反正向陳述 —— 偵測成功、判定失敗。
4. 修正後讀者再指出「很多人卡在…」是訴諸群體的安撫贅語 —— 這類連 grep 都沒命中（無固定關鍵詞）。

對應本卡：keyword bank 命中是候選、不是判決。第一類（命中誤判）揭露判定層盲點、第二類（無命中）揭露 coverage 仍需 reader-simulation 補。兩者共同說明：字句層 review 的偵測（grep）跟判定（語意）是兩個步驟、不能假設「跑了 bank 就會判對、就會抓全」。

本卡是一次 review 失誤的 self-retrospective（用 WRAP 的 Consider the Opposite 反向檢驗自己的 review 過程）抽出。具體限制：

• 樣本是 1 次 review、1 個 reviewer（我自己）：「design gap vs execution gap」這個二分基於單次自我檢討、不是跨多次 review 觀察到的 systematic pattern。
• 「自我歸因」有 self-serving 風險：reviewer 檢討自己漏抓時、可能傾向把責任推給「框架不足」（design gap）而非「我偷懶」（execution gap）—— 本卡的價值正是強迫拆開這兩者、但拆的人就是當事人、客觀性有限。
• 修法有效性未驗證：診斷後的修法（改框架 vs 改執行）是否真能讓下次 catch 到、未經後續 review 驗證。

讀者使用本卡時、把它當「review 失誤歸因的一個檢查步驟」、不當「驗證過的 review 流程」。

核心原則

Review 漏抓某類問題時，先分清是 design gap 還是 execution gap，再決定修法 —— 兩者修法相反。

• Design gap：框架根本沒有對應的 frame / keyword 去 catch 這類問題。修法是改框架（補 frame、補 keyword bank、補 lens）。
• Execution gap：框架有對應 frame、但 reviewer 這次沒跑（跑了子集、跳過該跑的輪）。修法是改執行（真的跑完該跑的輪），改框架沒用。

同一次漏抓常常兩者都有 —— 要分別處理、不能只修一邊。

具體 case

這次 review 一篇技術教材、跑了「3 個臨時擬的 agent frame + 一次字句層 grep」、回報「字句層大致 clean」。結果使用者分多輪 catch 出 register/stance 類問題（安撫讀者 / 第二人稱 / 自評誇飾 / 必然框架）。用 WRAP Consider the Opposite 反向檢驗，發現兩種 gap 都有：

Execution gap（我沒跑完整框架）

multi-pass review 框架定義了輪 9（reader simulation）、輪 10（self-criticism），但這次我根本沒跑 —— 只跑了我臨時擬的 3 個 agent frame + grep。如果跑了輪 9（用讀者視角讀「這段在跟我說話嗎」），喊話類當場會 catch。這部分不能怪框架、是我跑了子集。

Design gap（框架本身的 frame 不夠）

但即使跑了輪 9、現有定義是「拿掉 code block 看論述能不能 parse」（聚焦自包含性）、沒有 register lens（這段在管理 / 評價 / 絕對化讀者嗎）。而且 register 類有兩個結構特性讓 keyword bank（輪 8）抓不到：

• 無穩定關鍵詞：第二人稱「你」誤命中 code 註解、祈使句式發散、訴諸群體形式多。
• 最依賴外部 cold-read：這次正是**使用者（外部讀者）**才抓到 —— 同一 reviewer 模擬讀者視角有限（per multi-pass 自承的 partial fix 限制）。

這部分要改框架：輪 9 擴入 register lens、標明 register 類「reader-sim 主、keyword bank 輔」。

沒這樣做的麻煩

只改框架：framework bloat、execution 習慣沒解

漏抓後直覺反應是「加 keyword / 加 frame」—— 因為這看得見、像進步。但若真正成因是 execution gap（沒跑輪 9）、加再多 keyword 都沒用（那些輪還是沒跑）。框架越加越胖、reviewer 還是偷跑子集。

只改執行：漏掉的整類永遠 catch 不到

反過來、若把 design gap 誤判成「我下次認真跑就好」、但框架根本沒有對應 frame —— 認真跑現有的輪也 catch 不到、同類問題每次都漏。

「加 keyword」是最誘人的假修法

加 keyword bank 條目成本低、立即有「補上了」的感覺。但它只解 design gap 的一個 sub-type（偵測層、且限有穩定關鍵詞的類）。對 execution gap（沒跑輪）、對 register 這種無關鍵詞的 design gap、它都無效 —— 容易讓人以為修好了、其實沒。

跟其他抽象層原則的關係

• #114 Multi-pass review 的 frame 顆粒度盲點：#114 處理的是 design gap 的一個面向（frame 不夠細、抽象規則沒展開成具體訊號）。本卡是上位 —— 在「改 frame 顆粒度」之前、先問「這次漏抓到底是缺 frame（design）還是沒跑 frame（execution）」。#114 預設問題在框架、本卡先驗證這個預設。
• #147 規範化跟自審是兩種認知任務：#147 是 execution 側的 sibling —— 「立了規範 ≠ 自己稿件能辨識」講的就是「有 frame 不等於有跑」。本卡把它一般化成「有 frame 不等於有跑（execution gap）」、並跟「根本沒 frame（design gap）」對立起來。
• #149 keyword bank 命中是候選、不是判決：#149 是另一個「兩層別混」的 pattern（偵測 vs 判定）。本卡（design vs execution）跟 #149（偵測 vs 判定）都在拆「review 失效的成因層」—— 修法都依賴先分層、再對症。
• #150-152 教材 register / framing 卡：這三張是本卡的觸發 case（漏抓的具體內容）。本卡是它們揭露的 review 流程層 教訓 —— 內容卡講「該怎麼寫」、本卡講「review 為什麼沒抓到、該改框架還是改執行」。

判讀徵兆

適用範圍與邊界

• 適用：review 流程的 retrospective（漏抓後檢討）、framework 演進決策（要不要加 frame / keyword）、self-review 品質檢討。
• 不適用：一次性短文 review（沒有「框架」可言、談不上 design vs execution）。
• 邊界：兩者不互斥、常同時存在 —— 本卡要的不是「二選一」、是「分別診斷、分別修」。誤把它當 either-or 會只修一半。

Self-case：本卡的觸發來源

本卡觸發於對 HOF / typedef 文章 的 review 失誤做 WRAP 檢討。使用者問「多輪審查設定是否需要調整」，WRAP 的 Consider the Opposite 步驟揭露：失敗不全是框架缺陷 —— 一半是我只跑了臨時子集、跳過框架既有的輪 9/10（execution gap）、一半是輪 9 定義聚焦自包含性、缺 register lens、且 register 類無穩定關鍵詞（design gap）。

對應本卡：若沒做這個拆分、最可能的反應是「再加幾個 keyword」（只解 design gap 的偵測 sub-type）、既沒解 execution gap（下次還是偷跑子集）、也沒解 register 的 reader-sim design gap。拆開後修法清楚：execution gap 靠「review 時真的跑完該跑的輪」（紀律、不改框架）、design gap 靠「輪 9 擴 register lens + 標明 external-reader 依賴」（改框架、下一步執行）。

寫作規範的違規分兩類、判定性質根本不同。形式違規（emoji、編號、broken link、裸 URL、frontmatter 缺欄）可完全機械判定、命中即違規、該進工具鏈。register / 品味違規（核心概念前置、否定起手、喊話、誇飾、口語修辭）的判定有不可消除的品味核心、偵測可機械化但判定不可。

「不是 X、而是 Y」是 register 違規裡最隱蔽的一種、因為它的偵測可機械化（句型明顯、grep 抓得到）、這個「偵測可機械化」偽裝成「判定也可機械化」。被這個偽裝誤導、就會無限投入更精緻的判定方法（補 grep → 概念位置判準 → 行為測試）、而判定（這個否定在建立概念還是做對照）本質是品味判斷、始終在品味側、始終放水。

後續校正（見 #166 重點優先陳述是跨語言的資訊結構原則）：「不是 X、而是 Y」這個子集後來被釐清為資訊結構問題（重點後置）、不是純品味 —— 判定其實可操作（核心概念第一次正面出現在不在句首）、主解是強制執行重點位置判準、異源視角降為補充。本卡論的「品味核心 / 同源上限 / 異源為真防線」對喊話、誇飾這類無單一重點位置的 register 仍成立、但對「重點優先」這個可操作子集是過度推論。

為什麼 register 違規的判定不可機械化

判定要回答「這個句子讀起來對不對」、這是品味問題、品味需要一個會讀的主體去感受、沒有可機械化的判準能取代。「不是 X、而是 Y」的判定要區分兩種角色：

• 建立核心概念的否定（違規）：「外包一塊能力不是二元、而是有深度的」—— 核心概念「有深度」被擠到「而是」之後、句首先丟一個被否定的錯誤理解。
• 反例對照的否定（合規）：在明示反例段落裡、否定就是對照本體（見 #94）。

兩者 grep 命中長得一樣、語意角色相反。要判對、reviewer 得讀懂段落結構、感受核心概念的位置 —— 這是品味判斷。任何想把它機械化的嘗試都只是換個地方做品味判斷：「概念位置判準」要判斷哪句是概念句、「刪除測試」要判斷剩下的概念完不完整、終點都回到「這讀起來對不對」。偵測的可機械化掩蓋了這個事實。

同源自審的結構上限

更深一層的原因、解釋了為什麼再多輪 LLM 審查都跨不過：產出 register 違規的主體跟審查它的主體共享同一套文體直覺。「不是 X、而是 Y」是 LLM 高頻自產的定義句型、LLM reviewer 讀到它「讀起來自然、權威」、違規感不觸發 —— 作者的盲區跟 reviewer 的盲區是同一個。

這讓 register 違規的同源自審有結構上限。加 reviewer 數量、加審查輪次、換 frame、都在同一套文體直覺內打轉、跨不過盲區。要看出 register 違規、需要一雙「不共享作者文體」的眼睛。

這條上限是 #149（命中後判定會放水）跟 #147（立規範不等於自審執行）的共同根因：#147 的修法是「立規範當下轉 grep + sweep」、#149 的修法是「命中後用概念位置判定」、兩個修法都還在自動化側、對 register 違規都攔不住、因為判定的品味核心要異源的眼睛才感受得到。

理想做法

把違規先分類、再配對應的防線。

第一步：分類 —— 這個違規在哪一側

問一個判別問題：「這條規則的判定、是命中即違規（確定性）、還是要讀懂句子讀起來對不對（品味）？」確定性的進工具鏈、品味的進異源審查。emoji、編號、broken link 在確定性側；概念前置、否定起手、喊話、誇飾在品味側。

第二步：register 違規 —— 偵測機械化、判定靠異源

偵測仍用 grep、但定位是「曝光候選給異源視角抽查」、產出不是「自動判定違規」。判定交給文體異源的眼睛：

第三步：接受 100% 自動 catch 不可能

把 register 違規的審查目標設成「曝光候選 + 異源抽查」、而不是「自動判定 clean」。回報時誠實標「register 層靠異源抽查、未做窮舉自動判定」、不把同源自審的 clean 當成真 clean。

沒這樣做的麻煩

在錯的一側無限用力

把 register 違規當成自動化側問題、就會持續投入「更好的檢查方法」（補 grep、寫判準、做測試）、每次都改進一點、每次都還是放水 —— 因為判定始終在品味側。投入的努力跟結果脫節、看起來在進步、實際在原地。

同源 clean 製造虛假信心

跑完多輪 LLM 審查、回報「字句層 clean」、這個 clean 是同源盲區的產物、不是真 clean。比沒審更危險：沒審還知道沒查、同源審完誤以為查過了、register 違規帶著「已審查」標籤留在稿件裡。

規範卡越多、越以為夠了

blog 累積了 #94 / #147 / #149 一整套 register 審查原則、看起來防護很完整、反而讓人以為「照卡片做就夠」。這次的失敗證明：原則齊備、修法齊備、同源執行仍跨不過上限。原則的數量不等於防線的強度。

跟其他抽象層原則的關係

• #149 字句層 review：keyword bank 命中是候選、不是判決：#149 揭露「命中後判定會放水」這個現象、本卡是它的上層 —— 揭露放水的根因（判定在品味側、同源自審有結構上限）跟結構解（異源視角、不是更好的判定準則）。#149 的「概念位置判準」是好的判準、但它仍要同源 reviewer 執行品味判斷、本卡指出這一步有上限。
• #147 規範化跟自審是兩種認知任務：#147 講「立規範不等於自審執行」、修法是轉 grep + sweep。本卡補它沒覆蓋的：對 register 違規、grep + sweep 命中了、判定仍跨不過同源盲區。#147 解「自審有沒有做」、本卡解「自審做了、為什麼對 register 仍失效」。
• #82 字面攔截 vs 行為精修：本卡把 #82 的「字面 vs 行為」推到極限 —— 對 register 違規、連「行為精修」（讀者能不能驗證）都還是品味判斷、需要異源的讀者才感受得到。形式違規停在字面層即可、register 違規連行為層都需要異源。
• #95 Multi-pass review scope 要蓋同類風險區：#95 解 scope 軸（同類違規要 corpus-wide grep）、本卡解 source 軸（同類違規的判定要文體異源）。兩個一起才完整：grep 把候選掃出來（#95）、異源的眼睛判它違不違規（本卡）。這次三個 surface 鏡像內容共享同一違規句型、grep 掃得到、但同源判定全放行 —— scope 對了、source 沒換。
• #114 Multi-pass review 的 frame 顆粒度盲點：#114 解偵測層（展開成 keyword bank）、本卡指出對 register 違規、偵測層做好了、判定層仍需異源 —— frame 顆粒度再細、同源 reviewer 對品味違規仍有盲區。

判讀徵兆

適用範圍與邊界

• 適用：register / 品味類寫作規範（正向陳述、概念前置、喊話、誇飾、口語修辭、文體）的 review 流程設計；AI 輔助寫作的 self-review（最容易在 register 層同源放水）；multi-round-review 的 frame 與資源配置。
• 不適用：形式違規（emoji、編號、broken link、frontmatter）—— 這類確定性判定、進工具鏈即可、不需異源、本卡的「同源上限」不適用。
• 邊界：「同源自審有上限」不等於「同源自審無用」 —— 同源 reviewer 仍能抓形式違規、抓部分明顯的 register 違規；上限指的是「對 register 違規無法做到窮舉可靠」、所以要補異源、不是廢掉同源。也不等於「只能靠人」 —— 偵測機械化、對抗文體 reviewer、reader-simulation 都能降低對純人工的依賴、只是接受殘餘要異源抽查。

Self-case：本卡的觸發來源

本卡觸發於一次 backend 章節 + skill 的四輪 multi-round-review。流程是 12 個 LLM reviewer、4 輪、frame 涵蓋規範遵循 / 技術 / 一致性 / cadence / reader-simulation / title / self-application / steelman / outbound / cold-read / misuse / regression。Round 1-A 與 Round 3-A 都跑了 compositional-writing 的正向陳述 grep keyword bank、命中了三個 surface 的「不是 X、而是 Y」、全部判成「合規對照」放行、回報「字句層 clean」。

四輪結束、三個 PR 合併之後、使用者讀稿件、一眼指出「外包一塊能力不是二元、而是有深度的」是否定句型 + 概念後置違規。同一個違規在 0.22 章節、知識卡、skill principle 卡三個 surface 都存在、12 個 LLM reviewer 全漏、使用者一眼抓到。

對應本卡：register 違規的判定在品味側、12 個 LLM reviewer 共享文體直覺、同源自審跨不過盲區；使用者是文體異源的眼睛、所以一眼看到。這次失敗證明 #147 的「轉 grep + sweep」、#149 的「概念位置判定」、補 grep keyword bank —— 三個自動化側的修法疊起來、對 register 違規仍跨不過同源上限。結構解是把異源視角寫進流程、不是再疊第四個自動化側修法。

修法是新違規的來源。改寫一個違規句、補一條 lint 規則、改一個 pattern——這些動作本身會引入新問題，而且引入的常是同一類問題的變體：修掉「不是 X、而是 Y」、就暴露「不是 X — 是 Y」；補一條 pattern 抓某變體、下一個變體又漏。

兩個推論直接影響 review 流程：review 的 scope 要涵蓋「修法後的產物」、不只「原始內容」；停止判斷不能停在「修完這批」、因為修法本身產生新一批。

為什麼修法引入的是同類變體

修法用的是跟原作者同一套文體直覺、同一個對問題的理解。改一個表面實例時，注意力放在「這一處」、而同一個底層成因（重點後置的偏好、某個高頻句型）在別處或下一個變體仍在。修「而是」連接詞、沒動到「重點後置」這個成因，於是「— 是」「不在…而在」這些同成因的近親一個個浮現。補 pattern 也一樣：每補一個連接詞、成因（重點後置）沒被判準收斂、下一個連接詞的變體就漏。

這跟全新違規不同：全新違規是不同成因，同類變體是同一成因的不同表面。修法最容易產生後者——因為修的人盯著表面、放過成因。

這次的實證（同一批 retrospective 反覆出現）

每一次修法都暴露下一個同類變體。POS pattern 的連接詞清單擴了兩次（而是 → 加「— 是」→ 加「不在…而在」）、每次擴完就暴露下一個變體、第四個「、是」頓號版發現後決定不補——這正是「打地鼠」：表面層追不上成因層。

理想做法

review scope 涵蓋修法產物

修完一批不假設它乾淨。修法產物要重新過一次同樣的 frame——尤其修的是「會引入同類變體」的改寫或規則。這是 #95「scope 蓋同類風險區」的時間軸延伸：修法後的產物也是同類風險區、且是剛產生的。

同類變體靠判準收斂、不靠窮舉

成因層的判準（#166 的「核心概念在不在最前」）一次涵蓋所有連接詞變體；表面層的 pattern 永遠枚舉不完（擴兩次仍冒出第四個變體）。所以工具鏈的 pattern 定位是「曝光候選」、收斂靠判準——pattern 漏一個變體只是讓候選 silent、判準仍能在人讀到時抓出。有些變體（「、是」頓號版）誤判率高、刻意不補進 pattern、正是「判準優於窮舉」的活證明。

停止判斷含修法產物

「修完這批違規」不是停止訊號。修法產生新一批、停止判斷要看「frame 涵蓋 + 判準到位」（#148 的延伸）、不看「這批修完了」。

沒這樣做的麻煩

修完回報 clean、新引入的違規 silent

修法後直接回報「修好了」、不重審修法產物——新引入的同類變體帶著「已修」標籤留下。這次 Round 2 / Round 4 抓到的、都是前一輪「修完回報 clean」後才被下一輪 frame 揭出的。

補 pattern 永遠追不上變體

把希望放在「補完所有 pattern 變體」上、就會無限打地鼠——每補一個、下一個浮現。連接詞清單擴兩次仍冒出第四個變體（「、是」），證明表面層的窮舉追不上成因層。

跟其他抽象層原則的關係

• #166 重點優先陳述是跨語言的資訊結構原則：#166 講「句型 grep 枚舉不完、判準是重點位置」（靜態原則），本卡是它的過程面——修法 / 補 pattern 的動作會反覆暴露同類變體，正是「枚舉不完」在 remediation 過程的動態展現。#166 self-case 記了完整的 pattern 連接詞擴展軌跡。
• #95 Multi-pass review scope 要蓋同類風險區：#95 是空間軸（同類違規分布整個 corpus），本卡是時間軸（修法後的產物是剛產生的同類風險區）——兩個一起才是完整 scope：橫向蓋 corpus、縱向蓋修法產物。
• #153 Review 漏抓先分 design gap 與 execution gap：本卡補一類 gap 的來源——修法本身引入的新 gap。修法後沒重審，是把「修法產物」排除在 scope 外的 execution gap。
• #148 跨輪 review 停止訊號是 frame 涵蓋：本卡補「修法產生新批」這個維度——停止判斷不能停在「修完這批」、要含修法產物的重審。
• #149 keyword bank 命中是候選、不是判決：補 pattern 抓變體是偵測層、收斂靠判準是判定層——本卡的「靠判準不靠窮舉」是 #149「判定優先」在 remediation 的應用。

判讀徵兆

適用範圍與邊界

• 適用：批量改寫違規、補 lint 規則 / pattern、multi-round-review 的修法階段、任何「修一類問題」的 remediation。
• 不適用：修單一孤立 bug（無同類變體、修完即止）；確定性違規的工具鏈修法（emoji / broken link，補一條規則就窮舉完、無成因層變體）。
• 邊界：「修法引入同類變體」不等於「不該修」——該修、但修完要把修法產物納入下一輪 scope，且收斂靠成因層判準不靠表面窮舉。

Self-case：本卡的觸發來源

本卡抽自一次 backend + skill 的 register 違規 retrospective。整個過程是一連串修法、每次修法都暴露下一個同類變體：四輪 multi-round-review 每輪修完、下一輪不同 frame 都抓到前輪修法引入的新近逐字；POS-negation-lead pattern 的連接詞清單擴了兩次（而是 → 加「— 是」→ 加「不在…而在」）、每次擴完就暴露下一個變體、第四個「、是」頓號版發現後決定不補；修第 1 觸發句「不是二元、而是有深度」後、漏了第 2 觸發句「不是吹噓技術 — 是…」（不同連接詞變體），由使用者複核才抓到。

這條軌跡共同指向一個教訓：修法是新違規的來源、且引入的是同類變體；表面層的 pattern 窮舉追不上成因層、收斂要靠判準（#166 的重點位置）、review scope 要把修法產物納進來。

本卡是一次 multi-round-review 漏抓的 self-retrospective 抽出。限制：樣本為 1 次 review（til/terms 14 卡），「知情 vs 冷讀」二分基於單次觀察；修法（補冷讀 frame）的有效性已由同批內容的後續冷讀驗證初步確認，但未跨多批驗證。讀者把它當「review 讀者模擬的一個必查維度」，不當已驗證流程。

核心原則

多輪審查模擬讀者時，要區分兩種讀者，分開跑：

• 知情讀者（旅程 frame）：讀完全部、依學習路線走，看入口判讀與內容門檻。
• 冷讀者（零脈絡單卡落地 frame）：假裝經搜尋或他人貼連結，直接落在單一篇章，沒讀過其他篇與索引。

關鍵差別：知情 reviewer 會自動腦補脈絡，因此結構性看不見「洩漏撰寫者預設前提的行話」——未定義就出現的「家族」「上述」「如前所述」「本文前面提到」。只有零脈絡冷讀者會立刻問「這裡突然冒出的 X 是什麼」。

原子化 / Zettelkasten / glossary / 任何可被直連或搜尋單獨抵達的內容，冷讀 frame 為必備，不可只靠旅程 frame。

情境

til/terms 是一組 14 張互連的術語卡。經 3 輪多輪審查（含「讀者旅程」frame），三個 reviewer 全給 A、零必修。但每張卡都用「連到家族 / 概念家族」這個只有撰寫者懂的詞——讀者從搜尋落在單卡時，根本不知「家族」指什麼。知情 reviewer 讀完全部後腦補了「這是一組詞」，沒察覺這個洩漏。

理想做法

把 Reader simulation 拆成兩個子 frame：旅程（知情讀者走路線）與冷讀落地（單卡零脈絡）。冷讀 frame 逐篇問三件事：我知道為何讀這篇嗎？有沒有未在本篇定義的預設脈絡詞？我能不能從這篇找到回路？原子內容兩個 frame 都要跑。

沒這樣做的麻煩

只跑旅程 frame，知情 reviewer 全 A 放行，行話會留到讀者冷讀單卡時才卡住——而那時內容已發佈，回報後得回頭改全部卡。把「讀完全部的 reviewer 覺得通順」當成「冷讀者也通順」，是把 informed 的腦補誤當成內容自包含。

判讀徵兆

• 內容是原子 / 可被搜尋或直連單篇落地（術語卡、glossary、知識卡）。
• reviewer 是「讀完全部」才判讀旅程，沒人模擬「只讀這一篇」。
• 文中出現「家族 / 本盒 / 上述 / 如前所述 / 前面提到」這類需要前文才懂的詞。

本檢討已回饋到 multi-round-review skill（Round 2 新增 B′ 冷讀 frame）。寫作順序上 skill 修改先於本報告，屬例外；正序是報告（來源）→ skill 改進 → 下游。

本卡抽自 infra 教學模組的完整生產週期 retrospective。43 篇文章 + 21 張知識卡經歷三輪多輪審查（compliance / cadence+冷讀 / steelman+outbound），審查通過後使用者連續指出六個 review 未 catch 的問題，每個都導致大量修改。限制：evidence 來自單一教學模組的一次完整週期，盲點清單可能不窮盡。

核心原則

多輪審查框架的所有 frame 從「已寫的內容」出發（inside-out）：字句層看已寫的字、cadence 看已寫的結構、fact-check 看已寫的事實、steelman 看已寫的論述。缺的是從「讀者的完整需求」出發的 frame（outside-in）：讀者是誰、讀者從哪裡來、讀者讀完後要做什麼、讀者搜尋什麼問題。

inside-out 能保證已寫內容的品質，outside-in 才能發現「應該寫但沒寫」的缺口。兩者的盲區正交：inside-out 的盲區是缺口（看不到不存在的東西），outside-in 的盲區是細節（看不到已寫內容的字句問題）。完整的審查需要兩者交替。

六個盲點

一：宣導語氣通過三輪審查

三輪審查判定文章 clean，使用者指出「一台機器跑得好好的」「辦公大樓比喻」是對專業讀者的失配後，14 處需要重寫。

keyword bank 的設計對象是字面違規。宣導語氣的問題在 register——用教導外行人的姿態對專業人士說話，字面上每個字都合規。reviewer 跟作者共享同一套文體直覺，都覺得「用故事帶入」是好的教學手法，同源盲區讓整批宣導語氣被合理化放行。

缺的 frame：reader-persona register 適配——指定具體讀者角色，問「這個人讀到這段會覺得被低估嗎」。

二：管理層彙報資訊缺失

所有 reviewer 檢查了技術正確性和寫作規範，沒有一個問「讀者讀完後能不能跟老闆說明為什麼要做、要花多久」。使用者提出後掃描出 10 處成本/時程缺口。

review frame 全部從「內容品質」出發，沒有從「讀者的下游任務」出發。技術文章的讀者不只要「學會怎麼做」，還要「能向上彙報為什麼做」——後者是讀者的工作流程，品質導向的 review 結構性看不到。

缺的 frame：downstream-task 審查——問「讀者讀完後的下一個動作是什麼？他需要什麼素材？」

三：接手 vs 自建是不同情境

模組負一定位為「還沒有 infra 的手動環境」，所有 reviewer 都接受了這個前提。使用者指出「接手前人的專案」是完全不同的操作情境後，獨立成一個橫切模組。

review 的 scope 是「已寫的內容對不對」，不質疑結構本身的覆蓋範圍。steelman reviewer 問的是已有文章的論述有沒有漏洞，不是教材的讀者群有沒有被遺漏的情境。

缺的 frame：persona-coverage 審查——列出目標讀者可能進入教材的情境，檢查每個情境是否有對應入口。

四：操作步驟缺工具指引

文章寫「拍下現況」「匯出資料庫」，reviewer 確認了邏輯正確性。使用者問「用什麼拍？怎麼拍？」後才發現停在 WHAT 層、沒到 HOW WITH WHAT 層。

fact-check reviewer 驗證「描述是否正確」，不是「描述是否可執行」。「用 FTP 下載整站存進 Git」事實正確，但讀者照做時需要知道用哪個 FTP client、大檔案怎麼處理。

缺的 frame：executable-walkthrough 審查——假裝讀者從零照做，每步問「下一個動作是打開什麼軟體、輸入什麼指令」。

五：概覽級深度不拆分

350 行文章涵蓋四個面向，reviewer 認為「結構完整」。使用者指出「資料庫備份和安全管理其實都是大問題」後拆成 5 篇。後續又在 8 個模組發生同樣的拆分。

reviewer 評估「這篇文章本身好不好」，不是「搜尋特定問題的讀者能不能找到足夠深度的內容」。一篇涵蓋四面向的文章通讀體驗良好，但搜尋「共享主機 MySQL 備份」的讀者需要專題文章。

缺的 frame：search-landing 審查——列出讀者可能搜尋的具體問題，檢查每個問題能不能落在聚焦的文章上。跟 cold-read (B’) 相關但不同——B’ 看「落地後讀不讀得懂」，這裡看「能不能落地到足夠聚焦的內容」。

六：讀者定位未預設

「讀者是缺經驗的專業人士」這個原則在文章寫完、審查完、使用者反饋後才抽出來。它影響了語氣、比喻策略、管理層溝通——幾乎所有後續大修都源自這個原則。但它不在任何 reviewer prompt 裡。

寫作規範定義了「怎麼寫」的規則，沒有定義「寫給誰」——讀者定位被當成隱性決定。LLM 預設用「教外行人」的姿態寫教學內容，這個預設不被 review 挑戰，因為 reviewer 也共享同一個預設。

這不是 review frame 的問題——是生成端的前提缺失。每個教學模組在第一篇文章生成前就應該顯式聲明讀者定位。

理想做法

在現有 inside-out review 框架之外，補五個 outside-in frame：

生成端的修正：每個教學模組在撰寫前顯式聲明「讀者定位文件」（一段話描述目標讀者的背景、已有能力、缺的經驗），讓生成和 review 都有可檢查的基準。

沒這樣做的麻煩

六個盲點的修法總工程量遠超預防成本：14 處宣導語氣重寫 + 10 處管理層資訊補充 + 11 篇接手維運新文章 + 全模組工具補充 + 12 篇子文章拆分 + 3 篇入門/溝通層重寫。如果讀者定位在第一篇文章前就聲明、outside-in frame 在 Round 1 就跑，多數修改可以在初稿階段就避免。

判讀徵兆

review 完成後如果使用者的第一個反饋是關於「內容缺口」而非「內容品質」，代表 review 框架偏向 inside-out。inside-out 的 review 報告 clean 只代表「已寫的內容沒問題」，不代表「該寫的都寫了」。

跟其他抽象層原則的關係

• → 讀者是缺經驗的專業人士、不是外行人：盲點一和六的直接修法
• → 技術教材要內嵌管理層可彙報的資訊：盲點二的直接修法
• → 跨專業溝通用情境遞進、不用比喻堆疊：盲點一的溝通層修法
• → #148 跨輪 review 停止訊號：本卡揭露的是「停止訊號齊備但覆蓋不完整」的情境——frame 涵蓋度的判斷要包含 outside-in frame
• → #153 Review 漏抓先分 design gap 與 execution gap：六個盲點全部是 design gap（框架缺 frame），不是 execution gap（有 frame 沒跑）
• → #168 多輪審查要有冷讀者 frame：cold-read 是 outside-in 的一個實例（從零脈絡讀者出發），本卡把這個方向擴展到五個 frame