寫文字（文章 / 註解 / doc / prompt / commit message）的 ROI 來自 N 輪不同 frame 的 re-read、不是單次「寫對」。每輪 catch 上一輪 frame miss 的東西：

每輪用「跟前一輪不同的眼睛」看同一份文字 — 才能 catch 不同層的問題。第 1 輪的 frame 不可能同時 catch 所有層（#82 字面 vs 行為的 ceiling）。

為什麼一輪寫不出全部維度

寫的時候 working memory 有限、必須 collapse 多個維度去專注其中之一：

• 生成 frame 在意 idea 完整 → 顧不上語氣
• 語氣 frame 在意「機會成本 vs 絕對主義」→ 顧不上 grep-ability
• grep frame 在意關鍵字前置 → 顧不上反例

要求一輪同時 catch 所有 = 認知超載。實際結果是「每個維度都做一半」。

多輪設計接受 working memory 限制、用 N 輪解 N 維。每輪只專注一個 frame、效率反而高。

五輪 review 的具體 checklist

輪 1：生成

• idea 從頭寫到尾、不停下來改
• 預期會有 typo、結構亂、語氣不對 — 不在這輪修
• 跑得到結尾比寫得漂亮重要

輪 2：對意圖（#67）

• 開頭一句講清「這段在說什麼」嗎？
• 有沒有 #67 的「便利驅動偏移」— 寫得順但其實偏題了？
• 段落順序是不是「好寫」決定的、不是「易讀」決定的？
• 有沒有「為了補滿格式」寫的廢段？

輪 3：機會成本語氣

• 跑 grep 抓「應該 / 必須 / 不行 / 不可以 / 正確的方式 / 唯一」這些絕對詞
• 每個絕對詞檢查：是物理 / 法律 / 安全事實嗎？不是的話翻成「在 X 情境下 A 較好、Y 情境下 B 較好」
• 反模式表的「為什麼不好」寫到「違反某個原則」、不寫「就是不對」

輪 4：Grep-ability / 命名

• 關鍵字在段首、不在段中
• 表格欄位用 grep 友善的分隔（: | →）
• 檔名 / slug 跟 title 對應、不要用流水號
• 命名能用單次 grep 命中、不需要語意推理

輪 5：反例 / 邊界

• 「何時不適用」段寫了嗎？
• 反模式表給「為什麼不好 + 修法」嗎、還是只給警告？
• 跨卡 cross-link 補了嗎？
• 有沒有 over-claim、把「在多數情境下」說成「總是」？

套用到不同 output 類型

每類有特化的輪次組合：

文章（content/posts、content/report）

完整跑 1-5 輪。額外加：

• 輪 6：跨卡 cross-link 健康度（單向引用 vs 雙向）
• 輪 7：放回 _index.md 的索引條描述對應到內容嗎

程式註解（doc comment / inline）

跑 1-3 輪 + 額外：

• 輪 4’：grep-ability 改成「介面 vs 實作分層」— doc comment 不洩漏 impl、inline comment 講 why 不講 what
• 輪 5’：反例改成「這個註解 5 個月後讀還看得懂嗎」（時間軸 robust）

Naming（變數 / 函式 / 檔名 / slug）

→ 見 #84 Naming 是 iterated artifact、有特化的 4 輪設計。

Prompt（給 LLM 的指令）

跑 1-3 輪 + 額外：

• 輪 4’’：模糊指令（clarifying-ambiguous-instructions）— 「對齊」「靠近」這類詞翻成具體數字 / 條件
• 輪 5’’：「邊界 case 預期行為」明示了嗎

Stakes-conditional 追加輪：Epistemic Rigor

5 輪基本 frame 是 frame 軸（生成 / 意圖 / 語氣 / grep / 反例）；高 stakes 內容（reader 照做後錯誤不可逆 / 系統層 / 不可分批 ship 修正）追加 stakes 軸的 輪 E：epistemic rigor——比照學術 peer review 的 claim / evidence / method / threats / citation 五個 sub-check、確認論述強度足以承擔 reader 直接 implement 的下游風險。

啟動條件（opt-in、不污染預設）

判別啟動的核心問題：「reader 照這段實作會不會在生產系統留 silent gap、且不能靠後續 ship 修補？」——會 → 跑輪 E、不會 → 5 輪即可。動機論證見 #99 資安教學審查標準對應風險不對稱。

輪 E：Epistemic Rigor 的 5 個 sub-check

輪 E 的產出格式

跑完輪 E、每個 weakness 對應到一個 dimension + tier、見 #105 audit recommendation 層級：

• Accept：無 weakness 或在容忍範圍
• Minor revise：補 boundary / contrast / 版本標記類小改、不阻擋 ship
• Major revise：結構性 false sense、需重寫、ship 前必須修
• Withdraw：教錯主動誤導 reader（過時 crypto 沒標 deprecated / 扭曲 citation 反向違反現行標準 / defense theater 當示範），保留 = 增加生產系統 risk、必須移除或全換

