今天早上我做了一件有點瘋狂的事：一口氣讓 AI 助理寫了 20 篇部落格文章。
不是那種「我寫好了請 AI 幫我潤稿」的程度，也不是「給我一個大綱我自己展開」。是從主題發想、內容規劃到完整成稿，20 篇，全部在一個早上搞定。坦白說，寫完的瞬間我自己也有點不敢相信。
這篇文章記錄整個過程，以及過程中我對 AI 寫作這件事的一些反思。
起因：經驗債務爆表
過去這幾天，我密集地用 AI 助理做了一大堆事。串接 OneDrive 的串流下載、用 Notion API 自動化工作日報、搞定站會紀錄的自動產生、拿 AI 分析台股投資數據⋯⋯每天都在解鎖新的玩法，每天都覺得「這個值得寫一篇分享」。
但你知道技術人的通病——做的時候很興奮，要寫下來的時候就開始拖延。「等我有空再寫」、「這個週末來整理」、「先記個 TODO 之後補」。結果就是經驗債務越積越多，部落格永遠停在三個月前那篇。
然後某天早上喝咖啡的時候，腦子裡突然冒出一個念頭：
既然這些事情都是 AI 幫我做的，那它當然也知道細節。與其我自己慢慢回憶慢慢寫，不如直接讓它幫我把經驗輸出成文章？
想到就做。這大概是我從 AI 身上學到最重要的習慣——execution gap 趨近於零。
工作流程：不是「叫 AI 寫」這麼簡單
直接對 AI 說「幫我寫 20 篇部落格」，你會得到 20 篇看起來像 ChatGPT 預設輸出的泛泛之談。要讓 AI 產出有品質的內容，流程設計才是關鍵。
第一步：素材盤點
我用的 AI 助理（跑在 OpenClaw 上）有一套完整的記憶系統，每天做過什麼事都會記錄下來。所以第一步是請它翻閱最近幾天的記錄，把所有「值得寫成文章」的經驗撈出來。
這一步的好處是：AI 比我自己記得更清楚。有些我已經忘了的小插曲，它翻記錄的時候會提醒我「欸你那天還做了這個，要不要也寫？」。
第二步：主題規劃與分群
撈出來的素材大概有二十幾個，篩選掉太瑣碎的，最後定了 20 個主題。接著按類型分群：
- 純技術類（4 篇）：OneDrive 串流下載、Notion API 自動化、Cursor Agent CLI 實戰、MCP 和 Skills 的差異比較
- AI 應用類（8 篇）：站會自動化、AI 投資分析、AI 當 PM、OpenClaw 入門、OpenClaw Cron Jobs、OpenClaw 記憶系統、Sub-Agent 架構、Claude 與 GPT 的選擇
- 經驗分享類（3 篇）：CTO 的 AI 工具箱、Side Project 開發記錄、AI 應用的安全設計
- 產業與架構類（3 篇）：ERP 產業觀察（AI 如何改變客製化地獄）、DevContainer 打造 AI 友善開發環境、Monorepo 架構與 AI 協作的最佳實踐
- 知識管理類（1 篇）：Obsidian 結合 AI 的工作流
- Meta 類（1 篇）：就是你現在在讀的這篇
分群的目的不只是整理，更重要的是每一群可以用類似的 prompt 模板，減少重複工作。
第三步：定義品質規格
這一步很多人會跳過，但我認為這是整個流程最關鍵的環節。我為每篇文章定義了詳細的規格：
- 格式：Hexo 的 front matter 格式，包含 title、date、id、description、categories、tags
- 字數：至少 1500 字（後來發現 AI 通常會寫到 3000 以上，這個之後再說）
- 結構：開頭要有引言段落，引言後加
<!--more-->摺疊點 - 用語：繁體中文台灣用語，程式碼和專有名詞保持英文
- 隱私紅線：不能提到任何公司名、客戶名、個人名（這條超重要，後面會講為什麼）
- 文風：第一人稱、自然口語、帶點自嘲幽默，不要像教科書
第四步：Sub-Agent 平行執行
這是整個流程的精華。20 篇如果讓一個 AI agent 從頭寫到尾，串行執行大概要 2-3 小時。但 OpenClaw 支援 Sub-Agent 模式——可以同時開多個獨立的 AI 分身，每個負責一部分任務。
我把 20 篇拆成 6 批，每批 3-4 篇，同時派給多個 sub-agent。每個 sub-agent 收到的 task prompt 都寫了 2000 字以上，包含那批文章的所有細節：標題、要點、匿名化規則、格式要求、文風指引。
結果？每批大約 5-6 分鐘完成，全部跑完不到 20 分鐘。
第五步：進度追蹤
Sub-agent 在背景跑的時候，主 AI 助理還在對話中待命，隨時回報進度：「第一批完成了」、「第三批有一篇檔名需要確認」。我甚至可以在等待的過程中追加需求、調整後面幾批的規格。
這種感覺很奇妙——你坐在那邊喝咖啡，偶爾看一下進度，然後 20 篇文章就這樣生出來了。
為什麼選擇 Sub-Agent 架構？
有人可能會問：為什麼不用一個很強的 agent 一口氣寫完？
三個原因：
速度。平行 vs 串行，20 分鐘 vs 2-3 小時。這個差距在實務上很有感。
品質隔離。每個 sub-agent 有自己獨立的 context window。如果用同一個 agent 連續寫 20 篇，到後面它會開始「疲勞」——不是真的疲勞，而是 context 被前面的文章塞滿，影響後面文章的新鮮度和獨特性。你會發現第 18 篇的用詞和第 3 篇莫名相似。拆開來跑就完全沒有這個問題。
容錯性。如果某個 sub-agent 出了問題（格式錯誤、跑太久、內容偏題），只需要重跑那一批，不影響其他已完成的部分。實際跑的時候確實有一批的檔名出了衝突，只要那批重新指定就好。
Prompt Engineering：好的 Brief 勝過反覆修改
這次經驗讓我更深刻體會到一件事：花在 prompt 上的時間，會以十倍的效率回報在產出品質上。
舉個反面例子。如果我只跟 AI 說：
「幫我寫一篇關於 Notion API 自動化的部落格文章」
我會得到一篇結構工整但內容空洞的文章，充滿「Notion 是一款強大的生產力工具」之類的廢話。
但如果我這樣說：
「寫一篇文章，主題是用 Notion API 串接每日工作日報的自動化。背景是：團隊有一個 Notion 資料庫記錄任務工時，每天下班前需要手動填寫日報。我用 API 實作了自動彙整功能，從任務工時 DB 拉當天的資料，自動生成日報頁面。技術細節包括 Database Query 的 filter 語法、Page Create 的 block 結構、處理中文日期格式⋯⋯」
差距是天與地。好的 prompt 不是考卷（「寫一篇 1500 字的文章」），而是 creative brief（「這是背景、這是素材、這是我要的感覺」）。
每批 sub-agent 的 task prompt 我都寫了至少 2000 字。聽起來很誇張對吧？但跟「產出 → 不滿意 → 來回修改三四次」相比，一次到位的 prompt 絕對更省時間。
踩過的坑
當然不是一切都這麼順利。分享幾個實際遇到的問題：
隱私紅線必須具體列出
光說「不要提到個資」是不夠的。AI 不知道什麼算個資、什麼不算。你必須明確告訴它：「不要提到任何公司名稱、客戶名稱、個人姓名。涉及時用『某公司』或『一位同事』替代。」
我第一批沒有列得這麼具體，結果有一篇差點把客戶專案的名稱寫進去。還好發佈前有 review，但這是個很好的教訓：AI 不會自己意識到隱私邊界，你要幫它畫線。
文風需要範例，不能只用形容詞
跟 AI 說「寫得自然一點、有個人風格」，它的理解跟你的理解可能差很多。比較有效的做法是附上一篇你之前寫的文章，告訴它「參考這個風格」。
我在後面幾批加入了風格範例之後，產出品質明顯提升。AI 不怕你給太多參考資料，它怕的是你給太少然後嫌它不夠好。
Sub-Agent 之間的檔名衝突
這是個很實務的坑。如果你沒有在每批的 prompt 裡明確指定每篇文章的檔名，不同的 sub-agent 可能會用同樣的命名邏輯產生撞名的檔案。解法很簡單：每批 prompt 裡直接列出檔名清單，不要讓 AI 自己決定。
字數控制是門學問
跟 AI 說「至少 1500 字」，它會很開心地寫出 3000 到 5000 字。有些主題這個長度剛好，有些就太冗了。後來我學到要加上上限：「1500-2500 字之間」，或者更具體地說「重點突出，不要為了湊字數而贅述」。
技術正確性需要人工校稿
這是最重要的一點。AI 寫的技術細節大概有八成是正確的，但剩下的兩成會有微妙的錯誤——API 參數名寫錯、版本號搞混、某個設定的預設值記反。
這種錯誤特別危險，因為如果你不是真的做過這件事，你可能看不出來。所以技術類的文章，我的建議是：AI 寫初稿沒問題，但技術細節一定要作者本人校稿。
靈魂拷問：AI 寫的算你的文章嗎？
好，來聊聊這個敏感話題。
當我跟朋友說「我今天早上用 AI 寫了 20 篇部落格」的時候，我能看到對方眼裡的問號——「所以⋯⋯那些算你寫的嗎？」
我的答案是：算，也不完全算。
算的部分：
- 每一篇的主題都是我想的，來自我真實的工作經驗
- 品質規格是我定義的
- 整個工作流程是我設計的
- 最終要不要發佈，由我決定
- 發佈前我會逐篇 review 和修改
不完全算的部分：
- 具體的文字確實是 AI 產出的
- 有些表達方式是 AI 的風格，不是我原本會用的措辭
- 如果完全不校稿就直接發佈⋯⋯說實話，有點心虛
我覺得比較合理的類比是：這就像請一個寫手幫你寫草稿。你提供題材、方向、品質標準，寫手負責把它變成文章，然後你再修改定稿。很多專欄作家、企業高管的文章都是這樣產出的，沒有人會說那「不算他們的文章」。
差別只在於，我的「寫手」是 AI，速度快了一百倍，而且不用付稿費。
不過我也要對自己誠實：今天這 20 篇是初稿。在正式發佈之前，我會逐篇 review，補上只有我知道的細節和故事，修掉 AI 的慣用句式。初稿是 AI 的，但成稿是我的——至少我希望是這樣。
這套流程的真正價值
做完這件事之後，我覺得最大的收穫不是「省了多少時間」，而是心態上的轉變。
以前「寫部落格」在我心裡是一件「大事」——要找一個安靜的下午，打開編輯器，對著空白頁面發呆半小時，然後開始痛苦地擠文字。光是想到這個過程，就足以讓我無限期拖延。
現在？寫部落格變成了這樣的流程：
- 花 10 分鐘想主題、列要點
- 把規格丟給 AI，讓它跑
- 花 10-15 分鐘 review 和修改
- 發佈
從「找一個下午」變成「花半小時」。從「對著空白頁」變成「修改一份草稿」。寫作的心理門檻直接降了一個量級。
這讓我想到一個更大的啟示：AI 最強大的地方不是替你做事，而是消除啟動摩擦。 很多我們拖延的事情，不是因為太難，而是因為從零開始太痛苦。AI 幫你把起點從 0% 推到 60%，剩下的 40% 你自己來，反而做得又快又好。
如果你也想試試，我的建議是把這套流程做成可重複使用的模板。定義好格式規格、文風指引、隱私規則，存成一份 template。下次想寫部落格的時候，只要填入主題和要點，一個指令就開工。
寫在最後
一個早上 20 篇部落格，聽起來很誇張，但回頭看，每一篇都有真實的經驗在支撐。AI 不是在替代寫作，它是在替代「把腦中的想法轉化成文字」的苦力活。思考、判斷、經驗——這些始終是人的事。
如果你手上也累積了一堆「想寫但沒時間寫」的主題，或許可以認真考慮這種模式。不一定要一口氣 20 篇，先試 3 篇，感受一下那種「欸，原來寫部落格可以不痛苦」的感覺。
最後來點自嘲收尾：這次一口氣產出 20 篇之後，我的部落格文章數量大概比過去三年加起來還多。
真心希望讀者不會發現那個明顯的斷層。
「你最近怎麼突然這麼勤奮？」
「呃⋯⋯新年新希望？」😂