技能不是外掛：AI Agent 的「技能地獄」與四道防線

156,740——這是英國工程師 Matt Pocock 那份 Claude Code 技能庫在 GitHub 上累積的星數。他把自己每天實際在用的 .claude 技能檔案整包公開，說明文字只寫了一句：「這是我用來做真正工程的技能，不是 vibe coding。」

「My agent skills that I use every day to do real engineering — not vibe coding.」
（我每天用來做真正工程的 Agent 技能——不是 vibe coding。）—— Matt Pocock, github.com/mattpocock/skills

這句話背後有個矛盾：Pocock 一邊教大家幫 Claude Code 寫技能（Skills），一邊在他今年於 AI Engineer 大會的演講《Building Great Agent Skills: The Missing Manual》裡承認，技能寫多了，Agent 不會變聰明，反而會變笨——他稱這種狀態叫「技能地獄（Skill Hell）」：技能一支一支加進去，Context 塞得越滿，Agent 卻越常忘記該用哪一支、或乾脆不用。

他在演講裡整理出一套檢核清單，把「技能地獄」拆成四道防線：觸發、結構、引導、精簡。這篇文章照這四道防線，一一拆給你聽。

防線一：觸發方式——誰按下開關

第一個決定，是這支技能要「使用者觸發」還是「模型觸發」。模型觸發的技能會把描述文字塞進 Agent 的 system prompt，讓 Agent 自己判斷該不該叫出來用；使用者觸發的技能則反過來，把描述文字整支藏起來，只有你打出技能名稱才會啟動。

Pocock 在寫給模型觸發的技能時保留了描述欄位——這欄位的作用不只是給人看：

「A model-invoked skill keeps a description, so the agent can fire it autonomously and other skills can reach it.」
（模型觸發的技能保留一段描述，讓 Agent 能自主啟動它，其他技能也能呼叫到它。）—— Matt Pocock, writing-great-skills/SKILL.md

但方便是有代價的：每多一支模型觸發的技能，Agent 的 context 就多一份要背的說明，而且「該出手時沒出手」的機率也跟著墊高。使用者觸發剛好相反——你手動打技能名稱，Agent 的 context 乾乾淨淨，付出代價的人換成了你，你得記得自己有哪些技能可以用：

「Zero context load, but it spends cognitive load: you are the index that must remember it exists.」
（零 context 負擔，但要付認知負擔——你自己就是那份索引，得記得這支技能存在。）—— Matt Pocock, writing-great-skills/SKILL.md

這正是我在企業內訓現場常被問到的問題：「要不要把每個 SOP 都寫成一個會自動跳出來的 AI 小幫手？」答案不是「當然要」，是先想清楚：這件事該讓 Agent 自己判斷要不要做，還是該讓人自己記得去按？兩種都要付代價，只是代價落在不同人身上。

防線二：內部結構——步驟跟參考資料，不要混在一起

第二道防線在技能檔案內部。Pocock 把好技能的內容拆成兩種：一種是「步驟（Steps）」，帶著 Agent 一步步照做的程序；一種是「參考資料（Reference）」，支援步驟用的範本或背景知識。兩種可以混著用，但主檔案（SKILL.md）本身要盡量小——原因很直白：檔案越大，每次載入付的 token 成本越高，維護起來也越難改。

只有少數分支情境才用得到的參考資料，他的做法是整支移出主檔案，變成一份獨立的 Markdown，靠一句「上下文指標（Context Pointer）」指過去，等 Agent 真的走到那個分支才載入：

「External reference — reference pushed out of SKILL.md into a separate file, reached by a context pointer, loaded only when the pointer fires.」
（外部參考資料——從 SKILL.md 移出、放進獨立檔案，靠一個上下文指標指過去，只有指標被觸發時才載入。）—— Matt Pocock, writing-great-skills/SKILL.md

