案例引用深度是寫作層的紀律工具：把 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 紀律補回來、修法成本極低。

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 寫教學內容的系統性傾向。

服務型教材需要貫穿式案例作為教學骨架。資料庫、快取、queue、觀測、部署、可靠性、資安、事故與容量都可以獨立成章，但讀者真正需要學會的是這些能力如何在同一個服務裡交接、互相約束並共同演進。

貫穿式案例是一條可重播的服務演進路徑，而非單一大型專案手冊。它用同一個中性服務情境反覆穿過多個模組，讓讀者看到每個模組處理的是同一個系統在不同壓力下的責任切面。

WARP 分析摘要

反向驗證：貫穿式案例要維持中性、簡化、可替換，並明示它是教學載體；讀者理解案例所需的背景要由文章提供，而非內部專案知識。

情境

Backend 已有多篇服務路徑示範，例如 schema migration evidence、cache migration rollback、queue retry replay、checkout API evidence package、release gate、credential rotation 與 incident decision log。這些文章各自能說明一段能力，但它們在入口層還沒有被明確收斂成一條「讀者可以跟著走」的服務演進路線。

對照 Go 與 LLM：

Backend 的內容特性更需要貫穿式案例，因為它處理的是多個外部服務的協作教材，範圍大於單一語言或單一工具。

理想做法

第一步：選一個中性服務作為載體

貫穿式案例應該選讀者容易理解、又能自然觸發多個 Backend 模組的服務。較穩定的候選是 checkout / order / payment / notification 類流程。

這條服務路徑可承接：

第二步：把案例拆成多個可重播 episode

貫穿式案例要避免寫成一篇巨文。較穩定的做法是拆成 episode，每個 episode 對應一個模組責任。

Episode 讓讀者看到「同一服務在不同壓力下需要不同模組」，同時保留單篇文章的原子性。

第三步：讓每章都回到同一條服務路徑

每篇主章不需要都重述整個案例，但要能指出它在貫穿案例中的位置。這樣讀者可從任一章回到主線，也可按主線依序讀。

最小寫法：

1本章在貫穿式 checkout 案例中處理 E3：訂單事件 consumer 失敗後，如何判斷投遞、處理與恢復語意。

這句話把章節放回教學骨架，避免單章漂成孤立知識點。

沒這樣做的麻煩

章節各自正確，但整體難學

資料庫、快取、queue、觀測與事故章節都可以各自寫得正確。讀者看過它們如何在同一條服務路徑交接後，平行知識才會組成 production system 的整體模型。

案例庫會停在素材層

大量 case 能支撐反向驗證，但 case 本身不會自動形成學習路線。貫穿式案例的責任是把素材庫轉成讀者可重播的主情境。

Vendor / migration 內容會太早成為主角

讀者在還沒理解服務交接前讀 vendor 或 migration，容易把具體工具當成主線。貫穿式案例能先建立「問題如何跨模組流動」，再讓 vendor / migration 成為進階專題。

跟其他抽象層原則的關係

判讀徵兆

核心原則：服務型教材要有貫穿式案例。能力分類讓作者整理內容，讀者旅程讓讀者知道怎麼讀，貫穿式案例讓讀者看到多個能力如何在同一個 production service 中交接與演進。

案例庫主軸跟章節主題不在同一維度時、引用框架要從「正向掛入」切換到「反向追問」。正向掛入適用於「案例直接示範章節主題」、反向追問適用於「案例庫主軸是 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。

寫教學文章時、純靠 LLM 自生內容會踩到兩個系統性盲點：

1. Scope 盲點：內容停在「教科書級」結構、漏掉真實事故才會浮現的失敗模式跟設計取捨。
2. 準確性盲點：把通用 best practice 包裝成「[case] 揭露」、把案例沒講的細節寫成案例事實。

本文整理在 backend/01 至 backend/07 batch 1 七個模組撰寫過程中浮現的五階段流程：

1. 完整閱讀案例庫、抽 findings — 用案例驅動「該寫什麼」、不只是 LLM 自生
2. 基於 findings 建立內容 — findings 分布到章節、避免硬塞模板
3. Agent team 平行多輪審查 — 用 3 個專責 reviewer 補 LLM 自盲點
4. 修正循環 — 按檔案批次修 high + 重要 medium、reviewer 抓出問題各章節對應修
5. Polish pass — 跨檔系統性 pattern 集中處理（負向骨架掃描、編號漂移、用語不一、cross-link 補漏）

實作數據：7 個模組（backend/01-07 batch 1）、~45 章 / 385 個 review issue、case fidelity 落在 70-93% 區間、修正後品質升至 0 critical 編造、cross-link 全綠、規範違反 polish pass 後降到單位數低 issue。06 模組後方法論工具化為可觸發 skill、stage 1-5 流程跟 reviewer prompt template、self-scan regex 都封裝成可重用元件。07 模組驗證下「章節已有 routing layer skeleton」的特殊處理（在現有結構內補 case-driven 深化段、不擴成厚重章節）。

問題：LLM 自生內容的兩個盲點

純靠 LLM 寫教學章節、容易產出兩種品質風險：

Scope 盲點：LLM 從訓練資料抽出的內容偏 普遍性、是「教科書 + 部落格 + 文件」的綜合。但真實工程議題的判讀條件常常來自 特定事故揭露、不是普遍知識。例：

• 「DynamoDB GSI 在 backfill 完成前查不到完整資料」這種具體陷阱
• 「Super Bowl +50% no sweat 的工程意義是 headroom 提前預留、不是 vendor 神奇」這種反直覺判讀
• 「99.99% → 99.999% 是指數成本、遠超直覺的 10x 線性想像」這種規模對照

純技術知識推導不出來、要看真實案例才會浮現。

準確性盲點：LLM 寫到「對應 [case]」時、容易把通用 best practice 包裝成案例事實、或把案例沒提到的細節擴寫成「案例揭露」。例（從本文討論的實作中抓出的真實 issue）：

• Snowflake 案例描述「異常查詢偵測維度（query 體積 / IP / 跨 schema scan）」、LLM 自生內容寫成「query 體積從 1MB / 天跳到 10GB / 天、來源 IP 從 office network 變 unknown VPS」— 具體數字是 LLM 加上去的、案例沒寫
• Tixcraft 案例策略段建議「composite key」、LLM 自生內容寫成「Tixcraft 用 user_id 分散、不是 event_id」— 案例沒揭露 Tixcraft 實際 partition key 設計

