為什麼會寫超過目標讀者一級

寫商業分析的常見陷阱是把「自己熟悉的術語密度」當預設。寫作者跟 VC / 創辦人對 PLG、CAC、單位經濟、毛利 是日常詞彙、一句話三個術語也通順；但對技術背景讀者、這些術語都需要查、一句話三個術語就成了「停下來查三次」。

實際 case：Claude for Legal 之後 第一層擠壓段原本寫成：

毛利下降是讓 P&L 跑不過去的差距。PLG 的數學算不過來、要轉成 Sales-led 或 FDE、但這又拉高 CAC。兩頭夾擊—單位經濟受傷、估值倍數被壓。

3 句話塞了 6 個術語（毛利、P&L、PLG、Sales-led、FDE、CAC、單位經濟、估值倍數）。對 VC / 創辦人來說 3 秒讀完；對工程背景讀者來說每句都要停下來解碼、整段讀完得花 2-3 分鐘。

降一級的四個策略

策略一：拆因果鏈、每個邏輯 step 獨立成句

原版把「毛利下降 → PLG 數學算不過來 → 要轉 Sales-led 或 FDE → CAC 拉高 → 兩頭夾擊 → 單位經濟受傷 → 估值倍數被壓」這個 7 步推論壓進 3 句話。每步邏輯跳躍對熟悉領域的人是省力、對讀者是要在腦中補完跳過的步驟。

降一級的做法是把每個邏輯 step 獨立成段、用「第一 / 第二 / 第三」結構讓讀者跟得上：

• 第一、賺到的錢不夠付業務跟行銷（毛利下降的直接後果）
• 第二、免費試用變成燒錢（為什麼 PLG 數學算不過來）
• 第三、被迫轉成更貴的銷售模式（為什麼要轉 Sales-led / FDE）

每段獨立、讀者一次處理一個概念、不用在腦中疊三個跳躍。

策略二：術語首次出現時 unpack

原版的「PLG」連結到卡片、技術上沒問題、但讀者要中斷閱讀去點連結看卡片才能繼續。

降一級的做法是首次出現時直接在括號裡解釋一句：

PLG（Product-Led Growth、靠產品自己吸引用戶上來、不靠業務推銷）

讀者讀到這裡不用點開連結、括號裡的一句話就夠跟上後續論證。卡片連結保留、是給想深入的讀者用、不是預設動作。

策略三：加具體算式 / 數字

原版的「毛利下降」「兩頭夾擊」「估值倍數被壓」都是抽象描述。降一級的做法是配具體數字：

• 毛利下降 → 「從 70-80% 掉到 50% 出頭、30 個百分點差距」
• 兩頭夾擊 → 「收入端毛利從 70% 掉到 50%、支出端 CAC 從幾十美元跳到幾千甚至幾萬美元」
• 估值倍數被壓 → 沒有直接數字、但前後的因果鏈讓讀者能自己推導

抽象描述對熟悉領域的人是「我知道你在說什麼」、對讀者是「我不知道這個尺度多大」。具體數字提供尺度感。

策略四：避免術語連發、術語之間用「白話橋」連接

原版「PLG 的數學算不過來、要轉成 Sales-led 或 FDE、但這又拉高 CAC」是 4 個術語連發、白話讀者要在腦中組裝因果。

降一級的做法是用白話句連接術語：

PLG 不能用、改回業務面對面賣（Sales-led）、或乾脆派工程師駐點客戶辦公室（FDE、Forward Deployed Engineer）

「改回業務面對面賣」「乾脆派工程師駐點客戶辦公室」這兩句白話橋讓讀者看到從 PLG 轉到 Sales-led 或 FDE 的具體畫面、不是術語對術語的跳躍。

對照示範

同一段內容、用兩個 register 寫：

原版（深度部落格 / VC、創辦人）：

毛利下降是讓 P&L 跑不過去的差距。PLG 的數學算不過來、要轉成 Sales-led 或 FDE、但這又拉高 CAC。兩頭夾擊—單位經濟 受傷、估值 倍數被壓。

3 句、約 100 字。

降一級（MBA 教材 / 學生、經理人 / 工程背景讀者）：

這個毛利下降會連動三件事。

第一、賺到的錢不夠付業務跟行銷。 傳統 SaaS 賣 100 元、扣掉伺服器費用後剩 70-80 元（毛利 70-80%）、即使花 30% 在業務跟行銷也還能賺；AI 應用賣 100 元、要付給上游模型供應商的 token 費後只剩 50 元出頭（毛利 50%）、同樣花 30% 在業務跟行銷只剩 20% 利潤、損益表 P&L（公司一段期間內賺賠的財務報表）從正轉負。

第二、免費試用變成燒錢。 傳統 SaaS 的「免費試用」幾乎零成本—多開帳號伺服器頂多多用一點；AI 應用的免費試用每次都在燒 GPU 算力、是真實的成本支出。PLG（Product-Led Growth、靠產品自己吸引用戶上來、不靠業務推銷）模式靠的就是「免費試用零成本」這個前提、毛利掉到 50% 時這套數學就跑不下去了。

第三、被迫轉成更貴的銷售模式。 PLG 不能用、改回業務面對面賣（Sales-led）、或乾脆派工程師駐點客戶辦公室（FDE、Forward Deployed Engineer）、但這兩條路都讓 CAC（Customer Acquisition Cost、獲取一個新客戶要花的所有成本）從 PLG 的幾十美元跳到 Sales-led 的幾千美元、再到 FDE 的幾萬甚至幾十萬美元。

收入端（毛利從 70% 掉到 50%）被壓縮、支出端（CAC 上升 100 倍）被拉高—兩頭夾擊讓 單位經濟（每個客戶能不能帶來足夠收入回本獲客成本）受傷。投資人計算 估值 倍數時看到這個結構性壓縮、給的估值就低、新創 burn rate（每月燒錢速度）變相加速、生存難度提高。

5 段、約 500 字。長度增 5 倍、但讀者一次處理一個概念、不用中斷查術語。

篇幅成本跟對齊讀者的取捨

降一級的代價是篇幅 3-5 倍。寫作者要判斷這個代價值不值：

判別線：「我希望讀者直接吸收還是先學術語」。前者降級、後者保留密度。

跨領域應用：技術文章降級給商業讀者

降一級寫法不只用在「商業降給工程師」這個方向、反方向也成立。寫技術文章給商業讀者看時、同樣的策略適用：

• 拆因果鏈：把「Eventually Consistency 導致 stale read」拆成「資料更新後不會立刻所有人都看到、可能會看到舊版」
• Unpack 術語：「Eventual Consistency（最終一致性、資料更新會慢慢傳到所有副本）」
• 加具體數字 / 例子：「副本之間最多差 100 毫秒、千分之一的請求會讀到舊版」
• 用白話橋連接術語：「資料庫一寫入、其他副本可能要 100 毫秒才同步過來、這段時間讀到的是舊版」

矩陣框架的可遷移性：判別目標讀者層級 → 降一級寫法 → 對照原版檢查篇幅 vs 易讀性的取捨。任何跨領域知識傳達都適用。

完稿時的「降級檢查」

寫完一段後跑：

1. 數一下這段塞了幾個術語（縮寫、行話、領域特定詞）
2. 三個以上術語連發、考慮拆段或加白話橋
3. 因果鏈跳躍超過 2 步、考慮用「第一 / 第二 / 第三」結構拆細
4. 術語首次出現時、考慮在括號裡加一句解釋
5. 抽象描述（「夾擊」「擠壓」「鬆動」）配具體數字或例子

完稿後找一個目標讀者層級的人試讀、看哪段需要解釋、就是降級沒做夠的地方。

延伸閱讀

• 媒介—讀者—目的矩陣 — 識別文章類型跟目標讀者
• Claude for Legal 之後 — 採用降一級寫法的 case-analyses 示範

寫文字（文章 / 註解 / 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、必須分輪。跳輪的代價是某維度永遠做一半、累積成「看起來都對但其實有漏」的低品質文字。

寫作 / UI 中的問題分三層、不同層需要不同修法：

核心：修視覺工具預設錯誤就在視覺層。當症狀其實來自語意 / 邏輯層、用視覺工具修 = 蓋掉表面、根因還在 + 作者誤以為解決了（false confidence、跟 #82 的 hook 心理同病）。

修法的順序是 深層 → 淺層：先問「是不是邏輯 / 語意層的下游症狀」、是的話改結構；確認純視覺、再用視覺工具。

為什麼視覺工具對語意 / 邏輯問題無能為力

視覺工具（CSS、emoji、顏色、字體、間距、圖示）的本質是 呈現層的調整 — 它能改變字怎麼顯示、不能改變字本身代表的概念。能改的、跟改不到的、有清楚的界線：

能改的（純呈現）：

• 文字在窄視窗會不會換行
• 兩個區塊的視覺距離
• 不同類型用什麼顏色標

改不到的（結構 / 語意 / 邏輯）：

• 兩個概念該不該擠在同一行（結構層）
• 用 emoji 區分是否足夠承載語意（語意層）
• 論證有沒有完整（邏輯層）

當作者試圖用視覺工具解語意 / 邏輯問題、結果是 症狀被表面平整、但下次同類問題會用新形狀冒出來 — 因為根因（概念混淆 / 結構錯位）沒動。

反模式：用視覺修補蓋住下游症狀

False confidence 比沒修更危險

修了 CSS 之後、心理上會覺得「處理完了」。實際上 CSS 只擋了表面斷行、語意混淆照舊存在 — 但作者不再警覺、因為「我修過了」。

下一個讀者在不同 viewport / 不同設備 / 用螢幕閱讀器時、同樣的語意問題會用不同形狀重新出現（換行錯位、TTS 讀錯、複製貼上格式跑掉）。

第二行是最危險組合 — 跟 #82 的「Hook 抓不到的範圍誤以為有保護」同病。

症狀堆疊：「再加一條 CSS 規則」永遠補不完

視覺修補的直覺反應是「加一條規則」。但語意 / 邏輯下游的症狀無限多、規則永遠補不完。實際軌跡：

 1emoji 在窄 viewport 斷行
 2  → 加 white-space: nowrap
 3  → 文字溢出容器
 4  → 加 overflow: hidden
 5  → 文字被截斷看不見
 6  → 加 text-overflow: ellipsis
 7  → 螢幕閱讀器讀出「...」沒語意
 8  → 加 aria-label 補語意
 9  → 翻譯版本 aria-label 沒翻
10  → ...

每加一層 CSS、根因（兩個概念擠在一行）更深埋、修起來更貴。

→ CSS 規則膨脹是「用錯工具」的訊號、不是「規則寫得不夠細」的訊號。跟 #82 的 hook 規則膨脹同骨。

三層優先序：邏輯 → 語意 → 視覺

為什麼是這個順序

深層問題的影響範圍大、修不到根因的代價高。所以修法順序是先問深層、確認沒問題再修淺層。

修法的順序

 1看到症狀
 2   ↓
 3這是邏輯層問題嗎？（兩個獨立概念被擠在一起？論證有缺口？）
 4   是 → 重新分概念 / 補論證、結構改了之後語意 / 視覺問題自然消失
 5   否 → 下一層
 6   ↓
 7這是語意層問題嗎？（依賴視覺標記傳達唯一資訊？emoji 是唯一區分？）
 8   是 → 改表達結構、加文本標籤、用列表 / 分段
 9   否 → 下一層
10   ↓
11純視覺問題（容器寬度、字體大小、顏色對比）
12   是 → CSS / media query / 渲染配置

反向（從視覺往邏輯推）會 false confidence：先用 CSS 補了、表面平整、誤以為解決了、下次換 context 復發。

何時視覺修補真的足夠

某些情境純視覺就夠、用 CSS 是對的：

五類共通：內容本身沒爭議、只是顯示方式要調。其他情境視覺工具都會在某個時點走到 ceiling。

識別 ceiling：什麼時候該換手段

ceiling 訊號：

看到任一訊號、不是「再加一條 CSS / 換個 emoji」、是 接受視覺工具對這個層次的問題無能為力、改修結構。

跟其他抽象層原則的關係

本卡是 #82 的 sibling — 兩者都在說「工具有能擋的層 / 擋不到的層、超出 ceiling 是 false confidence」。組合理解：

套用到本系統的 case

Case 1：blog 文章 mermaid + emoji 圖例

寫 git rebase 搬部分檔案 文章時、用 mermaid gitGraph 配 emoji 圖例：

1> 🟢 HIGHLIGHT = 接收檔案變更的目標 commit（A）
2> 🔴 REVERSE = 含有不該屬於它的檔案變更的 commit（C）

某 viewport 下 emoji 跟文字之間斷行錯位、🔴 在前一行、REVERSE = … 在下一行。

第一直覺（錯）：修 emoji 渲染、加 white-space: nowrap。

追問層次：

• 視覺層：emoji 斷行 → 改 CSS 可以擋
• 語意層：HIGHLIGHT 跟 REVERSE 是兩個獨立概念、被擠在 > 引用區塊 的兩行 + 用 emoji 作為唯一區分 — emoji 不渲染（終端 / 老瀏覽器）就完全失語意
• 邏輯層：兩個獨立概念本就不該擠在引用區塊裡、引用區塊的語意是「附加說明」、但兩個概念都是主要資訊

根因在邏輯層：兩個概念該分開承載。

正解：拆成獨立列表項、每項獨立一個概念：

1**四個 commit 的角色**：
2
3- **A**（接收目標）：commit C 中對檔案的修訂應該屬於這裡
4- **C**（變更來源）：同時改了目標檔案和其他 6 個檔案

修了之後、emoji 斷行、aria-label、複製貼上格式、螢幕閱讀器順序等所有下游症狀同時消失 — 因為根因被處理了。

Case 2：mermaid gitGraph type 顏色設定

跟 Case 1 同篇文章的另一個議題：mermaid 的 type: HIGHLIGHT / type: REVERSE 自訂顏色不渲染（mermaid_gitgraph_type_color_config）。

這個 是 純視覺問題 — 內容本身沒爭議、只是 mermaid themeVariables 缺配置。修 CSS / themeVariables 是對的。

兩個議題在同一篇文章、但層次不同 — 一個是邏輯層下游症狀（誤判為視覺）、一個是真視覺問題（CSS 修對位）。判讀層次比修法重要。

Case 3：multi-pass review 的層次盲點

#83 的 5 輪 frame（生成 / 意圖 / 語氣 / grep / 反例）是 horizontal — 同一份文字、5 個視角輪流看。但這 5 輪都可能落在同一個 vertical layer（例如全部在看視覺層）、漏掉語意 / 邏輯層。

本卡補的是垂直軸：每輪 frame 內、要意識到問題在哪一層。第 1 輪生成可能寫出語意混淆、第 2 輪對意圖如果只看視覺呈現、整個 review 就停在視覺層。

實際軌跡：blog 文章寫完跑了 #83 的多輪 review、catch 到 emoji 斷行（視覺層）、但沒 catch 到 HIGHLIGHT/REVERSE 概念混淆（語意層）— 因為每輪 frame 都沒把 layer 當成獨立檢查維度。

判讀徵兆

核心：視覺工具的 ROI = 跟問題層次對齊 × 不超出 ceiling。CSS / emoji / 顏色不會理解語意、所以只能擋呈現；語意 / 邏輯問題需要改結構 / 改概念分組、不靠視覺工具。試圖用視覺工具蓋語意 / 邏輯問題 = 假裝修了、實際比沒修更危險（false confidence 阻止下次警覺）。

Audit / risk 識別 reader 不該做 X 後、寫作回應的 frame 決定整段自然 positive 還是 disclaimer。 兩個 frame：

兩 frame 對應同一個 risk、但 reader 拿到的東西不同。Disclaimer frame 自然產出負面陳述；逐句翻成正向句法後 frame 仍是 disclaimer、後續 multi-pass review 會繼續 catch 到負面殘餘。整段 reframe 成 next-action chain 才是根治、不是字面換句。

情境

實際 case：對資安 problem-node 章節跑 audit、找到 D2 Major weakness——「reader 拿章節層 control name 直接 ship、會產生 false sense of security」。寫作回應的選擇：

v1（Disclaimer frame，直覺選擇）：

章節給的是 routing layer、不是 implementation layer。判讀完成 ≠ 控制面實作完成。Reader 拿章節層 control 名稱直接 ship、會產生 false sense of security。

「不是」「≠」「會產生」一連串負面陳述。Multi-pass review catch 到、要求正向改寫。

v2（Disclaimer frame + 字面正向化）：

判讀完成代表 routing 階段交付；實作完成要靠 mechanism 層跟下游模組接續。Reader 拿章節層 control 名稱直接 ship、會建立 false sense of security——routing 跟 implementation 是兩個分開的交付里程碑。

字面去掉「不是」「≠」、但 frame 仍是 disclaimer——主軸是「警告 reader 別把 routing 當 implementation」、reader 拿到的仍是 prohibition + warning、actionable next step 隱含在「靠下游接續」一句。

v3（Next-action frame，reframe 後）：

本章交付三樣：問題節點清單、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation：

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-card、那層展開機制 / 邊界 / context-dependence。
2. Delivery chain：「交接路由」欄位指向下游模組（05 / 06 / 08 視章節而定）、接配置 / 驗證 / 處置交付。

Implementation 強度取決於兩條 chain 的完成度。

整段 positive、不需 contrast。Reader 拿到兩條 actionable chain + 完成判準。Risk 仍被處理（chain 不走完 = implementation 沒交付）、用「該做什麼」取代「不要做什麼」。

理想做法

寫 audit response 段前先問 frame：

Frame 選擇判準

1. 本段給 reader 什麼

• 「不要做 X」→ disclaimer frame（避開）
• 「做 Y / Z」→ next-action frame（採用）

2. 能否把「不要 X」翻成「該做 Y / Z」

• 多數 case 可以、因為 risk 通常對應 missing action
• 例：「不要把 routing 當 implementation」= 「沿 mechanism + delivery 兩條 chain 走完」
• 例：「不要用 universal mitigation」= 「對稱寫 in-scope + out-of-scope + 補強路由」（#101）
• 例：「不要用名稱層 mitigation 對位」= 「補 mechanism + 前提兩層」（#102）

3. 段落主體寫 Y / Z chain、completeness 判準明示

• Chain 步驟具體可執行
• 完成判準明示（reader 知道何時 chain 走完）

4. 若必須提到 risk、放段落結尾、subordinate 結構

• Risk 是 chain 不走完的後果、放段尾一行
• Main flow 仍是 chain、risk 是 chain 失敗的描述
• 例：「兩條 chain 走完，控制面交付完整。Chain 走不完，章節閱讀只完成 routing 階段。」

跟 #94 的分工

#94 正向改寫保留對照論據 處理「保留 contrast 怎麼正向」——適用於 contrast 是論述完整性必需的 case（X、不是 Y 是讀者直覺替代）。本卡處理「整段能否不需 contrast」——適用於 disclaimer frame 整段。

兩卡互補：

• 先跑本卡：能否 reframe 成 next-action？能 → 不需 contrast、整段自然 positive
• 再跑 #94：必須保留 contrast 的 case（reader 直覺替代是 Y、明確排除）→ 用「X、不是 Y」+ reasoning 結構

順序錯（先跑 #94 再考慮 reframe）= 在 disclaimer frame 內逐句正向化、frame 沒動、surface fix。

沒這樣做的麻煩

Disclaimer 段反覆陷入字面 surface fix

整段 frame 是「不要 X」、逐句改 positive 後仍是「不要 X」變體。Multi-pass review 會反覆 catch 到負面殘餘、每次只改字面、frame 沒動。跟 #82 字面攔截 vs 行為精煉 同骨——字面層補丁不解行為層問題。

Reader 拿到 prohibition、不知道 actionable next step

Disclaimer 給 reader 的 actionable 是「不要做」、但「該做什麼」reader 自己腦補。多 reader 各自腦補不同 next step、結果各不相同。Next-action frame 把 next step 寫進文字、跨 reader 一致。

Self-case：本系列實際遇到

寫資安章節「從本章到實作」段時：

1. 第一次 batch（v1，8 章）：disclaimer frame、negative phrasing
2. Multi-pass review catch、第二次 batch（v2，8 章 sed 換句）：字面去否定詞、frame 仍 disclaimer
3. User 指出「應該重新思考為什麼這樣寫」：浮現 frame 議題、reframe v3

兩次 batch 改 8 章是高 cost surface fix；frame 反思在 v1 之前就該做、避開兩次無效 batch。Disclaimer 段一出現、第一反應該是「能不能 reframe」、不是「怎麼把否定詞翻正向」。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：寫 audit / risk 的回應段、prohibition 段、warning 段、disclaimer 段；任何起手是「告訴 reader 不要做 X」的段落
• 不適用：純 reference 段（不傳達 risk、純列 fact）、合規必填 disclaimer（法律 / 合約必須照規定文字）、安全告警（值班場景需要強烈警示語、reader 已是 expert）
• 邊界：「Reframe 成 next-action」≠「刪掉所有警示」——risk 嚴重 / actionable 不明時、保留 warning subordinate 在段落結尾、main flow 仍是 next-action chain；判別準則：「reader 讀完段落、能否列出 next step？」能 → frame OK、不能 → 仍是 disclaimer
• 過度應用反例：所有段都 reframe 成 next-action、把 reference / 規格段也改成「該做 Y」、reader 找不到 fact reference；frame 選擇對應段落責任、不是普世 rule

對 multi-pass review 的補丁

#83 multi-pass review 的輪 3「機會成本語氣」目前只跑 grep 抓絕對詞（應該 / 必須 / 不行 / 不可以 / 正確）、catch 不到 frame 議題——disclaimer frame 段落的字面可能全 positive、但整段仍是 prohibition。

補丁：輪 3 加一條 frame 檢查問題：「段落主體在告訴 reader 該做什麼、還是不該做什麼？」——告訴不該做 → reframe；告訴該做 → frame OK。

這條檢查放在輪 3 是因為 frame 議題跟「絕對主義語氣」同軸、都是「告訴 reader 規則 vs 教 reader 思考」的延伸。Frame 議題的根因檢查在輪 1 生成時更便宜（生成段落時就問 frame）、輪 3 是 fallback safety net。

術語翻譯要保留原文錨點：第一次出現用「中文術語（original term）」建立雙錨點，後續可依語境使用中文或原文。中文名稱負責讓段落可讀，原文名稱負責讓概念可回溯到來源、搜尋結果與跨語言討論。

這次 paternalism 被翻成「父權式保護」就是典型風險。中文詞把 reader 帶向 gender / patriarchy 的語意場，但原詞在倫理與決策脈絡裡更接近「家長主義」或「家長作風」：替他人決定什麼對他好。保留 paternalism 讓 reviewer 能立刻發現中文錨點偏移。

為什麼只留中文會漂移

中文翻譯常同時承擔「自然語感」與「術語對位」兩個責任，兩者不一定一致。自然語感好的詞可能帶入額外文化語意；術語對位準的詞可能不夠口語。只留中文時，讀者看不到原概念邊界，reviewer 也難判斷翻譯是否偏移。

翻譯是把 reader 從原文帶到中文語境。原文錨點是這條路的回程票。

翻譯檢查先看句內邏輯

翻譯問題先是句內邏輯問題，再是術語問題。把譯名放回原句後，要檢查它跟主詞、動詞、修飾語、因果關係是否成立；如果譯名讓句子多出原文沒有的前提，或讓後面的論證方向改變，這個翻譯就有問題。

這類錯誤容易犯，是因為第一版翻譯常由三個便利訊號驅動：字根聯想、上下文補完、中文順口度。三者都能產生看似合理的詞，但句內邏輯檢查會暴露它們是否真的承接原文概念。

Case：家長主義為什麼漂成父權式保護

paternalism 容易被誤翻成「父權式保護」，是因為譯者同時看到 paternal 的父系字根與「保護他人」的語境，於是把兩個表面訊號合成一個看似順口的中文詞。這個合成跳過了術語層檢查：paternalism 在倫理、政治哲學與決策設計裡的核心是「以對方利益之名限制對方自主」，跟性別權力無關。

「父權式保護」不是完全無法理解，但它放回句子後會讓邏輯多出一個沒有來源的前提：這裡似乎有父權或性別權力結構。原段落真正需要承接的是 autonomy、consent、intervention、best-interest justification；中文譯名一旦讓 reader 問「父權在哪」，就表示它沒有通過句內邏輯檢查。

這個案例的修法是先定義概念責任，再選中文譯名：

1家長主義（paternalism）在本文指「以對方利益之名限制對方自主」。
2常見譯名也包含「家長作風」；本文統一用「家長主義」。

這樣寫保留三個訊號：中文有穩定常見譯名、英文可回溯原概念、定義句把 reader 從「父權」導回「自主性與介入正當性」。

判斷什麼算術語

術語是跨段落、跨文件或跨社群會被重複引用的概念單位。判斷重點是讀者是否需要用同一個 label 追蹤同一個概念，跟它是不是英文無關。

