<?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/%E5%91%BD%E5%90%8D/</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>Tue, 29 Sep 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E5%91%BD%E5%90%8D/index.xml" rel="self" type="application/rss+xml"/><item><title>壓縮標籤省下的字數是一次，展開成本乘以引用點數</title><link>https://tarrragon.github.io/blog/report/compressed-label-cost-multiplies-with-citations/</link><pubDate>Tue, 08 Sep 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/report/compressed-label-cost-multiplies-with-citations/</guid><description>&lt;h2 id="論述基礎與限制">論述基礎與限制&lt;/h2>
&lt;p>本卡由兩個實例歸納，兩例的形狀相同而取得方式不同，證據等級要分開讀。&lt;/p>
&lt;p>&lt;strong>第一例由併行 session 提供，該檔案由回報者持有，本卡的證據止於他的轉述。&lt;/strong> 一份互動規格的動畫提示表，列名寫「格選中態出現」，形式欄寫「點擊確認用內建 pressed 態，選中態本身無入場動畫（持續性標記）」。回報者指出還原這四個字要三項表外知識：「格」是哪一種格（回查該表所在章節的標題再對到元件目錄）、「選中態」是一次性回饋還是持續維持的標記（讀完形式欄的括號才知道）、「出現」在問什麼（看同表其他列才知道這一欄問的是狀態從無到有的那一瞬間要不要動畫）。自足寫法是「矩陣格的選取標記出現時」，多六個字。該列名另被下游規格四處逐字引用當跨檔錨點。回報者另記下同份文件的其他列寫得完整，判定為個案。&lt;/p>
&lt;p>&lt;strong>第二例是本站自測。&lt;/strong> #302 定義的七種裝置，名字住在那張卡上，四個引用點各自轉述。三處保留完整形（&lt;code>docs/rules/writing.md&lt;/code>〈&lt;code>content/&lt;/code> 文章的定位：教學；目錄頁與 report 卡另有體例〉（舊版的原則十一）的正文、&lt;code>compositional-writing&lt;/code> 的 &lt;code>SKILL.md&lt;/code>、&lt;code>multi-round-review&lt;/code> 的 Round 2 reference），一處把限定語砍掉（&lt;code>AGENTS.md&lt;/code> 完稿檢查清單的那一項）。&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>定義處的形態&lt;/th>
 &lt;th>檢查清單的形態&lt;/th>
 &lt;th>被砍掉的成分&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>順序關鍵加上顛倒的後果&lt;/td>
 &lt;td>顛倒的後果&lt;/td>
 &lt;td>主詞（什麼被顛倒）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>配比與參數數字&lt;/td>
 &lt;td>配比數字&lt;/td>
 &lt;td>一半的外延（參數）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>具體器具與工具作法&lt;/td>
 &lt;td>器具作法&lt;/td>
 &lt;td>範圍限定（具體、工具）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>可執行的操作判斷標準&lt;/td>
 &lt;td>操作判斷標準&lt;/td>
 &lt;td>資格限定（可執行的）&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>檢查順序的指示&lt;/td>
 &lt;td>檢查順序指示&lt;/td>
 &lt;td>無（語法壓縮）&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>整行省下十九個字。省下這些字的那一行正是完稿檢查清單，也就是這份規範裡逐項執行、每次使用都要重新解碼的位置；該處已隨本卡同一次改動補回完整形。分佈本身也是證據——其餘四個引用點都保留完整形，壓縮只發生在一處，所以一致性掃描找不到可比對的異常。&lt;/p>
&lt;p>&lt;strong>兩例都是個案，沒有對照組，本卡不宣稱這種缺陷有多常見。&lt;/strong> 成立的是機制與判斷標準，不是分佈。&lt;/p>
&lt;hr>
&lt;h2 id="核心原則">核心原則&lt;/h2>
&lt;p>&lt;strong>替一個概念取短名時，省下的字數付一次，還原限定語的成本乘以讀者數與引用點數。&lt;/strong> 兩側的量級不對稱，所以標籤越像術語、被引用得越廣，短名的收益越小而代價越大。&lt;/p>
&lt;p>&lt;a href="../sentence-self-sufficiency-by-consumption-unit/">#261&lt;/a> 把檢索鍵位（title、description、表格鍵欄、卡名、錨點）的義務定為識別充足——讀者能指認它索引的是哪個命題——並記下跟精簡規範衝突時精簡優先。本卡限定那條優先序：&lt;strong>精簡優先的前提是這個鍵只有一個消費點&lt;/strong>。鍵一旦被別處逐字引用，它就同時是錨點，而錨點有兩個性質讓天平倒過來：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>引用點只交付那個字串。&lt;/strong> 引用的形式是逐字比對，加字即斷開比對；每一個引用點因此只給得出短名本身，補完的責任全部落回讀者。&lt;/li>
&lt;li>&lt;strong>展開的代價隨引用點數上升。&lt;/strong> 既有標籤要改時，它與全部引用點必須同一次改，否則錨點斷開；所以短名的修復成本本身也乘以引用點數，而那個乘數只會隨時間變大。&lt;/li>
&lt;/ul>
&lt;p>識別充足因此需要一個可執行的判斷標準。判斷標準是兩個問句：&lt;strong>這個標籤裡的每個名詞，讀者知道是哪一個嗎；每個動詞，讀者知道主詞是誰嗎。&lt;/strong> 兩題都答得出來才算識別充足。省略的限定語補回標籤本身，不補在鄰欄——讀者先讀標籤才決定要不要讀那一列，補在鄰欄的限定語落在他已經跳過的位置。&lt;/p>
&lt;p>&lt;strong>例外有兩種。&lt;/strong> 表頭語境下已經自足的通用欄位標籤（「觸發」「反應」在該表結構下無歧義），以及領域內有正式定義而讀者一跳查得到的術語。&lt;/p>
&lt;hr>
&lt;h2 id="為什麼既有的檢查走不到它">為什麼既有的檢查走不到它&lt;/h2>
&lt;p>壓縮標籤看起來像術語，於是每一條以「殘片」為入口的檢查都放行。&lt;/p>
&lt;p>&lt;a href="../compressed-chinese-terms-need-head-noun/">#108&lt;/a> 查的是名詞頭有沒有被砍到只剩形容詞或單字，「盲」這種形態自己就現形——它讀起來是半個詞。「顛倒的後果」「配比數字」「格選中態出現」的名詞頭都在，語法完整，放進表格第一欄成立，拿去 grep 也命中；#108 的四道檢查（拿出句子後知不知道是什麼、能不能放進表格第一欄、讀者能不能用它問問題、能不能跟同類詞並列）它全部通過。被砍掉的是限定語，而限定語的缺席在語法上沒有痕跡。&lt;/p>
&lt;p>&lt;a href="../sentence-self-sufficiency-by-consumption-unit/">#261&lt;/a> 的指涉閉合條件形式上涵蓋這一類（殘片名詞要有完整形先行），執行時走不到——執行者要先認出那是殘片才會去找完整形，而這些標籤讀起來是完整的詞。本站那一例的完整形就在同一份檔案裡，與壓縮版相隔一百七十二行。&lt;/p>
&lt;p>一致性掃描同樣無效，而理由更基本：&lt;strong>周圍都是對的&lt;/strong>。兩例的作者在同一份文件的其他位置都寫了完整形，壓縮是零星發生的，所以掃描找不到可比對的異常，逐句自審讀起來也通順。&lt;/p>
&lt;p>根因在時序。壓縮發生在作者剛把一件事想清楚的當下，限定語在腦中太顯然、寫出來像廢話——而像廢話正是讀者需要的形態，他沒有經歷那次想清楚的過程。審查抓不到的原因相同：熟悉該文件的審查者持有同一份脈絡。第一例是由一位讀者問「這四個字是什麼意思」暴露的，而回答那個問題所花的成本（兩次檔案查詢加一整段拆解）本身就是量測值。&lt;/p>
&lt;hr>
&lt;h2 id="偵測與修法">偵測與修法&lt;/h2>
&lt;p>偵測的入口是引用點數，而引用點數可以直接算。&lt;/p>





&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-bash" data-lang="bash">&lt;span class="line">&lt;span class="ln">1&lt;/span>&lt;span class="cl">rg -F -l -- &lt;span class="s2">&amp;#34;&amp;lt;標籤字串&amp;gt;&amp;#34;&lt;/span> &amp;lt;內容根目錄&amp;gt;&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>命中兩個檔以上的標籤就是錨點，錨點逐個跑那兩個判斷標準問句。這條掃描的對象是定義處的標籤清單，不是全文的段標——用段標當代理會量到模板重複而不是引用（本站實測：段標出現次數的前幾名是 &lt;code>YAML&lt;/code>、&lt;code>Problem&lt;/code>、&lt;code>Server&lt;/code>，全部是模板欄位）。&lt;/p>
&lt;p>修法分兩種情形。&lt;/p>
&lt;p>&lt;strong>標籤還沒有被引用&lt;/strong>：直接把限定語補回標籤，成本是一次。&lt;/p>
&lt;p>&lt;strong>標籤已經是錨點&lt;/strong>：改動與全部引用點同一次進行，改完回頭跑一次同一條掃描確認沒有殘留舊字串。錨點斷開的失效形態跟 &lt;a href="../reference-by-semantic-title-not-number/">#155&lt;/a> 的編號錯位同型——字面完好、語意 silent 指向錯的內容，比斷鏈難偵測。&lt;/p>
&lt;hr>
&lt;h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>原則&lt;/th>
 &lt;th>關係&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>&lt;a href="../sentence-self-sufficiency-by-consumption-unit/">#261 語句要在它的消費單位內資訊自足&lt;/a>&lt;/td>
 &lt;td>母卡。#261 把檢索鍵位的義務定為識別充足並讓精簡優先；本卡給識別充足一個可執行的判斷標準，並限定那條優先序——鍵同時是跨檔錨點時，自足壓過精簡。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../compressed-chinese-terms-need-head-noun/">#108 中文壓縮術語要保留完整名詞頭&lt;/a>&lt;/td>
 &lt;td>互補的兩種壓縮。#108 管名詞頭被砍（殘片自己現形），本卡管名詞頭健在而限定語被砍（讀起來像完整術語）。#108 的四道檢查對本卡的形態全數放行，這一點是本卡存在的理由。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../reference-by-semantic-title-not-number/">#155 引用錨點用語意標題、不用位置編號&lt;/a>&lt;/td>
 &lt;td>錨點寫法家族的第一員。那裡的錨點是結構排列的 derivation，這裡的錨點是完整概念的壓縮；共同的失效是字面完好而語意 silent 指錯。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../name-collections-by-role-not-count/">#156 集合命名用角色、不內嵌數量&lt;/a>&lt;/td>
 &lt;td>家族的第二員：名字裡內嵌成員數。三員的共同結構是把只在作者側成立的前提寫進了標識符，而標識符會被複製。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../axis-named-by-proxy-not-mechanism/">#257 軸名取了次好的代理變數&lt;/a>&lt;/td>
 &lt;td>相鄰而不同。#257 的名字選了較弱的代理，機制寫在括號裡；本卡的名字選對了機制，砍掉的是限定語。兩者共用同一個對讀者的傷害——讀者只拿得到名字，作者讀名字時腦中補的是完整版。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../concept-used-but-never-named/">#321 從名字出發的術語檢查抓不到從未命名的概念&lt;/a>&lt;/td>
 &lt;td>同一種入口失配的另一端。#321 的名字頻率是零所以檢查走不到，本卡的名字語法合格所以檢查放行；兩者都由既有檢查的入口條件決定，跟審查認不認真無關。&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;a href="../positioning-decides-form-before-any-rule-applies/">#302 定位決定體例&lt;/a>&lt;/td>
 &lt;td>本卡第二個實例的來源：那七種裝置的名字住在 #302，而完稿檢查清單引用時砍掉限定語，照清單執行的人因此拿到四個無法就地判定的標籤（已修）。&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;hr>