這兩類盲點都不容易在 self-review 時抓到、因為 LLM 看不出自己內容是否真的對應案例。

階段 1：完整閱讀案例庫、抽 findings

為什麼要完整閱讀、不能只看 title + description

只看 title + description 能做 承接（建立 link）、但無法做 scope 擴展（揭露 LLM 不會自生的議題）。case 的 findings 通常埋在 body 的「判讀」段、不在 description 裡。

實作中的對照：第一輪 audit 6 個 case、每 case 平均揭露 2.3 個 finding；其中約 7 成是 description 跟 title 看不到、要讀完整 body 才能抽出。例如 DraftKings 案例的「讀寫雙峰錯位」（比賽中讀爆量、payout 時寫爆量）— description 只說「financial ledger」、要讀「核心負載形狀」段才看到雙峰結構。

邊際遞減的判斷

不是所有 case 都要讀。實作中觀察到的遞減曲線：

第三輪開始 純新議題 比例下降、重複 frame 出現（vendor dogfood 在 3 個 case 都揭露、benchmark 對照基準在 3 個 case 都揭露）。這是停止 audit 的訊號。

判讀條件：

• 繼續 audit：每 case 至少 1.5 個純新議題、且重複 frame 不超過 30%
• 停止 audit：純新議題 < 1 個 / case、重複 frame > 50%、累積 finding 數已涵蓋目標章節主要議題

實作中 11/94 cases（~12%）時邊際遞減訊號明顯、16/94 cases（~17%）時停止 audit、抽出 ~42 個 unique findings、足以支撐 6 個章節的 scope 擴展。

Findings 抽取方法

讀 case 時、把每個段落看成可能的 finding 來源、問三個問題：

1. 這段揭露什麼判讀條件？（是不是純技術推導不易浮現的議題）
2. 這段揭露什麼數字 / 設計細節？（規模、percentile、partition key 數量、replication lag 量級）
3. 這段揭露什麼失敗模式？（事故當下會出什麼問題、有什麼反直覺結論）

寫進 findings 列表時、要附上 case 來源 跟 該對應到哪個章節。例：

Finding: 線性擴展是 OLTP 設計最高目標、coordinator 是傳統 OLTP 的擴展瓶頸 來源: 9.C10 Spanner 案例「2 nodes → 45K reads/sec, 4 nodes → 90K reads/sec」段 章節: 1.11 全球分散式 OLTP

不寫來源跟章節定位、findings 會變成抽象列表、寫稿時用不上。

Case 類型的承接策略

不同 case 類型適合不同承接深度、誤判類型會引發 over-extrapolation 問題。實作中觀察到的兩類 case：

Rich case（典型：09/07 案例庫中含具體數字、設計細節、遷移路徑的長篇 case）：

• 內容深度：50-200 行、含具體數字、業務情境、引用源
• 承接方式：可直接引用為事實、case 揭露的具體數字（RPS、延遲、TPS、stale window）可放進章節
• 例：9.C5 Amazon Ads「90M RPS + 5M writes/sec + 99.999%」可直接寫進 1.10 KV 章節
• 例：9.C6 Tinder「4700 萬 MAU 配對引擎、cache 是主要服務面」可直接做為 2.1 high-concurrency 的判讀依據

Medium case（06 模組新發現的類別、典型：模組內部 case 庫中含結構化「決策機制」+「可觀測訊號」表、但無具體數字的中篇 case）：

• 內容深度：30-50 行、結構化 5 段（問題場景 / 決策機制 / 可觀測訊號 / 常見陷阱 / 下一步路由）、含 mechanism + 訊號名稱、但不給具體數字
• 承接方式：用 case 直接列出的 mechanism 名稱 精準引用、比 skeleton 精準、但比 rich 保守
• 承接句型：「對應 [case]：揭露 N 個機制 — A、B、C、D」
• 例：6.C1 Amazon Shuffle Sharding 揭露 cell boundary / shuffle sharding / static stability / constant work 四機制、可直接引用機制名稱、但不擴寫到「具體 shard 數量」「具體 cell 大小」等 case 沒提的實作細節

Skeleton case（典型：模組內部 N.Cx 案例庫中只有 frame、無具體數字的短篇 case）：

• 內容深度：10-30 行、只給方向、無具體數字 / taxonomy
• 承接方式：作為「視角 / 方向」、可引用為「case 揭露 X 議題」、但不引用為「case 揭露 X 具體場景數量」
• 例：2.C1 Meta Cache Consistency 只有「promotion、shard move、故障恢復」三個方向、不引用為「具體 inconsistency window 數字」
• 例：3.C9 反例只給「依賴特定 offset / 重試節奏 / idempotency」三個方向、不引用為「4 個具體誤配場景」

判讀條件：

• 看 case 行數 + 內容密度判斷類型
• skeleton case 的 finding 寫成「對應 [case] — 揭露 X 方向、以下展開基於通用工程知識補充」
• medium case 的 finding 寫成「對應 [case]：揭露 N 個機制 — A、B、C、D」、用 mechanism 名稱精準引用
• rich case 的 finding 可寫「對應 [case] — XXX 具體數字 / 設計」

實作中（01/02/03 三個模組驗證）、skeleton case 寫成 rich case 對應是 case fidelity reviewer 抓出 over-extrapolation 的主要來源（02 / 03 各 3-4 個 critical 編造都來自此陷阱）。誤判類型 → 編造 case 沒寫的細節 → reviewer 抓出 → 修正成本高。stage 1 抽 findings 時就要 標明 case 類型、stage 2 寫作時依類型決定承接深度。

Rich case 引用的反向風險（04/05 模組新發現）：rich case 雖然可以引用具體數字、但 case 內常含「觀察層」（具體 fact）跟「判讀層」（作者推論）兩段、引用時要分開處理。05 模組驗證時 case fidelity reviewer 抓出 4 個 high issue 都來自把「判讀層作者推論」寫成「case 揭露的 fact」：

• 9.C12 Riot Games：5.2 寫「揭露 35ms latency 反推 region 部署」、實際 case 的「35ms」是觀察層、「反推 region 部署」是作者判讀層
• 9.C34 GCP 130K：5.2 寫「揭露 Spanner 替 etcd 才是 K8s 規模極限的關鍵」、實際 case 用更保守的「control plane 極限取決於 storage backend、GCP 用 Spanner 替換 etcd」分兩個點寫
• 9.C12 Riot：5.2 引用「single-tenant per game 的多 cluster 策略」、漏掉 case 揭露的關鍵歷史轉折「從 multi-tenant cluster 模型改成 single-tenant per game」