例如 paternalism、narrow framing、premortem、dark pattern 都是術語；run、write、read 在一般句子裡多半不是術語。tool 若在討論 LLM tool selection 的決策偏誤時，才升格為術語錨點。

寫作規則

術語第一次出現時用中文在前、英文在括號後：家長主義（paternalism）。中文是讀者入口，英文是概念邊界。若英文是縮寫，第一次寫全名加縮寫：概念驗證（proof of concept, POC），後續再用 POC。

同一篇文章內保持一個中文譯名。若需要提到其他常見譯名，把它放在定義段，不在正文來回切換：

1家長主義（paternalism）在本文指「替他人決定什麼對他好」。
2常見譯名也包含「家長作風」；本文統一用「家長主義」。

翻譯不確定時，保留原文比假裝中文已穩定更可靠。下一輪 review 可改中文譯名，但原文錨點能維持搜尋與 cross-link 穩定。

Multi-pass 裡怎麼察覺翻譯邏輯錯位

翻譯檢查需要在多輪檢查中獨立成一個子 pass，重點不是問「這個中文順不順」，而是問「這個中文放回句子後，邏輯是否仍然成立」。一般命名 review 會問 grep、長度、一致性；翻譯邏輯 review 要額外問句內角色、修飾關係、因果方向與讀者追問。

翻譯 pass 的關鍵問題是：「這個中文詞是否讓句子說了一個原文沒有說的東西？」會的話，這是邏輯錯位，需要重譯。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：術語翻譯是概念對位，不是字面替換。中文讓文章可讀，原文讓概念可查、可驗、可被修正。少任一邊，reader 都會付額外成本。

中文壓縮術語要保留完整名詞頭：壓縮後的詞仍要能獨立回答「這是什麼」。技術文章可以把長概念縮短，但縮短後至少保留一個明確 head noun，例如「盲點」「風險」「偏誤」「檢查」「模式」「策略」。

這次「多步驟 perplexity 盲」的問題在中文最後只剩「盲」一個字，中英混用本身不構成障礙。讀者無法判斷它是「盲點」「盲區」「盲測」還是形容詞式比喻；改成「多步驟成功率盲點」後，概念角色才完整：它是一種盲點，不是一個未完成的片語。

為什麼單字壓縮會斷語意

中文可以高度省略，但技術寫作的省略成本由 reader 承擔。口語裡靠語境補完的詞，在文件裡會被單獨搜尋、引用、放進表格、出現在 index entry。當詞失去名詞頭，離開原句就失去語意。

壓縮後的詞會被拿去做段首、表格列名、索引條與 grep query。它必須在這些位置都能獨立成立。

Head noun 檢查

Head noun 是術語最後承擔分類責任的名詞。它告訴 reader 這個概念屬於哪一類東西：偏誤、風險、模式、策略、檢查、條件、訊號、盲點。

常用 head noun 應該具體對應概念責任：

改寫路徑

改寫壓縮詞時，先判斷它要扮演哪種概念角色，再補 head noun，不先追求短。

1. 先問：「這是偏誤、風險、盲點、模式，還是檢查？」
2. 保留最能定位來源的核心詞。
3. 把英文原詞放在中文後括號，避免中文壓縮造成歧義。
4. 對同一篇文章跑 grep，確認同概念沒有多個中文變體。

例如「多步驟 perplexity 盲」可拆成：

若原文術語本身重要，寫成「多步驟成功率盲點（multi-step success-rate blind spot）」比硬塞半段英文更穩。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：壓縮是最後一步，不是第一步。術語先要完整、可分類、可搜尋，再決定能不能縮短。少了 head noun 的短詞不是精煉，是把補完成本丟給 reader。

術語翻譯要保留概念角色：先判斷原詞在段落中承擔的是「論證方法」「檢查動作」「偏誤名稱」還是「流程階段」，再選中文名詞頭。中文譯名如果改變了概念類型，即使句子仍然順口，也會讓 reader 用錯誤方式理解後續操作。

這次 Steelman 被翻成「最強版本測試」就是這類問題。這個譯名抓到 WRAP checklist 裡的使用情境，卻把概念角色從「重建對方最強論點」壓成「通過一個測試」。較穩的寫法是「最強版本論證（Steelman）」：中文保留論證角色，英文保留可回溯來源。

為什麼概念角色會被翻掉

翻譯容易把術語放到當下文件的局部用途裡命名。當術語出現在 checklist、流程表或標題中，譯者會自然把它翻成「測試」「檢查」「步驟」；但原詞可能是一種論證姿態或推理方法，被壓成了測試動作。

Steelman 的核心不是「測出是否正確」，而是「把反方論點講到比原支持者更完整」。LessWrong 的 steelmanning 條目與 Wiktionary 的 steelman 定義都把它放在論證與辯論脈絡，而不是一般測試脈絡。中文若只寫「測試」，會把 reader 的注意力移到通過條件，而不是反方論證的重建品質。

Case：Steelman 為什麼不宜翻成最強版本測試

Steelman 常被中文社群譯成「鋼人論證」或「鋼鐵人論證」，也常直接保留英文。這些譯名各有成本：「鋼鐵人」容易被聯想到角色 IP，「鋼人」對未接觸者不直觀；但它們至少保留了「論證」這個角色。若改成「最強版本測試」，中文更直覺，卻把概念從論證方法改成檢核動作。

因此在 WRAP 文章中，canonical 用語採「最強版本論證（Steelman）」。第一次出現可補一句定義：「本文指先把被放棄選項或反方立場重建成最有力版本，再檢查自己的選擇是否仍站得住腳。」後續 checklist 可以寫「最強版本論證是否完成」，而不是把術語本身改成「測試」。

檢查流程

術語翻譯的概念角色檢查，要放在「句內邏輯」之後、「surface 同步」之前。先確認中文沒有多出原文沒有的前提，再確認中文名詞頭沒有把概念換類。

最低修法是：中文名詞頭要對應概念角色，英文括號要保留來源錨點。若中文沒有穩定固定譯名，採解釋型中文也可以，但不能把方法翻成測試、把偏誤翻成狀態、把流程階段翻成工具。

跟其他抽象層原則的關係

判讀徵兆

核心：翻譯術語時，中文要讓 reader 知道「這個概念是哪一類東西」。概念角色一旦翻錯，後續 checklist 再完整，也是在檢查錯的東西。

案例引用深度是寫作層的紀律工具：把 case 分成 skeleton / medium / rich 三類、各類對應不同承接句型、讓引用斷言能反向 trace 回 case 原文。誤判類型會引發 over-extrapolation（編造 case 沒寫的細節）或 under-citation（漏掉 case 揭露的 mechanism）、reviewer 抓出後修正成本高。

跨類型混合引用要分層處理 — 同段內若引兩類 case、先寫 rich case fact 作為支撐、再用 skeleton case 補方向、不混合成單一斷言。

為什麼這層紀律重要

LLM 從 case 反推內容時、訓練資料的「通用知識」會自動補進章節。當 case 沒寫的 mechanism / 數字 / taxonomy 被寫成「對應 [case]：揭露 X」斷言、讀者回查 case 時會發現章節說的「揭露」實際是 LLM 編造。

backend/01-07 七模組驗證（case-first workflow 的 case fidelity reviewer 抓的數據）：

最高的 92.9% 跟最低的 70% 差 23 個百分點 — 關鍵變數是引用紀律、案例品質本身只佔次要因素。Skeleton case 嚴守「揭露方向」、不擴寫成 rich case 樣式、就能達到 90%+。

三類 case 的判讀條件

Skeleton case：「揭露 X 方向、通用補充」

典型：模組內部 N.Cx 案例庫中只有 frame、無具體數字的短篇 case。內容深度 10-30 行、給「議題」「視角」、不給「實作細節」。

承接紀律：

• 引用為「揭露 X 方向」、不引用為「揭露 N 個具體場景數量」
• 後面補「以下展開基於通用工程知識補充」明示分層
• 不為了「整齊的 4 個攻擊面」「3 個攻擊向量」這種數字感、把 case 沒寫的 taxonomy 寫成 case 揭露

例：Meta Cache Consistency case 只給「promotion、shard move、故障恢復」三個方向 → 引用為「揭露三個方向」、不引用為「揭露具體 inconsistency window 數字」。

Medium case：「揭露 N 個機制 — A、B、C」

典型：模組內部 case 庫中、含結構化「決策機制」+「可觀測訊號」表、但無具體數字的中篇 case。內容深度 30-50 行、含 mechanism 名稱 + 訊號名稱、但不給 RPS / 延遲數字。

承接紀律：

• 用 case 直接列出的 mechanism 名稱 精準引用、比 skeleton 精準、比 rich 保守
• 不擴寫到 case 沒提的具體實作層（會踩「實作層擴寫過頭」失分）
• 「決策機制」段通常是 fact 層、「常見陷阱」段可能含作者判讀層、引用時也要分層

例：Amazon Shuffle Sharding case 揭露 cell boundary / shuffle sharding / static stability / constant work 四機制 → 引用四機制名稱、但不擴寫到「具體 shard 數量」「具體 cell 大小」等 case 沒提的細節。

Rich case：「揭露具體 X 數字 / 設計」

典型：跨模組 case 庫中含具體數字、設計細節、遷移路徑的長篇 case。內容深度 50-200 行、含具體 fact + 引用源。

承接紀律：

• 可直接引用為事實、case 揭露的具體數字（RPS、延遲、TPS、stale window）可放進章節
• 但 rich case 內常含「觀察層」（具體 fact）跟「判讀層」（作者推論）、引用時要分層（見 #116 fact-vs-derive 分層引用）
• 引用判讀層時用「揭露 X 觀察 + 作者判讀 Y」明示分層、避免把推論寫成 fact

例：Amazon Ads case「90M RPS + 5M writes/sec + 99.999%」 → 可直接寫進 KV 章節作為 reference。

反模式

Stage 1 抽 findings 時的判讀步驟

寫教學內容前、stage 1 audit case 庫時要 標明 case 類型：

1. 看 case 行數 + 內容密度、初判類型
2. 看是否有具體數字 / 設計細節、確認 Rich case
3. 看是否只給方向 / 議題、確認 Skeleton case
4. 介於中間時、傾向保守判讀為 Skeleton（避免過度承接）
5. 把類型寫進 findings 列表、stage 2 寫作時依類型決定承接深度

跨類型混合引用：

• 同一段內若引兩類 case、先寫 rich case fact 作為支撐、再用 skeleton case 補方向
• 不要把 skeleton case 的方向跟 rich case 的數字混合成單一斷言
• 跨類型引用時 disclaimer 要明示哪段屬通用、哪段屬 case fact

跟其他抽象層原則的關係

判讀徵兆

核心：誤判 case 類型 = 引用深度錯位 = case fidelity 失分。Stage 1 抽 findings 時花 30 秒判類型、能省 stage 4 修正 5-10 分鐘 / 案例。

Fact vs Derive 分層是 rich case 引用的內部紀律：case 內容分成觀察層（具體事實）跟判讀層（作者推論）兩層、章節引用時要各自標明來源、避免把作者判讀升級為 case fact。具體分層：

兩層在章節引用時要分層標明 — 一旦把判讀升級為 fact、章節就失去 case 支撐、讀者回查 case 時會發現章節說的「揭露」實際是作者推論。

跟「Case 類型決定引用深度」的差別

#115 case 類型決定引用深度 看 case 整體類型（skeleton / medium / rich）、決定承接深度。本卡看 case 內部結構（觀察 vs 判讀）、決定引用時要不要分層。

兩者互補：

• Skeleton case：主要是前者風險（擴寫成 fact）
• Rich case：兩個風險都要防（先判類型、再分層引用）
• Medium case：前者風險低（mechanism 名稱明確）、後者風險中（「常見陷阱」段可能含判讀）

為什麼這層紀律重要

LLM 寫作引用 rich case 時、容易把兩層壓縮成「揭露 X」、把作者判讀升級為 case fact。讀者回查 case 時會發現章節說的「fact」實際是作者判讀、章節的論述失去 case 支撐。

backend/05 deployment 模組驗證、case fidelity reviewer 抓出 4 個 high issue 都屬此類：

實證 1：Riot Games 35ms 延遲

• Case 觀察段：「35ms 是競技遊戲（VALORANT、League）的可接受上限」
• Case 判讀段：「從這個門檻反推：玩家所在 region 不能跨洲、需要區域 cluster」
• 章節（錯）：「揭露 35ms latency 反推 region 部署」← 合併兩層、把判讀寫成揭露
• 章節（對）：「揭露 35ms 延遲門檻 + Local Zones / Outposts 區域部署、可推得『延遲門檻反推 region 部署數量』」← 分層標明

實證 2：GCP K8s 130K scale

• Case 觀察段：「control plane 極限取決於 storage backend」+「GCP 用 Spanner 替換 etcd」（兩個分開的點）
• Case 判讀段：「把 storage 從瓶頸變成『showed no signs of not being able to support higher scales』」
• 章節（錯）：「揭露 Spanner 替 etcd 才是 K8s 規模極限的關鍵」← 把判讀升級成硬性結論、強化詞「才是」是訊號
• 章節（對）：「揭露 control plane vs data plane 容量規劃要分開、storage backend（GCP 用 Spanner 替代 etcd）是 K8s 規模極限的核心瓶頸層」← 保留條件性表述

實證 3：Riot Games 漏歷史轉折

• Case 觀察段：「關鍵架構決策：從 multi-tenant cluster 模型改成 single-tenant per game」
• 章節（錯）：「揭露 single-tenant per game 的多 cluster 策略」← 漏掉轉折、只保留終態
• 章節（對）：「揭露架構決策從 multi-tenant cluster 改成 single-tenant per game」← 保留 case 揭露的關鍵歷史

引用句型對照

Skeleton case 引用

1對應 [X.CN case-title]：揭露 X / Y / Z 三個方向（case 直接列出）；
2以下展開基於通用工程知識補充。

Rich case 引用（單層、純觀察）

1對應 [X.CN case-title]：揭露 X 具體數字 / 設計（case 觀察層）。

Rich case 引用（含作者判讀）

1對應 [X.CN case-title]：揭露 X 觀察 + 作者判讀 Y（case 中 Y 屬判讀層、
2本章引用此推論）。

Rich case 引用（避免硬性結論）

避免使用「才是 / 必須 / 一定 / 關鍵是」這類強化詞、保留 case 原文的條件性表述（「取決於」「核心瓶頸」「主要驅動」）。

反模式

Stage 1 抽 findings 的標明格式

抽 findings 時、rich case 的 finding 要標明來源層：

1Finding: 線性擴展是 OLTP 設計最高目標、coordinator 是傳統 OLTP 的擴展瓶頸
2來源: 9.C10 Spanner 案例
3- 觀察層：「2 nodes → 45K reads/sec, 4 nodes → 90K reads/sec」段（case fact）
4- 判讀層：作者「線性擴展是最高目標」是推論（case 中標為判讀）
5章節: 1.11 全球分散式 OLTP
6引用方式: 觀察層直接引用、判讀層用「作者判讀」明示

Stage 2 寫作時依照 finding 列表的層別標記決定引用句型。

自掃描提示

寫作完後、檢查每處 rich case 引用是否：

1. 用了「才是 / 必須 / 一定 / 關鍵是 / 唯一」等強化詞 → 通常是把判讀升級成 fact
2. 跨越兩段 case 內容（觀察 + 判讀）卻寫成單一斷言 → 應分層
3. 引用後直接展開細節、沒給「以下基於通用工程知識補充」承接 → 容易把通用知識掛到 case 名下
4. 漏掉 case 揭露的歷史轉折 / 條件 / 邊界 → 重讀 case「決策段」補回

跟其他抽象層原則的關係

判讀徵兆

核心：Fact 跟 derive 的差別在「來源是 case 還是作者」、跟內容對錯無關。讀者回查 case 時、要能反向 trace 章節的每個斷言到 case 原文的對應段、找不到的就是錯位。

跨 case 合成 frame 必須標為章節合成、非 case 原文揭露。這層紀律規範「章節把多個 case 的失效訊號抽象為更高層概念」時的引用語氣 — 抽象 frame 在 case 原文 grep 不到時、要 explicit 標「本章合成」、避免讀者把章節 derive 當 case fact。兩種寫法的差別：

兩種寫法的差別在 case fidelity 紀律 — 不只是修辭層的選擇 — reviewer B 對照原文時、會抓「揭露 X」斷言是否有 case 原文支撐。

跟既有 fact-vs-derive 分層的差別

#116 fact vs derive 分層 處理 單一 case 內部 的觀察層 vs 判讀層分層。本卡處理 跨多個 case 抽象出更高層 frame 的失分類型 — 屬於 fact-derive 紀律的第三類風險：

為什麼這層紀律重要

LLM 寫教學內容時容易把多個 case 的相似訊號抽象成 frame、讓段落結構更清楚。但 標明 frame 來源 直接決定 case fidelity：

• Case 真的揭露 frame：case 原文段直接寫此 frame、可寫「兩 case 共同標明 X」（屬合法 fact 引用）
• 章節從 case 失效訊號抽象：case 寫的是 單獨 訊號、章節把多個訊號抽象成更高層 frame、要明示「本章合成、非 case 原文」

漏掉這層 disclaimer、讀者把章節 derive 當成 case fact、回查 case 時會找不到 frame、章節失去 case 支撐。

實證案例

backend/07 batch 1 模組驗證、case fidelity reviewer 抓的 2 個 high issue 都屬此類：

實證 1：7.7 跨工具回查壓力

• 章節（錯）：「對應 [Uber 2022] 跟 [Slack 2022]：兩個案例都揭露『身分事件後的跨工具回查壓力』」
• Case 原文：Uber 失效控制面寫「身分異常事件與值班告警串接不足」、Slack 寫「程式碼資產存取異常訊號未快速匯流」— 都是 單工具內 的訊號失效、「跨工具」這個 axis 是章節合成
• 章節（對）：「兩個案例分別在身分監控層揭露同類失效訊號 — Uber 標明 X、Slack 標明 Y。本章把兩者抽象為『跨工具回查壓力』是稽核視角的合成 frame、非 case 原文框架。」

實證 2：7.7 平台責任切分

• 章節（錯）：「對應 [SolarWinds 2020]：揭露的『供應鏈事件中的平台責任切分』是稽核層的代表壓力場景」
• Case 原文：失效控制面寫「更新來源信任過於單點」「行為監測難以區分合法元件」「供應鏈異常缺隔離流程」— 都是供應鏈信任議題、不是「平台 vs 產品的 audit 責任分離」
• 章節（對）：「案例的失效控制面標明 X / Y / Z。本章把這幾條失效面從供應鏈信任視角延伸到稽核視角、抽象為『平台 vs 產品的責任邊界判讀壓力』— 此 frame 為本章合成、非 case 原文。」

反例：case 真的揭露 frame（不需 disclaimer）

跨 case 引用是否要標「本章合成」、取決於 frame 在 case 原文是否能 grep 找到。當 case 原文段直接寫此 frame、可直接引用：

反例 1：邊界設備三同步 mechanism

• 章節：「對應 [Citrix Bleed 2023] 跟 [PAN-OS 2024]：兩個案例的『mechanism 總綱』段共同標明這個三同步原則」
• Case 原文：兩個 case 文末「mechanism 總綱」段確實寫「邊界事件的核心是讓『漏洞修補』『會話 / 憑證失效』『異常痕跡清查』三件事同步發生」
• 判讀：frame 在 case 原文、可引用「兩 case 共同標明」、不需 disclaimer

差別判斷：

為什麼 LLM 容易踩

從 LLM 寫教學內容的視角看、跨 case 合成 frame 是「自然湧現」的模式：

1. LLM 讀完多個 case 後、會自動抽象出共通 pattern（這是 LLM 的訓練優勢）
2. 寫章節時、章節結構需要 frame 把多個 case 組織起來（教學結構需求）
3. 合成 frame 寫成「兩 case 都揭露 X」最順、不寫 disclaimer 最省字數
4. 結果是 frame 本身不在 case 原文、但章節寫得像 case 揭露

LLM 沒辦法 self-detect 這個盲點 — 因為從 LLM 視角、「合成」跟「揭露」在語意上很接近、需要對照 case 原文才能分辨。

防範路徑

Stage 2 寫作時主動防範

每寫一個跨 case 合成 frame、跑「frame 在 case 原文 grep 得到嗎」檢查：

1rg "<frame 文字>" <case file>

抓不到 → 用「本章合成、非 case 原文」disclaimer 抓得到 → 直接引用「兩 case 共同標明」

Stage 3 reviewer B prompt 補強

設計 reviewer B prompt 時、要明示「跨 case 合成 frame 必須標為本章合成、非 case 原文」是 high 級 issue 抓取項。沒明示時、reviewer B 容易把這類問題降級為 medium、累積失分。

prompt 應包含：

1特別檢查：當引用句說「兩個 case 都揭露 X」時、確認 X 是 case 原文寫的、
2還是章節跨 case 合成的。後者要在引用句明示「本章合成 / 非 case 原文框架」。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：跨 case 合成 frame 本身是合法的寫作技巧、問題在 不標明。一句 disclaimer（「本章合成、非 case 原文」）就能把 fact-derive 紀律補回來、修法成本極低。

Standard-driven 是 case-first 的替代策略、適用 standard framework 比 case 庫成熟的領域（如 LLM 安全）。判斷該用哪種策略看四維度：

典型對照：

• Case-driven 領域：分散式系統 / 安全控制面 / 可靠性 / 訊息佇列（案例公開充分、半衰期 5+ 年）
• Standard-driven 領域：LLM 安全（OWASP LLM Top 10 / MITRE ATLAS 已成型、案例 6 個月過時）、新興 compliance（NIST AI RMF）、cloud-native 標準（CNCF baseline）

Standard-driven 跟 case-driven 是平行的選項、依領域特性選用 — 兩者各自有適用情境、沒有退化 / 進階關係。誤套會導致 case 庫過早建構（standard-driven 領域）或章節停在教科書級（case-driven 領域）。

為什麼這個 axis 重要

之前的 case-first workflow 預設「沒 case 庫的新主題、要先建 case 庫」— 這暗示缺 case 庫一定要先補。LLM 安全章節驗證了 第三條路：

當該領域的 標準框架（如 OWASP LLM Top 10 2025 / NIST AI RMF 1.0 / MITRE ATLAS）已涵蓋 threat 分類、且 case 維護半衰期短於 standard、章節應 用 standard-driven 取代 case-driven。

誤套的代價：

• 誤套 case-driven 到 standard-driven 領域：建 case 庫 8-12 小時、6 個月後 case 過時、變成維護負擔
• 誤套 standard-driven 到 case-driven 領域：章節停留在標準引用、漏掉真實事故才會浮現的議題、scope 盲點

Standard-driven 章節的寫作策略

當判讀領域屬 standard-driven、章節採以下策略：

1. 章節對齊 standard framework 分類

用 framework 章節 ID 標明（如 OWASP LLM01 / NIST AI-1.1）取代「對應 [case] —」斷言。

1本章的 threat scope 對應 OWASP LLM Top 10 LLM01（Prompt Injection）+
2LLM02（Insecure Output Handling）、NIST AI RMF 1.0 MEASURE-2.7。

2. 加 Last reviewed cadence

每 quarter 重評估 standard 版本跟章節對應、寫進 frontmatter：

1---
2title: "..."
3date: 2026-05-12
4description: "..."
5tags: ["backend", "security", "llm"]
6---
7
8> Last reviewed: 2026-05-12（對齊 OWASP LLM Top 10 2025）

3.「案例觸發參考」段標明「公開案例累積中、值得追蹤的方向」

不寫「對應 [case] 揭露」斷言、避免引用源不穩定：

 1## 案例觸發參考
 2
 3LLM agent prompt injection 的公開案例累積中、值得追蹤的方向：
 4
 5- email assistant 場景：閱讀含 injection 的郵件、誘導 agent 觸發外送或洩漏
 6- coding agent 場景：讀含 injection 的 PR / issue、誘導 agent 修改非預期檔案
 7- 跨 agent chain：injection 在 sub-agent 累積、影響 parent agent 決策
 8
 9> **事實查核註**：LLM agent prompt injection 是 2024-2025 快速演進的研究領域、
10> 攻擊形態、防禦模式、公開案例都在累積中。建議引用前以 OWASP LLM Top 10、
11> 近期論文跟主流 vendor 的 incident 公告為準。

4. 引用標準時用版本號

OWASP LLM Top 10 2025 / NIST AI RMF 1.0 / MITRE ATLAS continuous — framework 改版要 trigger 章節重審。

引用源規範見 #104 security citation 時效精確。

何時要從 standard-driven 轉回 case-driven

下列 tripwire 出現時、重新評估：

不滿足任一條件時、繼續走 standard-driven、不勉強建 case 庫。

07 LLM 章節實證

backend/07 batch 2（LLM 安全 5 章）驗證 standard-driven 策略：