&lt;ul>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/derived-operational-form-needs-its-own-check/" data-link-title="從原則卡壓出來的操作形要獨立驗一次，而本體正確正是它不被檢查的原因" data-link-desc="把原則卡壓成 checklist、規範段落或 skill 條目之後，用來判斷壓出來的那一份要不要獨立量測">#353 從原則卡壓出來的操作形要獨立驗一次&lt;/a>：同一個壓縮機制的另一個載體而軸不同。本卡的判斷標準是引用點數（被別處逐字引用兩處以上就要自足），那張的判斷標準是會不會被執行——衍生形通常只有一個消費點，而它是被照著做的那一個，所以引用一次也要自足。&lt;/li>
&lt;/ul>
&lt;h2 id="判讀徵兆">判讀徵兆&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>訊號&lt;/th>
 &lt;th>該做的事&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>有人問「這個標籤是什麼意思」&lt;/td>
 &lt;td>回答所花的查詢步數就是量測值；把限定語補進標籤，讓下一個讀者直接讀得懂&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>某個標籤在兩個以上的檔案裡逐字出現&lt;/td>
 &lt;td>它是錨點，跑兩個判斷標準問句&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>標籤的限定語寫在鄰欄或括號裡&lt;/td>
 &lt;td>讀者先讀標籤才決定要不要讀鄰欄，把限定語搬進標籤本身&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>同一組名字在不同檔案有長短兩版&lt;/td>
 &lt;td>短版是壓縮的那一版，查它住在哪個消費位；住在檢查清單或路由表要優先修&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>剛把一件事想清楚，正在替它取名&lt;/td>
 &lt;td>限定語此刻讀起來像廢話，這是壓縮的觸發時點；判斷標準問句在這裡跑最便宜&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>&lt;strong>核心&lt;/strong>：短名的收益結算一次，展開的代價由每一個讀者、每一個引用點各付一遍。標籤越像術語被到處引用，兩側的差距越大。&lt;/p></description><content:encoded><![CDATA[<h2 id="論述基礎與限制">論述基礎與限制</h2>
<p>本卡由兩個實例歸納，兩例的形狀相同而取得方式不同，證據等級要分開讀。</p>
<p><strong>第一例由併行 session 提供，該檔案由回報者持有，本卡的證據止於他的轉述。</strong> 一份互動規格的動畫提示表，列名寫「格選中態出現」，形式欄寫「點擊確認用內建 pressed 態，選中態本身無入場動畫（持續性標記）」。回報者指出還原這四個字要三項表外知識：「格」是哪一種格（回查該表所在章節的標題再對到元件目錄）、「選中態」是一次性回饋還是持續維持的標記（讀完形式欄的括號才知道）、「出現」在問什麼（看同表其他列才知道這一欄問的是狀態從無到有的那一瞬間要不要動畫）。自足寫法是「矩陣格的選取標記出現時」，多六個字。該列名另被下游規格四處逐字引用當跨檔錨點。回報者另記下同份文件的其他列寫得完整，判定為個案。</p>
<p><strong>第二例是本站自測。</strong> #302 定義的七種裝置，名字住在那張卡上，四個引用點各自轉述。三處保留完整形（<code>docs/rules/writing.md</code>〈<code>content/</code> 文章的定位：教學；目錄頁與 report 卡另有體例〉（舊版的原則十一）的正文、<code>compositional-writing</code> 的 <code>SKILL.md</code>、<code>multi-round-review</code> 的 Round 2 reference），一處把限定語砍掉（<code>AGENTS.md</code> 完稿檢查清單的那一項）。</p>
<table>
  <thead>
      <tr>
          <th>定義處的形態</th>
          <th>檢查清單的形態</th>
          <th>被砍掉的成分</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>順序關鍵加上顛倒的後果</td>
          <td>顛倒的後果</td>
          <td>主詞（什麼被顛倒）</td>
      </tr>
      <tr>
          <td>配比與參數數字</td>
          <td>配比數字</td>
          <td>一半的外延（參數）</td>
      </tr>
      <tr>
          <td>具體器具與工具作法</td>
          <td>器具作法</td>
          <td>範圍限定（具體、工具）</td>
      </tr>
      <tr>
          <td>可執行的操作判斷標準</td>
          <td>操作判斷標準</td>
          <td>資格限定（可執行的）</td>
      </tr>
      <tr>
          <td>檢查順序的指示</td>
          <td>檢查順序指示</td>
          <td>無（語法壓縮）</td>
      </tr>
  </tbody>
</table>
<p>整行省下十九個字。省下這些字的那一行正是完稿檢查清單，也就是這份規範裡逐項執行、每次使用都要重新解碼的位置；該處已隨本卡同一次改動補回完整形。分佈本身也是證據——其餘四個引用點都保留完整形，壓縮只發生在一處，所以一致性掃描找不到可比對的異常。</p>
<p><strong>兩例都是個案，沒有對照組，本卡不宣稱這種缺陷有多常見。</strong> 成立的是機制與判斷標準，不是分佈。</p>
<hr>
<h2 id="核心原則">核心原則</h2>
<p><strong>替一個概念取短名時，省下的字數付一次，還原限定語的成本乘以讀者數與引用點數。</strong> 兩側的量級不對稱，所以標籤越像術語、被引用得越廣，短名的收益越小而代價越大。</p>
<p><a href="../sentence-self-sufficiency-by-consumption-unit/">#261</a> 把檢索鍵位（title、description、表格鍵欄、卡名、錨點）的義務定為識別充足——讀者能指認它索引的是哪個命題——並記下跟精簡規範衝突時精簡優先。本卡限定那條優先序：<strong>精簡優先的前提是這個鍵只有一個消費點</strong>。鍵一旦被別處逐字引用，它就同時是錨點，而錨點有兩個性質讓天平倒過來：</p>
<ul>
<li><strong>引用點只交付那個字串。</strong> 引用的形式是逐字比對，加字即斷開比對；每一個引用點因此只給得出短名本身，補完的責任全部落回讀者。</li>
<li><strong>展開的代價隨引用點數上升。</strong> 既有標籤要改時，它與全部引用點必須同一次改，否則錨點斷開；所以短名的修復成本本身也乘以引用點數，而那個乘數只會隨時間變大。</li>
</ul>
<p>識別充足因此需要一個可執行的判斷標準。判斷標準是兩個問句：<strong>這個標籤裡的每個名詞，讀者知道是哪一個嗎；每個動詞，讀者知道主詞是誰嗎。</strong> 兩題都答得出來才算識別充足。省略的限定語補回標籤本身，不補在鄰欄——讀者先讀標籤才決定要不要讀那一列，補在鄰欄的限定語落在他已經跳過的位置。</p>
<p><strong>例外有兩種。</strong> 表頭語境下已經自足的通用欄位標籤（「觸發」「反應」在該表結構下無歧義），以及領域內有正式定義而讀者一跳查得到的術語。</p>
<hr>
<h2 id="為什麼既有的檢查走不到它">為什麼既有的檢查走不到它</h2>
<p>壓縮標籤看起來像術語，於是每一條以「殘片」為入口的檢查都放行。</p>
<p><a href="../compressed-chinese-terms-need-head-noun/">#108</a> 查的是名詞頭有沒有被砍到只剩形容詞或單字，「盲」這種形態自己就現形——它讀起來是半個詞。「顛倒的後果」「配比數字」「格選中態出現」的名詞頭都在，語法完整，放進表格第一欄成立，拿去 grep 也命中；#108 的四道檢查（拿出句子後知不知道是什麼、能不能放進表格第一欄、讀者能不能用它問問題、能不能跟同類詞並列）它全部通過。被砍掉的是限定語，而限定語的缺席在語法上沒有痕跡。</p>
<p><a href="../sentence-self-sufficiency-by-consumption-unit/">#261</a> 的指涉閉合條件形式上涵蓋這一類（殘片名詞要有完整形先行），執行時走不到——執行者要先認出那是殘片才會去找完整形，而這些標籤讀起來是完整的詞。本站那一例的完整形就在同一份檔案裡，與壓縮版相隔一百七十二行。</p>
<p>一致性掃描同樣無效，而理由更基本：<strong>周圍都是對的</strong>。兩例的作者在同一份文件的其他位置都寫了完整形，壓縮是零星發生的，所以掃描找不到可比對的異常，逐句自審讀起來也通順。</p>
<p>根因在時序。壓縮發生在作者剛把一件事想清楚的當下，限定語在腦中太顯然、寫出來像廢話——而像廢話正是讀者需要的形態，他沒有經歷那次想清楚的過程。審查抓不到的原因相同：熟悉該文件的審查者持有同一份脈絡。第一例是由一位讀者問「這四個字是什麼意思」暴露的，而回答那個問題所花的成本（兩次檔案查詢加一整段拆解）本身就是量測值。</p>
<hr>
<h2 id="偵測與修法">偵測與修法</h2>
<p>偵測的入口是引用點數，而引用點數可以直接算。</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">rg -F -l -- <span class="s2">&#34;&lt;標籤字串&gt;&#34;</span> &lt;內容根目錄&gt;</span></span></code></pre></div><p>命中兩個檔以上的標籤就是錨點，錨點逐個跑那兩個判斷標準問句。這條掃描的對象是定義處的標籤清單，不是全文的段標——用段標當代理會量到模板重複而不是引用（本站實測：段標出現次數的前幾名是 <code>YAML</code>、<code>Problem</code>、<code>Server</code>，全部是模板欄位）。</p>
<p>修法分兩種情形。</p>
<p><strong>標籤還沒有被引用</strong>：直接把限定語補回標籤，成本是一次。</p>
<p><strong>標籤已經是錨點</strong>：改動與全部引用點同一次進行，改完回頭跑一次同一條掃描確認沒有殘留舊字串。錨點斷開的失效形態跟 <a href="../reference-by-semantic-title-not-number/">#155</a> 的編號錯位同型——字面完好、語意 silent 指向錯的內容，比斷鏈難偵測。</p>
<hr>
<h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係</h2>
<table>
  <thead>
      <tr>
          <th>原則</th>
          <th>關係</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="../sentence-self-sufficiency-by-consumption-unit/">#261 語句要在它的消費單位內資訊自足</a></td>
          <td>母卡。#261 把檢索鍵位的義務定為識別充足並讓精簡優先；本卡給識別充足一個可執行的判斷標準，並限定那條優先序——鍵同時是跨檔錨點時，自足壓過精簡。</td>
      </tr>
      <tr>
          <td><a href="../compressed-chinese-terms-need-head-noun/">#108 中文壓縮術語要保留完整名詞頭</a></td>
          <td>互補的兩種壓縮。#108 管名詞頭被砍（殘片自己現形），本卡管名詞頭健在而限定語被砍（讀起來像完整術語）。#108 的四道檢查對本卡的形態全數放行，這一點是本卡存在的理由。</td>
      </tr>
      <tr>
          <td><a href="../reference-by-semantic-title-not-number/">#155 引用錨點用語意標題、不用位置編號</a></td>
          <td>錨點寫法家族的第一員。那裡的錨點是結構排列的 derivation，這裡的錨點是完整概念的壓縮；共同的失效是字面完好而語意 silent 指錯。</td>
      </tr>
      <tr>
          <td><a href="../name-collections-by-role-not-count/">#156 集合命名用角色、不內嵌數量</a></td>
          <td>家族的第二員：名字裡內嵌成員數。三員的共同結構是把只在作者側成立的前提寫進了標識符，而標識符會被複製。</td>
      </tr>
      <tr>
          <td><a href="../axis-named-by-proxy-not-mechanism/">#257 軸名取了次好的代理變數</a></td>
          <td>相鄰而不同。#257 的名字選了較弱的代理，機制寫在括號裡；本卡的名字選對了機制，砍掉的是限定語。兩者共用同一個對讀者的傷害——讀者只拿得到名字，作者讀名字時腦中補的是完整版。</td>
      </tr>
      <tr>
          <td><a href="../concept-used-but-never-named/">#321 從名字出發的術語檢查抓不到從未命名的概念</a></td>
          <td>同一種入口失配的另一端。#321 的名字頻率是零所以檢查走不到，本卡的名字語法合格所以檢查放行；兩者都由既有檢查的入口條件決定，跟審查認不認真無關。</td>
      </tr>
      <tr>
          <td><a href="../positioning-decides-form-before-any-rule-applies/">#302 定位決定體例</a></td>
          <td>本卡第二個實例的來源：那七種裝置的名字住在 #302，而完稿檢查清單引用時砍掉限定語，照清單執行的人因此拿到四個無法就地判定的標籤（已修）。</td>
      </tr>
  </tbody>
</table>
<hr>
<ul>
<li><a href="/blog/report/derived-operational-form-needs-its-own-check/" data-link-title="從原則卡壓出來的操作形要獨立驗一次，而本體正確正是它不被檢查的原因" data-link-desc="把原則卡壓成 checklist、規範段落或 skill 條目之後，用來判斷壓出來的那一份要不要獨立量測">#353 從原則卡壓出來的操作形要獨立驗一次</a>：同一個壓縮機制的另一個載體而軸不同。本卡的判斷標準是引用點數（被別處逐字引用兩處以上就要自足），那張的判斷標準是會不會被執行——衍生形通常只有一個消費點，而它是被照著做的那一個，所以引用一次也要自足。</li>
</ul>
<h2 id="判讀徵兆">判讀徵兆</h2>
<table>
  <thead>
      <tr>
          <th>訊號</th>
          <th>該做的事</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>有人問「這個標籤是什麼意思」</td>
          <td>回答所花的查詢步數就是量測值；把限定語補進標籤，讓下一個讀者直接讀得懂</td>
      </tr>
      <tr>
          <td>某個標籤在兩個以上的檔案裡逐字出現</td>
          <td>它是錨點，跑兩個判斷標準問句</td>
      </tr>
      <tr>
          <td>標籤的限定語寫在鄰欄或括號裡</td>
          <td>讀者先讀標籤才決定要不要讀鄰欄，把限定語搬進標籤本身</td>
      </tr>
      <tr>
          <td>同一組名字在不同檔案有長短兩版</td>
          <td>短版是壓縮的那一版，查它住在哪個消費位；住在檢查清單或路由表要優先修</td>
      </tr>
      <tr>
          <td>剛把一件事想清楚，正在替它取名</td>
          <td>限定語此刻讀起來像廢話，這是壓縮的觸發時點；判斷標準問句在這裡跑最便宜</td>
      </tr>
  </tbody>
</table>
<p><strong>核心</strong>：短名的收益結算一次，展開的代價由每一個讀者、每一個引用點各付一遍。標籤越像術語被到處引用，兩側的差距越大。</p>
]]></content:encoded></item><item><title>正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引</title><link>https://tarrragon.github.io/blog/report/ordinal-labels-are-the-authors-index/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/report/ordinal-labels-are-the-authors-index/</guid><description>&lt;p>正文裡每一個被反覆提到的對象都需要一個名字，而那個名字的職責跟程式裡的變數名稱相同：&lt;strong>讀者只看到這個名字，就知道它指的是什麼&lt;/strong>。「語意模型」「選寫法」「當場報錯」「日期差自連接」做得到這件事；「第一支」「第三步」「第一級」「A1」做不到——它們是作者替一份清單編的索引，要讀者手上也有那份清單才解得開。&lt;/p>
&lt;p>這一類名字在程式碼審查裡過不了關。沒有人會接受 &lt;code>branch1&lt;/code>、&lt;code>step3&lt;/code>、&lt;code>level1&lt;/code>、&lt;code>a1&lt;/code> 當變數名稱，理由是讀到呼叫點的人得跳回定義處才知道它是什麼，跟風格無關。教材裡同一個名字出現幾十次，每一次都是一個呼叫點。&lt;/p>
&lt;h2 id="失效的形態">失效的形態&lt;/h2>
&lt;p>一次 SQL 教材分類的全面檢視裡，這一類名字有三種形態，而三種常常出現在同一句裡。&lt;/p>
&lt;p>&lt;strong>計數當成集合的名字。&lt;/strong> 「三支」「七步」「兩個軸」「七個決定」。數字是成員數，不是這群成員共同的性質，所以讀者從「三支」得不到任何一支在講什麼。它同時是 &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;/p>
&lt;p>&lt;strong>序數當成成員的名字。&lt;/strong> 「第一支」「第三步」「第五節」「第一級」「前提一」。序數只說這個成員排在第幾個，而讀者需要的是它是什麼。這個形態在作者用它推導的時候最嚴重。一個分類的目錄頁寫過這樣一句：&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;strong>字母代號當成實體的名字。&lt;/strong> 一張表把五個寫法標成 A 到 E，之後正文寫「A 與 B 從寬鬆的那一家搬到嚴格的那一家時屬於這一級」「D 與 E 在這裡」；另一篇把四種查詢形態標成 A1、A2、B、C，之後寫「A1 與 A2 的差別只在條件的形狀」「C 的排名從最後一名跳到第一名」。每一個字母都要讀者回到表格對一次。那五個寫法各自有現成的描述——未分組欄位、WHERE 用別名、同表未取別名、字串比對、空值排序——字母省下的只是幾個字。&lt;/p>
&lt;h2 id="這一類名字從哪裡來">這一類名字從哪裡來&lt;/h2>
&lt;p>它們是作者整理結構時的工作語言。規劃一個分類的時候，作者把篇章分成幾組、把流程切成幾步，而在規劃階段用編號稱呼它們是合理的：成員還在變，內容名還沒定，編號是最便宜的把手。問題在工作語言沒有在交稿前換掉，而且它跟另一個缺陷一起出現——&lt;strong>作者把自己的編排思路寫進了正文&lt;/strong>。「本分類其餘各篇各自處理其中一步的機制，而讀者逐篇讀過去的時候看不出它們是同一條路上的七站」「兩個軸的用法不同：想理解這個語言為什麼長這樣，照三支讀」，這些句子在描述作者怎麼組織這個分類，而描述組織的時候最順手的詞就是組織用的編號。所以看到序數名字密集的段落，也要一併問這一段是不是在講作者的編排、而不是講主題。&lt;/p>
&lt;h2 id="為什麼既有的審查掃不到">為什麼既有的審查掃不到&lt;/h2>
&lt;p>作者與同源的 reviewer 都持有那張清單。寫的人剛定義完「三支」，讀的 reviewer 讀過整份規劃，兩者讀到「第一支」都能當場解開，所以這個名字在他們的閱讀裡沒有成本。成本只落在從搜尋或路由進來、落在中段的讀者身上，而審查的人不在那個位置。&lt;/p>
&lt;p>既有的規則管到了這一類，而觸發條件放在另一個時間點。&lt;a href="https://tarrragon.github.io/blog/report/reference-by-semantic-title-not-number/" data-link-title="引用章節用語意標題、不用位置編號：編號是結構排列的 derivation、會隨版本漂移" data-link-desc="跨段落、跨檔引用結構單位（章節 / 階段 / 條列項）時、引用語意標題（副標題）、不引用位置編號（Stage 3、第 5 章、第 3 點）。編號是「目前結構排列」的 derivation、不是 fact；結構重排時編號全部位移、引用點不會報錯、而是 silent 指向錯的內容 — 比 broken link 更難偵測。標題的存在意義就是承載可被引用的語意。是 #44 SSoT 在結構引用維度的實例、#93 identifier-as-fact 家族的 sibling、#84 命名承載語意的引用面延伸。">#155&lt;/a> 的〈類別序數〉一節已經要求把「第二類」「第五步」換成類別名，它的論證是&lt;strong>集合變動時序數會漂移&lt;/strong>——補了一類，九處「第三類」同時指錯。那個論證要等集合變動才成立，而這個分類的「三支」「七步」從寫成到檢視都沒有變過，於是每一輪審查都可以合理地判定它不漂移、放行。本卡的損害不需要等：&lt;strong>集合沒變的時候，每一次出現都要讀者回頭查一次&lt;/strong>。&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> 管的是標題裡嵌進成員數，同樣以成員增減為失效條件。字母代號（「A1」「D 與 E」）則兩張都沒有涵蓋，它不在任何標題裡，也不是類別序數。字句層 keyword bank 的「位置與集合指涉」列了「前者／後者／前兩篇」，列不到「第一支／第三步／第一級」，因為它是從論述文歸納的，而這一類的詞綴隨內容變（支、步、級、節、層、階段、前提、種）。&lt;/p>
&lt;h2 id="判讀方式">判讀方式&lt;/h2>
&lt;p>&lt;strong>變數名稱測試&lt;/strong>：把這個名字當成程式裡的變數名稱，它過不過得了程式碼審查。&lt;code>step3&lt;/code> 過不了，&lt;code>chooseQueryForm&lt;/code> 過得了。&lt;/p>
&lt;p>&lt;strong>落點測試&lt;/strong>：讀者從搜尋落在這一句，沒讀過前文，他知不知道這個名字指什麼。要翻回去查才知道的，就是作者的索引。&lt;/p>
&lt;p>掃描的入口是詞形，而詞綴要按內容換：&lt;/p>





