連續 30 天的技術寫作,寫到後期最容易失控的不是靈感枯竭,而是忍不住把整篇文章丟給 AI 一鍵生成,結果讀起來總帶著模仿的破綻,多天累積下來系列風格逐漸崩壞。
這系列文章從這個困境出發,點出問題不在模型不夠聰明或 Prompt 不夠精準,而在於把規劃、查證、撰寫、審查全部塞進單一次推理,這種工作方式本身在架構上就站不住腳。
解法是像軟體架構師規劃系統一樣,把長篇技術系列寫作拆解成各司其職的代理人們,一步步打造出來,再串接成一條真正能協同運作的生產線。
如果你曾經報名過 IT 邦幫忙鐵人賽,或者只是認真考慮過要不要挑戰連續 30 天的技術寫作,你大概對這個畫面不陌生。前幾天靈感充沛,一天寫一篇不成問題,甚至還能...
在 《Day 00:用 AI Agent 撰寫長篇技術系列文章:35 天鐵人賽規劃》 中,我們拋出了一句直白的定調:傳統的「一鍵生成」只會產出結構鬆散、充斥 A...
《Day 01:為什麼傳統的「一鍵生成」寫不出好的長篇技術文章?》 的結尾留下了一個還沒被回答的問題。拆分成多個 Agent,解決的是「誰來做」,但拆分之後「先...
《Day 02:產出優先思維,先定義規格再動筆》 結尾留下一句還沒兌現的承諾,心法就位不等於藍圖就位。產出優先思維與單一職責 Agent 這兩個心法已經定案,但...
《Day 03:拆解寫作工作流,規劃、撰寫、視覺、審查的四種角色》 結尾留下一個還沒有名字的東西。規劃代理人交給寫作代理人的東西,究竟要用什麼共同的格式或依據,...
《Day 04:規劃代理人的產出介面,認識 Section Spec》結尾留下一個具體的問題。第 20 天的規劃代理人,要怎麼確保自己沒有遺忘或誤用第 8 天已...
《Day 05:系列的單一事實來源,打造全域錨點檔案》 結尾留下一個具體的問題。散落在各種零散筆記裡的原始素材,要如何被有效率地整理成可以查詢與引用的資料來源。...
《Day 06:從筆記到知識庫,素材的收集與初步整理》 結尾留下一個具體的問題。知識庫雛形份量過大、內容依然龐雜,要如何切成方便查詢的小單位,同時不能切壞程式碼...
《Day 07:知識庫的切分藝術,保留程式碼與上下文的完整性》 結尾留下一個具體的問題。規劃代理人這個角色具體要怎麼被設計出來,它的系統提示詞要怎麼寫,才能讓它...
Day 08:規劃代理人的系統提示詞設計 結尾留下一個具體的問題。規劃代理人具備清楚的邊界與可查閱的既有資源之後,具體要如何思考,才能把一個主題組織成一份結構清...