列舉與數字殘留在定義型文件會製造維護債務
核心原則
定義型文件（規則、規格、常駐名單——陳述「什麼成立」的文件，相對於報告、日誌這類記錄「當時發生什麼」的文件）中的冗餘列舉和描述性數字是撰寫過程中的推理殘留——作者需要先計算範圍和數量來確認定義正確，但這個計算過程不該留在最終文件裡。判斷標準：如果拿掉列舉或數字，讀者對定義的理解不受影響 → 刪除。
下面兩個層次的殘留是觀察到的 pattern：
| 殘留類型 | 文件中的樣子 | 維護成本 | 閱讀價值 |
|---|---|---|---|
| 冗餘列舉 | 「所有情境（A-G）無條件加入」 | 新增情境 H 時要回頭更新所有引用 | 零——「所有情境」已完整表達 |
| 描述性數字 | 「9 個函式、428 行可獨立抽出」 | 任何函式增減都要校準計數 | 低——讀者需要的是哪些函式、不是幾個 |
列舉在定義型文件中也有合理用途：當列舉本身就是定義（封閉 enum、有限狀態機的狀態集、HTTP 方法集），列舉本身就是被定義的對象。區分方式：列舉是在重述已由其他機制決定的範圍（冗餘）、還是在建立範圍（定義）。
同理，數字分兩種：描述性數字報告現狀（「目前有 9 個函式」），程式碼一變就過時；規範性數字規定目標值（「P99 < 200ms」「委員固定 7 人」「MAX_DEPTH=3」），是被定義的對象，該保留。
論述基礎與限制
本卡的論述基於 2 個 case（parallel-evaluation SKILL.md 常駐委員定義 + W3-008 分析報告）抽出來的觀察，每個子論點（列舉 / 數字）各只有 1 個 case 支撐。具體限制：
- 「列舉」指的是定義型文件中的冗餘列舉（如「所有情境（A-G）」），不包含報告格式範本中的 placeholder（如「情境: [A-G]」）——後者是填空欄位、不是定義；也不包含本身就是定義的封閉列舉（如 enum 成員清單）
- 「數字」指的是描述性計數（如「9 個函式」「428 行」），不包含規範性數字（如「MAX_DEPTH=3」「P99 < 200ms」）——後者是設計決策或 SLA 目標、不是統計快照
- 推理殘留不限於 AI 寫作：兩個 case 都來自 AI 生成的文件、AI 的生成順序可能讓這類殘留更常出現（見下方觀察），但人類作者在撰寫定義時同樣會先列舉確認再寫結論、忘了刪除中間產物
觸發案例
Case 1：常駐委員定義的冗餘列舉
parallel-evaluation SKILL.md 常駐委員表格寫了「所有情境（A-G）無條件加入」。「所有情境」已是完整定義，「（A-G）」在語意上重複——拿掉後讀者理解不受影響。留在文件裡則變成維護債務：新增情境 H 時「（A-G）」過時，讀者可能誤判 H 不含。
修正：刪除「（A-G）」。「所有情境無條件加入」自動涵蓋未來新增的情境。
Case 2：分析報告的數字快照
W3-008 分析報告寫了「duplicate_detection 群組 9 個函式、428 行」。這是分析時的統計快照、作為報告紀錄合理。但如果這些數字被寫進 ticket 驗收條件（「duplicate_detector.py 含 9 個函式」「create.py 行數減少約 428 行」），重構過程中任何函式增減都會讓驗收條件失效。
判讀：分析報告中的數字 → 保留（紀錄）。驗收條件中的描述性計數 → 改用結構性斷言（「所有 duplicate 相關函式已移至新模組」「既有測試通過」）。
AI 生成的順序觀察
兩個 case 都來自 AI 生成的文件。AI 的生成順序是先推理 → 再生成文字——模型在寫「所有情境無條件加入」之前，內部已驗證了 A 到 G 都涵蓋，列舉是推理的副產物被寫進生成的文字裡。同理，AI 在寫函式列表時傾向先數數量再列內容（「9 個函式：_tokenize, …」），數量是為了自我驗證完整性，但讀者只需要函式列表本身。
人類作者在撰寫定義時也會先列舉確認涵蓋範圍、AI 是否讓此模式更頻繁出現仍待更多樣本驗證（見限制段）。無論成因，判準相同：拿掉後讀者理解不受影響 → 刪除。
判斷決策表
| 文件類型 | 列舉/數字的角色 | 行動 |
|---|---|---|
| 定義型（規則、規格、常駐名單） | 推理殘留 | 刪除——定義本身已完整 |
| 報告型（分析、日誌、檢討） | 紀錄快照 | 保留——讀者需要知道當時的狀態 |
| 驗收條件 | 依被測屬性判斷 | 穩定屬性（函式名稱清單）→ 保留；易變屬性（行數、計數）→ 改結構性斷言 |
| 範本 placeholder | 填空欄位 | 保留——提示使用者填入具體值 |
驗收條件的判斷依據是被測屬性是否隨重構變動。函式名稱清單在重構後仍可驗證（名稱沒變、只是搬家），但行數和函式計數會因任何增減而失效——改用結構性斷言（「所有 X 相關函式已移至新模組」）讓驗收條件跟重構過程解耦。
真實文件常混合定義段與分析段（如 SKILL.md 同時有規則定義和設計紀錄），分類單位是段落而非整份文件——同一份文件內的定義段套用刪除判準、分析段保留數字。範本 placeholder 同理，它是填空欄位、不是定義。
跟其他原則的關係
- 讀者不需要知道的資訊不該出現在最終文件 — 同根原則的兩種表現：該卡處理 meta 動機殘留（「為什麼寫這篇」）、本卡處理推理過程殘留（列舉和數字）。兩者共用「拿掉後讀者體驗變不變差」的判準
- 適用範圍要展開成 file enumeration — 鏡像關係：該卡主張「適用範圍要 enumerate」、本卡主張「定義型文件的冗餘列舉要刪」。取決於文件型別——scope 文件需要 enumeration 確保執行時不遺漏、定義型文件的範圍已由定義本身表達
- 集合命名用角色、不內嵌數量 — 同原則在不同層面：前者處理命名層（「六大原則」的數字是成員清單的衍生值）、本卡處理正文定義層（「9 個函式」的數字是程式碼的衍生值）。兩卡共享「外部凍結數字可留」的邊界（前者的 SOLID / OWASP 對應本卡的 SLA / 設計常數）
- 便利驅動的寫法會偏離意圖 — 上位原則：列舉殘留是「寫的時候方便（先算再寫）、讀的時候多餘」的具體實例