&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-bash" data-lang="bash">&lt;span class="line">&lt;span class="ln">1&lt;/span>&lt;span class="cl">rg -n &lt;span class="s2">&amp;#34;[一二三四五六七八九十兩]支|[一二三四五六七八九十]步|第[一二三四五六七八九十][步支節級層章階種類條項]|前提[一二三四五]|兩個軸|另一個軸|這個軸&amp;#34;&lt;/span> content/&amp;lt;分類&amp;gt;
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">2&lt;/span>&lt;span class="cl">rg -n &lt;span class="s2">&amp;#34;\b[A-E][0-9]?\b 那|\b[A-E][0-9]? 與 [A-E][0-9]?\b&amp;#34;&lt;/span> content/&amp;lt;分類&amp;gt;&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>命中是候選。三種情形合規：緊鄰清單、隨即逐一具名展開的計數（「下面四個追問」後面立刻列出四個）；量測事實裡的數字（「差三個量級」「七十倍」）；外部凍結的編號（RFC 段號、法條、題號）。一段文字裡序數確實是順序本身的時候——「寫在最前面的 &lt;code>SELECT&lt;/code> 在語意上排在倒數第二步」，前一句剛列完那串步驟——它描述的是位置，不是在當名字用。&lt;/p>
&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;code>the-seven-steps&lt;/code> 也是。改名時用 Hugo 的 &lt;code>aliases&lt;/code> 保留舊網址，站內連結全部改到新網址。&lt;/p>
&lt;p>&lt;strong>跟著刪掉編排思路。&lt;/strong> 描述「各篇怎麼分組」「兩篇怎麼分工」「改哪一篇」的句子是作者的維護資訊，不是讀者要的內容。讀者需要的只有範圍交代，而範圍交代要帶內容名（「列數那一半在〈連接產出的是新的關係〉那一篇」）。&lt;/p>
&lt;h2 id="論述基礎與限制">論述基礎與限制&lt;/h2>
&lt;p>證據來自一個 SQL 教材分類的一次檢視：目錄頁有十七處序數或計數名字，一篇總覽文章十一處，一篇實例文章八處，加上兩篇文章的字母代號共五十五處。一個分類的一次觀測只證明這一類名字會在全面檢視後殘留、而且會集中在規劃結構的那幾頁，不證明它在每個分類的密度都這麼高。掃描指令的詞綴也是從這一個分類歸納的，換到別的分類要先盤點那裡用的是哪些詞綴。&lt;/p>
&lt;h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係&lt;/h2>
&lt;ul>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/reference-by-semantic-title-not-number/" data-link-title="引用章節用語意標題、不用位置編號：編號是結構排列的 derivation、會隨版本漂移" data-link-desc="跨段落、跨檔引用結構單位（章節 / 階段 / 條列項）時、引用語意標題（副標題）、不引用位置編號（Stage 3、第 5 章、第 3 點）。編號是「目前結構排列」的 derivation、不是 fact；結構重排時編號全部位移、引用點不會報錯、而是 silent 指向錯的內容 — 比 broken link 更難偵測。標題的存在意義就是承載可被引用的語意。是 #44 SSoT 在結構引用維度的實例、#93 identifier-as-fact 家族的 sibling、#84 命名承載語意的引用面延伸。">#155 引用章節用語意標題、不用位置編號&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/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/counted-summary-delivers-only-the-length/" data-link-title="摘要另一份內容時寫出成員，計數只告訴讀者清單有多長" data-link-desc="介紹另一篇、寫 description、填目錄頁的交付欄時，寫出了「四個追問、三種寫法、四類邊界」這種句子，讀者仍要點進去才知道那些是什麼時回來讀">#364 摘要另一份內容時寫出成員，計數只告訴讀者清單有多長&lt;/a>——同一個成因的另一個位置：本卡是計數或序數當成一個對象的名字，#364 是計數當成一段摘要的全部內容；計數式摘要沒有被當成名字，所以本卡的掃描放過它。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/naming-as-iterated-artifact/" data-link-title="Naming 是 iterated artifact：第一個名字幾乎不對、四輪 review 才收斂" data-link-desc="命名（變數 / 函式 / 檔名 / slug / API endpoint）幾乎沒有「一次寫對」的可能：第一個名字基於當下狹窄的 context、會在後續 cross-call-site / grep / 重構中暴露錯位。命名的正確設計是 iterated — 寫第一版 → grep-ability 測試 → cross-call-site 一致性 → impl 洩漏 → 重命名。本卡是 #83 在「命名」場景的特化。">#84 Naming 是 iterated artifact&lt;/a>——規劃階段的編號是第一版命名，本卡是那一條在教材上的具體出口：交稿前第一版的工作語言要換成內容名。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/unnamed-halves-are-unextracted-variables/" data-link-title="切開一個集合之前先寫切分的依據，再替每一塊命名；「一部分」「另一半」是還沒抽出來的變數" data-link-desc="文章用「一部分交得出去」「交不出去的那一半」「那一側」指稱一個被切開的集合，讀者說不出每一塊是什麼、為什麼這樣切時回來讀">#367 切開一個集合之前先寫切分的依據，再替每一塊命名&lt;/a>——本卡管已有名字而名字是索引的對象；那一張管還沒被命名、只以「一部分」「另一半」出現的對象，並補上先寫切分依據這一步。&lt;/li>
&lt;/ul>
&lt;h2 id="case">Case&lt;/h2>
&lt;p>2026-09-24，SQL 教材分類。使用者先指出總覽文章開頭一段「這七個決定⋯⋯讀者逐篇讀過去的時候看不出它們是同一條路上的七站」是作者的寫作脈絡，不該寫進文章；接著指出同一篇「三支與七步的對應」「同一步」「另一個軸」這些名字是最糟的寫法，因為它們在程式碼裡絕不會被接受。那一篇與它的實例文章在寫成當天走過三輪多輪審查，第二輪含理解探針，而這一類名字沒有被任何一輪回報。改寫的範圍擴到整個分類：三個分組改用各自的問題命名，步驟改用動作名，引擎差異的四個分級改用判斷標準命名，兩篇的字母代號換成描述，總覽文章的標題與網址一併改名。同一天稍後的逐段審查又在〈合不合法由引擎驗〉找到「第一種／第二種／第三種錯法」被單獨引用十餘次，這一篇在上述改寫裡被漏掉，原因是掃描指令的詞綴清單沒有「種」——補上之後正對照命中。這一條示範了本卡「詞綴要按內容盤點」那句限制的實際代價。&lt;/p></description><content:encoded><![CDATA[<p>正文裡每一個被反覆提到的對象都需要一個名字，而那個名字的職責跟程式裡的變數名稱相同：<strong>讀者只看到這個名字，就知道它指的是什麼</strong>。「語意模型」「選寫法」「當場報錯」「日期差自連接」做得到這件事；「第一支」「第三步」「第一級」「A1」做不到——它們是作者替一份清單編的索引，要讀者手上也有那份清單才解得開。</p>
<p>這一類名字在程式碼審查裡過不了關。沒有人會接受 <code>branch1</code>、<code>step3</code>、<code>level1</code>、<code>a1</code> 當變數名稱，理由是讀到呼叫點的人得跳回定義處才知道它是什麼，跟風格無關。教材裡同一個名字出現幾十次，每一次都是一個呼叫點。</p>
<h2 id="失效的形態">失效的形態</h2>
<p>一次 SQL 教材分類的全面檢視裡，這一類名字有三種形態，而三種常常出現在同一句裡。</p>
<p><strong>計數當成集合的名字。</strong> 「三支」「七步」「兩個軸」「七個決定」。數字是成員數，不是這群成員共同的性質，所以讀者從「三支」得不到任何一支在講什麼。它同時是 <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> 的形態——成員數一變名字就失真——而這裡的損害先於失真：成員數沒變的時候它已經讀不懂。</p>
<p><strong>序數當成成員的名字。</strong> 「第一支」「第三步」「第五節」「第一級」「前提一」。序數只說這個成員排在第幾個，而讀者需要的是它是什麼。這個形態在作者用它推導的時候最嚴重。一個分類的目錄頁寫過這樣一句：</p>
<blockquote>
<p>第一支的篇落在七步的第三、四、六步，第二支落在第五、七步，第三支落在第七步。</p></blockquote>
<p>這句話是兩份索引的對照表，裡面沒有任何一個詞指向內容。讀者要同時持有「三支各是什麼」與「七步各是什麼」兩張清單才解得開，而作者寫它的時候兩張清單都在腦中，所以讀起來精確。改成用內容命名之後是：</p>
<blockquote>
<p>講語意模型的篇用在選寫法、補前提、對邊界這幾個決定上，講文字之外的決定者的篇用在量代價與交付上。</p></blockquote>
<p><strong>字母代號當成實體的名字。</strong> 一張表把五個寫法標成 A 到 E，之後正文寫「A 與 B 從寬鬆的那一家搬到嚴格的那一家時屬於這一級」「D 與 E 在這裡」；另一篇把四種查詢形態標成 A1、A2、B、C，之後寫「A1 與 A2 的差別只在條件的形狀」「C 的排名從最後一名跳到第一名」。每一個字母都要讀者回到表格對一次。那五個寫法各自有現成的描述——未分組欄位、WHERE 用別名、同表未取別名、字串比對、空值排序——字母省下的只是幾個字。</p>
<h2 id="這一類名字從哪裡來">這一類名字從哪裡來</h2>
<p>它們是作者整理結構時的工作語言。規劃一個分類的時候，作者把篇章分成幾組、把流程切成幾步，而在規劃階段用編號稱呼它們是合理的：成員還在變，內容名還沒定，編號是最便宜的把手。問題在工作語言沒有在交稿前換掉，而且它跟另一個缺陷一起出現——<strong>作者把自己的編排思路寫進了正文</strong>。「本分類其餘各篇各自處理其中一步的機制，而讀者逐篇讀過去的時候看不出它們是同一條路上的七站」「兩個軸的用法不同：想理解這個語言為什麼長這樣，照三支讀」，這些句子在描述作者怎麼組織這個分類，而描述組織的時候最順手的詞就是組織用的編號。所以看到序數名字密集的段落，也要一併問這一段是不是在講作者的編排、而不是講主題。</p>
<h2 id="為什麼既有的審查掃不到">為什麼既有的審查掃不到</h2>
<p>作者與同源的 reviewer 都持有那張清單。寫的人剛定義完「三支」，讀的 reviewer 讀過整份規劃，兩者讀到「第一支」都能當場解開，所以這個名字在他們的閱讀裡沒有成本。成本只落在從搜尋或路由進來、落在中段的讀者身上，而審查的人不在那個位置。</p>
<p>既有的規則管到了這一類，而觸發條件放在另一個時間點。<a href="/blog/report/reference-by-semantic-title-not-number/" data-link-title="引用章節用語意標題、不用位置編號：編號是結構排列的 derivation、會隨版本漂移" data-link-desc="跨段落、跨檔引用結構單位（章節 / 階段 / 條列項）時、引用語意標題（副標題）、不引用位置編號（Stage 3、第 5 章、第 3 點）。編號是「目前結構排列」的 derivation、不是 fact；結構重排時編號全部位移、引用點不會報錯、而是 silent 指向錯的內容 — 比 broken link 更難偵測。標題的存在意義就是承載可被引用的語意。是 #44 SSoT 在結構引用維度的實例、#93 identifier-as-fact 家族的 sibling、#84 命名承載語意的引用面延伸。">#155</a> 的〈類別序數〉一節已經要求把「第二類」「第五步」換成類別名，它的論證是<strong>集合變動時序數會漂移</strong>——補了一類，九處「第三類」同時指錯。那個論證要等集合變動才成立，而這個分類的「三支」「七步」從寫成到檢視都沒有變過，於是每一輪審查都可以合理地判定它不漂移、放行。本卡的損害不需要等：<strong>集合沒變的時候，每一次出現都要讀者回頭查一次</strong>。<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> 管的是標題裡嵌進成員數，同樣以成員增減為失效條件。字母代號（「A1」「D 與 E」）則兩張都沒有涵蓋，它不在任何標題裡，也不是類別序數。字句層 keyword bank 的「位置與集合指涉」列了「前者／後者／前兩篇」，列不到「第一支／第三步／第一級」，因為它是從論述文歸納的，而這一類的詞綴隨內容變（支、步、級、節、層、階段、前提、種）。</p>
<h2 id="判讀方式">判讀方式</h2>
<p><strong>變數名稱測試</strong>：把這個名字當成程式裡的變數名稱，它過不過得了程式碼審查。<code>step3</code> 過不了，<code>chooseQueryForm</code> 過得了。</p>
<p><strong>落點測試</strong>：讀者從搜尋落在這一句，沒讀過前文，他知不知道這個名字指什麼。要翻回去查才知道的，就是作者的索引。</p>
<p>掃描的入口是詞形，而詞綴要按內容換：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">rg -n <span class="s2">&#34;[一二三四五六七八九十兩]支|[一二三四五六七八九十]步|第[一二三四五六七八九十][步支節級層章階種類條項]|前提[一二三四五]|兩個軸|另一個軸|這個軸&#34;</span> content/&lt;分類&gt;
</span></span><span class="line"><span class="ln">2</span><span class="cl">rg -n <span class="s2">&#34;\b[A-E][0-9]?\b 那|\b[A-E][0-9]? 與 [A-E][0-9]?\b&#34;</span> content/&lt;分類&gt;</span></span></code></pre></div><p>命中是候選。三種情形合規：緊鄰清單、隨即逐一具名展開的計數（「下面四個追問」後面立刻列出四個）；量測事實裡的數字（「差三個量級」「七十倍」）；外部凍結的編號（RFC 段號、法條、題號）。一段文字裡序數確實是順序本身的時候——「寫在最前面的 <code>SELECT</code> 在語意上排在倒數第二步」，前一句剛列完那串步驟——它描述的是位置，不是在當名字用。</p>
<h2 id="修法">修法</h2>
<p><strong>用它是什麼來命名。</strong> 分組用它回答的問題（「語意模型」「文字之外的決定者」），流程的步驟用動作（「追問需求」「選寫法」「量代價」），分級用它的判斷標準（「當場報錯」「等資料才報錯」「靜默而輸出不同」「靜默且輸出相同」），並排的做法用描述（「日期差自連接」「等值自連接」）。名字長一點沒關係——它要讓讀者不必翻回去，而那個成本乘上它出現的次數。</p>
<p><strong>段標的序號拿掉，引用改成節名或內容。</strong> 「第五節那張表」改成「代價量測那張表」。段標保留序號時，作者會持續用序號引用它，所以拿掉序號是讓這個習慣沒有把手。</p>
<p><strong>標題與網址裡的計數一起改。</strong> 「這條路有七步」這種標題把計數當成全篇的主題詞，網址 <code>the-seven-steps</code> 也是。改名時用 Hugo 的 <code>aliases</code> 保留舊網址，站內連結全部改到新網址。</p>
<p><strong>跟著刪掉編排思路。</strong> 描述「各篇怎麼分組」「兩篇怎麼分工」「改哪一篇」的句子是作者的維護資訊，不是讀者要的內容。讀者需要的只有範圍交代，而範圍交代要帶內容名（「列數那一半在〈連接產出的是新的關係〉那一篇」）。</p>
<h2 id="論述基礎與限制">論述基礎與限制</h2>
<p>證據來自一個 SQL 教材分類的一次檢視：目錄頁有十七處序數或計數名字，一篇總覽文章十一處，一篇實例文章八處，加上兩篇文章的字母代號共五十五處。一個分類的一次觀測只證明這一類名字會在全面檢視後殘留、而且會集中在規劃結構的那幾頁，不證明它在每個分類的密度都這麼高。掃描指令的詞綴也是從這一個分類歸納的，換到別的分類要先盤點那裡用的是哪些詞綴。</p>
<h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係</h2>
<ul>
<li><a href="/blog/report/reference-by-semantic-title-not-number/" data-link-title="引用章節用語意標題、不用位置編號：編號是結構排列的 derivation、會隨版本漂移" data-link-desc="跨段落、跨檔引用結構單位（章節 / 階段 / 條列項）時、引用語意標題（副標題）、不引用位置編號（Stage 3、第 5 章、第 3 點）。編號是「目前結構排列」的 derivation、不是 fact；結構重排時編號全部位移、引用點不會報錯、而是 silent 指向錯的內容 — 比 broken link 更難偵測。標題的存在意義就是承載可被引用的語意。是 #44 SSoT 在結構引用維度的實例、#93 identifier-as-fact 家族的 sibling、#84 命名承載語意的引用面延伸。">#155 引用章節用語意標題、不用位置編號</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/decodable-from-text-already-read/" data-link-title="敘事的解碼材料要在讀者已讀的文本裡，不在作者的地圖裡" data-link-desc="教學敘事出現不具名的指涉、只給一面的對比或留給讀者自推的結論時，用來判定哪些壓縮手法把解碼成本轉嫁給了讀者、以及各自怎麼展開">#270 敘事的解碼材料要在讀者已讀的文本裡</a>——序數與代號是「作者的地圖」最純粹的形態：解碼它需要的正是那張地圖本身。</li>
<li><a href="/blog/report/counted-summary-delivers-only-the-length/" data-link-title="摘要另一份內容時寫出成員，計數只告訴讀者清單有多長" data-link-desc="介紹另一篇、寫 description、填目錄頁的交付欄時，寫出了「四個追問、三種寫法、四類邊界」這種句子，讀者仍要點進去才知道那些是什麼時回來讀">#364 摘要另一份內容時寫出成員，計數只告訴讀者清單有多長</a>——同一個成因的另一個位置：本卡是計數或序數當成一個對象的名字，#364 是計數當成一段摘要的全部內容；計數式摘要沒有被當成名字，所以本卡的掃描放過它。</li>
<li><a href="/blog/report/naming-as-iterated-artifact/" data-link-title="Naming 是 iterated artifact：第一個名字幾乎不對、四輪 review 才收斂" data-link-desc="命名（變數 / 函式 / 檔名 / slug / API endpoint）幾乎沒有「一次寫對」的可能：第一個名字基於當下狹窄的 context、會在後續 cross-call-site / grep / 重構中暴露錯位。命名的正確設計是 iterated — 寫第一版 → grep-ability 測試 → cross-call-site 一致性 → impl 洩漏 → 重命名。本卡是 #83 在「命名」場景的特化。">#84 Naming 是 iterated artifact</a>——規劃階段的編號是第一版命名，本卡是那一條在教材上的具體出口：交稿前第一版的工作語言要換成內容名。</li>
<li><a href="/blog/report/unnamed-halves-are-unextracted-variables/" data-link-title="切開一個集合之前先寫切分的依據，再替每一塊命名；「一部分」「另一半」是還沒抽出來的變數" data-link-desc="文章用「一部分交得出去」「交不出去的那一半」「那一側」指稱一個被切開的集合，讀者說不出每一塊是什麼、為什麼這樣切時回來讀">#367 切開一個集合之前先寫切分的依據，再替每一塊命名</a>——本卡管已有名字而名字是索引的對象；那一張管還沒被命名、只以「一部分」「另一半」出現的對象，並補上先寫切分依據這一步。</li>
</ul>
<h2 id="case">Case</h2>
<p>2026-09-24，SQL 教材分類。使用者先指出總覽文章開頭一段「這七個決定⋯⋯讀者逐篇讀過去的時候看不出它們是同一條路上的七站」是作者的寫作脈絡，不該寫進文章；接著指出同一篇「三支與七步的對應」「同一步」「另一個軸」這些名字是最糟的寫法，因為它們在程式碼裡絕不會被接受。那一篇與它的實例文章在寫成當天走過三輪多輪審查，第二輪含理解探針，而這一類名字沒有被任何一輪回報。改寫的範圍擴到整個分類：三個分組改用各自的問題命名，步驟改用動作名，引擎差異的四個分級改用判斷標準命名，兩篇的字母代號換成描述，總覽文章的標題與網址一併改名。同一天稍後的逐段審查又在〈合不合法由引擎驗〉找到「第一種／第二種／第三種錯法」被單獨引用十餘次，這一篇在上述改寫裡被漏掉，原因是掃描指令的詞綴清單沒有「種」——補上之後正對照命中。這一條示範了本卡「詞綴要按內容盤點」那句限制的實際代價。</p>
]]></content:encoded></item><item><title>切開一個集合之前先寫切分的依據，再替每一塊命名；「一部分」「另一半」是還沒抽出來的變數</title><link>https://tarrragon.github.io/blog/report/unnamed-halves-are-unextracted-variables/</link><pubDate>Tue, 29 Sep 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/report/unnamed-halves-are-unextracted-variables/</guid><description>&lt;p>把一個集合切成幾塊來討論時，「一部分」「另一半」「那一側」「這部分」只說了有一刀，沒說刀落在哪裡、每一塊是什麼。讀者要自己從例子裡歸納出切分的依據，歸納出來的還未必是作者的那一個。修法跟重構程式時抽變數是同一個動作：&lt;strong>先寫出切分的依據（為什麼這一塊做得到、那一塊做不到），再替每一塊取名字，之後只用名字指它&lt;/strong>。名字依序從三處找：業界已有的術語、文章裡現成的案例名、最後才是一個描述內容的短語。&lt;/p>
&lt;h2 id="失效的形態">失效的形態&lt;/h2>
&lt;p>一篇 SQL 教材討論「答案對不對」這一層能不能交給機器判斷，原文三段的開頭是：&lt;/p>
&lt;blockquote>
&lt;p>交不出那條判定，而這裡仍有一部分不必等人來判。&lt;/p>
&lt;p>有一部分判斷標準交得出去。&lt;/p>
&lt;p>交不出去的那一半仍然有一個可以機械化的做法。&lt;/p>&lt;/blockquote>
&lt;p>同一個集合被切了三次，三塊都沒有名字，而三刀的依據各不相同，分散在段落中段的一句話裡（「交得出去的界線落在判斷需要什麼」只解釋了約束那一刀）。讀到「交不出去的那一半」時，讀者要先決定它指的是「這裡仍有一部分」切剩的、還是「有一部分判斷標準交得出去」切剩的。&lt;/p>
&lt;p>同一節的最後一段是反例——它做對了：&lt;/p>
&lt;blockquote>
&lt;p>預期值從哪裡取得叫 test oracle……「寫斷言的人與寫實作的人共用同一份誤解」叫 test provenance；而「造不出分岔的資料」在 Mutation Testing 裡叫 equivalent mutant。&lt;/p>&lt;/blockquote>
&lt;p>三個概念都已經在別處定義過、有公認的名字，所以一句話就能引用三次，讀者不必重建任何定義。&lt;/p>
&lt;p>改寫之後，那一節開頭先寫依據：一項判斷能不能交給機器，看判斷時要讀的資訊機器在那一刻讀不讀得到——引擎收到查詢時讀得到查詢文字與表結構，資料庫寫入時讀得到那一筆資料與它指向的列，「要問的是什麼」只有提問的人知道。依據寫出來之後三塊各有名字：只讀查詢文字與表結構的是&lt;strong>靜態分析&lt;/strong>，只讀寫入那一筆的是&lt;strong>約束&lt;/strong>，要讀「要問的是什麼」的只能記成一筆&lt;strong>反例資料&lt;/strong>（counterexample）。之後每一段都用名字開頭。&lt;/p>
&lt;h2 id="取名這一步會逼出內容">取名這一步會逼出內容&lt;/h2>
&lt;p>找業界名字不只是換標籤。「這裡仍有一部分不必等人來判」要改叫靜態分析，就得說出靜態分析在這個例子上實際判得出什麼——追下去找到的是最佳化器本身就做這個判斷：&lt;code>WHERE 評價.星等 &amp;lt;&amp;gt; 5&lt;/code> 讓 &lt;code>LEFT JOIN&lt;/code> 失效，PostgreSQL 16 的 &lt;code>EXPLAIN&lt;/code> 對那段查詢印 &lt;code>Hash Join&lt;/code>、對正解印 &lt;code>Hash Left Join&lt;/code>，MySQL 8 把它改寫成內連接。原文的「那個 &lt;code>LEFT&lt;/code> 是死的」是一句斷言，取名之後它變成讀者可以自己跑一次驗證的現象。&lt;/p>
&lt;p>「分岔的資料」換成「反例資料」也一樣：反例在邏輯裡的意思是「兩段查詢在它上面答案不同，就證明兩者不等價」，這個定義順手把最後一段的 equivalent mutant 接上了——造不出反例資料，就是兩段查詢等價。自創的「分岔的資料」接不上任何既有概念。&lt;/p>
&lt;p>同一篇第二輪把成因分類與反例資料的狀態也命名之後，又對出兩處：成因那一節寫「問錯了問題，換引擎、加約束、跑靜態分析都碰不到」，而後面一節寫靜態分析判得出「不等於五」——兩類有了名字，才看得出「不等於五」同時屬於「誤解語意模型」，靜態分析判出的是後者；「這幾種狀態」列了四種資料狀態並說三種錯法都發生在上面，而「漏掉星等」的反例（某張訂單的評價全部不是五星）不在清單裡、清單裡的「指不到任何一列的編號」三種錯法都用不到。改叫等價類劃分（equivalence partitioning）並把資料實際寫出來跑過一次，清單才對得上。&lt;/p>
&lt;h2 id="為什麼命名的既有規則沒擋住">為什麼命名的既有規則沒擋住&lt;/h2>
&lt;p>&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> 要求正文裡的對象用內容命名，掃的是序數、計數與字母代號（「第一支」「三步」「A1」）。那些字面上就是索引，一眼看得出來。「一部分」「另一半」不是索引，它們是&lt;strong>切分動作本身&lt;/strong>：作者寫下的時候手上有切法，所以對他來說「那一半」跟「約束那一類」一樣清楚，而 #363 的變數名稱測試問的是「這個名字能不能當變數」，「那一半」根本沒有被當成名字寫下，測試不觸發。&lt;/p>
&lt;p>跟 &lt;a href="https://tarrragon.github.io/blog/report/noun-without-its-owner-passes-the-slot-check/" data-link-title="名詞要求的「誰的、什麼的」也是槽位，論斷句與段標的省略藏在名詞裡" data-link-desc="句子主詞謂語都在、讀起來通順，而讀者說不出「誰的輸出」「什麼的來源」；或段標、總結句用了只寫在目錄頁的框架詞時回來讀">#366&lt;/a> 的關係是同一個成因的兩個尺度：#366 是一個名詞缺了所屬（「誰的輸出」），這一張是一整個集合缺了切分依據與成員名——「一部分」要求的所屬是「什麼的一部分、按什麼切出來的哪一部分」，句內兩樣都沒有。&lt;/p>
&lt;h2 id="偵測與它的射程">偵測與它的射程&lt;/h2>
&lt;p>字詞層掃得到候選：&lt;code>一部分|另一半|這一半|那一半|這部分|那部分|另一部分|那一側|這一側|另一側|另一邊&lt;/code>。在 SQL 分類 24 篇與知識卡上跑一次，程式碼區塊外 68 處命中，判定要改的 20 處。&lt;/p>
&lt;p>不用改的那些，所屬寫在同一句：「子表這一側是填進一個指不到的值，父表那一側是把還被指著的那一列刪掉」「反連接留下的是另一半——左邊那些在右邊配不到任何對象的列」。要改的那些分兩種：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>半邊沒有名字&lt;/strong>：「補決勝鍵只解決了並列那一半」（另一半是翻頁途中的寫入，要到另一篇才看得到）、「規則沒有規定的那一半」「列數那一半在 1.6」。改成直接寫出那一塊：「治得好並列造成的重複與遺漏、治不好翻頁途中有人寫入造成的那一種」。&lt;/li>
&lt;li>&lt;strong>「一側」當譬喻&lt;/strong>：「在條件這一側還有路」「語言這一側發生什麼」「代價那一側它是逐列執行的」。這裡沒有被切開的集合，「一側」只是換了個說法的「就……而言」，改成直接寫主詞（「改寫條件本身就能讓它走索引」）。&lt;/li>
&lt;/ul>
&lt;p>grep 分不出兩者與合規句，命中之後逐句問：&lt;strong>讀者只讀這一句，說不說得出這一塊是什麼、另一塊是什麼&lt;/strong>。另外，切分依據沒寫出來這件事沒有字詞可掃——三刀之中真正缺的是依據，而依據的缺席沒有痕跡。寫到「一部分」的當下先回答「按什麼切的」，再把答案寫在第一次切的位置。&lt;/p>
&lt;h2 id="修法">修法&lt;/h2>
&lt;ul>
&lt;li>&lt;strong>先寫依據&lt;/strong>：切開一個集合的第一句寫出「按什麼切」，而且是一個可以逐項判定的標準（「判斷時要讀什麼」），不是結果的描述（「有的交得出去」）。&lt;/li>
&lt;li>&lt;strong>再命名&lt;/strong>：業界有術語就用術語（靜態分析、約束、counterexample），並寫一句它在本文例子上的樣子；沒有術語就用文章裡的案例名（「不等於五的錯法」）；兩者都沒有才用描述短語。&lt;/li>
&lt;li>&lt;strong>之後只用名字&lt;/strong>：段落首句用名字開頭（「靜態分析只讀查詢的文字與表的結構」），不再用「這一部分」「另一半」回指。&lt;/li>
&lt;li>&lt;strong>審查端列為必修&lt;/strong>：教材逐段審查把「一個被反覆談論的概念沒有被界定與命名就被引用」列為必修，逐個概念點名檢查。審查者手上有作者的切法，讀到「那一半」解得開，所以靠讀起來順不順判斷永遠通過。同一條也涵蓋沒有字詞可掃的那一種：同一個概念每次換一個描述重講一次，讀者分不出幾次講的是不是同一件事——那是程式裡重複的運算式，一樣要抽成變數。&lt;/li>
&lt;li>&lt;strong>連到切分的句子一起改&lt;/strong>：別篇引用這個切分時用的也是「一部分交得出去」，要一併換成名字，否則讀者在兩篇之間拿到兩套說法。&lt;/li>
&lt;/ul>
&lt;h2 id="命名由句子結構完成取名的動作不寫進正文">命名由句子結構完成，取名的動作不寫進正文&lt;/h2>
&lt;p>一篇服務端監控的教材照這張卡先界定再命名，寫成：「一個觀察者的盲區有兩種，各取一個名字，下文都用這兩個名字。&lt;strong>問題盲區&lt;/strong>是……&lt;strong>位置盲區&lt;/strong>是……」。中間那個子句描述的是作者正在做的事（取名、約定下文怎麼用），刪掉之後讀者什麼都沒少：粗體與緊跟的定義已經完成命名，之後一律用名字是寫的人自己的紀律，不必向讀者宣告。&lt;/p>
&lt;p>命名交給句子結構：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>成員只有兩三個&lt;/strong>：一句寫完分類與成員的名字，下一句起逐一定義。「一個觀察者的盲區分成問題盲區與位置盲區。問題盲區是……」&lt;/li>
&lt;li>&lt;strong>成員更多&lt;/strong>：用清單列出名字，每一項可以附一句判別依據，下一段起逐一解釋。清單用編號只是版面，正文引用時仍然用名字。&lt;/li>
&lt;/ul>
&lt;p>判讀用刪除測試：&lt;strong>刪掉這個子句，讀者少了什麼。&lt;/strong> 少了名字或它的所指就留下——「下文把主機、容器、資料庫、快取與入口這些組成服務的單位稱為&lt;strong>元件&lt;/strong>」刪掉之後讀者不知道元件指什麼；什麼都沒少的刪掉——「各取一個名字」「下文都用這兩個名字」「以下逐一說明」。&lt;/p>
&lt;p>這個形態是執行本卡規則的副作用：規則描述的是寫的人要做的動作（先界定、再命名），寫的人把動作本身寫進了正文。它和 &lt;a href="https://tarrragon.github.io/blog/report/coherence-by-advancing-not-recapping/" data-link-title="連貫靠句句推進：讀者付出的每一次閱讀成本都要換到內容" data-link-desc="段落讀起來不連貫、或發現自己在寫過場句把前文摘一次再出發時，用來判斷哪些字該刪、譬喻該不該留、說明順序該由什麼驅動">#285&lt;/a> 的文章自指是同一類，讀者讀的是主題，不是文章怎麼安排自己。&lt;/p>
&lt;h2 id="全站掃過一次之後模糊的切分會藏住錯的論斷">全站掃過一次之後：模糊的切分會藏住錯的論斷&lt;/h2>
&lt;p>SQL 以外的分類另有 550 處候選，分十批交給篩選者（判定只看目標句與前一句、不改要附逐字依據），判定要改 89 處，主 session 重讀依據薄弱的不改項後再改 7 處，約六分之一。不改的多數是組成句「X 是 Y 的一部分」——部分與整體都寫在句內，沒有切開任何集合；這一類可以直接豁免。&lt;/p>
&lt;p>篩選者回報了規則原先沒寫到的三種形態：&lt;/p>
&lt;ul>
&lt;li>&lt;strong>每一塊有名字、被切開的整體沒有&lt;/strong>：「purgeable 是同一條線的另一半」「環境那一半的論證」——讀者知道這一半叫什麼，不知道它是什麼的一半。四個批次各自遇到，判定不一致，所以要寫進規則：整體也要在這一句或前一句具名。&lt;/li>
&lt;li>&lt;strong>裸「這部分」回指，而前面沒有切分&lt;/strong>：「或把這部分 relationalize」前一句有兩個名詞都可能是先行詞；「必要時用 &lt;code>chvt&lt;/code> 切到別的 VT，這部分見……」跟在一長串操作之後。這是指涉問題，修法相同：寫出那一塊的名字。&lt;/li>
&lt;li>&lt;strong>同一組東西混用幾個詞、或同一個詞指兩塊&lt;/strong>：「單邊／那一腳／那一邊」指同一組兩腳；「只算資本這一邊（……談的是資本的另一半）」讓「資本」同時指資金與人力資本。命名時整組一起定，一個名字只指一塊。&lt;/li>
&lt;/ul>
&lt;p>最值得記的是另一件事：&lt;strong>有兩處模糊的切分底下是錯的論斷。&lt;/strong> 存活者偏誤那一篇的通則寫「往被高估那一側走還是贏的結論仍然成立，靠近基準的指控型結論不成立」，而前一行才寫明觀察值是下界時「低於基準」存活——通則只在上界時成立。保證金模式那張卡寫「這個預設在猜錯時付出的是資金效率，猜對的另一邊付出的是同時被清算」，「另一邊」其實是反向的預設猜錯時，句子把邏輯寫反了。兩句讀起來都通順，因為「那一側」「另一邊」不必決定指的是什麼；替它們命名的時候才發現對不上。&lt;/p>
&lt;p>反方向也發生了一次：篩選者替「purgeable 是同一條線的另一半」取名，寫成「與本地快照並列的另一個根因」，而同一段寫明 purgeable 主要由快照構成，兩者不並列。&lt;strong>命名會逼作者決定所指，而決定錯了就把一個錯誤寫進文章&lt;/strong>，所以替換文字裡新出現的關係（並列、包含、因果）要回原文核對。&lt;/p>
&lt;h2 id="論述基礎與限制">論述基礎與限制&lt;/h2>
&lt;p>依據是一次改寫：一篇文章的一節加上 SQL 分類的全掃（68 處候選、20 處改動，判定由主 session 做），以及其餘分類的全掃（550 處候選、96 處改動，篩選者判定、主 session 抽查與核對）。「取名會逼出內容」觀察到四例（最佳化器的外連接化簡、反例接上 equivalent mutant、兩處寫反的論斷），不代表每一次命名都會找到新材料。&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>——那一張管已經有名字而名字是索引的對象；本卡管還沒被命名、只以切分動作出現的對象，並補上「先寫依據」這一步。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/noun-without-its-owner-passes-the-slot-check/" data-link-title="名詞要求的「誰的、什麼的」也是槽位，論斷句與段標的省略藏在名詞裡" data-link-desc="句子主詞謂語都在、讀起來通順，而讀者說不出「誰的輸出」「什麼的來源」；或段標、總結句用了只寫在目錄頁的框架詞時回來讀">#366 名詞要求的「誰的、什麼的」也是槽位&lt;/a>——一個名詞缺所屬；「一部分」缺的所屬是整個切法。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/counted-summary-delivers-only-the-length/" data-link-title="摘要另一份內容時寫出成員，計數只告訴讀者清單有多長" data-link-desc="介紹另一篇、寫 description、填目錄頁的交付欄時，寫出了「四個追問、三種寫法、四類邊界」這種句子，讀者仍要點進去才知道那些是什麼時回來讀">#364 計數式摘要只交付清單的長度&lt;/a>——「三種寫法」只給長度、不給成員；「一部分」連長度都沒給，只給了有一刀。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/reviewer-holds-the-map-readers-land-without-it/" data-link-title="逐段審查量讀者學不學得會，指稱解不解得開要問沒讀過前文的讀者" data-link-desc="教材走過逐段審查，仍殘留隔好幾段的「上面那一組」「兩者」、計數對不上成員、或解法只對列出的一部分成立的段落，而審查回報幾乎沒有這些項目時回來讀">#365 逐段審查量讀者學不學得會&lt;/a>——作者與審查者手上有切法，所以「那一半」對他們都解得開；讀者從中段落進來時手上沒有。&lt;/li>
&lt;li>&lt;a href="https://tarrragon.github.io/blog/report/question-answer-frame-blurs-problem-issue-request/" data-link-title="「問題」與「回答」當框架詞：一個詞蓋住問句、故障、議題與需求，以及系統被寫成應答的一方" data-link-desc="文章用「X 回答的問題是」「這是 Y 的問題」組織內容，讀者分不出那個「問題」是一句問句、一個故障、一個要處理的事項還是一項需求；或審查時看到監控、檢查、元件被寫成在回答問題時回來讀；「撐得住」這類足夠性斷言與「對不對」這類評價謂語是同一類詞">#374 「問題」與「回答」當框架詞&lt;/a>——自創術語建在譬喻框架上時（「問題盲區」），框架的歧義跟著進了名字；命名時先找業界術語，就是在避開這一種。&lt;/li>
&lt;/ul>
&lt;h2 id="判讀徵兆">判讀徵兆&lt;/h2>
&lt;ul>
&lt;li>同一個主題被「一部分」「另一半」「那一側」切了兩次以上，而切分的依據要讀完整段才歸納得出來。&lt;/li>
&lt;li>段落首句用「這一部分」「另一半」回指上一段，而上一段沒有替它命名。&lt;/li>
&lt;li>自創了一個描述性名稱（「分岔的資料」），而業界對同一件事已有術語。&lt;/li>
&lt;li>命名的句子另有一個子句宣告取名或約定下文用法（「各取一個名字，下文都用這兩個名字」），刪掉之後讀者什麼都沒少。&lt;/li>
&lt;/ul>
&lt;h2 id="case">Case&lt;/h2>
&lt;p>2026-09-29，SQL 教材分類的 SQL.13。使用者指出「交得出去的一部分、交不出去的另一半」是不好的例子，同一節的 test oracle / test provenance / equivalent mutant 那一句是好的例子：「當我們先說明界定好一個理論或者一個概念，我們就可以直接引用他的名字」；要解釋為什麼這個情境做得到、另一個做不到，然後給一個明確的命名——業界的說法，或直接舉一個案例、用案例的名字——「這也是當我們寫程式碼的時候有時候應該先嘗試抽變數的概念，只是這個變數在文章中他可以是一個 case，或者一個理論」。&lt;/p></description><content:encoded><![CDATA[<p>把一個集合切成幾塊來討論時，「一部分」「另一半」「那一側」「這部分」只說了有一刀，沒說刀落在哪裡、每一塊是什麼。讀者要自己從例子裡歸納出切分的依據，歸納出來的還未必是作者的那一個。修法跟重構程式時抽變數是同一個動作：<strong>先寫出切分的依據（為什麼這一塊做得到、那一塊做不到），再替每一塊取名字，之後只用名字指它</strong>。名字依序從三處找：業界已有的術語、文章裡現成的案例名、最後才是一個描述內容的短語。</p>
<h2 id="失效的形態">失效的形態</h2>
<p>一篇 SQL 教材討論「答案對不對」這一層能不能交給機器判斷，原文三段的開頭是：</p>
<blockquote>
<p>交不出那條判定，而這裡仍有一部分不必等人來判。</p>
<p>有一部分判斷標準交得出去。</p>
<p>交不出去的那一半仍然有一個可以機械化的做法。</p></blockquote>
<p>同一個集合被切了三次，三塊都沒有名字，而三刀的依據各不相同，分散在段落中段的一句話裡（「交得出去的界線落在判斷需要什麼」只解釋了約束那一刀）。讀到「交不出去的那一半」時，讀者要先決定它指的是「這裡仍有一部分」切剩的、還是「有一部分判斷標準交得出去」切剩的。</p>
<p>同一節的最後一段是反例——它做對了：</p>
<blockquote>
<p>預期值從哪裡取得叫 test oracle……「寫斷言的人與寫實作的人共用同一份誤解」叫 test provenance；而「造不出分岔的資料」在 Mutation Testing 裡叫 equivalent mutant。</p></blockquote>
<p>三個概念都已經在別處定義過、有公認的名字，所以一句話就能引用三次，讀者不必重建任何定義。</p>
<p>改寫之後，那一節開頭先寫依據：一項判斷能不能交給機器，看判斷時要讀的資訊機器在那一刻讀不讀得到——引擎收到查詢時讀得到查詢文字與表結構，資料庫寫入時讀得到那一筆資料與它指向的列，「要問的是什麼」只有提問的人知道。依據寫出來之後三塊各有名字：只讀查詢文字與表結構的是<strong>靜態分析</strong>，只讀寫入那一筆的是<strong>約束</strong>，要讀「要問的是什麼」的只能記成一筆<strong>反例資料</strong>（counterexample）。之後每一段都用名字開頭。</p>
<h2 id="取名這一步會逼出內容">取名這一步會逼出內容</h2>
<p>找業界名字不只是換標籤。「這裡仍有一部分不必等人來判」要改叫靜態分析，就得說出靜態分析在這個例子上實際判得出什麼——追下去找到的是最佳化器本身就做這個判斷：<code>WHERE 評價.星等 &lt;&gt; 5</code> 讓 <code>LEFT JOIN</code> 失效，PostgreSQL 16 的 <code>EXPLAIN</code> 對那段查詢印 <code>Hash Join</code>、對正解印 <code>Hash Left Join</code>，MySQL 8 把它改寫成內連接。原文的「那個 <code>LEFT</code> 是死的」是一句斷言，取名之後它變成讀者可以自己跑一次驗證的現象。</p>
<p>「分岔的資料」換成「反例資料」也一樣：反例在邏輯裡的意思是「兩段查詢在它上面答案不同，就證明兩者不等價」，這個定義順手把最後一段的 equivalent mutant 接上了——造不出反例資料，就是兩段查詢等價。自創的「分岔的資料」接不上任何既有概念。</p>
<p>同一篇第二輪把成因分類與反例資料的狀態也命名之後，又對出兩處：成因那一節寫「問錯了問題，換引擎、加約束、跑靜態分析都碰不到」，而後面一節寫靜態分析判得出「不等於五」——兩類有了名字，才看得出「不等於五」同時屬於「誤解語意模型」，靜態分析判出的是後者；「這幾種狀態」列了四種資料狀態並說三種錯法都發生在上面，而「漏掉星等」的反例（某張訂單的評價全部不是五星）不在清單裡、清單裡的「指不到任何一列的編號」三種錯法都用不到。改叫等價類劃分（equivalence partitioning）並把資料實際寫出來跑過一次，清單才對得上。</p>
<h2 id="為什麼命名的既有規則沒擋住">為什麼命名的既有規則沒擋住</h2>
<p><a href="/blog/report/ordinal-labels-are-the-authors-index/" data-link-title="正文裡的對象要用它是什麼來命名，序數、計數與字母代號是作者腦中的索引" data-link-desc="文章裡出現「三支」「七步」「第三步」「第一級」「前提一」「A1 與 C」這類名字，讀者要回頭翻才知道指什麼時回來讀">#363</a> 要求正文裡的對象用內容命名，掃的是序數、計數與字母代號（「第一支」「三步」「A1」）。那些字面上就是索引，一眼看得出來。「一部分」「另一半」不是索引，它們是<strong>切分動作本身</strong>：作者寫下的時候手上有切法，所以對他來說「那一半」跟「約束那一類」一樣清楚，而 #363 的變數名稱測試問的是「這個名字能不能當變數」，「那一半」根本沒有被當成名字寫下，測試不觸發。</p>
<p>跟 <a href="/blog/report/noun-without-its-owner-passes-the-slot-check/" data-link-title="名詞要求的「誰的、什麼的」也是槽位，論斷句與段標的省略藏在名詞裡" data-link-desc="句子主詞謂語都在、讀起來通順，而讀者說不出「誰的輸出」「什麼的來源」；或段標、總結句用了只寫在目錄頁的框架詞時回來讀">#366</a> 的關係是同一個成因的兩個尺度：#366 是一個名詞缺了所屬（「誰的輸出」），這一張是一整個集合缺了切分依據與成員名——「一部分」要求的所屬是「什麼的一部分、按什麼切出來的哪一部分」，句內兩樣都沒有。</p>
<h2 id="偵測與它的射程">偵測與它的射程</h2>
<p>字詞層掃得到候選：<code>一部分|另一半|這一半|那一半|這部分|那部分|另一部分|那一側|這一側|另一側|另一邊</code>。在 SQL 分類 24 篇與知識卡上跑一次，程式碼區塊外 68 處命中，判定要改的 20 處。</p>
<p>不用改的那些，所屬寫在同一句：「子表這一側是填進一個指不到的值，父表那一側是把還被指著的那一列刪掉」「反連接留下的是另一半——左邊那些在右邊配不到任何對象的列」。要改的那些分兩種：</p>
<ul>
<li><strong>半邊沒有名字</strong>：「補決勝鍵只解決了並列那一半」（另一半是翻頁途中的寫入，要到另一篇才看得到）、「規則沒有規定的那一半」「列數那一半在 1.6」。改成直接寫出那一塊：「治得好並列造成的重複與遺漏、治不好翻頁途中有人寫入造成的那一種」。</li>
<li><strong>「一側」當譬喻</strong>：「在條件這一側還有路」「語言這一側發生什麼」「代價那一側它是逐列執行的」。這裡沒有被切開的集合，「一側」只是換了個說法的「就……而言」，改成直接寫主詞（「改寫條件本身就能讓它走索引」）。</li>
</ul>
<p>grep 分不出兩者與合規句，命中之後逐句問：<strong>讀者只讀這一句，說不說得出這一塊是什麼、另一塊是什麼</strong>。另外，切分依據沒寫出來這件事沒有字詞可掃——三刀之中真正缺的是依據，而依據的缺席沒有痕跡。寫到「一部分」的當下先回答「按什麼切的」，再把答案寫在第一次切的位置。</p>
<h2 id="修法">修法</h2>
<ul>
<li><strong>先寫依據</strong>：切開一個集合的第一句寫出「按什麼切」，而且是一個可以逐項判定的標準（「判斷時要讀什麼」），不是結果的描述（「有的交得出去」）。</li>
<li><strong>再命名</strong>：業界有術語就用術語（靜態分析、約束、counterexample），並寫一句它在本文例子上的樣子；沒有術語就用文章裡的案例名（「不等於五的錯法」）；兩者都沒有才用描述短語。</li>
<li><strong>之後只用名字</strong>：段落首句用名字開頭（「靜態分析只讀查詢的文字與表的結構」），不再用「這一部分」「另一半」回指。</li>
<li><strong>審查端列為必修</strong>：教材逐段審查把「一個被反覆談論的概念沒有被界定與命名就被引用」列為必修，逐個概念點名檢查。審查者手上有作者的切法，讀到「那一半」解得開，所以靠讀起來順不順判斷永遠通過。同一條也涵蓋沒有字詞可掃的那一種：同一個概念每次換一個描述重講一次，讀者分不出幾次講的是不是同一件事——那是程式裡重複的運算式，一樣要抽成變數。</li>
<li><strong>連到切分的句子一起改</strong>：別篇引用這個切分時用的也是「一部分交得出去」，要一併換成名字，否則讀者在兩篇之間拿到兩套說法。</li>
</ul>
<h2 id="命名由句子結構完成取名的動作不寫進正文">命名由句子結構完成，取名的動作不寫進正文</h2>
<p>一篇服務端監控的教材照這張卡先界定再命名，寫成：「一個觀察者的盲區有兩種，各取一個名字，下文都用這兩個名字。<strong>問題盲區</strong>是……<strong>位置盲區</strong>是……」。中間那個子句描述的是作者正在做的事（取名、約定下文怎麼用），刪掉之後讀者什麼都沒少：粗體與緊跟的定義已經完成命名，之後一律用名字是寫的人自己的紀律，不必向讀者宣告。</p>
<p>命名交給句子結構：</p>
<ul>
<li><strong>成員只有兩三個</strong>：一句寫完分類與成員的名字，下一句起逐一定義。「一個觀察者的盲區分成問題盲區與位置盲區。問題盲區是……」</li>
<li><strong>成員更多</strong>：用清單列出名字，每一項可以附一句判別依據，下一段起逐一解釋。清單用編號只是版面，正文引用時仍然用名字。</li>
</ul>
<p>判讀用刪除測試：<strong>刪掉這個子句，讀者少了什麼。</strong> 少了名字或它的所指就留下——「下文把主機、容器、資料庫、快取與入口這些組成服務的單位稱為<strong>元件</strong>」刪掉之後讀者不知道元件指什麼；什麼都沒少的刪掉——「各取一個名字」「下文都用這兩個名字」「以下逐一說明」。</p>
<p>這個形態是執行本卡規則的副作用：規則描述的是寫的人要做的動作（先界定、再命名），寫的人把動作本身寫進了正文。它和 <a href="/blog/report/coherence-by-advancing-not-recapping/" data-link-title="連貫靠句句推進：讀者付出的每一次閱讀成本都要換到內容" data-link-desc="段落讀起來不連貫、或發現自己在寫過場句把前文摘一次再出發時，用來判斷哪些字該刪、譬喻該不該留、說明順序該由什麼驅動">#285</a> 的文章自指是同一類，讀者讀的是主題，不是文章怎麼安排自己。</p>
<h2 id="全站掃過一次之後模糊的切分會藏住錯的論斷">全站掃過一次之後：模糊的切分會藏住錯的論斷</h2>
<p>SQL 以外的分類另有 550 處候選，分十批交給篩選者（判定只看目標句與前一句、不改要附逐字依據），判定要改 89 處，主 session 重讀依據薄弱的不改項後再改 7 處，約六分之一。不改的多數是組成句「X 是 Y 的一部分」——部分與整體都寫在句內，沒有切開任何集合；這一類可以直接豁免。</p>
<p>篩選者回報了規則原先沒寫到的三種形態：</p>
<ul>
<li><strong>每一塊有名字、被切開的整體沒有</strong>：「purgeable 是同一條線的另一半」「環境那一半的論證」——讀者知道這一半叫什麼，不知道它是什麼的一半。四個批次各自遇到，判定不一致，所以要寫進規則：整體也要在這一句或前一句具名。</li>
<li><strong>裸「這部分」回指，而前面沒有切分</strong>：「或把這部分 relationalize」前一句有兩個名詞都可能是先行詞；「必要時用 <code>chvt</code> 切到別的 VT，這部分見……」跟在一長串操作之後。這是指涉問題，修法相同：寫出那一塊的名字。</li>
<li><strong>同一組東西混用幾個詞、或同一個詞指兩塊</strong>：「單邊／那一腳／那一邊」指同一組兩腳；「只算資本這一邊（……談的是資本的另一半）」讓「資本」同時指資金與人力資本。命名時整組一起定，一個名字只指一塊。</li>
</ul>
<p>最值得記的是另一件事：<strong>有兩處模糊的切分底下是錯的論斷。</strong> 存活者偏誤那一篇的通則寫「往被高估那一側走還是贏的結論仍然成立，靠近基準的指控型結論不成立」，而前一行才寫明觀察值是下界時「低於基準」存活——通則只在上界時成立。保證金模式那張卡寫「這個預設在猜錯時付出的是資金效率，猜對的另一邊付出的是同時被清算」，「另一邊」其實是反向的預設猜錯時，句子把邏輯寫反了。兩句讀起來都通順，因為「那一側」「另一邊」不必決定指的是什麼；替它們命名的時候才發現對不上。</p>
<p>反方向也發生了一次：篩選者替「purgeable 是同一條線的另一半」取名，寫成「與本地快照並列的另一個根因」，而同一段寫明 purgeable 主要由快照構成，兩者不並列。<strong>命名會逼作者決定所指，而決定錯了就把一個錯誤寫進文章</strong>，所以替換文字裡新出現的關係（並列、包含、因果）要回原文核對。</p>
<h2 id="論述基礎與限制">論述基礎與限制</h2>
<p>依據是一次改寫：一篇文章的一節加上 SQL 分類的全掃（68 處候選、20 處改動，判定由主 session 做），以及其餘分類的全掃（550 處候選、96 處改動，篩選者判定、主 session 抽查與核對）。「取名會逼出內容」觀察到四例（最佳化器的外連接化簡、反例接上 equivalent mutant、兩處寫反的論斷），不代表每一次命名都會找到新材料。</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>——那一張管已經有名字而名字是索引的對象；本卡管還沒被命名、只以切分動作出現的對象，並補上「先寫依據」這一步。</li>
<li><a href="/blog/report/noun-without-its-owner-passes-the-slot-check/" data-link-title="名詞要求的「誰的、什麼的」也是槽位，論斷句與段標的省略藏在名詞裡" data-link-desc="句子主詞謂語都在、讀起來通順，而讀者說不出「誰的輸出」「什麼的來源」；或段標、總結句用了只寫在目錄頁的框架詞時回來讀">#366 名詞要求的「誰的、什麼的」也是槽位</a>——一個名詞缺所屬；「一部分」缺的所屬是整個切法。</li>
<li><a href="/blog/report/counted-summary-delivers-only-the-length/" data-link-title="摘要另一份內容時寫出成員，計數只告訴讀者清單有多長" data-link-desc="介紹另一篇、寫 description、填目錄頁的交付欄時，寫出了「四個追問、三種寫法、四類邊界」這種句子，讀者仍要點進去才知道那些是什麼時回來讀">#364 計數式摘要只交付清單的長度</a>——「三種寫法」只給長度、不給成員；「一部分」連長度都沒給，只給了有一刀。</li>
<li><a href="/blog/report/reviewer-holds-the-map-readers-land-without-it/" data-link-title="逐段審查量讀者學不學得會，指稱解不解得開要問沒讀過前文的讀者" data-link-desc="教材走過逐段審查，仍殘留隔好幾段的「上面那一組」「兩者」、計數對不上成員、或解法只對列出的一部分成立的段落，而審查回報幾乎沒有這些項目時回來讀">#365 逐段審查量讀者學不學得會</a>——作者與審查者手上有切法，所以「那一半」對他們都解得開；讀者從中段落進來時手上沒有。</li>
<li><a href="/blog/report/question-answer-frame-blurs-problem-issue-request/" data-link-title="「問題」與「回答」當框架詞：一個詞蓋住問句、故障、議題與需求，以及系統被寫成應答的一方" data-link-desc="文章用「X 回答的問題是」「這是 Y 的問題」組織內容，讀者分不出那個「問題」是一句問句、一個故障、一個要處理的事項還是一項需求；或審查時看到監控、檢查、元件被寫成在回答問題時回來讀；「撐得住」這類足夠性斷言與「對不對」這類評價謂語是同一類詞">#374 「問題」與「回答」當框架詞</a>——自創術語建在譬喻框架上時（「問題盲區」），框架的歧義跟著進了名字；命名時先找業界術語，就是在避開這一種。</li>
</ul>
<h2 id="判讀徵兆">判讀徵兆</h2>
<ul>
<li>同一個主題被「一部分」「另一半」「那一側」切了兩次以上，而切分的依據要讀完整段才歸納得出來。</li>
<li>段落首句用「這一部分」「另一半」回指上一段，而上一段沒有替它命名。</li>
<li>自創了一個描述性名稱（「分岔的資料」），而業界對同一件事已有術語。</li>
<li>命名的句子另有一個子句宣告取名或約定下文用法（「各取一個名字，下文都用這兩個名字」），刪掉之後讀者什麼都沒少。</li>
</ul>
<h2 id="case">Case</h2>
<p>2026-09-29，SQL 教材分類的 SQL.13。使用者指出「交得出去的一部分、交不出去的另一半」是不好的例子，同一節的 test oracle / test provenance / equivalent mutant 那一句是好的例子：「當我們先說明界定好一個理論或者一個概念，我們就可以直接引用他的名字」；要解釋為什麼這個情境做得到、另一個做不到，然後給一個明確的命名——業界的說法，或直接舉一個案例、用案例的名字——「這也是當我們寫程式碼的時候有時候應該先嘗試抽變數的概念，只是這個變數在文章中他可以是一個 case，或者一個理論」。</p>
]]></content:encoded></item><item><title>flan</title><link>https://tarrragon.github.io/blog/til/cooking/naming/flan/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/cooking/naming/flan/</guid><description>&lt;p>flan 按&lt;strong>形狀&lt;/strong>切。法文的 flan 承自十二世紀的古法語 flaon，再往上是晚期拉丁語的 fladō「扁平的餅」，來源是法蘭克語的 flaþō，可以追到原始印歐語表示「寬、平」的詞根；英語在 1846 年從法文借入現在這個寫法，而約在 1300 年就已經有同源的 flawn。&lt;/p>
&lt;p>法文的 flan 同時還指鑄幣用的金屬圓餅與幣模，而這個非食物的義項在法文裡出現得比食物義更早（十一世紀末，食物義約 1180 年）。兩個義項共有的只有形狀，食物內容從一開始就不是這個字管的。&lt;/p>
&lt;p>法文辭典把甜與鹹並列在同一個義項底下——Larousse 的定義是「甜的或鹹的內餡在一層餅皮上烤成的塔」，甜鹹之分不構成兩個詞。這正是形狀這個切法的麻煩：它跟吃的人在意的每一項都不對應。甜的還是鹹的、當甜點還是當配菜、用蛋奶還是用蔬菜泥、需不需要冷藏——這幾項決定了要不要點它，而形狀對它們一個都不預測。所以在菜單上看到 flan 的當下，這個字本身給出的資訊接近於零。&lt;/p>
&lt;h2 id="各地的-flan-是什麼">各地的 flan 是什麼&lt;/h2>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>地區&lt;/th>
 &lt;th>這裡的 flan 是&lt;/th>
 &lt;th>單篇&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>西班牙&lt;/td>
 &lt;td>脫模後淋著焦糖醬的蛋奶凍，用全脂鮮奶&lt;/td>
 &lt;td>&lt;a href="../../dishes/creme-caramel/">crème caramel&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>拉丁美洲&lt;/td>
 &lt;td>同一種成品，改用煉乳，成品更濃（菲律賓叫 leche flan）&lt;/td>
 &lt;td>&lt;a href="../../dishes/creme-caramel/">crème caramel&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>法國&lt;/td>
 &lt;td>口語同時指上面那種與派皮布丁塔，也涵蓋鹹味的 flan salé&lt;/td>
 &lt;td>&lt;a href="../../dishes/creme-caramel/">crème caramel&lt;/a>、&lt;a href="../../dishes/flan-patissier/">flan pâtissier&lt;/a>、&lt;a href="../../dishes/sformato/">sformato 那一類&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>英國&lt;/td>
 &lt;td>有邊無上蓋的塔，甜鹹皆可，底座是派皮或海綿蛋糕&lt;/td>
 &lt;td>&lt;a href="../../dishes/english-flan/">英式 flan&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>義大利&lt;/td>
 &lt;td>菜單上借用的寫法（flan di verdure），本地的字是 sformato&lt;/td>
 &lt;td>&lt;a href="../../dishes/sformato/">sformato&lt;/a>&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>西班牙、拉丁美洲與法國的 crème caramel 是同一種成品的傳播，不是各自的發明。真正分開的是蛋奶凍、派皮布丁塔、開放式塔、鹹味蔬菜凍派這四條線。&lt;/p>
