把 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 下次執行任務非常重要。

所以我的順序是：

先從 session 裡抽出可重用 SOP。
把 SOP 寫成 Skill。
再從同一份材料裡提煉人類讀者會在意的故事和方法論。
最後寫成 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

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

我想保留的原則

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

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

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