Matt Pocock 的 Skills 技能包實測：22 個技能，讓 AI 照工程紀律做事

前幾天我在 YouTube 上滑到一支影片——Gary Chen 的〈700 萬人下載的 /grill-me，Matt Pocock 到底寫了什麼？〉。看完當下我就把 Matt Pocock skills 這整套技能包裝進自己的 Claude Code，這幾天所有專案都改用它在跑。

結論先說：這是我今年裝過、對工作習慣改變最大的一個東西。它不是框架、不是外掛、不用付錢、也不綁模型——它只是一疊寫得非常好的 Markdown 檔。但它做到了一件我一直做不好的事：逼我在 AI 動手之前，先把話講清楚。

這篇專門拆 Matt Pocock skills 這一套（GitHub 上的 mattpocock/skills）：它是誰做的、要修什麼問題、22 個技能各自負責什麼、兩種安裝方式差在哪、怎麼串成一條從想法到上線的動線，以及我實測後覺得哪些真的有感、哪些要小心。

（如果你還不知道「技能檔」這種東西是什麼，先看這篇：AI Skills 是什麼？）

Matt Pocock 在 TypeScript 圈子裡是個很有份量的名字——Total TypeScript 的作者，後來把重心移到 AI 工程教育（AI Hero），電子報有六萬多個開發者在看。這個倉庫的說明只有一句話：「Skills for Real Engineers. Straight from my .agents directory.」

這句話是重點。它不是為了教學而設計的教材，是他自己每天在用的那份設定，原封不動推上 GitHub。所以你看得到一個資深工程師真正在意什麼、怎麼跟 AI 分工、遇到爛結果時他怎麼補。

他在說明文件裡也直接劃了界線：市面上像 GSD、BMAD、Spec-Kit 這些方法論，是把流程整包接管走——好處是照做就有東西，壞處是流程出錯時你很難修，因為控制權不在你手上。他的做法相反：技能拆得小、彼此可組合、隨你改。「Hack around with them. Make them your own.」

2026 年 2 月開的倉庫，到 7 月已經累積十八萬顆星、一萬六千多次 fork（數字以 github.com/mattpocock/skills 當下顯示為準，這類專案的星數變動很快）。這個量級在開發工具圈算是現象級——但更值得注意的是它還在高頻更新，作者一邊用一邊改，你訂閱等於跟著一個資深工程師的日常實踐走。

這套技能包最值錢的其實不是那些檔案，是它的問題意識。作者開宗明義說：這些技能不是為了讓你「氛圍寫程式（vibe coding）」，是為了做真正的工程。他把 AI 開發最常見的失敗收斂成四種，每一種都配一帖藥，而且每一帖都引了一本經典當靠山。

「沒有人真正知道自己要什麼。」——《The Pragmatic Programmer》

軟體開發最常見的失敗從來不是技術，是沒對齊。你以為對方懂了，等看到成品才發現他完全誤會。AI 時代一模一樣，只是誤會的速度更快、產出更多。

解法是 /grill-me（非程式情境）與 /grill-with-docs（程式情境）：讓 AI 反過來拷問你。它會沿著決策樹一路往下問，一次只問一題、每題附上它建議的答案，能自己查的事實就自己查、只把決策留給你，而且在你確認達成共識之前，它不准動手。

這是整套裡最多人用的一個，我實測後也同意：光是這一招，返工率就少一半。以前我丟一句「幫我做一個報價單模組」，換來的是一坨要重寫的東西；現在被問完二十題，AI 寫出來的第一版就已經有八成能用。

「有了共通語言，開發者之間的對話和程式碼的表達，都源自同一個領域模型。」——Eric Evans《Domain-Driven Design》

AI 被丟進一個專案，卻沒人告訴它這裡的行話是什麼，所以它只好用二十個字講一件本來一個詞就講完的事。

解法是一份 CONTEXT.md——專案的共同語彙表。作者給的對照非常傳神：

• 之前：「課程某個章節裡的課程被『實體化』（也就是在檔案系統裡拿到位置）的時候會出問題」
• 之後：「實體化串聯（materialization cascade）出問題了」

這份文件由 /grill-with-docs 一邊訪談一邊長出來，順便把難解釋的決策寫成 ADR（架構決策紀錄）。好處遠不只變簡潔：變數、函式、檔名開始一致地使用同一套詞彙，AI 在專案裡導航變容易，連思考消耗的 token 都變少。這是我認為整套裡最被低估的一招。

「永遠踏小步、有意識地走。回饋的速率就是你的速限。」——《The Pragmatic Programmer》

就算你和 AI 對齊了，它還是可能寫出爛東西——因為它看不到自己的產出跑起來是什麼樣子。沒有回饋，它就是在盲飛。

