grill-me 从入门到精通：Matt Pocock 技能宇宙中最出圈的那个"追问机器"

入口只有 1 行代码，引擎只有 7 行正文。凭什么在 GitHub 拿下 17 万 Star，全仓库累计 610 万次安装？

答案不是因为技术有多复杂——恰恰相反，是因为它够简单。简单到只做一件事，而且做到极致：在写代码之前，先把话说清楚。

本文对 grill-me 最彻底的一次拆解。从零基础到源码级理解，看完你不仅能用好它，还能理解它背后的设计哲学——并且把这些哲学用在你自己的 Skill 开发里。

---

快速导航

章节	适合谁
一、它是什么	所有人
二～三、生态分量 + 三层进阶	想理解全貌的人
四～五、源码精读 + 设计哲学	想自己写 Skill 的人
八、决策指南	不确定要不要用的人

---

一、一句话说清楚：grill-me 到底是什么

grill-me 是一个让 AI 反过来面试你的 Skill。 但它本身极其简单——整个文件只有 1 行代码：

Run a `/grilling` session.

对，就这一行。grill-me 只是一个入口，真正干活的是另一个 Skill：grilling。grilling 才是那个 7 行正文的追问引擎。grill-me 的职责只有一个：当你喊 /grill-me 的时候，把 grilling 唤醒。

这个设计极其聪明——grill-me 标记为 disable-model-invocation: true，只有你主动调用时才触发，不会占用 AI 的上下文窗口。而 grilling 是 model-invoked，可以被其他 Skill 复用。

所以下文提到"追问逻辑"的时候，说的都是 grilling 引擎，不是 grill-me 本身。记住这个区分，整个设计哲学你就能看懂。

grilling 引擎做了什么？ 在写代码之前，AI 会像审讯官一样，沿着你计划中的每一个决策分支，一次一个问题地追问——直到你们两个对"到底要做什么"达成完全一致。

"Interview me relentlessly about every aspect of this plan until we reach a shared understanding."

不是 AI 帮你做决定。是 AI 让你意识到哪些决定还没做。

它解决的是 AI 编程的第一失败模式：Agent 没做你想要的——因为你要什么，连你自己都没想清楚。

三个核心特征：

1. 一次只问一个问题

   ——反对批量提问。Matt 的原话是"一次问多个问题会让人困惑（bewildering）"

2. 每个问题附带推荐答案

   ——降低你的决策疲劳。你只需要说 Yes / No / It depends

3. 能从代码库查到的，不问你

   ——只有真正需要你做取舍的决策，才会端到你面前

典型的 grilling session：15-50 个问题，30-60 分钟。少于 5 个说明需求写太细了（不需要 grill），大于 50 个说明范围太大需要拆分。

---

二、它在 mattpocock/skills 生态中的分量

数据告诉你它有多重

以下数据来自 skills.sh 实时统计（截至 2026 年 7 月）：

指标	数据
GitHub Stars	17 万+（仓库整体）
总安装量	610 万+（全仓库 50 个 Skill 累计）
grilling 引擎安装量	26.6 万
skills.sh 排名	**第 3 位**（Matt 一人占了 Top 10 中的 3 席）
核心代码行数	7 行正文（grilling 引擎）

架构分量：它是所有高阶 Skill 的底层原语

整个 mattpocock/skills 仓库有 50 个 Skill。grilling 不是"其中之一"——它是被其他 Skill 反复调用的底层引擎：

grilling（7行正文追问引擎）
   ├── /grill-me          纯对话版，无代码库
   ├── /grill-with-docs   追问 + 产出 CONTEXT.md + ADR
   ├── /triage            追问 Issue → 分类 → 写开发说明书
   ├── /codebase-design   追问架构决策
   └── /wayfinder         把大项目拆成并行 grilling sessions

一个 12 行的文件，被 5 个不同的 Skill 复用。 这就是"单一真相来源"（Single Source of Truth）的威力。如果追问逻辑要在每个 Skill 里重复写一遍，改一次要改 5 个文件，而且很快就会出现行为漂移。

Matt 把这个 12 行引擎放在 skills/productivity/grilling/SKILL.md，标记为 model-invoked——模型可以自动调用它，其他 Skill 也可以委托给它。

而用户直接使用的 /grill-me 只有 1 行正文，标记为 user-invoked——不占用模型的上下文窗口。它唯一的指令就是：

Run a /grilling session.

---

三、从入门到精通：三个层次

Level 1：`/grill-me` — 纯对话版

适用场景：没有代码库，纯聊天打磨想法。

怎么用：在任何 Claude Code 会话里输入：

