"Review-Process"
- Multi-pass review 的 frame 顆粒度盲點：抽象規則 → 具體訊號的轉譯不完整
Multi-pass review 跑了 4 輪、字句層問題（口語修辭 / 地區用語 / 依賴 code / 廢話前綴）仍漏 catch——揭露 frame 顆粒度盲點：抽象規則（如「機會成本語氣」「正向陳述」「最重要的話優先說」）沒被轉譯成具體訊號（如 grep keyword bank：「一輩子 / 碰巧 / 撞牆 / 下次 X 時 / 不是 A 而是 B」）。修法是把每條規則展開成可 grep 的 keyword bank、加 reader simulation 輪、加 self-criticism 輪。
- 字句層 review：keyword bank 命中是候選、不是判決
跑了字句層 grep keyword bank、命中『不是 A 而是 B』、卻把它判成『可接受的反例對照』放行；違規由讀者 catch。揭露 keyword bank 的第二層盲點：偵測（grep 命中）跟判定（這個命中是不是違規）是兩個認知步驟、reviewer 容易把命中合理化成合規而放行。判定準則：否定句構若在『建立核心概念』就改正向、只有在『明示反例段落』才保留。另有一類贅語（訴諸群體『很多人卡在』）連關鍵詞都沒有、keyword bank 結構上抓不到、要靠 reader-simulation 語意 pass。
- Review 漏抓先分 design gap 與 execution gap、再決定改框架還是改執行
Review 漏抓某類問題時，有兩個不同成因：design gap（框架根本沒有對應 frame）跟 execution gap（框架有 frame、但 reviewer 沒跑）。修法相反 —— design gap 要改框架（補 frame / keyword）、execution gap 要改執行（真的跑完該跑的輪）。診斷前先分清：把 execution gap 誤判成 design gap 會 framework bloat（一直加 frame 卻沒解決偷跑子集）、把 design gap 誤判成 execution gap 會永遠漏同類。常見陷阱是『加 keyword』感覺像進步、但對沒跑的輪毫無幫助。
- register 違規：偵測可機械化、判定要靠文體異源的眼睛
寫作規範的違規分兩類：形式違規（emoji / 編號 / broken link）可完全機械判定、該進工具鏈；register / 品味違規（概念前置 / 否定起手 / 喊話 / 誇飾）的判定有不可消除的品味核心。「不是 X、而是 Y」的陷阱是偵測可機械化（grep 抓得到句型）偽裝成判定可機械化、誘導無限投入更精緻的判定方法（grep → 概念位置 → 行為測試）、但判定始終在品味側、始終放水。更深一層：產出這類違規的 LLM 跟審查它的 LLM 共享文體直覺、同源自審對 register 違規有結構上限、加再多輪次都跨不過。結構解是引入文體異源的視角（人類冷讀 / reader-simulation / 對抗文體 reviewer）、並接受 100% 自動 catch 不可能。
- 修法是新違規的來源、且常引入同類變體
修法（改寫違規句、補 lint 規則、改 pattern）這個動作本身會引入新違規、而且引入的常是同一類問題的變體——修「不是 X、而是 Y」就暴露「不是 X — 是 Y」、補一個 pattern 就漏下一個變體。所以 review 的 scope 要涵蓋修法後的產物、不只原始內容；停止判斷不能停在「修完這批」、因為修法本身產生新一批。同類變體靠判準（重點位置）收斂、不靠窮舉 pattern；補 pattern 永遠追不上變體（打地鼠）。
- 多輪審查要有冷讀者 frame：知情 reviewer 看不見行話洩漏
多輪審查模擬讀者時要分兩種：知情讀者（讀完全部、走旅程）與冷讀者（經搜尋或直連落在單篇、零脈絡）。知情 reviewer 會自動腦補脈絡，結構性看不見洩漏撰寫者預設前提的行話。原子 / Zettelkasten / glossary 等可被直連抵達的內容，必須額外跑冷讀 frame。
- 多輪審查缺 outside-in 讀者 frame：六個系統性盲點
review 框架的所有 frame 從已寫的內容出發（inside-out），缺從讀者完整需求出發的 frame（outside-in）。六個盲點全部由使用者而非 reviewer 發現：宣導語氣、管理層資訊缺失、接手情境遺漏、工具指引缺失、深度不拆分、讀者定位未預設。