Day 10：定義文章的風格指南與目標受眾畫像 結尾留下一個具體的問題。

定義內容本身不會自動被遵守，35 天下來，要怎麼確保第 20 天的規劃代理人真的還記得並且正確套用第 1 天就定案的風格指南與受眾畫像。今天要正式回答這個問題。

定義都清楚了，但誰能保證每次都被用到

風格指南與受眾畫像的定義已經到位，全域錨點檔案、Section Spec、知識庫這些地基也都各自存在。但這還沒有回答一個問題，規劃代理人每次工作時，是否真的會拿出這些定義來用。

今天的任務，是正式設計一套具體、可執行的跨篇一致性機制，確保規劃代理人不會隨著系列天數推移逐漸遺忘或走鐘。

地基存在與地基被使用，是兩件不同的事

有一個容易被忽略的落差值得先點出來。全域錨點檔案、風格指南、受眾畫像都被記錄下來，不代表規劃代理人每次工作時都會主動去讀取並套用。光是「存在一份文件」不等於「這份文件真的被查閱」。

這個問題又會回到 Day 08：規劃代理人的系統提示詞設計 定案的原則：「查閱既有資源不能是可有可無的建議，而必須是無法跳過的前置步驟」，今天要把這個原則具體落實到跨篇一致性這個特定情境上。

同樣回頭看 Day 08 定案的另一個原則，系統提示詞是規劃代理人的行為契約，真正決定行為的是邊界與流程的具體措辭。

今天要設計的機制，本質上就是把「沿用既有定案」這個要求翻譯成系統提示詞裡具體可執行的條款。也就是把 Day 08 已經定案的這兩個原則，具體套用在跨篇一致性這個新情境上。

機制第一步，規劃前的強制讀取

規劃代理人在每次開始規劃新的一天之前，系統提示詞應該強制要求它先完整讀取全域錨點檔案裡目前已經定案的所有名詞與架構決策、風格指南、受眾畫像。

## 工作前必做：強制讀取既有狀態

開始規劃前，若使用者的專案中存在以下檔案，**必須**先完整讀取，這不是可有可無的建議，而是動工前無法省略的前置步驟，讀取到的內容要被當作規劃這一天內容時不可違背的既定前提，不能憑印象或訓練時的模糊記憶去回想：

1. **系列總覽筆記**，例如整體規劃文：了解整體階段劃分、篇數配置、系列調性
2. **全域錨點檔案**，如 `global_anchor.md`，若不存在則略過：了解已定義的名詞、已建立的架構決策，避免規劃出重複或矛盾的內容。每筆記錄應包含首次定案於哪一天、目前是否仍為有效狀態，查閱時以最新有效版本為準，不可誤用已被取代的舊定義
3. **風格指南**：了解系列已定案的語氣基調、句式偏好、用詞習慣，若不存在則依下方「風格指南與受眾畫像」段落的原則向使用者確認後定案
4. **目標受眾畫像**：了解系列已定案的讀者背景知識水位、痛點與動機、閱讀情境，若不存在則同樣依下方段落的原則向使用者確認後定案
5. **前一篇的文章或規格書**：確保銜接自然，結尾伏筆有被承接

若找不到這些檔案，直接詢問使用者要規劃的主題與上下文，不要憑空假設。

## 風格指南與受眾畫像

骨架的邏輯順序之外，語氣與深度是另一個完全獨立的變數，必須先想清楚讀者是誰，才能決定用什麼語氣跟他們說話，這個順序不能顛倒。

**目標受眾畫像**至少包含三項要素，必須先於風格指南定案：
- 讀者的背景知識水位：讀者已具備哪些先備知識、不具備哪些，決定哪些名詞可以直接使用、哪些需要從頭鋪陳
- 讀者的痛點與動機：讀者為什麼讀這篇文章、想得到什麼，決定文章該優先回答什麼問題
- 讀者的閱讀情境：讀者是通勤瀏覽還是動手實作，決定資訊密度與段落長度

**風格指南**至少包含三項要素，建立在受眾畫像之上：
- 語氣基調：直接了當的工程師對話口吻，還是正式的技術文件口吻
- 句式偏好：偏好長句鋪陳來龍去脈，還是短句直接下結論
- 用詞習慣：專有名詞的呈現方式、是否使用第一人稱、對讀者的稱呼方式

