Day 09：運用結構化推理模式產出大綱骨架 結尾留下一個具體的問題。同一份邏輯清楚的骨架，配上不同的語氣、深度、受眾假設，寫出來的東西可能天差地遠。

今天要正式回答，規劃代理人要怎麼確保系列讀起來一致，這個問題。

骨架清楚了，但讀起來還是不像同一個人寫的

現在我們的邏輯骨架已經到位，規劃代理人知道如何先梳理邏輯、再產出結構。

但這還沒有回答一個問題：同一份骨架配上不同的語氣、深度、受眾假設，寫出來的東西為什麼可能天差地遠。

今天的任務，是正式定義風格指南與目標受眾畫像該包含哪些具體要素，讓語氣與深度也能像邏輯骨架一樣被清楚地規劃，而不是憑當下感覺決定。

骨架之外的變數，語氣與深度

想像一個對照畫面。把同一份邏輯清楚的大綱骨架，分別交給兩種截然不同的語氣去撰寫，一種用直接了當的工程師對話口吻，一種用正式生硬的技術文件口吻。兩篇文章的論證順序完全相同，但讀起來像是兩個不同的作者，甚至像是被硬塞進同一個系列裡的外來文章。

這個現象背後的原因不難理解。邏輯骨架決定的是論證的先後順序與因果關係，但沒有決定用什麼語言方式呈現這個順序，也沒有決定假設讀者已經知道多少背景知識。語氣與深度是骨架之外一個完全獨立的維度。

把這個問題扣回 Day 09：運用結構化推理模式產出大綱骨架，結構化推理處理的是邏輯骨架這個維度，今天要處理的是語氣與深度這個維度，兩者合起來才能讓一份 Section Spec 真正具備跨天一致的完整品質。邏輯骨架清楚只是必要條件，不是充分條件。

風格指南該包含哪些要素

風格指南至少要包含三項要素。

語氣基調：系列整體要採用直接了當的工程師對話口吻，還是正式的技術文件口吻。這個選擇會決定讀者感受到的距離感，是像同事在旁邊講解，還是像在讀一份規範文件。

句式偏好：系列是偏好用長句鋪陳論證的來龍去脈，還是偏好用短句直接下結論。這個偏好會影響讀者閱讀時的節奏感，也會影響同一個論證讀起來是綿密還是俐落。

用詞習慣：包含專有名詞該用什麼方式呈現，是否使用第一人稱敘事，以及對讀者的稱呼方式。這些細節單獨看很瑣碎，但一旦某幾天悄悄改變了習慣，讀者會立刻察覺語氣不對勁。

這三項要素合起來，構成了「用什麼樣的語言方式說話」的完整輪廓。但語氣要對誰說話，還需要先知道說話的對象是誰，這正是接下來要談的受眾畫像。

目標受眾畫像該包含哪些要素

目標受眾畫像的部分，同樣至少要包含三項要素。

讀者的背景知識水位：讀者已經具備哪些先備知識、不具備哪些，這決定了哪些名詞可以直接使用不必解釋，哪些概念需要從頭鋪陳。缺少這項定義時，規劃代理人很容易忽高忽低地假設讀者的程度。

讀者的痛點與動機：讀者為什麼會讀這篇文章、想從中得到什麼，這決定了文章該優先回答讀者最在意的問題，而不是作者自己覺得有趣的細節。

讀者的閱讀情境：讀者是通勤時快速瀏覽，還是坐下來動手實作，這決定了文章該用什麼樣的資訊密度與段落長度呈現。通勤瀏覽需要更快能抓到重點的節奏，動手實作則需要更完整可跟著操作的細節。

這三項要素合起來，構成了「讀者是誰、需要什麼」的完整輪廓，這正是決定風格指南該怎麼設計的前提。

兩者的因果關係，先知道讀者是誰，才能決定怎麼說話

受眾畫像回答的是「讀者是誰、需要什麼」，風格指南回答的是「用什麼樣的語言方式對這樣的讀者說話」。兩者不是互相獨立、可以各自隨意決定的兩份文件。

