作者注：本文帶你零基礎跟做 mattpocock/skills 的兩個核心技能。先用 /grill-me 問清需求，再用 /tdd 寫代碼，每一步都給出驗收標準。
一句話結論：先用 /grill-me 讓 Agent 把需求問清楚，再用 /tdd 一次一個測試地寫代碼。
截至 2026-10-22 北京時間，GitHub 上的 mattpocock/skills 約有 30 萬星，採用 MIT 許可，最新版本是 v1.3.1。星數只說明關注度高，不等於在你的項目裏一定好用。所以本文只講怎麼裝、怎麼用、怎麼判斷它是否在正常工作，不渲染效果。
一份可以照着點、照着輸入的實操流程。我們會用“給下單流程加優惠券校驗”這個小需求，從安裝一直走到第一個測試變綠。
- 目標：裝好技能，用 /grill-me 跑完一輪需求提問，再用 /tdd 寫出第一個“紅→綠”測試
- 耗時：安裝只要幾分鐘（作者自述“30 秒裝好”）。提問和寫測試的時間主要取決於你回答得多快，以下爲編輯估算，整體大約 30 分鐘到 1 小時
- 前置條件：已經在用一種編程 Agent（Claude Code、Codex、GitHub Copilot、Gemini CLI 或 Cursor 等）；有一個可以隨便試的代碼倉庫
- 難度：入門。全程以圖形界面和對話框操作爲主，終端命令只作爲可選項列出
mattpocock/skills 核心要點：grill-me 和 tdd 各管什麼
mattpocock/skills 是 Matt Pocock 公開的一套 Agent 技能，倉庫描述是“Skills for Real Engineers”。作者在 README 裏寫到，這些技能小巧、可組合、能適配任意模型，並且“基於幾十年的工程經驗”。
| 要點 | 說明 | 價值 |
|---|---|---|
| /grill-me | 按輪提問，每題附推薦答案。不寫任何文件，只能由你手動輸入觸發 | 動手前和 Agent 對齊需求，暴露你沒意識到的決策 |
| /tdd | 先列出測試邊界（seam）並等你確認，再走“紅→綠”，一次一個測試 | 每一步都有反饋，測試能扛住重構 |
| /setup-matt-pocock-skills | 每個倉庫跑一次，配置 issue tracker、分診標籤和文檔存放位置 | 讓工程類技能知道往哪裏寫東西 |
| 安裝路線 | 插件（自動更新）和 skills.sh（可編輯文件）二選一 | 兩種都裝會讓每個技能出現兩份 |
grill-me 與 tdd 爲什麼要連着用
README 列出了幾種常見的失敗模式，其中兩條正好對應這兩個技能。第一條是“Agent 沒做我想要的”，根源是你和 Agent 之間有溝通落差。解法是一次 grilling（拷問式提問），讓 Agent 反過來詳細問你要做什麼。/grill-me 的本體其實只有一句話：調用 grilling 技能。真正的提問規則寫在 grilling 裏。
另一條是“代碼跑不起來”。即使需求對齊了，Agent 看不到代碼的實際運行結果，也等於盲飛。/tdd 的做法是先寫一個會失敗的測試，再寫剛好讓它通過的代碼，讓 Agent 每一步都拿到穩定的反饋。兩者連起來用，前一個解決“做什麼”，後一個解決“做對沒有”。
如何安裝 mattpocock/skills 並跑通 grill-me 與 tdd：5 步上手
第 1 步：安裝 mattpocock/skills（圖形界面優先）
官方列出了 Claude Code、Codex、GitHub Copilot、Gemini CLI 的裝法，其他 Agent 走 skills.sh。README 明確說這些技能適用於任意模型，官方也提到 Auggie、Droid、Goose 等尚未有人實測，目前建議先走 skills.sh。
| 你用的 Agent | 推薦裝法 | 是否自動更新 |
|---|---|---|
| GitHub Copilot（VS Code） | 打開命令面板，運行 Chat: Install Plugin From Source，輸入 https://github.com/mattpocock/skills |
是，每天更新 |
| Claude Code | 從官方插件市場 claude-plugins-official 安裝 mattpocock-skills |
是，默認開啓 |
| Codex | 先添加 mattpocock/skills 插件市場，再安裝插件 |
是，啓動時更新 |
| Copilot CLI | 通過 mattpocock 插件市場安裝 |
一次性設置 autoUpdate: true 後自動更新 |
| Gemini CLI | 分別安裝 engineering 和 productivity 兩個目錄 | 否，需重跑命令 |
| Cursor、OpenCode、Windsurf、Devin、Amp、Pi 等 | skills.sh | 否，需手動更新 |
VS Code 用戶最省事。按 Ctrl+Shift+P（macOS 爲 Cmd+Shift+P）打開命令面板，輸入 Chat: Install Plugin From Source，回車後粘貼倉庫地址即可。如果你習慣用終端，下面是官方給出的安裝命令，照抄即可：
- Claude Code：運行
claude plugin install mattpocock-skills@claude-plugins-official，默認自動更新。 - Codex：先運行
codex plugin marketplace add mattpocock/skills，再運行codex plugin add mattpocock-skills@mattpocock，每次啓動時自動更新。 - GitHub Copilot CLI：先運行
copilot plugin marketplace add mattpocock/skills，再運行copilot plugin install mattpocock-skills@mattpocock。 - Gemini CLI：分別運行
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering和gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity。它不會自動更新，想更新就重跑這兩條。 - 其他 Agent（skills.sh）：運行
npx skills@latest add mattpocock/skills -a cursor，把 cursor 換成你用的 Agent，比如 opencode、devin、windsurf、amp、pi；不寫-a會讓你自己選。更新時運行npx skills@latest update，有新技能時再重跑一次add。 - 只裝單個技能：運行
npx skills@latest add mattpocock/skills --skill=<name>，把<name>換成技能名。
Copilot CLI 還需要一次性打開 ~/.copilot/settings.json，加入這一段配置：{"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}。它的意思是把 mattpocock 插件市場登記爲來自 GitHub 倉庫 mattpocock/skills，並打開自動更新。官方說明這段配置按文檔格式編寫，但還沒有人實際跑過。
插件和 skills.sh 只能選一種。插件是自動更新的只讀包，skills.sh 會把可編輯文件複製進你的項目，兩種都裝會讓每個技能出現兩份。用 skills.sh 時，安裝器詢問要裝哪些技能，記得勾上 setup-matt-pocock-skills。
如果只想裝單個技能，有兩個依賴要一起裝。grill-me 本身只是調用 grilling，所以 grilling 必須同時安裝。tdd 依賴 codebase-design，用它的接口設計詞彙來討論 seam。
做到這樣就算成功：在 Agent 對話框裏輸入 /，候選列表裏能看到 grill-me、tdd、setup-matt-pocock-skills，而且每個只出現一次。
第 2 步：在對話框運行 /setup-matt-pocock-skills
第一次在一個倉庫裏用這套技能，先在 Agent 對話框輸入 /setup-matt-pocock-skills。它會依次問你三件事：用哪種 issue tracker（GitHub、GitLab、本地文件或你描述的其他方式），給工單分診時用哪些標籤，以及生成的文檔存在哪裏。
照實回答即可，不確定就選本地文件，以後還能改。嚴格來說，/grill-me 不依賴倉庫，可以不做這一步。但 /tdd 等工程類技能都建議先完成配置，每個倉庫只需要跑一次。
做到這樣就算成功：三個問題都問完，Agent 告訴你配置已完成，你也清楚之後的文檔會存到哪裏。
第 3 步：爲 grill-me 和 tdd 選對模型
官方文檔特別提到，提問階段比多數技能更依賴模型。grilling 靠的是模型自己對“系統會怎麼壞掉”的知識，所以要用你能用到的最好的模型。寫實現時主要跟隨上下文，便宜一些的模型也可以勝任。
| 階段 | 對模型的要求 | 建議做法 |
|---|---|---|
| /grill-me 提問 | 依賴模型自身的工程常識，越強問得越準 | 用你手上最強的模型，例如 Claude Opus 5.5 |
| /tdd 寫實現 | 主要跟隨已經建立的上下文 | 可以換成更便宜的模型 |
| 接入方式 | 在 Claude Code、Codex 裏按階段切換模型 | 用 API易 apiyi.com 的一個 Key 接入多種模型 |
在 Claude Code、Codex 裏配置統一接口，可以這樣做：
- Claude Code：先設置兩個環境變量，
ANTHROPIC_BASE_URL設爲https://api.apiyi.com（API易 統一接口），ANTHROPIC_AUTH_TOKEN設爲你的 API Key；然後運行claude啓動，在對話框裏用/model切換模型。 - Codex：打開
~/.codex/config.toml，寫入model = "<模型ID>"和model_provider = "apiyi"兩行；再新增一段[model_providers.apiyi]，在下面寫name = "API易"、base_url = "https://api.apiyi.com/v1"、env_key = "APIYI_API_KEY"三行。模型 ID 以控制檯顯示爲準。
字段名稱可能隨工具版本變化，具體請以工具官方文檔和 docs.apiyi.com 爲準。
🎯 選模型建議：提問階段寧可用最好的模型，寫實現時再降檔。通過 API易 apiyi.com 用一個 Key 在 Claude Code、Codex 裏切換模型，比較省事。需要說明的是，API易 只解決模型調用問題，不替代 grill-me、tdd 這些技能本身。
做到這樣就算成功：在對話框裏查看當前模型（Claude Code 可用 /model），確認提問階段用的是你選定的強模型。
第 4 步：用 /grill-me 問清“優惠券校驗”需求
開一個新會話，不要在 Agent 已經寫好計劃的會話裏接着用，同時關掉 plan mode。plan mode 會讓 Agent 急着產出計劃，而這一步你需要它不停地提問。在對話框輸入 /grill-me 我想給下單流程加一個優惠券校驗，回車即可。
grill-me 不會被 Agent 自動調用，只有你輸入時才觸發。它會把需求拆成一棵“設計樹”，每一輪把所有前置條件已經確定的問題一次問完。每道題都編號並附上推薦答案，措辭也特意設計成你回覆 yes 就等於接受推薦。一輪問答大致長這樣（示意）：
❓ Q1 – 過期按什麼時間判斷：按下單時刻，還是支付成功時刻？
➡️ 推薦：按下單時刻，避免用戶付款途中券突然失效。❓ Q2 – 滿減門檻是否包含運費？
➡️ 推薦：不包含，只看商品小計。❓ Q3 – 一筆訂單最多能用幾張券？
➡️ 推薦：一張。
這時最常見的失敗是一路回答“同意”。那樣只是給 Agent 寫的計劃蓋了章，你自己什麼都沒決定。更好的回覆是有取捨的，比如：
Q1 yes。Q2 不同意，我們的活動規則是含運費。Q3 不知道，要問運營，先按一張做。
下一輪的問題會建立在這些回答上，比如“含運費時，運費券和滿減券能否疊加”。如果問題需要查倉庫裏的事實，Agent 應該自己派子 Agent 去查，而不是來問你。官方文檔提到，四輪問下來累計四十多個問題屬於正常範圍。
做到這樣就算成功：
– 問題按輪出現，每題都有編號和推薦答案，回覆 yes 就能接受推薦
– 後面幾輪明顯建立在你前面的回答之上
– 你至少反駁過一次，或者認真說過一次“不知道”
– 結束時 Agent 先請你確認雙方已經達成共識，確認之前它不會動手，也不會寫任何文件
第 5 步：用 /tdd 一次一個測試地寫代碼
在同一個會話裏繼續，這樣剛剛建立的上下文都還在。必要時可以把模型換成更經濟的那一檔，然後輸入 /tdd 按剛纔確認的規則實現優惠券校驗。
它不會馬上寫測試，而是先列出準備測試的接口邊界（seam）並停下來等你確認。比如候選 A 是 validateCoupon(coupon, order, now) 這個純函數，能覆蓋規則邏輯，但測不到和下單流程的銜接。候選 B 是下單服務的 checkout()，能測到銜接，但更慢。如果它只給出名字，你就追問每個 seam 能抓到什麼、會漏掉什麼。這裏我們先確認 A。
下面是第一個測試的示例，用的是 TypeScript + Vitest。這只是演示，技能本身不限語言和測試框架：
- 測試文件：
coupon.test.ts，從vitest引入it和expect，從./coupon引入validateCoupon - 測試名：用戶不能使用已過期的優惠券
- 傳入的券：
{ code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") }，也就是滿 100 元可用、10 月 1 日到期 - 傳入的訂單：
{ subtotal: 120 }，小計 120 元 - 傳入的當前時間：
new Date("2026-10-22")。時間作爲參數傳入，不在函數內部讀取當前時間，這樣哪天跑結果都一樣 - 期望結果：
expect(result).toEqual({ ok: false, reason: "expired" })，即校驗不通過，原因是已過期
先運行測試，它會因爲 validateCoupon 還不存在而變紅。接着 Agent 只寫讓這個測試通過的最少代碼，比如判斷 now >= coupon.expiresAt 就返回過期。測試變綠後，纔開始寫下一個測試，例如“小計未達門檻時拒絕”。注意期望值是從規則推出來的字面量，測試名描述的是用戶能力，而不是“調用了某個內部函數”。
現在的 tdd 只有“紅→綠”，沒有重構階段。這個階段在 2026 年 6 月被去掉了，原因是 Agent 幾乎從不執行這一步，重構改由 /code-review 負責。技能描述裏仍寫着 red-green-refactor，這是已知問題，這個說法依然能觸發技能。mock 只用在外部 API、時間、隨機數這類系統邊界上，不要 mock 自己的模塊。
做到這樣就算成功：
– 寫任何測試文件之前，它先列出 seam 並等你確認
– 每次只出現一個測試，先紅後綠，然後才寫下一個，沒有出現“先一批測試、再一批代碼”
– 改個內部函數名，測試不會掛
何時用 grill-me、tdd 等技能及排錯清單
很多人卡住，不是因爲不會用，而是用錯了場景。下面這張表可以直接存下來，遇到不同情況時對照着選。
| 你的情況 | 用哪個 | 說明 |
|---|---|---|
| 想法還很模糊，不一定和代碼有關 | /grill-me | 不需要倉庫，不寫文件，商業決策、寫作也能用 |
| 在倉庫裏改代碼，希望沉澱術語和決策 | /grill-with-docs | 同樣的提問流程，會更新 GLOSSARY.md 和 ADR |
| 工作量一個會話裝不下 | /wayfinder | 在 issue tracker 上建立決策工單地圖，逐個解決 |
| 有明確輸入輸出的行爲要實現 | /tdd | 適合業務邏輯、請求響應契約、數據轉換、校驗 |
| 已有 spec 或工單，想讓它整體跑完 | /implement | 在約定的 seam 上驅動 /tdd，提交前跑 /code-review |
拿不準該用哪個時，可以輸入 /ask-matt，它會根據你的情況推薦合適的技能。實際使用中遇到的問題，大多能在下面這張表裏找到對應處理方式。
| 現象 | 常見原因 | 處理方式 |
|---|---|---|
| 問題太多，問到上百個 | 範圍太大，或上下文太滿導致提問質量下降 | 先讓 Agent 把工作拆小，再分別 grill |
| 很快結束，自己全程只說“同意” | 回答太被動 | 主動反駁、指出範圍漂移、如實說“不知道” |
| 某題反覆改寫也答不上來 | 屬於“聊不出答案”的問題，比如交互手感 | 停下提問，用 /prototype 做個一次性原型看看 |
| 選不出測試邊界 | 候選 seam 只列了名字 | 先追問每個 seam 能抓到什麼、漏掉什麼、慢多少 |
| 先寫了實現才補測試 | 模型的默認習慣 | 關鍵切片盯着運行，發現後讓它回到“先紅” |
| 瀏覽器測試陷入死循環 | 功能還不存在就先寫了端到端測試 | 在 CLAUDE.md 寫明瀏覽器測試等行爲跑通後再寫 |
| 測試只是把實現抄了一遍 | 配置、膠水代碼沒有獨立的對照答案 | 這類改動不走 tdd，可把規則寫進 CLAUDE.md |
| 每個技能出現兩份 | 插件和 skills.sh 都裝了 | 卸掉其中一種 |
mattpocock/skills 常見問題 FAQ
Q1：約 30 萬星，是不是說明效果一定好？
不是。星數反映的是關注度，不代表在你的項目裏的實際效果。作者自述基於幾十年工程經驗，但目前沒有第三方測評給出效率提升數據。最可靠的判斷方式，是對照本文每一步的驗收標準，在自己的倉庫裏實際跑一遍。
Q2：只能在 Claude Code、Codex 這些工具裏用嗎？
不是。官方列出的只是驗證過的裝法，沒有列出的 Agent 可以走 skills.sh，用 `-a` 指定或交互選擇。README 也說明這些技能適用於任意模型，本質上都是 Markdown 寫成的技能說明。
Q3：grill-me 問完之後，要不要開新會話再寫代碼？
不要。提問過程建立的上下文正是最有價值的部分。官方建議在同一會話裏繼續交給 /to-spec 生成規格。本文的小例子則直接在同一會話裏接上 /tdd。
Q4：覺得一輪問題太多，能改成一次只問一個嗎？
可以。在全局 `CLAUDE.md` 里加一句 `When grilling, ask one question at a time.` 就行。不過按輪提問能讓你一次看到所有可以決定的問題，建議先試幾次再決定要不要改。
Q5：爲什麼 tdd 描述寫着 red-green-refactor，實際卻不重構？
重構階段在 2026 年 6 月被有意移除，但描述還沒同步更新，這是一個已知且尚未關閉的問題。現在的流程是“紅→綠”，重構交給 /code-review。寫實現和做審查分成兩個會話，效果更好。
Q6：提問階段和實現階段想用不同模型，怎麼接最方便？
可以按本文第 3 步的配置方法，在 Claude Code 或 Codex 裏配置統一接口。通過 API易 apiyi.com 的一個 Key，就能在提問階段用 Claude Opus 5.5，寫實現時切到更經濟的模型。它只負責模型調用，技能本身照常安裝。
Q7：哪些改動不適合用 tdd？
配置、接線、膠水代碼、類型標註、直接轉發的增刪改查，這類改動沒有獨立的對照答案，測試很容易變成把實現抄一遍。官方承認技能目前不會幫你判斷“值不值得走 TDD”，需要你自己決定。拿不準時，可以先在 API易 apiyi.com 用一個輕量模型讓 Agent 列出這個改動的輸入和可觀察輸出，列不出來就不要用 tdd。
mattpocock/skills Key Takeaways 與總結
核心要點 Key Takeaways
- 先問後寫：先用 /grill-me 對齊需求，再用 /tdd 一次一個測試地實現
- 安裝二選一：插件和 skills.sh 只裝一種，否則每個技能都會出現兩份
- 依賴別漏：單獨安裝時，grill-me 要配 grilling，tdd 要配 codebase-design
- 主動回答：多反駁、多說“不知道”，一路“同意”是最常見的失敗
- 先確認 seam：tdd 先列出測試邊界並等你確認，然後紅→綠，不含重構
- 模型分檔：提問用最強的模型，實現可以降檔，用 API易 一個 Key 即可切換
總結
mattpocock/skills 的價值不在於約 30 萬星，而在於把“先對齊、再小步驗證”這兩條工程常識做成了可重複執行的技能。照着本文的 5 步走一遍：安裝、跑 setup、選模型、用 /grill-me 問清楚、用 /tdd 寫出第一個由紅變綠的測試，你就能判斷這套方法適不適合自己的項目。
如果你需要在提問階段和實現階段使用不同模型，可以通過 API易 apiyi.com 用一個 Key 在 Claude Code、Codex 裏完成切換。剩下的事，就是在真實需求上多練幾次，堅持主動回答。
參考資料
- GitHub – mattpocock/skills：倉庫主頁，包含 README 和全部 SKILL.md
- 鏈接：
github.com/mattpocock/skills -
說明：安裝方式、技能列表和更新記錄都以這裏爲準
-
AI Hero – Skills 文檔：grill-me、tdd 等技能的官方說明
- 鏈接：
aihero.dev/skills -
說明：包含“It’s working if”驗收清單和常見問題
-
skills.sh – mattpocock/skills：其他 Agent 的通用安裝入口
- 鏈接：
skills.sh/mattpocock/skills - 說明：適合 Cursor、OpenCode、Windsurf 等工具，需手動更新
作者：API易 技術團隊
技術交流：歡迎在 API易 apiyi.com 網站首頁聯繫我們，更多接入資料可訪問 docs.apiyi.com 文檔中心
