結論

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

段位內容反模式
段首概念定義句：該概念是什麼、承擔什麼責任「對應 [case] 揭露 X」段首取代核心概念
第二位置Case 引用：「對應 [case]：揭露 N 個機制 — …」跨章 13+ 段同句構、case 引用變儀式
通用展開「以下基於通用工程知識補充」+ 具體操作通用知識直接掛在 case 名下、沒明示分層

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

跟其他 case 引用紀律的差別

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

卡Axis看什麼
#115 案例引用深度跟著 case 類型走引用「深度」Case 整體類型（skeleton / medium / rich）決定承接深度
#116 Fact vs Derive 分層引用引用「分層」Case 內部結構（觀察層 / 判讀層）決定要不要分層標明
#117 跨 case 合成 frame 必須標明引用「合成」跨多 case 抽象 frame 時要 explicit 標「本章合成」
#120 案例引用三段式（本卡）引用「結構」段落順序：概念 → case → 通用

四 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 自身結構決定引用方式：

Case 結構適用句構
Case 直接列 N 個 mechanism「揭露 N 層失效控制面 — A、B、C」
Case 主寫單一壓力場景「補的失效訊號是 X、mechanism 是 Y」
Case 揭露歷史轉折「從 X 改成 Y 的關鍵架構決策」
Case 揭露對比結構「揭露兩個層次的對照：A vs B」
多 case 並列補不同層「A case 補 X、B case 補 Y」
Case 揭露 mechanism 可引用範圍「案例『可落地檢查點』直接列出 mechanism 屬可引用範圍」

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

反模式

反模式後果
段首直接是「對應 [case]」、沒概念定義句商業邏輯先於 case 原則被推翻、讀者尚未理解就被丟入案例細節
段首用「另一個面向」「不只是 X、是 Y」鋪墊取代概念定義推進論證骨架取代概念先行
三段式中段（case 引用）擴寫成具體實作細節把通用工程知識掛在 case 名下、case fidelity 失分
通用展開段沒明示「以下基於通用工程知識補充」讀者誤以為展開內容也來自 case
跨章 5+ 段用同一句構「揭露 N 層失效控制面」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 小時。

跟其他抽象層原則的關係

原則關係
#115 案例引用深度跟著 case 類型走互補 — 不同 axis、#115 看引用深度、本卡看引用結構
#116 Fact vs Derive 分層引用互補 — 不同 axis、#116 看 case 內部分層、本卡看段落順序
#117 跨 case 合成 frame 必須標明互補 — 不同 axis、#117 看跨 case 合成、本卡看單段結構
#83 Writing multi-pass review互補 — #83 是 review 流程跨輪 frame、本卡是寫作當下段落順序
#67 寫作便利度跟意圖對齊反相關同骨 pattern — 「對應 [case]」當段首最順、不寫概念定義最省字、便利跟意圖對齊反向
#114 Multi-pass review 的 frame 顆粒度盲點句構同質化是 #114 在 case 引用 surface 的具體展現

判讀徵兆

訊號該做的事
段首是「對應 [case] 揭露 X」補概念定義句、case 引用退到第二位置
段首用「另一個面向」「不只是 X、是 Y」鋪墊改成概念定義先行、不用對比骨架推進
跨章 5+ 段用同句構「揭露 N 層失效控制面」Stage 5 polish pass 句構分流
Reviewer A 抓出「case 引用段首」issue 多三段式紀律失效、整模組重審
通用展開段沒明示「以下基於通用工程知識補充」補承接句、讓讀者知道展開內容是通用知識

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