修法：rich case 引用時、用「揭露 X 觀察 + 作者判讀 Y」分層標明、避免把推論寫成 fact。或在引用後補一句「（case 中 X 屬作者判讀層、本章引用此推論）」明示分層。

兩類 case 的引用紀律可總結成一個 fact vs derive 分層原則：

• Skeleton case：絕大多數內容是 derive（方向 / 議題）、引用時不擴寫成 fact
• Rich case：含 fact（具體數字 / 設計）跟 derive（作者判讀）、引用時分層標明、避免把 derive 升級成 fact

階段 2：基於 findings 建立內容

Findings 分布到章節

抽完 findings 後、按章節主題分類、看哪個章節缺口最大、哪個 finding 該寫去哪。實作中的分布：

• 1.1 高併發：7 findings
• 1.5 紅隊：8 findings
• 1.9 reconciliation：4 findings
• 1.10 KV：6 findings
• 1.11 全球分散式：10 findings（最大缺口）
• 1.6+1.12 migration：5 findings

涉及多軸取捨的章節（1.11 一致性 / 可用性 / 成本 / 延遲）暴露最多缺口、純流程章節（1.9）暴露最少。這是 章節結構性質 的差異、不是寫得好壞。

Stage 2 寫作前先定 SSoT 對應

當同一 finding 或 frame 在 多個章節 都有用、要在開始寫之前 先定 SSoT 對應、否則 case-driven 擴章必然出現 frame 重複展開。

實作中觀察到的反例（02 / 03 模組都遇到過）：

• 02 cache：「cache 角色變化」frame 在 2.1 主寫但實際屬模組層級、應在 _index；Tubi 案例在 2.1 / 2.2 / 2.8 三章各自展開 mini-finding；Snap KeyDB 在 2.1 / 2.7 / 2.8 三章重複
• 03 message-queue（最嚴重）：「三層語意（delivery / processing / recovery）」在 3.4 / 3.6 / 3.8 三章各自定義；「Slack Kafka+Redis 拓樸」在 3.4 跟 3.8 兩章逐字重複；「規模對照（小 / 中 / 大型）」在 3.4 / 3.6 / 3.8 三章拆用、結論散落讀者拼不出總圖

SSoT 對應的判讀順序：

1. 列出所有 cross-chapter findings（出現在多章的 frame）
2. 每個 frame 指定 一個 主寫章節（SSoT）
3. 其他章節 只 link、不展開
4. SSoT 章節要有完整論述、被引用章節保留簡述跟 cross-link

SSoT 選擇標準：

• frame 涉及 跨模組層級概念 → 寫進 _index.md
• frame 涉及 單章核心責任 → SSoT 為該章
• frame 涉及 跨章交接點 → 選最相關章節為 SSoT、其他章節 link

漏掉這步、reviewer 跨章一致性會抓出 5-10 個 frame 重複 issue、修正成本高（要把已展開內容收斂回 SSoT）。Stage 2 前花 30 分鐘做 SSoT 對應、能省下 Stage 3 數小時的重構工。

避免硬塞模板

最大的反模式是把多個 findings 硬塞成同一個 table、每 row 一短語、失去情境敘事。

實作中的反例：1.9 章新增「Dual-track IC 5 個角色表」、本來想用表格整齊呈現、但 reviewer 抓出「5 角色平鋪、責任只一行、未展開每角色在真實事故的決策樣態」。修正後拆成：

• 主表格（5 個角色快速對照）
• Overall IC 跟 Tech IC 的差異獨立段（300 字）
• Data IC 的特殊角色獨立段（300 字、含「為什麼不能讓 Tech IC 兼任」的失誤對照）
• 事先準備 4 項各自延伸（不只列項目、解釋失效樣態）

這樣 每個項目都是情境 而非 硬塞的欄位、符合 AGENTS.md「表格不是終點」原則。

情境敘事的判讀條件

每段內容寫完後、問三個檢查問題：

1. 首句是不是核心原則？（不是「某 case 揭露 X」、是「X 是什麼、承擔什麼責任」）
2. 是不是用否定句主導？（「不是 X」「不只 X」開段要回到正向陳述）
3. 這個 finding 在不同情境下是否會變義？（一個 finding 套到多個情境、要分情境寫、不是套同模板）

案例引用的準確性

寫「對應 [case] — XXX」時、要回 case 原文驗證 XXX 是否真的出現。實作中常見的失分：

• 把 case 沒提到的數字補進去（「30-90 天 baseline」、「1MB→10GB / 天」）
• 把通用 best practice 寫成案例事實（「Snowflake 之後改為預設強制 MFA」— case 只說「資料平台應預設強制 MFA」、不是描述後續行動）
• 公開事實但 case 沒寫（「MOVEit 跨上百家客戶」、「LastPass master password 弱可被離線爆破」）

寫稿當下不容易抓、要靠階段 3 的 case fidelity reviewer 對照。

階段 3：Agent team 平行多輪審查

為什麼要 agent team、不能交給單一 reviewer

單一 reviewer 有兩個限制：

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

解法是用 3 個專責 reviewer、平行 background 跑、各自獨立報告、主 context 只看精煉摘要。

三個維度 reviewer 分工

實作中使用的三個 reviewer：

Reviewer A：寫作規範審查（AGENTS.md 核心原則）

• 對照核心原則先行、正向陳述優先、商業邏輯先於 case、表格不是終點、情境優先於模板、可操作判準等八原則
• 找首句用否定句切入、表格 / bullet 平鋪沒延伸、表格項硬塞模板等
• 實作中抓出 25 個 issue

Reviewer B：案例引用準確性

• 對照原始 case 內容、驗證「對應 [case] — XXX」斷言是否真的來自案例
• 識別編造數字、過度推論、把通用 best practice 寫成案例事實
• 實作中抓出 9 個 issue、包含 3 個 critical 編造

Reviewer C：跨章一致性

• 跨多章找重複 frame、矛盾說法、失效 cross-link、章節邊界錯位
• 識別「該在 A 章卻寫在 B 章」、「frame 重複展開沒整併」
• 實作中抓出 13 個 issue

