<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>摘要 on Tarragon</title><link>https://tarrragon.github.io/blog/tags/%E6%91%98%E8%A6%81/</link><description>Recent content in 摘要 on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E6%91%98%E8%A6%81/index.xml" rel="self" type="application/rss+xml"/><item><title>摘要另一份內容時寫出成員，計數只告訴讀者清單有多長</title><link>https://tarrragon.github.io/blog/report/counted-summary-delivers-only-the-length/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/report/counted-summary-delivers-only-the-length/</guid><description>&lt;p>摘要的職責是讓讀者不必打開原文，就知道原文交付什麼。「四個追問、三種寫法各自押的前提、四類邊界」做不到這件事：讀者讀完知道有四個、三種、四類，而不知道任何一個是什麼，所以還是要點進去。&lt;strong>計數交付的是清單的長度，摘要要交付的是清單的內容。&lt;/strong>&lt;/p>
&lt;p>這一類句子出現在一個固定的位置：用一段文字介紹另一份讀者還沒讀的內容——文章結尾指向下一篇的那一句、&lt;code>description&lt;/code>、目錄頁章節表的「交付」欄、閱讀路線表的說明欄。寫的人手上有那份內容，四個追問各是什麼他全部知道，數字對他來說是一份完整的索引；讀的人手上沒有，數字對他只是一個長度。&lt;/p>
&lt;h2 id="失效的形態">失效的形態&lt;/h2>
&lt;p>一次 SQL 教材的改寫裡，總覽文章的結尾這樣介紹實例篇：&lt;/p>
&lt;blockquote>
&lt;p>拿一個真實需求做完這些決定：四個追問、三種寫法各自押的前提、兩種漏掉前提的寫法錯在相反的方向、四種形態的代價橫跨三個量級（其中一種加了索引反而變慢），以及需求沒說的四類邊界。&lt;/p>&lt;/blockquote>
&lt;p>這句話裡的數字，只有「橫跨三個量級」是量測結果本身；四個、三種、兩種、四類都只說了數量。全句讓讀者知道內容的只有「其中一種加了索引反而變慢」這一處。改寫之後是：&lt;/p>
&lt;blockquote>
&lt;p>拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉分區與漏掉相隔天數的兩個錯誤版本，一個少報、一個多報；……最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。&lt;/p>&lt;/blockquote>
&lt;p>改寫後的版本變長了，而讀者讀完已經知道那一篇的主要結論——包括他可能根本不需要點進去。&lt;/p>
&lt;p>同一份內容的 &lt;code>description&lt;/code> 與對照表有同樣的形態：「三種寫法各自押的前提、四種形態的代價實測」「四個追問」「四類需求沒說的」「上線前的三件事」。這些位置原本就是讀者決定要不要讀的地方，計數讓他無從決定。&lt;/p>
&lt;h2 id="為什麼既有的檢查放行">為什麼既有的檢查放行&lt;/h2>
&lt;p>&lt;strong>它在寫的人眼裡是精確的。&lt;/strong> 計數確實正確，而且比列出成員短。精簡規範在檢索鍵位（標題、&lt;code>description&lt;/code>、表格鍵欄）優先，於是計數讀起來像是合規的壓縮。精簡的前提是「讀者能從短形還原」，計數式摘要在讀者手上沒有可還原的內容。&lt;/p>
&lt;p>&lt;strong>既有規則管的是別的位置。&lt;/strong> 字句層 keyword bank 的「位置與集合指涉」已經要求「集合指涉即使計數正確也要給成員或方向」，而它的 pattern（其他三篇、另外三本、前兩章）是回指正文裡已經出現過的集合；計數式摘要是預告一份還沒讀的內容，句型是「數字＋類別名」而不是「其他＋數字」，那條 pattern 碰不到它。&lt;a href="https://tarrragon.github.io/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">#156&lt;/a> 管的是標題裡嵌入成員數，&lt;a href="https://tarrragon.github.io/blog/report/ordinal-labels-are-the-authors-index/" data-link-title="正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引" data-link-desc="文章裡出現「三支」「七步」「第三步」「第一級」「前提一」「A1 與 C」這類名字，讀者要回頭翻才知道指什麼時回來讀">#363&lt;/a> 管的是用序數或計數當一個對象的名字；計數式摘要是一段描述的全部內容，而那段描述沒有名字可以指。&lt;/p>
&lt;p>&lt;strong>grep 分不出合規與違規。&lt;/strong> 「配對與成品兩個時刻」「exec 與 dev 兩種網址」同樣是數字加類別名，而成員就寫在數字前面，是合規的。一次抽樣裡，&lt;code>description&lt;/code> 行內含兩組以上計數的有六十幾行，抽看的多數合規。違規與合規的差別在數字旁邊有沒有成員，這要讀句子才知道。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>在介紹另一份內容的位置（連結的介紹句、&lt;code>description&lt;/code>、交付欄、路線說明），逐一找出「數字＋類別名」的片語，問一句：&lt;strong>沒讀過那一篇的人，讀完這個片語知不知道成員是什麼。&lt;/strong>&lt;/p>
&lt;ul>
&lt;li>成員緊鄰數字寫出來了（「自連接、視窗函數與相關子查詢三種寫法」）：合規，數字可留可刪。&lt;/li>
&lt;li>只有數字與類別名（「三種寫法」「四類邊界」）：違規，改寫。&lt;/li>
&lt;li>量測事實（「差三個量級」「七十倍」）：合規，數字本身就是內容。&lt;/li>
&lt;/ul>
&lt;h2 id="修法">修法&lt;/h2>
&lt;p>&lt;strong>把成員寫出來，數字通常可以拿掉。&lt;/strong> 成員列出來之後讀者自己數得出有幾個，數字不再承載資訊；留著也無妨，但不要只留數字。&lt;/p>
&lt;p>&lt;strong>成員太多列不動時，寫它們共同的性質而不是數量。&lt;/strong> 例如「需求沒說而資料會有的情形（重複、時區、補登這一類）」比「四類邊界」多交付了一個可以套到別的題目上的概念。成員多到連舉例都做不到，代表這個摘要的範圍太大，要切成更小的單位。&lt;/p>
&lt;p>&lt;strong>寫完問一次：讀者讀完這句，還需要點進去嗎。&lt;/strong> 需要點進去是正常的——摘要不必交付全部——但他點進去的理由應該是想看推導與細節，不是想知道那幾項各叫什麼。&lt;/p>
&lt;h2 id="論述基礎與限制">論述基礎與限制&lt;/h2>
&lt;p>證據來自一個 SQL 教材分類的一次改寫：總覽文章結尾一處、實例文章的 &lt;code>description&lt;/code> 與對照表共五處。一次觀測只證明這個形態在介紹另一份內容的位置會被寫出來、並通過多輪審查；它在全站的密度沒有量過，因為 grep 分不出合規與違規，要逐句讀。&lt;/p>
&lt;h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係&lt;/h2>
&lt;ul>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/ordinal-labels-are-the-authors-index/" data-link-title="正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引" data-link-desc="文章裡出現「三支」「七步」「第三步」「第一級」「前提一」「A1 與 C」這類名字，讀者要回頭翻才知道指什麼時回來讀">#363 正文裡的對象要用它是什麼來命名&lt;/a>——同一個成因的兩個位置：作者手上有清單，讀者沒有。#363 是計數或序數當成名字，本卡是計數當成摘要的全部內容。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/decodable-from-text-already-read/" data-link-title="敘事的解碼材料要在讀者已讀的文本裡，不在作者的地圖裡" data-link-desc="教學敘事出現不具名的指涉、只給一面的對比或留給讀者自推的結論時，用來判定哪些壓縮手法把解碼成本轉嫁給了讀者、以及各自怎麼展開">#270 敘事的解碼材料要在讀者已讀的文本裡&lt;/a>——那一張的集合指涉規則管回指已讀的集合；本卡管預告未讀的內容，讀者手上連那份清單的存在都還沒有。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">#156 集合命名用角色、不內嵌數量&lt;/a>——那一張管名字裡的數量會隨成員增減失真；本卡的數量在成員不變時就沒有交付內容。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/description-as-recall-trigger/" data-link-title="查閱型內容的 description 是未來自己的 recall trigger" data-link-desc="排錯記錄、工具筆記這類使用者帶著症狀來的內容，它的 description 要讓未來的自己在掃列表時判斷該不該回來讀，本卡處理這一半的寫法與判斷標準；教材那一半另有專卡。">#170 description 是查閱時的回想觸發&lt;/a>——&lt;code>description&lt;/code> 的四不要裡有「不內嵌數字」，理由是數字會過時；本卡補上另一個理由：數字在不過時的時候也只交付長度。&lt;/li>
&lt;/ul>
&lt;h2 id="case">Case&lt;/h2>
&lt;p>2026-09-24，SQL 教材分類。前一輪剛依 #363 把「三支」「七步」改成內容名，使用者接著指出總覽文章結尾介紹實例篇的那一句：「跟讀者說有四個追問跟三個寫法四類邊界，讀者根本不知道這是什麼，他還是需要點進去文章才知道，那這幾個名詞都是廢話。」那一句在 #363 的改寫裡沒有被抓到，因為它沒有被當成任何對象的名字；同一次掃描也放過了實例文章 &lt;code>description&lt;/code> 與對照表裡的同型寫法。&lt;/p></description><content:encoded><![CDATA[<p>摘要的職責是讓讀者不必打開原文，就知道原文交付什麼。「四個追問、三種寫法各自押的前提、四類邊界」做不到這件事：讀者讀完知道有四個、三種、四類，而不知道任何一個是什麼，所以還是要點進去。<strong>計數交付的是清單的長度，摘要要交付的是清單的內容。</strong></p>
<p>這一類句子出現在一個固定的位置：用一段文字介紹另一份讀者還沒讀的內容——文章結尾指向下一篇的那一句、<code>description</code>、目錄頁章節表的「交付」欄、閱讀路線表的說明欄。寫的人手上有那份內容，四個追問各是什麼他全部知道，數字對他來說是一份完整的索引；讀的人手上沒有，數字對他只是一個長度。</p>
<h2 id="失效的形態">失效的形態</h2>
<p>一次 SQL 教材的改寫裡，總覽文章的結尾這樣介紹實例篇：</p>
<blockquote>
<p>拿一個真實需求做完這些決定：四個追問、三種寫法各自押的前提、兩種漏掉前提的寫法錯在相反的方向、四種形態的代價橫跨三個量級（其中一種加了索引反而變慢），以及需求沒說的四類邊界。</p></blockquote>
<p>這句話裡的數字，只有「橫跨三個量級」是量測結果本身；四個、三種、兩種、四類都只說了數量。全句讓讀者知道內容的只有「其中一種加了索引反而變慢」這一處。改寫之後是：</p>
<blockquote>
<p>拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉分區與漏掉相隔天數的兩個錯誤版本，一個少報、一個多報；……最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。</p></blockquote>
<p>改寫後的版本變長了，而讀者讀完已經知道那一篇的主要結論——包括他可能根本不需要點進去。</p>
<p>同一份內容的 <code>description</code> 與對照表有同樣的形態：「三種寫法各自押的前提、四種形態的代價實測」「四個追問」「四類需求沒說的」「上線前的三件事」。這些位置原本就是讀者決定要不要讀的地方，計數讓他無從決定。</p>
<h2 id="為什麼既有的檢查放行">為什麼既有的檢查放行</h2>
<p><strong>它在寫的人眼裡是精確的。</strong> 計數確實正確，而且比列出成員短。精簡規範在檢索鍵位（標題、<code>description</code>、表格鍵欄）優先，於是計數讀起來像是合規的壓縮。精簡的前提是「讀者能從短形還原」，計數式摘要在讀者手上沒有可還原的內容。</p>
<p><strong>既有規則管的是別的位置。</strong> 字句層 keyword bank 的「位置與集合指涉」已經要求「集合指涉即使計數正確也要給成員或方向」，而它的 pattern（其他三篇、另外三本、前兩章）是回指正文裡已經出現過的集合；計數式摘要是預告一份還沒讀的內容，句型是「數字＋類別名」而不是「其他＋數字」，那條 pattern 碰不到它。<a href="/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">#156</a> 管的是標題裡嵌入成員數，<a href="/blog/report/ordinal-labels-are-the-authors-index/" data-link-title="正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引" data-link-desc="文章裡出現「三支」「七步」「第三步」「第一級」「前提一」「A1 與 C」這類名字，讀者要回頭翻才知道指什麼時回來讀">#363</a> 管的是用序數或計數當一個對象的名字；計數式摘要是一段描述的全部內容，而那段描述沒有名字可以指。</p>
<p><strong>grep 分不出合規與違規。</strong> 「配對與成品兩個時刻」「exec 與 dev 兩種網址」同樣是數字加類別名，而成員就寫在數字前面，是合規的。一次抽樣裡，<code>description</code> 行內含兩組以上計數的有六十幾行，抽看的多數合規。違規與合規的差別在數字旁邊有沒有成員，這要讀句子才知道。</p>
<h2 id="判讀方式">判讀方式</h2>
<p>在介紹另一份內容的位置（連結的介紹句、<code>description</code>、交付欄、路線說明），逐一找出「數字＋類別名」的片語，問一句：<strong>沒讀過那一篇的人，讀完這個片語知不知道成員是什麼。</strong></p>
<ul>
<li>成員緊鄰數字寫出來了（「自連接、視窗函數與相關子查詢三種寫法」）：合規，數字可留可刪。</li>
<li>只有數字與類別名（「三種寫法」「四類邊界」）：違規，改寫。</li>
<li>量測事實（「差三個量級」「七十倍」）：合規，數字本身就是內容。</li>
</ul>
<h2 id="修法">修法</h2>
<p><strong>把成員寫出來，數字通常可以拿掉。</strong> 成員列出來之後讀者自己數得出有幾個，數字不再承載資訊；留著也無妨，但不要只留數字。</p>
<p><strong>成員太多列不動時，寫它們共同的性質而不是數量。</strong> 例如「需求沒說而資料會有的情形（重複、時區、補登這一類）」比「四類邊界」多交付了一個可以套到別的題目上的概念。成員多到連舉例都做不到，代表這個摘要的範圍太大，要切成更小的單位。</p>
<p><strong>寫完問一次：讀者讀完這句，還需要點進去嗎。</strong> 需要點進去是正常的——摘要不必交付全部——但他點進去的理由應該是想看推導與細節，不是想知道那幾項各叫什麼。</p>
<h2 id="論述基礎與限制">論述基礎與限制</h2>
<p>證據來自一個 SQL 教材分類的一次改寫：總覽文章結尾一處、實例文章的 <code>description</code> 與對照表共五處。一次觀測只證明這個形態在介紹另一份內容的位置會被寫出來、並通過多輪審查；它在全站的密度沒有量過，因為 grep 分不出合規與違規，要逐句讀。</p>
<h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係</h2>
<ul>
<li><a href="/blog/report/ordinal-labels-are-the-authors-index/" data-link-title="正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引" data-link-desc="文章裡出現「三支」「七步」「第三步」「第一級」「前提一」「A1 與 C」這類名字，讀者要回頭翻才知道指什麼時回來讀">#363 正文裡的對象要用它是什麼來命名</a>——同一個成因的兩個位置：作者手上有清單，讀者沒有。#363 是計數或序數當成名字，本卡是計數當成摘要的全部內容。</li>
<li><a href="/blog/report/decodable-from-text-already-read/" data-link-title="敘事的解碼材料要在讀者已讀的文本裡，不在作者的地圖裡" data-link-desc="教學敘事出現不具名的指涉、只給一面的對比或留給讀者自推的結論時，用來判定哪些壓縮手法把解碼成本轉嫁給了讀者、以及各自怎麼展開">#270 敘事的解碼材料要在讀者已讀的文本裡</a>——那一張的集合指涉規則管回指已讀的集合；本卡管預告未讀的內容，讀者手上連那份清單的存在都還沒有。</li>
<li><a href="/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">#156 集合命名用角色、不內嵌數量</a>——那一張管名字裡的數量會隨成員增減失真；本卡的數量在成員不變時就沒有交付內容。</li>
<li><a href="/blog/report/description-as-recall-trigger/" data-link-title="查閱型內容的 description 是未來自己的 recall trigger" data-link-desc="排錯記錄、工具筆記這類使用者帶著症狀來的內容，它的 description 要讓未來的自己在掃列表時判斷該不該回來讀，本卡處理這一半的寫法與判斷標準；教材那一半另有專卡。">#170 description 是查閱時的回想觸發</a>——<code>description</code> 的四不要裡有「不內嵌數字」，理由是數字會過時；本卡補上另一個理由：數字在不過時的時候也只交付長度。</li>
</ul>
<h2 id="case">Case</h2>
<p>2026-09-24，SQL 教材分類。前一輪剛依 #363 把「三支」「七步」改成內容名，使用者接著指出總覽文章結尾介紹實例篇的那一句：「跟讀者說有四個追問跟三個寫法四類邊界，讀者根本不知道這是什麼，他還是需要點進去文章才知道，那這幾個名詞都是廢話。」那一句在 #363 的改寫裡沒有被抓到，因為它沒有被當成任何對象的名字；同一次掃描也放過了實例文章 <code>description</code> 與對照表裡的同型寫法。</p>
]]></content:encoded></item></channel></rss>