摘要的職責是讓讀者不必打開原文，就知道原文交付什麼。「四個追問、三種寫法各自押的前提、四類邊界」做不到這件事：讀者讀完知道有四個、三種、四類，而不知道任何一個是什麼，所以還是要點進去。計數交付的是清單的長度，摘要要交付的是清單的內容。

這一類句子出現在一個固定的位置：用一段文字介紹另一份讀者還沒讀的內容——文章結尾指向下一篇的那一句、description、目錄頁章節表的「交付」欄、閱讀路線表的說明欄。寫的人手上有那份內容，四個追問各是什麼他全部知道，數字對他來說是一份完整的索引；讀的人手上沒有，數字對他只是一個長度。

失效的形態

一次 SQL 教材的改寫裡，總覽文章的結尾這樣介紹實例篇：

拿一個真實需求做完這些決定：四個追問、三種寫法各自押的前提、兩種漏掉前提的寫法錯在相反的方向、四種形態的代價橫跨三個量級（其中一種加了索引反而變慢），以及需求沒說的四類邊界。

這句話裡的數字，只有「橫跨三個量級」是量測結果本身；四個、三種、兩種、四類都只說了數量。全句讓讀者知道內容的只有「其中一種加了索引反而變慢」這一處。改寫之後是：

拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉分區與漏掉相隔天數的兩個錯誤版本，一個少報、一個多報；……最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。

改寫後的版本變長了，而讀者讀完已經知道那一篇的主要結論——包括他可能根本不需要點進去。

同一份內容的 description 與對照表有同樣的形態：「三種寫法各自押的前提、四種形態的代價實測」「四個追問」「四類需求沒說的」「上線前的三件事」。這些位置原本就是讀者決定要不要讀的地方，計數讓他無從決定。

為什麼既有的檢查放行

它在寫的人眼裡是精確的。 計數確實正確，而且比列出成員短。精簡規範在檢索鍵位（標題、description、表格鍵欄）優先，於是計數讀起來像是合規的壓縮。精簡的前提是「讀者能從短形還原」，計數式摘要在讀者手上沒有可還原的內容。

既有規則管的是別的位置。 字句層 keyword bank 的「位置與集合指涉」已經要求「集合指涉即使計數正確也要給成員或方向」，而它的 pattern（其他三篇、另外三本、前兩章）是回指正文裡已經出現過的集合；計數式摘要是預告一份還沒讀的內容，句型是「數字＋類別名」而不是「其他＋數字」，那條 pattern 碰不到它。#156 管的是標題裡嵌入成員數，#363 管的是用序數或計數當一個對象的名字；計數式摘要是一段描述的全部內容，而那段描述沒有名字可以指。

grep 分不出合規與違規。 「配對與成品兩個時刻」「exec 與 dev 兩種網址」同樣是數字加類別名，而成員就寫在數字前面，是合規的。一次抽樣裡，description 行內含兩組以上計數的有六十幾行，抽看的多數合規。違規與合規的差別在數字旁邊有沒有成員，這要讀句子才知道。

判讀方式

在介紹另一份內容的位置（連結的介紹句、description、交付欄、路線說明），逐一找出「數字＋類別名」的片語，問一句：沒讀過那一篇的人，讀完這個片語知不知道成員是什麼。

• 成員緊鄰數字寫出來了（「自連接、視窗函數與相關子查詢三種寫法」）：合規，數字可留可刪。
• 只有數字與類別名（「三種寫法」「四類邊界」）：違規，改寫。
• 量測事實（「差三個量級」「七十倍」）：合規，數字本身就是內容。

修法

把成員寫出來，數字通常可以拿掉。 成員列出來之後讀者自己數得出有幾個，數字不再承載資訊；留著也無妨，但不要只留數字。

成員太多列不動時，寫它們共同的性質而不是數量。 例如「需求沒說而資料會有的情形（重複、時區、補登這一類）」比「四類邊界」多交付了一個可以套到別的題目上的概念。成員多到連舉例都做不到，代表這個摘要的範圍太大，要切成更小的單位。

寫完問一次：讀者讀完這句，還需要點進去嗎。 需要點進去是正常的——摘要不必交付全部——但他點進去的理由應該是想看推導與細節，不是想知道那幾項各叫什麼。

論述基礎與限制

證據來自一個 SQL 教材分類的一次改寫：總覽文章結尾一處、實例文章的 description 與對照表共五處。一次觀測只證明這個形態在介紹另一份內容的位置會被寫出來、並通過多輪審查；它在全站的密度沒有量過，因為 grep 分不出合規與違規，要逐句讀。

跟其他抽象層原則的關係

• #363 正文裡的對象要用它是什麼來命名——同一個成因的兩個位置：作者手上有清單，讀者沒有。#363 是計數或序數當成名字，本卡是計數當成摘要的全部內容。
• #270 敘事的解碼材料要在讀者已讀的文本裡——那一張的集合指涉規則管回指已讀的集合；本卡管預告未讀的內容，讀者手上連那份清單的存在都還沒有。
• #156 集合命名用角色、不內嵌數量——那一張管名字裡的數量會隨成員增減失真；本卡的數量在成員不變時就沒有交付內容。
• #170 description 是查閱時的回想觸發——description 的四不要裡有「不內嵌數字」，理由是數字會過時；本卡補上另一個理由：數字在不過時的時候也只交付長度。

Case

2026-09-24，SQL 教材分類。前一輪剛依 #363 把「三支」「七步」改成內容名，使用者接著指出總覽文章結尾介紹實例篇的那一句：「跟讀者說有四個追問跟三個寫法四類邊界，讀者根本不知道這是什麼，他還是需要點進去文章才知道，那這幾個名詞都是廢話。」那一句在 #363 的改寫裡沒有被抓到，因為它沒有被當成任何對象的名字；同一次掃描也放過了實例文章 description 與對照表裡的同型寫法。