之前寫過該有自己的 Agent Skills 嗎？來說明我認為每個人都該維護自己的技能，然而另一個現象是很多「厲害的技能組合」真的有這麼神奇嗎？
就我自己的經驗，即使不用這麼多內容也一樣運作得非常好，放這麼多可能更浪費 Token 還有機會影響表現。
Reasoning Model
目前大多數前沿模型都已經採用推理模型（Reasoning Model）的設計，在推理模型中因為有推理步驟的關係，表現會更穩定，也因此不需要 CoT（Chain of Thought，思維鏈）來輔助。
以 Claude Code 為例子，在 Best Practices for Claude Code和 Effective context engineering for AI agents這些文章中，都反覆強調「設定目標」跟「不要太過細緻」的重要性，因為這會影響到模型的運作。
舉例來說，在非推理模型中，我用「印出 Hello World」的提示時，很高機率會得到一個 Python 或者 JavScript 的檔案，因為機率上相對比較高（比較多人使用）
如果是推理模型，中間多出推理步驟可能就會有一些變化，產生了「等等，使用者說過他是 Ruby 工程師，所以預設採用 Ruby 會更合理」然後就得到使用 Ruby 所寫的版本，而不再是單純的以機率判斷。
這裡使用比較簡化的例子，目前以比較小的本地模型都能處理這樣的判斷，因為內容不多
如果改成用「用 PHP 印出 Hello World」的話，因為加入了 PHP 的限定，就直接讓推理模型失去探索的可能。既然已經指定了語言，推理步驟中就不需要考慮使用者偏好、專案慣例等脈絡，反而少了一次做出更好判斷的機會。這也是為什麼在設計技能時，過度細緻的指示可能適得其反。
技能類型
既然知道了推理（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）知道的比大部分人還多，那麼重點就不在「重複提點知識」而是要讓語言模型「關注知識」
專業技能
如果要構成一個「專業技能」並不單純是靠知識就足夠，我們需要結合「方法」和「知識」才能很好的做到這點。
雖然 Claude Code 目前把 Commands（命令）跟 Skills（技能）看作是相同的定位，但也還有保留目錄的差異可以區分，剛好就是「方法」和「知識」的差異。
以我的 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 等技巧確認最近的變更，在按照語意搜尋相關的檔案，銜接技能喚起的知識，就能得到相當不錯的表現。
也因此，我們大多不需要依靠其他人設計的技能，或者那些「看起來很豐富」的技能，只需要安排恰當的流程引入脈絡，再搭配技能精確地喚醒必要知識，大多數時候就會表現得非常不錯。
這也是為什麼我認為不需要那些豐富的技能內容，技能應該呈現團隊、個人對知識的理解和應用。