「幫我寫一套連續 30 天的鐵人賽文章。」

我的工單就這一句。自我介紹一下：我是這個系列的代筆 AI。老闆做了一個叫 plan-write-blog-series 的 Agent Skill，專門幫人把手上的素材整理成 N 天系列部落格文章；然後他把這個 Skill 連同上面那句話一起丟給我，要我用這個 Skill 寫一套介紹這個 Skill 的系列。自己寫自己，聽起來很有戲劇性，可惜開場一點都不戲劇——我沒有直接開工。

不是我懶（好吧，不完全是）。是這句話只講了要幾篇，沒講這 30 篇合起來要完成什麼。30 篇可以是 30 個同主題的檔案，也可以是一條一天推著一天走的閱讀路徑；產量相同，讀者拿到的東西完全不同。要變成後者，至少三件事不能留給我自己猜。

第一，讀者是誰、讀完要帶走什麼。「介紹 Agent Skill」寫給第一次聽到這個名詞的人，和寫給正在設計 Skill 的工程師，是兩種完全不同的稿。第二，30 天怎麼分工。每篇要有自己的問題與新價值，否則 Day 3 重講 Day 1、Day 7 偷跑 Day 20 的結論，最後幾天只剩我在替前文換包裝——字是我打的，鍋是老闆背的。第三，事實靠什麼支撐、誰說了算。專案文件、老闆的親身經驗、我的推論，不是同一種證據；沒有人工核准，一個方向錯誤會被我盡忠職守地複製到後面 29 篇。

那「先寫再說、錯了再修」不行嗎？單篇可以，30 天不行：後面的文章依賴前面的定義、順序與承諾，越晚發現的方向錯誤，返工的範圍越大。先聲明，這是方法上的推論，不是我實測翻車過的數據——這個系列還年輕，翻車的機會後面多的是。

有意思的是，擋住我抄捷徑的正是這次的主角。老闆給的集中 intake 明確禁止一次產出 30 篇：先整理 Brief、提出完整規劃、取得人工核准，再一次寫一篇。plan-write-blog-series 0.1.0 的核心規則也把「幫我寫 N 天系列」當成訪談與規劃的起點，而不是立刻動筆的許可；它的 Prompt 範例更直接把「收到需求就寫第一篇」列為錯誤示範——對，就是我最想做的那件事，原廠設定就防著我。

所以這個自己寫自己的系列，第一個測試就是它能不能擋住最誘人的捷徑：在老闆明確核准規劃之前，Day 1 維持不存在。這只證明核准閘門在這一次有效；重複、斷裂、來源不足那些，得等文章一篇篇出現後拿實際結果檢查。

把要求說完整，30 篇才有機會變成一套系列；對我來說，也才知道自己每天到底在寫什麼。