grill-me 实战：把一个模糊 idea 用对话压成可落地的决策

为什么这个技能值得专门写

2026 年 3 月，Matt Pocock 发了一条视频 《My ‘Grill Me’ Skill Went Viral》——一个 6 行的 Claude Code skill（让 agent 持续追问需求直到达成共识），随后在开发者社区被广泛采用。它和同年 4 月发布的 grill-with-docs 是两个不同用途的兄弟技能：前者是任何场合、任何主题都能开的对话式需求压实，后者是仓库内、带 CONTEXT.md 和 ADR 落盘的工程化版本。

我学完这个技能后，把它接进了已有的"需求模板 → 任务拆分 → 派活执行"流水线，在"人提一个松散 idea → 决定值不值得做"这个最前置的环节里塞一道 5-10 轮的"压实"关卡。本文记录这次学习的两个部分：方法论源头 + 真实实践。

方法论源头：四股历史力量的合流

grill-me 不是孤立发明的。它是 27 年软件工程里四个独立传统的合流——理解这四条线才能知道它的能力边界。

1. 橡胶鸭调试（1999-）

出处：Andrew Hunt, David Thomas, 《The Pragmatic Programmer: From Journeyman to Master》, 1999

程序员给一只橡皮鸭逐行解释代码，问题会在解释过程中"跳出来"。核心机制：强迫你把内部模型外化成语言——外化的瞬间，模型的漏洞就暴露了。

Matt 自陈 grill-me 的本质就是"rubber ducking 的 AI 化"——区别在于：(a) 鸭子不会反问，AI 会；(b) 鸭子不记得上一轮，AI 有上下文；(c) 鸭子不查代码，AI 不需要查代码——grill-me 跨出代码范畴，对任何 idea 都能用。

2. DDD 通用语言（2003-）

出处：Eric Evans, 《Domain-Driven Design: Tackling Complexity in the Heart of Software》, 2003 推广：Martin Fowler, “Ubiquitous Language”, 2006

Evans 提出的核心论断：复杂的业务系统里，开发者和领域专家必须用同一套词讨论问题。如果代码里的 “Account” 含义是财务账户、运营讨论时 “Account” 指用户账号、销售说 “Account” 是潜在客户名单——系统注定扭曲。通用语言就是把所有人口径对齐到同一张术语表。

grill-me 的对话过程就是建立这种对齐——只是对齐的对象不是"团队 + 领域专家"，而是"你 + 你脑子里的 idea"。

3. 架构决策记录 ADR（2011-）

出处：Michael Nygard, “Documenting Architecture Decisions”, Cognitect Blog, 2011-11-15 变体：MADR（Markdown ADR, 2017-）→ YADR（YAML ADR, 2026-03）

Nygard 的洞见：六个月后新人问"为什么当初选 PostgreSQL 不选 MongoDB"时，原作者可能已经离职，剩下的人靠记忆和传说不一定能复现当时的权衡。ADR 是一次决策的快照：上下文 + 决定 + 后果——1 页 Markdown，git 跟踪，5 分钟写完，半年后救命。

grill-me 不写 ADR——它是 ADR 之前的那一步：帮你把"为什么这么决定"想清楚，不写下来。如果之后要进工程化，grill-me 同会话可以无缝接 grill-with-docs 或 to-spec。

4. LLM 的不确定性 / 歧义检测（2025-）

工业界有最新数据给这套传统加注脚：ICSME 2025 工业研究（Requirements Ambiguity Detection with LLMs）表明，10-shot 提示比 0-shot 在歧义分类任务上平均提升 20.2%——给模型看 10 个歧义 vs 不歧义的例子，能显著减少它把模糊需求当成明确需求跑掉的情况。arxiv 2507.05981 的多智能体辩论实验（F1 0.726 → 0.841）则提示我们：多轮追问比多 agent 辩论更划算——前者和 grill 协议天然同构。