withdraw tier 是高 stakes 內容跟一般內容的關鍵差異——一般內容 review 沒有「保留 = 增加 risk」的硬決策、高 stakes 必須有。

跟 5 輪基本 frame 的分工

兩軸正交、不取代——高 stakes 內容兩軸都跑（5 輪 frame + 輪 E stakes）、一般內容只跑 5 輪。輪 E 不在 5 輪裡是因為：把 epistemic rigor 設為預設會讓一般文章 over-audit、稀釋 review 紀律；設為 conditional opt-in 才能讓高 stakes 場景拉到學術級而不污染日常寫作。

→ 詳細維度展開（threat model 對稱 / mitigation 對位 mechanism / context-dependence / citation 時效）跟 audit recommendation tier 判準、見 #99 → #100 → #101-104 → #105 系列。

反模式：跳輪的代價

何時可以跳某些輪

四類共通：ROI 不同、輪次組合不同。Production 文件 / 卡片 / 註解 全跑、即時通訊只跑核心。

跟其他抽象層原則的關係

判讀徵兆

核心：Writing 的 ROI 來自多輪不同 frame、不是單次「寫得仔細」。要寫得仔細的部分太多、超過 working memory、必須分輪。跳輪的代價是某維度永遠做一半、累積成「看起來都對但其實有漏」的低品質文字。

第一次寫的名字幾乎都不對 — 不是因為命名能力不夠、是因為第一版命名只能基於「寫的當下看到的 context」、而正確的名字需要看到「未來所有 call-site / grep 結果 / 重構場景」。

命名的正確設計是 iterated artifact：寫 → re-read → 改 → 再 re-read → 收斂。每輪用不同 frame：

每輪可能 catch 到「上一輪沒看到」的問題、迫使重命名。接受重命名是命名工作的常態、不是失敗。

為什麼第一版幾乎不對

寫第一版時、認知資源都在「概念是什麼」、剩下的給命名只夠：

• 看到當前 function 在做的事 → 命名只反映當前
• 不知道未來會有 N 個 call-site → 沒考慮一致性
• 不知道未來會有 grep / refactor → 沒考慮 unique-ness
• 不知道未來會換 impl → 命名容易洩漏現在的 impl 細節

第一版命名是對「現在的 context」過度擬合。下一輪 review 換 frame 才能看到擬合方向之外。

四輪 review 的具體 checklist

輪 1：第一版

• 名字反映「做什麼 / 是什麼」、不是「怎麼做」
• 動詞 / 名詞符合語言慣例（function 動詞、value 名詞）
• 不超過 4 個單字（長 ≠ 清楚）
• 跑得到 next step、不在這輪糾結

輪 2：Grep-ability

• grep -r "<name>" 能命中目標、不會被別的 entity 蓋過
• 跟 framework / library reserved name 不撞（避免 data、type、value 等過泛）
• 名字不是其他名字的子字串（get 會匹配 getName getUser…）
• 中英混合場景下、英文部分能 grep（不要用 處理器handler 這種 mixed）
• 縮寫慎用（usr cfg mgr 增加 grep 失敗率）

輪 3：Cross-call-site 一致性

• 從 caller 角度看、名字暗示的契約對嗎？
• 跟同 module 其他類似 entity 命名格式一致嗎？（getUser vs fetchUser 不該混用）
• 同一個概念在不同 file 用同名嗎？（不該 userId / user_id / uid 三個並存）
• 動詞時態一致嗎？（fetched vs fetching vs fetch 對應狀態 / 動作 / 命令、不該混用）

輪 4：Impl 洩漏檢查

• 名字含 impl 細節嗎？（fetchUserViaSql ≠ fetchUser、後者較好）
• 換 impl 後名字還對嗎？（cacheGetUser 改成走 DB 後名字錯了）
• 名字洩漏 data structure 細節嗎？（userArray ≠ users、後者不綁 array）
• 介面層名字 vs 實作層名字區分嗎？（介面用「做什麼」、實作用「怎麼做」可加細節）

套用到不同命名場景

變數 / 函式

完整跑 1-4 輪。

額外注意：

• 作用域 — 越窄作用域越可短（loop counter i、close-up var tmp）；越寬作用域越要明確
• 類型暗示 — boolean 用 is / has / should 開頭

檔名 / module

跑 1-4 + 加：

• 層級表達 — 檔名能否反映在 directory 結構中的位置？
• 避免 utils / helpers / common — 這類是「不知該叫什麼」的訊號、強制再過一次輪 1-4

URL slug / route

跑 1-4 + 加：

• SEO — 跟 search query 的 substring match 對齊（#73 search 匹配模式）
• kebab-case 一致
• 不含 stop words（the、a、is、of、with、and）— 跟搜尋引擎 stemming 對齊

API endpoint / DB column

跑 1-4 + 加：

