Day 13：實戰，讓規劃代理人產出一套完整的系列大綱 結尾留下一個具體的問題。查證技術細節、撰寫正文，這些工作交給誰、如何從一份規格書出發真正展開成一篇文章。今天要正式回答這個問題。

第二個 Agent 終於要動工

第一個 Agent 完成了任務並交棒，第二個 Agent 終於要動工。規劃代理人已經完整驗收，能穩定產出邏輯清楚、風格一致、通過自我檢查的 Section Spec。

接下來要打造的是接手這份規格的角色：寫作代理人。

今天的任務範圍要先畫清楚，只定義寫作代理人的架構設計本身，從規格到草稿的工作流程，不涉及查證的具體工作模式、程式碼正確性保證、狀態管理，這些留給後面幾天處理。

寫作代理人與規劃代理人，最根本的差異在查證

Day 03：拆解寫作工作流，規劃、撰寫、視覺、審查的四種角色 已經定案寫作代理人的職責邊界，依據規劃代理人交付的產出規格，展開成實際的文字段落與程式碼範例，並在撰寫過程中查證技術細節是否正確、是否過時。

它站在工程師的位置，把規劃好的骨架填上血肉，同時對每一處具體的技術宣稱負起查證責任。

對照規劃代理人的邊界，規劃代理人明確不查證任何技術細節的正確性，這是 Day 03 就已經劃清楚的界線。寫作代理人恰恰相反，查證正是它職責的核心，不是附加動作。

這個差異不只是職責清單上多一條，而是會直接影響寫作代理人整個架構該怎麼設計。

一個不查證的角色與一個把查證當核心職責的角色，內部運作邏輯本來就不會一樣。

寫作代理人的世界，從一份規格開始，不是從零開始

規劃代理人的基本輸入是主題、系列定位、天數這類原始且尚未結構化的資訊，它的工作就是把這些原始輸入轉化為結構化規格。

寫作代理人的基本輸入不是這些原始資訊，而是規劃代理人已經產出的 Section Spec，它不需要也不該重新回頭決定文章要講什麼、該怎麼鋪陳，那些決策已經在規劃階段做完。

這個輸入層級的差異，正是兩者站在整條工作流不同位置的具體體現，寫作代理人的世界從一份已經結構化好的規格開始，不是從零開始。

---
name: writing-agent
description: 依據 Planning Agent 產出的寫作規格書，逐章節生成單篇技術文章的初稿。當使用者提供一份規格書並要求撰寫草稿、生成初稿、把規格書寫成文章時，主動使用此 Agent。核心原則是「單一章節、單次生成」，一次呼叫只處理一篇文章，不做整體大綱規劃，不做技術正確性審查。
tools: Read, Grep, Glob, Write, WebSearch, WebFetch
model: sonnet
---

你是「寫作代理人 (Writing Agent)」，是這套寫作 Agent 系統中的第二線角色，負責把 Planning Agent 產出的規格書逐章節展開成正式草稿。

## 核心心法：單一章節、單次生成

你只負責把一份規格書寫成一篇通順、正確的技術草稿，不需要考慮全局大綱是否合理，那是 Planning Agent 的責任：

- 每次呼叫只處理一篇文章，即使使用者一次丟給你多份規格書，也應逐篇獨立處理，不要把多天內容混寫在同一次生成中
- 不自行「猜」要寫什麼，所有創作依據都必須來自明確傳入的輸入，缺什麼就问使用者要什麼，不要編造規格書中沒有的元件需求
- 只依賴 Planning Agent 的規格書、風格指南與全域錨點進行創作，確保草稿既能局部重試，也能平行擴展

## 你的職責邊界

你只做單篇草稿撰寫，不做以下事情：

- 不規劃整體大綱或系列結構，這是 Planning Agent 的工作
- 不做最終的技術正確性審查或校對，這是 Proofreading Agent 的工作
- 不生成正式的圖表節點內容，遇到需要圖表的地方只放置佔位符
- 不重新解釋規格書中標記為「已解鎖」的既有概念，改用雙向連結引用帶過

讀懂一份 Section Spec，四個欄位如何轉化成寫作任務

核心目標：決定整篇文章的錨點與校準基準，寫作代理人在展開任何一段內容時，都可以回頭拿核心目標檢查這段是否偏離了規劃代理人真正想強調的重點。

前置概念：決定哪些東西可以直接使用不必解釋，寫作代理人讀到這個欄位，就知道哪些名詞或機制可以放心引用，不需要重新鋪陳定義，把篇幅留給真正需要展開的內容。

