--- title: "Agent Skills 需要多少內容？" date: 2026-03-25T00:00:00+08:00 publishDate: 2026-03-25T00:00:00+08:00 lastmod: 2026-03-23T20:31:24+08:00 tags: ["LLM","AI","經驗"] toc: true permalink: "https://blog.aotoki.me/posts/2026/03/25/how-much-content-do-agent-skills-need/" language: "zh-tw" --- 之前寫過[該有自己的 Agent Skills 嗎？](https://blog.aotoki.me/posts/2026/02/11/should-you-have-your-own-agent-skills/)來說明我認為每個人都該維護自己的技能，然而另一個現象是很多「厲害的技能組合」真的有這麼神奇嗎？ 就我自己的經驗，即使不用這麼多內容也一樣運作得非常好，放這麼多可能更浪費 Token 還有機會影響表現。 ## Reasoning Model 目前大多數前沿模型都已經採用推理模型（Reasoning Model）的設計，在推理模型中因為有推理步驟的關係，表現會更穩定，也因此不需要 CoT（Chain of Thought，思維鏈）來輔助。 以 Claude Code 為例子，在 [Best Practices for Claude Code](https://code.claude.com/docs/en/best-practices)和 [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)這些文章中，都反覆強調「設定目標」跟「不要太過細緻」的重要性，因為這會影響到模型的運作。 舉例來說，在非推理模型中，我用「印出 Hello World」的提示時，很高機率會得到一個 Python 或者 JavScript 的檔案，因為機率上相對比較高（比較多人使用） 如果是推理模型，中間多出推理步驟可能就會有一些變化，產生了「等等，使用者說過他是 Ruby 工程師，所以預設採用 Ruby 會更合理」然後就得到使用 Ruby 所寫的版本，而不再是單純的以機率判斷。 > 這裡使用比較簡化的例子，目前以比較小的本地模型都能處理這樣的判斷，因為內容不多 如果改成用「用 PHP 印出 Hello World」的話，因為加入了 PHP 的限定，就直接讓推理模型失去探索的可能。既然已經指定了語言，推理步驟中就不需要考慮使用者偏好、專案慣例等脈絡，反而少了一次做出更好判斷的機會。這也是為什麼在設計技能時，過度細緻的指示可能適得其反。 ## 技能類型{#skill-types} 既然知道了推理（Reasoning）是怎麼發揮效果，那麼就能以此為基礎思考，當需要設計一個技能的時候，該怎麼讓「推理」按照預期的進行。 以上一段的「印出 Hello World」為例子，這裡的印出文字就是目標，要怎麼達成這個手段有非常多種方式，考慮到脈絡（Context）像是 CLAUDE.md 或者 AGENTS.md 等資訊，模型就能依靠「根據 CLAUDE.md 的內容，這個專案大多是 Ruby 的檔案，應該要使用 Ruby 比較適合」的推理得到結論 但是還有一些不同的情況，剛剛是執行一個任務的案例。如果現在變成「實作有很多重複怎麼辦？」這樣的情境時，我們要怎麼驅動模型選擇預期的方式處理？ - 寫一個方法減少重複 - 建議可以用 Factory Pattern 處理 - 使用 Design Pattern 維護專案 在沒有任何脈絡時，模型選擇「寫一個方法減少重複」的機會很大，比起 Creation Method（建立方法，Factory Pattern 的一種簡化形式）的概念，「實作方法減少重複」對模型訓練更常見。 如果是有經驗的工程師，很可能會給「用 Factory 重構」這樣的指示，而且高機率也會選到 Creation Method 的方式處理。 然而考慮到推理模型的特性，更加彈性的會是「善用 Design Pattern 重構？」就會自己推理出 Creation Method 方式適合，不需要描述「重複」也不用提示「Factory」這些關鍵字，模型會發現有重複，如果是 Design Pattern 那使用 Factory 可能比較適合。 按照這樣分類，我們可以分成兩種大方向 - 達成目標能用的方法 - 達成目標所需的知識 同時，大多數人應該都會認同大型語言模型（Large Language Model，LLM）知道的比大部分人還多，那麼重點就不在「重複提點知識」而是要讓語言模型「關注知識」 ## 專業技能{#expert-skills} 如果要構成一個「專業技能」並不單純是靠知識就足夠，我們需要結合「方法」和「知識」才能很好的做到這點。 雖然 Claude Code 目前把 Commands（命令）跟 Skills（技能）看作是相同的定位，但也還有保留目錄的差異可以區分，剛好就是「方法」和「知識」的差異。 以我的 [coding-skills](https://github.com/elct9620/ai-coding-skills) 當作案例，我放在 `commands/` 目錄的都是一套方法（流程）這些內容並不能讓一個初階工程師變成一個資深工程師，但是他可以很大的減少「試錯」的過程，一名熟練的工程師做事有一套習慣，而且這個習慣很穩定（如：除錯會先看日誌，不會盲目開始改程式） > 如果有用過 Claude Code 官方的 `/skill-creator` 其中一個評比就是 Token 效率，在沒有啟用技能時，大部分都是因為試錯浪費掉。 但是，光是只有這樣頂多確保過程順暢，卻不能對品質有所保證。因此在 `commands/` 目錄下的指示，都會提供一組決策表格（Decision Table）來說明該啟用哪些技能。 舉例來說，在 `/coding:write` 這個命令中，會要求再寫新的實作時先啟用 `coding:principles` 這個技能，了解原則性的目標。而「原則」技能中，簡單說明了 SOLID 的應用，以及評分表（Rubric）來幫助確認實作是否達到標準。 也因此，當我在使用 `/coding:write` 時，如果是一個全新的實作就會把 `coding:principles` 自動的啟用，同時根據 SOLID 的原則，雖然沒有給範例以及做法，只提到像是「Direct instantiation of dependencies」的違規原則，對 Opus 4.6 這類模型，就會自然選則依賴注入，而不是直接在建構子（Constructor）中建立實例。 會選擇這樣設計的理由也很單純，首先相信模型的知識量遠比想像的多，正確的提醒關鍵字更有效。當關鍵字生效後，好的脈絡（Context）更有幫助，初始狀態透過經常維護的 `CLAUDE.md` 對基本命令、專案結構有所理解，再由命令搭建的工作流程，引導先使用 `git log` 等技巧確認最近的變更，在按照語意搜尋相關的檔案，銜接技能喚起的知識，就能得到相當不錯的表現。 也因此，我們大多不需要依靠其他人設計的技能，或者那些「看起來很豐富」的技能，只需要安排恰當的流程引入脈絡，再搭配技能精確地喚醒必要知識，大多數時候就會表現得非常不錯。 這也是為什麼我認為不需要那些豐富的技能內容，技能應該呈現團隊、個人對知識的理解和應用。