• 跨 service 一致性 — 同一概念在 client / server / DB 用同名（避免 user_id / userId / uid 跨 layer 不一致）
• 不可變更性 — DB column / API endpoint 改名成本極高、輪 1-4 多跑幾次值得

反模式：放棄重命名

何時可以跳輪

兩極：作用域越窄越可省、跨邊界 / public 越要 multi-pass。

跟其他抽象層原則的關係

判讀徵兆

核心：命名是 iterated artifact、不是 single-shot 動作。第一版基於狹窄 context 幾乎必錯。接受 N 輪 review 跟 K 次重命名是常態、命名品質會提升一個量級。試圖一次寫對 = 第一版 ship 出去 = 後續長期付 cognitive 成本。

凡是教做事方法的東西（SKILL、playbook、methodology document、checklist）— 如果你認為 multi-pass refinement 是必要的、就要把它放在核心結構層（pillar、principle、step）、不是放在附帶段（appendix、tips、reminder、see also）。

放在 appendix = 結構暗示「optional、看心情選擇」 = 在 #72 高 ROI 無觸發 的結構壓力下、永遠被跳過。Pillar 層 = 結構性必跑、用結構強制行為、不靠紀律。

為什麼 pillar / appendix 的位置決定執行率

讀者看 SKILL / methodology 時、認知資源分配：

• Pillar / Core Principles：必讀、會內化、實作中會回想
• Steps / Reference：實作中翻
• Tips / Appendix / “See also”：第一次讀掃過、之後忘記

把 multi-pass review 放 appendix = 結構暗示「這是進階、可選」。即使內容寫得很詳細、結構訊號蓋過內容。

對比放 pillar：每次接觸 SKILL、第一眼看到 4-5 個 pillar 中包含 “Multi-pass Refinement” — 結構性提示「這跟其他 pillar 同樣重要」。

各 methodology 的 pillar / appendix 切分

實際 methodology 文件的 pillar 應該包含 multi-pass、appendix 應該避免：

每個 methodology 的設計都該檢查：multi-pass 是 pillar 還是 appendix？

如何識別「該升 pillar 但被當 appendix」

訊號：

每個訊號都是 multi-pass 的位置太低、結構壓力把它當作 optional。

升 pillar 後的設計：四個必要元素

把 multi-pass 升成 pillar、需要含這四個元素才完整：

1. 明示「第 1 輪不追求完美」

寫在 pillar 內容、第一句就講：「第 1 輪不要追求 perfect、預期會有未發現問題、設計第 2 輪去 catch」。

去掉「第 1 輪該寫對」的隱含預設、釋放認知資源。

2. 列出 N 輪的 frame 清單

每輪用什麼 frame、catch 什麼。例：

1輪 1：生成 — idea → 字
2輪 2：對意圖 — 跟原意對齊嗎
3輪 3：機會成本語氣 — 絕對主義詞翻成 trade-off
4輪 4：grep-ability — 關鍵字前置嗎
5輪 5：反例 / 邊界 — 何時不適用寫了嗎

3. 何時可跳輪

不是所有情境都跑全輪。寫清楚「跳輪的合理情境」、避免「跑全輪 = 過度工程」的反彈。

4. 跨 frame 的不可替代性

明示：輪 N 不能用「再跑一次輪 N-1」取代 — 不同 frame 才能 catch 不同層。重複同 frame = 同類錯一直 miss。

反模式：「我自己會 review」當 pillar 替代

1不該寫：「請務必在送出前自行 review。」
2應該寫：「此 methodology 的第 N 個 pillar 是 Multi-pass Review、含 1-5 輪 frame：⋯⋯」

「自行 review」= L1 紀律（#72）= 預期失敗。

「列入 pillar + 列輪次 + 列 checklist」= L3-L5 結構性對策 = 結構強制執行。

套用到本系統的具體 case

Case 1：requirement-protocol skill

• 現況：3 大支柱 + 6 大原則、multi-pass 散在「2 次門檻」「漸進驗證」「revert checkpoint」三條原則裡、沒明示
• 應該：升第 4 支柱「Multi-pass Refinement」、把散落的多輪意涵集中

Case 2：compositional-writing skill

• 現況：3 大支柱 + 5 大原則、各 reference 結尾有「self-check」段（部分 multi-pass 跡象）
• 應該：升第 6 原則「Re-read Pass」、引用 #83 的 5 輪 frame、各 reference 加「第 2 輪 review checklist」

Case 3：frontend-with-playwright skill

• 現況：「漸進驗證」原則含 multi-pass、但跟「dogfood / 多輪測試」沒串連
• 應該：補抽象層原則段、明示 multi-pass 跨「漸進驗證 → playwright dogfood → production observation」是同一條 spiral

跟其他抽象層原則的關係

判讀徵兆

核心：Methodology 設計的 pillar / appendix 切分不是內容深淺問題、是執行率問題。Pillar 層必跑、appendix 層不跑。把 multi-pass 視為「附帶」= 結構性確保它不被執行。真正必要的東西要升結構、不能藏在末尾。