Day 08：規劃代理人的系統提示詞設計 結尾留下一個具體的問題。規劃代理人具備清楚的邊界與可查閱的既有資源之後，具體要如何思考，才能把一個主題組織成一份結構清晰的大綱骨架。

今天要正式回答這個問題。

邊界清楚了，但還不知道怎麼想

邊界與資源都已經寫進系統提示詞，規劃代理人知道自己該做什麼、不該做什麼，也知道要查閱哪些既有資源。但這些都還沒有回答一個更根本的問題，拿到一個主題之後，具體要怎麼一步步想，才能想出一份結構清晰的大綱骨架。

今天的任務，就是拆解規劃代理人應該如何先梳理邏輯、再產出結構，而不是直接跳到條列式的大綱。

大綱淪為關鍵字排列的樣貌

不少人可能有過這樣的經驗。如果要求 AI 工具「直接列出這篇文章的大綱」，很容易只是把主題相關的關鍵詞或子主題掃過一輪，用條列的方式排出幾個看起來合理的標題。

這種大綱有明顯的症狀，標題與標題之間彼此獨立，看不出論證的先後順序或因果關係。讀者讀完大綱只知道這篇文章涵蓋哪些主題，卻看不出這篇文章要證明什麼、怎麼證明。

有一個簡單的自我檢查角度可以馬上驗出這種症狀，如果把這份大綱的任兩個標題順序互換，讀起來依然通順、依然成立，這正是關鍵字隨意排列的明顯特徵，而不是邏輯先行的結構。

這種大綱不是完全沒用，它至少完成了主題覆蓋，讀者知道這篇文章大概會談到哪些東西。

但，這遠遠不夠。

隨意排列的根本問題，思考被跳過去了

根本問題在於，這種大綱只完成了主題覆蓋，沒有完成邏輯先行於結構這個更關鍵的工作。如果規劃代理人在還沒想清楚論證脈絡之前就直接產出結構，等於把應該屬於思考階段的工作，跳過去直接變成排版階段的工作。

這種被跳過的思考工作不會憑空消失，它會轉嫁給下游的寫作代理人。寫作代理人又必須自己在撰寫過程中重新補上規劃代理人本該想清楚的邏輯關係，這等於讓規格書失去了它原本該有的價值，寫作代理人拿到的雖然是一份 Section Spec，但實際上還要做一次規劃代理人沒做完的功課。

把這個問題扣回 Day 02：產出優先思維，先定義規格再動筆 所說的產出優先思維，可以往內遞迴一層看得更清楚。這正是產出優先思維在規劃代理人內部工作方式上的具體實踐。

產出優先思維原本談的是先定義規格、再回推資料的工作順序，這個順序原則同樣適用在規劃代理人自己內部的思考流程，規劃代理人自己也應該先確立這篇文章要證明的目標與支撐目標的論證邏輯，再產出最終的結構化格式，而不是反過來先把結構套出來，再回頭東拼西湊邏輯。

解法，結構化推理作為梳理邏輯的橋樑

解法是，要求規劃代理人在產出最終的 Section Spec 之前，先用一段簡短的論證脈絡描述，把這篇文章要證明的核心論點、支撐這個論點需要的論證順序、每個論證環節彼此之間的因果或遞進關係梳理清楚。

## 輸出規格書之前：先做結構化推理

在寫出任何一行規格書之前，必須先用一段簡短的論證脈絡描述，把這篇文章的邏輯骨架梳理清楚。這段推理不是正式的規格書格式，不具備「必要規格元件」「參考素材」等欄位，純粹是你自己內部想清楚的過程，具體要梳理：

1. **核心論點**：這篇文章最終要讓讀者接受的主張是什麼，必須是一句明確、可被檢驗的陳述，不能只是模糊的主題範圍，例如「某個技術能解決什麼具體問題」或「為什麼某種做法優於另一種做法」，而不是「介紹某個技術」。
2. **支撐前提**：要讓讀者接受這個核心論點，必須先被說服哪些較小的子論證，這些子論證就是構成規格元件的積木。
3. **排列順序**：這些子論證，也就是規格書中的場景鋪陳、程式碼要求、對比表格等元件，該用什麼順序排列才能讓讀者一步步被說服，環環相扣，而不是彼此獨立、可任意並列的主題清單。

梳理完成後，用互換測試驗證邏輯是否先行於結構，自問：如果把規格元件中任兩個項目的順序互換，這篇文章的論證還能不能成立。如果調換完全不影響閱讀理解，代表這兩個項目只是主題並列而非邏輯遞進，必須回頭重新梳理順序；如果調換會讓後面的元件引用了還沒被建立的前提，讀者會感到困惑或跳躍，這才是真正具備邏輯先行性質的骨架。

這段推理脈絡完全服務於規格書的品質，本身不會出現在最終成品中，也不需要、不應該被寫進上方任何一個正式欄位裡。

