---
title: "技能不是外掛：AI Agent 的「技能地獄」與四道防線"
description: "Matt Pocock 的 Claude Code 技能庫在 GitHub 累積超過 15 萬顆星，他形容那是「真正的工程，不是 vibe coding」。技能一支一支加，Agent 卻開始不聽話——他歸納出觸發、結構、引導、精簡四道防線，這篇文章拆解給你聽。"
author: "莊哲昀（AJ）"
tag: "AI Agent 與自動化"
date: 2026-07-05
canonical: https://www.ahadigit.work/blog/agent-skills-matt-pocock
source: "html"
---

# 技能不是外掛：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 自己判斷要不要做，還是該讓人自己記得去按？兩種都要付代價，只是代價落在不同人身上。

![深色背景的程式碼編輯器畫面，象徵 AI Agent 技能檔案的結構設計](https://images.unsplash.com/photo-1759661881353-5b9cc55e1cf4?fm=jpg&q=70&w=1600&auto=format&fit=crop)

*技能檔案跟程式碼一樣，長太肥的那支通常最先出包。Photo by [Jakub Żerdzicki](https://unsplash.com/@jakubzerdzicki) on [Unsplash](https://unsplash.com/photos/n3ba57RKVNs)*

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

第二道防線在技能檔案內部。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 分支才會用到」的東西，通通丟到外部檔案去。這跟寫程式時把很少呼叫到的分支邏輯拆成獨立函式，是同一種紀律。

> 我自己帶團隊做 Claude Code 技能工作坊時，最常見的錯誤示範，就是把一支技能寫成「萬用瑞士刀」——十種情境全塞進同一份 SKILL.md。拆完之後 Agent 表現通常立刻變乾淨，因為它不用每次都讀完十種情境才找到自己要走哪一條。

## 防線三：引導控制——用一個詞牽著 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

![工作者在筆電前檢視文件草稿，象徵拆解技能檔案、逐步精簡的過程](https://images.unsplash.com/photo-1758874384555-37d50c0ee81a?fm=jpg&q=70&w=1600&auto=format&fit=crop)

*拆一支技能成兩支，有時比多寫十行提醒更有效。Photo by [Vitaly Gariev](https://unsplash.com/@silverkblack) on [Unsplash](https://unsplash.com/photos/Ad2TAPEhliE)*

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

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

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

> 那個數位在替企業與政府單位做 Claude Code / AI Agent 導入訓練時，「幫團隊寫出真正會被用、而不是寫好就沒人記得的技能」是我們最常被問到的題目。如果你的團隊也在被自己越堆越多的技能檔案拖慢，[歡迎預約洽詢](https://www.ahadigit.work/contact)。

## 資料來源

**本文引語與資料來源**

① Matt Pocock 演講《Building Great Agent Skills: The Missing Manual》，YouTube：youtube.com/watch?v=UNzCG3lw6O0

② Matt Pocock「writing-great-skills」技能原文：github.com/mattpocock/skills/blob/main/skills/productivity/writing-great-skills/SKILL.md

③ Matt Pocock「skills」repo 簡介與星數（2026 年 7 月查證）：github.com/mattpocock/skills