平行 background 跑、不佔主 context

關鍵設計是 3 個 reviewer 並行、各自 background、各自寫 output file、不污染主 context：

• 主 context 只看到「啟動 reviewer」跟「reviewer 完成的彙整報告」
• Raw output 跟 reviewer 的 deep dive 留在 output file、需要時 SendMessage 繼續對話
• 3 個 reviewer 完成時間 ~5-15 分鐘、可以同時跑、不必等

實作中 3 個 reviewer 平均 2-3 分鐘完成、主 context 增量 ~3K tokens（彙整 + 47 issue 清單）、相比把所有案例跟章節塞進主 context 做 review 節省 ~80% context。

Reviewer issue 數量的 baseline

7 個模組（01 / 02 / 03 / 04 / 05 / 06 / 07 batch 1）驗證後、每模組 reviewer 抓到的 issue 數量在 standards reviewer 抓 pattern 越來越細的趨勢下持續擴大、可作為流程預期：

模式觀察：

• 每模組 issue 數隨 standards reviewer 抓 pattern 越來越細而擴大：01-03 穩定在 47-55、04/05 推到 51-59、06 推到 71、07 batch 1 回到 52（章節已有 routing skeleton、擴章規模小）。趨勢來自 standards reviewer 抓的 pattern 越來越廣（從負向骨架 → 「核心責任不是」變體 → 「沒有 X 會 Y」鏈式 → 「case 引用段首」框架 → 「case 引用句構同質化」）。
• Case fidelity 準確率分布更廣：04 的 92.9% 來自 skeleton case 嚴守「揭露方向、通用補充」紀律；05 的 80% 因引用 09 rich case 加入「fact vs derive 分層」新失分模式；06 的 88% 屬 medium case 紀律首次套用、揭露「實作層擴寫過頭」失分；07 batch 1 的 81% 揭露「跨 case 合成 frame」新失分類型（reviewer B 2 high 都屬此類）
• Consistency reviewer 抓到的 frame 重複跟章節數成正比：02 / 03 / 04 都有 ~13-18 個一致性 issue、05/06 跨模組 cross-link 密度高仍維持在 baseline 內、07 batch 1 因 7 章規模、issue 13 個落在 baseline 下緣

Stage 3 修正成本估算：

• Critical（編造、矛盾）：~每個 5-10 分鐘修正、佔 0-5 個（04/05 都 0 critical、紀律已成熟）
• High（重複 frame、章節邊界、判讀層 vs fact）：~每個 10-20 分鐘修正、佔 5-14 個
• Medium / Low（規範細節、cross-link 補）：~每個 2-5 分鐘修正、佔 35-45 個
• 總計 ~1.5-2.5 小時 / 模組

Stage 4 修正後仍會有 ~30-40% issue 殘留（low / medium 的 cross-link、編號漂移、用語不一）、屬於系統性 pattern、適合在 Stage 5 polish pass 集中處理（見後段）。

為何要多輪 review、不是一次到位

第一輪 review 的目的是 找問題、不是 修問題。問題清單列出後、要做兩件事：

1. 分類優先序：critical / high / medium / low、按嚴重度跟修改成本排序
2. 修正循環：批次修正、避免一個一個改散開、修完再跑驗證

修正後可選擇性做第二輪 review、檢查：

• 修正本身有沒有引入新問題
• 之前 reviewer 漏掉的維度（例：教學性、讀者路徑、實作可行性）
• 跨 commit 一致性

實作中第一輪足夠處理 47 個 issue、第二輪沒進行、留到未來模組（02 cache、03 message queue）累積經驗後再評估是否必要。

修正循環的執行原則

47 個 issue 分布到 6 個章節、修正時 按檔案批次、不是按 issue 編號順序。每個檔案一次修完所有相關 issue、減少切換成本：

• 1.5 紅隊章（12 issue）：含 2 個 critical 編造、優先處理
• 1.10 KV（7 issue）：含 1 個 critical 編造
• 1.11 全球分散式（5 issue）
• 1.12 大規模遷移（10 issue）：表格密度最高、最多延伸
• 1.1 高併發（4 issue）
• 1.9 reconciliation（5 issue）

每個檔案修完後跑一次 mdtools fmt --fix + mdtools cards + mdtools lint、確認該檔內部一致、再進下一檔。最後跑一次跨檔驗證、確認 cross-link 全部對齊。

階段 5：Polish pass（04/05 模組後新增）

Stage 4 修完 high + 重要 medium 後、仍有 ~30-40% 的 low / medium 殘留、屬於系統性 pattern（負向骨架、編號漂移、cross-link 缺漏、模板化）。這些 issue 不適合按章節批次修、適合用「跨檔系統性掃描」處理 — 這是 polish pass 的核心責任。

Polish pass 的觸發條件

Stage 4 後出現以下任一訊號、就該排 polish pass：

• Standards reviewer 抓出的「不是 X、而是 Y」段首結構超過 5 處（屬寫作習慣、單章修改無效率）
• Consistency reviewer 抓出「編號漂移」「失效 link」「用語不一」多處（屬跨檔規範問題）
• 自掃描漏掉的 pattern 出現在 reviewer report（例：04 自掃描說 pass、reviewer A 抓出 31 個 issue、暴露自掃描 regex 不夠寬）

Polish pass 不該做的事

• 不重寫章節結構：polish pass 是把現有內容修得更貼合規範、不是重新組織。重寫的觸發條件應該回到 stage 2、不是 polish pass。
• 不擴大 scope：原本 4.20 / 5.4 等不在擴充範圍的章節、polish pass 也不動。Polish pass 邊界 = stage 4 修改過的章節集合。
• 不追求 0 issue：reviewer 抓的 ~15 個 low 通常可保留為下次擴章節時自然處理。Polish pass 處理「系統性 pattern」、不處理「孤立 issue」。

Polish pass 的標準工序

按系統性 pattern 分批處理、每批跑一次自掃描確認：