藥有兩帖。/tdd 把紅燈→綠燈的循環變成硬紀律，而且它的重點根本不在「寫測試」，在於規定測試該長什麼樣：只測公開介面不測內部實作、測試位置（seam）要事先跟人談定、禁止同義反覆的假測試、禁止一次寫完所有測試再來實作（要一次一片垂直切片，作者叫它「曳光彈」）。

/diagnosing-bugs 則把除錯拆成一條不准跳步的流程：重現 → 縮到最小 → 提假設 → 埋觀測 → 修 → 補回歸測試。這條流程擋掉的是 AI 最愛的壞習慣：看到錯誤訊息就開始亂改，改到不報錯為止。

「最好的模組是深的：用很簡單的介面，提供很多功能。」——John Ousterhout《A Philosophy of Software Design》

AI 讓寫程式變快，同時也讓架構腐化變快。這是我自己最有感的一點：三天就能長出一個模組，三個月後那個資料夾沒人敢碰。

/improve-codebase-architecture 是這套裡我最喜歡的設計。它會先看 git 紀錄找出最近一直在改的熱區（不是全庫亂掃），再派探索型子代理去走讀，找出「淺模組」——那種介面複雜度幾乎等於實作複雜度、存在感很低的東西。然後它產出一份自帶前後對照圖的 HTML 報告丟到暫存資料夾打開給你看，讓你挑一個，再針對那個進行訪談。

它甚至內建一個判準叫刪除測試：把這個模組刪掉，複雜度會被收攏，還是只是搬到別的地方？只有前者才值得動手。作者建議每隔幾天就跑一次。

整套只用一條軸線分類，而且這條軸線設計得非常聰明——誰有權呼叫它：

• 使用者呼叫（user-invoked）：只有你打指令才會啟動，負責指揮與編排。
• 模型自動呼叫（model-invoked）：你可以叫，AI 也會在任務對得上時自己啟動，負責可複用的紀律。

還有一條鐵則：使用者呼叫的技能可以去叫模型呼叫的技能，但不能叫另一個使用者呼叫的技能。這條規則避免了指揮鏈打架——編排的只有一層，紀律可以被任何人重複使用。

除了說明文件正式列出的這 22 個，倉庫裡還有兩區可以挖：skills/misc/ 放了幾個很實用的雜項（擋掉危險 git 指令的護欄、自動裝好 pre-commit 檢查、測試資料型別遷移），skills/in-progress/ 則是作者還在實驗的東西。這也是這套最好的地方——它是一個人的 .agents 資料夾直接開源，你看得到他正在想什麼。

官方給了兩條路，差別不在難易度，在你想不想改它。

第一種：skills.sh 安裝器（可編輯）——把技能檔實體複製進你的專案，你可以隨意改成自己的版本。

npx skills@latest add mattpocock/skills

跑完會讓你勾選要裝哪些技能、要裝到哪些 AI 工具（Claude Code、Codex 等都支援）。記得一定要勾 /setup-matt-pocock-skills。

第二種：Claude Code 外掛（託管）——整包當成唯讀套件安裝，作者更新你就跟著更新，等於訂閱而不是分叉。

claude plugin marketplace add mattpocock/skills
claude plugin install mattpocock-skills@mattpocock

在 Claude Code 裡面則是：

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock

技能單看很零散，串起來才看得到威力。這是我目前跑的一條動線，每一步都對應到一個技能：

順帶一提，這條動線的每一步在我自己的專案裡都留下痕跡：CONTEXT.md 是共同語言、ADR 是決策的歷史紀錄、票是進度、審查紀錄是品質的證據。這些東西合起來，就是一個團隊的記憶。人可以換、模型可以換，記憶留著就好。

把整件事收攏成一句話：模型負責智力，技能檔負責紀律，而紀律才是決定你能不能交付的那一半。

Matt Pocock 這套之所以值得看，不是因為它有多少行程式碼，是因為它把幾十年的工程判斷，壓縮成 22 段你可以直接抄、也可以直接改的指示。如果你還想先搞懂「技能檔」這種東西的原理，可以接著看 AI Skills 是什麼？

我是王永鉞（Elmers Wang），WASPCORE 的創辦人。我做的事就是把這類方法論，變成企業內部真的跑得起來的系統——從共同語言、流程紀律，到最後能自動運轉的 AI 工作流。如果你也想把公司的做事方法變成 AI 會照做的標準，可以先看企業 AI 導入顧問服務怎麼從第一個流程開始，或直接聊聊你現在卡在哪一步。

本文用到的名詞定義

• AI 技能包 AI Skills｜Claude Code｜模型上下文協定 MCP