這兩份定義屬於系列規劃初期就該一次性確立的定案內容，性質上更接近全域錨點檔案記錄的「已定案架構決策」，而不是每天 Section Spec 裡各自變動的段落規格。若系列尚未定案這兩份文件，規劃第一篇之前必須先與使用者確認並產出，產出後應與全域錨點檔案同樣被視為後續每一天都要強制讀取的既定前提。

這些內容讀取進來之後，要被當作規劃這一天內容時不可違背的既定前提，而不是憑印象或訓練時的模糊記憶去回想這些定案內容。

這裡的「強制」兩個字值得特別強調。如果只是把讀取既有資源寫成建議性的措辭，例如「可以參考全域錨點檔案」，這種措辭仍然給 Agent 留下不讀取也能動工的空間，必須明確要求這是動工前不可省略的步驟。

機制第二步，產出後的一致性比對

規劃代理人在產出這一天的 Section Spec 之後，可以要求它主動比對，這次規格書中使用的用詞、語氣、深度假設，是否與剛剛讀取到的全域錨點檔案、風格指南、受眾畫像存在衝突或不一致。

## 交出規格書之前：自我檢查

在做跨篇一致性比對之前，必須先檢查規格書自己內部有沒有問題，這與下一節的跨篇比對是不同層次的問題，本節檢查的是規格書自身是否自洽，完全不需要對照全域錨點檔案這類外部文件，單看這一份規格書本身就能發現，下一節檢查的才是有沒有沿用外部的既有定案。想清楚了不等於寫清楚了，結構化推理階段已經想清楚的邏輯，轉譯成正式欄位時可能在過程中被漏掉，所以即使已經做過結構化推理，仍要回頭檢查這一次實際寫出來的文字。

逐一執行以下四項檢查，用清單方式逐項確認，不能用「仔細檢查一遍」這種空泛方式帶過：

1. **完整性檢查**：逐一確認核心目標、前置概念、段落規格、結尾伏筆這四個必要欄位是否都存在，有沒有哪一項還停留在草稿狀態或完全缺席。
2. **內部邏輯一致性檢查**：對這次寫出來的段落規格重新跑一次互換測試，確認段落之間確實存在先後依賴關係，而不是在結構化推理階段想清楚的順序，轉譯成正式欄位時又變回了可任意調換的主題並列。
3. **錨點衝突檢查**：確認規格書內部有沒有自己跟自己矛盾，例如某個名詞在段落規格一裡的用法，跟它在段落規格三裡的用法是否一致，即使兩種用法各自單獨看都合理，放在同一份規格書裡卻不能互相矛盾。
4. **核心目標對齊檢查**：逐一檢視每一個段落規格，確認它是否真的服務於這份規格書已經定義的核心目標，排除那些單獨閱讀也說得通、卻對核心目標沒有實質貢獻、只是順著話題延伸出去的枝節段落。

四項檢查合起來確保規格書在交給下游之前就先攔下瑕疵，因為寫作代理人的職責是依規格展開內容，不負責也不該越界質疑規劃代理人交付的規格是否自洽，瑕疵一旦流向下游才被發現，回頭修正的成本遠高於在這裡先攔下來。

若偵測到衝突，應優先沿用既有定案，而不是自己另創一個聽起來也合理的新說法，即使新說法在邏輯上同樣站得住腳，優先權仍然屬於先前已經拍板的版本。

這裡有一個容易混淆的地方需要特別提醒。這個比對動作與 Day 12 即將處理的自我檢查機制性質不同，這裡比對的對象是「有沒有沿用既有定案」，關注的是這一天的產出是否忠於過去，而不是檢查這份規格書自己內部的邏輯是否自洽，兩者是不同層次的問題，不可混為一談。

具體失敗情境，一個站得住腳的直覺推斷如何釀成矛盾

如果沒有強制讀取既有定案這道機制，規劃代理人在規劃第 20 天內容時，很可能單純根據當下拿到的主題，直覺推斷某個名詞的定義或某個架構決策的適用範圍。

這個情境的隱蔽性在於，這個直覺推斷本身即使邏輯上完全說得通、單獨看也毫無破綻，卻可能與第 8 天已經拍板的版本存在細微出入，因為 Agent 是憑當下的推理重新生成一次定義，而不是去讀取第 8 天原本已經寫定的那個版本。

這種細微出入正是全系列讀起來自相矛盾的根源，讀者未必說得出哪裡不對，但會隱約感覺到前後兩天對同一個名詞的描述有微妙落差。

