<?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>Rule-Codification on Tarragon</title><link>https://tarrragon.github.io/blog/tags/rule-codification/</link><description>Recent content in Rule-Codification on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Wed, 27 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/rule-codification/index.xml" rel="self" type="application/rss+xml"/><item><title>規範化跟自審是兩種認知任務、立規範當下無法保護同批稿件</title><link>https://tarrragon.github.io/blog/report/rule-codification-vs-self-audit/</link><pubDate>Wed, 27 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/report/rule-codification-vs-self-audit/</guid><description>&lt;h2 id="結論">結論&lt;/h2>
&lt;p>把反模式抽象成規範卡、跟在自己稿件辨識該反模式的局部實例、是兩種不同認知任務。同一個作者可以清楚寫下「『看 X 如何 Y』是抽象斷言反模式」、同一個 batch 內已寫的 5 篇章節仍能有 11 處該句型未被察覺。&lt;/p>
&lt;p>兩個任務對比：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>認知任務&lt;/th>
 &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>Outside-in（歸納）&lt;/td>
 &lt;td>找 N 個 case 的共同特徵、命名&lt;/td>
 &lt;td>看到不同 case 重複出現同類問題&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>自審&lt;/td>
 &lt;td>Inside-out（比對）&lt;/td>
 &lt;td>把規範當 grep keyword、掃稿件&lt;/td>
 &lt;td>主動把卡片「判讀徵兆」套到自己文字&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>兩者用相似概念詞、走不同神經路徑。立規範時注意力放在「為什麼這 pattern 是反模式」、自審時注意力要放在「我這句話符不符合該 pattern」。前一個動作完成、不會自動觸發後一個動作。&lt;/p>
