<?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/%E8%A6%8F%E5%89%87%E8%A8%AD%E8%A8%88/</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>Wed, 19 Aug 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/%E8%A6%8F%E5%89%87%E8%A8%AD%E8%A8%88/index.xml" rel="self" type="application/rss+xml"/><item><title>規則用數量當門檻時，先問那個數量在代理什麼判斷</title><link>https://tarrragon.github.io/blog/report/count-threshold-is-a-proxy-for-a-checkable-judgment/</link><pubDate>Wed, 19 Aug 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/report/count-threshold-is-a-proxy-for-a-checkable-judgment/</guid><description>&lt;h2 id="結論">結論&lt;/h2>
&lt;p>規則裡的數量門檻分兩種。&lt;strong>數量就是證據&lt;/strong>的那種留著：同一個問題出現第二次，重複本身就是「這不是運氣」的證據，沒有別的東西可以取代它（見 &lt;a href="../two-occurrence-threshold/">2 次門檻&lt;/a>）。&lt;strong>數量是代理&lt;/strong>的那種要換掉：它背後有一個真正的判斷，而那個判斷通常可以直接檢查，只是訂規則的當下比較難描述，於是用個數字頂替。&lt;/p>
&lt;p>分辨方法是問一句：&lt;strong>這個數字從 N-1 變成 N 的那一刻，世界上發生了什麼事&lt;/strong>。指得出來（多了一次獨立證據、跨過了統計顯著性、超出了單人可維護的上限）就是證據型。指不出來、只能說「這樣比較不會浪費」，就是代理型。&lt;/p>
&lt;p>代理型門檻的特徵是它在&lt;strong>維護者角度成立、在使用者角度失效&lt;/strong>。維護者關心的是「別產生沒人維護的東西」，使用者關心的是「這東西現在對我有沒有用」，而後者在第一個實例就有答案。&lt;/p>
&lt;h2 id="為什麼代理會在使用者角度失效">為什麼代理會在使用者角度失效&lt;/h2>
&lt;p>門檻把一段時間切成「還不算數」與「算數了」，而使用者不是在門檻跨過的那一刻才出現的。til 的例子具體：原規則是「同主題累積三篇以上再開子分類」，於是第一篇到第三篇之間，內容散在根層沒有分類說明。這段期間落地的讀者看到的是一份沒有標示的清單——而分類要解決的正是這個問題。門檻把解法延後到問題最不嚴重的時候才生效。&lt;/p>
&lt;p>更根本的問題是代理挑錯了要防的東西。那條規則想擋的失敗不是「篇數太少」，是「這個子分類其實只是某一篇文章的主題」。而後者可以直接測：寫得出一句「這裡收什麼」而那句話不等於裡面某一篇的標題，就是分類；寫不出來，累積十篇也還是一堆各自獨立的文章。判準一旦寫成這樣，數量就不必進來了。&lt;/p>
&lt;h2 id="為什麼訂規則的當下會伸手拿數字">為什麼訂規則的當下會伸手拿數字&lt;/h2>
&lt;p>數字有兩個對訂規則者的好處：它不必被解釋，而且它讓規則看起來可執行。「累積三篇」誰都會判；「寫得出範圍說明」聽起來像主觀判斷，訂規則的人會擔心它擋不住任何東西。&lt;/p>
&lt;p>這個擔心是對的，但解法不是換回數字，是把判斷寫成有痕跡的形式。「寫得出一句話」之所以擋得住，是因為那句話要寫出來、寫出來就可以被別人拿去比對——它有產物。真正擋不住的是沒有產物的判斷（「覺得夠成熟了」），而那跟「非數量」不是同一件事。&lt;/p>
&lt;h2 id="反模式">反模式&lt;/h2>
&lt;ul>
&lt;li>&lt;strong>用數量取代可直接檢查的判斷&lt;/strong>：「累積 N 篇再開分類」「重複 N 次再抽共用函式」「N 個以上才值得建卡」——這三個的真正判準分別是能不能說出範圍、有沒有共同的變動理由、是不是跨篇被當前提。&lt;/li>
&lt;li>&lt;strong>把代理型門檻寫死成流程閘門&lt;/strong>：數字進了 checklist 之後，實際判斷就不會再被做了，因為數字比判斷省力。&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>（不需要累積）。til 那條的替換是「寫得出一句『這裡收什麼』、而那句話不是複述某一篇的標題」——產物是那句範圍說明，它在第一篇就寫得出來或寫不出來。&lt;/p>
&lt;p>同時要保留原規則想防的失敗，寫成徵兆與處置而非門檻。til 那條的反向失敗是子分類長得比文章快、首頁變成一排名詞，處置是合併範圍相鄰的子分類。徵兆加處置取代門檻，是因為徵兆描述的是真正要避免的狀態，而門檻只是猜測那個狀態什麼時候會到。&lt;/p>
&lt;h2 id="觸發-case">觸發 case&lt;/h2>
&lt;p>&lt;code>content/til/_index.md&lt;/code> 原本寫「還沒成氣候的知識點直接放本資料夾根層、同主題累積三篇以上再開子分類」。實際要開一個新子分類時，手上剛好有兩篇同類內容（一篇既有、一篇要新寫），照規則不能開。停下來問這條規則在防什麼，才發現三這個數字沒有對應到任何事件——它只是「不要開空目錄」的估計值。改成範圍說明判準之後，同一批內容足以支持兩個子分類（群體層與個人層各一），而按原規則兩個都開不了。&lt;/p>
&lt;p>同一天的另一個實例在書單模組：Backlog 登記了六個術語缺卡，登記依據是「跨多篇被當共用前提」，但登記時沒有逐項數。實測後只有兩個真的跨篇，其餘四個都只出現在一篇，其中兩個還是該篇的主線術語、本來就該就地展開。這是同一個毛病的鏡像——前者用數量頂替判斷，後者宣稱了數量卻沒有真的去數。&lt;/p>
&lt;h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係&lt;/h2>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="../two-occurrence-threshold/">2 次門檻：第一次是運氣、第二次是訊號&lt;/a>：那是證據型門檻的範例，也是本卡的邊界。那裡數的是同一個問題的重複出現，而重複本身就是「不是偶然」的證據，沒有更直接的檢查方式可以取代。本卡不動那類門檻。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>&lt;a href="../escalation-trigger-quantification/">升級 trigger 的量化設計&lt;/a>：那張卡主張「不夠就升級」的「不夠」要量化，否則永遠覺得再觀察一下。本卡限定它的適用範圍——量化在被量的東西就是決策依據時有效；當數字只是某個可直接檢查的判斷的代理時，量化會把判斷擠掉而不是讓它更可執行。兩張卡的分界同樣是「這個數字在代理什麼」。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>&lt;a href="../checkable-anchor-must-be-able-to-fall/">#266 可核對的錨要選會下降的量&lt;/a>：姊妹——本卡管用數量當&lt;strong>門檻&lt;/strong>（累積 N 個再做 X），那張管用數量當&lt;strong>證據&lt;/strong>（覆蓋率 N/M 證明這一維有人在維護）。共同根因相同，失效方式不同：門檻側是 N 取代了判斷，證據側是分母沒有定義、而分子量的是措辭&lt;/p>
&lt;/li>
&lt;li>
&lt;p>&lt;a href="../axis-named-by-proxy-not-mechanism/">軸名取了次好的代理變數&lt;/a>：同型的錯誤發生在命名端——真正做功的機制寫在括號裡，而軸名用了它的代理。本卡是同一個錯誤發生在規則的觸發條件上。兩者可以並存於同一份規範：軸名取了代理、觸發條件也取了代理。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>&lt;a href="../name-collections-by-role-not-count/">集合命名用角色、不內嵌數量&lt;/a>：那裡的數量寄生在名稱（「六大原則」），本卡的數量寄生在規則的觸發條件。兩者的共同根因是數量比它要描述的東西容易寫下來，而代價都在後來才顯現。&lt;/p>
&lt;/li>
&lt;li>
&lt;p>&lt;a href="../mechanical-constraints-buy-the-measured-number/">#278 機械約束買到被量測的那個數字&lt;/a>：程式碼度量是代理型門檻最常見的載體（複雜度上限、覆蓋率下限），#278 給出代價的落點——它落在沒有被那個數字量到的維度上。&lt;/p>
&lt;/li>
&lt;/ul>
&lt;h2 id="判讀徵兆">判讀徵兆&lt;/h2>
&lt;ul>
&lt;li>規則裡出現「累積 N 個」「重複 N 次」「N 個以上」，而指不出 N-1 到 N 之間發生了什麼事。&lt;/li>
&lt;li>規則的理由只有「這樣比較不會浪費 / 比較好管理」，給不出使用者在門檻兩側的體驗差別。&lt;/li>
&lt;li>想遵守規則的人問「那我現在到底能不能做」，而答案取決於一個跟他的實際處境無關的計數。&lt;/li>
&lt;li>門檻跨過之前的那段期間，有人正在承受這條規則本來要解決的問題。&lt;/li>
&lt;/ul></description><content:encoded><![CDATA[<h2 id="結論">結論</h2>
<p>規則裡的數量門檻分兩種。<strong>數量就是證據</strong>的那種留著：同一個問題出現第二次，重複本身就是「這不是運氣」的證據，沒有別的東西可以取代它（見 <a href="../two-occurrence-threshold/">2 次門檻</a>）。<strong>數量是代理</strong>的那種要換掉：它背後有一個真正的判斷，而那個判斷通常可以直接檢查，只是訂規則的當下比較難描述，於是用個數字頂替。</p>
<p>分辨方法是問一句：<strong>這個數字從 N-1 變成 N 的那一刻，世界上發生了什麼事</strong>。指得出來（多了一次獨立證據、跨過了統計顯著性、超出了單人可維護的上限）就是證據型。指不出來、只能說「這樣比較不會浪費」，就是代理型。</p>
<p>代理型門檻的特徵是它在<strong>維護者角度成立、在使用者角度失效</strong>。維護者關心的是「別產生沒人維護的東西」，使用者關心的是「這東西現在對我有沒有用」，而後者在第一個實例就有答案。</p>
<h2 id="為什麼代理會在使用者角度失效">為什麼代理會在使用者角度失效</h2>
<p>門檻把一段時間切成「還不算數」與「算數了」，而使用者不是在門檻跨過的那一刻才出現的。til 的例子具體：原規則是「同主題累積三篇以上再開子分類」，於是第一篇到第三篇之間，內容散在根層沒有分類說明。這段期間落地的讀者看到的是一份沒有標示的清單——而分類要解決的正是這個問題。門檻把解法延後到問題最不嚴重的時候才生效。</p>
<p>更根本的問題是代理挑錯了要防的東西。那條規則想擋的失敗不是「篇數太少」，是「這個子分類其實只是某一篇文章的主題」。而後者可以直接測：寫得出一句「這裡收什麼」而那句話不等於裡面某一篇的標題，就是分類；寫不出來，累積十篇也還是一堆各自獨立的文章。判準一旦寫成這樣，數量就不必進來了。</p>
<h2 id="為什麼訂規則的當下會伸手拿數字">為什麼訂規則的當下會伸手拿數字</h2>
<p>數字有兩個對訂規則者的好處：它不必被解釋，而且它讓規則看起來可執行。「累積三篇」誰都會判；「寫得出範圍說明」聽起來像主觀判斷，訂規則的人會擔心它擋不住任何東西。</p>
<p>這個擔心是對的，但解法不是換回數字，是把判斷寫成有痕跡的形式。「寫得出一句話」之所以擋得住，是因為那句話要寫出來、寫出來就可以被別人拿去比對——它有產物。真正擋不住的是沒有產物的判斷（「覺得夠成熟了」），而那跟「非數量」不是同一件事。</p>
<h2 id="反模式">反模式</h2>
<ul>
<li><strong>用數量取代可直接檢查的判斷</strong>：「累積 N 篇再開分類」「重複 N 次再抽共用函式」「N 個以上才值得建卡」——這三個的真正判準分別是能不能說出範圍、有沒有共同的變動理由、是不是跨篇被當前提。</li>
<li><strong>把代理型門檻寫死成流程閘門</strong>：數字進了 checklist 之後，實際判斷就不會再被做了，因為數字比判斷省力。</li>
<li><strong>反向的過度修正</strong>：發現門檻不對就整條刪掉、不補替代判準。那會把規則變成沒有攔截點，而原本要防的失敗仍然存在。</li>
</ul>
<h2 id="修法">修法</h2>
<p>替換的判準要滿足兩件事：<strong>有產物</strong>（判斷完會留下可被別人比對的東西）與<strong>在第一個實例就成立</strong>（不需要累積）。til 那條的替換是「寫得出一句『這裡收什麼』、而那句話不是複述某一篇的標題」——產物是那句範圍說明，它在第一篇就寫得出來或寫不出來。</p>
<p>同時要保留原規則想防的失敗，寫成徵兆與處置而非門檻。til 那條的反向失敗是子分類長得比文章快、首頁變成一排名詞，處置是合併範圍相鄰的子分類。徵兆加處置取代門檻，是因為徵兆描述的是真正要避免的狀態，而門檻只是猜測那個狀態什麼時候會到。</p>
<h2 id="觸發-case">觸發 case</h2>
<p><code>content/til/_index.md</code> 原本寫「還沒成氣候的知識點直接放本資料夾根層、同主題累積三篇以上再開子分類」。實際要開一個新子分類時，手上剛好有兩篇同類內容（一篇既有、一篇要新寫），照規則不能開。停下來問這條規則在防什麼，才發現三這個數字沒有對應到任何事件——它只是「不要開空目錄」的估計值。改成範圍說明判準之後，同一批內容足以支持兩個子分類（群體層與個人層各一），而按原規則兩個都開不了。</p>
<p>同一天的另一個實例在書單模組：Backlog 登記了六個術語缺卡，登記依據是「跨多篇被當共用前提」，但登記時沒有逐項數。實測後只有兩個真的跨篇，其餘四個都只出現在一篇，其中兩個還是該篇的主線術語、本來就該就地展開。這是同一個毛病的鏡像——前者用數量頂替判斷，後者宣稱了數量卻沒有真的去數。</p>
<h2 id="跟其他抽象層原則的關係">跟其他抽象層原則的關係</h2>
<ul>
<li>
<p><a href="../two-occurrence-threshold/">2 次門檻：第一次是運氣、第二次是訊號</a>：那是證據型門檻的範例，也是本卡的邊界。那裡數的是同一個問題的重複出現，而重複本身就是「不是偶然」的證據，沒有更直接的檢查方式可以取代。本卡不動那類門檻。</p>
</li>
<li>
<p><a href="../escalation-trigger-quantification/">升級 trigger 的量化設計</a>：那張卡主張「不夠就升級」的「不夠」要量化，否則永遠覺得再觀察一下。本卡限定它的適用範圍——量化在被量的東西就是決策依據時有效；當數字只是某個可直接檢查的判斷的代理時，量化會把判斷擠掉而不是讓它更可執行。兩張卡的分界同樣是「這個數字在代理什麼」。</p>
</li>
<li>
<p><a href="../checkable-anchor-must-be-able-to-fall/">#266 可核對的錨要選會下降的量</a>：姊妹——本卡管用數量當<strong>門檻</strong>（累積 N 個再做 X），那張管用數量當<strong>證據</strong>（覆蓋率 N/M 證明這一維有人在維護）。共同根因相同，失效方式不同：門檻側是 N 取代了判斷，證據側是分母沒有定義、而分子量的是措辭</p>
</li>
<li>
<p><a href="../axis-named-by-proxy-not-mechanism/">軸名取了次好的代理變數</a>：同型的錯誤發生在命名端——真正做功的機制寫在括號裡，而軸名用了它的代理。本卡是同一個錯誤發生在規則的觸發條件上。兩者可以並存於同一份規範：軸名取了代理、觸發條件也取了代理。</p>
</li>
<li>
<p><a href="../name-collections-by-role-not-count/">集合命名用角色、不內嵌數量</a>：那裡的數量寄生在名稱（「六大原則」），本卡的數量寄生在規則的觸發條件。兩者的共同根因是數量比它要描述的東西容易寫下來，而代價都在後來才顯現。</p>
</li>
<li>
<p><a href="../mechanical-constraints-buy-the-measured-number/">#278 機械約束買到被量測的那個數字</a>：程式碼度量是代理型門檻最常見的載體（複雜度上限、覆蓋率下限），#278 給出代價的落點——它落在沒有被那個數字量到的維度上。</p>
</li>
</ul>
<h2 id="判讀徵兆">判讀徵兆</h2>
<ul>
<li>規則裡出現「累積 N 個」「重複 N 次」「N 個以上」，而指不出 N-1 到 N 之間發生了什麼事。</li>
<li>規則的理由只有「這樣比較不會浪費 / 比較好管理」，給不出使用者在門檻兩側的體驗差別。</li>
<li>想遵守規則的人問「那我現在到底能不能做」，而答案取決於一個跟他的實際處境無關的計數。</li>
<li>門檻跨過之前的那段期間，有人正在承受這條規則本來要解決的問題。</li>
</ul>
]]></content:encoded></item></channel></rss>