/grill-me 我想做一个用户头像上传功能，支持裁剪

然后 AI 开始追问：

Q1: "图片来源是本地上传还是 URL 引用？我建议本地上传，因为你需要裁剪功能，裁剪通常在前端做，需要用到本地文件。对吗？"

Q2: "存储位置你倾向 S3 还是本地文件系统？我建议 S3，因为你后续会做 CDN 加速。对吗？"

Q3: "裁剪在前端做还是后端做？我建议前端，用 react-image-crop 这个库，5MB 限制、1:1 输出 200×200。你觉得呢？"

每一个问题都带推荐答案，你只需要点头或摇头。 6 个问题、2 分钟，所有模糊点变成了明确的技术决策。

这个层面你只需要记住一句话：/grill-me 是对话工具，不碰文件，不产生代码。追问结束后的产出——全在你的脑子里和聊天记录里。

---

Level 2：`/grill-with-docs` — 代码库版 + 自动沉淀

适用场景：有代码库，需要把追问结论固化到项目文档中。

核心区别：在 grilling 引擎的基础上，同步运行 /domain-modeling：

产出的文档	作用	写什么
`CONTEXT.md`	项目术语表	所有领域术语的精确定义
ADR（架构决策记录）	硬决策归档	只记录**同时满足三个条件**的决策

ADR 的三个条件：不可逆 + 脱离上下文会困惑 + 确实做了取舍。

不满足这三个条件的决策，不写 ADR。Matt 自己的项目里，ADR 目录通常不超过 10 个文件。

Level 2 的关键认知：grill-with-docs 解决的不仅是"这次把需求说清楚"，更是"下次换一个会话 / 换一个人，不需要重新说清楚"。共享语言（CONTEXT.md）让每一次 AI 会话都变得更短、更精准。

Matt 自己的 course-video-manager 仓库里有一个经典案例：

一段长达 15 个单词的啰嗦描述，被精炼成了一个术语——"materialization cascade"（物化级联）。此后每一次 AI 会话，因为有了这个共享词汇，描述从 15 个词变成了 2 个词。

---

Level 3：`grilling` 引擎 + 你写的 Skills

适用场景：你自己写 Skill，想复用追问机制。

怎么用：在你的 SKILL.md 里，不需要重写追问逻辑。直接引用 grilling 引擎：

# 在你自己写的 Skill 里：
  执行以下步骤：
  1. 运行 /grilling session，确认用户需求和技术边界。
 2. 追问结束后，进入实现阶段……

因为 grilling 是 model-invoked，你的 Skill 可以直接调用它，不用复制粘贴。这就是 Matt 架构里最聪明的地方：把追问能力做成一个可复用的组件。

你需要理解的是 grilling 引擎的设计原则（下一章），这样你才知道什么时候该调用它、什么时候该自己写追问逻辑。

---

四、源代码精读：12 行凭什么能打

先看完整源码。这是 skills/productivity/grilling/SKILL.md 的全部内容：

---
 name: grilling
 description: Grill the user relentlessly about a plan, decision, or idea. Use
   when the user wants to stress-test their thinking, or uses any 'grill'
   trigger phrases.
 ---
  Interview me relentlessly about every aspect of this plan until we reach a
 shared understanding. Walk down each branch of the design tree, resolving
 dependencies between decisions one-by-one. For each question, provide your
 recommended answer.
  Ask the questions one at a time, waiting for feedback on each question before
 continuing. Asking multiple questions at once is bewildering.
  If a question can be answered by exploring the codebase, explore the codebase
 instead.

正文只有 7 行。 我们逐行拆解。

第一块：定义任务 + 完成标准

*Interview me relentlessly about every aspect of this plan until we reach a shared understanding.*

"relentlessly" 是整个文件最重要的词。它不是 "carefully"（仔细地）、不是 "thoroughly"（彻底地）、不是 "comprehensively"（全面地）——这三个词在 LLM 的默认行为里全是 no-op（不改变行为的废话）。

"Relentlessly" 告诉模型：这次的追问比平常的"彻底"更猛，不要因为觉得够了就停。 一个词完成了 20 行指令才能达到的行为锚定。

"until we reach a shared understanding" 是完成标准（completion criterion）。它必须是可检查的——模型自己能判断"理解了"还是"还没理解"。好的完成标准不需要人类介入验证。

"relentlessly" 锚定的是橙色菱形的那一步——它能自检"够不够"，所以不会问到一半就停了，也不会无限追问。

而如果没有这个自检条件，就会变成：