&lt;h2 id="菜單上的三種線索解析度差很多">菜單上的三種線索，解析度差很多&lt;/h2>
&lt;p>&lt;strong>國別是唯一有決定性的那一個&lt;/strong>，因為這個字的用法差異沿著國界走。同一個線索在不同國家指向相反的答案：西班牙甜點區的 flan de queso 是加了起司的蛋奶凍，甜的；英國的 cheese flan 是加了起司的派皮塔，接近鹹派。兩者同樣以起司為賣點、同樣叫 flan，而分開它們的只有國別。&lt;/p>
&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>這個字底下的四條線各自有自己的形態頁，而那些頁面用的是成品的性質而不是名字：&lt;/p>
&lt;ul>
&lt;li>脫模後自己站著、會晃的蛋奶凍 → &lt;a href="../../forms/egg-custard/">egg custard（蛋液凝凍）&lt;/a>，那一篇寫凝固與變質之間只有三度、以及各種孔洞分別怎麼形成的&lt;/li>
&lt;li>有派皮當容器、側面看得到皮與餡兩層 → &lt;a href="../../forms/pastry-tart/">派皮塔&lt;/a>，那一篇寫塔皮與千層酥皮做出來的成品為什麼大小不同&lt;/li>
&lt;li>底座是海綿蛋糕、餡沒有進過烤箱 → &lt;a href="../../forms/sponge-flan/">海綿底塔&lt;/a>，那一篇寫底座吸水為什麼限制了餡能放什麼&lt;/li>
&lt;li>主體是蔬菜、蛋只當黏合劑 → &lt;a href="../../forms/vegetable-puree/">蒸蔬菜泥&lt;/a>，那一篇寫濃度為什麼要另外補&lt;/li>
&lt;/ul>
&lt;h2 id="別的字用別的方式切">別的字用別的方式切&lt;/h2>
&lt;p>flan 按形狀切，而同一個分類裡的其他名字各看一個面向：&lt;a href="../geng/">羹&lt;/a> 的古義按材料切、今義按質地切，而台灣與中國的今義又不一樣——那一篇比對兩邊各要求什麼。&lt;/p>
&lt;p>按動作切的例子是 sformato（字面是「脫模之物」），按誰有權使用那個名字切的例子是 Pastéis de Belém（受歐盟商標保護），兩者分別在 &lt;a href="../../dishes/sformato/">sformato&lt;/a> 與 &lt;a href="../../dishes/pastel-de-nata/">pastel de nata&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>flan 按<strong>形狀</strong>切。法文的 flan 承自十二世紀的古法語 flaon，再往上是晚期拉丁語的 fladō「扁平的餅」，來源是法蘭克語的 flaþō，可以追到原始印歐語表示「寬、平」的詞根；英語在 1846 年從法文借入現在這個寫法，而約在 1300 年就已經有同源的 flawn。</p>
<p>法文的 flan 同時還指鑄幣用的金屬圓餅與幣模，而這個非食物的義項在法文裡出現得比食物義更早（十一世紀末，食物義約 1180 年）。兩個義項共有的只有形狀，食物內容從一開始就不是這個字管的。</p>
<p>法文辭典把甜與鹹並列在同一個義項底下——Larousse 的定義是「甜的或鹹的內餡在一層餅皮上烤成的塔」，甜鹹之分不構成兩個詞。這正是形狀這個切法的麻煩：它跟吃的人在意的每一項都不對應。甜的還是鹹的、當甜點還是當配菜、用蛋奶還是用蔬菜泥、需不需要冷藏——這幾項決定了要不要點它，而形狀對它們一個都不預測。所以在菜單上看到 flan 的當下，這個字本身給出的資訊接近於零。</p>
<h2 id="各地的-flan-是什麼">各地的 flan 是什麼</h2>
<table>
  <thead>
      <tr>
          <th>地區</th>
          <th>這裡的 flan 是</th>
          <th>單篇</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>西班牙</td>
          <td>脫模後淋著焦糖醬的蛋奶凍，用全脂鮮奶</td>
          <td><a href="../../dishes/creme-caramel/">crème caramel</a></td>
      </tr>
      <tr>
          <td>拉丁美洲</td>
          <td>同一種成品，改用煉乳，成品更濃（菲律賓叫 leche flan）</td>
          <td><a href="../../dishes/creme-caramel/">crème caramel</a></td>
      </tr>
      <tr>
          <td>法國</td>
          <td>口語同時指上面那種與派皮布丁塔，也涵蓋鹹味的 flan salé</td>
          <td><a href="../../dishes/creme-caramel/">crème caramel</a>、<a href="../../dishes/flan-patissier/">flan pâtissier</a>、<a href="../../dishes/sformato/">sformato 那一類</a></td>
      </tr>
      <tr>
          <td>英國</td>
          <td>有邊無上蓋的塔，甜鹹皆可，底座是派皮或海綿蛋糕</td>
          <td><a href="../../dishes/english-flan/">英式 flan</a></td>
      </tr>
      <tr>
          <td>義大利</td>
          <td>菜單上借用的寫法（flan di verdure），本地的字是 sformato</td>
          <td><a href="../../dishes/sformato/">sformato</a></td>
      </tr>
  </tbody>
