《Day 07：知識庫的切分藝術，保留程式碼與上下文的完整性》 結尾留下一個具體的問題。規劃代理人這個角色具體要怎麼被設計出來，它的系統提示詞要怎麼寫，才能讓它確實依循系統地基的所有工作。今天終於要動工回答這個問題。

地基蓋完了，第一個 Agent 終於要動工

系統地基三塊拼圖：Section Spec、全域錨點檔案、知識庫，都已經到位，這是今天要打造的規劃代理人接下來會實際依賴的基礎設施。地基蓋完了，接下來要做的事很明確，規劃代理人這個角色具體要怎麼被設計出來。答案的核心是系統提示詞，今天要正式討論這份提示詞該怎麼寫。

系統提示詞是什麼，一份行為契約

先破除一個容易帶著走的直覺印象。系統提示詞不單單只是隨口一句「你是一個資深編輯」這種身分宣告。很多人寫系統提示詞時止步於此，以為講清楚身分就足夠。

系統提示詞真正扮演的角色，是一份行為契約。

它決定這個 Agent 遇到各種情境時會做什麼、不會做什麼，身分只是契約裡最表面的一條款項，真正決定行為的是邊界與流程的具體措辭。

系統提示詞設計的核心困難，不是寫不出來，而是寫得不夠精確。一份看似完整的系統提示詞，實際運作時 Agent 依然可能在模糊地帶做出不符預期的行為，這正是今天要深入處理的問題。

規劃代理人的角色設定，身分、資源、範圍

先重申 Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 已經定案的規劃代理人職責邊界，它只產出結構化規格，不撰寫任何一句會出現在成品中的正文，也不查證任何技術細節的正確性。這條邊界今天不重新論證，直接沿用。

規劃代理人的系統提示詞，至少要包含三項角色設定要素。

身分定位：規劃代理人在系統提示詞裡應該被明確告知自己站在編輯的位置，任務是把主題、系列定位、天數等輸入轉化為結構化產出規格，這與 Day 03 的描述一致。

可存取的既有資源：系統提示詞應該明確列出規劃代理人被授權查閱哪些既有資源，也就是全域錨點檔案與知識庫。全域錨點檔案提供已定案的結論，知識庫提供可查證引用的原始素材，兩者各自的作用要在系統提示詞裡點清楚。

任務範圍：系統提示詞應該明確界定規劃代理人的產出物是什麼形式，也就是 Day 04：規劃代理人的產出介面，認識 Section Spec 定案的 Section Spec 這種結構化規格書，而不是一份文章草稿或大綱式條列。

這三項要素合起來，構成規劃代理人系統提示詞的骨架。但骨架本身還不足以確保 Agent 真正守住邊界，這正是下一節要處理的問題。

邊界的措辭陷阱，名義上知道不等於真正遵守

想像一個失敗案例。如果系統提示詞只簡單寫著「請規劃一篇文章的大綱」，Agent 在規劃段落安排時，很容易在描述某一段的重點時，不小心多寫了一兩句像是會直接出現在成品裡的完整句子，而不是停留在規格層級的重點描述。這種夾帶不是 Agent 刻意違規，而是指令本身沒有劃出清楚的停止線。

這種失敗的根因並不難理解。

模糊的指令，例如「規劃大綱」「列出重點」，並沒有明確區分「描述這一段要談什麼」與「寫出這一段的內容本身」這兩件事的邊界。對 Agent 而言，這兩種輸出在語言形式上非常接近，一段清楚的重點描述與一段簡短的正文草稿，有時候差別只在於語氣與完整度，指令如果沒有明確要求，Agent 很容易滑向後者。

對比來看，模糊的指令傾向直接要求產出結果，例如「規劃這一段」。明確的指令則會具體要求產出的形式本身，例如要求每一段只能用條列的重點描述呈現，並且明確禁止出現任何完整、可直接沿用的句子或段落，甚至可以要求規劃代理人只能用「這一段要論證什麼」而不是「這一段寫了什麼」的語氣來表達。

這條原則背後有一個更普遍的道理，行為邊界要真正被遵守，系統提示詞裡就必須把邊界翻譯成具體、可執行、可檢查的格式規則，而不是停留在抽象的職責宣告。一句「不要寫正文」對 Agent 來說仍然是模糊的，因為它沒有回答「什麼樣的輸出才算正文」這個實際問題。

查閱既有資源的強制動作，避免規格憑空杜撰

還有另一種常見的失敗模式值得討論。如果系統提示詞沒有明確要求規劃代理人查閱既有資源，Agent 很容易單靠自己對主題的既有理解直接產出規格。這種規格可能與系列已經定案的名詞或架構決策衝突，也可能引用了實際上不存在或已經過時的技術細節，卻用肯定的語氣寫進規格書裡。

系統提示詞應該把「查閱既有資源」設計成一道明確、無法跳過的前置步驟，而不是一項可有可無的建議。具體來說，規劃代理人在產出任何規格之前，應該被要求先確認這次要處理的主題是否涉及全域錨點檔案裡已經定案的名詞或架構，若涉及則必須沿用既有定義，不得另創同義詞或調整語意。

同樣地，系統提示詞應該要求規劃代理人在規格書裡標註參考自知識庫的哪些既有素材，確保後續要求的程式碼案例方向或比喻方向，都有實際依據可循，而不是憑空杜撰一個聽起來合理但實際不存在的技術細節。

這正是 Day 04：規劃代理人的產出介面，認識 Section Spec、Day 05：系列的單一事實來源，打造全域錨點檔案、Day 06：從筆記到知識庫，素材的收集與初步整理、Day 07：知識庫的切分藝術，保留程式碼與上下文的完整性 建立的系統地基被規劃代理人實際使用的方式。

地基本身不會自動發揮作用，必須靠系統提示詞明確要求規劃代理人主動查閱，這三塊拼圖才會真正被整合進規劃代理人的日常工作流程裡，而不是被晾在一旁的裝飾性文件。

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

今天把規劃代理人的角色設定與行為邊界，落實成系統提示詞設計的具體方法論。

系統提示詞是規劃代理人的行為契約，角色設定要包含身分定位、可存取的既有資源、任務範圍這三項要素。而「只產出規格、不撰寫正文」這條邊界要真正被遵守，必須翻譯成具體、可執行、可檢查的格式規則，不能停留在抽象的職責宣告。同時系統提示詞必須把查閱全域錨點檔案與知識庫設計成一道無法跳過的前置步驟，系統地基才會真正被整合進規劃代理人的日常工作流程，而不是被晾在一旁的裝飾性文件。

規劃代理人現在知道自己該做什麼、不該做什麼，也知道要先查閱哪些既有資源才能動工。但光有清楚的邊界，不代表它就知道「如何」把一個主題實際推理、組織成一份結構清晰的大綱骨架，這個「如何思考、如何產出結構」的具體方法，今天還沒有答案，將在 《Day 09：運用結構化推理模式產出大綱骨架》 正式揭曉。