作者注：本文带你零基础跟做 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 文档中心