把这四股力量拼起来看：rubber ducking 提供"对话形式" → DDD 提供"对齐的目标" → ADR 提供"决策快照"（grill-me 不产出，但为它铺路）→ LLM 提供"执行者"。grill-me 是把这四块第一次用一个 6 行 prompt 装到一块的合流点——而且这个合流点完全 stateless，不污染任何工作区。

grill-me 协议本身：6 行 prompt 的解构

公开版本（mattpocock/skills）的核心文本（2026-08-24 更新版）：

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. If a question can be answered by
exploring the codebase, explore the codebase instead. For each question,
provide your recommended answer.

四句话各对应一个机制：

第四句是 Matt 后来加的（2026 年 3 月之后），改之前用户被 540 个无推荐问题淹没——加上之后，“是 / 否 / 改成 X” 比"自己想答案"效率高一个量级。

注意：grill-me 的 6 行 prompt 没有“写到 CONTEXT.md"或"建 ADR”——这是它和 grill-with-docs 的根本区别。grill-me 是 stateless（无状态），只在你脑子里留下一个"被压实的 idea"；grill-with-docs 是 stateful（带落盘），把术语和决策写进 CONTEXT.md 和 docs/adr/。

grill-me vs grill-with-docs vs wayfinder：三选一速查

grill-me 唯一不能用的情况是：你已经在另一段对话里写了一个完整 plan——那时该用 to-spec 把那个 plan 变成结构化文档，而不是再开 grill。

失败模式库：9 个坑的真实分布

Matt 在 2026-05 的 9 Things People Get Wrong 视频里把常见失败归成 9 类。我按"踩坑代价 × 发生频率"重新排序：

高频高代价（立刻影响交付）

1. 试图在 grill 会话里答高保真问题（hands-on 验证问题）

问"表单字段应该拆页还是一页"这种问题——你不实际看一版 UI 根本答不了。grill 会话里纯靠语言讨论，得不到新信息，只能编。Matt 提的解法叫 handoff 模式：

grill（低保真问题） → prototype（做一版 UI 看效果） → grill 回来继续

2. Scope 太大撑爆 context window

Grilling session 一般 45 分钟、累积下来的"决策密度"会在 context window 120k token 之后明显下降（Matt 称之为 “dumb zone”）。超 120k 之后模型开始丢三落四、立场漂移、答非所问。

解法：开局先让 agent 把大 scope 拆 grillable chunks，每个 chunk 单 session 跑。这正是任何任务拆分流程都在强调的"bite-sized 2-5 分钟任务"思路的会话级对应物。

3. 太被动——被 agent 反向 scope creep

passive vs active 是一根轴。passive 用户会被 agent 扔 540 个无意义问题，scope 失控；overly active 用户会陷入"在低保真细节上 grill 个没完"——问题在于你没判断"该写代码了就停"。

正确姿势：每个 session 开局明确"我打算这轮只问 3 类问题，问完就停"。

4. 选错模型

Grilling 强烈依赖模型的参数化知识（parametric knowledge）——不是你塞给它的上下文，而是它"先天知道的东西"，否则你提一个方案它反驳不出更好的。小模型 grill 不出好东西——它们没有足够的训练语料去提"你想过 X 吗"。

对我们的实际影响：grill-me 必须云端大模型——本地 8B 提不出"你考虑过 X 吗"这种主动挑战。

中频中代价（影响结果质量）

5. 清空 context 写 PRD = 扔掉所有决策

Grilling 跑完时，context window 装满了"为什么这么设计"的活证据。你想清理一下再来写 spec——大错特错。你刚把决策密度最值钱的部分扔了。

正确姿势：context 够就直接在同一个 session 接 to-spec（Matt 流水线第二步）；不够就并行开第二个 session 接续。

6. 假装有 domain 但其实没有

Matt 的金句：A domain language you do not understand yourself becomes meaningless drivel once written down. ——CONTEXT.md 不替代你的理解，只强制你的理解要精确。grill-me 不写 CONTEXT.md，但同样的原则适用：你不能在 grill 里"造出"你自己都不懂的判断。