左边是 carefully / thoroughly / comprehensively 的效果：普通词汇没有锚定行为，模型要么过早停止（觉得"够仔细了"），要么无休止追问（不知道什么时候算结束）。右边 relentlessly + shared understanding 的组合：一个词定义了强度，一个短语定义了出口。

第二块：决策树遍历算法

*Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.*

"design tree" 来自 Frederick Brooks 的经典著作《The Design of Design》。LLM 的预训练数据里有这个概念的完整知识——设计是一个树形结构，每个节点是一个决策，每个分支是一个选择。

这一行包含了一个隐式的遍历算法：

1. 从根节点（最高层目标）开始

2. 沿一个分支走到底

3. 回溯，走下一个未遍历的分支

4. 重复直到所有分支都被访问

每个分支的终点是三种状态之一：

• DECIDED

  （已决定）——可以走

• RABBIT HOLE

  （兔子洞）——有价值但现在不挖，标记后跳出

• NO-GO

  （不可行）——死路，排除后跳出

深度优先遍历顺序：决策 A → 走到底（A1→DECIDED）→ 回溯 → A2→RABBIT HOLE → 回溯 → A3→NO-GO → 决策 B → …

"provide your recommended answer" 是把决策成本从"创造"降为"判断"。你不必从零构建答案，你只需要判断 AI 的推荐是对是错。

第三块：反批量提问

*Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.*

这一行是 v2 版本加的。Matt 观察到，不加这一行時，模型在约 25% 的会话中会一次性抛出 3-5 个问题。

加了 "bewildering" 之后，批量提问率降到接近零。

为什么是 "bewildering" 而不是 "bad practice" 或 "forbidden"？

因为 LLM 对 "bewildering" 有情感共情——它在训练数据里见过无数人类描述被信息轰炸時的困惑感。"Bad practice" 只是一条规则，LLM 会在边界条件测试中自我合理化地违反它。"Bewildering" 让 LLM 理解了人类感受——它不是在违反规则，是在让人困惑。

这是一个单一词汇改变行为模式的经典案例。

关键不是模型"学会了一条规则"——规则会被绕过去。关键是 "bewildering" 让模型产生了情感共情：它不是在违反规则，是在让人类困惑。

第四块：事实 vs 决策

*If a question can be answered by exploring the codebase, explore the codebase instead.*

全文件最重要的 6 个英文单词。这行解决的是 LLM 的天然缺陷：分不清"能从代码库查到的事实"和"需要人类做决定的取舍"。

这也是 v1.1.0 的 bug fix。之前某些 workflow 里，Agent 会替用户回答决策问题——把"我猜你想用 PostgreSQL"当成事实写进代码。

现在它被训成了：先用工具读代码，读到答案就闭嘴；读不到才开口问。

v1.1.0 之前没有这个分支判断——Agent 把"我猜你想用 PostgreSQL"当事实写进代码。加了这行之后，事实走左边的绿色通道，决策走右边的蓝色通道，两个不再混淆。

---

五、设计哲学：Matt Pocock 的 Skill 写作方法论

理解 grilling 的源码只是第一步。理解它背后的设计哲学，你才能在自己的项目里做出同等质量的 Skill。

这套哲学来自 Matt 的 /writing-great-skills 元技能（83 行 + 配套 GLOSSARY.md）。以下五个概念是核心。

1. Leading Words（引导词）

Leading Word = 一个在模型预训练数据中已经深度理解的紧凑概念。不需要重新教，只需要激活。

在 grilling 中出现	模型已有的知识	省掉了多少行指令
grill	审讯式追问、单刀直入、不给面子	~15 行
relentlessly	不达目的不停手	~20 行
design tree	树形结构、分支遍历、叶子节点	~25 行
bewildering	人类被信息轰炸的困惑感	~10 行

对比 Superpowers 的 689 行：不是 Matt 偷懒，是两种哲学。Superpowers 假设模型会找一切机会逃逸，所以堵死每一个路径。Matt 假设模型已经懂得大部分概念，你只需要用 Leading Words 激活它们，然后用精确定位的行为约束（不是堵逃逸，是给正确方向）来校准。

2. Progressive Disclosure（渐进披露）

Skill 的内容不应该全部堆在一个文件里。应该按"模型需要它的紧急程度"分层：

Layer 1: SKILL.md 主体（~50 行以内）
   ↓ 每一步有明确的 completion criterion
  Layer 2: 同目录下的 references/ 文件
   ↓ 用 context pointer 引用
  Layer 3: 外部文件（代码库、文档、网站）
   ↓ 只在必须时才加载

grilling 做到了极致：引擎 7 行在 Layer 1，调用它的 Logic（triage、grill-with-docs 的追问策略）在各自的调用层，文档产出逻辑（domain-modeling）在 Layer 2。