• 章節 113-137 行、含完整 threat scope + 問題節點表 + 風險邊界
• 引用 OWASP LLM Top 10 + NIST AI RMF + MITRE ATLAS 取代個別 case 引用
• 加 Last reviewed: 2026-05-12 cadence
• 「案例觸發參考」段寫「公開案例累積中、值得追蹤的方向」+「事實查核註」
• 完全不寫「對應 [case] —」斷言、不存在 case fidelity reviewer 該抓的準確性問題

對照 backend/01-07 batch 1 的 case-driven 章節、LLM 章節是 用不同方法達到同樣品質 — scope 涵蓋真實 production 議題（KV cache 跨租戶、shared prefix optimization、batch 推論順序敏感）、不停在教科書級內容。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：寫教學內容的策略要依領域性質選擇 — case-driven 適合議題穩定 + case 公開的領域、standard-driven 適合 framework 比 case 庫成熟的領域。沒有預設策略。

Routing layer 章節辨識是擴章策略選擇的前置紀律。章節分三類、各對應不同擴章策略：

擴章策略要對應章節結構 — 在 routing layer 章節空白擴章會引發 frame 重複展開或章節失衡。誤判章節類型是 backend/07 batch 1 三個 H issue 的共同根因。

跟 standard-driven 領域判讀的差別

#118 standard-driven vs case-driven 領域判讀 看 領域整體 該用哪種策略。本卡看 單一章節 的結構類型決定擴章策略。

兩者互補：

• 領域 + 章節同 case-driven：走完整 case-first workflow（空白擴章）
• 領域 case-driven + 章節 routing layer：走補強段（在現有結構內補深化）
• 領域 standard-driven：所有章節用 standard 引用 + Last reviewed cadence

為什麼章節結構決定擴章策略

case-first workflow 之前預設「章節空白、case 庫驅動擴章」— 但實務中常遇到 章節已有 routing layer skeleton 的情境（如 backend/07 batch 1 紅隊核心安全 7 章）：

• 章節已有 threat scope（In-scope / Out-of-scope 路由）
• 已有 問題節點表（4-6 個問題節點 + 判讀訊號 + 風險後果 + 前置控制面）
• 已有 風險邊界（4-6 條升級條件）
• 已有 案例觸發參考（已 link 3-5 個 case）

這種章節屬 routing layer 結構 — 完整 skeleton 已存在、case 引用段已 link 既有 case。空白擴章會：

• 跟既有問題節點表結構衝突
• 把章節擴成厚重 case-driven 章節、失衡 routing 性質
• 引發 frame 重複展開（既有節點 + 新擴章節點都寫一遍）

正確策略：補強段 — 在現有結構內補 mechanism 深化段、不重建結構。

Routing layer 章節的判讀訊號

掃描章節時、看以下訊號判斷是否為 routing layer：

含 4+ 個訊號 → 屬 routing layer 章節、走補強段策略。

補強段策略

在 routing layer 章節內補 case-driven 深化段、遵守以下紀律：

1. 補強段位置

通常放在「問題節點表」後、「常見風險邊界」前：

1## 問題節點（案例觸發式）
2
3| 問題節點 | ... | ... |
4
5## [新增補強段：對應某問題節點的 mechanism 深化]
6
7[補強內容、case 引用三段式]
8
9## 常見風險邊界

2. 補強段的範圍紀律

• 每個補強段對應 1-2 個既有問題節點、不擴新議題
• 不重建 threat scope / 問題節點表（保留 routing 性質）
• 補的 mechanism 深化要明示「本節聚焦 X 視角、canonical 在 Y 章」（避免 frame 重複）

3. Cross-link 密度上升

補強段要明示「跟其他章節的視角分工」、否則 reviewer C 會抓 frame 重複展開：