1. 負向骨架掃描修正：用更寬泛的 regex 不是 |而不是|沒有.*[，、]會 掃描、把「不是 X、而是 Y」「而不是 X」改成正向陳述 + 後置邊界提醒。技術約束敘述（「多人共用 IP 無法區分」）保留。
2. 編號漂移統一：把 04.X 風格 plain text 改成 [4.X title](url) markdown link、跟 _index 對齊。
3. 表格延伸段補強（關鍵段）：選 2-3 個最高 impact 表格（判讀訊號表的爭議列、Buffer / Sampling 等選型表）補延伸子段、不全部補（避免擴展超出 scope）。
4. 模板化拆敘事（代表性段）：選 1-2 個最明顯的「四步驟模板套不同情境」段、拆成情境化敘事、其他保留為下次。
5. Cross-link 補漏 + ownership 邊界補強：reviewer C 報告的所有 cross-link 缺漏一次補完、用同一個批次跑 mdtools 驗證。
6. 用語不一統一 + 失效 link 修正：簡轉繁、/knowledge-cards/ vs /section/ URL 統一、失效 link 改規劃中或正確路徑。
7. 最終驗證 + commit：跑 mdtools fmt --fix && mdtools cards && mdtools lint、確認全綠、commit。

Polish pass 的實作成本

實作中（04 / 05 polish pass 合併 commit 1072087）：

• 處理範圍：11 個檔案、+44 / -29 行
• 修正項目：~35 個 issue（10 個負向骨架、2 個模板化、3 個編號漂移、3 個表格延伸段、3 個 cross-link、1 個 case 引用結構）
• 時間：~30-45 分鐘（不重寫、只 pattern match）
• 剩餘 ~15 個 low 保留下次

Polish pass 的 ROI 來自「系統性 pattern 一次處理 vs 散在各章一個個改」的效率差異。每個 pattern 在多章重複出現時、用 grep / rg 跨檔修一輪比每章單獨修快 3-5 倍。

自掃描盲點更新

04 流程暴露了一個 self-scan 盲點：原 regex 不行|不可以|不要|無法|不能 漏掉「核心責任不是 X、而是 Y」這個變體段首。修正建議：

• 加 ^[^|].*責任(不是|並非) 抓「核心責任不是 X」變體
• 加 ^[^|].*[，,]而是 抓「X、而是 Y」結構（已是正常陳述、但段首位置仍是負向骨架）
• 加 ^[^|].*[，,]不是 抓「X、不是 Y」結構

把自掃描 regex 視為持續演進的工具、每個 reviewer 抓出新 pattern 就更新一次、避免在下個模組重蹈覆轍。

適用情境跟限制

適用情境

• 長期累積的教學模組：6+ 章、跨章引用密集、規範遵循重要
• 有現成 case 庫：07/09 累積的 100+ 案例是這套流程的前提、沒案例庫做不到 case-first
• 品質高於速度：完整三階段約 3-4 小時 / 模組（stage 2 寫作 ~1.5-2hr + reviewer ~15 分鐘 + stage 3 修正 ~1.5-2hr）、適合長期累積的內容、不適合 one-off 文章
• 主 context 容量敏感：reviewer 平行 background 是節省 context 的關鍵設計

不適用情境

• 新主題沒案例庫：要先建案例庫、不能直接套這流程
• 單篇短文：流程的固定成本（讀案例 + 跑 reviewer）對短文 ROI 低
• 快速迭代原型：流程偏向 寫一次寫好、不是 快速修改
• Routing layer / 導讀性質章節：已含完整 threat scope + 引用標準 + 問題節點表、case 庫不對應或缺位、應跳過本流程、用標準引用 + 通用工程知識補充承接（07 LLM / 治理章節驗證）
• Standard framework 比 case 庫成熟的領域：見下段「Standard-driven 取代 case-driven」

Standard-driven 取代 case-driven（07 LLM 章節驗證）

在標準框架比 case 庫成熟的領域、case-driven 不是預設選擇。LLM 安全章節跑完 5 章驗證後浮現一個 finding：當該領域的 標準框架（如 OWASP LLM Top 10 2025 / NIST AI RMF 1.0 / MITRE ATLAS）已涵蓋 threat 分類、且 case 維護半衰期短於 standard、章節應 用 standard-driven 取代 case-driven。Standard-driven 跟 case-driven 是平行選項、依領域特性選用 — 兩者沒有退化 / 進階關係。

判斷該用哪種策略的四維度：

典型對照：

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

Standard-driven 章節的寫作策略：

1. 章節對齊 standard framework 分類：用 framework 章節 ID 標明（如 OWASP LLM01 / NIST AI-1.1）取代「對應 [case] —」斷言
2. 加 Last reviewed cadence：每 quarter 重評估 standard 版本跟章節對應、寫進 frontmatter
3. 「案例觸發參考」段標明「公開案例累積中、值得追蹤的方向」：不寫「對應 [case] 揭露」斷言、避免引用源不穩定
4. 引用標準時用版本號：OWASP LLM Top 10 2025 / NIST AI RMF 1.0 / MITRE ATLAS continuous — framework 改版要 trigger 章節重審

實證：07 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 推論順序敏感）、不停在教科書級內容。

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

• 該領域累積 5+ 個高可信度 case（vendor disclosure + academic paper + CVE 三來源交叉）
• 跨章 frame 重複出現、case-driven mechanism 深化能解 SSoT 衝突
• 出現「等級類似 SolarWinds」的 incident、案例本身夠重、單一 case 即可支撐章節擴章
• 讀者反饋章節太抽象、需要具體 case 才能理解 mechanism

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

對 case-first-module-workflow skill 的補強：

skill 之前的「不適用情境」寫「沒 case 庫的新主題（要先建 case 庫）」— 這暗示缺 case 庫一定要先補。07 LLM 章節驗證了第三條路：用 standard-driven 取代、適用 standard framework 比 case 庫成熟的領域。這個 finding 已補進 skill 的「不適用情境」段。

限制

• Reviewer 維度有限：當前 3 個 reviewer 沒覆蓋「教學性」「讀者路徑」「實作可行性」、若主題需要這些維度、要加 reviewer
• 修正可能引入新 issue：第一輪 review 後修正、修正本身可能違反規範、若大量修正最好做第二輪
• Case 庫品質決定 findings 品質：case 寫得淺、findings 也淺；case fidelity reviewer 也只能驗證「跟 case 一致」、不能驗證「case 本身對不對」
• 依賴 LLM agent 平台能力：流程預設可平行跑 background agent、不是所有 LLM 平台都支援

7 個模組驗證後的反覆陷阱

