<?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>Skill on Tarragon</title><link>https://tarrragon.github.io/blog/tags/skill/</link><description>Recent content in Skill on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 26 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/skill/index.xml" rel="self" type="application/rss+xml"/><item><title>Compositional Writing</title><link>https://tarrragon.github.io/blog/skills/compositional-writing/skill/</link><pubDate>Fri, 26 Jun 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/skills/compositional-writing/skill/</guid><description>&lt;h2 id="compositional-writing">Compositional Writing&lt;/h2>
&lt;p>以 Zettelkasten（卡片盒筆記法）為核心的寫作方法論。將每段文字視為可重複組合的原子卡片，讓人類讀者與 AI 代理人都能以最小認知負擔找到答案。&lt;/p>
&lt;hr>
&lt;h2 id="core-pillars核心支柱">Core Pillars（核心支柱）&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;strong>Atomization&lt;/strong> 原子化&lt;/td>
 &lt;td>一段文字只承載一個概念，可獨立閱讀與重用&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>Explicit Intent&lt;/strong> 意圖顯性與層級貼合&lt;/td>
 &lt;td>讀者第一眼就看懂「為什麼在這裡、屬哪個抽象層級、該做什麼」&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>&lt;strong>Searchability&lt;/strong> 可查詢性&lt;/td>
 &lt;td>人和 AI 都能用關鍵字 / grep / regex 快速定位&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;hr>