</table>
<p>西班牙、拉丁美洲與法國的 crème caramel 是同一種成品的傳播，不是各自的發明。真正分開的是蛋奶凍、派皮布丁塔、開放式塔、鹹味蔬菜凍派這四條線。</p>
<h2 id="菜單上的三種線索解析度差很多">菜單上的三種線索，解析度差很多</h2>
<p><strong>國別是唯一有決定性的那一個</strong>，因為這個字的用法差異沿著國界走。同一個線索在不同國家指向相反的答案：西班牙甜點區的 flan de queso 是加了起司的蛋奶凍，甜的；英國的 cheese flan 是加了起司的派皮塔，接近鹹派。兩者同樣以起司為賣點、同樣叫 flan，而分開它們的只有國別。</p>
<p><strong>菜單分區的解析度只到「在一餐裡的角色」。</strong> 甜點區或糕點櫃指向蛋奶凍與派皮布丁塔，配菜區指向鹹味蔬菜版——它答得出甜鹹，答不出形態，因為鹹味蔬菜凍派與鹹味的派皮塔會落在同一區。</p>
<p><strong>主體食材指向形態而不指向國別。</strong> 牛奶、蛋、糖這組基本組合指向蛋奶凍，焦糖與香草也是；蔬菜名指向鹹味凍派；水果在英式菜單上指向開放式塔。</p>
<p>三種線索之間有依賴關係：後兩種的讀法隨國別改變，所以國別未定的時候它們給出的答案沒有意義。這是這個字最難用的地方——<strong>它自己不帶國別資訊，而它的一切都取決於國別</strong>。</p>
<h2 id="從成品的樣子反查">從成品的樣子反查</h2>
<p>這個字底下的四條線各自有自己的形態頁，而那些頁面用的是成品的性質而不是名字：</p>
<ul>
<li>脫模後自己站著、會晃的蛋奶凍 → <a href="../../forms/egg-custard/">egg custard（蛋液凝凍）</a>，那一篇寫凝固與變質之間只有三度、以及各種孔洞分別怎麼形成的</li>
<li>有派皮當容器、側面看得到皮與餡兩層 → <a href="../../forms/pastry-tart/">派皮塔</a>，那一篇寫塔皮與千層酥皮做出來的成品為什麼大小不同</li>
<li>底座是海綿蛋糕、餡沒有進過烤箱 → <a href="../../forms/sponge-flan/">海綿底塔</a>，那一篇寫底座吸水為什麼限制了餡能放什麼</li>
<li>主體是蔬菜、蛋只當黏合劑 → <a href="../../forms/vegetable-puree/">蒸蔬菜泥</a>，那一篇寫濃度為什麼要另外補</li>
</ul>
<h2 id="別的字用別的方式切">別的字用別的方式切</h2>
<p>flan 按形狀切，而同一個分類裡的其他名字各看一個面向：<a href="../geng/">羹</a> 的古義按材料切、今義按質地切，而台灣與中國的今義又不一樣——那一篇比對兩邊各要求什麼。</p>
<p>按動作切的例子是 sformato（字面是「脫模之物」），按誰有權使用那個名字切的例子是 Pastéis de Belém（受歐盟商標保護），兩者分別在 <a href="../../dishes/sformato/">sformato</a> 與 <a href="../../dishes/pastel-de-nata/">pastel de nata</a>。</p>
]]></content:encoded></item><item><title>pastel de nata（葡式蛋塔）</title><link>https://tarrragon.github.io/blog/til/cooking/dishes/pastel-de-nata/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/cooking/dishes/pastel-de-nata/</guid><description>&lt;p>pastel de nata 是千層酥皮裡灌進蛋奶糊、送進極熱的烤箱快速烤成的葡萄牙點心。成品表面帶特徵性的黑色焦斑、餅皮酥脆、內餡柔軟，一口到兩口的大小，出爐就吃，桌上另備肉桂粉與糖粉自行撒。&lt;/p>
&lt;p>餡的組成是牛奶、蛋、糖、檸檬、肉桂，也有把牛奶換成鮮奶油、或加麵粉與澱粉的作法。&lt;/p>
&lt;h2 id="高溫短時間讓表面焦化時中心還沒熱到出水">高溫短時間讓表面焦化時，中心還沒熱到出水&lt;/h2>
&lt;p>蛋奶糊能停留的溫度範圍很窄：蛋、奶、糖的混合物在 80 到 85 度之間凝固成形，88 到 90 度就開始把水擠出來、質地變粗，中間只剩三度——這一段就是 &lt;a href="../../forms/egg-custard/">egg custard（蛋液凝凍）&lt;/a> 說的容錯帶。成品要停在那三度裡，而烤箱的空氣遠高過它。&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>千層酥皮由麵團與油脂反覆摺疊而成，每摺一次層數翻倍。進烤箱後麵皮裡的水分變成蒸氣，把層與層之間撐開，所以它是酥的、咬下去有層、會掉屑。&lt;/p>
&lt;p>&lt;strong>這個撐開需要熱在短時間裡到達每一層。&lt;/strong> 體積越大，中心的層就越晚受熱，等到那裡的水變成蒸氣時外圈已經定形，撐不開了。所以這一類做成一口到兩口的大小，而不是整模再切。&lt;/p>
&lt;p>壓實不摺疊的塔皮沒有這個限制。它的成品是脆的、切得開、不分層，因此可以做大。港式蛋撻的牛油皮就是這一種，而賣港式蛋撻的店往往也賣酥皮的版本，兩者從斷面分得開；&lt;a href="../hk-egg-tart/">港式蛋撻&lt;/a> 那一篇另外寫它的餡是中式燉蛋那一路，跟這裡的蛋奶糊來歷不同。塔皮的兩種作法（摺疊的酥皮與壓實的塔皮）為什麼決定成品能做多大，&lt;a href="../../forms/pastry-tart/">派皮塔&lt;/a> 有一節專講。&lt;/p>
&lt;h2 id="名字的邊界由商標劃定">名字的邊界由商標劃定&lt;/h2>
&lt;p>pastel de nata 是通稱，指的是這一整類。&lt;strong>Pastéis de Belém 是里斯本貝倫區那一家店的名字，受商標保護&lt;/strong>：ANTIGA CONFEITARIA DE BELEM LDA 持有歐盟商標 EUTM 001254895，1999 年申請、2000 年註冊，涵蓋餅乾與糕點類。&lt;/p>
&lt;p>所以同一份配方換一家店做，就只能叫 pastel de nata。&lt;strong>這一種切法連食物本身都不看&lt;/strong>——分開兩個名字的是誰有權使用它，而不是成品有什麼差別。台灣說的「葡式蛋塔」指的就是這一整類。按形狀切的名字是 &lt;a href="../../naming/flan/">flan&lt;/a>，古義按材料、今義按質地切的是 &lt;a href="../../naming/geng/">羹&lt;/a>。&lt;/p>
&lt;h2 id="起源查得到的只有三個年份而它們分屬三個等級">起源查得到的只有三個年份，而它們分屬三個等級&lt;/h2>
&lt;p>&lt;strong>1834 年&lt;/strong>葡萄牙解散修會、關閉全國的修道院與女修院。這一條有法令。&lt;/p>
&lt;p>&lt;strong>1879 年&lt;/strong>一份公證書記載 Domingos Rafael Alves 以十萬 réis 向教子 José Vicente da Silva Pinto 買下配方的祕密。這是關於這家店最早的文件證據。&lt;/p>
&lt;p>&lt;strong>1837 年&lt;/strong>是店家自述的開業年份，而這個說法的來源是 1983 年由該店一位股東提供的資訊。&lt;/p>
&lt;p>修道院起源這一條更弱：葡文維基寫的是「terá sido criado pelos monges jerónimos」，用的是推測式。本篇因此不寫成事實。另一個流傳很廣的說法——修士用大量蛋白替衣物上漿、剩下的蛋黃拿來做點心——在查得到的每一個來源裡都標為相傳，同樣不採用。&lt;/p>
&lt;h2 id="兩道都焦黑這一道靠溫差派皮布丁塔靠放寬的容錯帶">兩道都焦黑：這一道靠溫差，派皮布丁塔靠放寬的容錯帶&lt;/h2>
&lt;p>&lt;a href="../flan-patissier/">flan pâtissier（派皮布丁塔）&lt;/a> 同樣直接進烤箱、表面同樣焦黑，而它走的是另一條路：烤得久、烤得透，餡裡加玉米粉把容錯帶放寬。它的焦斑來自寬容錯帶給的餘裕，表面有時間走到焦化而內部仍然完整，所以成品內外一致、扎實得可以整模烤好再切片。這一道的焦斑則是溫差的證據，內外本來就不一致。澱粉怎麼穩定蛋白質的網、厚度與可切片從哪裡來，是派皮布丁塔那一頁的主題；兩條路怎麼分、成品為什麼不同，在 &lt;a href="../../techniques/direct-baking/">直接烘烤&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>pastel de nata 是千層酥皮裡灌進蛋奶糊、送進極熱的烤箱快速烤成的葡萄牙點心。成品表面帶特徵性的黑色焦斑、餅皮酥脆、內餡柔軟，一口到兩口的大小，出爐就吃，桌上另備肉桂粉與糖粉自行撒。</p>
<p>餡的組成是牛奶、蛋、糖、檸檬、肉桂，也有把牛奶換成鮮奶油、或加麵粉與澱粉的作法。</p>
<h2 id="高溫短時間讓表面焦化時中心還沒熱到出水">高溫短時間讓表面焦化時，中心還沒熱到出水</h2>
<p>蛋奶糊能停留的溫度範圍很窄：蛋、奶、糖的混合物在 80 到 85 度之間凝固成形，88 到 90 度就開始把水擠出來、質地變粗，中間只剩三度——這一段就是 <a href="../../forms/egg-custard/">egg custard（蛋液凝凍）</a> 說的容錯帶。成品要停在那三度裡，而烤箱的空氣遠高過它。</p>
<p>多數作法的對策是壓住升溫——蒸氣停在一百度、熱水在沸點以下吸熱，各自造一個上限讓蛋液慢慢靠近目標。<strong>這一道放棄了那個上限，改用時間。</strong></p>
<p>烤箱燒得夠熱、烤的時間夠短，熱來不及傳到中心，所以表面早就越過焦化的溫度而中心還沒熱到出水。黑色焦斑證明表面到過那個溫度，柔軟內餡證明中心沒有跟上——<strong>那個對比本身就是溫差拉得夠開的證據</strong>，不是烤不均勻。</p>
<h2 id="酥皮的層次限制了它的尺寸">酥皮的層次限制了它的尺寸</h2>
<p>千層酥皮由麵團與油脂反覆摺疊而成，每摺一次層數翻倍。進烤箱後麵皮裡的水分變成蒸氣，把層與層之間撐開，所以它是酥的、咬下去有層、會掉屑。</p>
<p><strong>這個撐開需要熱在短時間裡到達每一層。</strong> 體積越大，中心的層就越晚受熱，等到那裡的水變成蒸氣時外圈已經定形，撐不開了。所以這一類做成一口到兩口的大小，而不是整模再切。</p>
<p>壓實不摺疊的塔皮沒有這個限制。它的成品是脆的、切得開、不分層，因此可以做大。港式蛋撻的牛油皮就是這一種，而賣港式蛋撻的店往往也賣酥皮的版本，兩者從斷面分得開；<a href="../hk-egg-tart/">港式蛋撻</a> 那一篇另外寫它的餡是中式燉蛋那一路，跟這裡的蛋奶糊來歷不同。塔皮的兩種作法（摺疊的酥皮與壓實的塔皮）為什麼決定成品能做多大，<a href="../../forms/pastry-tart/">派皮塔</a> 有一節專講。</p>
<h2 id="名字的邊界由商標劃定">名字的邊界由商標劃定</h2>
<p>pastel de nata 是通稱，指的是這一整類。<strong>Pastéis de Belém 是里斯本貝倫區那一家店的名字，受商標保護</strong>：ANTIGA CONFEITARIA DE BELEM LDA 持有歐盟商標 EUTM 001254895，1999 年申請、2000 年註冊，涵蓋餅乾與糕點類。</p>
<p>所以同一份配方換一家店做，就只能叫 pastel de nata。<strong>這一種切法連食物本身都不看</strong>——分開兩個名字的是誰有權使用它，而不是成品有什麼差別。台灣說的「葡式蛋塔」指的就是這一整類。按形狀切的名字是 <a href="../../naming/flan/">flan</a>，古義按材料、今義按質地切的是 <a href="../../naming/geng/">羹</a>。</p>
<h2 id="起源查得到的只有三個年份而它們分屬三個等級">起源查得到的只有三個年份，而它們分屬三個等級</h2>
<p><strong>1834 年</strong>葡萄牙解散修會、關閉全國的修道院與女修院。這一條有法令。</p>
<p><strong>1879 年</strong>一份公證書記載 Domingos Rafael Alves 以十萬 réis 向教子 José Vicente da Silva Pinto 買下配方的祕密。這是關於這家店最早的文件證據。</p>
<p><strong>1837 年</strong>是店家自述的開業年份，而這個說法的來源是 1983 年由該店一位股東提供的資訊。</p>
<p>修道院起源這一條更弱：葡文維基寫的是「terá sido criado pelos monges jerónimos」，用的是推測式。本篇因此不寫成事實。另一個流傳很廣的說法——修士用大量蛋白替衣物上漿、剩下的蛋黃拿來做點心——在查得到的每一個來源裡都標為相傳，同樣不採用。</p>
<h2 id="兩道都焦黑這一道靠溫差派皮布丁塔靠放寬的容錯帶">兩道都焦黑：這一道靠溫差，派皮布丁塔靠放寬的容錯帶</h2>
<p><a href="../flan-patissier/">flan pâtissier（派皮布丁塔）</a> 同樣直接進烤箱、表面同樣焦黑，而它走的是另一條路：烤得久、烤得透，餡裡加玉米粉把容錯帶放寬。它的焦斑來自寬容錯帶給的餘裕，表面有時間走到焦化而內部仍然完整，所以成品內外一致、扎實得可以整模烤好再切片。這一道的焦斑則是溫差的證據，內外本來就不一致。澱粉怎麼穩定蛋白質的網、厚度與可切片從哪裡來，是派皮布丁塔那一頁的主題；兩條路怎麼分、成品為什麼不同，在 <a href="../../techniques/direct-baking/">直接烘烤</a>。</p>
]]></content:encoded></item><item><title>名字</title><link>https://tarrragon.github.io/blog/til/cooking/naming/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/cooking/naming/</guid><description>&lt;p>這個子分類&lt;strong>從名字進入&lt;/strong>：手上有一個字，問它底下有哪些成品。名字本身不是重點，它是分辨的工具——各地按不同的方式命名，有的按形狀、有的按質地、有的按手法，而這幾種切法互相對不上，也對不上成品實際的界線。讀者被卡住的位置幾乎都在這裡。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="flan/">flan&lt;/a>：按&lt;strong>形狀&lt;/strong>切。而形狀跟目的、調味、材料一個都不對應，所以同一個字底下同時有甜點與配菜&lt;/li>
&lt;li>&lt;a href="geng/">羹&lt;/a>：古義按&lt;strong>材料&lt;/strong>切、今義按&lt;strong>質地&lt;/strong>切。台灣又在質地之上加了一道古義沒有的條件（勾芡），於是按質地命名的「蛋羹」在台灣讀不通&lt;/li>
&lt;/ul>
&lt;p>另有兩種切法不看食物長什麼樣。&lt;a href="../dishes/quiche/">quiche&lt;/a> 按它所屬的上位類別切——字來自德語的 Kuchen「蛋糕」，說的是它歸在哪一類底下，不是它是什麼樣子。還有一種連食物都不看：&lt;a href="../dishes/pastel-de-nata/">pastel de nata&lt;/a> 是通稱，而 Pastéis de Belém 是一家店的註冊商標——同一份配方換一家店做就換一個名字，劃界的是誰有權使用那個名字。&lt;/p>
&lt;h2 id="這裡不寫作法">這裡不寫作法&lt;/h2>
&lt;p>每道菜的完整作法、比例與判讀住在 &lt;a href="../dishes/">菜&lt;/a> 底下的單篇裡，這裡只給指向。這個索引若也各寫一份說明，同一道菜會有兩份講法而隨時間漂移。&lt;/p>
&lt;p>想從成品的樣子反查的話，入口是 &lt;a href="../forms/">形態&lt;/a>；想知道某一步在解什麼問題，入口是 &lt;a href="../techniques/">手法&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>這個子分類<strong>從名字進入</strong>：手上有一個字，問它底下有哪些成品。名字本身不是重點，它是分辨的工具——各地按不同的方式命名，有的按形狀、有的按質地、有的按手法，而這幾種切法互相對不上，也對不上成品實際的界線。讀者被卡住的位置幾乎都在這裡。</p>
<ul>
<li><a href="flan/">flan</a>：按<strong>形狀</strong>切。而形狀跟目的、調味、材料一個都不對應，所以同一個字底下同時有甜點與配菜</li>
<li><a href="geng/">羹</a>：古義按<strong>材料</strong>切、今義按<strong>質地</strong>切。台灣又在質地之上加了一道古義沒有的條件（勾芡），於是按質地命名的「蛋羹」在台灣讀不通</li>
</ul>
<p>另有兩種切法不看食物長什麼樣。<a href="../dishes/quiche/">quiche</a> 按它所屬的上位類別切——字來自德語的 Kuchen「蛋糕」，說的是它歸在哪一類底下，不是它是什麼樣子。還有一種連食物都不看：<a href="../dishes/pastel-de-nata/">pastel de nata</a> 是通稱，而 Pastéis de Belém 是一家店的註冊商標——同一份配方換一家店做就換一個名字，劃界的是誰有權使用那個名字。</p>
<h2 id="這裡不寫作法">這裡不寫作法</h2>
<p>每道菜的完整作法、比例與判讀住在 <a href="../dishes/">菜</a> 底下的單篇裡，這裡只給指向。這個索引若也各寫一份說明，同一道菜會有兩份講法而隨時間漂移。</p>
<p>想從成品的樣子反查的話，入口是 <a href="../forms/">形態</a>；想知道某一步在解什麼問題，入口是 <a href="../techniques/">手法</a>。</p>
]]></content:encoded></item><item><title>英式 flan（開放式塔）</title><link>https://tarrragon.github.io/blog/til/cooking/dishes/english-flan/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/cooking/dishes/english-flan/</guid><description>&lt;p>在英國，flan 指的是一個有邊、無上蓋、底座盛著餡的圓形烤物。這個字保證的是形狀，餡放什麼不在它管的範圍裡——水果 flan 是甜的，cheese flan 接近鹹派，兩者同樣叫這個名字。&lt;/p>
&lt;h2 id="這個字約束形狀不約束內容">這個字約束形狀，不約束內容&lt;/h2>
&lt;p>「有邊、無上蓋、圓形」把它跟兩類食物分開：有蓋的那些在英文裡多半叫 pie，而沒有邊、餡直接攤在底座上的那些不算。剩下的空間很寬——甜的鹹的、蛋做的水果做的、冷的熱的，全部收得進來。&lt;/p>
&lt;p>&lt;strong>所以在菜單上看到這個字，能確定的只有端上來的是什麼形狀。&lt;/strong> 它是甜點還是正餐、要不要冷藏、裡面有沒有蛋，這個字一項都不預測，要看寫在它前面的那個詞（fruit flan、cheese flan、custard flan）或者問。&lt;/p>
&lt;h2 id="底座有兩種而它們的加熱關係相反">底座有兩種，而它們的加熱關係相反&lt;/h2>
&lt;p>&lt;strong>派皮底&lt;/strong>是生的麵團，餡倒進去之後一起進烤箱，餡在裡面凝固——成敗因此綁在烤箱的溫度上。&lt;strong>海綿蛋糕底&lt;/strong>反過來，底座先單獨烤成、放涼，餡才鋪上去，所以餡從來沒有進過烤箱。&lt;/p>
&lt;p>&lt;strong>這個相反是這個字最麻煩的地方&lt;/strong>：它把兩個失敗條件完全不同的東西裝在同一個名字底下，而名字本身不透露端上來的是哪一種。派皮那一種的凝固物理在 &lt;a href="../../forms/pastry-tart/">派皮塔&lt;/a>，海綿底那一種為什麼餡能放什麼受限制在 &lt;a href="../../forms/sponge-flan/">海綿底塔&lt;/a>。&lt;/p>
&lt;h2 id="同一個字在英國與西班牙指相反的兩種食物">同一個字在英國與西班牙指相反的兩種食物&lt;/h2>
&lt;p>西班牙的 flan de queso 是加了起司的蛋奶凍，甜的，脫模後淋焦糖醬；英國的 cheese flan 是加了起司的派皮塔，接近鹹派。兩者同樣以起司為賣點、同樣叫 flan，而端上來的是兩種不同的食物。&lt;/p>
&lt;p>分開它們的是國別，不是菜名裡的任何一個字。看到 flan 這個字的當下，先確認這是哪一國的菜單，後面的線索才讀得對。&lt;/p>
&lt;h2 id="這個字底下裝了兩類東西而別的語言把它們分開叫">這個字底下裝了兩類東西，而別的語言把它們分開叫&lt;/h2>
&lt;p>英國用一個字涵蓋兩個形態，其他語言則各給名字。派皮底那一類在法國按餡分成兩個：加了玉米粉的甜餡叫 flan pâtissier，鹹餡加培根與起司的叫 quiche——&lt;a href="../flan-patissier/">派皮布丁塔&lt;/a> 寫澱粉怎麼撐寬容錯帶，&lt;a href="../quiche/">法式鹹派&lt;/a> 寫傳統的 quiche lorraine 到底加不加起司。&lt;/p>
&lt;p>海綿底那一類在別的語言裡沒有對應的單一名稱，因為它的分類依據（底座先烤、餡後鋪）在那些語言裡不構成一個類。&lt;/p>
&lt;p>&lt;strong>所以「英國的 flan 是什麼」這個問題答不出一個東西，只答得出一個形狀。&lt;/strong> 想從成品反查它屬於哪一類，見 &lt;a href="../../forms/pastry-tart/">派皮塔&lt;/a> 與 &lt;a href="../../forms/sponge-flan/">海綿底塔&lt;/a>；想知道這個字為什麼落在只管形狀這個位置，見 &lt;a href="../../naming/flan/">flan&lt;/a>。&lt;/p>
&lt;p>派皮那一種的完整成員與兩種容器形態，在 &lt;a href="../../forms/pastry-tart/">派皮塔&lt;/a>；海綿底那一種為什麼餡能放什麼受限制，在 &lt;a href="../../forms/sponge-flan/">海綿底塔&lt;/a>。派皮那一種的餡為什麼難烤、失敗長什麼樣，在 &lt;a href="../../forms/egg-custard/">egg custard（蛋液凝凍）&lt;/a>。&lt;/p>
&lt;p>這個字為什麼會落在「只管形狀」這個位置、以及它在各國分別指什麼，在 &lt;a href="../../naming/flan/">flan&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<p>在英國，flan 指的是一個有邊、無上蓋、底座盛著餡的圓形烤物。這個字保證的是形狀，餡放什麼不在它管的範圍裡——水果 flan 是甜的，cheese flan 接近鹹派，兩者同樣叫這個名字。</p>
<h2 id="這個字約束形狀不約束內容">這個字約束形狀，不約束內容</h2>
<p>「有邊、無上蓋、圓形」把它跟兩類食物分開：有蓋的那些在英文裡多半叫 pie，而沒有邊、餡直接攤在底座上的那些不算。剩下的空間很寬——甜的鹹的、蛋做的水果做的、冷的熱的，全部收得進來。</p>
<p><strong>所以在菜單上看到這個字，能確定的只有端上來的是什麼形狀。</strong> 它是甜點還是正餐、要不要冷藏、裡面有沒有蛋，這個字一項都不預測，要看寫在它前面的那個詞（fruit flan、cheese flan、custard flan）或者問。</p>
<h2 id="底座有兩種而它們的加熱關係相反">底座有兩種，而它們的加熱關係相反</h2>
<p><strong>派皮底</strong>是生的麵團，餡倒進去之後一起進烤箱，餡在裡面凝固——成敗因此綁在烤箱的溫度上。<strong>海綿蛋糕底</strong>反過來，底座先單獨烤成、放涼，餡才鋪上去，所以餡從來沒有進過烤箱。</p>
<p><strong>這個相反是這個字最麻煩的地方</strong>：它把兩個失敗條件完全不同的東西裝在同一個名字底下，而名字本身不透露端上來的是哪一種。派皮那一種的凝固物理在 <a href="../../forms/pastry-tart/">派皮塔</a>，海綿底那一種為什麼餡能放什麼受限制在 <a href="../../forms/sponge-flan/">海綿底塔</a>。</p>
<h2 id="同一個字在英國與西班牙指相反的兩種食物">同一個字在英國與西班牙指相反的兩種食物</h2>
<p>西班牙的 flan de queso 是加了起司的蛋奶凍，甜的，脫模後淋焦糖醬；英國的 cheese flan 是加了起司的派皮塔，接近鹹派。兩者同樣以起司為賣點、同樣叫 flan，而端上來的是兩種不同的食物。</p>
<p>分開它們的是國別，不是菜名裡的任何一個字。看到 flan 這個字的當下，先確認這是哪一國的菜單，後面的線索才讀得對。</p>
<h2 id="這個字底下裝了兩類東西而別的語言把它們分開叫">這個字底下裝了兩類東西，而別的語言把它們分開叫</h2>
<p>英國用一個字涵蓋兩個形態，其他語言則各給名字。派皮底那一類在法國按餡分成兩個：加了玉米粉的甜餡叫 flan pâtissier，鹹餡加培根與起司的叫 quiche——<a href="../flan-patissier/">派皮布丁塔</a> 寫澱粉怎麼撐寬容錯帶，<a href="../quiche/">法式鹹派</a> 寫傳統的 quiche lorraine 到底加不加起司。</p>
<p>海綿底那一類在別的語言裡沒有對應的單一名稱，因為它的分類依據（底座先烤、餡後鋪）在那些語言裡不構成一個類。</p>
<p><strong>所以「英國的 flan 是什麼」這個問題答不出一個東西，只答得出一個形狀。</strong> 想從成品反查它屬於哪一類，見 <a href="../../forms/pastry-tart/">派皮塔</a> 與 <a href="../../forms/sponge-flan/">海綿底塔</a>；想知道這個字為什麼落在只管形狀這個位置，見 <a href="../../naming/flan/">flan</a>。</p>
<p>派皮那一種的完整成員與兩種容器形態，在 <a href="../../forms/pastry-tart/">派皮塔</a>；海綿底那一種為什麼餡能放什麼受限制，在 <a href="../../forms/sponge-flan/">海綿底塔</a>。派皮那一種的餡為什麼難烤、失敗長什麼樣，在 <a href="../../forms/egg-custard/">egg custard（蛋液凝凍）</a>。</p>
<p>這個字為什麼會落在「只管形狀」這個位置、以及它在各國分別指什麼，在 <a href="../../naming/flan/">flan</a>。</p>
]]></content:encoded></item><item><title>羹</title><link>https://tarrragon.github.io/blog/til/cooking/naming/geng/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/til/cooking/naming/geng/</guid><description>&lt;p>古代字書裡的羹按&lt;strong>材料&lt;/strong>切。《爾雅·釋器》記「肉謂之羹」，郭璞注為「肉臛也」（臛也是肉做的濃湯），邢昺疏開頭一句就講明了這一條在分什麼：「此辨魚肉所作食味之名也。」分的是這個食物用什麼做的。&lt;/p>
&lt;p>《說文解字》收的本字是「𩱧」，在䰜部（一般說的鬻部），說解作「五味盉羹也」——盉是調和，後世字書引它時多寫成通行的「和」。這一條說的也是調味，不是稠度。&lt;/p>
&lt;p>這個字的邊界寬到調味與不調味都收得進去。《周禮·天官·亨人》記祭祀要備「大羹鉶羹」兩種，注解說「羹加五味，盛以鉶器，故曰鉶羹」——加了五味的叫鉶羹，不加的叫大羹；《禮記·樂記》講大饗之禮「大羹不和，有遺味者矣」，講的就是不加五味的那一種。&lt;/p>
&lt;p>稠不稠不在這些條件裡。而今天兩岸叫得出口的羹，認的正是稠——&lt;strong>這個字的判斷標準從材料換成了質地&lt;/strong>。雞蛋羹是蛋做的，按「肉謂之羹」根本掛不上這個字，讓它掛得上的是它舀起來的樣子。&lt;/p>
&lt;h2 id="台灣拿這個字去描述一碗湯時它要求勾芡">台灣拿這個字去描述一碗湯時，它要求勾芡&lt;/h2>
&lt;p>肉羹、魷魚羹、花枝羹、羊肉羹，稠度一律來自太白粉或番薯粉——勾芡就是把澱粉調成水漿倒進滾湯裡攪散，讓湯變稠。&lt;strong>在台灣，稠度若不是這樣來的，就不叫羹。&lt;/strong>&lt;/p>
&lt;h2 id="這個字也出現在外來語的名字裡">這個字也出現在外來語的名字裡&lt;/h2>
&lt;p>羊羹是一塊可以切開的凝固甜點，多半是紅豆泥加洋菜凝成，跟湯與勾芡都無關。這個名字連同它指的那樣點心一起從日語來，中文這一邊拿到的是整個現成的詞。&lt;/p>
&lt;p>&lt;strong>所以本篇的條件對它不適用。&lt;/strong> 前面幾節說的是拿這個字去描述一碗湯的時候，它在兩岸各要求什麼。外來語碰巧用上了同一個字，而它指的那樣點心落在這些條件的範圍之外。&lt;/p>
&lt;h2 id="中國的羹不要求勾芡">中國的羹不要求勾芡&lt;/h2>
&lt;p>中國說的 &lt;a href="../../dishes/chinese-steamed-egg/">雞蛋羹&lt;/a> 是蛋液蒸成的滑嫩凝凍，濃稠、半固體、用湯匙舀著吃，稠度來自蛋而非澱粉。中國同樣有大量勾芡的羹——西湖牛肉羹、酸辣羹——兩種都叫羹。&lt;/p>
&lt;p>兩邊都按質地認，而台灣在質地之上多要求了一件事：稠度得是勾芡來的。中國沒有這道限制，質地夠濃稠就算。&lt;/p>
&lt;h2 id="雞蛋羹與蒸蛋是兩種命名方式">「雞蛋羹」與「蒸蛋」是兩種命名方式&lt;/h2>
&lt;p>同一道菜，兩個名字按完全不同的方式切開它。&lt;strong>「蛋羹」按質地切&lt;/strong>：濃稠、半固體，落在羹這一類裡。&lt;strong>「蒸蛋」按手法切&lt;/strong>：用蒸的蛋。手法相同，兩個名字說的是不同的事。&lt;/p>
&lt;p>台灣讀者對不上這兩個名字，因為台灣的羹要求勾芡，而蒸蛋沒有——「蛋羹」在台灣被讀成加了蛋花的勾芡湯。&lt;/p>
&lt;h2 id="從成品的樣子反查">從成品的樣子反查&lt;/h2>
&lt;p>這個字在兩岸各自涵蓋的成品落在兩個不同的類別，而分開它們的是稠度從哪裡來：&lt;/p>
&lt;ul>
&lt;li>稠度來自澱粉、成品仍然是液體只是流得慢 → &lt;a href="../../forms/thickened-soup/">勾芡濃湯&lt;/a>，那一篇寫這一類的完整成員、以及主料換過一輪而湯那一層沒變&lt;/li>
&lt;li>稠度來自蛋、成品是半固體舀得起來 → &lt;a href="../../forms/egg-custard/">egg custard（蛋液凝凍）&lt;/a>，那一篇寫凝固與變質之間只有三度&lt;/li>
&lt;/ul>
&lt;p>台灣的 &lt;a href="../../dishes/rou-geng/">肉羹&lt;/a> 落在前一個，那一篇寫塊與湯為什麼是兩層不同的稠化；中國的 &lt;a href="../../dishes/chinese-steamed-egg/">雞蛋羹&lt;/a> 落在後一個，那一篇寫水量怎麼同時決定嫩度與成形難度。&lt;strong>兩岸對同一個字的要求差在哪，正好對應這兩頁的分界。&lt;/strong>&lt;/p>
&lt;h2 id="別的字用別的方式切">別的字用別的方式切&lt;/h2>
&lt;p>羹的古義按材料切、今義按質地切，而歐洲語言也有名字比作法更分歧的同型現象：&lt;a href="../flan/">flan&lt;/a> 按形狀切，那一篇寫這個字在西班牙、拉丁美洲、法國、英國、義大利分別指哪一種成品，以及為什麼形狀這個切法跟吃的人在意的每一項都對不上。&lt;/p></description><content:encoded><![CDATA[<p>古代字書裡的羹按<strong>材料</strong>切。《爾雅·釋器》記「肉謂之羹」，郭璞注為「肉臛也」（臛也是肉做的濃湯），邢昺疏開頭一句就講明了這一條在分什麼：「此辨魚肉所作食味之名也。」分的是這個食物用什麼做的。</p>
<p>《說文解字》收的本字是「𩱧」，在䰜部（一般說的鬻部），說解作「五味盉羹也」——盉是調和，後世字書引它時多寫成通行的「和」。這一條說的也是調味，不是稠度。</p>
<p>這個字的邊界寬到調味與不調味都收得進去。《周禮·天官·亨人》記祭祀要備「大羹鉶羹」兩種，注解說「羹加五味，盛以鉶器，故曰鉶羹」——加了五味的叫鉶羹，不加的叫大羹；《禮記·樂記》講大饗之禮「大羹不和，有遺味者矣」，講的就是不加五味的那一種。</p>
<p>稠不稠不在這些條件裡。而今天兩岸叫得出口的羹，認的正是稠——<strong>這個字的判斷標準從材料換成了質地</strong>。雞蛋羹是蛋做的，按「肉謂之羹」根本掛不上這個字，讓它掛得上的是它舀起來的樣子。</p>
<h2 id="台灣拿這個字去描述一碗湯時它要求勾芡">台灣拿這個字去描述一碗湯時，它要求勾芡</h2>
<p>肉羹、魷魚羹、花枝羹、羊肉羹，稠度一律來自太白粉或番薯粉——勾芡就是把澱粉調成水漿倒進滾湯裡攪散，讓湯變稠。<strong>在台灣，稠度若不是這樣來的，就不叫羹。</strong></p>
<h2 id="這個字也出現在外來語的名字裡">這個字也出現在外來語的名字裡</h2>
<p>羊羹是一塊可以切開的凝固甜點，多半是紅豆泥加洋菜凝成，跟湯與勾芡都無關。這個名字連同它指的那樣點心一起從日語來，中文這一邊拿到的是整個現成的詞。</p>
<p><strong>所以本篇的條件對它不適用。</strong> 前面幾節說的是拿這個字去描述一碗湯的時候，它在兩岸各要求什麼。外來語碰巧用上了同一個字，而它指的那樣點心落在這些條件的範圍之外。</p>
<h2 id="中國的羹不要求勾芡">中國的羹不要求勾芡</h2>
<p>中國說的 <a href="../../dishes/chinese-steamed-egg/">雞蛋羹</a> 是蛋液蒸成的滑嫩凝凍，濃稠、半固體、用湯匙舀著吃，稠度來自蛋而非澱粉。中國同樣有大量勾芡的羹——西湖牛肉羹、酸辣羹——兩種都叫羹。</p>
<p>兩邊都按質地認，而台灣在質地之上多要求了一件事：稠度得是勾芡來的。中國沒有這道限制，質地夠濃稠就算。</p>
<h2 id="雞蛋羹與蒸蛋是兩種命名方式">「雞蛋羹」與「蒸蛋」是兩種命名方式</h2>
<p>同一道菜，兩個名字按完全不同的方式切開它。<strong>「蛋羹」按質地切</strong>：濃稠、半固體，落在羹這一類裡。<strong>「蒸蛋」按手法切</strong>：用蒸的蛋。手法相同，兩個名字說的是不同的事。</p>
<p>台灣讀者對不上這兩個名字，因為台灣的羹要求勾芡，而蒸蛋沒有——「蛋羹」在台灣被讀成加了蛋花的勾芡湯。</p>
<h2 id="從成品的樣子反查">從成品的樣子反查</h2>
<p>這個字在兩岸各自涵蓋的成品落在兩個不同的類別，而分開它們的是稠度從哪裡來：</p>
<ul>
<li>稠度來自澱粉、成品仍然是液體只是流得慢 → <a href="../../forms/thickened-soup/">勾芡濃湯</a>，那一篇寫這一類的完整成員、以及主料換過一輪而湯那一層沒變</li>
<li>稠度來自蛋、成品是半固體舀得起來 → <a href="../../forms/egg-custard/">egg custard（蛋液凝凍）</a>，那一篇寫凝固與變質之間只有三度</li>
</ul>
<p>台灣的 <a href="../../dishes/rou-geng/">肉羹</a> 落在前一個，那一篇寫塊與湯為什麼是兩層不同的稠化；中國的 <a href="../../dishes/chinese-steamed-egg/">雞蛋羹</a> 落在後一個，那一篇寫水量怎麼同時決定嫩度與成形難度。<strong>兩岸對同一個字的要求差在哪，正好對應這兩頁的分界。</strong></p>
<h2 id="別的字用別的方式切">別的字用別的方式切</h2>
<p>羹的古義按材料切、今義按質地切，而歐洲語言也有名字比作法更分歧的同型現象：<a href="../flan/">flan</a> 按形狀切，那一篇寫這個字在西班牙、拉丁美洲、法國、英國、義大利分別指哪一種成品，以及為什麼形狀這個切法跟吃的人在意的每一項都對不上。</p>
]]></content:encoded></item></channel></rss>