--- title: "該有自己的 Agent Skills 嗎？" date: 2026-02-11T00:00:00+08:00 publishDate: 2026-02-11T00:00:00+08:00 lastmod: 2026-02-09T20:53:16+08:00 tags: ["AI","Agent Skill","經驗"] toc: true permalink: "https://blog.aotoki.me/posts/2026/02/11/should-you-have-your-own-agent-skills/" language: "zh-tw" --- 我經常看到「某某工具超強」的討論，但實際用了別人的 Agent Skill 後，往往發現不太順手，效果也跟預期有落差。更何況讓任意的人提供你 Agent Skill 從安全角度來看也非常危險，因為我們會授權給 Agent 做很多事情，遠比工具軟體危險更多。 除了安全以外，還有很多理由應該要有一套自己的 Agent Skill 會更好。 ## 客製化{#customize} 當我看到 Agent 的概念開始出現時，我第一個想到的就是「客製化」的情境，作為軟體工程師設計軟體，很多時候是要在使用者之間找到平衡，設計所有人都會方便的軟體。這是因為資源有限，我們很難去滿足所有人。 但是 Agent 可以幫助任何人寫程式來解決問題，那就表示非常多情境是可以客製化的，也包含學習，以往需要請家教才能幫你解決的學習障礙，可以讓 AI 幫助你客製化（可以讀 [2026 年最值得投資的 AI 技能](https://blog.aotoki.me/posts/2025/12/31/ai-skills-worth-investing-in-2026/)這篇文章） 從這點來看，如果想要讓 AI 很好的幫忙你工作，應該是把這些工作流程（Workflow）變成可重複使用的提示（Prompt）讓 AI 使用跟你相似的習慣處理事情，這樣更容易找到中間的錯誤和得到跟你相同的品質。 以我在 Claude Code 的使用來說，我有一個 [coding-skills](https://github.com/elct9620/ai-coding-skills) 把我常用的 `/write`、`/fix`、`/refactor` 三個動作變成命令，只要是實作我都會用 `/write ...` 這樣開始。 > 雖然 Claude Code 已經不再區分 Slash Command 和 Skill 的差異，但是背後的提示組成還是不太一樣，使用 Command 直到 2.1.37 時都還是會用 `` 包覆 這種類型的 Agent Skill 通常是只限個人用的，其他人用起來通常會不太順手，但也不太容易出錯（因為限制明確、高度客製化） ## 能力{#ability} 另一種就是真的比較「泛用」的情境，目前 AI 的基礎是 LLM（Large Language Model，大型語言模型）最不缺的就是知識，但怎麼把知識引導出來就是一門學問。 通常在討論 Agent Skill 時，大家認知的都是這一種類型的，像是「建立 PDF 的能力」這樣的概念，有點類似於如果有「知識」但不知道怎麼運用時，這些知識就完全沒有用，因此「使用知識」就是很關鍵的能力。 在我的 coding-skills 中，我把 Clean Architecture、Testing 等等類型放到 `./skills` 目錄也是這個理由，首先我預期 AI 都已經知道什麼是 Clean Architecture、Test-Driven Development 這些概念，訓練資料中一定會有。 但是我在實踐 Test-Driven Development 時，該寫哪種測試呢？如果要測試，我該怎麼判斷適不適合寫測試，這些就不單純是知識的問題，而是經驗跟實踐累積出來的技巧（Skill） 這才是 Agent Skill 該具備的資訊，我應該告訴 AI 當我使用 Test-Driven Development 的方式進行時，我會先寫一個失敗的測試（Red）然後實作讓測試通過（Green）接下來重構（Refactor）而且會先選擇「整合測試」來寫等等。 如果換其他人、其他團隊就不一定會這樣做，因此他只是「客製化」的範圍更廣，可能是一個團隊、一間公司適用的狀況。 剩下純工具使用，才是最通用的技能，但你也會發現「經常不會被使用」因為這些技能因為太過於通用，幾乎沒有觸發的條件。 ## 技能組{#skillset} 以我對的安全性、客製化的角度來思考，會發現其他人的技能大多不好用，而且混再一起還會衝突。因為每個人都在客製化，判斷基準不同，那 AI 就更難區分該聽哪一個技能的指示。這樣還不如擁有自己的技能組。 基本上，按照客製化階段的工作流程，以及能力中的技能，我們可以得出「想做好一件事情，需要同時具備技能跟流程」這樣的推論，如何組織跟應用技能由工作流程設計，每個流程中需要的能力，以及細節則由技能提供。 在 coding-skills 中，假設你要使用 `/write` 這個命令開始一個開發工作，你會發現大致上是這樣運作的。 - 瀏覽目前專案（如：`git log` 和讀原始碼） - 釐清實作問題 - 從「技能規則」中選擇技能 - 根據技能的知識，制定計劃 - 執行計劃 在「技能規則」的段落，則說明每一種情境適合哪種規則。像是 `clean-architecture` 只需要在建立 `docs/architecture.md` 或者有比較明顯的結構調整時才需要，大多數時候都是靠 `testing` 和 `principles` 來處理。 那麼，每次使用 `/write` 命令時，就會很自然的引入測試、並且遵守原則（通常是 SOLID 原則）整個開發流程就會更專注在「該做什麼」上。 擁有自己的技能組，就是在定義自己的工作方式。如果無法決定怎麼工作、使用什麼知識，那還能稱作專業人士嗎？