換句話說：主檔案只留下「這件事會發生的每一次都要看」的內容，剩下「只有走到 B 分支才會用到」的東西，通通丟到外部檔案去。這跟寫程式時把很少呼叫到的分支邏輯拆成獨立函式，是同一種紀律。

防線三：引導控制——用一個詞牽著 Agent 的行為走

第三道防線最反直覺：與其寫一整段話解釋你要什麼，不如換成一個高度濃縮的專業術語。Pocock 稱這種詞叫「核心詞彙（Leading Word）」——一個模型在預訓練階段就已經懂、且帶著明確意涵的詞，Agent 執行技能時會拿這個詞當思考的骨架，在輸出裡反覆講到它，行為就不容易跑偏：

「A leading word is a compact concept already living in the model's pretraining that the agent thinks with while running the skill.」
（核心詞彙是一個早已存在於模型預訓練知識裡的濃縮概念，Agent 執行技能時會拿它來思考。）—— Matt Pocock, writing-great-skills/SKILL.md

他舉的例子是軟體工程裡的「垂直切片（Vertical Slice）」——比起寫三段話解釋「請先做一個小而完整、能跑通頭尾的版本」，直接寫「用垂直切片的方式做」，Agent 反而抓得更準，因為這個詞在它的訓練資料裡本來就跟「先求完整、再求規模」牢牢綁在一起。

第二個工具是「充實度控制（Leg Work）」。如果 Agent 在某個步驟——比如「先把問題問清楚」——老是隨便問兩句就急著往下衝，Pocock 的解法不是加更多警告字句，而是把這步驟切成一支獨立技能，讓 Agent 看不到後面「做計畫」那個目標，逼它只能專心把眼前這一步做完：

「A demanding completion criterion drives thorough legwork — the digging the agent does within the work.」
（一個高要求的完成標準，會逼出扎實的充實度——也就是 Agent 在工作裡願意深挖的程度。）—— Matt Pocock, writing-great-skills/SKILL.md

防線四：技能精簡——清沉積、殺無效句

最後一道防線，是定期回頭刪東西。第一件事是別讓同一個概念在兩個地方各寫一份——每個知識點只留一個「單一事實來源」，要改行為只需要改一個地方：

「Keep each meaning in a single source of truth: one authoritative place, so changing the behaviour is a one-place edit.」
（每個意涵只留一個單一事實來源：一個權威的地方，改行為就只是一處編輯。）—— Matt Pocock, writing-great-skills/SKILL.md

第二件事，是抓「沉積物（Sediment）」。技能檔案跟共用文件一樣，多人協作、長期維護下來，會不斷堆積早就過時、卻沒人敢刪的段落——因為「加東西感覺安全，刪東西感覺有風險」：

「Sediment — stale layers that settle because adding feels safe and removing feels risky.」
（沉積物——因為『加感覺安全、刪感覺有風險』而不斷堆積的過期段落。）—— Matt Pocock, writing-great-skills/SKILL.md

第三件事最容易被忽略，是抓「無效操作（No-op）」——那些看起來煞有其事、實際上刪掉也不會改變 Agent 行為的句子，因為模型本來就會照做，你等於是花 token 講一句廢話：

「No-op — a line the model already obeys by default, so you pay load to say nothing.」
（無效操作——模型本來就會照做的一行字，你卻為了說一句廢話付出負擔。）—— Matt Pocock, writing-great-skills/SKILL.md

三件事合起來就是一份技能檔案的減法清單：別重複、別留沉積物、別寫廢話。

回到那 156,740 顆星

那份 GitHub 星數不是因為 Pocock 寫出一套「複製貼上就能用」的萬用技能包——事實上他反覆強調技能該按自己團隊的實際工作寫，別人的技能拿來抄，通常水土不服。真正被抄的，是這套四道防線的檢核清單：一支技能該讓誰按開關、內容該擺主檔案還是外部檔案、要不要塞一個核心詞彙、多久該回頭清一次沉積物。技能地獄不是技能太多造成的，是沒有人定期回頭問這四個問題造成的。