判断手法：你能不能在 30 秒内给"什么是 X"一个别人能复述的定义？不能就别在 grill 里硬答——写出来只会变成 lore。

低频高代价（容易掉以轻心）

7. 把 ungrillable 问题当 grillable 处理

Matt 在 grill-me 页明确说：“One long form or three pages?“和"how should this interaction feel?“是 ungrillable——它们需要看到东西才能答。硬 grill 这种问题，session 会膨胀到失控：agent 一直重述问题，你一直猜，scope 长到塞满不确定性。

正确姿势：撞到 ungrillable → 停 grill → 开 prototype session 做一版实物 → 看完用一句话回来答。

8. 在已有 plan 的对话上 grill

Matt：“Start it in a fresh conversation, not on top of a plan you already had an agent write.” ——plan mode 会让 agent 急着出方案，正是 inquiry 的反面。grill 是还没有 plan 之前的对话；已经有 plan 之后该 to-spec。

9. 用"是/否/同意"刷过 40 个问题

Matt 的话：“The failure mode is passivity: answering ‘agreed, agreed, agreed’ for forty questions and coming out with a plan the agent wrote and you nodded at. It feels productive because it was long. Nothing was actually decided.”

这是最隐蔽的失败模式——你觉得自己做了很多事，但其实只有 agent 做了决定，你只是按了"同意”。正确姿势是"you disagree with something”——session 至少有一个问题你 pushback 过，那才是真 grill。

我们的实践姿势：嵌进现有流水线

大多数组织都已有"需求模板 → 任务拆分 → 派活执行"这条流水线（比如 SPEC 文档 + sprint 切分 + Jira 工单）。grill-me 的合理位置是最前面——比写模板还更早：

人提一个松散 idea（"我想做一个……"）
    ↓
[1] /grill-me 跑 5-10 轮（单 session, stateless, 30-45 分钟）
    ↓ 产出：
    ↓ - 你脑子里的 idea 从"模糊"变成"你能 defend 给没参与的人听"
    ↓ - 一段已结清的对话，装着所有"为什么这么决定"的活证据
    ↓
[2] 同一个 session 继续 → /to-spec 把对话压成结构化文档
    ↓（如果涉及代码改动才走这步；纯商业/写作决策可停在 [1]）
    ↓
[3] /grill-with-docs（如果有仓库，把术语锁到 CONTEXT.md、决策写到 ADR）
    ↓
[4] 用需求模板把 CONTEXT 翻译成 PRD（功能清单/边界/验收/不要做四件套）
    ↓（领域术语已锁 → 模板里的 "input/output/边界" 不会再被同名异义拖累）
    ↓
[5] 任务拆分：写 markdown plan，把需求切成 2-5 分钟可执行单元
    ↓
[6] 派活执行：人工或 AI agent 跑单元任务

关键：grill-me 同 session 接 to-spec——不要清空 context 另开新对话（失败模式 #5）。

实操节奏建议

• 每天 ≤ 2 次 grill——超过 2 次 context window 累计会进 dumb zone 的边缘
• 每个 grill 30-45 分钟封顶——不是模型死了，是人的耐心和精确度到顶
• 撞到 ungrillable 立即停——开 prototype session，不要在 grill 里硬编答案
• 判被动 vs 主动：session 末尾如果回看，至少一个问题你 pushback 过——否则这次没意义
• 不写 CONTEXT.md 不写 ADR 不是失败——grill-me 本来就是 stateless。真正失败的是"你出来之后说不清自己为什么这么决定”

触发条件

不是所有事都要 grill。建议自动 grill 的触发条件（任一）：

• idea 涉及 ≥ 3 个之前没明确命名的实体（“账号 / 订单 / 任务 / 凭据”）
• idea 涉及架构层切换（关系型 → 向量库 / 单体 → 微服务 / 同步 → 异步）
• idea 涉及"什么算成功"模糊（“做一个好用的工具”）
• idea 跨人 / 跨 agent 协作（交付物会被第三方接手）

不属于这些的（小修小补、单文件改动、明确 bug 修复）——直接 任务拆分 → 派活执行，grill 是杀鸡用牛刀。

