把 Agent Session 沉澱成 Skill：我開始整理可重用工作流的方法

Agent session 最大的浪費，是做完後沒有留下方法

很多 Agent session 其實不只是單次任務。

例如一次完整的網站調整，可能包含：

• 先討論產品或 UX 的問題
• 實作元件
• 補測試或驗證 build
• archive change
• commit 到專案
• 最後整理出為什麼這樣做

如果這些只停在聊天紀錄裡，下次要做類似事情時，我還是得重新說一次背景、偏好、流程和驗證方式。真正有價值的不是「這次改了哪幾個檔案」，而是中間形成的判斷流程。

所以我開始把完成的 session 當成原料，整理成之後可以重用的知識。

我把產物分成 Skill、Draft 和 Project note

不是每一次 session 都應該變成同一種東西。

我目前會先判斷它比較適合沉澱成哪一類：

• Skill：給 Agent 重用的操作流程。重點是觸發條件、步驟、命令、常見坑、驗證清單。
• Draft：給人閱讀的文章草稿。重點是背景、問題意識、取捨、最後形成的方法。
• Project note：只對某個專案有用的脈絡，例如某個 repo 的架構決策或維護規則。

這個分類很重要，因為 Skill 和文章的寫法完全不同。

Skill 不需要好看，它要可執行。文章不需要列出所有命令，它要讓讀者理解為什麼這套方法值得採用。

為什麼我採用「Skill first」

我現在傾向先寫 Skill，再寫文章。

原因是：如果先寫文章，很容易把 session 包裝成一個漂亮故事，但漏掉真正能重用的細節。例如：

• 什麼時候要觸發這個 workflow？
• 哪些情況不該用？
• 要先檢查什麼前置條件？
• 如果工具失敗，要怎麼換路徑？
• 最後要用什麼結果確認任務真的完成？

這些內容放在文章裡會太瑣碎，但對 Agent 下次執行任務非常重要。

所以我的順序是：

1. 先從 session 裡抽出可重用 SOP。
2. 把 SOP 寫成 Skill。
3. 再從同一份材料裡提煉人類讀者會在意的故事和方法論。
4. 最後寫成 Draft。

這樣文章不會只是操作紀錄，Skill 也不會變成散文。

什麼樣的 session 值得沉澱

不是所有聊天都值得保存。

我現在會看幾個訊號：

• 有 5 個以上的實際操作步驟
• 中間遇到非顯而易見的坑
• 有明確驗證方式
• 下次一到三個月內可能重複遇到
• 和我的核心工作流有關
• 最後形成了一個可以教給 Agent 的操作模式

如果只是一次查資料、單純問答，或只對當下有效，就不需要硬寫成 Skill。硬存太多只會讓知識庫變吵。

一次 session 裡，我會抽出哪些東西

沉澱時，我不是直接複製聊天紀錄，而是整理下面這些資訊：

• 這次原本要解決什麼問題
• 最後實際完成了什麼
• 中間做了哪些關鍵決策
• 哪些方法試過但不適合
• 哪些細節下次很容易忘記
• 需要保留的命令、檔案路徑或驗證方式
• 哪些內容不能放進公開文章，例如敏感憑證、私人 ID、內部端點或過細的機器資訊

這一步其實像是把「聊天」轉成「產品化後的工作流」。

聊天紀錄是時間序列；Skill 和文章則是經過編排的知識。

Skill 的內容要偏向可執行

一個好的 Skill 對 Agent 來說應該像是 SOP，而不是心得文。

我會希望 Skill 裡至少包含：

• 什麼情境要使用
• 什麼情境不要使用
• 前置條件
• 具體步驟
• 可能用到的命令或工具
• 常見錯誤，用「症狀 → 原因 → 修法」整理
• 最後的驗證清單

這樣下次我只要說「把這次沉澱一下」，Agent 就不需要重新猜我要的是什麼，可以直接進入整理流程。

Draft 的重點是讓讀者看懂取捨

Draft 不應該只是 Skill 的人類版。

文章要處理的是：為什麼我需要這個方法？它解決了什麼問題？我以前怎麼做？現在為什麼改成這樣？

所以文章裡會保留：

• 具體場景
• 做法的轉折
• 方法背後的取捨
• 可以被讀者借用的判斷標準

例如這次的核心不是「我建立了一個 Skill」，而是：

Agent workflow 如果只追求完成任務，很容易失去累積性；但如果每次都能把可重用部分沉澱下來，Agent 就會逐漸變成真正貼近個人工作流的助手。

這才是文章要傳達的東西。

這套流程之後會怎麼用

之後如果一個 session 完成了複雜任務，我可以直接用幾種說法觸發：

• 「把這次沉澱一下」
• 「這次可以寫成 skill」
• 「整理成 draft」
• 「把這次 session 變成 skill 和文章草稿」

Agent 接到之後，就先判斷輸出模式：

• 只需要 SOP：寫 Skill
• 有公共分享價值：Skill + Draft
• 主要是觀點整理：Draft
• 只跟專案內部有關：Project note

這讓工作流的尾聲不只是收尾，而是把這次工作變成下一次的起點。

我想保留的原則

最後，我會把這套方法壓成幾個原則：

1. 不要讓 session 只留下結果，要留下方法。
2. Skill 是給 Agent 執行的，文章是給人理解的。
3. 先保存操作細節，再寫敘事。
4. 不是每次都值得沉澱，只有可重用的才保存。
5. 公開前一定要做隱私檢查。

這樣 Agent 才不只是一次性工具，而是會隨著每次合作，逐步靠近我的實際工作方式。