案例引用深度是寫作層的紀律工具：把 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 保護。維度設計要對任務客製化、不要固定不變。

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