&lt;h2 id="為什麼立規範後仍會犯">為什麼立規範後仍會犯&lt;/h2>
&lt;p>三個認知機制讓兩者解耦：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>抽象化耗用認知頻寬&lt;/strong>：寫下「N+1 query 反模式」這個概念時、作者的工作記憶被 pattern 的本質、對比、邊界佔滿、不會同時掃描自己已寫過的稿件&lt;/li>
&lt;li>&lt;strong>規範化視角是 outside-in&lt;/strong>：規範化把 N 個實例抽象成 1 個模式、看的是「共同特徵」；自審視角是 inside-out、從自己具體句子往外比對、看的是「這句屬不屬於這個 pattern」&lt;/li>
&lt;li>&lt;strong>同 batch 主題語意 attractor&lt;/strong>（見 &lt;a href="https://tarrragon.github.io/blog/report/cadence-homogenization-in-batch-writing/" data-link-title="Cadence 同質化是模板的隱形維度" data-link-desc="規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位">#122 Cadence 同質化是模板的隱形維度&lt;/a>）：規範化之前寫的稿件、受同主題 / 同 constraint 拉到相似句型；規範化動作本身不會 retroactive 修這些句型、需要主動 sweep&lt;/li>
&lt;/ol>
&lt;p>這三個機制累積起來、「我剛寫完反模式定義」不等於「我能在自己稿件抓出該反模式的所有實例」。&lt;/p>
&lt;h2 id="case">Case&lt;/h2>
&lt;p>backend 模組 5 篇章節（5.9 / 0.18 / 0.19 / 9.13 / 1.13）的修正過程：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>Round 1 reviewer audit&lt;/strong> 抓出 1.13 章節案例引用 mis-cite、修正後寫成 &lt;a href="https://tarrragon.github.io/blog/report/case-misalignment-reverse-inquiry/" data-link-title="案例庫不對齊章節主題時用反向追問取代強掛" data-link-desc="當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度">#146 案例庫不對齊章節主題時用反向追問&lt;/a> 卡片。#146 明確列出「抽象斷言訊號：『看 X 如何 Y』這類無具體斷言的句型是反模式」、並作為「判讀徵兆」的四訊號之一。&lt;/li>
&lt;li>&lt;strong>#146 卡寫完當下&lt;/strong>、作者同 batch 已寫的 5 篇章節 case 段內仍有 11 處「看 X 如何 Y」句型未被察覺、未被修正。&lt;/li>
&lt;li>&lt;strong>Round 2 reviewer&lt;/strong> 用 cadence frame 跑 grep（直接拿 #146 描述的反模式當 keyword）、抓出全部 11 處、Round 2 修正後用具體事實 / 數字 / 機制斷言取代。&lt;/li>
&lt;/ol>
&lt;p>這個案例的諷刺感正是本卡的核心：作者剛寫完規範、自審能力卻沒同步提升。中間缺的是「規範化 → grep 自審」這條主動觸發路徑。Round 2 reviewer 補上的就是這條路徑、但理想上規範作者自己當下就該做。&lt;/p>
&lt;h2 id="修法">修法&lt;/h2>
&lt;p>三種觸發機制可以接在規範化動作後：&lt;/p>
&lt;h3 id="1-立規範後立刻跑-keyword-grep含同義變體">1. 立規範後立刻跑 keyword grep（含同義變體）&lt;/h3>
&lt;p>把新立的規範轉成 &lt;code>rg&lt;/code> 可掃的 pattern、對所有同 batch（甚至既有）稿件跑一次 grep：&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">&lt;span class="c1"># 例：#146 立下後的 keyword grep&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">2&lt;/span>&lt;span class="cl">rg &lt;span class="s2">&amp;#34;看 .{1,20}如何|看 .{1,20}的決|看 .{1,30}的策略|看 .{1,30}的差異&amp;#34;&lt;/span> content/&amp;lt;scope&amp;gt;/
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">3&lt;/span>&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">4&lt;/span>&lt;span class="cl">&lt;span class="c1"># 但同義變體 grep 同樣重要 — Round 3-A 抓出的盲區&lt;/span>
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">5&lt;/span>&lt;span class="cl">rg &lt;span class="s2">&amp;#34;展示 .{1,30}效應|展示 .{1,30}邏輯|本案展示|案例展示&amp;#34;&lt;/span> content/&amp;lt;scope&amp;gt;/&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>第一輪 grep pattern 受作者當下視野侷限、通常只涵蓋規範化時用的字面例子、漏掉同義變體。「規範化第一次落地不可能 catch 所有同義變體」是這條機制的天然限制 — 需要 Round N 持續擴張 keyword bank、跟 &lt;a href="https://tarrragon.github.io/blog/report/multi-pass-review-frame-granularity-blindspot/" data-link-title="Multi-pass review 的 frame 顆粒度盲點：抽象規則 → 具體訊號的轉譯不完整" data-link-desc="Multi-pass review 跑了 4 輪、字句層問題（口語修辭 / 地區用語 / 依賴 code / 廢話前綴）仍漏 catch——揭露 frame 顆粒度盲點：抽象規則（如「機會成本語氣」「正向陳述」「最重要的話優先說」）沒被轉譯成具體訊號（如 grep keyword bank：「一輩子 / 碰巧 / 撞牆 / 下次 X 時 / 不是 A 而是 B」）。修法是把每條規則展開成可 grep 的 keyword bank、加 reader simulation 輪、加 self-criticism 輪。">#114 multi-pass review 的 frame 顆粒度盲點&lt;/a> 同源。實證：本卡 Round 2 修「看 X 如何 Y」字面層、Round 3-A 仍能 catch 出「展示 X 效應」「展示 X 邏輯」同義變體、證明 path 需要疊代而非一次性動作。&lt;/p></description><content:encoded><![CDATA[<h2 id="結論">結論</h2>
<p>把反模式抽象成規範卡、跟在自己稿件辨識該反模式的局部實例、是兩種不同認知任務。同一個作者可以清楚寫下「『看 X 如何 Y』是抽象斷言反模式」、同一個 batch 內已寫的 5 篇章節仍能有 11 處該句型未被察覺。</p>
<p>兩個任務對比：</p>
<table>
  <thead>
      <tr>
          <th>認知任務</th>
          <th>視角</th>
          <th>處理動作</th>
          <th>觸發條件</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>規範化</td>
          <td>Outside-in（歸納）</td>
          <td>找 N 個 case 的共同特徵、命名</td>
          <td>看到不同 case 重複出現同類問題</td>
      </tr>
      <tr>
          <td>自審</td>
          <td>Inside-out（比對）</td>
          <td>把規範當 grep keyword、掃稿件</td>
          <td>主動把卡片「判讀徵兆」套到自己文字</td>
      </tr>
  </tbody>