&lt;h2 id="core-principles核心原則速查">Core Principles（核心原則速查）&lt;/h2>
&lt;p>讀者能在本區塊完成快速複習；需要具體應用時，依下方「觸發路由」讀對應情境 reference。&lt;/p>
&lt;h3 id="1-原子化atomization">1. 原子化（Atomization）&lt;/h3>
&lt;p>一張卡一個概念：能獨立理解、可跨情境重用。拆分依據是&lt;strong>認知負擔與情境匹配度&lt;/strong> — 讀者要同時記住的概念數、以及這張卡是否符合讀者當下的情境需求。常見的誤判依據是「行數」（卡太長就拆）、行數只反映表面字數、不反映概念數：一張 200 行的卡可能只講一個概念、一張 30 行的卡可能塞了三個概念。判別問題是「讀者要同時 hold 幾個概念才讀得懂這張卡」、超過 7 個就要拆。&lt;/p>
&lt;p>&lt;strong>拆分判準的核心問題&lt;/strong>：「這張卡聚焦在什麼問題、議題切完整了嗎？」— 判準是 &lt;strong>focus 完整度&lt;/strong>。常見的次級訊號是「卡之間是否衝突」「邊界是否清晰」、兩者都不夠：兩張卡互不衝突、仍可能各切了一半同樣議題；一張卡邊界清晰、仍可能塞了兩個獨立議題。focus 完整度問的是「這張卡有沒有把它聲稱要解決的議題講完」、是 contrast 上面那兩個訊號抓不到的死角。&lt;/p>
&lt;h3 id="2-索引建立indexing">2. 索引建立（Indexing）&lt;/h3>
&lt;p>用 MOC（Map of Content）、tag 層級與反向索引把卡片串成可導航的網。入口文件&lt;strong>只做路由&lt;/strong>、把細節留給目標卡；引用深度&lt;strong>最多一層&lt;/strong>、讓讀者一跳就到答案（避免 A→B→C 的多層跳躍）。&lt;/p>
&lt;p>&lt;strong>引用錨點用語意標題、不用位置編號&lt;/strong>：引用另一個章節 / 階段 / 條列項時寫「見核心問題」、不寫「見 Stage 3」— 編號是結構排列的 derivation、結構重排時引用句字面完好、語意 silent 指向錯的內容（比 broken link 難偵測：連結斷掉會報錯、編號錯位會成功解析到錯的東西）。對應要求是每個結構單位的標題要承載核心意義（「Stage 3：核心問題」、編號只作排序前綴）、引用取語意半邊；發布方凍結的編號（RFC 段號 / 法條）是 fact、可引用。詳見 &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 命名承載語意的引用面延伸。">reference-by-semantic-title-not-number&lt;/a>。&lt;/p>
&lt;p>&lt;strong>語意錨用單一字串、引用他卡用對方的詞彙&lt;/strong>：同一個結構單位的語意名稱只能有一個 canonical 字串（取標題語意半邊）— 同義雙名（標題「決策記錄 + scaffold 建議」、引用「決策收斂階段」）讓 grep 掃 A 漏 B、重排修復退回人腦對應。引用另一張卡並描述它的內容時、寫之前把被引卡重新打開、用它自己的分類詞彙轉述 — 記憶存概念不存 taxonomy、憑印象轉述會把對方明確分開的類別併掉、每條關係宣告要找得到被引卡的支撐句。&lt;/p>
&lt;p>&lt;strong>集合命名用角色、不內嵌數量&lt;/strong>：標題要當穩定錨、就得先是純 fact —「核心七問」「成長六階段」「四大支柱」把成員數烤進名字、數量是成員清單的 derivation、加一問名稱先失真、所有複製過名稱的地方跟著過期。命名只承載角色與層級（核心問題 / 撞牆階段 / 支柱）、數量讓清單自己呈現；外部凍結品牌（SOLID 五原則 / OWASP Top 10）跟概念閾值（兩次門檻）的數字是 fact、可留。詳見 &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 命名檢驗的數量維度。">name-collections-by-role-not-count&lt;/a>。&lt;/p>
&lt;h3 id="3-意圖顯性與層級貼合explicit-intent--layer-alignment">3. 意圖顯性與層級貼合（Explicit Intent &amp;amp; Layer Alignment）&lt;/h3>
&lt;p>&lt;strong>寫作前先標記本文所在抽象層級（實作 / 工具 / 協作 / 認知 / 架構）、論述停在該層&lt;/strong>。素材取自哪個層級、論述就收斂在哪個層級 — 因為跨層提升等於用 X 層的詞彙描述 Y 層的議題、讀者拿到規則但對不到自己當下的情境。要把實作層素材抽象到認知層、先補對應抽象層的支撐文件（讓論述有對應層的詞彙跟 case 可引用）、再做跨層提升。&lt;/p>
&lt;p>寫「為什麼」和「要達成什麼」、把「程式碼在做什麼」留給程式碼自身（程式碼讀一次就知道做什麼、寫進註解只是冗餘）。主詞與動詞直接、段落開頭即表達意圖。TODO / placeholder 留給 inline 註解、文件本體只放當前契約 — 因為文件常被當成「契約 SSoT」引用、混入未完成事項會讓讀者誤判契約範圍。同一篇文字貼合它在系統裡的抽象層級、把下層實作藏在介面後面。&lt;/p>
&lt;p>&lt;strong>機會成本語氣優先&lt;/strong>：程式設計大多是多目標取捨、討論的是「在什麼情境下哪個選項較划算」。把絕對二元語氣（「正確概念是 X / 替代方案不足 / 應該這樣做」）翻成情境化敘述：「比較好的做法是 A、因為 [情境] / B 在 [其他情境] 合理 / D 的成本特別高、只在 [極端情境] 才划算」。機會成本教讀者「思考方式」（能套用到新情境）、絕對主義教讀者「規則」（壓力下會忘）— 所以前者是預設語氣。例外保留給物理 / 法律 / 數學事實（安全性、數據完整性、合規、雜湊必有碰撞）。絕對二元語氣有兩種形式：&lt;strong>命令式&lt;/strong>（「應該做 X」）讀者聽得出是主張、會審；&lt;strong>必然式&lt;/strong>（「X 天生就是 Y / 本質就是 / 必然」）偽裝成事實陳述、更隱形 — 把設計選擇講成自然法則時尤其要 catch、還原成「在選了某前提後 X 才以此形式成立」。判別線：這個必然有沒有上游設計選擇當前提（有=條件性、要講前提；無=真必然、可斷言）。詳見 &lt;a href="https://tarrragon.github.io/blog/report/teaching-register-states-not-addresses-reader/" data-link-title="教材用中性陳述、不對讀者喊話" data-link-desc="教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。">teaching-prose-neutral-register&lt;/a>。&lt;/p></description><content:encoded><![CDATA[<h2 id="compositional-writing">Compositional Writing</h2>
<p>以 Zettelkasten（卡片盒筆記法）為核心的寫作方法論。將每段文字視為可重複組合的原子卡片，讓人類讀者與 AI 代理人都能以最小認知負擔找到答案。</p>
<hr>
<h2 id="core-pillars核心支柱">Core Pillars（核心支柱）</h2>
<table>
  <thead>
      <tr>
          <th>支柱</th>
          <th>意義</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><strong>Atomization</strong> 原子化</td>
          <td>一段文字只承載一個概念，可獨立閱讀與重用</td>
      </tr>
      <tr>
          <td><strong>Explicit Intent</strong> 意圖顯性與層級貼合</td>
          <td>讀者第一眼就看懂「為什麼在這裡、屬哪個抽象層級、該做什麼」</td>
      </tr>
      <tr>
          <td><strong>Searchability</strong> 可查詢性</td>
          <td>人和 AI 都能用關鍵字 / grep / regex 快速定位</td>
      </tr>
  </tbody>
</table>
<hr>
<h2 id="core-principles核心原則速查">Core Principles（核心原則速查）</h2>
<p>讀者能在本區塊完成快速複習；需要具體應用時，依下方「觸發路由」讀對應情境 reference。</p>
<h3 id="1-原子化atomization">1. 原子化（Atomization）</h3>
<p>一張卡一個概念：能獨立理解、可跨情境重用。拆分依據是<strong>認知負擔與情境匹配度</strong> — 讀者要同時記住的概念數、以及這張卡是否符合讀者當下的情境需求。常見的誤判依據是「行數」（卡太長就拆）、行數只反映表面字數、不反映概念數：一張 200 行的卡可能只講一個概念、一張 30 行的卡可能塞了三個概念。判別問題是「讀者要同時 hold 幾個概念才讀得懂這張卡」、超過 7 個就要拆。</p>
<p><strong>拆分判準的核心問題</strong>：「這張卡聚焦在什麼問題、議題切完整了嗎？」— 判準是 <strong>focus 完整度</strong>。常見的次級訊號是「卡之間是否衝突」「邊界是否清晰」、兩者都不夠：兩張卡互不衝突、仍可能各切了一半同樣議題；一張卡邊界清晰、仍可能塞了兩個獨立議題。focus 完整度問的是「這張卡有沒有把它聲稱要解決的議題講完」、是 contrast 上面那兩個訊號抓不到的死角。</p>
<h3 id="2-索引建立indexing">2. 索引建立（Indexing）</h3>
<p>用 MOC（Map of Content）、tag 層級與反向索引把卡片串成可導航的網。入口文件<strong>只做路由</strong>、把細節留給目標卡；引用深度<strong>最多一層</strong>、讓讀者一跳就到答案（避免 A→B→C 的多層跳躍）。</p>
<p><strong>引用錨點用語意標題、不用位置編號</strong>：引用另一個章節 / 階段 / 條列項時寫「見核心問題」、不寫「見 Stage 3」— 編號是結構排列的 derivation、結構重排時引用句字面完好、語意 silent 指向錯的內容（比 broken link 難偵測：連結斷掉會報錯、編號錯位會成功解析到錯的東西）。對應要求是每個結構單位的標題要承載核心意義（「Stage 3：核心問題」、編號只作排序前綴）、引用取語意半邊；發布方凍結的編號（RFC 段號 / 法條）是 fact、可引用。詳見 <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 命名承載語意的引用面延伸。">reference-by-semantic-title-not-number</a>。</p>
<p><strong>語意錨用單一字串、引用他卡用對方的詞彙</strong>：同一個結構單位的語意名稱只能有一個 canonical 字串（取標題語意半邊）— 同義雙名（標題「決策記錄 + scaffold 建議」、引用「決策收斂階段」）讓 grep 掃 A 漏 B、重排修復退回人腦對應。引用另一張卡並描述它的內容時、寫之前把被引卡重新打開、用它自己的分類詞彙轉述 — 記憶存概念不存 taxonomy、憑印象轉述會把對方明確分開的類別併掉、每條關係宣告要找得到被引卡的支撐句。</p>
<p><strong>集合命名用角色、不內嵌數量</strong>：標題要當穩定錨、就得先是純 fact —「核心七問」「成長六階段」「四大支柱」把成員數烤進名字、數量是成員清單的 derivation、加一問名稱先失真、所有複製過名稱的地方跟著過期。命名只承載角色與層級（核心問題 / 撞牆階段 / 支柱）、數量讓清單自己呈現；外部凍結品牌（SOLID 五原則 / OWASP Top 10）跟概念閾值（兩次門檻）的數字是 fact、可留。詳見 <a href="/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">name-collections-by-role-not-count</a>。</p>
<h3 id="3-意圖顯性與層級貼合explicit-intent--layer-alignment">3. 意圖顯性與層級貼合（Explicit Intent &amp; Layer Alignment）</h3>
<p><strong>寫作前先標記本文所在抽象層級（實作 / 工具 / 協作 / 認知 / 架構）、論述停在該層</strong>。素材取自哪個層級、論述就收斂在哪個層級 — 因為跨層提升等於用 X 層的詞彙描述 Y 層的議題、讀者拿到規則但對不到自己當下的情境。要把實作層素材抽象到認知層、先補對應抽象層的支撐文件（讓論述有對應層的詞彙跟 case 可引用）、再做跨層提升。</p>
<p>寫「為什麼」和「要達成什麼」、把「程式碼在做什麼」留給程式碼自身（程式碼讀一次就知道做什麼、寫進註解只是冗餘）。主詞與動詞直接、段落開頭即表達意圖。TODO / placeholder 留給 inline 註解、文件本體只放當前契約 — 因為文件常被當成「契約 SSoT」引用、混入未完成事項會讓讀者誤判契約範圍。同一篇文字貼合它在系統裡的抽象層級、把下層實作藏在介面後面。</p>
<p><strong>機會成本語氣優先</strong>：程式設計大多是多目標取捨、討論的是「在什麼情境下哪個選項較划算」。把絕對二元語氣（「正確概念是 X / 替代方案不足 / 應該這樣做」）翻成情境化敘述：「比較好的做法是 A、因為 [情境] / B 在 [其他情境] 合理 / D 的成本特別高、只在 [極端情境] 才划算」。機會成本教讀者「思考方式」（能套用到新情境）、絕對主義教讀者「規則」（壓力下會忘）— 所以前者是預設語氣。例外保留給物理 / 法律 / 數學事實（安全性、數據完整性、合規、雜湊必有碰撞）。絕對二元語氣有兩種形式：<strong>命令式</strong>（「應該做 X」）讀者聽得出是主張、會審；<strong>必然式</strong>（「X 天生就是 Y / 本質就是 / 必然」）偽裝成事實陳述、更隱形 — 把設計選擇講成自然法則時尤其要 catch、還原成「在選了某前提後 X 才以此形式成立」。判別線：這個必然有沒有上游設計選擇當前提（有=條件性、要講前提；無=真必然、可斷言）。詳見 <a href="/blog/report/teaching-register-states-not-addresses-reader/" data-link-title="教材用中性陳述、不對讀者喊話" data-link-desc="教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。">teaching-prose-neutral-register</a>。</p>
<p><strong>選項數由議題本身的合理選項數決定</strong>：機會成本的精神是「教思考方式」 — 議題有幾個合理選項就寫幾個（2 個寫 A/B、3 個寫 A/B/C、4 個寫 A/B/C/D）。強湊到固定數量會把「教思考」退化成「填格式」、生出「實務上幾乎不存在」的低品質假反模式。真正的反模式直接標「D：反模式 — 違反 X 原則」、給讀者明確的「為什麼這條路該避開」、保持誠實。</p>
<p><strong>讀者定位聲明（生成端前置步驟）</strong>：每個教學模組在第一篇文章生成前，顯式聲明讀者定位——一段話描述目標讀者的背景、已有能力、缺的經驗。這份聲明是後續所有生成和 review 的可檢查基準。缺少顯式聲明時，LLM 預設用「教外行人」的姿態寫教學內容，這個預設不被 review 挑戰（reviewer 共享同一個預設），導致宣導語氣通過多輪審查。per <a href="/blog/report/review-lacks-outside-in-reader-frames/" data-link-title="多輪審查缺 outside-in 讀者 frame：六個系統性盲點" data-link-desc="review 框架的所有 frame 從已寫的內容出發（inside-out），缺從讀者完整需求出發的 frame（outside-in）。六個盲點全部由使用者而非 reviewer 發現：宣導語氣、管理層資訊缺失、接手情境遺漏、工具指引缺失、深度不拆分、讀者定位未預設。">outside-in reader frames report</a></p>
<p><strong>讀者定位：缺經驗的專業人士、不是外行人</strong>：技術教材的讀者是在特定領域缺乏經驗的專業人士，不是完全不懂的外行人。寫法是補足經驗缺口（直接描述情境與操作需求），不是從零科普（故事線導入、比喻堆疊、宣導語氣）。宣導式語氣（「你可能沒注意到」「把 X 想成 Y」「跑得好好的」）預設讀者無能、降低教材可信度。詳見 <a href="/blog/report/audience-is-professional-not-layperson/" data-link-title="讀者是缺經驗的專業人士、不是外行人" data-link-desc="技術教材的讀者定位應該是「在這個領域缺乏經驗的專業人士」，不是「完全不懂的外行人」。寫法是補足經驗缺口、不是從零科普。宣導式語氣（跑得好好的、你可能不知道）預設讀者無能，實際上會降低教材的可信度。">audience-is-professional-not-layperson</a>。</p>
<p><strong>跨專業溝通用情境遞進、不用比喻堆疊</strong>：向非本領域的專業人士（管理層、決策者）解釋技術議題時，減少術語並從簡單情境遞進到複雜情境。比喻傳遞形狀但不傳遞嚴重性、在細節處崩解、且隱含「對方聽不懂」的預設。用決策者熟悉的維度（影響範圍、恢復時間、成本量級）表達。詳見 <a href="/blog/report/cross-expertise-communication-scenario-not-analogy/" data-link-title="跨專業溝通用情境遞進、不用比喻堆疊" data-link-desc="向非本領域的專業人士解釋技術議題時，減少術語並從簡單情境遞進到複雜情境，比堆疊比喻有效。比喻傳遞形狀但不傳遞嚴重性；情境遞進讓對方用自己熟悉的決策框架（成本、風險、時間）消化資訊。">cross-expertise-scenario-not-analogy</a>。</p>
<p><strong>技術教材內嵌管理層可彙報的資訊</strong>：技術段落旁嵌入成本量級、時程估算、進度指標與決策簽核點（各 1-2 句），讓讀者學完技術做法的同時拿到向上彙報的素材。成本用量級不用精確數、時程用範圍不用單點、進度用可查詢指標。詳見 <a href="/blog/report/technical-content-needs-management-reportable-info/" data-link-title="技術教材要內嵌管理層可彙報的資訊" data-link-desc="技術文章的讀者不只要知道怎麼做，還要能向上彙報為什麼做、花多久、花多少。成本量級、時程估算、進度指標與需簽核的決策點應該嵌在技術段落旁邊，而非集中在另一篇溝通指南裡。">management-reportable-info-in-technical-content</a>。</p>
<p><strong>知識卡建卡判準用「最不熟悉的讀者」</strong>：知識卡的建卡判準是「目標讀者群裡最不熟悉的那端能不能理解這個術語」，不是「作者覺得夠不夠常見」。常識是相對於背景的——.htaccess 對 PHP 工程師是常識、對 Node.js 工程師完全陌生。跨背景讀者群的教材裡，幾乎所有領域特定術語都需要建卡。建卡的邊際成本低（40-50 行）、讀者缺卡的代價高（離開教材去 Google、可能找到不一致的解釋）。per <a href="/blog/report/common-knowledge-is-relative-to-reader-background/" data-link-title="常識是相對於讀者背景的、不是作者背景的" data-link-desc="知識卡的建卡判準不能用「這個夠不夠常見」——對 PHP 工程師是常識的 .htaccess，對 Node.js 工程師完全陌生；對後端工程師是常識的 DNS TTL，對前端工程師需要解釋。建卡看的是目標讀者群裡最不熟悉的那個人能不能理解，不是作者自己覺得夠不夠普遍。">常識是相對於讀者背景的</a>。</p>
<p><strong>操作步驟帶環境專屬工具路徑</strong>：操作型文章的每一步至少帶一條工具路徑（用什麼軟體、輸入什麼指令）。同一個動作在不同環境（container / VM / 共享主機）的工具路徑可能完全不同——「拍下現況」在 container 是 <code>docker commit</code>、在 VM 是 AMI 快照、在共享主機是 FTP mirror + phpinfo。文章涵蓋多種環境時、每一步要按環境分列工具、或標明適用環境。自測問題：「讀者坐在電腦前，下一個動作是打開什麼軟體？」答不出來就是缺口。per <a href="/blog/report/operational-how-needs-environment-specific-tooling/" data-link-title="操作指引的「怎麼做」要帶環境專屬的工具路徑" data-link-desc="操作型教材說「拍下現況」「匯出資料庫」「建立備份」時，不同執行環境（container / VM / 共享主機）的工具路徑完全不同。只寫動作不寫工具，讀者知道該做什麼但做不到。這個缺口在 fact-check 和 steelman 審查裡結構性隱形，因為動作本身在邏輯層是正確的。">操作指引要帶環境專屬工具路徑</a>。</p>
<p><strong>Case 引用段落的三段式結構</strong>：三段式是案例引用段落的順序紀律 — 把「概念 → 案例 → 操作」三層分開承擔（段首給概念定義、case 引用居中、通用工程知識展開）、讓段落結構跟讀者學習新概念的認知順序對齊。LLM 從 case 反推內容容易把 case 揭露當概念出發點、實證觀察 11/12 段都犯這個錯。詳見 <a href="/blog/report/case-citation-three-part-structure/" data-link-title="案例引用三段式段落結構：概念定義 → case 引用 → 通用展開" data-link-desc="Case 引用段落要走三段式結構：(1) 段首概念定義句先寫『該概念是什麼、承擔什麼責任』、(2) 第二位置 case 引用、(3) 通用工程知識展開；段首被 case 引用取代是 06 模組最大宗 systemic 違規（11/12 段都犯）；本卡跟 #115（引用深度）/ #116（內部分層）/ #117（跨 case 合成）正交、處理段落結構順序">case-citation-three-part-structure</a>。</p>
<p><strong>原子筆記要有向上的議題入口</strong>：承載知識的原子筆記（Zettelkasten 卡 / glossary / 術語條目）不是字典條目 — 字典答「這個詞是什麼」、承載知識答「你在討論什麼、撞到什麼問題、才需要這知識」。撰寫者有預設情境讀者沒有、所以每張卡（或其上層）要從情境進入而非劈頭給定義：建議題 hub（以讀者遇到的問題為題）討論再分流到原子卡、卡頂回指議題、讓搜尋直接落地者也有回路。沒這層卡淪字典、讀者沒有觸發點、不知何時用。詳見 <a href="/blog/report/atomic-note-needs-situational-entry/" data-link-title="原子筆記要有向上的議題入口：讀者要知道為何讀這張、何時會撞到" data-link-desc="承載知識的原子筆記不是字典條目。每張卡（或其上層）要回答「你在討論什麼議題、撞到什麼問題，才需要這個知識」——從情境進入，而非從定義進入。做法是建『議題 hub』上層筆記討論問題、再分流到術語卡，術語卡頂部回指議題。">atomic-note-needs-situational-entry</a>。</p>
<h3 id="4-可查詢性searchability">4. 可查詢性（Searchability）</h3>
<p>關鍵字前置、使用可 grep 的分隔符（<code>:</code> <code>|</code> <code>→</code> <code>==</code>）、欄位名稱使用 regex 友善格式。命名讓 AI 能以單次 grep 命中，不需要語意推理。</p>
<h3 id="5-欄位設計field-design">5. 欄位設計（Field Design）</h3>
<p>同一份文件的不同欄位，從不同角度觀察同一件事，不重複撰寫。<code>what</code> 描述動作、<code>why</code> 陳述動機、<code>acceptance</code> 定義可驗證條件；混淆欄位會讓讀者在多處讀到相同內容。</p>
<h3 id="6-多輪-re-read-passmulti-pass-review">6. 多輪 Re-read Pass（Multi-pass Review）</h3>
<p>完稿即進入 review 階段。一次寫對全部維度違反 working memory、實際結果是「每維度都做一半」。設計 N 輪 re-read、每輪用不同 frame：</p>
<table>
  <thead>
      <tr>
          <th>輪</th>
          <th>Frame</th>
          <th>抓什麼</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>1</td>
          <td>生成</td>
          <td>idea → 字、預期會有錯</td>
      </tr>
      <tr>
          <td>2</td>
          <td>對意圖（<a href="/blog/report/ease-of-writing-vs-intent-alignment/" data-link-title="寫作便利度跟意圖對齊反相關" data-link-desc="寫程式時最容易寫出的版本、通常是離意圖最遠的版本。便利度建立在「現有上下文 / 已 materialize 資料 / 已存在 API」上、而意圖對齊需要找到正確的層、處理上游、跨抽象層 — 兩者方向相反。識別這個反相關 = 識別自己掉進「容易寫的陷阱」。">ease-of-writing-vs-intent-alignment</a>）</td>
          <td>正文、title、description、MOC hook 都跟原意對齊</td>
      </tr>
      <tr>
          <td>3</td>
          <td>機會成本語氣</td>
          <td>全 surface 的絕對詞翻成 trade-off</td>
      </tr>
      <tr>
          <td>4</td>
          <td>Grep-ability / 命名 / 術語</td>
          <td>title、slug、link label、段首關鍵字可單次 grep 命中；術語保留原文錨點與完整名詞頭</td>
      </tr>
      <tr>
          <td>5</td>
          <td>反例 / 邊界</td>
          <td>「何時不適用」段、反模式列表</td>
      </tr>
  </tbody>
</table>
<p>Surface enumeration 是 multi-pass 的固定前置步驟。寫作產物包含 body surface 與 metadata / navigation surface：<code>title</code>、<code>description</code>、<code>tags</code>、heading、link label、MOC / index entry、slug / filename。每輪 frame 都掃這份 surface 清單，讓正文與讀者入口共用同一個概念錨點。description / hook 對規則做壓縮時、<strong>可以丟細節、不可以改模態</strong> — 把本體的「條件允許（可延後但要記錄）」壓成「絕對禁止（不可跳過）」、讀者依摘要行動就會偏離本體；摘要讀起來比本體「更有力、更乾脆」就是失真訊號、模態詞跟主詞動詞同級、最後砍。實測一批七份文檔有四份的 description 出現模態漂移 — 這個檢查每批都要跑。</p>
<p><strong>核心</strong>：「再仔細一次」≠ multi-pass — 同 frame 重看 catch 不到新問題。每輪換 frame、才能 catch 不同層。各 reference（writing-articles / writing-code-comments / writing-documents / writing-prompts）依 output 類型有特化的輪次組合。</p>
<p>Naming 是這條原則最容易跳的子場景 — 第一版命名幾乎不對、四輪 review（第一版 / grep / cross-call-site / impl 洩漏）才收斂、見 <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 在「命名」場景的特化。">naming-as-iterated-artifact</a> 跟 writing-code-comments 的 naming review 段。術語是 naming 的高歧義子場景：翻譯術語第一次出現保留原文錨點，中文壓縮術語保留完整名詞頭，中文名詞頭要保留來源中的概念角色，見 <a href="/blog/report/terminology-keeps-original-anchor/" data-link-title="術語翻譯要保留原文錨點" data-link-desc="翻譯術語時、中文名稱負責降低閱讀門檻，原文名稱負責鎖定概念邊界。只留中文會把 reader 帶進中文詞的日常歧義，只留英文會提高閱讀成本；中文後接英文括號是技術文章的穩定折衷。">terminology-keeps-original-anchor</a>、<a href="/blog/report/compressed-chinese-terms-need-head-noun/" data-link-title="中文壓縮術語要保留完整名詞頭" data-link-desc="中文技術寫作可以壓縮長詞，但不能省到只剩形容詞或單字修飾。像「多步驟 perplexity 盲」這類詞少了完整名詞頭，讀者無法判斷是在說盲點、盲區、盲測或失明比喻。壓縮後仍要能獨立回答「這是什麼」。">compressed-chinese-terms-need-head-noun</a> 與 <a href="/blog/report/translation-must-preserve-concept-role/" data-link-title="術語翻譯要保留概念角色" data-link-desc="術語翻譯不能只追求中文好讀，還要保留原詞在論證中的概念角色。Steelman 若翻成「最強版本測試」，reader 會以為它是一個檢查動作；但在決策語境裡，它更核心的責任是把反方論點重建成最強版本。">translation-must-preserve-concept-role</a>。</p>
<p><strong>高 stakes 內容追加輪 E（epistemic rigor、conditional opt-in）</strong>：reader 照做後錯誤不可逆的內容（資安 / concurrency 正確性 / distributed consistency / financial / medical）在 5 輪基本 frame 之外、追加 stakes 軸的 epistemic rigor pass——比照學術 peer review 跑 claim / evidence / method / threats / citation 五個 sub-check、加上 audit recommendation tier（accept / minor / major / withdraw）。一般內容 5 輪夠、不跑輪 E；高 stakes 內容兩軸都跑。詳見 <code>references/auditing-articles.md</code> 跟 <code>/report/writing-multi-pass-review/</code> 的「stakes-conditional 追加輪」段。</p>
<p><strong>Production 教學文章追加輪 8-10（字句層 catch、跑 N 輪仍漏時觸發）</strong>：跑了 5 輪基本 frame 仍系統性漏 catch 字句層問題（口語修辭 / 廢話前綴 / 地區漂移 / 依賴 code / <strong>裝飾符號 emoji</strong> / 對讀者喊話 / 自評誇飾 / 必然性框架 / 恐嚇式語氣 / 歸因語氣）時、追加三個換軸機制——輪 8 keyword bank（換工具、含 emoji / 裝飾 unicode 掃描）、輪 9 reader simulation（換視角、四 lens：自包含性 + register/stance + meta 殘留 + AI 歸因過度）、輪 10 self-criticism（換層次、審視 framework 本身覆蓋度）。短文 / 即時 note 不需要、production 教學文章在跑 5 輪後仍漏同類問題時 opt-in。<strong>keyword bank 命中是候選、不是判決</strong>——grep 命中後仍要一個語意判定步驟（這個命中是建立概念的違規、還是合規的反例對照 / hook），reviewer 容易把違規合理化放行；偵測（bank）跟判定（語意）是兩個認知步驟。<strong>register/stance 類（喊話 / 誇飾 / 必然）無穩定關鍵詞、keyword bank 抓不到、輪 9 reader-sim 是主 keyword bank 是輔、且最依賴 external cold-read</strong>。漏抓後補機制前先分 <strong>design gap</strong>（框架缺 frame、改框架）vs <strong>execution gap</strong>（框架有 frame 但只跑了臨時子集、改執行不是改框架）——「加 keyword」對 execution gap 跟無關鍵詞的類都無效。詳見 <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 輪。">multi-pass-review-frame-granularity</a>、<a href="/blog/report/visual-tool-error-layer-alignment/" data-link-title="視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題" data-link-desc="修視覺問題的工具（CSS、emoji、顏色、排版）只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 &#43; false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序：邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。">decorative-symbols-keyword-bank</a>、<a href="/blog/report/teaching-register-states-not-addresses-reader/" data-link-title="教材用中性陳述、不對讀者喊話" data-link-desc="教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。">teaching-prose-neutral-register</a> 跟 <code>references/writing-articles.md</code> 輪 8-10 段。</p>
<p><strong>批量 sibling 寫作的生成端輪替</strong>：一次寫多份同類文檔時、cadence 同質化會在六個層發生（title 形式 / 開場句式 / 章節標題 / 敘事骨架 / 條目形態 / 跨檔引用句）、單份 review 全部抓不到、且 review 端抓過的同骨會在下一批復發 — 同類 finding 第二次出現、就把規則升到生成端：寫之前排好開場 frame 輪替（規則先行 / 後果先行 / 動作先行 / 反差先行）、條目形態輪替、敘事視角輪替、引用句去重。詳見 <a href="/blog/report/cadence-homogenization-in-batch-writing/" data-link-title="Cadence 同質化是模板的隱形維度" data-link-desc="規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位">cadence-homogenization</a>。</p>
<p><strong>Instance 軸：跨 reviewer instance 隔離</strong>：Instance 軸是 multi-pass review 的另一條擴展軸 — N 個獨立 reviewer instance 各自獨立 context、各自跑 background、解「單一 reviewer 同時看多維度容易維度盲點 + context 污染」的問題。Instance 指獨立 reviewer 程式實體（如 agent tool spawn 出的 subagent）、跟同一 reviewer 換輪次 frame（frame 軸）正交可疊加。適用 production 教學文章 / 高 stakes 內容 / 跨章節教學模組這類維度複雜度高的審查場景。詳見 <a href="/blog/report/agent-team-context-isolation/" data-link-title="Agent team context 隔離設計：用不同 instance 換 frame、平行 background 保護主 context" data-link-desc="Multi-pass review 跨輪 frame（#83）跟跨 reviewer instance 隔離（本卡）是兩個 axis：#83 是同一 reviewer 換輪次 frame、本卡是不同 reviewer instance 各自獨立 background 跑；context 隔離設計讓主 context 只接精煉摘要、節省 ~80% token、跟同 reviewer 多輪 catch 同類錯（#114）形成互補解法">agent-team-context-isolation</a>。</p>
<p>詳見 <a href="/blog/report/writing-multi-pass-review/" data-link-title="Writing 的 multi-pass review：N 輪 review、每輪換 frame" data-link-desc="寫文章 / 註解 / 文件 / prompt 的「寫」不是單次動作 — 是 N 輪 review。第 1 輪生成、第 2 輪對意圖（#67）、第 3 輪檢查機會成本語氣、第 4 輪 grep-ability、第 5 輪反例 / 邊界。每輪不同 frame、單輪寫不出全部維度。本卡是 #82 在「寫」這個 output 動作的具體實例。">Writing 的 multi-pass review</a>、<a href="/blog/report/methodology-multi-pass-embedding/" data-link-title="Methodology 的 multi-pass 該升級為 pillar 層：核心結構才會被執行" data-link-desc="任何「教做事方法」的 methodology / SKILL / playbook、應該把 multi-pass refinement 放在 pillar / 核心原則層、不是放在末尾「附帶提醒」段。Pillar 層 = 結構性必跑、appendix 層 = 看心情選擇 = 永遠不跑。本卡是 #82 行為驗證 &#43; #72 結構性對策在「方法論設計本身」這一層的展現。">Methodology 的 multi-pass 該 embed 在 pillar</a>、<a href="/blog/report/metadata-surface-in-writing-review/" data-link-title="Metadata surface 要納入寫作 review 範圍" data-link-desc="寫作 review 的 surface 包含正文與 metadata surface：title、description、frontmatter、heading、link label、MOC 索引條。正文通過 positive wording 或 multi-pass review 只代表 body surface 收斂；讀者入口與索引入口也要跑同一套 frame，才能讓文章在第一眼、搜尋與跨篇路由上維持同一個概念錨點。">Metadata surface 要納入寫作 review 範圍</a>、<a href="/blog/report/false-sense-of-security-as-primary-failure/" data-link-title="False sense of security 是資安寫作的主要失敗模式" data-link-desc="資安教學內容的失敗模式不是「讀者學不到」、是「讀者以為學到了並照做、實際還有破口」。讀者實作後沒警覺 = 後續驗證、修補、事件偵測都不會被觸發、破口在生產系統長期 silent 累積。識別 false sense of security 句子的判準：讀者讀完後會說「我做了 X 防護所以安全」、卻無法回答「對什麼 threat 安全 / 什麼 deployment 條件 / 什麼前提失效」。">False sense of security 是高 stakes 寫作的主要失敗模式</a>、<a href="/blog/report/security-teaching-rigor-asymmetry/" data-link-title="資安教學的審查標準要對應風險不對稱" data-link-desc="一般教學寫不清楚、讀者學不到、損失停在學習端；資安教學寫不清楚、讀者照做後在系統上產生破口、損失轉嫁到生產端。兩者風險不對稱、審查嚴格度應該對應下游實作代價、不是讀者讀懂程度。資安內容的 audit bar 預設要拉到「讀者會 implement」、不是「讀者會 read」、否則所有寫作便利選擇（含糊敘述、省略邊界、引用而不驗證版本）都會 silent 變成實作端破口。">Risk-asymmetric audit standard</a>、<a href="/blog/report/colloquial-rhetoric-erodes-technical-precision/" data-link-title="口語化修辭在判斷工具型段落會稀釋技術精度" data-link-desc="技術文章的「判斷工具型段落」（讀者用來判斷自己 case 的論述）用「一輩子」「碰巧能用」「立刻撞牆」「沒事」這類口語修辭、會稀釋精度。修法是把口語修辭翻譯回技術屬性語言。但 hook / 引言 / narrative 段落用口語仍然合理——這是情境化的取捨、不是精度永遠優於可讀性。">colloquial-rhetoric-erodes-technical-precision</a>、<a href="/blog/report/prose-self-contained-without-code-reference/" data-link-title="商業邏輯論述要 self-contained：不依賴 code 才能被理解" data-link-desc="技術文章在「不放 code 的段落」仍然要 self-contained——商業邏輯論述不能預設讀者已經看過 code、用「那個 payload 第二段」「剛才的變數」這類 reference 等於把理解門檻轉嫁給讀者去翻 code。修法是把 reference 翻譯成「用名詞 / 角色 / 條件描述」的 self-contained 句子、即使讀者跳過所有 code block 也能理解論述。">prose-self-contained-without-code-reference</a>、<a href="/blog/report/regional-terminology-alignment/" data-link-title="地區用語對齊：寫作前先確定讀者的中文語料" data-link-desc="繁中 vs 簡中的用詞差異不只是字形（屏 / 螢幕、視頻 / 影片）、更是技術術語跟業務情境的精度差。寫作前要先確定讀者的中文語料、避免用對方語料中不存在或意思偏移的詞。常見漂移：硬體（屏 / 螢幕）、檔案系統（文件 / 檔案）、概念詞（默認 / 預設）、修辭詞（質量 / 品質）、混雜情境的英文中文比例。">regional-terminology-alignment</a>、<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 輪。">multi-pass-review-frame-granularity</a>、<a href="/blog/report/design-flaw-by-current-axes-not-hindsight/" data-link-title="設計檢討用當下三軸論證、不依賴 hindsight" data-link-desc="本卡提倡用「當下成本對稱條件下選了限制更高的選項」當設計缺陷的判定方式、避免 hindsight 論述把需求演化誤判成設計缺陷。當下三軸論證（成本對稱性 / 可逆性 / 領域先驗）讓判斷不依賴結局發生、且歸因偏向工具預設與制度而非個人預見性。">design-flaw-by-current-axes-not-hindsight</a>、<a href="/blog/report/agent-team-context-isolation/" data-link-title="Agent team context 隔離設計：用不同 instance 換 frame、平行 background 保護主 context" data-link-desc="Multi-pass review 跨輪 frame（#83）跟跨 reviewer instance 隔離（本卡）是兩個 axis：#83 是同一 reviewer 換輪次 frame、本卡是不同 reviewer instance 各自獨立 background 跑；context 隔離設計讓主 context 只接精煉摘要、節省 ~80% token、跟同 reviewer 多輪 catch 同類錯（#114）形成互補解法">agent-team-context-isolation</a>、<a href="/blog/report/visual-tool-error-layer-alignment/" data-link-title="視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題" data-link-desc="修視覺問題的工具（CSS、emoji、顏色、排版）只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 &#43; false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序：邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。">decorative-symbols-keyword-bank</a>、<a href="/blog/report/teaching-register-states-not-addresses-reader/" data-link-title="教材用中性陳述、不對讀者喊話" data-link-desc="教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。">teaching-prose-neutral-register</a>。</p>
<hr>
<h2 id="when-to-consult-this-skill觸發路由">When to Consult This Skill（觸發路由）</h2>
<table>
  <thead>
      <tr>
          <th>觸發情境</th>
          <th>讀哪份 reference</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>要寫或改一段程式碼註解 / doc comment</td>
          <td><code>references/writing-code-comments.md</code></td>
      </tr>
      <tr>
          <td>要起草 / 改寫一份文件（worklog、spec、README）</td>
          <td><code>references/writing-documents.md</code></td>
      </tr>
      <tr>
          <td>要設計 log / 錯誤訊息 / 結構化輸出</td>
          <td><code>references/writing-logs.md</code></td>
      </tr>
      <tr>
          <td>要撰寫給 AI 的 prompt / instruction / Agent 派發 / Ticket Context Bundle</td>
          <td><code>references/writing-prompts.md</code>（為 <code>.claude/rules/core/ai-communication-rules.md</code> 的詳細版庫，portability-allow）</td>
      </tr>
      <tr>
          <td>要撰寫完整長篇技術文章（blog post / post-mortem / 架構決策 / 除錯復盤 / 技術評估）</td>
          <td><code>references/writing-articles.md</code></td>
      </tr>
      <tr>
          <td>要把外部分析文章 / 產業評論 / 投資人備忘錄 / 高密度研究材料轉成教學型分析文章，或把 AI 改寫稿從摘要升級成可遷移框架</td>
          <td><code>references/source-to-teaching-analysis.md</code></td>
      </tr>
      <tr>
          <td>要翻譯 / 轉譯文章、把英文材料改寫成中文、檢查術語誤譯或中文譯名放回句子後是否成立</td>
          <td><code>references/translation-review.md</code></td>
      </tr>
      <tr>
          <td>要管理多篇相關文章的結構（系列、文集、知識庫、素材庫比例、MOC、跨篇引用、何時抽抽象層 / Pattern 卡片）</td>
          <td><code>references/managing-article-collections.md</code></td>
      </tr>
      <tr>
          <td>要對既有高 stakes 內容（資安 / concurrency / distributed / financial / medical）做 reviewer-style audit、找 false sense of security / 對位失效 / context 缺 / citation 過時</td>
          <td><code>references/auditing-articles.md</code></td>
      </tr>
      <tr>
          <td>要設計 ticket 欄位 / schema frontmatter / 表單欄位</td>
          <td><code>references/designing-fields.md</code></td>
      </tr>
      <tr>
          <td>想驗證寫作品質（認知負擔、獨立理解率）</td>
          <td><code>references/meta-metrics.md</code></td>
      </tr>
      <tr>
          <td>要新增或修改一份 Skill reference（撰寫品質規範、結構標準）</td>
          <td><code>references/reference-authoring-standards.md</code></td>
      </tr>
      <tr>
          <td>要驗收 Skill 發布品質（語意層驗收、Phase 2 dry-run）</td>
          <td><code>references/dry-run-guide.md</code></td>
      </tr>
  </tbody>
</table>
<p>每份 reference 自包含：以該情境為核心，把核心原則翻譯成可直接套用的檢查項與範例。閱讀任一 reference 不需要回來看其他 reference。</p>
<hr>
<h2 id="success-criteriam1-m2-認知負擔類">Success Criteria（M1-M2 認知負擔類）</h2>
<table>
  <thead>
      <tr>
          <th>Metric</th>
          <th>定義</th>
          <th>目標</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><strong>M1 — 找到答案路徑</strong></td>
          <td>讀者從 SKILL.md 出發，需要開啟幾個檔案才能解決問題</td>
          <td>≤ 2</td>
      </tr>
      <tr>
          <td><strong>M2 — reference 獨立理解率</strong></td>
          <td>隨機挑一份 reference，不讀其他 reference 能否獨立套用</td>
          <td>100%</td>
      </tr>
  </tbody>
</table>
<p>詳細量測方式與自評表見 <code>references/meta-metrics.md</code>。M3-M5（token 類）保留未定，待實際範例累積後補足。</p>
<hr>
<h2 id="跟特化寫作流程的分工">跟特化寫作流程的分工</h2>
<p>本 skill 是 <em>單篇</em> 寫作的基礎方法、覆蓋 articles / comments / logs / prompts / fields 等 surface。當寫作對象是 <em>跨多章節的教學模組</em>（5+ 章、有案例庫支撐、跨章引用密集）、屬特化情境、有專屬的 <em>跨章節生產流程</em>：案例庫 audit 抽 findings、SSoT 對應規劃、agent team 平行 review、跨檔修正循環、跨章 polish pass。</p>
<p>兩類流程的分工：</p>
<table>
  <thead>
      <tr>
          <th>流程</th>
          <th>適用</th>
          <th>核心紀律</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><strong>本 skill（compositional-writing）</strong></td>
          <td>單篇文字（articles / comments / logs / prompts / fields）</td>
          <td>6 原則（原子化 / 索引 / 意圖顯性 / 可查詢 / 欄位 / 多輪 review）+ 各 surface 特化 reference</td>
      </tr>
      <tr>
          <td>跨章節教學模組生產流程</td>
          <td>跨 5+ 章、有 case 庫的教學模組</td>
          <td>case-first 流程：案例 audit → 基於 findings 寫稿 → agent team 平行 review → 修正循環 → polish pass、加 case 引用四 axis 紀律（深度 / 分層 / 合成 / 結構）</td>
      </tr>
  </tbody>
</table>
<p>兩類流程互補疊加 — 教學模組的每章內部寫作仍套本 skill 6 原則、case 引用段落用 <a href="/blog/report/case-citation-three-part-structure/" data-link-title="案例引用三段式段落結構：概念定義 → case 引用 → 通用展開" data-link-desc="Case 引用段落要走三段式結構：(1) 段首概念定義句先寫『該概念是什麼、承擔什麼責任』、(2) 第二位置 case 引用、(3) 通用工程知識展開；段首被 case 引用取代是 06 模組最大宗 systemic 違規（11/12 段都犯）；本卡跟 #115（引用深度）/ #116（內部分層）/ #117（跨 case 合成）正交、處理段落結構順序">case-citation-three-part-structure</a>、agent team review 用 <a href="/blog/report/agent-team-context-isolation/" data-link-title="Agent team context 隔離設計：用不同 instance 換 frame、平行 background 保護主 context" data-link-desc="Multi-pass review 跨輪 frame（#83）跟跨 reviewer instance 隔離（本卡）是兩個 axis：#83 是同一 reviewer 換輪次 frame、本卡是不同 reviewer instance 各自獨立 background 跑；context 隔離設計讓主 context 只接精煉摘要、節省 ~80% token、跟同 reviewer 多輪 catch 同類錯（#114）形成互補解法">agent-team-context-isolation</a>。當下游專案沒有跨章節教學模組需求、本 skill 即可獨立運作；當有需求、教學模組生產流程是本 skill 的擴展層、不取代本 skill。</p>
<h2 id="跟-multi-round-review-的協同">跟 multi-round-review 的協同</h2>
<p>寫多篇章節 / report 卡 / knowledge card 後做<strong>多輪 agent reviewer audit</strong> 時、本 skill 應該跟 multi-round-review skill 同時啟動。觸發詞「多輪審查 / Round 1/2/3 / batch review / 寫作 audit」會同時啟動兩個 skill：</p>
<ul>
<li><strong>multi-round-review</strong> 規劃 frame 切換結構（Round 1 compliance / Round 2 cadence / Round 3 self-application）跟跨輪 finding 整合工作流</li>
<li><strong>本 skill（compositional-writing）</strong> 提供每輪 frame 的字句層 keyword bank — Round 1-A 寫作規範 reviewer 必須跑：
<ul>
<li><strong>正向陳述優先 grep</strong>：<code>rg &quot;不[行可是要能該支對符夠必]|無法|沒[做有]|而非|而不是&quot;</code>、加上<strong>否定起手定義句</strong>（原 pattern 漏「而是」、抓不到「不是 X、而是 Y」的後半）：<code>rg &quot;不是.{0,30}而是|不是.{0,20}、是|與其.{0,20}不如|不只.{0,15}更&quot;</code> — 主要敘述要正向、反例對照的少量負向可保留；判別在「核心概念第一次正面出現在句首、還是被擠到『而是』之後」</li>
<li><strong>口語修辭 grep</strong>：<code>rg &quot;其實|實務上|真的|碰巧|立刻撞牆|沒事&quot;</code></li>
<li><strong>地區用語 grep</strong>：<code>rg &quot;集群|默認|質量|視頻|函數|文件夾|接口&quot;</code></li>
<li><strong>廢話前綴 grep</strong>：<code>rg &quot;值得注意的是|需要說明的是|實際上|基本上|事實上&quot;</code></li>
<li><strong>裝飾符號 grep</strong>：<code>rg &quot;✅|❌|⚠️|🚨|🟡|🟢|⭐|📌|✓|✗&quot;</code></li>
<li><strong>對讀者喊話 grep</strong>：<code>rg &quot;很多人|大家|不少人|你天天|你會|你可能|先讀懂|先釐清|別搞混|別被&quot;</code> — 教材中性陳述、不安撫情緒 / 不第二人稱代入 / 不祈使控制閱讀（hook / narrative 段落輕度第二人稱可留）</li>
<li><strong>自評誇飾 grep</strong>：<code>rg &quot;教科書級|堪稱|可謂|完美|經典|範本級|大師級|漂亮地|優雅地|最佳實踐|best practice&quot;</code> — 品質 verdict 頂替技術理由、換成機制 / 條件</li>
<li><strong>必然性框架 grep</strong>：<code>rg &quot;天生|與生俱來|本質就是|本來就是|必然|唯一|註定|理所當然&quot;</code> — 把設計選擇講成自然法則、還原成條件性（物理 / 法律 / 數學事實除外）</li>
<li><strong>歸因語氣 grep</strong>：<code>rg &quot;承認|暴露了|證明了失敗|被迫&quot;</code> — 描述系統行為用「信號」「反映」「顯示」等中性觀測詞、避免「承認」「暴露」等責任歸因詞；「被迫」在描述外部強制約束時可保留</li>
<li><strong>宣導語氣 grep</strong>：<code>rg &quot;你可能沒注意|你可能不知道|想像一下|把.{1,5}想成|跑得好好的|聽起來很|其實很簡單|說穿了就是|等於拆未爆彈|乾瞪眼|延遲引爆&quot;</code> — 預設讀者無知或用情緒管理取代事實陳述；讀者是專業人士、直接描述情境與後果</li>
<li><strong>泛用詞濫用 grep</strong>：<code>rg &quot;坑|東西|搞|弄|處理一下|情況&quot;</code> — 同一個泛用詞蓋過不同具體情境時、依情境換精確詞（意外 / 陷阱 / 出問題 / 發生狀況）；命中密集且各指不同事才算違規、真泛指 / 引號引用 / 輕度 hook 合規；「坑」另有地區偏移面（某些地區高頻、某些少用）。見 <a href="/report/avoid-overused-generic-words/">avoid-overused-generic-words</a></li>
<li><strong>這些 grep 曝光候選、不做自動判定</strong>：命中後要不要算違規有品味核心；且 LLM reviewer 跟作者共享文體、同源自審對 register 類（否定起手 / 喊話 / 誇飾 / 概念前置）有結構上限 ——「不是 X、而是 Y」這種 LLM 高頻自產句型最容易全員放水。grep + 同源判定只負責曝光候選、register 層的真防線是文體異源視角（human cold-read 或 prompt 採「挑剔否定起手 / 概念後置」對抗姿態的 reviewer）、同源回報的「clean」不可當真</li>
</ul>
</li>
</ul>
<p>詳細各維度的判讀規則跟修法、見對應 reference（writing-articles / writing-documents 等）跟 <code>references/principles/</code> 內的 cadence-homogenization / colloquial-rhetoric / regional-terminology / decorative-symbols / multi-pass-review-frame-granularity 等卡。</p>
<p>協同要點：</p>
<ul>
<li>單獨用 multi-round-review、容易漏字句層 — reviewer prompt 列「規範遵循」但漏 grep 具體 pattern</li>
<li>單獨用本 skill、容易漏跨輪 frame 規劃 — 知道要檢查字句層、但缺「Round N+1 用什麼新 frame」結構</li>
<li>兩個 skill 一起啟動 — multi-round-review 給結構、本 skill 給每輪的 grep checklist</li>
</ul>
<p>寫作對象是「單篇 + 完稿前自己 review」時、用本 skill 第 6 原則（多輪 Re-read Pass）的 5 輪 frame 即可；寫作對象是「跨多篇 + agent reviewer 平行 audit」時、multi-round-review 接手結構規劃、本 skill 在 reviewer prompt 內被引用作為檢查清單。</p>
<hr>
<h2 id="directory-index">Directory Index</h2>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln"> 1</span><span class="cl">compositional-writing/
</span></span><span class="line"><span class="ln"> 2</span><span class="cl">├── SKILL.md                              # 本檔：核心原則速查 + 觸發路由
</span></span><span class="line"><span class="ln"> 3</span><span class="cl">└── references/
</span></span><span class="line"><span class="ln"> 4</span><span class="cl">    ├── writing-code-comments.md          # 情境 1：程式碼註解
</span></span><span class="line"><span class="ln"> 5</span><span class="cl">    ├── writing-documents.md              # 情境 2：文件撰寫
</span></span><span class="line"><span class="ln"> 6</span><span class="cl">    ├── writing-logs.md                   # 情境 3：log 輸出
</span></span><span class="line"><span class="ln"> 7</span><span class="cl">    ├── writing-prompts.md                # 情境 4：prompt 撰寫
</span></span><span class="line"><span class="ln"> 8</span><span class="cl">    ├── writing-articles.md               # 情境 5：完整長篇技術文章
</span></span><span class="line"><span class="ln"> 9</span><span class="cl">    ├── source-to-teaching-analysis.md     # 情境 5a：外部分析材料 → 教學型分析文章
</span></span><span class="line"><span class="ln">10</span><span class="cl">    ├── translation-review.md             # 情境 5b：文章翻譯 / 轉譯的句內邏輯 review
</span></span><span class="line"><span class="ln">11</span><span class="cl">    ├── managing-article-collections.md   # 情境 5c：跨多篇文章的結構（三層、素材庫比例、MOC、Pattern 卡片）
</span></span><span class="line"><span class="ln">12</span><span class="cl">    ├── designing-fields.md               # 情境 6：欄位設計（含六欄位角度總表）
</span></span><span class="line"><span class="ln">13</span><span class="cl">    ├── designing-fields-ticket-6w.md     # 六欄位詳細範例：正確 + 混淆共 12 項（按需讀取）
</span></span><span class="line"><span class="ln">14</span><span class="cl">    ├── meta-metrics.md                   # 品質量化驗收（M1-M5）
</span></span><span class="line"><span class="ln">15</span><span class="cl">    ├── reference-authoring-standards.md  # Skill reference 撰寫品質規範
</span></span><span class="line"><span class="ln">16</span><span class="cl">    ├── dry-run-guide.md                  # Skill 發布前語意層驗收（Phase 2 dry-run 流程）
</span></span><span class="line"><span class="ln">17</span><span class="cl">    └── principles/                       # Skill 內部支撐型原則卡（含 terminology / naming / review / case-citation / agent-team 等原則）</span></span></code></pre></div><hr>
<h2 id="reading-order建議閱讀順序">Reading Order（建議閱讀順序）</h2>
<ol>
<li>第一次接觸 → 從本 SKILL.md 的「核心支柱 + 核心原則」讀起</li>
<li>進入實際寫作情境 → 依觸發路由讀對應 reference（只讀一份）</li>
<li>想驗證成果 → 讀 <code>meta-metrics.md</code> 做自評</li>
</ol>
<hr>
<p><strong>Last Updated</strong>: 2026-06-25
<strong>Version</strong>: 0.18.0 — 輪 9 reader-sim 加第四 lens「AI 歸因過度」（AI 生成內容系統性把通用 pattern 框為 AI 特有、縮窄適用範圍且背上無法證實的舉證負擔；判準：「AI」換成「作者」論點仍成立 → 改通用觀察）；提交自檢清單加第 4 個生成端自問句（AI 歸因測試）。</p>
<p><strong>Version</strong>: 0.18.0 — 新增「泛用詞濫用」字句層 frame（讀者回饋觸發：反覆用「坑」把不同情境壓成同一模糊標籤、繁中少用）：keyword bank 加 <code>rg &quot;坑|東西|搞|弄|處理一下|情況&quot;</code>、新增 principle 卡 <a href="/report/avoid-overused-generic-words/">avoid-overused-generic-words</a>（依情境換精確詞、跟 colloquial/regional/cadence 三卡的軸區分）、writing-articles 輪 8 清單同步；命中密集且各指不同事才違規、真泛指 / 引號 / 輕度 hook 合規
<strong>Version</strong>: 0.17.0 — keyword bank 新增歸因語氣 grep + 否定起手定義句 pattern；輪 8-10 描述補恐嚇式語氣 / 歸因語氣；移除 comment-qa-hook / worklog-format-check hook（職責已由其他機制覆蓋）；references 更新（atomic-note / teaching-prose / writing-articles / writing-documents）。</p>
<p><strong>Version</strong>: 0.16.0 — 從工具 opinion 文章的三輪審查 + 使用者回饋回流 6 張 report 卡（WRAP 分析後選混合方案）：(1) keyword bank 加歸因語氣 grep（<code>承認|暴露了|證明了失敗|被迫</code>）— 唯一有穩定關鍵詞的新 design gap；(2) <code>teaching-prose-neutral-register</code> 加第四類「恐嚇式語氣」（把讀者放在被警告位置、判別線是「你→我們」替換測試）；(3) writing-articles 輪 9 reader-sim 加第三 lens「meta 資訊 vs 內容」（涵蓋 meta-commentary 殘留 + 主題偏移兩個 gap）；(4) writing-articles 提交自檢清單加 3 個生成端自問句（恐嚇式 hook / meta 刪除測試 / 歸因語氣）。不新增 principle 卡（27 張已夠、新議題融入現有卡）、不增 SKILL.md 主體段落（密度飽和、改動集中在 keyword bank 一行 + 下游 reference）。</p>
<p><strong>Last Updated</strong>: 2026-06-11
<strong>Version</strong>: 0.15.0 — 對七張同批 report 卡（#157-#163 主題：語意錨 / 決策表 / 入口分流 / 跨 surface / 摘要模態 / 引用詞彙 / 欄位契約）跑三 reviewer audit 後的回饋：(1) 新增 principle 卡 <a href="/blog/report/cadence-homogenization-in-batch-writing/" data-link-title="Cadence 同質化是模板的隱形維度" data-link-desc="規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位">cadence-homogenization</a>（同時修復 SKILL.md 長期 dangling 的引用）— 六個同骨層實測清單 + 生成端輪替規則 + 「同類 finding 第二次出現升生成端」的升級原則（觸發：上一輪抓過的「判準句同模」在本批復發、擴到 4/7）；(2) 原則 6 surface enumeration 補 description 模態檢查（實測 4/7 份 description 模態漂移、其中一份把同批另一張卡才立的「候選」壓成「證據」）；(3) 原則 6 補批量 sibling 生成端輪替段；(4) 原則 2 補「語意錨單一字串 + 引用他卡用對方詞彙」段（關係宣告 28 條核對抓到 2 條：被引卡沒漏的宣稱成漏、對方的 navigation surface 被轉述成 metadata surface）。</p>
<p><strong>Last Updated</strong>: 2026-06-11
<strong>Version</strong>: 0.14.0 — multi-round review Round 1 的 self-application 修正：兩個 reviewer 從不同 frame 獨立抓到本 skill 自身殘留 count-bearing 名稱（convergence 訊號）。(1) 「Core Pillars（三大支柱）」→「（核心支柱）」、「Six Principles（六大原則速查）」→「Core Principles（核心原則速查）」、「五階段流程」→「case-first 流程」；(2) references 內「五大原則」全改「核心原則」— 這批字串在原則從 5 個長到 6 個之後就已經全部過期（SKILL.md 寫六大、references 寫五大）、是 name-collections-by-role-not-count 卡描述的失效模式在本 skill 的實證；(3) reference-by-semantic-title-not-number 卡的 ISO 邊界限定到版本年份（跨版改版會重編條款）。後續 Round 3 self-application sweep 抓到本條宣稱的漏網（writing-code-comments 的「五大寫作原則」）與另兩處 count 殘留（「五大 surface」「三大正交 axis」）、已一併清除；兩張新 principle 卡依 steelman 補強（#155 卡補「標題改名 vs 編號位移」斷裂等級差、#156 卡補數字記憶價值的誠實對沖與「內部宣告凍結」邊界）。</p>
<p><strong>Last Updated</strong>: 2026-06-11
<strong>Version</strong>: 0.13.0 — 0.12.0 的同日延伸：使用者指出「核心七問」「成長六階段」是另一層問題 — 引用端修好了、但錨點名稱本身內嵌成員數（七 / 六 是 membership 的 derivation）、加一問名稱先失真、所有複製過名稱的地方跟著過期；0.12.0 的原則 2 新段自己就用「見核心七問」當正面範例而未察覺、證明命名端與引用端是獨立檢查維度。(1) 原則 2 補「集合命名用角色、不內嵌數量」段；(2) 新增 principle 卡 <a href="/blog/report/name-collections-by-role-not-count/" data-link-title="集合命名用角色、不內嵌數量：「核心七問」的七是成員數的 derivation、加一問就全面失真" data-link-desc="「核心七問」「成長六階段」「四大支柱」這類名稱把成員數量烤進名字裡 — 數量是集合當前成員的 derivation、不是集合的語意身分；成員增減時名稱失真、且名稱是被複製最多次的字串、缺陷隨每次引用繁殖。修法：命名只承載角色與層級（核心問題 / 次要問題 / 撞牆階段）、數量讓清單自己呈現。本卡是 #155 的命名端 sibling（#155 修引用端、本卡讓「語意標題是穩定錨」的前提真正成立）、#44 SSoT 在名稱內容的實例、#84 命名檢驗的數量維度。">name-collections-by-role-not-count</a>（self-contained、含三種可留數字的邊界：外部凍結品牌 / 概念閾值 / 緊鄰清單行內計數、含命名端掃描 regex）；(3) reference-by-semantic-title-not-number 卡補 sibling 連結、0.12.0 三處「核心七問」範例全改「核心問題」；(4) writing-documents Principle 2 補命名端段落。</p>
<p><strong>Last Updated</strong>: 2026-06-11
<strong>Version</strong>: 0.12.0 — 從一份多階段訪談 skill 的階段重編號事故回流：跨檔引用寫成「Stage 3」「Stage 1-3」、流程從四階段改六階段後十多處引用 silent 錯位（字面完好、語意指向錯的階段）、grep 只能抓字面、人工逐處判讀仍漏修兩處。(1) 原則 2（索引建立）補「引用錨點用語意標題、不用位置編號」段 — 編號是結構排列的 derivation、misdirected 比 dangling 難偵測、標題要承載可被引用的語意、凍結編號（RFC / 法條）是 fact 例外；(2) 新增 principle 卡 <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 命名承載語意的引用面延伸。">reference-by-semantic-title-not-number</a>（self-contained、含重排 commit 的引用面掃描 regex）；(3) writing-documents Principle 2 cross-reference 段補同主題小節 + anti-pattern 表加「See Stage 3 指向活文件」列。同一問題第二次出現（v0.9.1 曾修過「Stage 1-5」→「五階段流程」的 portability leak）、符合兩次門檻立卡。</p>
<p><strong>Last Updated</strong>: 2026-06-01
<strong>Version</strong>: 0.11.0 — 從一篇技術教材 review 抽出三類字句層 register/framing 問題回流：(1) keyword bank 加 3 類（對讀者喊話 / 自評誇飾 / 必然性框架）、同步 description、協同段 grep、輪 8-10 段、writing-articles 輪 8；(2) 原則三補「絕對二元語氣的命令式 vs 必然式」subtype（必然式偽裝成事實、更隱形）；(3) 新增 principle 卡 <a href="/blog/report/teaching-register-states-not-addresses-reader/" data-link-title="教材用中性陳述、不對讀者喊話" data-link-desc="教材的 register 是中性陳述概念、不是對讀者說話。三種對讀者喊話的形式 —— 安撫情緒（很多人卡在）、第二人稱代入（你天天寫）、祈使控制閱讀（先讀懂 / 別搞混）—— 表面不同、共同違反是把讀者當成要管理的對話對象、而非把概念講清楚。問題不在精度（「你天天寫的 int count」精度完全正確）、在 stance。修法是換成中性陳述（常見的 int count）或描述性名詞標題（簽章的型別與名字拆解）。邊界：hook / narrative 段落的輕度第二人稱可幫讀者進入、不一律禁。">teaching-prose-neutral-register</a>（涵蓋三類、self-contained）；(4) multi-pass-review-frame-granularity 補「偵測之後：keyword bank 命中是候選不是判決」判定層段（偵測 vs 判定兩步驟、clean 可能是判定放水）。跟 multi-round-review Round 1-A 同步加 3 grep + 判定指引。</p>
<p><strong>Last Updated</strong>: 2026-05-27
<strong>Version</strong>: 0.10.0 — 從 13 張 knowledge cards 批量改寫負向表述的經驗回流：(1) description 加觸發詞「多輪審查 / multi-round review / batch review / 寫作 audit / 正向陳述 / 口語修辭 / 字句層 grep」、明示「也在 multi-round-review 啟動時觸發」；(2) 新增「跟 multi-round-review 的協同」段、列出 Round 1-A 寫作規範 reviewer 必須跑的 5 個 grep pattern（正向陳述 / 口語修辭 / 地區用語 / 廢話前綴 / 裝飾符號）、明示兩 skill 垂直協同關係；(3) 修正 multi-round-review 漏抓字句層的盲區、跟 multi-round-review v1.1 同步 cross-trigger 設計
<strong>Version</strong>: 0.9.2 — 從 business case-analyses 演變回流：新增 <code>source-to-teaching-analysis.md</code> 路由，處理外部分析文章 / 產業評論 / 投資人備忘錄到教學型分析文章的轉換；新增三張 principle（external-analysis-source-layering / cross-domain-reader-level-alignment / analysis-rewrite-delivers-transferable-framework），把 source 分層、跨領域讀者降層、可遷移框架交付從 blog report 抽成 portable 規則。
<strong>Version</strong>: 0.9.1 — Stage 4 修正 3-reviewer 抓的 33 issue：(1) #120 mirror 縮 scope 解過載（移除四 axis 表 / 句構分流 / polish pass 段、聚焦三段式結構 axis）+ 結論段首改概念定義句解 dogfooding 失敗；(2) #121 mirror 結論表三欄重設計（設計選擇 / 解決問題 / 失敗模式）+ 實作 pattern 縮成 abstract pattern；(3) 兩 mirror 角色段引用點改措辭（移除虛假引用宣告）；(4) SKILL.md 原則 3/6 兩補強段段首改概念定義句、原則 6「詳見」list 補新 mirror、Directory Index 補；(5) Portability leak 修：「Stage 2 自查清單」→「寫稿後段落自查清單」、「Stage 1-5」→「五階段流程」；(6) 五大 / 六大原則 drift 對齊（line 105 / 160）；(7) 既有 principles（writing-multi-pass-review / multi-pass-review-frame-granularity / ease-of-writing-vs-intent-alignment）補回引新 mirror、形成雙向 cross-link
<strong>Version</strong>: 0.9.0 — 從跨章節教學模組生產經驗回流：原則 3 補「Case 引用段落三段式結構」段（詳見 case-citation-three-part-structure）；原則 6 補「Instance 軸：跨 reviewer instance 隔離」段（詳見 agent-team-context-isolation、跟 frame 軸正交可疊加）；新增「跟特化寫作流程的分工」段（明示本 skill 是單篇基礎方法、跨章節教學模組生產流程是擴展層）；principles/ 新增兩張 mirror 卡（case-citation-three-part-structure / agent-team-context-isolation）、自包含、不引用外部 skill 或 blog content
<strong>Version</strong>: 0.8.1 — 第 6 原則同步 writing-articles v0.8.1：補「Production 教學文章追加輪 8-10」段（換工具 / 換視角 / 換層次三機制處理「跑 N 輪仍漏」字句層問題）；「詳見」連結加 5 張新 principle（colloquial-rhetoric / prose-self-contained / regional-terminology / multi-pass-review-frame-granularity / design-flaw-by-current-axes）
<strong>Version</strong>: 0.7.4 — 新增 <code>translation-review.md</code> 路由：翻譯 / 轉譯文章時，用句內邏輯檢查譯名是否跟主詞、動詞、修飾語、因果與讀者追問方向對位。
<strong>Version</strong>: 0.7.3 — managing-article-collections 補「素材庫比例」路由：多篇文章需要案例 / source / scenario / pattern 支撐時，主文章情境維持少量、素材庫保留 2-3 倍來源做反向驗證
<strong>Version</strong>: 0.7.2 — 補 multi-pass 的 surface 軸：review 先列 body / metadata / navigation surface（title、description、tags、heading、link label、MOC hook、slug / filename），每輪 frame 都掃同一份 surface 清單；新增內部 principle <code>metadata-surface-in-writing-review.md</code>
<strong>Version</strong>: 0.22.0 — 原則 3 加「知識卡建卡判準用最不熟悉的讀者」；常識是相對於讀者背景的、跨背景讀者群幾乎所有領域特定術語都需要建卡
<strong>Version</strong>: 0.21.0 — 原則 3 加「操作步驟帶環境專屬工具路徑」（同動作在 container/VM/共享主機的工具不同）
<strong>Version</strong>: 0.20.0 — 原則 3 加「讀者定位聲明」生成端前置步驟；從 infra 模組 retrospective 抽出（讀者定位未預設導致宣導語氣通過三輪審查）
<strong>Version</strong>: 0.19.0 — 新增三張 principle 卡（audience-is-professional-not-layperson / cross-expertise-scenario-not-analogy / management-reportable-info-in-technical-content）、原則 3 加讀者定位與跨專業溝通子原則、keyword bank 加宣導語氣 grep；從 infra 教學模組的寫作 retrospective 抽出
<strong>Version</strong>: 0.7.0 — Phase B1 結構升級：加第 6 原則「多輪 Re-read Pass」（明示 5 輪 frame）、引用 #83 / #84 / #85 multi-pass 系列。後續 Phase B2 會把各 reference 結尾加「第 2 輪 review checklist」段
<strong>Version</strong>: 0.6.0 — 從 references 過載的反思：writing-articles.md 從 780 行瘦身到 ~530 行（拆分判準 / 三類 structure 模板搬到 managing-article-collections.md、focus 集中在「單篇文章內部」）；新增規則八「自我應用 (dogfooding)」（教某條規則的段落本身遵守該規則）；managing-article-collections.md 整合「拆分判準」+「三層 structure 詳細對照 + 模板」；meta-metrics.md M2 加 dogfooding 失敗訊號
<strong>Version</strong>: 0.5.0 — 從批量改寫 35 篇的經驗回流：原則 3 補「選項數由議題決定、不強湊」（避免 A/B/C/D 強迫症與「實務上幾乎不存在」的假反模式）；writing-articles.md 新增規則九（三類文章 structure 模板）；managing-article-collections.md 新增「跨篇引用 idiom 庫」與「三層 structure 對照」
<strong>Version</strong>: 0.4.0 — 新增 <code>managing-article-collections.md</code>（跨多篇文章結構：三層、MOC、Pattern 卡片）；強化原則 1「原子化」（focus 是議題完整度、不是邊界清晰）；強化原則 3「意圖顯性」（機會成本語氣、不用絕對主義）
<strong>Version</strong>: 0.3.0 — 新增 <code>dry-run-guide.md</code> 於 Directory Index 與觸發路由（Skill 發布前語意層驗收 Phase 2 dry-run）</p>
]]></content:encoded></item></channel></rss>