01 / 02 / 03 / 04 / 05 / 06 / 07 七個模組執行下來、以下陷阱在 多數模組都重複出現、屬於 LLM case-driven 寫作的系統性失分點。本流程下次套用前要 主動防範、不能依賴 stage 3 reviewer 補救（雖然 reviewer 都會抓到、但修正成本高）。

陷阱 1：Skeleton case 擴寫成 case 事實

當 case 內容簡短（10-30 行、只有 frame 沒有具體數字 / taxonomy）、LLM 寫作時容易把通用知識（具體數字、攻擊向量列表、設計細節）寫成「對應 [case] —」斷言。實際 case 沒寫的。

實證：

• 01 紅隊：Snowflake「30-90 天 baseline」編造、Tixcraft「partition key 用 user_id」編造
• 02 cache：Tubi 三層 cache 具體 latency（L1 < 1ms、L2 < 10ms、L3 10-100ms）編造、Redis「100K-200K ops/sec」無來源、KeyDB「5-10x throughput」其實是 case 判讀段非引用源
• 03 messaging：PayPay「broker 寫入 3K msg/sec」實際 case 寫的是「DynamoDB 寫入 3K msg/sec」（PayPay 用 DynamoDB 不是傳統 broker）、3.C9 case 三個方向被擴寫成「4 個誤配場景」、3.C10 case 「大型服務 DLQ 是診斷入口」完全編造

防範：

• Stage 1 抽 findings 時 標明 case 類型（rich vs skeleton）
• Stage 2 寫 skeleton case finding 時、用「對應 [case] — 揭露 X 方向、以下展開基於通用工程知識補充」這種 fact vs derive 標記
• 不要為了「整齊的 4 個攻擊面」「3 個攻擊向量」「5 個誤配場景」這種數字感、把 case 沒寫的 taxonomy 寫成 case 揭露

陷阱 2：Frame 重複展開（SSoT 不清）

同一概念在多章 case-driven 擴章時各自展開、形成 frame 重複。讀者跨章讀會踩到重述、結論散落拼不出總圖。

實證：

• 01：容量三口徑 frame 在 1.1 跟 1.12 重複展開、storage / compute 分離 frame 在 1.1 跟 1.11 重複
• 02：cache 角色變化 frame 在 2.1 主寫但屬模組層級、應在 _index；Tubi 案例在 2.1 / 2.2 / 2.8 三章 mini-展開
• 03（最嚴重）：三層語意（delivery / processing / recovery）在 3.4 / 3.6 / 3.8 三章各自定義；Slack Kafka+Redis 拓樸在 3.4 跟 3.8 兩章逐字重複；規模對照在 3.4 / 3.6 / 3.8 三章拆用

防範：

• Stage 2 寫作前花 30 分鐘做 SSoT 對應（見前面「Stage 2 寫作前先定 SSoT 對應」段）
• 列出 cross-chapter frames、指定唯一主寫章節、其他章節只 link
• 寫每章前問「這個 frame 主寫在哪？我現在寫的是主寫還是 link？」

陷阱 3：負向陳述 + 模板化（規範系統性失分）

「不是 X、是 Y」推進論證、L1/L2/L3 三層平鋪、三選一表格、四步驟流程。這兩個原則違反在每模組都重複出現、是 LLM 寫作的反覆模式、stage 3 standards reviewer 每模組會抓 10-20 處。

實證：

• 01 規範 violation：表格不延伸（7 處）、負向陳述（5 處）、首句結構（4 處）
• 02 規範 violation：原則 8 模板化（6 處）、原則 2 負向陳述（6 處）、原則 4 表格不延伸（4 處）
• 03 規範 violation：原則 2 負向陳述（12 處最嚴重）、原則 1 首句結構（5 處）、原則 6 用語節制（2 處）
• 04 規範 violation：原則 2 負向陳述（12 處最嚴重、含「核心責任不是 X、而是 Y」變體段首）、原則 1 首句結構（9 處）、原則 4 表格不延伸（9 處）
• 05 規範 violation：原則 2「不是 X、而是 Y」+「沒有 X、會 Y」（10 處）、原則 8 四步驟 / 四層並列模板（7 處）、原則 3 case 引用框架取代商業邏輯先行（6 處）

防範：

• Stage 2 寫完後 寫稿端就跑掃描、不等 reviewer：
  • rg -n "不行|不可以|不要|無法|不能" <module-path> 找負向骨架（技術約束敘述例外）
  • rg -n "^[^|].*責任(不是|並非)" <module-path> 找「核心責任不是 X」變體段首（04 模組新發現的 pattern）
  • rg -n "^[^|].*[，,]而是|^[^|].*[，,]不是" <module-path> 找對比骨架開段
  • 自查表格：每個 bullet 是否有後文延伸？
  • 自查首句：是否「核心原則先行」而非「對應 [case] 揭露」
• 模板化（L1/L2/L3、三選一）出現時、先問「這三項是真的對等？還是業務情境不同？」— 不同情境的話拆敘事段、不用表格

陷阱 4：Rich case 判讀層被當 case fact 引用（04/05 模組新發現）

引用 09 / 07 等 rich case 時、case 內常含「觀察層」（具體 fact）跟「判讀層」（作者推論）兩段。LLM 寫作時容易把兩層壓縮成「揭露 X」、把作者判讀升級為 case fact。

跟陷阱 1（skeleton case 擴寫成 case 事實）的差別：

• 陷阱 1：case 沒提的細節（具體數字、taxonomy）被寫成 case 揭露
• 陷阱 4：case 有提、但屬作者判讀層的內容被寫成 case fact

實證：

• 05 / 9.C12 Riot：5.2 寫「揭露 35ms latency 反推 region 部署」、實際 case 的「35ms」是觀察層、「反推 region 部署」是作者判讀層
• 05 / 9.C34 GCP：5.2 寫「揭露 Spanner 替 etcd 才是 K8s 規模極限的關鍵」、實際 case 用更保守的「control plane 極限取決於 storage backend、GCP 用 Spanner 替換 etcd」分兩個點寫、章節壓縮 + 強化成硬性結論
• 05 / 9.C12 Riot：漏掉 case 揭露的關鍵歷史轉折「從 multi-tenant cluster 模型改成 single-tenant per game」

防範：