边界与局限

grill-me 协议不解决的：

1. 不知道什么值得做——grill-me 只解决"想出来对不对"，不解决"该不该做"。后者需要市场/用户研究（任何 idea 在 grill 前都应该先验证"为什么这个值得做"）
2. 不知道怎么做——grill-me 帮你对齐"做什么"，怎么做交给 TDD + implement
3. 不能替代批判性思维——Matt 自己承认，glossary 对 agent 性能是否有提升有公开争议
4. 必须用大模型——本地 8B 跑 grill-me 提不出有意义的挑战
5. 不污染工作区的好处也是坏处——你下次再 grill 同一个 idea，得重新跑一遍。grill-with-docs 的落盘机制在这一点上更稳

grill-me 当前的已知约束（Matt 自陈）：

• 撞到 ungrillable 问题，agent 不会主动提醒——你要自己识别（看 session 是不是在同义反复）
• session 结束消息倾向开放——不像 to-spec 那样有明确出口。主流程的答案是同一 session 接 to-spec
• 没有任何 ledger 把"grill 出来的决策"持久化到 CONTEXT.md / docs/adr/——这是 grill-with-docs 的事

收尾

Grill-me 协议的本质不是"一个新工具"——是软件工程里"通用语言"和"决策记录"两个老传统，被 LLM 时代重新包装成一段 6 行 prompt。它解决的不是工程问题，是想法问题：当一个松散 idea 经过 5-10 轮追问变成你 defend 得过的决策，复杂项目的扭曲点会少一半。

但它有真边界：依赖大模型的参数化知识、依赖单 session 的 context window、依赖你能持续主动 pushback。一周用它两次以下收益最高；当成万能仪式开每个会都跑——会变成新形式的"填表主义"。

对我来说最有价值的不是 skill 本身——是它强迫我把"我为什么想做这个"想清楚再动手这件事。CONTEXT.md 只是一张快照（grill-me 不写）；真正的工序是 grill 过程中的"你刚才说的 A 和我现在 pushback 的 A 是不是一个 A"那种自问。

附录 A：Rigor Gate 14 项自查

结论：14/14 通过。

附录 B：来源清单

上游原始资料

• Matt Pocock, “The /grill-me Skill”, https://www.aihero.dev/skills-grill-me（2026-08-24 更新）
• Matt Pocock, “9 Things People Get Wrong With /grill-me and /grill-with-docs”, https://www.aihero.dev/things-people-get-wrong-with-grill-me-and-grill-with-docs（2026-05-25）
• Matt Pocock, “My ‘Grill Me’ Skill Went Viral”, https://www.aihero.dev/my-grill-me-skill-has-gone-viral（2026-03-23）
• Matt Pocock Skills 仓库, https://github.com/mattpocock/skills

对照（grill-me 的兄弟技能）

• Matt Pocock, “The /grill-with-docs Skill”, https://www.aihero.dev/skills-grill-with-docs（用作三选一速查对照，不是本文主轴）
• Matt Pocock, “The /wayfinder Skill”, https://www.aihero.dev/skills-wayfinder（多 session 决策地图，本文仅作选型对比）

历史脉络

• Andrew Hunt, David Thomas, The Pragmatic Programmer, Addison-Wesley, 1999（rubber duck debugging 首次印刷于该书）
• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003
• Martin Fowler, “Ubiquitous Language”, 2006-10-31
• Michael Nygard, “Documenting Architecture Decisions”, Cognitect Blog, 2011-11-15
• Olaf Zimmermann et al., MADR (Markdown ADR) Template, 2017-（YADR 2026-03 衍生）

学术支撑

• Ahmad Bashir et al., “Requirements Ambiguity Detection and Explanation with LLMs: An Industrial Study”, ICSME 2025 Industry Track（10-shot 相对 0-shot 提升 20.2%）
• arxiv 2507.05981, “Multi-Agent Debate in Requirements Engineering”（F1 0.726 → 0.841）