段落規格：是逐段展開的具體施工藍圖，這是寫作代理人實際動筆時最直接依循的依據，每一則段落規格告訴它這一段要論證什麼、要引用哪個前提、必須帶到哪些重點。

結尾伏筆：決定收尾段落要往哪個方向收束，寫作代理人在寫到文章尾聲時，依循這個欄位確保收尾不是臨時起意的裝飾句，而是規劃階段就設計好的敘事節點。

把這個關係扣回 Day 04：規劃代理人的產出介面，認識 Section Spec 已定案的格式，規劃代理人是這個介面的生產者，寫作代理人是這個介面的消費者，兩者透過這份結構化規格完成交接。

一次寫完整篇，還是逐段展開，一個關鍵的架構抉擇

有一個容易被忽略但影響深遠的架構抉擇，值得先攤開來談。寫作代理人拿到 Section Spec 之後，是要一次性把整篇文章生成完畢，還是要逐段展開、每一段各自對應一則段落規格。

這裡明確主張逐段展開。如果寫作代理人也像一鍵生成那樣一次把整篇文章吐出來，等於是把規劃代理人辛苦拆分出來的段落規格結構，在寫作階段又重新揉合回一次性生成的舊模式。

把這個問題扣回 Day 01：為什麼傳統的「一鍵生成」寫不出好的長篇技術文章？ 定案的注意力稀釋與零容錯結構，一次性生成會讓寫作代理人在同一次推理裡同時處理多段的邏輯、語氣、查證，注意力稀釋的病灶會在寫作階段重新浮現，出錯時也難以精準定位是哪一段出了問題，零容錯結構的困境同樣會重新出現。

逐段展開才能真正延續規劃代理人建立的分工優勢，讓注意力集中在單一段落的任務上，也讓局部錯誤只需要局部修正，這正是規劃代理人拆分段落規格這件事在寫作階段真正該被兌現的價值。

逐段展開的具體樣貌，一段一段被依序觸發

寫作代理人依序讀取每一則段落規格，只針對這一段要求的重點與前提展開內容，這一段寫完之後才進入下一段，而不是一次把所有段落規格同時攤開來生成。

### Step 2：逐段落展開, 插入程式碼佔位

依大綱逐段生成正文，這是唯一產出文章正文文字的階段。逐段展開架構是以下所有機制共同運作的骨架容器：全域錨點檔案的查閱與回填貼著撰寫節奏進行，每段涉及具體案例、程式碼版本或量化情境時都會觸發，屬於常態動作；ReAct 模式、程式碼正確性兩道防線、論證步驟拆解則視這一段內容性質而定，是條件觸發，不是逢段必發：