3. Negation Discipline（否定纪律）

否定式指令会适得其反。"别想大象"就是在脑子里画大象。

grilling 全文没有一个 "don't"。看它如何避坑：

坏写法（否定式）	grilling 的实际写法（正向 + 解释）
Don't ask multiple questions at once.	**Ask the questions one at a time.**
Don't overwhelm the user.	Asking multiple questions at once **is bewildering**.
Don't answer your own questions.	**If a question can be answered by exploring the codebase, explore the codebase instead.**

第三条是最漂亮的——它不是禁止 LLM 自问自答，而是给它一个更正确的替代行为。LLM 不需要压抑冲动，它只需要走另一条路。

4. Completion Criterion（完成标准）

每个 Skill 的每一步都需要一个模型自己能检查的完成标准。

grilling 的完成标准设计得很精妙：

• "until we reach a shared understanding"

   ——模型能自检（用户说"对"、"明白了"、"可以了"）

• "each branch of the design tree"

   ——树遍历的隐喻自带检测（所有分支都访问了 → 完成）

差的完成标准："把需求想清楚"——什么叫清楚？模型不知道。

好的完成标准："设计树的每个分支都被标记为 DECIDED / RABBIT HOLE / NO-GO 之一"——模型能数出来还剩几个分支没走。

5. Sediment（沉积物）与 Deletion Test

Sediment = 随着时间推移堆积在 Skill 文件里的无效指令。多人协作修改、版本迭代、补丁叠加——慢慢地，文件里塞满了"写了但没用"的东西。

Deletion Test：删掉一行 → 跑一轮 → 看行为变了没。没变 → 这一行是 sediment → 永久删除。

Superpowers 的 writing-skills 有 689 行。做了 deletion test 能剩下多少？不知道——但是如果 689 行里有 200 行是沉积物，那这 200 行除了吃掉上下文 token 之外毫无作用。

grilling 的 12 行里，每一行都通过过 deletion test。

---

六、实战全流程：从模糊想法到明确决策

这里用一个完整的例子展示 grill-with-docs 的实战流程。

场景

一个 Todo 应用，用户说："先实现新增、完成、过滤三个能力。"

Step 1：启动 grilling

/grill-with-docs 我要做一个 Todo 应用。先实现三个核心能力：新增 todo、标记完成、按状态过滤。请先问我实现前必须确认的问题，不要直接写代码。

Step 2：AI 逐问，你逐答

AI 一次一个问题，逐层递进：

层	问题	你的回答	分支状态
数据	要不要持久化？建议 localStorage。	同意	DECIDED
架构	状态来源要不要单一化？建议单一状态树。	同意	DECIDED
模型	完成态怎么存？建议 boolean 字段。	同意	DECIDED
功能	过滤要支持哪些视图？建议全部/未完成/已完成。	同意	DECIDED
交互	新增输入方式？建议输入框 + 回车键。	同意	DECIDED
架构	运行形态？建议单页 Web 应用。	同意	DECIDED
数据	是否需要初始示例数据？建议 3 条。	同意	DECIDED
UI	空白内容怎么处理？建议提示"还没有任务"。	同意	DECIDED
范围	是否支持删除和编辑？	先不支持	RABBIT HOLE
排序	列表排序规则？建议按创建时间倒序。	同意	DECIDED
实现	唯一标识怎么生成？建议时间戳 + 随机数。	同意	DECIDED
UX	新增后输入框是否自动清空 + 聚焦？	是	DECIDED
交互	完成切换：点击整行还是只点复选框？	整行点击	DECIDED
持久化	过滤条件要不要持久化？	URL 参数	DECIDED

14 个问题，约 15 分钟。 所有模糊地带被扫清。此时才开始写代码——而且不会出现"写了半天发现不是我想要的"那种情况。

Step 3：沉淀

grill-with-docs 自动做了两件事：

CONTEXT.md 更新：

- **todo**: 一个任务项，包含 id、文本、完成状态、创建时间
 - **单一状态树**: 所有 todo 存在一个顶层的 `todos: Todo[]` 数组中
 - **过滤视图**: all（默认）/ active / completed，通过 URL 参数 `?filter=` 持久化

ADR 归档：（本例中没有满足"不可逆 + 会困惑 + 有取舍"三个条件的决策，所以不创建 ADR）

Step 4：进入实现

/to-spec       → PRD 文档，提交到 GitHub Issue
 /to-tickets    → 拆成垂直切片任务卡片
 /implement     → 按 ticket 逐一实现（驱动 /tdd + /code-review）