</table>
<p>兩者用相似概念詞、走不同神經路徑。立規範時注意力放在「為什麼這 pattern 是反模式」、自審時注意力要放在「我這句話符不符合該 pattern」。前一個動作完成、不會自動觸發後一個動作。</p>
<h2 id="為什麼立規範後仍會犯">為什麼立規範後仍會犯</h2>
<p>三個認知機制讓兩者解耦：</p>
<ol>
<li><strong>抽象化耗用認知頻寬</strong>：寫下「N+1 query 反模式」這個概念時、作者的工作記憶被 pattern 的本質、對比、邊界佔滿、不會同時掃描自己已寫過的稿件</li>
<li><strong>規範化視角是 outside-in</strong>：規範化把 N 個實例抽象成 1 個模式、看的是「共同特徵」；自審視角是 inside-out、從自己具體句子往外比對、看的是「這句屬不屬於這個 pattern」</li>
<li><strong>同 batch 主題語意 attractor</strong>（見 <a href="/blog/report/cadence-homogenization-in-batch-writing/" data-link-title="Cadence 同質化是模板的隱形維度" data-link-desc="規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位">#122 Cadence 同質化是模板的隱形維度</a>）：規範化之前寫的稿件、受同主題 / 同 constraint 拉到相似句型；規範化動作本身不會 retroactive 修這些句型、需要主動 sweep</li>
</ol>
<p>這三個機制累積起來、「我剛寫完反模式定義」不等於「我能在自己稿件抓出該反模式的所有實例」。</p>
<h2 id="case">Case</h2>
<p>backend 模組 5 篇章節（5.9 / 0.18 / 0.19 / 9.13 / 1.13）的修正過程：</p>
<ol>
<li><strong>Round 1 reviewer audit</strong> 抓出 1.13 章節案例引用 mis-cite、修正後寫成 <a href="/blog/report/case-misalignment-reverse-inquiry/" data-link-title="案例庫不對齊章節主題時用反向追問取代強掛" data-link-desc="當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度">#146 案例庫不對齊章節主題時用反向追問</a> 卡片。#146 明確列出「抽象斷言訊號：『看 X 如何 Y』這類無具體斷言的句型是反模式」、並作為「判讀徵兆」的四訊號之一。</li>
<li><strong>#146 卡寫完當下</strong>、作者同 batch 已寫的 5 篇章節 case 段內仍有 11 處「看 X 如何 Y」句型未被察覺、未被修正。</li>
<li><strong>Round 2 reviewer</strong> 用 cadence frame 跑 grep（直接拿 #146 描述的反模式當 keyword）、抓出全部 11 處、Round 2 修正後用具體事實 / 數字 / 機制斷言取代。</li>
</ol>
<p>這個案例的諷刺感正是本卡的核心：作者剛寫完規範、自審能力卻沒同步提升。中間缺的是「規範化 → grep 自審」這條主動觸發路徑。Round 2 reviewer 補上的就是這條路徑、但理想上規範作者自己當下就該做。</p>
<h2 id="修法">修法</h2>
<p>三種觸發機制可以接在規範化動作後：</p>
<h3 id="1-立規範後立刻跑-keyword-grep含同義變體">1. 立規範後立刻跑 keyword grep（含同義變體）</h3>
<p>把新立的規範轉成 <code>rg</code> 可掃的 pattern、對所有同 batch（甚至既有）稿件跑一次 grep：</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"><span class="c1"># 例：#146 立下後的 keyword grep</span>
</span></span><span class="line"><span class="ln">2</span><span class="cl">rg <span class="s2">&#34;看 .{1,20}如何|看 .{1,20}的決|看 .{1,30}的策略|看 .{1,30}的差異&#34;</span> content/&lt;scope&gt;/
</span></span><span class="line"><span class="ln">3</span><span class="cl">
</span></span><span class="line"><span class="ln">4</span><span class="cl"><span class="c1"># 但同義變體 grep 同樣重要 — Round 3-A 抓出的盲區</span>
</span></span><span class="line"><span class="ln">5</span><span class="cl">rg <span class="s2">&#34;展示 .{1,30}效應|展示 .{1,30}邏輯|本案展示|案例展示&#34;</span> content/&lt;scope&gt;/</span></span></code></pre></div><p>第一輪 grep pattern 受作者當下視野侷限、通常只涵蓋規範化時用的字面例子、漏掉同義變體。「規範化第一次落地不可能 catch 所有同義變體」是這條機制的天然限制 — 需要 Round N 持續擴張 keyword bank、跟 <a href="/blog/report/multi-pass-review-frame-granularity-blindspot/" data-link-title="Multi-pass review 的 frame 顆粒度盲點：抽象規則 → 具體訊號的轉譯不完整" data-link-desc="Multi-pass review 跑了 4 輪、字句層問題（口語修辭 / 地區用語 / 依賴 code / 廢話前綴）仍漏 catch——揭露 frame 顆粒度盲點：抽象規則（如「機會成本語氣」「正向陳述」「最重要的話優先說」）沒被轉譯成具體訊號（如 grep keyword bank：「一輩子 / 碰巧 / 撞牆 / 下次 X 時 / 不是 A 而是 B」）。修法是把每條規則展開成可 grep 的 keyword bank、加 reader simulation 輪、加 self-criticism 輪。">#114 multi-pass review 的 frame 顆粒度盲點</a> 同源。實證：本卡 Round 2 修「看 X 如何 Y」字面層、Round 3-A 仍能 catch 出「展示 X 效應」「展示 X 邏輯」同義變體、證明 path 需要疊代而非一次性動作。</p>
<h3 id="2-結構句型-cadence-sweep補字面-grep-不抓的維度">2. 結構句型 cadence sweep（補字面 grep 不抓的維度）</h3>
<p>字面 keyword grep 抓詞、抓不到結構骨架。常見漏抓的結構句型：</p>
<ul>
<li>「先 X、再 Y、最後 Z」三段平行</li>
<li>「N 個案例可分別對應&hellip;」枚舉式收尾</li>
<li>「對應本章 X 段」反覆出現、構成段末 cadence</li>
</ul>
<p>這類結構違反字面層查不到、要靠 reviewer 跨稿件對讀才能 catch。修法是擴張 #122 cadence 同質化的 grep target、加入「結構骨架」維度：sweep「先看 .{1,30}、(再|接著)」「N 個 .* 分別」「對應本章「.*」段」這類 pattern。</p>
<h3 id="3-把規範卡的判讀徵兆當-self-audit-checklist">3. 把規範卡的「判讀徵兆」當 self-audit checklist</h3>
<p>每張 report 卡的「判讀徵兆」段（如 #146 列的 4 訊號：抽象句型 / 句型雷同 / 維度錯位 / 配額膨脹）就是現成的 self-audit checklist。立規範當下、作者應該主動把這 checklist 套到自己同 batch 稿件 — 而非預設「我剛寫完應該不會犯」。</p>
<h3 id="4-用-reviewer-跑-in-stream-sampling">4. 用 reviewer 跑 in-stream sampling</h3>
<p>如 <a href="/blog/report/emergence-violations-need-in-stream-sampling/" data-link-title="Emergence-class 違規規則化不了、要 stage 0 變體規劃 &#43; stage 內抽樣兩層" data-link-desc="違規分三類（字面 / 結構 / emergence）、enforcement 時機要對應違規類型；字面違規（emoji / 裸 URL）可 regex hook 在 pre-commit 攔、結構違規（章節缺失 / frontmatter）可 linter 攔、emergence 違規（cadence 同質化 / 跨檔語氣漂移）規則化不了、需要 *stage 0 變體規劃（主動設計）* &#43; *stage 內抽樣（被動監測）* 兩層；checkpoint 只是監測工具、若 stage 0 沒準備 variant、被動抽樣不會自動發現 collapse；補 #82 字面 vs 行為的「時機」軸">#124 emergence-class 違規 enforcement 時機</a> 描述、emergence-class 違規（cadence 同質、抽象斷言這類）字面 hook 抓不到、要 reviewer in-stream 才能發現。本案 Round 2 cadence reviewer 是這個機制的應用、Round 3-A 進一步抓出 Round 2 修法的同義變體盲區 — 兩輪 reviewer 用不同 frame 才能完整覆蓋。理想上規範作者自己應該先做前三層（字面 grep + 結構 sweep + checklist）、reviewer 是補位、不是替代。</p>
<p>四種機制按介入點分層：字面 grep 是 keyword 層、結構 sweep 是 cadence 層、checklist 是徵兆層、reviewer 是 frame 層。立規範後四層都跑一次、覆蓋率最完整。單跑字面 grep（如本卡初版只給 keyword pattern）會漏掉結構 cadence 跟同義變體、屬「規範化視角」單軸盲區、要靠後續疊代擴張。</p>
<h2 id="跟其他卡的關係">跟其他卡的關係</h2>
<ul>
<li><a href="/blog/report/cadence-homogenization-in-batch-writing/" data-link-title="Cadence 同質化是模板的隱形維度" data-link-desc="規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位">#122 Cadence 同質化是模板的隱形維度</a> — 解釋「為什麼同 batch 會有 systemic 違規」的成因機制（主題語意 attractor）。本卡補完：規範化動作本身無法解這個 attractor、需要主動 sweep 才能切斷。</li>
<li><a href="/blog/report/emergence-violations-need-in-stream-sampling/" data-link-title="Emergence-class 違規規則化不了、要 stage 0 變體規劃 &#43; stage 內抽樣兩層" data-link-desc="違規分三類（字面 / 結構 / emergence）、enforcement 時機要對應違規類型；字面違規（emoji / 裸 URL）可 regex hook 在 pre-commit 攔、結構違規（章節缺失 / frontmatter）可 linter 攔、emergence 違規（cadence 同質化 / 跨檔語氣漂移）規則化不了、需要 *stage 0 變體規劃（主動設計）* &#43; *stage 內抽樣（被動監測）* 兩層；checkpoint 只是監測工具、若 stage 0 沒準備 variant、被動抽樣不會自動發現 collapse；補 #82 字面 vs 行為的「時機」軸">#124 Emergence-class 違規規則化不了、要 stage 內抽樣</a> — 解釋「什麼時候 enforcement 最有效」（batch 進度 10-20%）。本卡補一個更早的時機點：立規範當下立刻 sweep 同 batch、不必等 batch 進度推進。</li>
<li><a href="/blog/report/multi-pass-review-frame-granularity-blindspot/" data-link-title="Multi-pass review 的 frame 顆粒度盲點：抽象規則 → 具體訊號的轉譯不完整" data-link-desc="Multi-pass review 跑了 4 輪、字句層問題（口語修辭 / 地區用語 / 依賴 code / 廢話前綴）仍漏 catch——揭露 frame 顆粒度盲點：抽象規則（如「機會成本語氣」「正向陳述」「最重要的話優先說」）沒被轉譯成具體訊號（如 grep keyword bank：「一輩子 / 碰巧 / 撞牆 / 下次 X 時 / 不是 A 而是 B」）。修法是把每條規則展開成可 grep 的 keyword bank、加 reader simulation 輪、加 self-criticism 輪。">#114 Multi-pass review 的 frame 顆粒度盲點</a> — 解釋「為什麼同 reviewer 多輪抓不到不同東西」、提出 keyword bank / reader simulation / self-criticism 三機制。本卡是 #114 在「規範作者本人」這個 reviewer 角色的具體實例：作者剛寫完規範、仍需主動換 frame 才能自審。</li>
<li><a href="/blog/report/collapse-is-implicit-default/" data-link-title="Collapse 是隱形預設：多維空間被壓成單格的三類典型" data-link-desc="決策對話、決策呈現、批量輸出三個 surface 都有同一個 pattern — 高維選擇空間預設被 collapse 到 1-2 個窄格、且這個 collapse 因為「便利 / 合規 / 簡潔」被當成中性預設、不被覺察；#80 是 decision surface 上的極致 collapse、#79 是 dialogue 五維 collapse、#123 是 output framing 在 constraint 下 collapse；三者共骨：*某個高自由度空間被便利驅動 reduce 到最少格子*；對策不是去除 collapse、是讓 collapse 變顯性、由設計者決定要 collapse 哪一維、不是預設全 collapse">#125 Collapse 是隱形預設</a> — 「規範化耗光認知頻寬、自審視角沒上線」是 collapse 的具體機制：規範化動作把高維注意力 reduce 到單軸（pattern 共同特徵）、其他軸（同 batch 自己稿件）被預設關閉。本卡是 #125 在「規範化 surface」的子實例。</li>
<li><a href="/blog/report/writing-review-multi-axis-completeness/" data-link-title="寫作 review 是多軸完整性、不是單軸深度" data-link-desc="寫作 review 的完整性不是單一軸越做越深、是多軸交集都對齊；#83 frame 軸 &#43; #121 instance 軸 &#43; #97 surface 軸 &#43; #95 scope 軸 &#43; #122 cadence 軸 &#43; #124 timing 軸 &#43; #114 granularity 軸、七軸正交、缺任一軸都會 systematic miss；review 設計時要 enumerate 七軸覆蓋狀況、不是只跑一兩個維度做深；是 #79 五維決策對話在 review 工具設計的姊妹卡">#126 寫作 review 是多軸完整性、不是單軸深度</a> — 本卡揭露的「規範化 ≠ 自審」是 #126「Timing 軸」+「Granularity 軸」的具體交集：立規範當下不掃 = timing collapse、規範字面 vs 同 batch 違規 = granularity collapse。</li>
<li><a href="/blog/report/case-misalignment-reverse-inquiry/" data-link-title="案例庫不對齊章節主題時用反向追問取代強掛" data-link-desc="當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度">#146 案例庫不對齊章節主題時用反向追問取代強掛</a> — 本卡的 case 來源。#146 才剛立規範、同 batch 仍犯該規範、是「規範化 ≠ 自審」最直接的諷刺證據。本卡跟 #146 互為驗證關係：#146 給出規範本身、本卡解釋為什麼立完規範還需要主動 sweep。</li>
</ul>
<h2 id="判讀徵兆">判讀徵兆</h2>
<p>立規範後若不主動 sweep 同 batch、會出現以下訊號：</p>
<ul>
<li><strong>諷刺對映訊號</strong>：規範卡描述的「反模式」可以一字不改貼回自己稿件、自己仍意識不到。最強訊號、出現代表 inside-out 視角完全沒啟動。</li>
<li><strong>跨稿件 catch 訊號</strong>：該規範立下後一週內 reviewer audit 跨稿件、catch 出該規範的多處違規（≥ 3 處）。代表規範化跟自審之間斷層。</li>
<li><strong>自審盲區訊號</strong>：自己 review 自己稿件時、卡片描述跟稿件實例之間的「相似度」感官弱（明明 textbook 案例、自己讀不出來）。代表規範化耗光認知頻寬、自審視角沒上線。</li>
<li><strong>品質非單調訊號</strong>：同 batch 多篇文章在規範化前後寫的、品質沒有顯著差異。代表規範化未轉換成執行力。</li>
</ul>
<p>出現任一訊號、表示「規範化 → 自審」這條路徑沒接通。立刻跑修法的三層機制（grep / checklist / reviewer）對自己稿件做 sweep。</p>
]]></content:encoded></item></channel></rss>