Tarragon

"Writing"

• 2026-05-20 降一級寫法：用矩陣框架讓技術讀者讀懂商業分析 用 [媒介—讀者—目的矩陣](/business/reading-frameworks/reader-purpose-matrix/) 識別文章目標讀者層級、然後刻意降一級寫法、讓技術背景讀者讀懂原本給 VC / 創辦人看的商業分析。具體做法是拆因果鏈、unpack 術語、加具體算式；對照示範用 Claude for Legal 案例中『毛利擠壓』那段展示降級前後的差異。
• 2026-04-26 Writing 的 multi-pass review：N 輪 review、每輪換 frame 寫文章 / 註解 / 文件 / prompt 的「寫」不是單次動作 — 是 N 輪 review。第 1 輪生成、第 2 輪對意圖（#67）、第 3 輪檢查機會成本語氣、第 4 輪 grep-ability、第 5 輪反例 / 邊界。每輪不同 frame、單輪寫不出全部維度。本卡是 #82 在「寫」這個 output 動作的具體實例。
• 2026-04-28 視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題 修視覺問題的工具（CSS、emoji、顏色、排版）只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 + false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序：邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。
• 2026-05-01 用 Next-action frame 取代 Disclaimer：把 prohibition 翻成 actionable chain 當 audit / risk 識別 reader 不該做 X、寫作回應若停在 disclaimer 段（告訴 reader 不要 X）、整段自然產出 negative phrasing（不是 / ≠ / 不要）、即使逐句翻正向句法仍是 disclaimer。Reframe 成 next-action 段（告訴 reader 沿 chain 做 Y / Z）整段自然 positive、不需 contrast。Frame 選擇是 #94 正向改寫的上游問題——逐句正向化處理不到 frame 層、reframe 整段才會根治。
• 2026-05-04 術語翻譯要保留原文錨點 翻譯術語時、中文名稱負責降低閱讀門檻，原文名稱負責鎖定概念邊界。只留中文會把 reader 帶進中文詞的日常歧義，只留英文會提高閱讀成本；中文後接英文括號是技術文章的穩定折衷。
• 2026-05-04 中文壓縮術語要保留完整名詞頭 中文技術寫作可以壓縮長詞，但不能省到只剩形容詞或單字修飾。像「多步驟 perplexity 盲」這類詞少了完整名詞頭，讀者無法判斷是在說盲點、盲區、盲測或失明比喻。壓縮後仍要能獨立回答「這是什麼」。
• 2026-05-04 術語翻譯要保留概念角色 術語翻譯不能只追求中文好讀，還要保留原詞在論證中的概念角色。Steelman 若翻成「最強版本測試」，reader 會以為它是一個檢查動作；但在決策語境裡，它更核心的責任是把反方論點重建成最強版本。
• 2026-05-13 案例引用深度跟著 case 類型走 skeleton / medium / rich case 各有不同承接深度；誤判類型 → 編造數字 / taxonomy（over-extrapolation）或漏掉 case 揭露的 mechanism（under-citation）；引用前先看 case 行數 + 內容密度判類型、決定該寫『揭露 X 方向』還是『揭露 N 個機制』還是『揭露具體數字 / 設計』
• 2026-05-13 引用案例要分觀察層 / 判讀層、強化詞是錯位訊號 引用案例（特別是 rich case）時、case 內容分兩層：觀察層（具體 fact）跟判讀層（作者推論）；兩層在章節引用時要分層標明、避免把作者判讀升級成 case fact；強化詞（才是 / 必須 / 一定 / 關鍵是）通常是錯位訊號、保留 case 原文的條件性表述（取決於 / 核心瓶頸 / 主要驅動）
• 2026-05-13 跨多個 case 合成的 frame 必須標為章節合成、非 case 原文 當段落把多個 case 的失效訊號抽象為更高層 frame（如『跨工具回查壓力』『平台責任切分』）、要 explicit 標為『本章合成、非 case 原文』；否則章節 derive 會被讀者當成 case fact、回查 case 時發現章節說的『揭露』實際是章節抽象、不是 case 原文框架
• 2026-05-13 Standard-driven 取代 Case-driven 適用 standard framework 比 case 庫成熟的領域 並非所有領域都該走 case-driven。判斷該用哪種策略看四維度：議題穩定度 / case 公開度 / standard 成熟度 / 維護半衰期。LLM 安全屬 standard-driven 領域（OWASP LLM Top 10 + NIST AI RMF 已成型、case 半衰期 6 個月）；分散式系統 / 安全控制面屬 case-driven 領域（case 公開充分、半衰期 5+ 年）。誤套會導致 case 庫過早建構或 case 過時
• 2026-05-13 章節已有 routing skeleton 走補強段、不空白擴章 章節結構分兩類：空白章節（threat scope / 問題節點表都待補）vs routing layer 章節（已有完整結構、case 庫缺位用 standard 引用承接）。擴章策略要對應結構——空白章節走 case-driven 大幅擴章；routing layer 章節走補強段（在現有結構內補 mechanism 深化）；誤判結構會引發 frame 重複展開或章節失衡
• 2026-05-13 案例引用三段式段落結構：概念定義 → case 引用 → 通用展開 Case 引用段落要走三段式結構：(1) 段首概念定義句先寫『該概念是什麼、承擔什麼責任』、(2) 第二位置 case 引用、(3) 通用工程知識展開；段首被 case 引用取代是 06 模組最大宗 systemic 違規（11/12 段都犯）；本卡跟 #115（引用深度）/ #116（內部分層）/ #117（跨 case 合成）正交、處理段落結構順序
• 2026-05-13 Agent team context 隔離設計：用不同 instance 換 frame、平行 background 保護主 context Multi-pass review 跨輪 frame（#83）跟跨 reviewer instance 隔離（本卡）是兩個 axis：#83 是同一 reviewer 換輪次 frame、本卡是不同 reviewer instance 各自獨立 background 跑；context 隔離設計讓主 context 只接精煉摘要、節省 ~80% token、跟同 reviewer 多輪 catch 同類錯（#114）形成互補解法
• 2026-05-18 Cadence 同質化是模板的隱形維度 規範定義「模板」時通常只指內容欄位（規模對照、tripwire、失敗模式），忽略句型骨架 / 段首語 / 段末收尾語 / 表格前導句 / 過渡詞同樣是模板的一種；批量寫作時最易讓 cadence 同質化、單篇看起來都合規、連讀多篇才浮現預期化；51 vendor 都用「四件事 → 任一缺失就是 X 邊界的待補項目」是案例；自檢要 grep 首句 / 段末句 / 表格前導句、不是只看欄位
• 2026-05-18 多重硬規範同時生效會把 cadence 推向便利解 當 N 個硬規範同時 enforce（11 章節結構 + 表格深化 + sweet spot 行數 + lint 規則）、找到一個「都通過」的 framing 後、批量寫作會把這個 framing 複製到所有檔案；cadence 同質化不是違規、是「合規最佳解」的副作用；對策是把 framing 多樣性也納入硬規範、或拉開 constraint 讓多個 framing 都有合規路徑；是 #67 在「批量寫作」的具體機制展現
• 2026-05-18 Emergence-class 違規規則化不了、要 stage 0 變體規劃 + stage 內抽樣兩層 違規分三類（字面 / 結構 / emergence）、enforcement 時機要對應違規類型；字面違規（emoji / 裸 URL）可 regex hook 在 pre-commit 攔、結構違規（章節缺失 / frontmatter）可 linter 攔、emergence 違規（cadence 同質化 / 跨檔語氣漂移）規則化不了、需要 *stage 0 變體規劃（主動設計）* + *stage 內抽樣（被動監測）* 兩層；checkpoint 只是監測工具、若 stage 0 沒準備 variant、被動抽樣不會自動發現 collapse；補 #82 字面 vs 行為的「時機」軸
• 2026-05-18 寫作 review 是多軸完整性、不是單軸深度 寫作 review 的完整性不是單一軸越做越深、是多軸交集都對齊；#83 frame 軸 + #121 instance 軸 + #97 surface 軸 + #95 scope 軸 + #122 cadence 軸 + #124 timing 軸 + #114 granularity 軸、七軸正交、缺任一軸都會 systematic miss；review 設計時要 enumerate 七軸覆蓋狀況、不是只跑一兩個維度做深；是 #79 五維決策對話在 review 工具設計的姊妹卡
• 2026-05-20 WRAP Widen Options 容易塌成稻草人 framing、要改 evidence weight 結構 WRAP 框架的 Widen Options 段在案例寫作中容易塌成「列爛選項 → 打掉 → 留正解」的修辭結構、變成稻草人 setup。問題不在框架本身、在於寫作時把 Widen Options → Reality Test 當作全文 narrative 主軸。修法是把 Widen Options 從「對抗稻草人」改成「並陳合理因果鏈用 evidence 配重」、Reality Test 從 binary verdict 改成 weight assessment + Falsifier。是 #125 Collapse 在 WRAP 寫作 surface 的具體 instance、#79 多軸決策的姊妹卡。
• 2026-05-20 WRAP 是寫作者的內部工具、不是文章章節結構 WRAP 框架（Anchor Check / Step 0 / Widen Options / Reality Test / Attain Distance / Prepare to be Wrong / Tripwire）是寫作者背後做 hypothesis 探索與認知偏誤防護的內部工具。當把這些 process 標籤暴露成文章章節標題、讀者會踩三個壞 effect：預設讀者認知、塞滿 meta dialogue、同論點重複預告。修法是把 WRAP 工作內嵌進教學 narrative、章節順序服從教學流程。是 #140 WRAP Widen Options 稻草人的上位原則、跟 #125 Collapse 同骨。
• 2026-05-20 文章主體要對齊標題承諾、WRAP 內部分析不該喧賓奪主 文章標題對讀者做了承諾、文章主體必須對齊這個承諾。WRAP 內部分析（Widen Options + Reality Test 含 prior 引用 + evidence weight）即使方法論做得好、如果不是標題承諾的內容、就不該佔文章主體—屬於 scope mismatch、跟 process metadata 暴露（#141）的議題分開。附帶議題：當 WRAP 內部分析喧賓奪主、為了支撐 prior 容易引入沒實際出處的 source citation；把 WRAP 內部分析從主體移除、hallucination 風險自然降低。是 #141 的姊妹卡—#141 處理章節標題 surface、本卡處理章節內容 scope。
• 2026-05-20 外部分析文章要先拆成事實、作者判讀、本文推導 把外部分析師文章轉成教學型商業分析時、原文不是可直接搬進正文的 case fact。寫作者要先把材料拆成三層：可驗證事實、原作者判讀、本文推導。三層混寫會讓分析師 frame 被讀者誤當事實、也會讓本文自己的結論失去可回溯性。修法是先做 source layering、再決定哪些內容進事件段、哪些內容只作為 hypothesis prior、哪些內容要標為本文合成。
• 2026-05-20 跨領域分析要先定位讀者層級、再決定術語密度 把商業分析寫給工程背景讀者時、不能繼承原分析文章的 VC / founder / industry insider 讀者假設。跨領域寫作要先定位來源文章與目標讀者的層級差，再決定術語密度、因果鏈步長與例子粒度。若直接沿用高密度商業語言，文章看似專業、但讀者只能記名詞，無法複製判讀。
• 2026-05-20 外部分析改寫的交付物是可遷移框架、不是風格轉換 把其他分析師文章交給 AI 改寫時、任務目標不能停在語氣、段落與措辭符合本站風格。教學型商業分析的交付物是讀者可帶到下一個事件使用的判讀框架。若只做風格轉換，文章會像摘要或二次評論；若做框架轉換，文章會把事件拆成訊號、機制、風險、預警與下一步路由。
• 2026-05-27 案例庫不對齊章節主題時用反向追問取代強掛 當案例庫主軸跟章節主題不在同一維度時、引用框架要從『正向掛入』切換到『反向追問』；強掛 case 的根因是『想填滿案例段』的模板配額、而非『想讓讀者看到證據』；反向追問把案例庫的限制當 first-class 訊息傳給讀者、case 變成『沒做 X 的後果』的反證、不是 X 的示範；reviewer 第一輪 fact-check 就能抓出強掛、修正成本高；判讀徵兆是引用句寫不出 case 具體段落 / 多個 case 句型雷同 / 章節主題跟 case 庫主軸不同維度
• 2026-05-27 規範化跟自審是兩種認知任務、立規範當下無法保護同批稿件 把反模式抽象成規範卡、跟在自己稿件辨識該反模式的局部實例、是兩種不同認知任務；前者用『歸納共同特徵』的視角、後者用『局部 pattern matching』的視角；用相同概念詞、走不同神經路徑；案例：#146 卡描述「看 X 如何 Y」是反模式、同 batch 5 篇章節仍有 11 處該句型未被作者察覺；修法是規範化當下立刻把規範轉成 grep keyword、對同 batch 稿件主動 sweep；不修則 #122 主題語意 attractor 跟 #124 emergence 違規會在同 batch 內持續累積
• 2026-05-27 跨輪 review 停止訊號是 frame 涵蓋、不是 finding 數遞減 判斷「該不該再來一輪 review」的訊號是『frame 軸是否還有未動』、不是『上一輪 finding 變少』；多輪 review 的 ROI 不是 monotonically decreasing、而是 frame 切換的質性轉換 — Round N 用新 frame 通常仍會抓出 substantial finding、但內容從 surface compliance 往深層 structural issue 走；停止訊號是「下一輪可用的新 frame 已經想不出來」、不是 finding 數遞減；本卡填補 #114 / #126 / #147 沒覆蓋的「何時夠了」判讀缺口
• 2026-06-26 Compositional Writing Composes atomic, intent-revealing, grep-friendly writing (Zettelkasten) for code comments, docs, log
• 2026-06-25 三輪審查的檢討收穫 — 工具 opinion 文章的寫作品質演進 一篇 work-log 經過三輪多視角審查（8 frame、33 findings），從 B+ 提升到 A+。記錄每輪抓到什麼、為什麼前一輪漏抓、以及哪些寫作 pattern 會在 AI 輔助寫作中反覆出現。
• 2026-06-25 文章語氣校正：恐嚇式 hook 與技術分享的邊界 「可能正在你的工具中靜默發生」是恐嚇語氣，「從一個版本錯置的經驗出發」是分享語氣。兩者的差別在於把讀者放在什麼位置——被警告的對象，還是同行的分享者。
• 2026-06-25 文章範圍漂移：從 CLI 工具到工具設計的泛化過程 一篇文章初稿聚焦在 CLI 工具的 opinion 設計，經三輪審查和作者回饋後逐步泛化到所有工具設計。記錄範圍擴展的決策點和需要同步調整的位置（title、hook、原則段、checklist、對照表）。
• 2026-06-25 主題偏移：內部系統知識洩漏到面向讀者的論述 「規則檔和 memory 系統也能傳遞教訓」是正確的技術描述，但在討論「工具應該有 opinion」的文章中偏離了主題。讀者不需要知道作者的內部系統架構，他們需要的是可遷移的工具設計原則。
• 2026-06-25 信號不是承認 — 技術寫作中的歸因語氣 「都是承認工具沒做到位的信號」把客觀的觀測訊號包裝成主觀的責任歸因。工程上，信號是提醒，不是定罪。語氣偏差會讓讀者從「可以改善」的正向心態轉為「做錯了要承認」的防禦心態。
• 2026-06-25 讀者不需要知道 — 刪除比解釋更尊重讀者 「整理目的」blockquote 告訴讀者這篇文章的寫作動機和邊界。但讀者不需要知道作者為什麼寫這篇文章——他們需要知道讀完能帶走什麼。meta 資訊（寫作動機、邊界聲明、脈絡解釋）服務的是作者的組織需求，不是讀者的閱讀需求。
• 2026-05-02 Blog 文章模板設計：作者品質閘門與正文分工 文章模板的定位與 SSoT 歸屬：模板是作者品質閘門、正文仍走技術推導、backend 正文不暴露填表結構。
• 2026-04-22 Snippet、Template、Skeleton 的差別 從一般英文與技術寫作兩個角度，整理 snippet、template、skeleton 三個常見詞的差異。