• 引用 rich case 前、先把 case 內的「觀察段」跟「判讀段」分開讀、抽 finding 時各自標明來源層
• 引用時用「揭露 X 觀察 + 作者判讀 Y」分層寫、或在引用後補一句「（case 中 X 屬作者判讀層、本章引用此推論）」
• 避免使用「才是 / 必須 / 一定」這類強化詞、保留 case 原文的條件性表述
• Stage 3 case fidelity reviewer 的 prompt 要特別點出「判讀層 vs 觀察層」的分界、把這當作 high 級 issue 抓取

陷阱 5：自掃描盲點累積（04/05/06 模組持續顯現）

自掃描的 regex 跟 reviewer 抓的 pattern 會逐漸脫節。每個模組 reviewer 會發現新 pattern、self-scan regex 跟著演進、但 reviewer 仍會發現下一個。

實證：

• 04 自掃描用 不行|不可以|不要|無法|不能 跟「不是 X、是 Y」掃描通過、但 reviewer A 抓出「核心責任不是 X、而是 Y」變體段首（佔 12 處）
• 05 自掃描通過、但 reviewer A 仍抓出「沒有 X、會 Y」鏈式負向句構 + 「四步驟模板」+ 「case 引用框架取代商業邏輯先行」三類新 pattern
• 06 self-scan 加了「不是 X、而是 Y」變體 + 「沒有 X 會 Y」、仍漏掉「對應 [case]：揭露 N 個機制」段首取代核心概念句的 pattern（reviewer A 抓 45 issue、其中 11/12 新段都犯這個錯）

防範：

• 每個模組 reviewer 抓出新 pattern 後、回頭更新 self-scan regex
• 把 self-scan 視為持續演進的工具、不是固定 checklist
• Stage 5 polish pass 是處理自掃描盲點累積的標準入口（見前段）
• 06 模組後 self-scan 加 rg -n "^對應 \[" <module-paths> 抓段首 case 引用框架

陷阱 6：Case 引用段首取代核心概念句（06 模組新發現）

LLM 從 case 反推內容時、容易把 case 揭露當概念出發點、寫成「對應 [case]：揭露 N 個機制 — …」段首結構。讀者尚未理解概念就被丟入案例細節、且跨章讀同句構會感同質。

實證：

• 06 模組 12 個新段中 11 個用「對應 [case]：揭露 N 個機制」相同句構作為 section 第二段
• 概念定義句被推到第二段或更後、商業邏輯先於 case 的原則被推翻

防範：

• 把 case 引用視為「三段式」結構：概念定義句 → case 引用 → 通用展開
• 寫每段時、先確認段首是「該概念是什麼、承擔什麼責任」、case 引用退到第二位置
• Case 引用句構應變化：寫多章時刻意避免同句構連續超過 3 次
• 詳見 skill 內部原則卡 principles/case-citation-three-part（對應檔案 .claude/skills/case-first-module-workflow/references/principles/case-citation-three-part.md、屬 skill 內部 reference、不對外暴露）

陷阱 7：Medium case 實作層擴寫過頭（06 模組新發現）

Medium case（30-50 行、結構化但無具體數字）首次套用時、容易把 case 沒提的具體實作層擴寫進章節、把通用工程知識掛到 case 名下。

實證：

• 06 模組 6.12 idempotency-replay 從 S1「key 設計要跟業務邊界一致」一條方向擴寫成「key 來源 / TTL / fallback / 偽造防護 / 5 個 observability 欄位」5 條實作判讀、case 沒提這些細節
• 06 模組 6.14 dependency-reliability-budget 從 M1 region failover 擴寫成「thundering herd」機制名 + 「先恢復核心 region 最小集合」具體步驟、case 沒提這兩個

防範：

• Medium case 引用用 mechanism 名稱 精準引用、不擴寫到 case 沒提的具體實作細節
• 引用後若要展開實作層、用「以下實作層判讀屬通用工程知識展開、case 本身只給 X 方向」明示分層
• Case fidelity reviewer 的 prompt 要特別點出 medium case 的「實作層擴寫」失分類型

陷阱 8：跨 case 合成 frame 升級成 case 揭露（07 模組新發現）

當段落把多個 case 的失效訊號抽象為更高層 frame（如「跨工具回查壓力」「平台責任切分」）、LLM 會把章節合成的 frame 包裝成 case 揭露。讀者回查 case 時會發現章節說的「case 揭露 X」實際是章節 derive、不是 case 原文框架。

跟陷阱 1（skeleton case 擴寫成 case 事實）跟陷阱 4（rich case 判讀層當 fact）的差別：

• 陷阱 1：case 沒提的細節（具體數字、taxonomy）被寫成 case 揭露
• 陷阱 4：case 有提、但屬作者判讀層的內容被寫成 case fact
• 陷阱 8：case 單獨 寫的訊號被章節 跨 case 合成 抽象為更高層 frame、frame 本身不在任一 case 原文

實證（07 batch 1 reviewer B 抓的 2 個 high issue）：

• 7.7 跨工具回查壓力：Uber 失效控制面寫「告警串接不足」、Slack 寫「訊號未匯流」— 都是單工具內訊號、章節合成「跨工具回查」axis
• 7.7 平台責任切分：SolarWinds 失效控制面寫「更新來源信任過於單點」「行為監測難以區分合法元件」— 都是供應鏈信任議題、章節合成「平台 vs 產品 audit 責任分離」frame

防範：

• 段落把多 case 抽象為更高層 frame 時、要 explicit 標明「frame 是本章合成、case 原文沒有此 frame」
• 修法範例：「兩個案例分別在 X 層揭露同類失效訊號 — A case 標明 B、C case 標明 D。本章把兩者抽象為『XXX』是 YYY 視角的合成 frame、非 case 原文框架。」
• Stage 3 reviewer B prompt 要明示「跨 case 合成 frame 必須標為本章合成」是 high 級 issue 抓取項

陷阱 9：Case 引用句構同質化（07 模組新發現）

即使遵守 case 引用三段式紀律、跨章節 case 引用仍會出現句構同質化。13 處 case 引用 11 處用同一句構「揭露 N 層失效控制面 — A、B、C。案例『可落地檢查點』標明 mechanism 為 X、前提是 Y」。讀者跨章連讀時、會把 case 引用當儀式而非論證。

實證：07 batch 1 reviewer A 抓出 systemic medium issue (Issue 8.1)、13 段 case 引用 11 段用相同句構。Stage 5 polish pass 主動分流 4 處後狀況改善。

防範：

