最近，grill me 这个 skill 变得非常的流行。很多人在一番比较之后，得出了「grill me 比 superpowers 更好用」的结论，也有很多人抛弃了原先的工作流转向使用 grill me。
但是，grill me 也是一个非常特殊、甚至有些怪异的 skill，你在第一次用它的时候，一定会对它的「连环盘问」非常不习惯。很多 skill 都是想帮你一次性把事情做完。grill me 反其道而行之，不把问题问清楚不罢休，一次问个 40 个、60 个问题都不稀奇。
为什么这样一个怪异的 skill 会被一堆人说好用呢？
其实，它只专注于一件事：让 AI 真正理解你想要做的事。
我们团队用 grill me 也有两个月的时间了，今天我想聊聊这个神奇的 skill 究竟该如何使用。
什么是 grill me
Grill me 的原文在这里：https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md
作为一个 skill，它的内容非常的短，只有四段话（早期甚至只有两段话）：
Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision 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 fact can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer.
Do not act on it until I confirm we have reached a shared understanding.这样短短的几句话，究竟有什么魔力呢？
Grill me，解决的是「意图对齐」
有一定 AI 编程经验的人，大体都会同意这个观点：越是复杂的项目，在维护的时候，越是需要仔细地梳理方案。希望通过一句话的「许愿」就让 AI 产出自己想要的结果，很大概率上是不可行的。
流行的 SDD (Spec-Driven Development) 很大程度上就是为了解决这个问题。在做任何修改的时候，都先让 AI 写出 spec 文档。一方面能让 AI 自己先梳理好方案，避免盲目动手；另一方面能让人评审下 AI 的方案，如果和自己想要的有偏差，可以及时打回重改。
听起来很美好，但是实际用起来，完全不是那么一回事。
不知道你有没有和我一样：当 AI 写出 spec 之后，根本懒得评审，最多草草看一眼，就直接让它开干了。甚至一眼都懒得看。
一开始我还以为是自己太懒，后来才发现，这件事的根本症结在于：AI 产出的 spec，我大概率看完总是觉得「没问题」，看了也白看。
为什么会这样？
因为 AI 非常擅长生产「看起来像样的垃圾」。如果你让 AI 写过论文、写过述职报告，体感大概率会特别强烈。LLM 的天生特性让它擅长拟合出一堆看起来还不错的文字。但是在关键的论点、数据、引用中，总是有哪里不太对。
AI 写设计方案（spec）也是一样的。它可以吐出一段结构清晰、措辞专业的实现计划，让你看起来就想回复「looks good, go ahead」，但是其中的模糊地带，都被它忽略掉了：
- 「做一个用户友好的 X」—— 用户友好是啥意思？
- 「必要时添加 Y」—— 啥时候算必要？
- 「参考现有实现」—— 参考哪个实现？
这些问题你在一开始不会注意到，而是往往到 Agent 写完代码才发现。正是这些意图没有对齐的地方，往往会让你非常难受，来回返工。
那么，有没有办法，能让 AI 一次性把意图跟我对齐，把我真正想要的理解清楚呢？
有的，grill me 它来了。
只要你用过一次 grill me，就会发现，它能够从各个角度向你提出问题，主动对齐意图。一轮轮对话问完，你自己的心里也会非常有底，明白 AI 已经考虑得非常全面了，接下来的实施过程不会有太大的偏差。
找出你没意识到的不确定性
那么，为什么 grill me 能如此有效呢？
核心在于 skill 中的这句话：
Interview me relentlessly about every aspect of this until we reach a shared understanding.这句话做了一个关键的「角色翻转」，平时我们都是主动写 Prompt，指挥 Agent 做事情。现在控制权反了过来，让 AI 针对不确定的问题来问我们。
这样一来，我们就再也不需要去「预料」AI 可能不理解的地方。AI 如果有不理解的，它自然会反过来问我们。
这背后的原理，在于没意识到的不确定性。
在使用 grill me 的时候，你可能会发现：很多问题你可能一开始就没有考虑过，是在一轮轮的问答中挖掘出来的。而如果没有这些问答，大概率 Agent 会按照你错误的想法去执行，然后返工。
Claude 工程师 Thariq Shihipar 有一篇关于「如何在用 AI 做复杂任务时避免失控」的文章，其中分享的核心观点就是：不要一上来就让 AI 做事，而是先让它帮你把自己没意识到的不确定性找出来。
因为在 AI 不断变强的情况下，主要的瓶颈从 AI 能不能写出代码实现，变成了人有没有把问题说清楚。「未知的盲点」本身成为了最大的风险。
如果把我们熟悉的已知未知四象限套用到 AI 编程中来，其中 known 的部分都是容易的：
- Known knows：这就是我们写的 Prompt，它的意思是非常明确的，你也知道自己想要什么
- Known unknowns：一般是一些不太确定的方案，需要调研跟讨论的，这些问题弄清楚也不难
真正难的是 unknown 的部分：
- Unknown knowns：你没有告诉 AI，但是你以为 AI 会遵循，但是有些时候，AI 可能真的不明白
- Unknown unknowns：这便是你在使用 grill me 的时候，突然发现的自己一开始根本没考虑过的问题，如果用普通的 Prompt，根本发掘不出来
因为未知，所以是盲点。要么是我们不知道 AI 不知道，然后发现 AI 偏离了我们的意图，要么就是我们不知道自己不知道，导致 Prompt 可能一开始就给了一个错误的需求或者方案。
Grill me 最大的作用就是在处理这些 unknown 的问题上。它始终抓着一些模糊的地方进行提问，在这些模糊的地方，很可能就隐藏着最大的未知和不确定性。
也许它问的问题你觉得很啰嗦，但是只要能发现这样一个盲点，就直接回本了。
如何使用 grill me
主动引导
在使用 grill me 的时候，不要一味地回答 yes 或者 no。如果这样的话，回答的意义不大，而且你会迅速变得无聊，成为回答 yes 的无情机器。
要始终谨记：grill me 的真正目标是帮你找到未知的盲点。
我会把一些我觉得需要讨论的点抛给它，让它在对话的过程中跟我讨论，有意地引导它向我最需要的讨论点前进。
我使用 grill me 的时候，对于不同问题的回答风格非常不一样：
- 如果是我很在意的问题：详细回答，并说明我的思路，然后再回抛一些更深入的问题让它思考。
- 如果是常规的我预料之中的问题：回答 yes。
- 如果是它给出了我反对的推荐方案：回答 no，并且强调我的思路。
- 如果我看不懂它的问题：直接说我看不懂，让它重新解释，直到我能明白为止（这时候一定不要偷懒）。
- 如果我发现它在纠结一些细节的实现方案：直接拒绝回答，并且让它不要再问任何过于细节的问题。
使用轻量级的框架
很多人在用了 grill me 之后，坚定认为 grill me 比 superpowers 好。
其实，grill me 的风格和 superpowers 大相径庭。superpowers 全面，试图包圆你的整个开发流程，grill me 极简，你需要结合自己的场景来灵活使用。但是它们都能起到一个作用：避免 Vibe Coding 产出一堆垃圾。
不过，越是有经验的开发者，grill me 所能起到的加成越大。
因为 superpowers 是保下限，能从 60 分提升到 80 分；grill me 是提升上限，能从 80 分提升到 90 分。
而现在随着模型能力的不断增强，即使不用任何 skill，Agent 本身也能达到差不多 80 分的水平了，这个时候，superpowers 这种保下限的 skills 就很难有用武之地了。这也是很多人发现，GPT 5.6 用了 superpowers 效果甚至不如不用的原因。
我自己的使用经验是，使用 grill me 搭配一个轻量级的 SDD 框架就好。Grill me 单独使用的话有些单薄，我们可以在 grill me 结束之后，把 grill 的结论记录到 spec 里，接下来让 Agent 自己实施就好了。我用的是自己写的超轻量 SDD 框架 zest-dev，你也可以用 OpenSpec 这样的 SDD 框架。但是更重量级的 SDD 框架就不推荐了。