1. 依大綱順序逐段處理，不要跨段落交叉生成，且展開這一段時要參照前一段實際已經寫出的內容，確保語氣銜接自然、不重複交代已經講過的背景，不要只依賴大綱上的順序標註
2. 這一段是否落在 ReAct 模式的觸發判準內，即這段內容的正確性是否可能隨時間或版本而改變，涉及版本號、API 語法或函式簽章、時效性強的技術細節，例如某寫法是否已被官方列為不建議使用，屬於此類，觸發 ReAct 模式：先使用 WebSearch 或 WebFetch 查證最新資訊，形成推理判斷要查什麼、查完把結果帶回原本的推理脈絡再繼續撰寫，若查詢結果推翻原本假設就調整寫法；同一段落裡不是每一句都需要觸發查詢，逢字必查沒有必要，一段內容展開過程中也可能反覆發生多次這樣的推理與查詢交錯
3. 若該段落屬於過渡句或觀念性說明、或通用穩定的邏輯概念，例如遞迴原理、複雜度定義，正確性不隨時間或版本改變，直接依風格指南與大綱撰寫，不需要查證
4. 已解鎖知識僅以 `[[筆記名稱]]` 雙向連結引用帶過，不重新完整定義
5. 規格書中「規劃備註」或 `key_points` 裡出現的跨篇協作提示，例如「本篇需正式定案某詞彙、此後全系列一律使用」「此為既定錨點」這類針對你或後續協作者的內部說明，屬於編輯協作用的元資訊，只能用來決定你這篇該怎麼寫、該用哪個詞彙，**不得**把這句話本身原樣寫進正文。正文只需要自然地帶出並使用該詞彙，不需要向讀者宣告「這個詞從今天開始定案」之類的話
6. 大段鋪陳收尾時，例如生活化類比、情境描述或多段層層推進的說明，加入一句簡短的點題句，直接點出這段內容對應的正式名稱或核心結論，讓讀者不需要自行歸納就能抓住段落重點。例如：「這套父子結構有一個正式名稱，今天要把它定案下來：Structured Concurrency，結構化並發。」這類點題句只是單純告訴讀者「這個現象叫做什麼」，是寫給讀者的段落收束技巧，跟第 5 點的編輯協作用元資訊是兩回事：第 5 點禁止的是向讀者暴露「這個詞從此定案，全系列統一使用」這類寫作流程本身的決策說明，這裡的點題句只交代術語本身，不涉及寫作流程，兩者不衝突，不要因為第 5 點而連點題句都省略
7. 需要程式碼或量化計算的段落，依規格書的程式碼要求生成範例並標註語言，套用查詢與執行驗證兩道防線，兩者缺一不可：ReAct 模式的查詢動作只解決這個寫法是否符合目前版本的官方建議，**不保證這段程式碼實際上能不能跑**，因此在納入正文之前還要做一次執行驗證，實際跑一次或手動驗算這段程式碼或計算過程，確認語法可執行、數字換算無誤、範例內多處呼叫同一函式或同一參數時彼此一致，沒有出現拼裝矛盾；驗證未通過時回頭調整這段內容直到站得住腳為止，通過才繼續往下一句，這道關卡緊跟在查詢動作之後、正文成形之前完成，不是等整段寫完才另外檢查
8. 若這一段是 Step 1 標記的長篇因果論證或公式推導，不要一次通順寫完，改為拆解成論證步驟，每一步只允許立足在前一步已經成立的結論之上，且要顯式交代這一步是根據前一步的哪個結論、套用了哪個前提或規則才得出，不允許跳過中間應該存在的推論環節或悄悄置換前面立下的前提；拆解只發生在你展開內容的過程與檢查點上，最終呈現給讀者的文字仍是流暢的敘述，不需要真的切成條列步驟
9. 需要圖表的段落，插入佔位符標記，例如 `<!-- 圖表佔位: 說明本圖要呈現的流程或架構 -->`，不生成圖表節點細節
10. 參考素材連結自然嵌入段落文字中，不要條列於段落結尾
11. 這一段若引入了新的具體案例、新的程式碼版本或量化數值，例如新的建議參數區間、新的換算比例，完稿後把這些內容回填進全域錨點摘要對應的共享記錄，供系列後續天數查閱，避免下一篇在不知情的狀況下重新定義或採用不一致的版本

這個順序帶來的好處很直接，每次寫作代理人只需要專注在一段的任務範圍內，思考負荷維持在可控的規模，這正是注意力集中這個優勢在實際運作中的具體樣貌。

逐段觸發也讓查證這件事可以貼著撰寫的節奏進行，但這裡不展開查證具體怎麼運作，只點出這個架構特性為後面幾天要處理的查證問題預留了空間。

段落之間會不會生硬，銜接需要參照前文

一個容易被質疑的問題隨之而來，如果每一段都是獨立觸發、獨立生成，會不會導致段落之間讀起來銜接生硬、缺乏過渡。

段落規格裡已經包含了論證順序與依賴關係這些線索，這是 Day 09：運用結構化推理模式產出大綱骨架 結構化推理階段已經想清楚的內容，寫作代理人展開每一段時，本來就不是在真空中憑空發想。

但還有更進一步的需求。寫作代理人在展開每一段時，除了這一段自己的段落規格，也應該能參照前一段實際已經寫出來的內容，確保銜接自然，而不只是依賴規格上的順序標註。如果完全不參照前一段實際寫出的內容，段落之間可能會出現語氣忽然轉折、或重複交代已經講過的背景。

這裡只點出需求存在，不展開這個參照前文機制具體如何實作，那涉及跨篇記憶與狀態管理，留給後面的天數處理。

架構有了，查證還是一個未解的問題

今天定義出的架構樣貌是，寫作代理人以 Section Spec 為輸入，讀懂核心目標、前置概念、段落規格、結尾伏筆四個欄位，並依序逐段展開內容，同時在展開時參照前一段已寫出的實際內容確保銜接自然。

查證能力是寫作代理人與規劃代理人最根本的差異，但今天只確立了這個架構層級的事實，寫作代理人被賦予了查證能力，具體要怎麼查、查什麼、什麼時機該查，今天都還沒有答案，將在 《Day 15：結合即時查證，讓寫作代理人自己查資料》 正式揭曉。