這個中間產出的性質值得說清楚，它不是正式的 Section Spec 格式本身，不需要具備核心目標、前置概念、段落規格等正式欄位。它是介於「拿到主題」與「產出結構化規格」之間的一道橋樑，形式上可以只是一段簡短的推理過程描述。這裡姑且用「結構化推理」這個說法稱呼這個工作方式，理解其精神即可，不需要拘泥於固定措辭。

有了這一道橋樑，規劃代理人才不會在還沒想清楚之前就急著排版。接下來要具體拆解，結構化推理實際上要梳理哪些東西。

具體要梳理什麼，論點、前提、順序

第一件要梳理的事，這篇文章最終要讓讀者接受的核心論點是什麼。這個核心論點應該是一句明確、可被檢驗的主張，而不是一個模糊的主題範圍。核心論點不會只是「介紹某個技術」，而應該是「某個技術能解決什麼具體問題，或者為什麼某種做法優於另一種做法」這樣可被論證的主張。

第二件要梳理的事，支撐這個核心論點需要哪些前提或子論證，也就是讀者要先被說服哪些較小的主張，才有可能接受最終的核心論點。這些子論證是構成整篇文章骨架的積木。

第三件要梳理的事，這些子論證之間該用什麼順序排列才能讓讀者一步步被說服，而不是隨機排列也能成立。順序的設計原則可以是先建立讀者認同某個前提，再用這個前提推導出下一個子論證，環環相扣，而不是把各自獨立、彼此平行的主題並列擺放。

把核心論點、支撐論點的前提、前提之間的順序都想清楚之後，才輪到把這些內容轉譯成 Section Spec 裡的段落規格，順序不能顛倒。

如何驗證邏輯先行，互換測試

這裡有一個具體、可操作的驗證方法。規劃代理人產出大綱骨架之後，可以自問：如果把其中任兩個段落的順序互換，這篇文章的論證還能不能成立。

這個測試背後的判斷邏輯很直接。如果調換順序完全不影響閱讀理解，讀者依然能順暢地讀完整篇文章，這通常代表這兩個段落之間只是主題並列，而不是邏輯遞進，這正是需要被修正的警訊。

對比來看，真正具備邏輯先行性質的大綱應該有的樣貌是，如果調換某兩個段落的順序會導致後面的段落引用了還沒被建立的前提，讀者會感到困惑或跳躍，這種「互換會出問題」的狀態，反而證明了段落之間存在真正的依賴關係與先後順序。

這個測試不需要是一套正式的檢查清單流程，而是規劃代理人在完成大綱骨架後，可以逐一針對每一組相鄰段落快速自問的簡單動作，用來抓出那些看似合理、實際上只是關鍵字並列的段落安排。

職責邊界釐清，推理脈絡不進成品也不進規格欄位

這裡有必要重申 Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 定案的規劃代理人職責邊界，它只產出結構化規格，不撰寫任何一句會出現在成品中的正文。

今天要明確定義結構化推理這個中間步驟，在這條邊界裡的位置。

結構化推理依然完全發生在規劃代理人內部，它的產出是規劃代理人用來確保自己交出的 Section Spec 具備邏輯骨架的內部工作過程，這段推理脈絡本身不是文章正文的一部分，不會出現在最終成品裡。

同樣地，這段推理脈絡也不需要被正式寫進 Section Spec 的某個欄位裡。Section Spec 是規劃代理人與寫作代理人之間交接的正式介面，交接的內容是梳理完畢之後的結構化結果，而不是梳理過程本身，兩者不應該混為一談，否則會讓 Section Spec 這個介面的格式邊界變得模糊。

結構化推理是規劃代理人交出高品質規格之前，自己內部先想清楚的過程，它服務於規格的品質，但它本身不是規格的一部分，這條界線劃清楚，才不會讓職責邊界再度變得模糊。

骨架邏輯清楚了，但語氣還沒統一

今天把規劃代理人「先梳理邏輯、再產出結構」這個工作方式，具體拆解成可操作的方法論。

一份只完成主題覆蓋的大綱，標題與標題之間彼此獨立，看不出論證的先後順序或因果關係，這樣的大綱把應該屬於思考階段的工作，跳過去變成了排版階段的工作，最終這筆債會轉嫁給下游的寫作代理人。

解法是結構化推理，要求規劃代理人在產出最終 Section Spec 之前，先梳理清楚這篇文章要證明的核心論點、支撐論點的前提或子論證、以及子論證之間該有的排列順序，這正是產出優先思維在規劃代理人內部工作方式上的具體實踐。互換任兩個段落的順序是否依然成立，是檢驗一份骨架是否真的邏輯先行的簡單測試，而這段推理脈絡本身完全發生在規劃代理人內部，不會出現在成品裡，也不會寫進 Section Spec 的正式欄位。

規劃代理人現在知道如何先梳理邏輯、再產出一份骨架清楚的大綱。但同一份邏輯清楚的骨架，配上不同的語氣、深度、對讀者背景知識的假設，寫出來的東西可能天差地遠，規劃代理人要怎麼確保自己每次規劃出來的深度與語氣是系列一致的，這個問題今天還沒有答案，將在 《Day 10：定義文章的風格指南與目標受眾畫像》 正式揭曉。