关键约束：Step 1-3（grill → spec → tickets）必须在同一个不中断的上下文窗口完成。拆分任务后，每个 ticket 可以开新会话独立实现。

---

七、9 大避坑指南（来自 Matt 官方视频）

四组经典对比，每组都是"把坑反过来就是最佳实践"。

Matt 在 aihero.dev 上发过一个视频《9 Things People Get Wrong With My /grill-* Skills》。以下是精华浓缩版：

#	错误	后果	正确做法
1	**混淆低保真和高保真问题**	争论表单布局 10 分钟没结论	"这个表单应该两栏还是三栏？"→ 切 /prototype 做个原型，30 秒就有答案
2	**范围太大**	50+ 个问题还没停，上下文爆炸	让 AI 帮你拆成小块，分 session 追问
3	**太被动**	被 AI 带着跑了 45 分钟，很多问题显然可以跳过	主动说"这个方向正确，直接推进到下一层"
6	**用弱模型做 grilling**	AI 提的问题全是虚的（"你希望什么风格？"）	Grilling 用前沿模型（Opus/Sonnet，高推理 effort）；写代码可以用弱模型
7	**不跑并行 session**	大项目追完整棵决策树要 2 小时	拆成多个聚焦的 grilling session，两个窗口并行跑
8	**把能从代码库查到的反过来问你**	AI 问"现在用的是什么数据库？"	明确指令：能从代码库查的不问我（这是 grilling 引擎内置的）
9	**跳过 grilling 直接 Plan Mode**	AI 产出看起来很专业但核心假设全错的方案	永远先 grill 对齐 → 再 plan → 再执行

再多说一句第 6 条（用弱模型）

这是被低估的坑。grilling 和其他 Skill 不一样——它对模型质量极度敏感。因为 Good questions come from the model's parametric knowledge（好问题来自模型的参数化知识）。你问一个小模型"这个 API 设计还有什么我没考虑到的？"，它的参数化知识里可能就没有 edge case 的概念。

Matt 的建议是：grilling 阶段用你能承受的最强模型，写代码阶段随意。

---

八、什么时候该用，什么时候别用

✅ 应该用 grilling 的场景

• 复杂改动、多分支决策、意图模糊

• 跨模块重构、数据模型或 API 形态修改

• 涉及大量领域术语

• 做错后的返工成本高

• 后续其他 Agent 要继续同个计划

❌ 不应该用的场景

• 改一行配置、修一个明确 bug

• 你能用一句话写清楚：目标 + 范围 + 禁止事项 + 验收标准

• 单文件内的改动

判断标准：你能在一句话里写清楚「要什么 + 不要什么 + 怎么算做完」，就不必 grill。写不出来——先别让 AI 动代码。

不同阶段的推荐用法

阶段	推荐	说明
大项目（方向不明确）	`/wayfinder`	先画地图，再启动并行 grilling
改小东西	不开 grind	直接写代码

---

九、小结

这篇文章的核心认知

grill-me 表面上看是一个"AI 追问工具"。但往深了看，它是 Matt Pocock 的 Skill 设计哲学的完美样本：

• 12 行代码

  ，靠 Leading Words 激活模型的先验知识，而不是重教

• Progressive Disclosure

   分层信息，引擎 7 行在底层，调用者各自在轻量层

• Negation Discipline

   全文没有 "don't"，用正向指令 + 情感锚点（bewildering）替代

• Completion Criterion

   树遍历隐喻自带检测，模型自己知道什么时候做完

• Deletion Test

   每一行都通过过——删掉任何一句，行为就会退化

"Skill 是消耗品，用完就扔。" — Matt Pocock

连 grill-me 的作者自己都已经换了——Matt 现在用 grill-with-docs 和 domain-modeling。这不是说它不好，是说工具为阶段服务，阶段变了，工具就换。

但 grilling 引擎的 12 行设计哲学——Leading Words、Progressive Disclosure、Negation Discipline——不会过时。它们是你写任何 Skill 的底层方法论。

---

现在该你动手了

# 安装全家族
 npx skills@latest add mattpocock/skills
  # 初次使用前先初始化
 /setup-matt-pocock-skills
  # 然后试试
 /grill-me 我想做一个小程序，帮我先想清楚再写代码

如果想了解 grilling 引擎背后的完整设计方法论，去看 Matt 的 /writing-great-skills 技能——83 行 + GLOSSARY.md，比任何教科书都实用。

---

*关注本号，获取更多 AI 编程工具深度拆解。*

*本文核心素材来自：mattpocock/skills GitHub 仓库、aihero.dev 多篇官方文章及视频、社区实测反馈、Superpowers 对比分析、writing-great-skills 元技能文档。*