「模板」有兩個維度、寫作規範通常只 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 副作用、不是只看「單檔有沒有過」。