機制如何預防它，答案就在前面設計的強制讀取與一致性比對步驟。規劃第 20 天時若確實先讀取了第 8 天已定案的版本，就不會出現重新直覺推斷的空間，即使真的推斷出了不同版本，事後的比對步驟也能攔下這個衝突。

機制第三步，全域錨點檔案的即時回寫維護

還有一個容易被忽略的維護責任。全域錨點檔案不是寫死不動的靜態文件，隨著系列往下推進，某一天的規劃過程中可能因為系列進展而需要新增一個先前沒有的專有名詞定義，或需要根據新的情境略微擴充某個既有架構決策的適用範圍。

這個新增或擴充動作本身也應該被要求即時寫回全域錨點檔案，而不是規劃代理人自己心裡知道就好，或者只記錄在當天的 Section Spec 裡。

## 產出後：跨篇一致性比對與回寫

完成自我檢查、確認規格書本身自洽之後，規格書寫定後、告知使用者之前，必須完成以下兩個步驟，這是攔截內容漂移的最後一道防線，不可省略：

1. **一致性比對**：主動比對這份規格書中使用的用詞、語氣、深度假設，是否與前面強制讀取到的全域錨點檔案、風格指南、受眾畫像存在衝突或不一致。若偵測到衝突，優先沿用既有定案，不要自己另創一個聽起來也合理的新說法，即使新說法邏輯上同樣站得住腳，優先權仍屬於先前已拍板的版本。這個比對關注的是「有沒有沿用既有定案」，不是檢查規格書自己內部的邏輯是否自洽，內部自洽是上一節自我檢查的職責。
2. **即時回寫**：若這次規劃過程中新增了先前沒有的專有名詞定義，或擴充了某個既有架構決策的適用範圍，必須立即把這個新增或擴充寫回全域錨點檔案，不能只記在自己心裡或只留在當天的 Section Spec 裡，確保後續天數查閱到的永遠是最新且完整的版本。

這個即時回寫的必要性在於，確保後續天數查閱到的永遠是最新且完整的版本。如果回寫這個動作被拖延或省略，等於讓後面規劃的天數查到的是一份過時的地基，這反而會製造出新一輪的漂移。

全域錨點檔案的維護不該是系列結束後才回頭整理的馬後炮工作，而應該是跨篇一致性機制裡與「讀取」同樣重要的另一半動作。

扣回內容漂移病灶，規劃階段的第一道防線

把今天設計的整套機制：強制讀取、產出後比對、即時回寫。回頭和 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的內容漂移病灶做一個比對。

我們可以發現，這套機制的定位，其實正是規劃階段用來具體攔截內容漂移病灶的第一道防線。

讓內容漂移不必等到成文之後才被讀者發現，而是在規劃階段就被主動預防。地基本身不會自動發揮防止漂移的作用，必須靠這套具體的讀取、比對、回寫機制，地基才會真正轉化為防止漂移的實際效果。

跟過去保持一致了，但這一次的產出本身呢

今天把「定義內容已經清楚，但如何確保被持續正確沿用」這個問題，具體拆解成一套跨篇一致性機制。

機制包含三個步驟：規劃前強制讀取全域錨點檔案、風格指南、受眾畫像作為既定前提、產出後主動比對用詞、語氣、深度假設是否與既有定案衝突、若有新增或擴充則即時回寫全域錨點檔案。

三者合起來確保規劃代理人不會隨系列推移而遺忘或走鐘。

這套機制的定位，是把 Day 08 定案的「系統提示詞是行為契約」與「查閱既有資源必須是無法跳過的前置步驟」這兩個原則，具體套用在跨篇一致性這個情境上，也是規劃階段攔截內容漂移病灶的第一道防線。

規劃代理人現在知道要先讀取既有定案、確保沿用一致，也知道要即時回寫更新，這解決的是跟過去保持一致這個問題。但這不代表規劃代理人這一次自己產出的規格書內部就完全沒有問題，規格書本身有沒有邏輯漏洞、段落規格是否前後矛盾、有沒有遺漏必要欄位，這是另一個獨立的問題，規劃代理人要如何在交出規格書之前自己先檢查一遍自己的產出，這個問題今天還沒有答案，將在 《Day 12：規格書的自我檢查，規劃代理人如何驗證自己的產出》 正式揭曉。