• 句構選擇要 跟著 case 類型走、不是隨機變化（case 直接列 N mechanism → 「揭露 N 層」；case 揭露單一壓力 → 「補的失效訊號是 X」；case 揭露對比 → 「揭露兩個層次的對照」）
• Stage 5 polish pass 加句構分流為標準工序之一（跟負向骨架同層級）
• 自掃描 regex ^對應 \[ 抓不到此類問題（這是符合三段式的引用、只是句構單一）、要靠 stage 5 主動 scan：rg -c "揭露[^。]*失效控制面" <module-paths> 看同句構出現次數、超過 5 處要分流

「章節已有 routing skeleton」的特殊處理（07 模組新發現）

07 模組跟 06 / 09 不同之處：章節在 stage 2 前已有完整 routing layer 結構（threat scope / 從本章到實作 / 問題節點表 / 風險邊界 / 案例觸發 / 路由）— stage 2 是在現有結構內補 case-driven 深化段，而非空白擴章。

這個情境下：

• SSoT 衝突更容易發生：新段落要跟既有章節結構協調、不只是新增內容。07 batch 1 三個 H issue（C-H1/H2/H3）都是 frame 跟既有章節 / 其他章節新增段衝突
• 章節寫作邊界要先確認：補強段聚焦在「現有問題節點表的 mechanism 深化」、不擴成厚重 case-driven 章節（避免章節結構失衡）
• Cross-link 密度顯著上升：補強段要明示「本節聚焦 X 視角、canonical 在 Y 章」、否則 reviewer C 會抓 frame 重複展開

判讀條件：

• 章節已有 threat scope / 問題節點表 / 案例觸發段 → 走「補強段」策略、不空白擴章
• 章節是 routing layer / 導讀性質、不適合 case-driven 深化 → 跳過本流程
• 章節有 case 庫但 case 主要是 skeleton 型（30 行 frame） → 補強段嚴守「揭露 X 方向、通用補充」紀律、不擴寫實作層

衍生 insight：reviewer 維度沒覆蓋的部分

3 個模組跑下來、發現現有 3 reviewer 維度（規範 / 案例準確性 / 跨章一致性）有未覆蓋的問題：

• 教學性 / 讀者路徑：章節之間的閱讀順序是否合理？讀者讀完 A 章能不能銜接 B 章？目前沒 reviewer 檢查
• 判讀條件可操作性：寫了判讀訊號、但實際工程師能不能用這些訊號做決策？沒 reviewer 驗證
• 實作可行性：建議的設計是否真的能落地？跨團隊協調是否現實？需要懂業務的 reviewer

未來 6 / 7 / 8 模組執行時、可以考慮加第 4 個 reviewer 維度（教學性 + 實作可行性）。

跟其他寫作流程的差異

跟「LLM 自生 + 人工 review」比、本流程的差異：

跟「LLM 自生 + 自我 review」比：

• 自我 review 抓不到自生內容的盲點（self-blindness）
• Agent team 是 不同 instance、不共享 context、能扮演獨立 reviewer

下一步

本流程在 backend/01 至 backend/07 batch 1 七個模組驗證後（共 ~45 章 / 385 review issue / case fidelity 70-93% 區間）、方法論已工具化為 case-first-module-workflow skill（內部檔 .claude/skills/case-first-module-workflow/、含 stage 1-5 流程、reviewer prompt template、self-scan regex 跟 5 個原則卡）、後續套用到：

• backend/07 batch 2 LLM 安全：case 庫缺位（OWASP LLM Top 10 + agent injection 公開事件未累積成模組 case）、要先建 LLM case 庫再走 case-first
• backend/07 batch 3 治理章節：routing 層 / 導讀性質、case-driven 深化適用度低、做標準 polish pass 即可
• backend/08 incident response：跟 04 / 06 / 07 cross-link 密度最高、SSoT 對應規劃壓力最大
• 其他模組依此類推

06 模組是首次套用工具化 skill 的模組、驗證 skill 對 stage 1-2 加速有效、但 reviewer A 仍抓出 45 issue（高於 05 之前 baseline 20-30、推動 v1.2 把 standards reviewer baseline 擴大到 20-45）— 揭露 skill 改進方向（self-scan regex 需要持續演進、case 引用段首結構是 LLM 系統性傾向）。

07 batch 1 驗證下「章節已有 routing skeleton」情境的處理策略：補強段不擴成厚重 case-driven 章節、聚焦 mechanism 深化 + cross-link 對齊。揭露兩個新陷阱（跨 case 合成 frame 升級成 case 揭露、case 引用句構同質化）、補進 skill 跟方法論。

流程本身會在每個模組後 retrospective、看 reviewer 維度是否該調整、findings 抽取方法是否該強化、polish pass 處理 pattern 是否該擴充。目前已知改進方向：

• 加 reviewer：教學性審查（讀者路徑是否清楚、判讀順序是否合理）
• 強化 findings 抽取：標註 finding 的 泛化程度、避免把 case-specific 細節推為通用結論
• Rich / Medium case 引用紀律：把「fact vs derive」分層 + 「mechanism 名稱精準引用」寫進 stage 1 抽 findings 模板、stage 3 case fidelity reviewer prompt 也明示此分界
• 自掃描 regex 持續演進：每個模組 reviewer 抓出新 pattern 後、回頭加進 self-scan 工具、避免在下個模組重蹈覆轍。06 模組後加 ^對應 \[ 抓段首 case 引用框架。07 模組後標明 ^對應 \[ 在三段分離結構下會 false positive、要靠 awk 看 prev line context
• Case 引用三段式：把「概念定義 → case 引用 → 通用展開」當段落結構紀律、避免段首被 case 引用取代（06 模組最大宗 systemic 違規）
• Case 引用句構分流：07 模組後 stage 5 polish pass 加句構分流為標準工序、避免跨章 13+ 段同句構讀感儀式化
• 跨 case 合成 frame 紀律：07 模組後 reviewer B prompt 明示「跨 case 合成 frame 必須標為本章合成」是 high 級 issue
• 加修正後自動 lint：修完不只跑 mdtools、加跑「找首句否定句」「找表格沒延伸」「找模板化並列點」「找段首 case 引用」的自動掃描

跟其他寫作協議的整合：本流程跟 compositional-writing skill 互補（後者管 單篇 寫作的原子化跟意圖、本流程管 跨章模組 的 scope 跟一致性）、跟 requirement-protocol skill 互補（後者管 對話協議、本流程管 內容生產）。