1## 高權限工具的會話收斂節奏
2
3身分被取得後、token 撤銷跟 session kill 的時間窗口直接決定攻擊者可觸及的
4資產面積、是初始落點橫向擴散的關鍵節流點。會話收斂節奏的 canonical 在
5[7.5 § 會話重放跟全域失效](../transport-trust-and-certificate-lifecycle/#會話重放跟全域失效canonical)、
6本節從身分層補 token 撤銷窗口的 specific 訊號。
7
8對應 [Slack 2022 case]：...

07 batch 1 實證

backend/07 batch 1 七章節（identity-access / secrets / entrypoint / transport / credential-rotation / audit / workload-identity）走補強段策略：

• 章節原本 80-100 行、補強後 100-140 行（+20-40 行 / 章）
• 每章補 2-3 個 mechanism 深化段、對應既有問題節點
• 三個 H issue（C-H1/H2/H3）都是 frame 重複展開、補強段紀律失效引起
• 修正後加 cross-link 明示「canonical 在 X 章、本節補 Y 視角」、frame 重複收斂

對照 backend/06 reliability 模組（章節空白擴章）：

• 章節原本 30-50 行、擴章後 80-90 行
• 每章建 mechanism + 訊號 + 反模式完整結構
• 沒有 routing skeleton 衝突問題

兩種策略對應不同章節初始狀態、不互斥。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：擴章策略對應章節結構 — 空白章節走 case-driven 擴章、routing layer 章節走補強段、導讀章節走 standard-driven。三類策略各自有適用情境、選錯會引發 frame 重複展開或章節失衡。

Case 引用段落要走三段式結構紀律 — 段首是概念定義句、case 引用退到第二位置、最後通用工程知識展開。讓段落結構反映「概念 → 案例 → 操作」的論證流、不是「案例 → 概念 → 操作」的反向流。

違反三段式最常見的形式是「概念定義句缺位、case 引用直接當段首」— 讀者尚未理解概念就被丟入案例細節。

跟其他 case 引用紀律的差別

本卡跟 #115 / #116 / #117 是 case 引用紀律的不同 axis、互相正交：

四 axis 組合起來覆蓋 case 引用的完整紀律。寫每段 case 引用時、四個 axis 都要過一遍。

為什麼這層紀律重要

backend/06 模組 reviewer 抓出 11/12 新段都犯「case 引用取代概念定義」的問題、屬最大宗 systemic 違規。原因：

1. LLM 從 case 反推內容時、容易把 case 揭露當概念出發點
2. Case 引用句構單一（「對應 [X]：揭露 N 個機制」）、跨章讀感同質
3. 概念定義被推到第二段、商業邏輯先於 case 的原則被推翻

三段式紀律的價值是把「概念」「案例」「展開」三層分離、讓讀者依層級理解。

三段式範例

正確結構

 1## 失效局部化：cell 邊界跟 shuffle sharding
 2
 3失效局部化是把單一依賴退化限制在最小可影響範圍的能力。把「依賴 budget」
 4從統一全域帳本拆成 per-cell 可用度結構、是這層治理的核心責任。失效局部
 5化要解四個子問題：擴散邊界、熱點重疊、控制面解耦、失敗模式工作量恆定。
 6
 7對應 [A1 Amazon Shuffle Sharding 與 Cell 邊界](.../shuffle-sharding-and-cell-boundary/)：
 8揭露四個機制對應上述四個子問題 — cell 邊界（擴散邊界）、shuffle sharding
 9（熱點重疊）、static stability（控制面解耦）、constant work（失敗模式工作
10量恆定）。這四個機制把恢復策略從「全域搶救」轉為「分批收斂」。
11
12以下基於通用工程知識補充的具體操作 ...

錯誤結構

1## 失效局部化：cell 邊界跟 shuffle sharding
2
3依賴 budget 的另一個面向是把失效影響限制在局部、不擴散到全域。多租戶
4服務跟共享資源服務若沒有明確邊界，單一依賴退化會觸發整體退化。
5
6對應 [A1 Amazon Shuffle Sharding 與 Cell 邊界]：
7揭露四個機制 — cell 邊界、shuffle sharding、static stability、constant work。

差異：

• 正確：段首「失效局部化是…的能力」直接給概念定義、case 揭露的四機制對應到「四個子問題」、讀者懂概念才看到案例
• 錯誤：段首用「另一個面向」鋪墊、case 直接列四機制、讀者尚未理解就被丟入案例細節

案例引用句構分流（07 模組強化）

即使遵守三段式紀律、跨章 case 引用句構仍會同質化。07 batch 1 驗證 13 處 case 引用 11 處用同一句構「揭露 N 層失效控制面 — A、B、C」、讀者跨章連讀時把 case 引用當儀式而非論證。

分流原則：句構跟著 case 類型走、用 case 自身結構決定引用方式：

寫多章時刻意變化句構、避免讀者連讀數章感「每段開頭都長一樣」。

反模式

Stage 2 自查清單

寫完每章 case 引用後、檢查：

1. 段首是否是概念定義句？（不是 case 引用、不是「另一個面向」鋪墊）
2. Case 引用是否在第二位置？（不是段首）
3. 通用展開是否有「以下基於通用工程知識補充」承接？
4. 句構是否跟前面章節相同？（同模組超過 3 章用同句構就該變化）

掃描指令：

1# 找段首是 case 引用的段（最嚴格）
2rg -n "^對應 \[" <module-paths>
3
4# 找 ## 標題後緊接 case 引用的段（要手動 review）
5rg -B0 -A3 -n "^## " <file> | rg "對應 \["
6
7# 找句構同質化（跨檔抓「揭露 N 層失效控制面」出現次數）
8rg -c "揭露[^。]*失效控制面" <module-paths>

False positive 警示：^對應 \[ 在三段分離結構（概念定義段 → 空行 → case 引用獨立段）下會 false positive、要用 awk 看 prev line 是否為實質概念段：

1awk '/^對應 \[/{prev_blank=(prev==""); print FILENAME ":" NR ": prev_blank=" prev_blank} {prev=$0}' <file>

prev_blank=1 + 前段有實質概念定義 → 屬規範允許（三段分離）。

Polish pass 修法

如果 stage 3 reviewer 抓出大量「case 引用段首」issue、polish pass 的修法：

1. 每個有 issue 的段、在 case 引用前補一句「概念定義 + 核心責任」
2. 不重寫整段、只加 lead sentence（保留 case 引用本身）
3. 變化 case 引用句構：把 11/12 段同一句構打散成 3-4 種變化
4. 修完跑自掃描確認段首不再是 case 引用

修法成本：每段補 1-2 句概念定義、單章約 5-10 分鐘、整模組 1-2 小時。

跟其他抽象層原則的關係

判讀徵兆

核心：三段式紀律的價值是把「概念 → 案例 → 操作」三層分離、讓讀者依層級理解。段首被 case 引用取代會推翻商業邏輯先於 case 的原則、是 LLM 寫教學內容的系統性傾向。

Agent team context 隔離是 LLM-era review 工具設計的核心模式 — 用 N 個獨立 reviewer instance 各自跑 background、各自寫 output file、主 context 只接精煉摘要、不被 reviewer 細節污染。

跟 multi-pass review（#83）的差別：#83 是 同一 reviewer 換輪次 frame（生成 / 對意圖 / 機會成本 / grep / 反例）；本卡是 不同 reviewer instance 各自獨立（規範 / 案例準確 / 跨章一致 / compositional-writing 等）。兩者正交、可疊加。

跟 multi-pass review 的差別

兩軸正交、可疊加 — 同一 reviewer instance 內跑 multi-pass（#83）、跨 reviewer instance 各自獨立（本卡）。Case-first stage 3 設計同時用兩軸：3 個 reviewer instance 各自獨立 + 每個 reviewer 內部跑多輪 frame check。

為什麼這層設計重要

單一 reviewer 同時處理多維度有兩個限制：

1. 維度盲點：一個 reviewer 同時看寫作規範 + 案例準確性 + 跨章一致性、容易維度互相干擾、最後每個維度都看不深
2. Context 污染：reviewer 讀完整 commit + 所有案例 + 所有章節後、自身 context 被佔滿、給的建議也對應主 context 跟著沉重

Context 隔離解這兩個問題：

• 用 N 個專責 reviewer、各自只處理一個維度 → 維度深度提升
• Reviewer 各自 background、不污染主 context → 主 context 保留判讀空間
• Reviewer 寫 output file、不傳 raw 內容到主 context → 主 context 增量極少

設計紀律：何時用幾個 reviewer

Reviewer 數量決定取決於審查對象的維度複雜度：

維度設計要對審查對象客製、不要固定一套維度套所有任務。

平行 background 的具體實作

Case-first stage 3 的實作 pattern：

 1# Agent tool spawn 平行 background
 2for reviewer_id in ['A', 'B', 'C']:
 3    Agent({
 4        description: f"Reviewer {reviewer_id}: {dimension}",
 5        subagent_type: "general-purpose",
 6        run_in_background: True,
 7        prompt: get_reviewer_prompt(reviewer_id)
 8    })
 9
10# 主 context 不阻塞、繼續其他工作
11# Reviewer 完成時主 context 接通知（task-notification）
12# Reviewer 各自寫 output 到 /tmp/reviewer-{id}-report.md
13# 主 context 讀 output 彙整、不讀 raw conversation transcript

關鍵設計選擇：

1. run_in_background: true：平行跑、不阻塞
2. Reviewer 寫 output file：報告寫 /tmp/... 不污染主 conversation
3. 主 context 不讀 reviewer transcript：只讀 task-notification 的 summary + 最後讀 output file
4. Reviewer prompt 含「不要佔我主 context、報告寫進檔即可」明示：避免 reviewer 把 raw issue 都吐回主 conversation

Reviewer 維度設計：跟著任務客製化

Reviewer 維度不該固定 — backend/07 batch 1 案例驅動章節用「規範 / 案例 / 跨章一致」三維度、方法論審查用「規範 / 三方自一致 / 概念邊界 / compositional-writing」四維度。

設計原則：

• 拆 axis 不重疊：每個 reviewer 的維度跟其他 reviewer 互斥（如「規範」vs「案例準確性」是不同 axis）
• 覆蓋審查對象的關鍵風險：審查 case-driven 章節要 case fidelity reviewer、審查方法論要三方自一致性 reviewer
• 預期 issue baseline 設好：每 reviewer 給 prompt 預期數量、reviewer 不要過度抓 / 漏抓
• prompt 含主 context 保護指令：「報告寫到 /tmp/X-report.md、不要在主 conversation 吐 raw issue」

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：Agent team context 隔離是 LLM-era review 工具的設計模式 — 用 instance 隔離換維度深度跟 context 保護。維度設計要對任務客製化、不要固定不變。

「模板」有兩個維度、寫作規範通常只 enforce 第一維、第二維是隱形維度：

實際案例（backend/07 批量 51 vendor）：51 個 vendor 個別頁的「最短判讀路徑」段都收尾在「四件事任一缺失、就是 X 邊界的待補項目」。51/51 同骨、跨 9 個 service group、跨不同 vendor 性質。每一篇單看符合規範、表格有延伸、無 emoji、章節結構齊、案例正確；連讀 5 篇後讀者預期化、cadence 變成「閱讀時自動跳過的雜訊」。

為什麼 cadence 維度最容易失守

三層原因疊加：

1. 規範語言只涵蓋 內容 層、不涵蓋 形式 層：AGENTS.md 原則八寫「不為了整齊把不同案例硬套同一模板」、配的例子是「規模對照、tripwire、失敗模式」；批量寫作時 Claude 把「保留情境差異」自動解讀成「敘事內容不同就行」、cadence / framing 不在規範定義的「模板」內、沒被擋。

2. 批量寫作的便利成本最低：寫第一個 vendor 找到一個「都過 lint + 章節完整 + 表格有延伸」的 framing 後、複製這個骨架到下 50 個 vendor 是最省 token 的選擇；每篇都合規、輸出快、且看不到單篇有問題。

3. 單篇 review 看不到 cadence 違規：cadence 同質化是 跨檔 emergence、單檔 review（一次只讀一份）不會 trigger 訊號；只有「連讀多份 + 對齊 first sentence / closing line」才會看出。連 reviewer agent 也容易漏 — backend/07 三個 reviewer 中、只有寫作規範 reviewer 一句 footnote 提到「cadence 過齊」、其他兩個都沒抓到。

Cadence 自檢方法

寫批量內容（≥ 5 個同類檔案）時、加入 cadence 抽樣 pass。不是讀全文、是抽固定位置的句子做骨架對照：

抽樣不需要全做、選 最容易反覆使用 的 2-3 個位置即可；批量越大、抽樣位置越要多。

Cadence 多樣性是「正向設計」、不是「事後修補」

寫第 1-3 篇時就該意識：cadence 會被複製到下 N 篇。對策不是「寫完後 review 改」、是「寫第一篇時就刻意製造 N 種 framing 變體、之後在這 N 種裡輪替」：

這個做法的關鍵是 變體不是事後抽出來的、是設計階段就準備好的。一旦寫過 5 篇還沒主動製造變體、就會預設複製第一篇 framing 到所有後續檔案。

Dogfood evidence (2026-05-18、N=4 sub-threshold 驗證)

本卡浮現後立即跑了一次小批量 dogfood：4 篇 deep article（Vault dynamic credential / K8s graceful shutdown / Splunk RBA / Cloudflare Page Shield）寫作前主動規劃 4 種不同 entry framing（標準問題情境 / 痛點宣告 / 概念反向定義 / 對照表驅動）、跨檔 cadence audit 結果：

兩個重點驗證：

1. Sub-threshold（N < 5）仍適用：原本 pilot 表格寫「第 1-3 篇刻意寫 3 種變體」、預設批量 ≥ 5 篇；實測 N=4 sub-threshold 配 4 種 variant 也能完全錯開 cadence
2. Pilot phase 邊際成本低於 batch 後 polish：寫作前花 ~5 分鐘規劃 4 種 framing variant、vs backend/07 51 vendor 批量後 polish ~30-60 分鐘改 51 處 cadence — 預先設計成本 < 事後修正成本 ~10 倍

Update: N=5 full-threshold + 同 vendor sub-tool 系列驗證

第一次 N=4 驗證後、立即再跑 N=5 full-threshold batch — 5 篇 PostgreSQL sub-tool deep article（Patroni HA / autovacuum tuning / declarative partitioning / logical replication + Debezium / PITR + WAL archiving）。這批比第一批 cadence collapse 風險更高 — 同 vendor、同 article type、同 6-section structure、同 audience。

三批 cadence 比較：

額外驗證（補既有 sub-threshold 驗證）：

3. Full-threshold N=5 variant 不耗盡：5 種 variant（lifecycle-driven / pain-driven / concept-reversed / table-driven / standard 6-section）都對應主題本質、沒有「為了不同而不同」、5 篇骨架完全錯開
4. 同 vendor 同 article type 仍可錯開：理論上 同 vendor 同 type 是 cadence collapse 最高風險場景（共同變數最多）；實測 variant 設計仍能覆蓋、collapse 風險不來自共同 context、來自 寫作前是否主動規劃 variant
5. 批次間 sample size 邊界更寬：原 principle 寫 ≥ 5 才適用、實測 N=4 跟 N=5 一樣有效、threshold 5 是 emergence 訊號偵測的閾值、不是 principle 適用 的閾值；變體規劃在 N ≥ 2 就該做

Update: Partial collapse 實證（被動 vs 主動 variant 對照）

Partial collapse 定義：批量內 部分檔案 cadence 收斂、部分錯開、collapse rate 在 0% 跟 100% 之間（典型 30-70%）。跟全 collapse（100%）跟全錯開（0%）的差異在於 混合訊號：同批內存在不同寫作行為（被動 vs 主動 variant 規劃）、cadence 結果反映行為差異。

第三輪 batch 寫 5 篇 migration playbook（跨 vendor、不同 module）、前 3 篇被動寫作、後 2 篇主動規劃 variant。結果：

3/5 collapse、2/5 錯開 = partial collapse。

五批 cadence rate 對照：

主題語意 attractor 定義（atomic）：批量寫作中、主題本身的語意結構 對 framing 選擇產生的隱形吸引力 — 例如 migration 主題天然引出「為什麼遷：X / Y / Z driver」開頭、SIEM rule 翻譯天然引出「先 audit 再 translate」開頭。這是 #123 多重硬規範收斂 cadence 的 內容驅動子類型：#123 處理的是 外部 constraint（章節結構 + lint 規則）收斂 cadence、本概念處理的是 主題內部語意 收斂 cadence；兩者機制同骨、attractor 來源不同。

三個關鍵 finding：

6. 主題語意 attractor 跟主題相似性正相關：5 篇 migration playbook 都圍繞「為什麼換 vendor」、entry 自然收斂到「driver list」格式；migration 主題的語意 attractor 比結構 constraint 更強
7. Sample size 不能解 cadence collapse：N=5 跟前批 N=5 全錯開差異在 variant 規劃、不是 sample size；證實本卡論斷「variant 規劃必須主動、不是 N≥5 自動避免」
8. Partial collapse 是 natural attractor 訊號、不是 principle 強化證據：本批 3/5 collapse 提供 主題語意 attractor 強度 的量化訊號（在無 variant 規劃時 60% 同質化）、但不增強既有 principle 的論證力 — principle 在前兩批已穩定、本批只是揭露新 attractor 來源；後續寫作流程應 預期 主題相似批次的 collapse 風險、不是樂觀假設
9. 第二輪 migration playbook 全主動 variant 在 N=5 同主題下 collapse 0/5：學第一輪教訓、第二輪 5 篇寫前 主動列 5 種 entry framing variant（meta-reflection / paradox / decision matrix / code-led / reverse definition）、跨檔 cadence audit 結果 0/5 collapse；同主題（migration playbook）+ 同 N=5、唯一變數是 variant 規劃完整度；證實 variant 規劃是 cadence 結果的唯一因果變數、不是「主題不同自然錯開」

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：模板不只是內容欄位的模板、cadence / 句型骨架 / 收尾語也是。批量寫作前準備 framing 變體、寫作中跨檔抽樣對照、不要等 batch 完成後 reviewer 才發現連讀預期化。

多個 constraint 同時 enforce、批量寫作就會把 cadence 收斂到「最便利合規解」。這不是違規、是 合規最佳解的副作用。

機制：

1. N 個硬 constraint 同時 enforce（章節結構 / 表格深化 / 行數範圍 / lint 規則 / frontmatter 完整）
2. 寫第一篇時 Claude 找到一個 framing 同時滿足所有 N 個 constraint
3. 寫第二篇起、複製這個 framing 是 合規 + 省 token + 風險最低 的選擇
4. 51 篇後、cadence 已經 collapse 到一個 framing、雖然每篇都合規

backend/07 案例：「11 章節 + 表格延伸段 + 130-160 行 + 零 emoji + 案例回寫」5 個 constraint 同時 enforce 下、「四件事 → 任一缺失就是 X 邊界的待補項目」是合規最便利 framing。51/51 都用了。

Constraint 越多、cadence 收斂越快

關鍵直覺：constraint 是 過濾器、constraint 越多、能通過所有過濾器的 framing 種類就越少；批量寫作下、Claude 會選 第一個發現的可行 framing 並複製。

這跟 over-constraint 設計問題同骨：要求越具體、解空間越小、批量後解就會集中到少數幾個。

為什麼這個 attractor 規範擋不住

對應「為什麼 cadence 維度 #122 失守」、本卡是 機制側 解釋：

• 每篇單看都合規：constraint 設計成「單檔通過 / 不通過」、沒有「跨檔 framing 變異性」這個 constraint、所以 single-file lint 永遠 pass
• 複製是 Claude 的 cost optimum：批量第 N 篇複製第 1 篇骨架 = 最少新 token、最少 risk、最快輸出；除非有反向壓力、預設行為就是複製
• 規範本身鼓勵「找一個都過的 framing」：要求章節齊全 + 表格深化、Claude 自然會收斂到「對所有 vendor 都適用」的 framing；越通用的 framing、cadence 越單一

「對所有 vendor 都適用」跟「對每個 vendor 都到位」是兩件事 — 通用 framing 不會錯、但會 只到位最小公分母。批量寫作下、最小公分母 framing 大量複製就是 cadence 同質化。

對策：拉開 constraint 或加 anti-template constraint

兩條互補路徑：

實務 default：Pilot phase 強制 + 加 anti-template constraint。先在 pilot 階段準備變體、再用規範要求跨檔抽樣、雙層防護。

Dogfood 驗證見 #122 cadence 同質化 — 4 篇 deep article batch 用 pilot phase 4 種 variant 取代「事後 polish」、cadence collapse 從前批 100% 降到 0%、修正成本省 ~10 倍。本卡的「拉開 constraint」對策獲實證。

不是只發生在「寫作」

同骨機制在其他批量產出任務上也成立：

• Code generation：用同一 LLM 一次生 N 個 service 的 boilerplate、結構會收斂到同一 framing（同樣的 error handling pattern、同樣的 log 格式）
• Test case 批量寫：N 個 unit test 都用同一個 setup-act-assert framing、覆蓋面看似齊但其實只測一種 axis
• API doc 批量寫：N 個 endpoint doc 都用同一段「方法 / 參數 / 回傳」三段式、抓不到 endpoint-specific 邊界

這些都是 constraint 設計的 collapse — 只是發生在不同 surface。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：多重硬規範同時生效時、cadence 收斂到合規最便利解是預設行為、不是違規。對策不是加更多 constraint、是拉開 constraint 或強制 pilot phase 準備變體；規範設計時要評估 attractor 副作用、不是只看「單檔有沒有過」。

違規類型決定 enforcement 時機 + 機制。把所有違規都丟給 batch 完成後的 reviewer 是錯的；同樣錯的是 只靠生成中抽樣、沒有 stage 0 的主動變體規劃。Emergence 違規需要 兩層防護：

• Stage 0 主動設計層：寫批量前列 N 種 framing variant、分配給對應主題；這層決定 cadence 是否錯開的根因
• Stage 內被動監測層：生成中抽樣 audit、發現 collapse 立即修方向；這層 偵測 而不是 設計

兩層缺一不可：跳過 stage 0、被動抽樣不會自動發現 主題語意 attractor（相似主題天然引出的 framing collapse、見 #122 cadence 同質化 Update 段定義；migration playbook 3/5 collapse 即此實證、見本卡「Update: 被動寫作下…」段）；跳過 stage 內抽樣、stage 0 設計可能在中途 drift 沒被 catch。

backend/07 案例對照：51 個 vendor 字面違規 0、結構違規 0、emergence 違規（cadence 同質化）51/51；後者三個 reviewer 中只有一個 footnote 提到、是因為 reviewer 一次審 51 檔、emergence 訊號夠強才看出 — 如果只審 5 檔、emergence 訊號還不夠強、會被漏掉。

為什麼 emergence-class 違規規則化不了

字面違規可以寫成 regex（rg "✅|❌"）、結構違規可以寫成 grammar 規則（章節必須有 N 個 H2）。Emergence 違規的特徵：

1. 跨檔才能偵測：單檔 cadence 沒問題、N 檔 cadence 對齊才是違規
2. 規則化會 over-fit：寫「段末不可用『四件事任一缺失』」會把這句正常用法也擋掉；寫「段首句句型分佈要 ≥ 3 種」需要先語法剖析、複雜度爆炸
3. 訊號隨樣本數變化：5 檔比對訊號弱、50 檔比對訊號強；linter 沒有「批次」概念、只看單檔
4. 跟風格邊界模糊：cadence 一致 vs cadence 同質、之間是漸層、threshold 因領域而異

結論：emergence 違規不能靠 hook / linter / 字面規則攔、只能靠 流程設計 在生成中 trigger 抽樣 review。

Stage 內抽樣的設計

對 case-first-module-workflow 補強：stage 2（內容生成）內部加入 cadence checkpoint、不要等 stage 3 reviewer 才發現。

關鍵：抽樣不是「Reviewer 在 batch 完成後跑」、是「寫作者在生成中跑」。寫第 5 篇之前先回頭看前 5 篇、發現問題就在第 5 篇修方向、不是寫完 50 篇才回頭改 50 個。

Dogfood evidence (2026-05-18、N=4 sub-threshold 驗證)

本卡浮現後立即跑 4 篇 deep article 小批量 dogfood、用 寫作中抽樣 + pilot phase variant 取代 batch 後 reviewer：

對照前批 backend/07 51 vendor（無寫作中 checkpoint）：

兩個驗證：

1. Stage 內抽樣在 sub-threshold N=4 仍有效：原本 checkpoint 表格寫第 5 / 10 篇抽樣、預設批量 ≥ 5；實測 寫每篇前都做一次 entry framing variant check 在 N=4 也能完全錯開 cadence
2. 生成中抽樣的邊際成本 « batch 後 polish 成本：每篇前 ~1-2 分鐘 cadence check vs batch 後修 51 處 ~30-60 分鐘 — 比例 ~10-15 倍。本卡論斷「修正成本 N 倍」獲實證

Update: N=5 full-threshold checkpoint 排程驗證

第一次 N=4 後立即跑 N=5 full-threshold batch（5 篇 PostgreSQL sub-tool）、驗證 checkpoint 排程在 ≥ 5 真實閾值的表現：

兩批對照：

額外驗證：

3. 進度 10-20% 抽樣訊號偏弱、80% 抽樣最強：N=5 batch 確認 進度 80% audit 是 emergence 訊號最強位置；原 principle 寫「進度 10-20% 抽樣」是過早、實際 寫前 variant 規劃 + 進度 60-80% audit 組合更穩
4. 同 vendor 同 type 是 collapse 最高風險、checkpoint 仍 cover：N=5 batch 共同 context 比 N=4 多（同 vendor / 同 audience / 同 article type）、本卡論斷 emergence 風險 = 共同 context × N 成立；checkpoint 設計能 cover 是因為 variant 規劃在 stage 0、不靠 sample size 補

Update: 被動寫作下 stage-internal checkpoint 仍失效

第三輪 5 篇 migration playbook 中 前 3 篇被動寫作（沒主動規劃 variant）— stage-internal checkpoint 雖然按時 fired、但因為 沒 variant 預先準備、checkpoint 看到的「不同主題」誤以為 framing 會自然錯開、實際 collapse 到「為什麼遷：X/Y/Z driver」格式：

兩個關鍵 finding：

5. Checkpoint 不夠、變體規劃才是 root：stage-internal checkpoint 確實 fire、但 沒準備 variant 時 checkpoint 變被動驗證、不是主動防護；本卡原論斷「checkpoint 取代 batch 後 reviewer」需修正為「checkpoint + 預先 variant 規劃 兩層」
6. 主題語意 attractor 是新失效源：N=5 batch 中前 3 篇都圍繞「為什麼換 vendor」、entry 自然 collapse 到 driver list；這個 attractor 比結構 constraint 更強、未來寫作要 預先列 framing 變體 而不是 依賴 checkpoint 提醒換

修正後的 Stage 內 checkpoint 排程（補 stage 0 變體規劃）：

關鍵：Stage 0 變體規劃是必要 step、不能跳；checkpoint 是 監測 工具、不是 設計 工具。

詳細 SOP 跟 5 種 type 的具體應用見 Migration playbook methodology — 該 methodology 從 5 篇 migration playbook batch 抽出 stage 0 variant 規劃流程、本卡的「checkpoint 不夠」訊號是該流程的觸發實證。

Update（2026-05-19）：第二輪 migration batch 全主動 variant 驗證

第二輪 migration batch（5 篇）寫前主動列 5 種 entry framing variant、cadence audit 結果 0/5 collapse；跟第一輪 3/5 collapse 對照、唯一差異是 variant 規劃完整度：

第二輪確認本卡核心論斷：

5. Checkpoint + Stage 0 兩層在全主動下成功：第二輪 5 篇 stage 0 全列 variant、checkpoint 監測無 collapse alarm、最終 audit 0/5；證實兩層防護在 都執行 下達成 principle 目標
6. Stage 0 規劃的標準動作：第二輪 stage 0 動作為「列 5 種 distinct entry framing 候選、對應 5 篇主題分配」— 不是「想到才換」、是 寫第一篇前就完成 的設計步驟
7. 主題相似性不會自動解決 cadence：第二輪 5 篇都是 migration playbook、主題相似性跟第一輪一樣高；唯一差異是 stage 0 是否做、結果差 60% collapse vs 0% — 確認本卡論斷「checkpoint 不夠變體規劃才是 root」在 主題相似性高 場景下仍成立

Batch 完成後 reviewer 為什麼太晚

三個成本問題：

1. 修正成本 N 倍：51 篇都同質化、修正要動 51 篇；如果第 5 篇就 catch、只動 5 篇
2. Cadence 已內化成「正確答案」：寫完 50 篇後 Claude 已經把 dominant framing 視為「合規最佳解」、要打破比第 5 篇難
3. Reviewer 訊號要求高樣本：5 檔不夠 emergence、50 檔才強訊號；但 50 檔出來時修正成本已經爆

最佳時機：Sample size 剛夠看出 emergence、且修正成本還可控 — 通常是 batch 內 10-20% 進度的位置（51 批量 → 第 5-10 篇）。

跟字面 / 結構違規的時機對照

字面違規（emoji）的 enforcement 鏈：

• 寫作中：Claude 預設不寫 emoji（pre-trained behavior + system prompt）
• Pre-commit：mdtools / regex hook 攔
• CI：full lint sweep

三層防護、字面違規幾乎不可能漏網。

結構違規（章節缺失）的 enforcement 鏈：

• 寫作中：模板 / skeleton 提示
• Pre-commit：lint 章節結構
• Review：人類 / agent 看章節列表

兩層機制、結構違規會被攔。

Emergence 違規目前的 enforcement：

• 寫作中：無（cadence 沒提示）
• Pre-commit：無（regex 攔不到）
• Review：Stage 3 reviewer 可能漏（單 reviewer 視野有限）

只有 stage 3 reviewer 這一層、且不可靠。本卡的修法是在「寫作中」這層加 stage 內抽樣。

不只是寫作：emergence 違規的其他例子

三類違規對應三層 enforcement、不能混用工具。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：違規分字面 / 結構 / emergence 三類、enforcement 時機要對應類型。Emergence 違規規則化不了、不能丟給 hook 或 batch 後 reviewer、要在生成中（batch 進度 10-20% 時）抽樣 catch；最佳時機是 emergence 訊號剛夠強、且修正成本還可控的位置。

寫作 review 完整性的本質是 多軸交集、不是 單軸深度。七個軸已經從前面卡片浮現、缺任一軸就會 systematic miss 對應類型的問題：

七軸正交：每個軸獨立解一類盲點、不重疊；缺任一軸都會 systematic miss 對應類型問題。

為什麼是多軸、不是單軸越做越深

單軸越做越深的失敗模式：

1. Frame 軸跑 10 輪、不換 instance 軸：同一 reviewer 跑 10 輪、catch 的問題仍高度相關（#114 已點出）
2. Instance 軸開 10 個 reviewer、不換 frame 軸：10 個 reviewer 都跑「規則 check」這個 frame、catch 的盲點相同
3. Frame + Instance 都做、不管 Surface 軸：Body review 通過、但 title / description 沒被審、搜尋入口失效
4. Surface 都做、不管 Cadence 軸：51 篇個別合規、連讀預期化
5. Cadence 軸有抽樣、Timing 軸放在 batch 後：抽樣等於 batch 後 review、修正成本 N 倍

七軸缺任一條、就有對應類型違規逃過 review。

多軸是預設、單軸是 collapse

跟 #125 Collapse 是隱形預設 同骨 — 把 review 設計 collapse 到單軸是預設行為（最便利）、但 collapse 掉的軸對應的違規會 systematic miss。

預設展開七軸、選窄做要證明 — 跟 #78 / #79 / #80 / #125 同條結構。

Review 設計時的 enumerate 紀律

設計新的 review 流程（人類 / agent / 自動化）時、不該只看「捕獲哪些違規」、要列七軸覆蓋狀況：

七題都回答後、再判斷該不該補軸。如果某軸沒覆蓋、不一定要補（cost vs risk）、但要 知道沒覆蓋對應什麼盲點。

Cadence + Timing 軸 dogfood (2026-05-18)

4 篇 deep article batch 驗證 cadence + timing 兩軸的設計、不靠 reviewer 補、是靠 stage 2 寫作流程內抽樣：

• Cadence 軸：4 篇 pilot phase 主動規劃 4 種 framing variant、跨檔 cadence audit 顯示「任一缺失」collapse 族 0/4、entry framing 種類 4 種
• Timing 軸：每篇寫作前做 cadence check（生成中 checkpoint）、不等 batch 完成後 reviewer；修正成本 ~5 分鐘 / 篇 vs 前批 batch 後 polish ~30-60 分鐘

N=5 full-threshold 補強驗證（同日第二批）：再跑 5 篇 PostgreSQL sub-tool deep article、用 5 種 variant 覆蓋 同 vendor 同 audience 的 cadence collapse 最高風險場景；結果 5/5 framing 全錯開、過渡詞密度 0、cadence collapse 0/5。確認 Cadence 軸 + Timing 軸 不靠 sample size、靠 stage 0 variant 規劃。

詳細數據見 #122 cadence dogfood evidence 跟 #124 dogfood — 兩軸都不必加 reviewer instance、是 Stage 2 寫作流程設計即可解。

七軸不是隨機湊出來、有結構

七軸可以再 group 成三個 上位 axis：

四上位 axis 各自獨立、合起來覆蓋 review 設計的所有 surface。當 review 出問題、依四上位 axis 找根因比依七子軸快。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：寫作 review 完整性是七軸交集、不是單軸深度；缺軸不缺深度。設計 review 流程時 enumerate 七軸覆蓋狀況、預設展開、選窄要證明；當 review 報告漏抓 systematic 違規、查的不是「再加一輪」、是「哪一軸沒覆蓋」。

WRAP 框架的 Widen Options 段落是「探索本質不同的因果解釋」、不是「列出競爭性派系然後打掉錯的」。當寫作時把「Widen Options → Reality Test」當作全文 narrative 主軸、整個 hypothesis space 探索就會塌成「兩弱一強稻草人」結構—A、B 是 dummy、C 永遠預設正解、Reality Test 用來證明 C。讀者第一遍可能不發現、第二遍就會看穿是修辭、不是真實的選項擴增。

判別問題：「刪掉 Reality Test 那段、單看 Widen Options 那段、讀者能不能猜出哪個是正解？」能猜出 = 稻草人結構、不能猜出 = 真正的 widen。

情境

寫商業 case-analyses 套 WRAP 框架時、最容易踩的陷阱是把 Widen Options 寫成派系命名 + 預設正解、然後 Reality Test 一條一條打掉。寫作者的心理路徑很自然：先有觀點 → 為了「公平」列出反方 → 為了「驗證」打掉反方 → 留下原本就要說的觀點。這個流程跑完、Widen Options 段落變成修辭裝飾、不是真正的 hypothesis space 探索。

具體 case（2026-05-20、e00253c 修法前）：blog 寫 3 篇 case-analyses（Claude for Legal / FDE 軍備競賽 / CoreWeave 收購 Bufstream）、3 篇全部踩同一個結構：

• claude-for-legal：A「AWS 類比派」/ B「保護傘派」/ C「Enterprise Lock-in 派」、C 預設正解
• fde-arms-race：A「模仿派」/ B「策略選擇派」/ C「結構性被迫派」、C 預設正解
• bufstream：對 CoreWeave 為什麼買、X「業務擴張」/ Y「技術自主」、Y 預設正解

3-reviewer audit 平行跑、3 個 reviewer 獨立都點出「兩弱一強稻草人」結構共通—診斷一致是這個 pattern 不是個別失誤、是 WRAP 套案例寫作的系統性陷阱。e00253c 重寫後改為「解釋 (1) / (2) / (3) / (4) 並陳因果鏈、每個有 prior + prediction」、Reality Test 改為 evidence weight assessment + Falsifier、Round 2 驗證通過。

理想做法

第一步：Widen Options 改成「並陳的合理因果鏈」、不是派系命名

每個選項要滿足四個判準：

1. 有實際 prior：誰持這論、為何合理。Prior 可以引用 VC / 創辦人 / 學者 / 業界分析師的公開立場、或從產業結構推導出的合理初始假設。
2. 有 testable prediction：若這個解釋成立、會看到什麼具體 evidence（合約規模、客戶分布、銷售節奏、員工流向）。
3. 跟其他選項的因果鏈本質不同：不是同一個結論的不同包裝、是不同的因果起點。
4. 不是設定就要被打爆的 dummy：選項要站得住、要可被讀者挑戰、不是 reductio ad absurdum 的設定。

選項命名用中性編號「解釋 (1) / (2) / (3)」、避免「X 派 / Y 派 / Z 派」派系暗示—派系命名自帶「選邊」修辭框架。

第二步：Reality Test 改成 evidence-based weight assessment

不是「A 不成立、B 不成立、C 成立」三連否定、而是給每個解釋配 evidence 強度 + 估佔比百分比：

1解釋 (1)：強訊號（觀察 X、Y、Z 都支持）— 估佔比 ~50%
2解釋 (2)：中等訊號（觀察 W 支持、觀察 V 部分反駁）— 估佔比 ~30%
3解釋 (3)：弱訊號（難排除巧合）— 估佔比 ~20%

允許多選項並存、用「主因 / 次因 / 邊際」權重判讀、不是 winner-takes-all。最後綜合判讀用「主要承擔 A 功能、伴隨 B 跟 C 兩個次要動機」這類多解釋並存的措辭。

第三步：補 Falsifier 段、列出每個解釋的反證訊號

每個解釋配對應的 Falsifier：「若觀察到 X、解釋 (N) 主導論垮、要重評估」。這跟 Tripwire 段銜接、形成可監控的判讀結構。Falsifier 不是「整套論述崩」、是 partial revision—某個解釋的權重變化、不一定推翻整個分析框架。

第四步：完稿時跑「刪 Reality Test 測試」

寫完後、心裡 simulate「刪掉 Reality Test 那段、讀者單看 Widen Options 那段能不能猜出哪個是正解」。能猜出就是稻草人結構、需要重寫 Widen Options 讓選項真的並陳。

沒這樣做的麻煩

修辭被讀穿、信任度下降

讀者一旦看穿稻草人結構、會懷疑作者的真誠度跟結論可靠度。教學文章靠「分析嚴謹」立信、稻草人結構直接破壞這個基礎。本 blog 的 3-reviewer audit 之所以能 3 個 reviewer 獨立都 catch 到同一個 pattern、就是因為這個結構在 careful reader 眼中明顯—第一篇可能蒙混、第三篇就會被當成 systematic 修辭技倆。

Hypothesis space 探索失效、判讀框架不可遷移

WRAP 的核心價值是「強制做 hypothesis space 探索、防止認知偏誤」、稻草人結構讓 Widen Options 退化成修辭裝飾、原本要解的「直覺接受第一個解釋」問題沒被解。讀者拿走的判讀框架也不可遷移到下次事件—因為框架的應用方式本身就是錯的、套到新事件還是會列稻草人。

Tone 滑成 opinion piece

「我列出爛選項打掉、留下正解」的結構帶有「我來糾正你」的姿態、整篇 register 從教學滑向 opinion piece。即使每個字句都中性、整體 tone 仍會偏。本 blog case-analyses 重寫前的 register 評估是 opinion 40% / blog 30% / teaching 20% / academic 10%、重寫後翻轉到 teaching 55-60% / academic 25-35% / blog ≤ 15%—單純改 framing 結構就能整體位移 register。

跟其他抽象層原則的關係

• #125 Collapse 是隱形預設：本卡是 #125 在「WRAP Widen Options」surface 的具體實例。Widen Options 塌成「兩弱一強」是把高維 hypothesis space collapse 到便利的「正解 vs 稻草人」二維。修法是預設展開多選項、選窄要 evidence 支持、不是修辭便利。

• #79 決策對話的五維度：sister 卡。#79 是 decision-making 多軸、本卡是 WRAP 寫作多軸；兩者結構同骨—Widen Options 不能塌成 2 維、就像 decision dialogue 不能塌成單軸。

• #126 寫作 review 是多軸完整性：本卡是 review 設計時要看「frame 軸」的具體 instance。寫 case-analyses 時 review 不能只看「結構是否符合 WRAP」、要看「Widen Options 是否真的並陳 hypothesis、還是塌成稻草人」。Frame 軸的覆蓋要包含 framing 結構檢查、不只是規則 check。

• #82 字面攔截 vs 行為精煉：本卡是 #82 在「framing 層級」的具體案例。lint 規則層（字面）catch 得到「不是」「不要」等否定詞密度、但 catch 不到「整段 framing 結構是稻草人」這個行為層問題。Framing 違規屬於 #82 的「行為精煉」維度、需要 reviewer agent 跑 multi-pass 才能捕獲。

• #83 Writing multi-pass review：本卡是 review 第 4-5 輪該掃的「framing 維度」。前幾輪掃結構 / 術語 / 規範、framing 屬於 review 後段才能看穿的層次（因為要對全文 narrative 結構評估、不是單句檢查）。

判讀徵兆

適用範圍與邊界

• 適用範圍：
  • 用 WRAP 框架寫商業 case-analyses、市場事件拆解、產業策略分析
  • 用其他類似「列選項 / 對比 / 收斂」框架寫案例（5W1H、5-Forces、JTBD 階段）
  • 寫「對抗主流敘事 + 提出新解釋」類型的分析文章—這類最容易踩
• 不適用：
  • 純技術教學（無 hypothesis space 探索、Widen Options 段落本身不存在）
  • 既有 case 的事後紀錄（Outcome 已定、不需要 widen）
  • 觀察筆記（明確標為個人觀察、不假裝是結構化分析）
• 邊界：「對抗稻草人」跟「列負面反例做對照」不同。AGENTS.md 原則二允許「反例段落、目的為對照」、本卡禁的是「把對抗稻草人當 narrative 主軸」。少量負面反例可保留、整段不可由稻草人結構主導。判別線：反例是否單獨成段並主導 narrative 結構—成段主導就違規、附句對照就可接受。

WRAP 框架（含 Anchor Check / Step 0 / Widen Options / Reality Test / Attain Distance / Prepare to be Wrong / Tripwire）是寫作者背後做 hypothesis space 探索與認知偏誤防護的內部工具。當把這些 process 標籤暴露成文章章節結構、讀者體驗會被三個壞 effect 破壞：

修法是把 WRAP 工作內嵌進教學 narrative、章節順序服從「讀者最快理解事件結構」的教學流程、不是「WRAP 七步驟」的 process 順序。

情境

寫 3 篇商業 case-analyses（Claude for Legal / FDE 軍備競賽 / CoreWeave 收購 Bufstream）第一版時、把 WRAP 七步驟全部當章節標題暴露給讀者：

 1[開頭]
 2## 事件本身
 3## Anchor Check：要回答什麼
 4## Step 0：資料充足度
 5## Widen Options：N 個解釋路徑
 6## Reality Test：用實證驗證
 7## [結構性機制章節]
 8## Attain Distance：長期影響
 9## Prepare to be Wrong：預先設計失敗回退
10## Tripwire：何時重新評估
11## 結論：可遷移框架

3-reviewer audit + Round 2 重寫後、讀者再次 feedback 指出三個具體問題：

第一、claude-for-legal 開頭寫「『律師會被取代』是這套機制的末端表象、本篇從上游動作開始拆」—但「事件本身」段在開頭之後、讀者還不知道有「律師會被取代」這個敘事存在、開頭預設了讀者跟作者共享的 context。

第二、Anchor Check 段寫「錨點問題聚焦在結構、而非個別公司執行力」—這是「為什麼不討論某個非問題」的 disclaim、屬於分析報告 frame、不是教學 frame。讀者根本沒問「會討論個別公司執行力嗎」、預先 disclaim 反而增加閱讀成本。

第三、「這個動作對應用層 SaaS、新創、知識工作者三層分別造成什麼影響」這個論點在開頭、事件本身、Anchor Check 三段各出現一次—讀者讀到 Anchor Check 還沒接觸實質內容、只是被預告了三次同一件事。

更深層的問題是：把 WRAP 從「寫作者的內部工具」當成「文章的章節結構」。WRAP 是寫作者背後 review 自己有沒有做完 hypothesis 探索的 checklist、不是讀者要走的步驟序列。

理想做法

第一步：WRAP 工作在腦中或草稿跑完、不暴露到讀者

WRAP 七步驟是寫作者完稿前要做完的 internal review：

• 我有沒有做 Anchor Check（搞清楚要回答什麼）？
• 我手上的 evidence 夠不夠下結論（Step 0 資料充足度）？
• 我有沒有列出所有合理因果解釋（Widen Options）？
• 每個解釋我都用 evidence 驗證了（Reality Test）？
• 我有看 5-10 年長期影響嗎（Attain Distance）？
• 我列了關鍵假設跟反證訊號嗎（Prepare to be Wrong）？
• 我設了何時重新評估的 Tripwire 嗎？

這七題自己回答完、不寫進文章。文章是教學 deliverable、不是 review process 的 paper trail。

第二步：章節結構服從教學流程、不是 WRAP 步驟順序

教學流程的合理順序：

 1[開頭 1 段]                 直接描述事件 + 一句帶到本篇拆解什麼
 2                            無預設讀者認知、不對抗他人敘事
 3
 4## 事件本身                  把事件講清楚、包括同期動作、為什麼值得拆
 5                            讀完讀者知道「發生了什麼」
 6
 7## 為什麼 X（教學段）         把 Widen Options + Reality Test 內嵌進教學 narrative
 8                            含並陳因果解釋（每個有 prior + prediction）+ evidence 配重
 9
10## 結構性機制章節             把分析結果展開成讀者可吸收的結構知識
11                            按層 / 維度 / 時間軸組織、不按 WRAP 步驟
12
13## 長期影響與機會成本          Attain Distance 內容、移除 process 標籤
14
15## 預警訊號                   Prepare to be Wrong + Tripwire 合併
16                            教學語氣：「假設一 / 假設二 / 假設三 + 監控訊號」
17
18## 可遷移的判讀框架           結論段、給讀者帶走的工具

第三步：開頭不對抗他人敘事、不預設讀者認知

開頭只做兩件事：

• 描述事件（讀者進入 context）
• 一句話帶到本篇要拆什麼（讀者知道接下來會讀到什麼）

不做這些事：

• 「市場敘事是 X、但 X 不重要、Y 才是」（contrarian framing、見 #140）
• 「X 是這套機制的末端表象、本篇從上游動作開始拆」（預設讀者已有 X 的認知）
• 「我們不討論個別公司執行力」（分析報告 frame、不是教學 frame）

對其他敘事的回應、放到「事件本身」段、有 context 後才提：「公開討論集中在 X—這是這個動作的下游表象、本篇焦點在觸發它的上游機制」。讀者讀完「事件本身」段、才有 context 理解 X 是什麼、預設讀者認知的問題自然消失。

第四步：完稿時跑「process metadata 掃描」

寫完後、grep 文章章節標題、檢查有沒有殘留：

1grep -E "^## (Anchor Check|Step 0|Widen Options|Reality Test|Attain Distance|Prepare to be Wrong|Tripwire)" *.md

任何命中、都是 WRAP process metadata 暴露給讀者。改成教學標題：

沒這樣做的麻煩

讀者預期被預設、認知門檻不對齊

開頭「X 是末端表象、本篇拆上游」要求讀者已經知道 X 是什麼。如果 X 在後文才介紹、讀者在開頭就被 confused、之後讀「事件本身」段才搞懂、回去重讀開頭—閱讀成本翻倍。

Register 從教學滑成分析報告

「Anchor Check」「Step 0 資料充足度」「Reality Test」這類詞屬於 analyst 內部對 own work 的 review 對話、不是給讀者看的章節標題。把這些暴露給讀者、整篇 register 從「教學知識庫」滑成「給同行看的分析報告」、讀者輪廓變成「已經懂 WRAP 框架的分析師」而非「想學商業分析的工程師」。

同論點重複預告、推進緩慢

WRAP 七步驟本來就有「先講要回答什麼、再講資料、再講選項、再驗證」的內在重複—每一步都會提到核心論點一次。如果七個步驟全部變章節、核心論點會在前三段被預告三次（開頭、Anchor Check、Step 0 都會講「本篇要拆什麼」）、讀者讀到 Reality Test 才接觸實質內容。

WRAP 框架的價值被當成修辭裝飾

WRAP 的真正價值是讓寫作者做 hypothesis 探索、防認知偏誤。當 WRAP 變章節結構、讀者跟寫作者都會把它當成「應該照走的 process」、原本的 hypothesis 探索變成「填表」、防認知偏誤的功能失效。

跟其他抽象層原則的關係

• #140 WRAP Widen Options 容易塌成稻草人 framing：本卡是 #140 的上位原則。#140 處理 Widen Options 段落的內容違規（兩弱一強稻草人）、本卡處理 WRAP 整套被當章節結構暴露的 surface 違規。兩卡互補—改 Widen Options 內容不夠、還要改 surface presentation。

• #125 Collapse 是隱形預設：本卡是 #125 在「寫作 process 透明度」surface 的具體 instance。Process metadata 暴露給讀者是「省去設計教學流程的便利選擇」的後果—不思考章節順序、直接把 WRAP 步驟當章節是最便利、但 collapse 掉了「為讀者設計閱讀順序」這個維度。

• #82 字面攔截 vs 行為精煉：本卡是 #82 在「process metadata 暴露」維度的具體案例。lint 規則層 catch 不到「章節標題是 Anchor Check 還是『為什麼 X』」、要靠 reviewer / 讀者 feedback 才能發現—屬於 #82 的「行為精煉」維度。

• #97 Metadata surface 要納入寫作 review 範圍：本卡擴 #97 的 metadata surface 概念。#97 處理 title / description / heading 是讀者入口的 metadata；本卡指出 章節結構本身 也是 metadata surface—章節標題傳達「文章是什麼類型」、process 標題傳達「這是分析報告」、教學標題傳達「這是教學文章」。

• #126 寫作 review 是多軸完整性：本卡是 review 設計時要看的「surface 軸」的具體 instance。Review 不能只看「內容是否正確」、要看「章節結構傳達的 register 是否跟目標讀者對齊」。

判讀徵兆

適用範圍與邊界

• 適用範圍：
  • 用 WRAP 框架寫商業 case-analyses、市場事件拆解、產業策略分析
  • 用其他「先列 process、再走 process」框架寫教學文章（5W1H、5-Forces 分步、JTBD 階段、case method 步驟）
  • 任何「寫作者內部 review tool」跟「讀者教學 narrative」混淆的情境
• 不適用：
  • 給同行看的分析報告（analyst-to-analyst、process metadata 是正當的）
  • 學術論文（IMRaD 結構有正當性、process 標題是學術慣例）
  • 純技術 reference 文件（process metadata 反而幫助快速定位）
• 邊界：本卡禁的是「把 WRAP 整套步驟當文章章節結構」、不是禁所有 process 詞彙。在合適的位置提一句「以下用 WRAP 框架背後的 hypothesis 探索方法拆」是 OK 的、整篇用 WRAP 步驟當章節就違規。判別線：章節標題是描述「讀者會學到什麼」（教學）還是「作者在做什麼分析步驟」（process）。

文章標題對讀者做了承諾、文章主體必須對齊這個承諾。WRAP 內部分析（Widen Options + Reality Test 含 prior 引用 + evidence weight）即使方法論做得好、若不是標題承諾的內容、就不該佔文章主體。

這跟 #141 WRAP 是寫作者的內部工具、不是文章章節結構 是兩個不同層級的議題：

兩卡互補—改了章節標題還不夠、章節內容也要對齊標題承諾。

情境

3 篇 case-analyses 經過 #141 的 Round 3 重寫、章節標題已從 WRAP process metadata 改成教學風格（「為什麼供應商選擇 enterprise 包裝」取代「Widen Options」）。但讀者再次 feedback 指出更深的問題：

第一、Claude for Legal 之後 的標題承諾「應用層、新創、知識工作者的三層擠壓」、但「供應商為什麼選擇 enterprise 包裝」段佔了文章 30%+ 篇幅—讀者拿到的內容跟標題承諾不匹配。

第二、那一段內容引用「a16z、Sequoia 公開報告跟 Anthropic 投資人 deck 都強調 enterprise ARR」這類 source—但這些引用沒具體出處（哪份報告、哪一頁、哪一段）、有 hallucination 風險。為了支撐 WRAP Widen Options 的 prior 而引入沒實際出處的 source、是 fidelity 漏洞。

第三、解釋順序錯位—寫成「a16z / Sequoia 等公開報告強調 ARR、背後邏輯是 X」、把 source 放前面、解釋放後面、違反 AGENTS.md 原則一「核心原則先行」。

更深層問題：即使章節標題改成教學風格、WRAP 內部分析（含 prior 引用）的內容仍然喧賓奪主、偏離標題承諾。3 篇都踩同樣的 pattern：

• claude-for-legal 標題「三層擠壓」、原版「供應商為什麼選擇 enterprise 包裝」段佔大量篇幅、含 hallucinated source
• fde-arms-race 標題「SaaS 三支柱鬆動」、原版「三家為什麼同步押 FDE」段佔了三支柱主體的空間
• bufstream 標題「整併週期 + 基礎設施重組」、原版「Buf 為什麼賣」「CoreWeave 為什麼買」兩段 WRAP 分析佔主體

Round 4 重寫後、3 篇都移除「為什麼 X」獨立段、把核心動機塞進「事件本身」一兩句 + cross-link 到處理該動機的對應文章、文章主體留給標題承諾的內容。

理想做法

第一步：寫稿前明確列出標題承諾什麼

標題是讀者跟文章之間的合約。寫稿前用一句話寫下「這篇標題承諾讀者拿到什麼」：

• 「Claude for Legal 之後：應用層、新創、知識工作者的三層擠壓」→ 承諾三層擠壓的拆解
• 「FDE 軍備競賽：SaaS 三支柱鬆動下的結構性轉變」→ 承諾三支柱怎麼鬆動的機制
• 「CoreWeave 收購 Bufstream：整併週期下的賽道判讀與基礎設施重組」→ 承諾整併週期判讀 + 基礎設施重組分析

承諾寫下後、後續每個章節都對齊問：「這段是不是在履行承諾？」

第二步：跑完 WRAP 內部分析、區分「主結論」跟「分析過程」

WRAP 七步驟在寫作者腦中跑完—Anchor Check / Step 0 / Widen Options / Reality Test / Attain Distance / Prepare to be Wrong / Tripwire 都要做。但跑完後、分兩類東西：

• 主結論：可以放文章主體、是讀者要拿走的判讀
• 分析過程：（Widen Options 的多個解釋、Reality Test 的逐一驗證、Prior 的 source 引用）留在腦中或寫作筆記、不放進文章

判別線是「這段內容是不是標題承諾的一部分」。承諾「三層擠壓」、文章主體就是三層擠壓；供應商動機是 prelude / context、塞進「事件本身」一兩句帶過、不獨立成段做完整 WRAP 分析。

第三步：完稿時跑「標題對齊測試」

寫完後、列出文章各段佔多少篇幅、跟標題承諾比對：

1列出每段標題 + 段落篇幅 + 是否對齊標題承諾

例：

1- 事件本身 (10%) — 提供 context、合理
2- 供應商為什麼選擇 enterprise 包裝 (30%) — 不在標題承諾、過度
3- 第一層擠壓 (15%) — 對齊承諾
4- 第二層擠壓 (15%) — 對齊承諾
5- 第三層擠壓 (15%) — 對齊承諾
6- 長期影響 (10%) — 對齊承諾
7- 預警訊號 + 框架 (5%) — 對齊承諾

「不在標題承諾」的段落佔 > 20% 就要重寫—把該段縮成一兩句塞進「事件本身」、cross-link 到處理該議題的對應文章、不獨立展開。

第四步：Source citation 必須真實可驗證

引用 source 時遵守三條規則：

1. 能 verify 才寫：引用「a16z 報告」「Sequoia 分析」前、確認你看過該報告、能給具體標題或連結。不能就改成 hedged claim（「業界普遍觀察」「分析師多次點過」）。
2. 解釋在前、source 在後：「API 利潤太薄需要長合約對沖（這個論點 a16z 多次公開分析）」、不是「a16z 公開分析 API 利潤太薄、所以需要長合約對沖」。核心原則先行—讀者先吸收解釋、再判斷 source 可信度。
3. 不確定就刪掉 source 引用：寫到「a16z、Sequoia、Andreessen」這種列舉時要問「我真的能列出三家都講過這個論點嗎？」答案是「不確定」就改成「業界普遍觀察」、不列 specific 名字。

第五步：WRAP 內部分析的次要結論的處理

WRAP 內部分析跑完後、會產出「主結論 + 次要結論」。主結論放標題承諾的主體、次要結論的處理：

沒這樣做的麻煩

讀者拿到的內容跟標題承諾不匹配

標題承諾「三層擠壓」、文章主體 30% 在講「供應商為什麼選擇 enterprise 包裝」、讀者拿走的判讀工具偏離標題暗示的方向。這比章節標題違規更隱蔽—章節標題違規讀者一眼看穿、內容偏離標題要讀完才發現、傷害更深。

Hallucinated source citation 的 fidelity 漏洞

WRAP Widen Options 需要 prior 支撐（「誰持這論」）、寫作者為了證明 prior 存在、容易引用「a16z、Sequoia、Andreessen」這類沒具體出處的 source。讀者 trust 在 source citation 上、hallucinated source 一旦被識破、整篇文章的 fidelity 崩。

解釋順序錯位、違反核心原則先行

當寫作者重心在「我有 source 支撐」、會把 source 放前面（「a16z 公開報告強調 X」）、解釋放後面。違反 AGENTS.md 原則一「核心原則先行」—讀者要的是解釋本身、source 是 attribution、不是 lead。

WRAP 內部分析方法論價值反而被稀釋

WRAP 是寫作者的 hypothesis 探索工具、價值在「強制做完整探索、防認知偏誤」。當分析過程被搬上文章主體、讀者把它當成「文章內容」吸收、原本的探索工具退化成「對讀者展示我做了多少 hypothesis 探索」的修辭。

跟其他抽象層原則的關係

• #141 WRAP 是寫作者的內部工具、不是文章章節結構：sibling 卡。#141 處理章節標題 surface 違規（process metadata 暴露）、本卡處理章節內容 scope 違規（WRAP 內部分析喧賓奪主）。兩卡互補—改章節標題不夠、還要改章節內容比重。

• #140 WRAP Widen Options 容易塌成稻草人 framing：cousin 卡。#140 處理 Widen Options 段落內部的稻草人結構、本卡處理 Widen Options 段落「該不該存在」的更上位議題。如果 Widen Options 跟標題承諾不對齊、根本不該獨立成段、稻草人問題自然消失。

• #131 教材完整性要用讀者旅程驗證：本卡是 #131 在「標題承諾兌現」維度的具體 instance。讀者旅程的起點是標題暗示、終點是讀完文章能做什麼。標題承諾不兌現、讀者旅程斷在中段、完成感跟可遷移工具都失效。

• #97 Metadata surface 要納入寫作 review 範圍：本卡擴 #97 的 metadata surface 概念。標題本身是 metadata surface—它對讀者承諾文章主體是什麼。Review 不能只看內文是否正確、要看「內文跟標題承諾是否對齊」。

• #126 寫作 review 是多軸完整性：本卡是 review 設計時要看的「scope 軸 + 標題對齊軸」的具體 instance。Review 不只看 frame / instance / surface、還要看「內容範圍跟標題承諾是否對齊」、是 scope 軸的延伸應用。

判讀徵兆

適用範圍與邊界

• 適用範圍：
  • 用 WRAP 框架寫商業 case-analyses、市場事件拆解、產業策略分析
  • 任何「標題承諾 vs 文章主體 scope」可能不對齊的情境（深度教學文章、技術 deep-dive、產業分析）
  • 文章標題明確指涉特定主題、但寫作過程容易被相關但非標題承諾的分析吸引展開
• 不適用：
  • 探索式 essay（標題本來就模糊、scope 由內文展開）
  • 短篇 commentary（內容篇幅不夠展開 scope mismatch）
  • 純技術 reference（標題承諾的是「查得到」、不是「主題聚焦」）
• 邊界：本卡禁的是「WRAP 內部分析喧賓奪主」、不是禁所有 WRAP 內部分析出現在文章。標題承諾本身就是「拆解 X 動機」的文章（例如 fde-arms-race 主題就是供應商為什麼押 FDE）、那 WRAP 內部分析才是文章主體、屬於正當對齊。判別線：標題承諾的主題跟 WRAP 分析的對象是否一致。一致就展開、不一致就壓縮成 cross-link。

外部分析文章是寫作材料、不是可直接搬進教學文章的事實層。把分析師文章、VC essay、產業評論改寫成本 blog 的商業分析時、先把材料拆成三層：可驗證事實、原作者判讀、本文推導。

判別問題：「這句話如果拿掉原作者名字、還能被當成可驗證事實嗎？」不能、就不可寫成事實句。

情境

content/business/ 的原始出發點是輸入其他分析師文章、再讓 AI 轉換成本 blog 要的風格。第一版 business case-analyses 雖然已經用 WRAP 拆事件、但 commit 演變顯示三個容易混在一起的材料來源：

第一、公開事件本身，例如 Anthropic 推出 Claude for Legal、Snowflake / Databricks / MotherDuck 同期推出 FDE、CoreWeave 收購 Bufstream。這些是可驗證事實。

第二、外部分析師對事件的判讀，例如「這是 enterprise ARR 驅動」「這是基礎設施垂直整合」「這是 SaaS 三支柱被鬆動」。這些是原作者或市場的解釋，不是事件本身。

第三、本文要教讀者帶走的框架，例如「三層擠壓」「資料平台前端化」「整併週期下的賽道判讀」。這些是本文推導。

Round 4 的 #142 已經處理「WRAP 內部分析喧賓奪主」；本卡補更上游的 source 問題：在開始寫正文前、先知道每句材料屬於哪一層。

理想做法

第一步：來源進稿前先做三欄標註

把外部文章或 AI 轉寫草稿中的句子標成三欄：

同一句若同時包含兩層、拆成兩句。例：「CoreWeave 收購 Bufstream，代表算力廠商開始垂直整合 data pipeline」應拆成：

1. CoreWeave 收購 Bufstream。這是事實。
2. 算力廠商往 data pipeline 延伸。這是本文判讀。

第二步：事實進事件段、判讀進 hypothesis、推導進主體

三層各有適合的位置：

外部分析師的判讀可以幫助 widen hypothesis space，但它不該直接變成本 blog 的正文結論。正文結論要由本文的 evidence weight 與可遷移框架承擔。

第三步：合成 frame 要標成本文推導

當文章把多個來源合成成一個框架時、要讓讀者知道這是本文的教學合成。寫法可以是：

1本文把這個變化整理成三層：應用層 SaaS、新創供應商、知識工作者。

這比「市場正在發生三層擠壓」精準，因為前者承認這是本文整理出的框架，後者容易讓讀者誤以為三層分類是外部事件本身。

第四步：引用來源時先寫概念、再放 attribution

來源 attribution 是可回溯支撐，不是段落主詞。先寫本文要教的概念，再補來源角色：

1API 型產品若毛利薄、供應商會傾向用 enterprise contract 對沖收入波動。這個判讀可作為檢查供應商動機的 prior，不能直接當作本篇三層擠壓的主體。

不要寫成「某某報告說 X，所以 X 是結論」。這會把來源權威放在概念之前，也讓讀者無法分辨 source claim 與本文推導。

沒這樣做的麻煩

分析師 frame 被誤當事實

外部文章的分類與比喻通常是作者的 frame。直接搬進正文，讀者會以為那是事件本身揭露的事實。後續若讀者回查來源找不到「三層擠壓」或「SaaS 三支柱鬆動」這些詞，會降低文章可信度。

AI 改寫會放大 attribution 漂移

AI 轉寫常把「某作者認為」壓縮成「這代表」。這個壓縮讓 claim 從觀點層滑到事實層。若沒有 source layering，改寫後的句子會更順、但 fidelity 更差。

本文自己的貢獻變模糊

教學型商業分析的價值是把事件整理成讀者可遷移的框架。若原作者判讀與本文推導混在一起，讀者看不出本文到底新增了什麼，只會覺得是另一篇摘要。

跟其他抽象層原則的關係

判讀徵兆

核心原則：外部分析文章進入教學寫作前、先拆成事實、作者判讀、本文推導。三層分清楚，文章才有可回溯性，也才看得出本文真正教了什麼。

跨領域分析的讀者層級要先定位、再決定術語密度。把商業分析寫給工程背景讀者時、不能繼承原分析文章的 VC / founder / industry insider 讀者假設；要把原文的高密度術語與壓縮因果鏈降到目標讀者可複製判讀的層級。

判別問題：「讀者若沒有商業分析背景，能不能用這段推導去分析下一個事件？」不能，就要降一級。

情境

content/business/reading-frameworks/writing-down-a-level.md 是從 business case-analyses 的 Round 5 修文抽出來的。當時讀者回饋指出，文章雖然比第一版更像教學，但仍太像寫給 VC / founder 的 deep blog：三句內連續塞進多個商業術語，且因果鏈跨太多步。

例如 Claude for Legal 的第一層擠壓原本把 enterprise license、API margin、長約、垂直流程、法律風險等概念壓在少數句子裡。工程背景讀者可能知道 API、SaaS、workflow，但未必直覺知道「為什麼毛利結構會推動供應商賣 enterprise contract」。若不拆開，讀者只能記住結論，無法複製推導。

後續 b9c5f06 新增 reading framework，8c67ab6 再把 FDE 與 Bufstream 文章的 5 段高密度內容降一級，形成穩定規則：跨領域文章要先判斷原文寫給誰，再決定本站要降到哪裡。

理想做法

第一步：先辨識原文的 reader contract

外部商業文章常見 reader contract：

本站 business case-analyses 的目標更接近「工程背景讀者讀 MBA 教材」：保留商業分析深度，但不預設讀者熟悉投資圈 shorthand。

第二步：用術語密度決定是否降一級

一段內若連續出現三個以上跨領域術語，就要拆段或補橋接句。

1API margin → enterprise ARR → vertical workflow lock-in

這串對 VC 讀者可能順，但對工程背景讀者需要拆成：

1. API 型產品的收入跟成本如何變動。
2. 為什麼長約能降低收入波動。
3. 為什麼垂直流程能讓客戶更難替換。

第三步：用因果鏈步長決定段落切分

每段只推一到兩步。若一句話需要讀者同時理解「成本結構、銷售模式、採購風險、workflow switching cost」，拆成多段。

第四步：用卡片承擔術語，不讓正文變字典

降一級不等於每次都在正文長篇定義名詞。若術語會反覆影響判斷成本，就建卡或連既有卡；正文只保留當下推導需要的最小解釋。

例：unit economics、switching cost、vertical SaaS 這類詞，若每篇都重新解釋，正文會膨脹；卡片負責概念，文章負責事件推導。

沒這樣做的麻煩

讀者只能記名詞，不能複製判讀

高密度商業語言會讓文章看起來專業，但讀者若無法把術語放回因果鏈，只會記住「FDE 代表 SaaS 三支柱鬆動」這種結論句。下一次遇到不同市場事件時，判斷工具無法遷移。

AI 改寫會保留原文讀者假設

AI 常把原文風格重寫得更流暢，但不會自動調整 reader contract。原文若寫給 VC / founder，改寫後仍可能保留高密度 shorthand，只是中文更順。

文章篇幅變短，但理解成本變高

跨領域文章最常見的錯覺是「短 = 清楚」。實際上，短句若省略中間因果，讀者需要自行補推導。對目標讀者而言，補推導的成本比多讀兩段更高。

跟其他抽象層原則的關係

判讀徵兆

核心原則：跨領域分析的寫作目標是讓讀者複製判讀，不是讓原文變順。先定位原文與目標讀者的層級差，再調整術語密度與因果鏈步長。

外部分析改寫的交付物是可遷移框架、不是風格轉換。把其他分析師文章交給 AI 改寫時，任務目標不能停在「改成本站語氣」「更正向」「更像教學」；真正要交付的是讀者能帶到下一個市場事件使用的判讀工具。

判別問題：「讀者讀完後，是否多了一個可重用的判斷問題或檢查表？」沒有，就還只是改寫。

情境

content/business/ 的建立過程是一場從「外部分析文章」到「本站教學型商業知識」的轉換實驗。commit 演變顯示，早期版本雖然有 WRAP、知識卡與 case analyses，但仍多次被讀者 feedback 拉回核心問題：

• #140：Widen Options 不能用稻草人修辭展示作者結論。
• #141：WRAP 是內部工具，不能直接當文章章節。
• #142：即使章節標題改了，正文仍要對齊標題承諾。
• writing-down-a-level：目標讀者是工程背景讀者，不是原文的投資人或創辦人。

這些問題共同指向一件事：AI 轉換文章風格不夠。文章要從「原作者如何看這件事」轉成「本站讀者以後如何判讀同類事件」。

理想做法

第一步：把任務定義成 frame extraction

輸入外部文章時，先問：

若事件只能產出「某公司發生某事」的摘要、沒有可遷移框架，就放在筆記，不硬寫成 case-analysis。

第二步：正文結構服務可遷移框架

教學型商業分析的穩定結構可以是：

1事件本身 → 結構性機制 → 長期影響 → 預警訊號 → 可遷移框架

這是責任順序，可依標題承諾調整。事件段讓讀者進場；機制段教為什麼；長期影響處理時間軸；預警訊號讓框架可被反證；可遷移框架讓讀者能帶走。

若某篇文章的標題承諾需要不同順序，可以調整；但最後仍要回答「這個事件教讀者下次看什麼」。

第三步：把原文觀點轉成判斷問題

風格轉換會把原文句子改得更順；框架轉換會把原文觀點改成讀者可問的問題。

判斷問題比結論更有價值，因為問題可以帶到下一個 case。

第四步：用預警訊號保護框架

可遷移框架需要知道何時失效。每篇 case-analysis 至少要有一段預警訊號，列出哪些觀察會推翻或削弱本文判讀。

沒有預警訊號的框架只是一組漂亮分類。讀者需要知道「何時重新評估」，才會把框架當工具，而不是把它當口號。

沒這樣做的麻煩

文章會變成原文摘要

AI 很擅長把原文改成不同語氣，但摘要仍然沿著原文的 frame 走。讀者得到的是「另一個版本的原文」，不是本站累積出的知識單元。

事件評論不可重用

若文章只回答「這件事代表什麼」，下次遇到不同公司、不同市場、不同產品時，讀者還是要從頭判斷。可遷移框架要回答「下次遇到相似事件，我要看哪些訊號」。

寫作規範會被誤解成表面風格

正向陳述、核心原則先行、商業邏輯先於 CASE 不是語氣規則；它們是把思考過程變成可重用知識的結構規則。若只做風格轉換，會通過部分表面檢查，但仍不符合知識庫目標。

跟其他抽象層原則的關係

判讀徵兆

核心原則：外部分析改寫的交付物是讀者可遷移的判讀框架，把原文變順只是表層。沒有框架、預警與下一步路由，文章仍停在摘要層。

案例庫主軸跟章節主題不在同一維度時、引用框架要從「正向掛入」切換到「反向追問」。正向掛入適用於「案例直接示範章節主題」、反向追問適用於「案例庫主軸是 A、章節主題是 B、A 與 B 雖正交但 A 可作為 B 重要性的反證」。

不對齊情境下若硬用正向句型、就會落到強掛。Reviewer 第一輪 audit 抓出後、修正成本是「全段重寫 + 重做案例對照」。先判讀對不對齊、再決定框架、比事後重寫便宜。

為什麼強掛會發生

寫作者面對「案例回寫」段時、預設「每章都該有 3-5 個 case 引用」、案例庫實際只有 1-2 個直接相關時、剩下會用 stretch 句型硬掛。stretch 的徵兆通常有三個：

• 用案例提到的 vendor / 服務名稱掛、不用案例揭露的機制掛
• 描述句型抽象、避免具體斷言：「看 X 如何決定 Y」、回查 case 找不到「怎麼決定」
• 把案例次要訊息當主軸：case 主軸是 A、引用句只提 B、B 在 case 是一筆帶過

背後動機是「想讓段落看起來完整」、而非「想讓讀者看到證據」。3-5 個 bullet 變成內在配額、引用變成填空、不是工具。這條動機跟 #122 Cadence 同質化是模板的隱形維度 的成因同源 — 模板從「輔助結構」滑落為「強制配額」。

反向追問步驟

不對齊時、反向追問的標準操作分三步：

1. 誠實標示案例庫主軸差異：開段直接寫明「本案例庫主軸是 A、直接以 B 為主題的案例較少」、把案例庫的限制當 first-class 訊息傳給讀者。讀者知道後續引用會用反向讀法、而非把它當成直接示範。
2. 把案例當「沒做 B 的後果」：每個 case 改寫成「在沒有先用 B 收回壓力的前提下、團隊走了哪條路（遷移 / scale-out / vendor 升級）」、case 因此變成 B 重要性的反證。寫作意圖從「示範 B」轉成「示範沒做 B 的代價」。
3. 明示分層追問：在引用描述句裡寫明追問 — 讀者讀完 case 應主動問「這條撞牆是否被 B 放大」。把追問句寫進引用、讓讀者知道這是反向讀法、而非把 case 當對齊。

三步驟做完、案例段仍保留同樣多的引用、但語意誠實、reviewer fact-check 不會抓出不符。

Case

backend/01.13 查詢反模式章節 在 reviewer audit 階段的具體經驗：

原寫法：3 個 09 模組 case（DoorDash / Zomato / Standard Chartered）被強掛在「Long-Running Transaction」「Query 預算」這類 application-layer query 反模式主題上。

Reviewer fact-check 結果：

• DoorDash case 主軸是 single-primary 寫入吞吐瓶頸、跟 long transaction 無關
• Zomato case 主軸是 TiDB → DynamoDB 遷移、case 完全沒有 query budget 討論
• Standard Chartered case 主軸是合規驅動容量規劃、跟 N+1 / query 預算 stretch

2.5 / 3 case 的引用描述跟 case 原文不符。

修正：改用反向追問框架。開段標示「09 案例庫主軸是規模、vendor 與容量壓力、直接以 query 反模式為主題的案例較少」、三個 case 重寫成「遷移 / scale-out / 合規容量規劃前、是否該先用 query 反模式收回單機容量」的反向追問。Reviewer 二輪通過、3 個 case 全保留、語意誠實。

這個 case 揭露的核心：reviewer 抓到的不是「引用太多」、是「引用方向錯」。改框架後同樣 3 個 case、reviewer 滿意。

跟其他卡的關係

本卡跟以下三張卡正交、各自處理 case 引用的不同層問題：

• #115 案例引用深度跟著 case 類型走 — 處理「case 類型決定引用深度」（skeleton / medium / rich）。本卡處理「case 主軸不對應時的引用框架選擇」、是更上游的問題：先判斷對不對齊、再決定引用深度。
• #120 案例引用三段式段落結構 — 處理「段落結構順序」（概念 → case → 通用展開）。本卡補 #120 的特殊情境：當 case 主軸不對應時、第二段位置的 case 引用該寫什麼。
• #122 Cadence 同質化是模板的隱形維度 — 處理「cadence 模板化」。本卡的「強掛」現象背後就是 cadence 模板化的內在動機之一 — 想讓每段都「看起來合規」、結果犧牲語意誠實度。本卡是 #122 在「案例引用」surface 的具體成因 + 修法。

跟 #116 引用案例要分觀察層 / 判讀層 也有張力：#116 強調觀察層 / 判讀層分明、本卡的反向追問可以視為一種「明示分層」的特殊型 — 把整個引用標為「反向讀法」、相當於把整段都歸到判讀層。

補兩張上位卡：

• #114 Multi-pass review 的 frame 顆粒度盲點 — #146 的「抽象斷言訊號」（「看 X 如何 Y」）就是 #114「keyword bank」機制的具體 keyword 條目。本卡是 #114 機制 1 的應用實例 — 給作者一份可直接 grep 的關鍵字清單。
• #117 跨多 case 合成的 frame 必須標為章節合成 — #117 處理「合成必須明示標示」、本卡的「反向追問」也是明示標示的一種 — 把「我用反向讀法解釋案例」明確告知讀者、避免讀者誤以為 case 直接示範了主題。兩者都處理引用層的誠實標示、是姊妹卡。

沒這樣做的麻煩

強掛 case 在以下節點會引爆：

• Reviewer 第一輪 audit：fact-check 案例內容 vs 引用描述、不對齊馬上抓出。修正要全段重寫。
• 讀者回頭追查：讀者點進 case 看不到引用句宣稱的內容、會懷疑整章其他斷言的可信度。
• 長期 SSoT 漂移：案例 case 內容後續更新時、強掛的引用不會跟著更新、變成 stale reference。

更深的代價：強掛 case 違反 AGENTS.md 原則八「情境優先於模板」— 把不同案例塞進同一段落模板、抹平案例的真實主軸。Reviewer 抓到的是表面（描述不符）、根因是寫作者讓模板配額凌駕語意誠實度。

判讀徵兆

寫完案例段時、用以下訊號自檢、出現任一就考慮切換到反向追問：

• 抽象句型訊號：引用句寫成「看 X 如何決定 Y」這種無具體斷言的句型、回查 case 找不到「怎麼決定」的具體段落。
• 句型雷同訊號：多個 case 引用句型雷同（都是「看 X、對照 Y 段」）、跟 #122 cadence 同質化 重疊。
• 維度錯位訊號：章節主題是 application-layer（query 反模式 / 應用層快取設計）、case 庫主軸是 vendor / 規模 / 容量壓力 — 兩者在不同抽象維度。
• 配額膨脹訊號：引用句數 ≥ 3 但每個都「邊際相關」、沒有任一個「直接相關」。

四個訊號中出現任一、優先切換到反向追問、別把不對齊強寫成對齊。寫作意圖從「填滿段落」轉成「給讀者誠實證據」、case 段才能撐住 reviewer fact-check。

把反模式抽象成規範卡、跟在自己稿件辨識該反模式的局部實例、是兩種不同認知任務。同一個作者可以清楚寫下「『看 X 如何 Y』是抽象斷言反模式」、同一個 batch 內已寫的 5 篇章節仍能有 11 處該句型未被察覺。

兩個任務對比：

兩者用相似概念詞、走不同神經路徑。立規範時注意力放在「為什麼這 pattern 是反模式」、自審時注意力要放在「我這句話符不符合該 pattern」。前一個動作完成、不會自動觸發後一個動作。

為什麼立規範後仍會犯

三個認知機制讓兩者解耦：

1. 抽象化耗用認知頻寬：寫下「N+1 query 反模式」這個概念時、作者的工作記憶被 pattern 的本質、對比、邊界佔滿、不會同時掃描自己已寫過的稿件
2. 規範化視角是 outside-in：規範化把 N 個實例抽象成 1 個模式、看的是「共同特徵」；自審視角是 inside-out、從自己具體句子往外比對、看的是「這句屬不屬於這個 pattern」
3. 同 batch 主題語意 attractor（見 #122 Cadence 同質化是模板的隱形維度）：規範化之前寫的稿件、受同主題 / 同 constraint 拉到相似句型；規範化動作本身不會 retroactive 修這些句型、需要主動 sweep

這三個機制累積起來、「我剛寫完反模式定義」不等於「我能在自己稿件抓出該反模式的所有實例」。

Case

backend 模組 5 篇章節（5.9 / 0.18 / 0.19 / 9.13 / 1.13）的修正過程：

1. Round 1 reviewer audit 抓出 1.13 章節案例引用 mis-cite、修正後寫成 #146 案例庫不對齊章節主題時用反向追問 卡片。#146 明確列出「抽象斷言訊號：『看 X 如何 Y』這類無具體斷言的句型是反模式」、並作為「判讀徵兆」的四訊號之一。
2. #146 卡寫完當下、作者同 batch 已寫的 5 篇章節 case 段內仍有 11 處「看 X 如何 Y」句型未被察覺、未被修正。
3. Round 2 reviewer 用 cadence frame 跑 grep（直接拿 #146 描述的反模式當 keyword）、抓出全部 11 處、Round 2 修正後用具體事實 / 數字 / 機制斷言取代。

這個案例的諷刺感正是本卡的核心：作者剛寫完規範、自審能力卻沒同步提升。中間缺的是「規範化 → grep 自審」這條主動觸發路徑。Round 2 reviewer 補上的就是這條路徑、但理想上規範作者自己當下就該做。

修法

三種觸發機制可以接在規範化動作後：

1. 立規範後立刻跑 keyword grep（含同義變體）

把新立的規範轉成 rg 可掃的 pattern、對所有同 batch（甚至既有）稿件跑一次 grep：

1# 例：#146 立下後的 keyword grep
2rg "看 .{1,20}如何|看 .{1,20}的決|看 .{1,30}的策略|看 .{1,30}的差異" content/<scope>/
3
4# 但同義變體 grep 同樣重要 — Round 3-A 抓出的盲區
5rg "展示 .{1,30}效應|展示 .{1,30}邏輯|本案展示|案例展示" content/<scope>/

第一輪 grep pattern 受作者當下視野侷限、通常只涵蓋規範化時用的字面例子、漏掉同義變體。「規範化第一次落地不可能 catch 所有同義變體」是這條機制的天然限制 — 需要 Round N 持續擴張 keyword bank、跟 #114 multi-pass review 的 frame 顆粒度盲點 同源。實證：本卡 Round 2 修「看 X 如何 Y」字面層、Round 3-A 仍能 catch 出「展示 X 效應」「展示 X 邏輯」同義變體、證明 path 需要疊代而非一次性動作。

2. 結構句型 cadence sweep（補字面 grep 不抓的維度）

字面 keyword grep 抓詞、抓不到結構骨架。常見漏抓的結構句型：

• 「先 X、再 Y、最後 Z」三段平行
• 「N 個案例可分別對應…」枚舉式收尾
• 「對應本章 X 段」反覆出現、構成段末 cadence

這類結構違反字面層查不到、要靠 reviewer 跨稿件對讀才能 catch。修法是擴張 #122 cadence 同質化的 grep target、加入「結構骨架」維度：sweep「先看 .{1,30}、(再|接著)」「N 個 .* 分別」「對應本章「.*」段」這類 pattern。

3. 把規範卡的「判讀徵兆」當 self-audit checklist

每張 report 卡的「判讀徵兆」段（如 #146 列的 4 訊號：抽象句型 / 句型雷同 / 維度錯位 / 配額膨脹）就是現成的 self-audit checklist。立規範當下、作者應該主動把這 checklist 套到自己同 batch 稿件 — 而非預設「我剛寫完應該不會犯」。

4. 用 reviewer 跑 in-stream sampling

如 #124 emergence-class 違規 enforcement 時機 描述、emergence-class 違規（cadence 同質、抽象斷言這類）字面 hook 抓不到、要 reviewer in-stream 才能發現。本案 Round 2 cadence reviewer 是這個機制的應用、Round 3-A 進一步抓出 Round 2 修法的同義變體盲區 — 兩輪 reviewer 用不同 frame 才能完整覆蓋。理想上規範作者自己應該先做前三層（字面 grep + 結構 sweep + checklist）、reviewer 是補位、不是替代。

四種機制按介入點分層：字面 grep 是 keyword 層、結構 sweep 是 cadence 層、checklist 是徵兆層、reviewer 是 frame 層。立規範後四層都跑一次、覆蓋率最完整。單跑字面 grep（如本卡初版只給 keyword pattern）會漏掉結構 cadence 跟同義變體、屬「規範化視角」單軸盲區、要靠後續疊代擴張。

跟其他卡的關係

• #122 Cadence 同質化是模板的隱形維度 — 解釋「為什麼同 batch 會有 systemic 違規」的成因機制（主題語意 attractor）。本卡補完：規範化動作本身無法解這個 attractor、需要主動 sweep 才能切斷。
• #124 Emergence-class 違規規則化不了、要 stage 內抽樣 — 解釋「什麼時候 enforcement 最有效」（batch 進度 10-20%）。本卡補一個更早的時機點：立規範當下立刻 sweep 同 batch、不必等 batch 進度推進。
• #114 Multi-pass review 的 frame 顆粒度盲點 — 解釋「為什麼同 reviewer 多輪抓不到不同東西」、提出 keyword bank / reader simulation / self-criticism 三機制。本卡是 #114 在「規範作者本人」這個 reviewer 角色的具體實例：作者剛寫完規範、仍需主動換 frame 才能自審。
• #125 Collapse 是隱形預設 — 「規範化耗光認知頻寬、自審視角沒上線」是 collapse 的具體機制：規範化動作把高維注意力 reduce 到單軸（pattern 共同特徵）、其他軸（同 batch 自己稿件）被預設關閉。本卡是 #125 在「規範化 surface」的子實例。
• #126 寫作 review 是多軸完整性、不是單軸深度 — 本卡揭露的「規範化 ≠ 自審」是 #126「Timing 軸」+「Granularity 軸」的具體交集：立規範當下不掃 = timing collapse、規範字面 vs 同 batch 違規 = granularity collapse。
• #146 案例庫不對齊章節主題時用反向追問取代強掛 — 本卡的 case 來源。#146 才剛立規範、同 batch 仍犯該規範、是「規範化 ≠ 自審」最直接的諷刺證據。本卡跟 #146 互為驗證關係：#146 給出規範本身、本卡解釋為什麼立完規範還需要主動 sweep。

判讀徵兆

立規範後若不主動 sweep 同 batch、會出現以下訊號：

• 諷刺對映訊號：規範卡描述的「反模式」可以一字不改貼回自己稿件、自己仍意識不到。最強訊號、出現代表 inside-out 視角完全沒啟動。
• 跨稿件 catch 訊號：該規範立下後一週內 reviewer audit 跨稿件、catch 出該規範的多處違規（≥ 3 處）。代表規範化跟自審之間斷層。
• 自審盲區訊號：自己 review 自己稿件時、卡片描述跟稿件實例之間的「相似度」感官弱（明明 textbook 案例、自己讀不出來）。代表規範化耗光認知頻寬、自審視角沒上線。
• 品質非單調訊號：同 batch 多篇文章在規範化前後寫的、品質沒有顯著差異。代表規範化未轉換成執行力。

出現任一訊號、表示「規範化 → 自審」這條路徑沒接通。立刻跑修法的三層機制（grep / checklist / reviewer）對自己稿件做 sweep。

判斷「該不該再來一輪 review」的訊號是「frame 軸是否還有未動」、不是「上一輪 finding 變少」。

兩種訊號的對比：

多輪 review 的 ROI 不是 monotonically decreasing。每輪用新 frame 通常仍會抓出 substantial finding、但內容會從 surface compliance（編號 / 連結 / 案例對應）往深層 structural issue（cadence / enumeration / 反向引用斷裂）走。停止訊號是「下一輪可用的新 frame 已經想不出來」、不是「上一輪 finding 變少」。

為什麼 finding 數不是停止訊號

三個原因讓「finding 遞減」誤導：

1. 每輪修法會 surface 下一輪問題：修 cadence 1.0 會把 cadence 從位置 X 漂到位置 Y、變成 cadence 2.0；修 enumeration 不窮盡會 surface 反向引用斷裂（補完 enumeration 才看見哪些章節該引）。修 = 暴露 new surface。
2. frame 切換等於進入新的問題空間：Round 1 用 compliance frame catch 不到 cadence 同質化、Round 2 用 cadence frame catch 不到 enumeration 不窮盡、Round 3 用 steelman frame catch 不到 outbound impact。三輪 frame 正交、finding 互不重疊、自然不會遞減。
3. finding 深度遞增、不是寬度遞減：Round N 通常需要 frame 更精緻才能 catch、但 catch 到的問題更接近本質。Raw count 可能不變或增加、但每個 finding 的修正成本跟價值都更高。

把 finding 遞減當停止訊號、會在「正在進入更深層 issue」的時刻錯誤收尾。

跨輪 review 的質性 transition 模式

實證觀察、跨輪 review 的 finding 內容會走以下 transition：

實證的階段不一定按此順序、但通常從 surface 開始、隨 frame 切換往深層走。Meta 階段在 surface / cadence / structural 都修完後仍能 surface 新問題 — 因為它檢查的是「修法過程本身」、屬另一個維度。

每個階段內、frame 用完就遞減；跨階段、新 frame 上線就重新進入「新一輪不遞減」狀態。

停止訊號的 4 個判讀

何時可以判定「真的夠了」？四個判讀齊備、再停：

1. 七軸 frame 全動完：per #126 review 七軸、frame / instance / surface / scope / cadence / timing / granularity 七軸都用過、沒有遺漏的觀察維度
2. 新 frame 想不出來：團隊腦力激盪後想不出「能 catch 上一輪 frame 抓不到的東西」的新 frame、代表問題空間已涵蓋
3. Finding 性質回到 surface：若新 frame catch 到的 finding 又退回到 surface（編號、連結、低密度 cadence）、代表 structural / meta 維度已穩定
4. 修法成本反轉：若修一個 finding 的成本超過讀者實際感受的價值、繼續修不划算 — 用 #125 collapse 的提醒、避免完美主義 collapse 到無止境疊代

四個訊號齊備、停的判讀是 evidence-based 而非 finding 數驅動。

Case

本次 backend 5 章 + 1 report 卡的 3 輪 review 實證：

• Round 1（compliance / 案例 / 跨章 frame）：12 個 finding、surface 層為主、編號 mis-cite + case mis-citation
• Round 2（cadence / 旅程 / title frame）：10 個 finding、cadence 同骨化 + 影片詞彙橋斷裂 + 時序總表缺失
• Round 3（self-application / steelman / outbound frame）：16 個 finding（比 Round 1 / 2 還多）、三段式 cadence 從位置漂移 + enumeration 稻草人 + 單向反向引用斷裂

Total 38 個 finding、9 個 reviewer instance、零重疊。Round 3 finding 數反而比 Round 1 / 2 多、但 Round 3 是 review 自然停下的點 — 因為「想不出能 catch Round 3 frame 抓不到的東西的 Round 4 frame」。

判讀停止的依據是 frame 涵蓋（七軸動完、Round 4 frame 想不出來），不是 finding 數遞減（Round 3 數還在升）。若按 finding 遞減判讀、Round 1 → Round 2（12 → 10）就該停、會錯過 Round 3 抓出的 16 個結構性問題。

跟其他卡的關係

本卡跟以下卡片正交、處理「多輪 review 何時停」這個 #114 / #126 / #147 沒覆蓋的問題：

• #114 Multi-pass review 的 frame 顆粒度盲點 — 說明「需要不同 frame」。本卡補完：知道需要不同 frame 後、判讀「何時 frame 涵蓋夠」的訊號。
• #126 寫作 review 是多軸完整性、不是單軸深度 — 列七軸。本卡用七軸作為停止判讀的具體 checklist、補強 #126 在「執行收尾」這層的判讀工具。
• #147 規範化跟自審是兩種認知任務 — 說明「規範化第一次落地不可能完整、需要疊代」。本卡補完：疊代到什麼時候停？停止訊號跟疊代啟動訊號是不同維度。
• #125 Collapse 是隱形預設 — 「無止境疊代」是 collapse 的另一個極端（從「規範化單軸 collapse」反向到「review 過度 collapse 完美主義」）。本卡用「修法成本反轉」訊號避免這個反向 collapse。

判讀徵兆

跨輪 review 中、出現以下訊號時要重新評估「該繼續還是該停」：

• 新 frame 卡住訊號：規劃下一輪 review 時、想了 30 分鐘想不出「能 catch 新東西的 frame」— 是「frame 涵蓋已足」的強訊號
• Finding 性質退化訊號：新一輪 finding 退回 surface 層（編號 / 連結這類低密度議題）、structural / meta 層沒新東西 — 代表深層 issue 已穩定
• 修法成本超過邊際價值訊號：修一個 finding 要動 50+ 行、但讀者實際感受改善有限 — 修法 ROI 已下降
• Frame 重複訊號：新一輪 reviewer 的 finding 跟上一輪有重疊（per #114 同 frame 多輪 catch 高度相同）— 代表 frame 軸沒換、再跑無增益

四個訊號中出現任二、可以判定「真的夠了」。出現任一、繼續但要規劃 frame 切換。沒有任一、按七軸繼續推進。

「夠了」的判讀本身是 evidence-based、不是直覺 — 用上面四個訊號當 checklist、比「finding 變少就停」可靠。

以 Zettelkasten（卡片盒筆記法）為核心的寫作方法論。將每段文字視為可重複組合的原子卡片，讓人類讀者與 AI 代理人都能以最小認知負擔找到答案。

Core Pillars（核心支柱）

Core Principles（核心原則速查）

讀者能在本區塊完成快速複習；需要具體應用時，依下方「觸發路由」讀對應情境 reference。

1. 原子化（Atomization）

一張卡一個概念：能獨立理解、可跨情境重用。拆分依據是認知負擔與情境匹配度 — 讀者要同時記住的概念數、以及這張卡是否符合讀者當下的情境需求。常見的誤判依據是「行數」（卡太長就拆）、行數只反映表面字數、不反映概念數：一張 200 行的卡可能只講一個概念、一張 30 行的卡可能塞了三個概念。判別問題是「讀者要同時 hold 幾個概念才讀得懂這張卡」、超過 7 個就要拆。

拆分判準的核心問題：「這張卡聚焦在什麼問題、議題切完整了嗎？」— 判準是 focus 完整度。常見的次級訊號是「卡之間是否衝突」「邊界是否清晰」、兩者都不夠：兩張卡互不衝突、仍可能各切了一半同樣議題；一張卡邊界清晰、仍可能塞了兩個獨立議題。focus 完整度問的是「這張卡有沒有把它聲稱要解決的議題講完」、是 contrast 上面那兩個訊號抓不到的死角。

2. 索引建立（Indexing）

用 MOC（Map of Content）、tag 層級與反向索引把卡片串成可導航的網。入口文件只做路由、把細節留給目標卡；引用深度最多一層、讓讀者一跳就到答案（避免 A→B→C 的多層跳躍）。

引用錨點用語意標題、不用位置編號：引用另一個章節 / 階段 / 條列項時寫「見核心問題」、不寫「見 Stage 3」— 編號是結構排列的 derivation、結構重排時引用句字面完好、語意 silent 指向錯的內容（比 broken link 難偵測：連結斷掉會報錯、編號錯位會成功解析到錯的東西）。對應要求是每個結構單位的標題要承載核心意義（「Stage 3：核心問題」、編號只作排序前綴）、引用取語意半邊；發布方凍結的編號（RFC 段號 / 法條）是 fact、可引用。詳見 reference-by-semantic-title-not-number。

語意錨用單一字串、引用他卡用對方的詞彙：同一個結構單位的語意名稱只能有一個 canonical 字串（取標題語意半邊）— 同義雙名（標題「決策記錄 + scaffold 建議」、引用「決策收斂階段」）讓 grep 掃 A 漏 B、重排修復退回人腦對應。引用另一張卡並描述它的內容時、寫之前把被引卡重新打開、用它自己的分類詞彙轉述 — 記憶存概念不存 taxonomy、憑印象轉述會把對方明確分開的類別併掉、每條關係宣告要找得到被引卡的支撐句。

集合命名用角色、不內嵌數量：標題要當穩定錨、就得先是純 fact —「核心七問」「成長六階段」「四大支柱」把成員數烤進名字、數量是成員清單的 derivation、加一問名稱先失真、所有複製過名稱的地方跟著過期。命名只承載角色與層級（核心問題 / 撞牆階段 / 支柱）、數量讓清單自己呈現；外部凍結品牌（SOLID 五原則 / OWASP Top 10）跟概念閾值（兩次門檻）的數字是 fact、可留。詳見 name-collections-by-role-not-count。

3. 意圖顯性與層級貼合（Explicit Intent & Layer Alignment）

寫作前先標記本文所在抽象層級（實作 / 工具 / 協作 / 認知 / 架構）、論述停在該層。素材取自哪個層級、論述就收斂在哪個層級 — 因為跨層提升等於用 X 層的詞彙描述 Y 層的議題、讀者拿到規則但對不到自己當下的情境。要把實作層素材抽象到認知層、先補對應抽象層的支撐文件（讓論述有對應層的詞彙跟 case 可引用）、再做跨層提升。

寫「為什麼」和「要達成什麼」、把「程式碼在做什麼」留給程式碼自身（程式碼讀一次就知道做什麼、寫進註解只是冗餘）。主詞與動詞直接、段落開頭即表達意圖。TODO / placeholder 留給 inline 註解、文件本體只放當前契約 — 因為文件常被當成「契約 SSoT」引用、混入未完成事項會讓讀者誤判契約範圍。同一篇文字貼合它在系統裡的抽象層級、把下層實作藏在介面後面。

機會成本語氣優先：程式設計大多是多目標取捨、討論的是「在什麼情境下哪個選項較划算」。把絕對二元語氣（「正確概念是 X / 替代方案不足 / 應該這樣做」）翻成情境化敘述：「比較好的做法是 A、因為 [情境] / B 在 [其他情境] 合理 / D 的成本特別高、只在 [極端情境] 才划算」。機會成本教讀者「思考方式」（能套用到新情境）、絕對主義教讀者「規則」（壓力下會忘）— 所以前者是預設語氣。例外保留給物理 / 法律 / 數學事實（安全性、數據完整性、合規、雜湊必有碰撞）。絕對二元語氣有兩種形式：命令式（「應該做 X」）讀者聽得出是主張、會審；必然式（「X 天生就是 Y / 本質就是 / 必然」）偽裝成事實陳述、更隱形 — 把設計選擇講成自然法則時尤其要 catch、還原成「在選了某前提後 X 才以此形式成立」。判別線：這個必然有沒有上游設計選擇當前提（有=條件性、要講前提；無=真必然、可斷言）。詳見 teaching-prose-neutral-register。

選項數由議題本身的合理選項數決定：機會成本的精神是「教思考方式」 — 議題有幾個合理選項就寫幾個（2 個寫 A/B、3 個寫 A/B/C、4 個寫 A/B/C/D）。強湊到固定數量會把「教思考」退化成「填格式」、生出「實務上幾乎不存在」的低品質假反模式。真正的反模式直接標「D：反模式 — 違反 X 原則」、給讀者明確的「為什麼這條路該避開」、保持誠實。

讀者定位聲明（生成端前置步驟）：每個教學模組在第一篇文章生成前，顯式聲明讀者定位——一段話描述目標讀者的背景、已有能力、缺的經驗。這份聲明是後續所有生成和 review 的可檢查基準。缺少顯式聲明時，LLM 預設用「教外行人」的姿態寫教學內容，這個預設不被 review 挑戰（reviewer 共享同一個預設），導致宣導語氣通過多輪審查。per outside-in reader frames report

讀者定位：缺經驗的專業人士、不是外行人：技術教材的讀者是在特定領域缺乏經驗的專業人士，不是完全不懂的外行人。寫法是補足經驗缺口（直接描述情境與操作需求），不是從零科普（故事線導入、比喻堆疊、宣導語氣）。宣導式語氣（「你可能沒注意到」「把 X 想成 Y」「跑得好好的」）預設讀者無能、降低教材可信度。詳見 audience-is-professional-not-layperson。

跨專業溝通用情境遞進、不用比喻堆疊：向非本領域的專業人士（管理層、決策者）解釋技術議題時，減少術語並從簡單情境遞進到複雜情境。比喻傳遞形狀但不傳遞嚴重性、在細節處崩解、且隱含「對方聽不懂」的預設。用決策者熟悉的維度（影響範圍、恢復時間、成本量級）表達。詳見 cross-expertise-scenario-not-analogy。

技術教材內嵌管理層可彙報的資訊：技術段落旁嵌入成本量級、時程估算、進度指標與決策簽核點（各 1-2 句），讓讀者學完技術做法的同時拿到向上彙報的素材。成本用量級不用精確數、時程用範圍不用單點、進度用可查詢指標。詳見 management-reportable-info-in-technical-content。

知識卡建卡判準用「最不熟悉的讀者」：知識卡的建卡判準是「目標讀者群裡最不熟悉的那端能不能理解這個術語」，不是「作者覺得夠不夠常見」。常識是相對於背景的——.htaccess 對 PHP 工程師是常識、對 Node.js 工程師完全陌生。跨背景讀者群的教材裡，幾乎所有領域特定術語都需要建卡。建卡的邊際成本低（40-50 行）、讀者缺卡的代價高（離開教材去 Google、可能找到不一致的解釋）。per 常識是相對於讀者背景的。

操作步驟帶環境專屬工具路徑：操作型文章的每一步至少帶一條工具路徑（用什麼軟體、輸入什麼指令）。同一個動作在不同環境（container / VM / 共享主機）的工具路徑可能完全不同——「拍下現況」在 container 是 docker commit、在 VM 是 AMI 快照、在共享主機是 FTP mirror + phpinfo。文章涵蓋多種環境時、每一步要按環境分列工具、或標明適用環境。自測問題：「讀者坐在電腦前，下一個動作是打開什麼軟體？」答不出來就是缺口。per 操作指引要帶環境專屬工具路徑。

Case 引用段落的三段式結構：三段式是案例引用段落的順序紀律 — 把「概念 → 案例 → 操作」三層分開承擔（段首給概念定義、case 引用居中、通用工程知識展開）、讓段落結構跟讀者學習新概念的認知順序對齊。LLM 從 case 反推內容容易把 case 揭露當概念出發點、實證觀察 11/12 段都犯這個錯。詳見 case-citation-three-part-structure。

原子筆記要有向上的議題入口：承載知識的原子筆記（Zettelkasten 卡 / glossary / 術語條目）不是字典條目 — 字典答「這個詞是什麼」、承載知識答「你在討論什麼、撞到什麼問題、才需要這知識」。撰寫者有預設情境讀者沒有、所以每張卡（或其上層）要從情境進入而非劈頭給定義：建議題 hub（以讀者遇到的問題為題）討論再分流到原子卡、卡頂回指議題、讓搜尋直接落地者也有回路。沒這層卡淪字典、讀者沒有觸發點、不知何時用。詳見 atomic-note-needs-situational-entry。

4. 可查詢性（Searchability）

關鍵字前置、使用可 grep 的分隔符（: | → ==）、欄位名稱使用 regex 友善格式。命名讓 AI 能以單次 grep 命中，不需要語意推理。

5. 欄位設計（Field Design）

同一份文件的不同欄位，從不同角度觀察同一件事，不重複撰寫。what 描述動作、why 陳述動機、acceptance 定義可驗證條件；混淆欄位會讓讀者在多處讀到相同內容。

6. 多輪 Re-read Pass（Multi-pass Review）

完稿即進入 review 階段。一次寫對全部維度違反 working memory、實際結果是「每維度都做一半」。設計 N 輪 re-read、每輪用不同 frame：

Surface enumeration 是 multi-pass 的固定前置步驟。寫作產物包含 body surface 與 metadata / navigation surface：title、description、tags、heading、link label、MOC / index entry、slug / filename。每輪 frame 都掃這份 surface 清單，讓正文與讀者入口共用同一個概念錨點。description / hook 對規則做壓縮時、可以丟細節、不可以改模態 — 把本體的「條件允許（可延後但要記錄）」壓成「絕對禁止（不可跳過）」、讀者依摘要行動就會偏離本體；摘要讀起來比本體「更有力、更乾脆」就是失真訊號、模態詞跟主詞動詞同級、最後砍。實測一批七份文檔有四份的 description 出現模態漂移 — 這個檢查每批都要跑。

核心：「再仔細一次」≠ multi-pass — 同 frame 重看 catch 不到新問題。每輪換 frame、才能 catch 不同層。各 reference（writing-articles / writing-code-comments / writing-documents / writing-prompts）依 output 類型有特化的輪次組合。

Naming 是這條原則最容易跳的子場景 — 第一版命名幾乎不對、四輪 review（第一版 / grep / cross-call-site / impl 洩漏）才收斂、見 naming-as-iterated-artifact 跟 writing-code-comments 的 naming review 段。術語是 naming 的高歧義子場景：翻譯術語第一次出現保留原文錨點，中文壓縮術語保留完整名詞頭，中文名詞頭要保留來源中的概念角色，見 terminology-keeps-original-anchor、compressed-chinese-terms-need-head-noun 與 translation-must-preserve-concept-role。

高 stakes 內容追加輪 E（epistemic rigor、conditional opt-in）：reader 照做後錯誤不可逆的內容（資安 / concurrency 正確性 / distributed consistency / financial / medical）在 5 輪基本 frame 之外、追加 stakes 軸的 epistemic rigor pass——比照學術 peer review 跑 claim / evidence / method / threats / citation 五個 sub-check、加上 audit recommendation tier（accept / minor / major / withdraw）。一般內容 5 輪夠、不跑輪 E；高 stakes 內容兩軸都跑。詳見 references/auditing-articles.md 跟 /report/writing-multi-pass-review/ 的「stakes-conditional 追加輪」段。

Production 教學文章追加輪 8-10（字句層 catch、跑 N 輪仍漏時觸發）：跑了 5 輪基本 frame 仍系統性漏 catch 字句層問題（口語修辭 / 廢話前綴 / 地區漂移 / 依賴 code / 裝飾符號 emoji / 對讀者喊話 / 自評誇飾 / 必然性框架 / 恐嚇式語氣 / 歸因語氣）時、追加三個換軸機制——輪 8 keyword bank（換工具、含 emoji / 裝飾 unicode 掃描）、輪 9 reader simulation（換視角、四 lens：自包含性 + register/stance + meta 殘留 + AI 歸因過度）、輪 10 self-criticism（換層次、審視 framework 本身覆蓋度）。短文 / 即時 note 不需要、production 教學文章在跑 5 輪後仍漏同類問題時 opt-in。keyword bank 命中是候選、不是判決——grep 命中後仍要一個語意判定步驟（這個命中是建立概念的違規、還是合規的反例對照 / hook），reviewer 容易把違規合理化放行；偵測（bank）跟判定（語意）是兩個認知步驟。register/stance 類（喊話 / 誇飾 / 必然）無穩定關鍵詞、keyword bank 抓不到、輪 9 reader-sim 是主 keyword bank 是輔、且最依賴 external cold-read。漏抓後補機制前先分 design gap（框架缺 frame、改框架）vs execution gap（框架有 frame 但只跑了臨時子集、改執行不是改框架）——「加 keyword」對 execution gap 跟無關鍵詞的類都無效。詳見 multi-pass-review-frame-granularity、decorative-symbols-keyword-bank、teaching-prose-neutral-register 跟 references/writing-articles.md 輪 8-10 段。

批量 sibling 寫作的生成端輪替：一次寫多份同類文檔時、cadence 同質化會在六個層發生（title 形式 / 開場句式 / 章節標題 / 敘事骨架 / 條目形態 / 跨檔引用句）、單份 review 全部抓不到、且 review 端抓過的同骨會在下一批復發 — 同類 finding 第二次出現、就把規則升到生成端：寫之前排好開場 frame 輪替（規則先行 / 後果先行 / 動作先行 / 反差先行）、條目形態輪替、敘事視角輪替、引用句去重。詳見 cadence-homogenization。

Instance 軸：跨 reviewer instance 隔離：Instance 軸是 multi-pass review 的另一條擴展軸 — N 個獨立 reviewer instance 各自獨立 context、各自跑 background、解「單一 reviewer 同時看多維度容易維度盲點 + context 污染」的問題。Instance 指獨立 reviewer 程式實體（如 agent tool spawn 出的 subagent）、跟同一 reviewer 換輪次 frame（frame 軸）正交可疊加。適用 production 教學文章 / 高 stakes 內容 / 跨章節教學模組這類維度複雜度高的審查場景。詳見 agent-team-context-isolation。

詳見 Writing 的 multi-pass review、Methodology 的 multi-pass 該 embed 在 pillar、Metadata surface 要納入寫作 review 範圍、False sense of security 是高 stakes 寫作的主要失敗模式、Risk-asymmetric audit standard、colloquial-rhetoric-erodes-technical-precision、prose-self-contained-without-code-reference、regional-terminology-alignment、multi-pass-review-frame-granularity、design-flaw-by-current-axes-not-hindsight、agent-team-context-isolation、decorative-symbols-keyword-bank、teaching-prose-neutral-register。

When to Consult This Skill（觸發路由）

每份 reference 自包含：以該情境為核心，把核心原則翻譯成可直接套用的檢查項與範例。閱讀任一 reference 不需要回來看其他 reference。

Success Criteria（M1-M2 認知負擔類）

詳細量測方式與自評表見 references/meta-metrics.md。M3-M5（token 類）保留未定，待實際範例累積後補足。

跟特化寫作流程的分工

本 skill 是 單篇 寫作的基礎方法、覆蓋 articles / comments / logs / prompts / fields 等 surface。當寫作對象是 跨多章節的教學模組（5+ 章、有案例庫支撐、跨章引用密集）、屬特化情境、有專屬的 跨章節生產流程：案例庫 audit 抽 findings、SSoT 對應規劃、agent team 平行 review、跨檔修正循環、跨章 polish pass。

兩類流程的分工：

兩類流程互補疊加 — 教學模組的每章內部寫作仍套本 skill 6 原則、case 引用段落用 case-citation-three-part-structure、agent team review 用 agent-team-context-isolation。當下游專案沒有跨章節教學模組需求、本 skill 即可獨立運作；當有需求、教學模組生產流程是本 skill 的擴展層、不取代本 skill。

跟 multi-round-review 的協同

寫多篇章節 / report 卡 / knowledge card 後做多輪 agent reviewer audit 時、本 skill 應該跟 multi-round-review skill 同時啟動。觸發詞「多輪審查 / Round 1/2/3 / batch review / 寫作 audit」會同時啟動兩個 skill：

• multi-round-review 規劃 frame 切換結構（Round 1 compliance / Round 2 cadence / Round 3 self-application）跟跨輪 finding 整合工作流
• 本 skill（compositional-writing） 提供每輪 frame 的字句層 keyword bank — Round 1-A 寫作規範 reviewer 必須跑：
  • 正向陳述優先 grep：rg "不[行可是要能該支對符夠必]|無法|沒[做有]|而非|而不是"、加上否定起手定義句（原 pattern 漏「而是」、抓不到「不是 X、而是 Y」的後半）：rg "不是.{0,30}而是|不是.{0,20}、是|與其.{0,20}不如|不只.{0,15}更" — 主要敘述要正向、反例對照的少量負向可保留；判別在「核心概念第一次正面出現在句首、還是被擠到『而是』之後」
  • 口語修辭 grep：rg "其實|實務上|真的|碰巧|立刻撞牆|沒事"
  • 地區用語 grep：rg "集群|默認|質量|視頻|函數|文件夾|接口"
  • 廢話前綴 grep：rg "值得注意的是|需要說明的是|實際上|基本上|事實上"
  • 裝飾符號 grep：rg "✅|❌|⚠️|🚨|🟡|🟢|⭐|📌|✓|✗"
  • 對讀者喊話 grep：rg "很多人|大家|不少人|你天天|你會|你可能|先讀懂|先釐清|別搞混|別被" — 教材中性陳述、不安撫情緒 / 不第二人稱代入 / 不祈使控制閱讀（hook / narrative 段落輕度第二人稱可留）
  • 自評誇飾 grep：rg "教科書級|堪稱|可謂|完美|經典|範本級|大師級|漂亮地|優雅地|最佳實踐|best practice" — 品質 verdict 頂替技術理由、換成機制 / 條件
  • 必然性框架 grep：rg "天生|與生俱來|本質就是|本來就是|必然|唯一|註定|理所當然" — 把設計選擇講成自然法則、還原成條件性（物理 / 法律 / 數學事實除外）
  • 歸因語氣 grep：rg "承認|暴露了|證明了失敗|被迫" — 描述系統行為用「信號」「反映」「顯示」等中性觀測詞、避免「承認」「暴露」等責任歸因詞；「被迫」在描述外部強制約束時可保留
  • 宣導語氣 grep：rg "你可能沒注意|你可能不知道|想像一下|把.{1,5}想成|跑得好好的|聽起來很|其實很簡單|說穿了就是|等於拆未爆彈|乾瞪眼|延遲引爆" — 預設讀者無知或用情緒管理取代事實陳述；讀者是專業人士、直接描述情境與後果
  • 泛用詞濫用 grep：rg "坑|東西|搞|弄|處理一下|情況" — 同一個泛用詞蓋過不同具體情境時、依情境換精確詞（意外 / 陷阱 / 出問題 / 發生狀況）；命中密集且各指不同事才算違規、真泛指 / 引號引用 / 輕度 hook 合規；「坑」另有地區偏移面（某些地區高頻、某些少用）。見 avoid-overused-generic-words
  • 這些 grep 曝光候選、不做自動判定：命中後要不要算違規有品味核心；且 LLM reviewer 跟作者共享文體、同源自審對 register 類（否定起手 / 喊話 / 誇飾 / 概念前置）有結構上限 ——「不是 X、而是 Y」這種 LLM 高頻自產句型最容易全員放水。grep + 同源判定只負責曝光候選、register 層的真防線是文體異源視角（human cold-read 或 prompt 採「挑剔否定起手 / 概念後置」對抗姿態的 reviewer）、同源回報的「clean」不可當真

詳細各維度的判讀規則跟修法、見對應 reference（writing-articles / writing-documents 等）跟 references/principles/ 內的 cadence-homogenization / colloquial-rhetoric / regional-terminology / decorative-symbols / multi-pass-review-frame-granularity 等卡。

協同要點：

• 單獨用 multi-round-review、容易漏字句層 — reviewer prompt 列「規範遵循」但漏 grep 具體 pattern
• 單獨用本 skill、容易漏跨輪 frame 規劃 — 知道要檢查字句層、但缺「Round N+1 用什麼新 frame」結構
• 兩個 skill 一起啟動 — multi-round-review 給結構、本 skill 給每輪的 grep checklist

寫作對象是「單篇 + 完稿前自己 review」時、用本 skill 第 6 原則（多輪 Re-read Pass）的 5 輪 frame 即可；寫作對象是「跨多篇 + agent reviewer 平行 audit」時、multi-round-review 接手結構規劃、本 skill 在 reviewer prompt 內被引用作為檢查清單。

Directory Index

 1compositional-writing/
 2├── SKILL.md                              # 本檔：核心原則速查 + 觸發路由
 3└── references/
 4    ├── writing-code-comments.md          # 情境 1：程式碼註解
 5    ├── writing-documents.md              # 情境 2：文件撰寫
 6    ├── writing-logs.md                   # 情境 3：log 輸出
 7    ├── writing-prompts.md                # 情境 4：prompt 撰寫
 8    ├── writing-articles.md               # 情境 5：完整長篇技術文章
 9    ├── source-to-teaching-analysis.md     # 情境 5a：外部分析材料 → 教學型分析文章
10    ├── translation-review.md             # 情境 5b：文章翻譯 / 轉譯的句內邏輯 review
11    ├── managing-article-collections.md   # 情境 5c：跨多篇文章的結構（三層、素材庫比例、MOC、Pattern 卡片）
12    ├── designing-fields.md               # 情境 6：欄位設計（含六欄位角度總表）
13    ├── designing-fields-ticket-6w.md     # 六欄位詳細範例：正確 + 混淆共 12 項（按需讀取）
14    ├── meta-metrics.md                   # 品質量化驗收（M1-M5）
15    ├── reference-authoring-standards.md  # Skill reference 撰寫品質規範
16    ├── dry-run-guide.md                  # Skill 發布前語意層驗收（Phase 2 dry-run 流程）
17    └── principles/                       # Skill 內部支撐型原則卡（含 terminology / naming / review / case-citation / agent-team 等原則）

Reading Order（建議閱讀順序）

1. 第一次接觸 → 從本 SKILL.md 的「核心支柱 + 核心原則」讀起
2. 進入實際寫作情境 → 依觸發路由讀對應 reference（只讀一份）
3. 想驗證成果 → 讀 meta-metrics.md 做自評

Last Updated: 2026-06-25 Version: 0.18.0 — 輪 9 reader-sim 加第四 lens「AI 歸因過度」（AI 生成內容系統性把通用 pattern 框為 AI 特有、縮窄適用範圍且背上無法證實的舉證負擔；判準：「AI」換成「作者」論點仍成立 → 改通用觀察）；提交自檢清單加第 4 個生成端自問句（AI 歸因測試）。

Version: 0.18.0 — 新增「泛用詞濫用」字句層 frame（讀者回饋觸發：反覆用「坑」把不同情境壓成同一模糊標籤、繁中少用）：keyword bank 加 rg "坑|東西|搞|弄|處理一下|情況"、新增 principle 卡 avoid-overused-generic-words（依情境換精確詞、跟 colloquial/regional/cadence 三卡的軸區分）、writing-articles 輪 8 清單同步；命中密集且各指不同事才違規、真泛指 / 引號 / 輕度 hook 合規 Version: 0.17.0 — keyword bank 新增歸因語氣 grep + 否定起手定義句 pattern；輪 8-10 描述補恐嚇式語氣 / 歸因語氣；移除 comment-qa-hook / worklog-format-check hook（職責已由其他機制覆蓋）；references 更新（atomic-note / teaching-prose / writing-articles / writing-documents）。

Version: 0.16.0 — 從工具 opinion 文章的三輪審查 + 使用者回饋回流 6 張 report 卡（WRAP 分析後選混合方案）：(1) keyword bank 加歸因語氣 grep（承認|暴露了|證明了失敗|被迫）— 唯一有穩定關鍵詞的新 design gap；(2) teaching-prose-neutral-register 加第四類「恐嚇式語氣」（把讀者放在被警告位置、判別線是「你→我們」替換測試）；(3) writing-articles 輪 9 reader-sim 加第三 lens「meta 資訊 vs 內容」（涵蓋 meta-commentary 殘留 + 主題偏移兩個 gap）；(4) writing-articles 提交自檢清單加 3 個生成端自問句（恐嚇式 hook / meta 刪除測試 / 歸因語氣）。不新增 principle 卡（27 張已夠、新議題融入現有卡）、不增 SKILL.md 主體段落（密度飽和、改動集中在 keyword bank 一行 + 下游 reference）。

Last Updated: 2026-06-11 Version: 0.15.0 — 對七張同批 report 卡（#157-#163 主題：語意錨 / 決策表 / 入口分流 / 跨 surface / 摘要模態 / 引用詞彙 / 欄位契約）跑三 reviewer audit 後的回饋：(1) 新增 principle 卡 cadence-homogenization（同時修復 SKILL.md 長期 dangling 的引用）— 六個同骨層實測清單 + 生成端輪替規則 + 「同類 finding 第二次出現升生成端」的升級原則（觸發：上一輪抓過的「判準句同模」在本批復發、擴到 4/7）；(2) 原則 6 surface enumeration 補 description 模態檢查（實測 4/7 份 description 模態漂移、其中一份把同批另一張卡才立的「候選」壓成「證據」）；(3) 原則 6 補批量 sibling 生成端輪替段；(4) 原則 2 補「語意錨單一字串 + 引用他卡用對方詞彙」段（關係宣告 28 條核對抓到 2 條：被引卡沒漏的宣稱成漏、對方的 navigation surface 被轉述成 metadata surface）。

Last Updated: 2026-06-11 Version: 0.14.0 — multi-round review Round 1 的 self-application 修正：兩個 reviewer 從不同 frame 獨立抓到本 skill 自身殘留 count-bearing 名稱（convergence 訊號）。(1) 「Core Pillars（三大支柱）」→「（核心支柱）」、「Six Principles（六大原則速查）」→「Core Principles（核心原則速查）」、「五階段流程」→「case-first 流程」；(2) references 內「五大原則」全改「核心原則」— 這批字串在原則從 5 個長到 6 個之後就已經全部過期（SKILL.md 寫六大、references 寫五大）、是 name-collections-by-role-not-count 卡描述的失效模式在本 skill 的實證；(3) reference-by-semantic-title-not-number 卡的 ISO 邊界限定到版本年份（跨版改版會重編條款）。後續 Round 3 self-application sweep 抓到本條宣稱的漏網（writing-code-comments 的「五大寫作原則」）與另兩處 count 殘留（「五大 surface」「三大正交 axis」）、已一併清除；兩張新 principle 卡依 steelman 補強（#155 卡補「標題改名 vs 編號位移」斷裂等級差、#156 卡補數字記憶價值的誠實對沖與「內部宣告凍結」邊界）。

Last Updated: 2026-06-11 Version: 0.13.0 — 0.12.0 的同日延伸：使用者指出「核心七問」「成長六階段」是另一層問題 — 引用端修好了、但錨點名稱本身內嵌成員數（七 / 六 是 membership 的 derivation）、加一問名稱先失真、所有複製過名稱的地方跟著過期；0.12.0 的原則 2 新段自己就用「見核心七問」當正面範例而未察覺、證明命名端與引用端是獨立檢查維度。(1) 原則 2 補「集合命名用角色、不內嵌數量」段；(2) 新增 principle 卡 name-collections-by-role-not-count（self-contained、含三種可留數字的邊界：外部凍結品牌 / 概念閾值 / 緊鄰清單行內計數、含命名端掃描 regex）；(3) reference-by-semantic-title-not-number 卡補 sibling 連結、0.12.0 三處「核心七問」範例全改「核心問題」；(4) writing-documents Principle 2 補命名端段落。

Last Updated: 2026-06-11 Version: 0.12.0 — 從一份多階段訪談 skill 的階段重編號事故回流：跨檔引用寫成「Stage 3」「Stage 1-3」、流程從四階段改六階段後十多處引用 silent 錯位（字面完好、語意指向錯的階段）、grep 只能抓字面、人工逐處判讀仍漏修兩處。(1) 原則 2（索引建立）補「引用錨點用語意標題、不用位置編號」段 — 編號是結構排列的 derivation、misdirected 比 dangling 難偵測、標題要承載可被引用的語意、凍結編號（RFC / 法條）是 fact 例外；(2) 新增 principle 卡 reference-by-semantic-title-not-number（self-contained、含重排 commit 的引用面掃描 regex）；(3) writing-documents Principle 2 cross-reference 段補同主題小節 + anti-pattern 表加「See Stage 3 指向活文件」列。同一問題第二次出現（v0.9.1 曾修過「Stage 1-5」→「五階段流程」的 portability leak）、符合兩次門檻立卡。

Last Updated: 2026-06-01 Version: 0.11.0 — 從一篇技術教材 review 抽出三類字句層 register/framing 問題回流：(1) keyword bank 加 3 類（對讀者喊話 / 自評誇飾 / 必然性框架）、同步 description、協同段 grep、輪 8-10 段、writing-articles 輪 8；(2) 原則三補「絕對二元語氣的命令式 vs 必然式」subtype（必然式偽裝成事實、更隱形）；(3) 新增 principle 卡 teaching-prose-neutral-register（涵蓋三類、self-contained）；(4) multi-pass-review-frame-granularity 補「偵測之後：keyword bank 命中是候選不是判決」判定層段（偵測 vs 判定兩步驟、clean 可能是判定放水）。跟 multi-round-review Round 1-A 同步加 3 grep + 判定指引。

Last Updated: 2026-05-27 Version: 0.10.0 — 從 13 張 knowledge cards 批量改寫負向表述的經驗回流：(1) description 加觸發詞「多輪審查 / multi-round review / batch review / 寫作 audit / 正向陳述 / 口語修辭 / 字句層 grep」、明示「也在 multi-round-review 啟動時觸發」；(2) 新增「跟 multi-round-review 的協同」段、列出 Round 1-A 寫作規範 reviewer 必須跑的 5 個 grep pattern（正向陳述 / 口語修辭 / 地區用語 / 廢話前綴 / 裝飾符號）、明示兩 skill 垂直協同關係；(3) 修正 multi-round-review 漏抓字句層的盲區、跟 multi-round-review v1.1 同步 cross-trigger 設計 Version: 0.9.2 — 從 business case-analyses 演變回流：新增 source-to-teaching-analysis.md 路由，處理外部分析文章 / 產業評論 / 投資人備忘錄到教學型分析文章的轉換；新增三張 principle（external-analysis-source-layering / cross-domain-reader-level-alignment / analysis-rewrite-delivers-transferable-framework），把 source 分層、跨領域讀者降層、可遷移框架交付從 blog report 抽成 portable 規則。 Version: 0.9.1 — Stage 4 修正 3-reviewer 抓的 33 issue：(1) #120 mirror 縮 scope 解過載（移除四 axis 表 / 句構分流 / polish pass 段、聚焦三段式結構 axis）+ 結論段首改概念定義句解 dogfooding 失敗；(2) #121 mirror 結論表三欄重設計（設計選擇 / 解決問題 / 失敗模式）+ 實作 pattern 縮成 abstract pattern；(3) 兩 mirror 角色段引用點改措辭（移除虛假引用宣告）；(4) SKILL.md 原則 3/6 兩補強段段首改概念定義句、原則 6「詳見」list 補新 mirror、Directory Index 補；(5) Portability leak 修：「Stage 2 自查清單」→「寫稿後段落自查清單」、「Stage 1-5」→「五階段流程」；(6) 五大 / 六大原則 drift 對齊（line 105 / 160）；(7) 既有 principles（writing-multi-pass-review / multi-pass-review-frame-granularity / ease-of-writing-vs-intent-alignment）補回引新 mirror、形成雙向 cross-link Version: 0.9.0 — 從跨章節教學模組生產經驗回流：原則 3 補「Case 引用段落三段式結構」段（詳見 case-citation-three-part-structure）；原則 6 補「Instance 軸：跨 reviewer instance 隔離」段（詳見 agent-team-context-isolation、跟 frame 軸正交可疊加）；新增「跟特化寫作流程的分工」段（明示本 skill 是單篇基礎方法、跨章節教學模組生產流程是擴展層）；principles/ 新增兩張 mirror 卡（case-citation-three-part-structure / agent-team-context-isolation）、自包含、不引用外部 skill 或 blog content Version: 0.8.1 — 第 6 原則同步 writing-articles v0.8.1：補「Production 教學文章追加輪 8-10」段（換工具 / 換視角 / 換層次三機制處理「跑 N 輪仍漏」字句層問題）；「詳見」連結加 5 張新 principle（colloquial-rhetoric / prose-self-contained / regional-terminology / multi-pass-review-frame-granularity / design-flaw-by-current-axes） Version: 0.7.4 — 新增 translation-review.md 路由：翻譯 / 轉譯文章時，用句內邏輯檢查譯名是否跟主詞、動詞、修飾語、因果與讀者追問方向對位。 Version: 0.7.3 — managing-article-collections 補「素材庫比例」路由：多篇文章需要案例 / source / scenario / pattern 支撐時，主文章情境維持少量、素材庫保留 2-3 倍來源做反向驗證 Version: 0.7.2 — 補 multi-pass 的 surface 軸：review 先列 body / metadata / navigation surface（title、description、tags、heading、link label、MOC hook、slug / filename），每輪 frame 都掃同一份 surface 清單；新增內部 principle metadata-surface-in-writing-review.md Version: 0.22.0 — 原則 3 加「知識卡建卡判準用最不熟悉的讀者」；常識是相對於讀者背景的、跨背景讀者群幾乎所有領域特定術語都需要建卡 Version: 0.21.0 — 原則 3 加「操作步驟帶環境專屬工具路徑」（同動作在 container/VM/共享主機的工具不同） Version: 0.20.0 — 原則 3 加「讀者定位聲明」生成端前置步驟；從 infra 模組 retrospective 抽出（讀者定位未預設導致宣導語氣通過三輪審查） Version: 0.19.0 — 新增三張 principle 卡（audience-is-professional-not-layperson / cross-expertise-scenario-not-analogy / management-reportable-info-in-technical-content）、原則 3 加讀者定位與跨專業溝通子原則、keyword bank 加宣導語氣 grep；從 infra 教學模組的寫作 retrospective 抽出 Version: 0.7.0 — Phase B1 結構升級：加第 6 原則「多輪 Re-read Pass」（明示 5 輪 frame）、引用 #83 / #84 / #85 multi-pass 系列。後續 Phase B2 會把各 reference 結尾加「第 2 輪 review checklist」段 Version: 0.6.0 — 從 references 過載的反思：writing-articles.md 從 780 行瘦身到 ~530 行（拆分判準 / 三類 structure 模板搬到 managing-article-collections.md、focus 集中在「單篇文章內部」）；新增規則八「自我應用 (dogfooding)」（教某條規則的段落本身遵守該規則）；managing-article-collections.md 整合「拆分判準」+「三層 structure 詳細對照 + 模板」；meta-metrics.md M2 加 dogfooding 失敗訊號 Version: 0.5.0 — 從批量改寫 35 篇的經驗回流：原則 3 補「選項數由議題決定、不強湊」（避免 A/B/C/D 強迫症與「實務上幾乎不存在」的假反模式）；writing-articles.md 新增規則九（三類文章 structure 模板）；managing-article-collections.md 新增「跨篇引用 idiom 庫」與「三層 structure 對照」 Version: 0.4.0 — 新增 managing-article-collections.md（跨多篇文章結構：三層、MOC、Pattern 卡片）；強化原則 1「原子化」（focus 是議題完整度、不是邊界清晰）；強化原則 3「意圖顯性」（機會成本語氣、不用絕對主義） Version: 0.3.0 — 新增 dry-run-guide.md 於 Directory Index 與觸發路由（Skill 發布前語意層驗收 Phase 2 dry-run）

多輪審查的價值在 frame 切換而非重複加深。三輪用了 8 個不同 frame，每輪抓到的問題類型和上一輪不重疊。停止訊號是「想不出新 frame」而非「finding 數遞減」。

每輪的 frame 和收穫

Round 1：Compliance（規範 + 事實 + 冷讀）

Round 2：Cadence + 讀者旅程 + Title commitment

Round 3：Self-application + Steelman

三輪漏抓鏈：為什麼前一輪漏了

每一輪的遺漏都是因為 frame 的視角限制——同一個 reviewer 用同一個 frame 跑多輪只會重複相同的 catch。多輪的價值在 frame 切換。

你的文章需要多輪審查嗎？

• 品質敏感（教學、規範、長期累積的內容）且篇幅 > 100 行 → 至少 2 輪不同 frame
• 第一輪 finding > 10 → 再加一輪
• 同一批次有 3+ 篇相關文章 → 加跨篇一致性 frame
• 想不出新 frame → 停止

AI 輔助寫作中反覆出現的 pattern

從這次和過去的審查經驗，以下 pattern 在 AI 生成的文章中出現頻率高：

這些 pattern 的防護適合放在生成端（寫作前的 checklist），而非只放在審查端（寫完後掃描）。

技術文章的開頭語氣決定了讀者和作者的關係。恐嚇式語氣（「問題可能正在發生」）把讀者放在「被警告的對象」位置；分享式語氣（「從一個經驗出發討論」）把讀者放在「同行」位置。兩者傳遞相同的資訊，但讀者的接收姿態不同。

案例

兩句話的資訊含量相同（都在說「這篇討論工具設計的某個面向」）。差異在語氣詞：「靜默發生」暗示讀者有問題但不知道，帶有居高臨下的意味；「容易忽略的面向」承認這是普遍現象，不預設讀者有問題。

判斷標準

寫完開頭後問一個問題：如果把「你」換成「我們」，語句是否仍然自然？

• 「可能正在我們的工具中靜默發生」——可以，但語氣變成自我診斷，不像是要嚇別人
• 「從一個經驗出發，討論我們容易忽略的面向」——自然，分享語氣不變

如果換成「我們」後語氣彆扭，代表原句預設了作者和讀者的不對稱——作者知道問題、讀者不知道。技術分享的前提是對稱：我遇到了，你可能也會遇到，我們一起看看。

AI 寫作的傾向

AI 生成的開頭容易偏向恐嚇式，因為訓練資料中大量的技術文章用「你可能不知道的 N 件事」「你一直在犯的 N 個錯誤」作為 hook。這些 hook 在點擊率導向的平台上有效，但在技術社群中會降低信任——讀者會覺得「你在教我做事」。

生成端防護：寫完 hook 後檢查有沒有「正在」「靜默」「不知不覺」「你可能」等暗示讀者無知的措辭。

場景邊界：此判斷標準適用於經驗分享和檢討文章。教學文章的第二人稱指引（「你應該先安裝 X」）屬合理用法——教學的語氣本就是引導式。

文章範圍的泛化（CLI → 工具設計）需要在五個位置同步調整，遺漏任一個都會讓文章的「說的」和「做的」不一致：title、開頭 hook、原則段措辭、對照表範例、結尾 checklist。

漂移軌跡

教訓

案例具體、原則泛化是 work-log 的理想結構：用具體的 CLI 事件作為案例（讀者需要具體故事才能共鳴），但原則段和 checklist 不綁定在案例的技術棧上（讀者需要帶走可遷移的 takeaway）。

泛化時容易遺漏的是中間地帶——title 和 hook 已經泛化，但內文的某句話仍寫著「Opinionated CLI」或「列出你的 CLI 所有參數」。這類殘留在自己反覆讀時不容易發現（因為知道意思），但冷讀者會注意到 title 說「工具設計」而內文只講 CLI。

逐行 grep 原始範圍的關鍵詞（如 CLI、命令列）是最有效的殘留偵測方式。每處命中判斷：是案例引用（保留）還是原則陳述（改泛化）。

這個 pattern 適用於任何「把具體經驗提煉為通用原則」的寫作——技術 blog、內部 postmortem、教學文章。泛化的時機通常在第一輪回饋後，觸發點是讀者說「這不只適用於你的場景」。

當一句話在技術上正確但偏離文章主題時，刪除比保留好。補充內部系統的細節滿足的是作者的完整性需求，不是讀者的理解需求。

案例

修正前的語句在技術上完全正確——規則檔和 memory 系統確實是防線的一部分。但這個補充回答的是「作者的系統有哪些防護層」，而不是「為什麼工具 opinion 重要」。讀者來這篇文章是想知道後者。

判斷流程

對每段補充依序判斷：

1. 主題相關性：這段話回答的是文章標題承諾的問題，還是一個衍生的子問題？
2. 刪除測試：刪掉這段話，讀者對主題的理解會減少嗎？
3. 受眾測試：這段話的受眾是讀者（幫助他理解主題），還是作者（滿足自己的完整性偏好）？

三者任一指向「不服務主題/讀者」→ 刪除。「規則檔和 memory 系統」的補充在三項測試中都指向刪除：它回答的是「作者的系統有哪些防護層」（衍生問題）、刪掉不影響理解、受眾是作者。

延伸

AI 生成的文章容易出現這類偏移——prompt context 中的系統知識會被 AI 當作「相關因此應寫入」。但「推理中相關」和「讀者需要知道」是兩件事。同類問題（AI 把內部推理殘留外露到文章中）的另一面見 reader-does-not-need-to-know。

描述系統行為時，使用「信號」「提醒」「觀測」等中性詞，避免「承認」「暴露」「證明了失敗」等歸因詞。工程上的信號是指向可改善之處的指標，不是對過去決策的道德判定。

案例

兩句話指向相同的行動（評估能否把提醒轉化為工具預設行為），但讀者的接收姿態不同。「承認」讓讀者進入防禦模式（「我的工具沒做錯，文件有文件的用途」）；「信號」讓讀者進入改善模式（「確實，這個文件提醒可以被工具化」）。

判斷標準

寫完一句帶有歸因意味的描述後，問：這句話在描述事實，還是在分配責任？

• 事實：「文件提醒的存在表示工具的預設行為有改善空間」
• 歸因：「文件提醒的存在承認了工具沒做到位」

如果描述的目的是引導讀者改善，用事實語氣。歸因語氣適合事故報告（需要追溯責任），不適合技術分享（目的是傳遞改善思路）。

延伸

同類歸因詞在技術寫作中常見的變體：

文章中的 meta 資訊（「這篇文章的目的是…」「本文邊界是…」「先交代脈絡，否則…」）服務的是作者，不是讀者。讀者打開文章的問題是「這篇文章對我有什麼用」，而非「作者為什麼寫這篇文章」。

案例

案例一：整理目的 blockquote

「整理目的」告訴讀者作者為什麼寫這篇文章。但讀者的問題不是「你為什麼寫」，而是「我為什麼要讀」。兩者的差別：

• 作者視角：「這是一篇反思，不是事件報告」→ 在做分類
• 讀者視角：「讀完這篇我能改善什麼？」→ 在評估投入回報

案例二：脈絡解釋

這句話是寫給自己的編輯註記——「提醒自己為什麼要寫背景段」。讀者不需要知道作者的編輯考量。章節標題（「背景：我們怎麼管理版本和工作項目」）已經告訴讀者接下來是脈絡交代。

判斷標準

寫完一段 meta 描述後問：這段話消失後，讀者的閱讀體驗會變差嗎？

• 「整理目的」消失 → 讀者仍然能從內文判斷這是反思而非報告 → 不會變差 → 刪除
• 「先交代脈絡」消失 → 讀者仍然會讀到脈絡段 → 不會變差 → 刪除
• semver 背景段消失 → 讀者會在事件段卡住 → 會變差 → 保留

meta 資訊的本質是「替讀者做他已經能自己做的事」。讀者能從標題和內文推斷文章類型，不需要作者顯式宣告。

AI 寫作的傾向

AI 生成的文章高頻出現 meta 資訊，因為 AI 的生成過程包含「規劃→組織→寫作」三步，meta 資訊是規劃步驟的殘留——AI 把內部的推理過程（「我接下來要先交代脈絡」）外露到了文章中。

生成端防護：完成初稿後掃描所有 blockquote 和段首句，問「這句在描述內容還是在描述寫作過程？」描述寫作過程的句子刪除。

場景邊界：此判斷適用於短篇分享文。長篇技術文件或 RFC 的 scope 聲明（「本文不討論 X」）有不同作用——幫讀者快速判斷是否繼續讀，屬合理 meta。

文章模板的責任是穩定作者流程，正文的責任是承載技術文章本身。讀者進入文章時，需要看到概念、判讀、取捨與路由；作者在寫作時，需要一組欄位檢查文章是否具備可維護的最低結構。

本 blog 同時由人類作者、Claude Code 與 Codex 協作產生內容。模板若只放在單一 agent 的設定裡，就會形成工具分岔；模板若直接放進 backend 正文，又會把作者工作流暴露成讀者負擔。因此模板的單一真實來源放在 content/posts/，作為本 blog 專屬的寫作設定記錄。

放置決策

模板放置位置的核心判準是讀者與維護者是否一致。backend 文章面向技術讀者，report 面向可重用事後檢討，posts 面向 blog 自身的規範、設計與工具鏈紀錄。

這個分工讓模板同時支援 Claude Code 與 Codex，也保留文章對讀者的自然技術敘事。

模板責任

模板是品質閘門，責任是讓文章保留關鍵判準。它要檢查文章是否具備責任、判讀、風險、邊界與下一步路由，正文仍用技術文章的推導順序排列。

模板欄位可以出現在文章大綱、作者檢查清單或 agent brief 裡。正文要以技術文章方式展開，讓讀者看到推導，作者填表痕跡留在工作流內部。

Backend 技術文章最小模板

Backend 技術文章的最小模板是「概念定位 → 核心判讀 → 判讀訊號 → 風險與邊界 → 交接路由」。這組欄位適合 04 / 06 / 08 這類語言無關的後端能力文章。

 1## 概念定位
 2
 3{概念} 是 {能力 / 流程 / 控制面}，責任是 {它在系統中承擔什麼問題}。
 4
 5這一頁處理的是 {抽象層級}。它跟 {相鄰章節} 的分工是 {邊界}。
 6
 7## 核心判讀
 8
 9判讀 {概念} 時，先看 {第一判準}，再看 {第二判準}。
10
11重點訊號包括：
12
13- {訊號 1}
14- {訊號 2}
15- {訊號 3}
16
17| 判讀面向 | 最小可用判準 | 常見失真 |
18| --- | --- | --- |
19| {面向} | {判準} | {失真} |
20
21## 判讀訊號
22
23- {真實服務中會看到的徵兆}
24- {工程團隊會踩到的操作問題}
25- {事故或演練會暴露的缺口}
26
27## 交接路由
28
29- {上游章節}：{承接內容}
30- {下游章節}：{下一步處理}

這份模板只定義文章最低結構。若某篇文章需要完整案例、方案比較或實作步驟，正文可以增加章節；增加章節時仍要保留責任、判讀、風險與路由。

案例前置欄位

案例前置欄位的責任是讓服務案例能回寫到文章系統。它屬於作者拆案例時的內部欄位，正文只吸收欄位背後的判讀與取捨。

04 / 06 / 08 的案例拆解可共用這組欄位，但正文仍要用技術文章敘事。欄位幫作者維持可比性，文章幫讀者理解機制。

Agent 共用方式

Claude Code 與 Codex 共用模板時，本文是 blog 內的穩定契約。.claude/ 與 .codex/ 可以引用本文的欄位與判準，但實際模板語意以本文為準。

這個安排避免 .claude/ 與 .codex/ 各自演化成不同模板，也避免把 agent 操作細節寫進 backend 讀者正文。

使用邊界

模板適合用在多篇系列文章、跨模組路由與案例回寫。單篇短文、事故紀錄或工具使用筆記可以採較輕的結構，只要仍能說清楚核心責任與下一步。

模板開始主導正文時，需要降級成作者檢查清單。文章完成後的檢查重點是讀者能否理解技術推導，並確認欄位已在文章背後支撐判讀。

完稿檢查

完稿檢查的責任是確認技術文章維持主線。檢查時先看正文是否能獨立閱讀，再看欄位是否完整支撐交接。

• 首段是否先說概念責任
• 判讀訊號是否來自真實服務情境
• 表格項目是否有延伸說明
• 交接路由是否指向具體章節
• 案例欄位是否能回寫到 04 / 06 / 08
• 正文是否保留技術推導，並把欄位轉成讀者可理解的判讀

一般英文中的意思

snippet 原本是「片段」或「摘錄」。

• 可以是一小段文字
• 也可以是程式碼、對話、影像或聲音的片段
• 重點是它是從整體中切出來的一小部分

template 是「模板」或「範本」。

• 表示一個可以反覆套用的格式
• 通常會保留一些空位，等人填入內容
• 重點是「先有結構，再填資料」

skeleton 是「骨架」。

• 表示最基本、最少的框架
• 還沒有完整細節
• 重點是「先把架構立起來」

技術寫作中的意思

在技術文件、程式開發、教學內容裡，這三個詞常常各自負責不同層級的重用。

snippet

通常指短小、可直接插入的內容片段。

• 一小段程式碼
• 一小段設定
• 一小段說明文字
• 一小段固定格式的提醒

它的特徵是短、穩、可重複使用。

template

通常指帶欄位的完整格式。

• 有固定順序
• 有需要填寫的位置
• 適合反覆產生同類內容

它的特徵是完整、可套用、可替換變數。

skeleton

通常指最小可用的結構輪廓。

• 先定大標題與章節
• 細節之後再補
• 常用在草稿、設計、規劃階段

它的特徵是先搭架構，再補內容。

情境式範例

1. snippet 的例子

你在寫信時，常常會重複用到一句固定話術，例如：

請在方便時回覆。

這句話就是一個 snippet。它短、固定、可以直接貼上。

如果你每次都要通知對方資料格式，也可以保留一小段固定內容，例如：

姓名：___

日期：___

這種短段落也屬於 snippet 的概念。

2. template 的例子

如果你要寫一封活動通知，可以先準備一個模板：

1標題：{活動名稱}
2
3時間：{日期}
4地點：{地點}
5對象：{受邀者}
6說明：{補充內容}

這就是 template。

• 結構先固定
• 需要的資料留空
• 每次只要填入不同內容就能使用

3. skeleton 的例子

如果你要先寫一篇文章，但還沒想好內容，可以先畫出骨架：

1# 主題
2
3## 背景
4
5## 問題
6
7## 方法
8
9## 結論

這就是 skeleton。

• 只有章節
• 沒有細節
• 目的是先把文章的基本輪廓立起來

三者比較

直覺分辨法

如果要用最簡單的方式分辨：

• snippet 是「拿來貼的短段」
• template 是「拿來填的格式」
• skeleton 是「拿來搭的骨架」

也可以這樣記：

• snippet 解決「每次都要重寫同一句」
• template 解決「每次都要重建同一種格式」
• skeleton 解決「先把架構搭起來，再慢慢補細節」

什麼時候用哪一個

• 想重用短句或固定提醒時，用 snippet
• 想重複產生同類文件或表單時，用 template
• 想先把內容架構起來、還沒準備好細節時，用 skeleton

結論

這三個詞都可以翻成「片段」或「範本」的近義概念，但在技術寫作裡，它們的分工很清楚：

• snippet 偏短，重點是可直接重用
• template 偏完整，重點是可套用的格式
• skeleton 偏框架，重點是先有架構再補細節