不要再蒐集 Skill 了：我開始建立自己的 Skill Factory
- 把書籍、實務經驗與工作紀錄，蒸餾成真正屬於你的 AI 能力 -
最近我一直在研究 Agent Skill。GitHub 上每天都有人分享新的 Skill，從「必裝清單」到上百個 Skill 的合集，我自己也常常看到不錯的就安裝。
前陣子算了一下，我裝的 Skill 加上 Plugin 指令已經超過 100 個。但我開始問自己：裝了這麼多，AI 真的有變得比較懂我嗎？
答案沒有想像中明顯。
最近看到理工威森分享〈不用懂技術，3 步把一本書蒸餾成你的 AI 技能〉，他談到把書中的方法 Distill 成 Agent 能使用的規則。我很喜歡這個方向，也開始想：蒸餾的材料，為什麼只能是書？
我真正想建立的，可能不只是 Skill Library，而是一座會把知識、經驗和工作紀錄轉成可用能力的 Skill Factory。
Skill 越多，為什麼 AI 不一定更懂我？
看到 GitHub 上不錯的 Skill，就安裝；看到別人推薦，又安裝。Skill Library 很容易變成另一種「稍後閱讀」：收藏了一大堆，真正工作時卻不確定該用哪一個。
更重要的是，那些 Skill 描述的是別人的工作方法。它可能很好，卻不一定符合我的寫作方式、課程設計流程、簡報架構、網站驗收標準、Agent 工作流程或客戶溝通方式。
所以我現在更在意的，不是「我安裝了多少 Skill」，而是：
AI 到底學會了多少我的工作方法？
Skill 的價值，在於它能不能讓 Agent 理解一項工作何時開始、該怎麼判斷、如何完成，以及什麼情況才算驗收通過。
蒸餾的不是摘要，而是判斷規則
假設讀完一本談判的書，請 AI 摘要，可能會得到幾個核心觀念、金句和技巧。看完當下覺得有收穫，過一段時間卻不一定記得怎麼用。
如果我希望 AI 學會用這本書的方法處理客戶殺價，問題就不只是「這本書在講什麼」，而是「遇到這種情境時，AI 要怎麼判斷與行動」。
例如客戶說太貴，Agent 可以先協助釐清：是真的預算不足、還沒理解價值、正在測試議價空間，還是拿競爭對手比較？可能原因不同，下一步就不該一律回覆同一句話。
這類「遇到什麼情況、先確認什麼、依什麼條件分流、最後如何檢查」的規則，才比較接近能放進 SKILL.md 的工作方法。一本書最後留下的，不必是完整摘要，而可以是 Agent 在實際任務中用得上的流程。
真正值錢的，也許是我自己的工作經驗
一本暢銷書或熱門 Skill，很多人都能取得；但我過去十幾年的工作經驗，只有我自己有。
我長期做 AI 教學、企業內訓、數位行銷、網站、AI Agent、Vibe Coding、LINE API 和自動化流程。這些經驗的價值，不只在於我知道哪些工具，更在於遇到不同狀況時，我會怎麼判斷。
例如製作一套課程，我逐漸形成了這樣的流程：
需求分析 → 學員分析 → 課程架構 → 實作設計 → Slide Manifest → 簡報 → 講義 → Prompt Card → 實際操作 → 驗收
這套流程不是哪一本書直接教我的，而是做過許多次後慢慢磨出來的。如果每次開新的 Agent Session 都要從頭解釋，這些方法就沒有真正累積下來。
把「我糾正 Agent 的地方」留下來
建立 Skill 時，我不想只靠回想「自己通常怎麼工作」。人描述自己怎麼做，和實際工作時做出的選擇，有時並不完全相同。
更直接的材料，是我和 Agent 一起完成工作的 Session。過程裡，我可能會說：
- 「這頁不對，實作比例太低。」
- 「這個提示詞要給建議填值。」
- 「簡報大綱跟講義對不起來。」
- 「先做 Slide Manifest。」
- 「新手在這裡一定看不懂。」
這些修正看起來只是聊天紀錄，背後卻可能藏著課程比例、教材一致性、提示詞易用性和讀者理解門檻等專業判斷。
如果我反覆要求 Agent 修改同一類問題，或每次都得重新解釋相同規則，那就值得回頭檢查：這是一次性的需求，還是已經穩定到可以成為工作規則？
我會從三種來源蒸餾 Skill
1. Knowledge Distill：把外部知識變成可執行方法
材料可以是書籍、YouTube、Podcast、課程、文章或研究報告。目標不是把來源濃縮成摘要，而是抽出適用情境、判斷方式、步驟和限制，讓 Agent 能在工作中使用。
2. Experience Distill：把實務經驗整理成自己的 Know-how
把自己做過多次的工作拆開來看，例如如何設計 AI 課程、規劃企業內訓、寫粉專文章、驗收網站、設計 Agent Workflow，或拆解 Vibe Coding 專案。
這些經驗不必一開始就寫成很大的 Skill。先把一項工作中反覆出現的判斷和品質標準說清楚，就已經是有價值的原料。
3. Session Review：從和 Agent 的工作紀錄找出規則
回顧過去的 Session，觀察自己反覆要求修改、最常否決、重複說明或固定採用的決策。這些重複出現的訊號，可以幫助我找到那些平常不一定會主動說出口的工作方法。
把 Skill Library 變成 Skill Factory
我想把建立 Skill 的流程整理成五個階段：
Capture：先留下真實工作過程
先照常完成一項真實任務。讓 Agent 參與實際工作，保留足以看出需求、修改、判斷與結果的過程，不急著在開始前猜測自己應該怎麼做。
Distill：抽出能重複使用的規則
任務完成後，請 Agent 協助找出自己曾經糾正、修改、否決、補充或重複要求的地方，再把它們整理成偏好、SOP、判斷規則、品質標準、禁止事項和驗收條件。
一條規則最好能說清楚觸發情境、要採取的行動，以及怎麼判斷結果合格；遇到例外時，也要知道何時該停下來確認。
Test：拿另一個真實任務試用
寫完 Skill 不代表它已經有效。可以把它用在另一個相似但不同的工作上，觀察自己是不是少講了重複要求、Agent 是否更接近預期，以及規則有沒有造成新的問題。
例如，若以前一份教材要反覆修改很多次，套用 Skill 後所需的修正明顯減少，這是值得追蹤的訊號；但重點不是達到固定數字，而是確認工作結果與協作過程是否真的改善。
Review：請另一個模型找出盲點
我也想使用多模型做對抗性 Review。例如一個模型協助規劃，另一個模型負責執行，再請第三個模型檢查完成的 Skill。不同模型可以從不同角度找出規則衝突、描述模糊、無法執行、限制過多、缺少例外或難以驗證等問題。
模型提供的是審查意見，最後仍要回到實際工作驗證：規則是否符合我的目的、是否改善結果、是否保留了必要的彈性。
Promote：通過驗證後再納入穩定版本
Skill 可以先放在 Experimental，經過實際任務測試後進入 Testing，確認適用範圍、品質和例外都清楚，再升級到 Stable。
不是每個聊天指令都要變成 Skill。單次需求可能只適用於那個任務；經常重複、可清楚描述而且能在別的任務中驗證的方法，才比較值得正式留下來。
GitHub 不只是放 Skill 的地方
如果持續累積，Skill 的組織方式也會慢慢清楚。初期可能有課程設計、文章寫作、簡報 Manifest、網站 Review 和 Agent Workflow；之後再依工作領域整理：
- 教學：課程設計、實作活動、Prompt Card。
- 內容：部落格文章、Facebook 貼文、教學文件。
- 開發：專案規劃、對抗性 Review、驗收。
- 商務：提案、客戶需求、報價。
這時 GitHub 就不只是擺放 Skill 的地方，也能協助記錄每個工作方法如何形成、如何修改，以及目前驗證到什麼程度。它逐漸累積的會是「我的數位工作方法」。
AI 之間的差距，可能也來自它有多了解你
以前我常比較 GPT 和 Claude 哪個比較強、不同模型寫程式的能力如何。隨著模型能力演進，我也開始思考：另一個差異會不會是 Agent 已經掌握多少你的工作方法？
兩個人即使使用同一個模型，一個每次都要從零說明，另一個已經累積多年工作規則和經過驗證的 Skill，實際合作起來可能就會很不一樣。
因此我現在不只把 Skill 看成外掛或工具清單，也把它當成一種能被整理、測試和更新的經驗。若你想先了解我對 Skill 與 Skill Library 的想法，可以接著閱讀從 Prompt 到 Skill Library：我從 Agent Skill 講座學到什麼。
以後完成一件工作，我想多問自己一句：
這次有沒有什麼值得留下來，變成 Skill？
看到一本好書，可以 Distill；完成一個專案，可以 Distill；和 Agent 來回修正很多次，也可以回頭檢查那些反覆出現的判斷。
我不再只追蹤「我有幾個 Skill」，而想知道：「有多少原本要我親自判斷的事情，Agent 已經真正學會了？」
當這個數字慢慢增加，我建立的就不只是 AI 工作流，而是一套越來越像我的 AI 工作系統。
常見問答 (FAQ)
Q1：Skill Factory 和 Skill Library 有什麼不同？
Skill Library 著重收納 Skill；Skill Factory 則著重把知識、實務經驗和工作紀錄，經過整理、測試與 Review，逐步製作成可重複使用的 Skill。
Q2：什麼樣的工作經驗值得整理成 Skill？
如果一項判斷或要求在多次工作中反覆出現，而且能說清楚適用情境、處理方式與驗收條件，就值得評估是否整理成 Skill。只適用於單一任務的指令，不一定需要升級成固定規則。
Q3：要怎麼知道 Skill 有沒有用？
把它用在另一個真實任務，觀察 Agent 是否少了重複提醒、結果是否更符合預期，以及 Skill 是否帶來新的錯誤或限制。用實際工作表現來修正規則。
Q4：可以把每一次糾正 Agent 的內容都寫進 Skill 嗎？
不必。先分辨那是單次需求，還是跨任務都適用的工作方法。反覆出現、能清楚說明並且可以驗證的規則，通常更適合成為 Skill。
Q5：多模型 Review 可以取代實際測試嗎？
不行。其他模型可以幫忙找模糊描述或規則衝突，但是否符合你的工作方式，仍要透過真實任務驗證，再決定要不要升級到 Stable。