這個因果先後順序值得說清楚，受眾畫像某種程度上決定了風格指南該怎麼設計。如果讀者的背景知識水位偏低，語氣基調就該更貼近口語、句式該更短更直接；如果讀者已經是熟手，語氣就可以更精煉、允許更高密度的專有名詞。

把這個順序扣回 Day 02：產出優先思維，先定義規格再動筆 定案的產出優先思維，先定義讀者、論點與產出規格的順序原則，受眾畫像正是「先定義讀者」這個環節的具體展開。

風格指南必須建立在這個環節之上，而不是先憑感覺定調語氣，再回頭找理由解釋為什麼這樣寫適合讀者。

必須先想清楚讀者是誰，才能決定用什麼語氣跟他們說話，這個順序不能顛倒。這也是為什麼本篇把受眾畫像的定義放在風格指南之後說明，但實際規劃時的思考順序應該是先受眾、後風格。

誰來定義、何時定義，一次性確立而非每天重新決定

風格指南與受眾畫像應該在系列規劃初期就一次性確立，而不是每天由規劃代理人重新臨時決定。理由是受眾與風格是整個系列的定位問題，而不是單篇文章的個別決定，如果每天都重新決定一次，等於放任每天各自漂移的風險。

回頭看 Day 05：系列的單一事實來源，打造全域錨點檔案 定案的全域錨點檔案，一份記錄系列中所有已定義專有名詞與已定案架構決策的獨立檔案，作為所有 Agent 共享的單一事實來源。

風格指南與受眾畫像本質上也是一種需要跨天沿用的定案結論，適合被記錄在類似全域錨點檔案這樣的共享地基裡，供所有天數的規劃代理人查閱引用。

這意味著風格指南與受眾畫像在概念上更接近全域錨點檔案記錄的「已定案架構決策」這一類內容，而不是每天 Section Spec 裡各自變動的段落規格。

沒有清楚定義會發生什麼，內容漂移的另一種面貌

想像一個畫面，同一個系列裡，某幾天的文章突然改用比較生硬的「總而言之」「值得注意的是」這類制式套話，讀者讀到這裡會隱約感覺到這幾天像是換了個人寫。再想像另一個畫面，某一天忽然假設讀者已經具備某個從未解釋過的先備知識，直接跳過本該有的鋪陳，讀者會感到困惑，覺得自己是不是漏讀了哪一篇。

把這兩個畫面扣回 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的內容漂移病灶，這正是內容漂移病灶在語氣與受眾假設這個維度上的具體體現，而不只發生在論證深度這個維度。先前討論的內容漂移多半聚焦在邏輯或論點層級，本篇補上的是語氣與受眾假設同樣會漂移，而且這種漂移往往比邏輯漂移更容易被讀者直覺察覺。

這正是為什麼風格指南與受眾畫像，值得被鄭重定義，而不是留給每天的規劃代理人臨時發揮。

語氣與受眾都有定義了，但要怎麼確保每天都記得

今天把「邏輯骨架之外還有什麼變數」這個問題，具體拆解成風格指南與目標受眾畫像兩份定義。同一份邏輯清楚的骨架，配上不同的語氣、深度、受眾假設，讀起來可以像是完全不同的作者所寫，這是結構化推理處理的骨架維度之外，另一個獨立但同樣關鍵的維度。

風格指南定義語氣基調、句式偏好、用詞習慣，受眾畫像定義背景知識水位、痛點與動機、閱讀情境，兩者存在因果先後關係，必須先想清楚讀者是誰，才能決定用什麼語氣跟他們說話。

這兩份定義該在系列規劃初期一次性確立，而非每天臨時決定，也適合被記錄在類似全域錨點檔案這樣的共享地基裡。

風格指南與受眾畫像現在都有清楚的定義內容了。

但定義內容本身不會自動被遵守，35 天下來，要怎麼確保第 20 天的規劃代理人真的還記得，並且正確套用第 1 天就定案的這份風格指南與受眾畫像，而不是隨著時間推移逐漸遺忘或走鐘，這個問題今天還沒有答案，將在 《Day 11：避免內容漂移，跨篇一致性的機制設計》 正式揭曉。