拷问

它的作用¶

grilling 是在任何人采取行动之前，对计划、决策或想法进行压力测试的访谈循环。它将主题映射为一棵设计树：每个决策都会分支出依附于它的决策，并逐分支向你访谈，直到没有任何假设仍未被明确。

它不会一次只问一个问题，也不会一次性问完所有问题。每个轮次都会询问整个前沿：所有前提条件已经确定的决策，且仅此而已。如果一个问题依赖于另一个问题，它们绝不会处于同一轮次；取决于某个尚未确定答案的问题属于后续轮次。你的回答会确定决策，前沿向外扩展，下一轮会询问由此解锁的内容。十三个问题通常大约落在三轮左右，而不是十三轮。

何时使用¶

输入 /grilling，或者当任务符合时，代理 会自行使用它。它是 grilling 家族中唯一由模型调用的技能，所以你很少手动输入它。通常，你确实输入过的某个技能会替你运行它。

直接输入 /grilling 只会得到纯访谈，没有其他内容。当你想要更多时：

轮次、前沿与决策者¶

该技能基于三个想法。

设计树是主题的模型：决策之下还挂着决策。前沿是所有前提条件均已确定的决策集合：也就是代理目前唯一可以提出的问题。轮次就是一个前沿，完整提出并完整回答。

在一轮内，每个问题都有固定格式：在 ❓ 后面编号并加标题，然后是正文，最后代理的推荐答案单独放在一行 ➡️ 上。这种格式让你可以按编号回答一轮（“1 是，2 第二个选项，3 否，原因如下”），而不是把问题引用回来。该格式有一个已知问题。推荐答案有时会对问题的措辞本身提出反对，因此同意推荐答案意味着对问题回答“否”。当这种情况发生时，回答推荐答案并说明这一点。

设计的另一半是事实与决策的划分。事实是技能自己的职责。当前沿问题需要环境能够确定的内容时，代理会派出一个子代理去查明，而不是问你。轮次不会等待该研究；只有依赖它的问题才会等待。决策是你的，代理必须等待它们。一个运行 grilling 却回答自己决策的代理已经破坏了该技能。当前沿为空时，会话结束。然后代理会等待你确认共同理解，再对你们达成的一致采取行动。

前沿有一个限制。代理凭判断选择它；它不会从图中计算它。因此，它可能把两个问题放在同一轮中，之后才发现其中一个答案本应改变另一个。唯一的防护是告诉它。这会在下一轮重新打开受影响的分支。

本页内容与包装技能内容¶

本页介绍机制。包装技能的页面回答人们最常问的问题。

常见问题¶

我能回到一次只问一个问题吗？ 可以，而且很大一部分用户确实这样做。将此添加到你的全局 CLAUDE.md：

When grilling, ask one question at a time.

并非所有人都偏好基于轮次的默认方式。阅读较慢的用户、使用第二语言工作的用户，或使用顺序格式来帮助集中注意力的用户都报告说，一次一个问题对他们更有效。退出该默认方式是受支持的设置，而不是变通方案。

/batch-grill-me 去哪了？ 进入这个技能。基于轮次的提问曾短暂作为独立技能发布，然后移入 grilling 本身，因此所有基于该原语构建的内容（grill-me、grill-with-docs、triage、wayfinder）都一次性获得了它。没有可安装的 batch-grill-me，也没有独立的顺序技能；上面的 CLAUDE.md 行就是回到一次一个问题的方式。

一次问完一整轮，必然会丢失我先前答案本应引发的问题。不是吗？ 这是对轮次最常见的反对意见，而前沿回答了它。一轮只包含彼此不依赖的问题，因此一轮中的任何答案都不会使该轮中的另一个问题失效。你的答案仍然会改变后续内容，因为代理会从头开始推导每一轮后续问题。你确实会失去一些东西，但比“所有问题一次问完”所暗示的要少。见上文的前沿限制。

它问完问题后就开始动手构建。 确认门就是为此而存在的。该技能在你表示理解一致时完成，而不是当问题前沿变空时。更弱、更快的 模型 仍会跳过这个门。用户最常报告这种情况发生在低投入或非前沿模型上，这些模型会把“访谈直到达成共识”压缩成几个问题和一份大纲。如果你的模型这样做，可靠的修复方法是在你自己的 AGENTS.md 或 CLAUDE.md 中加一行，告诉 agent 未经许可不要实现。

它自己回答了自己的问题，而不是问我。 这是运行中的一个 bug，也是该技能的文本将事实与决策分开的原因。它最常发生在另一个技能运行 grilling 来解决一个工单时，agent 把该任务当作继续推进的许可。同样的约束也是没有异步模式的原因。有人要求一个变体，它读取 GitHub issue 并发布一份合并的决策备忘录，但那是另一个技能，因为一个无人回答的 grilling 会话产生的是 agent 的观点，而不是你的观点。

我能限制问题数量吗？ 不能，而且限制问题数量是有意不在范围内的。有些计划需要三个问题，有些需要五十个；固定上限要么截断困难情况，要么在简单情况下显得武断。预期的控制方式是普通语言。告诉它收尾，或者停下来接受当前状态的计划。如果一个会话运行得很长，原因通常是范围太大；把工作拆开，并分别 grill 各个部分。

我只安装了 grill-me，但什么都没发生。 grill-me 是一个单行技能，其全部内容就是“运行一个 /grilling 会话”，因此它也需要安装这个技能。grill-with-docs 也是如此，它还需要 domain-modeling。安装整套可以避免这个问题；选择性安装意味着也要安装这些原语。

grill-with-docs 运行了，但它从未加载 grilling。 这是一个真实的 bug，仍未修复，用户报告它出现在各种 运行框架 和模型上。一个命名了另一个技能的技能并不一定会可靠地导致该技能被加载，而 grill-with-docs 命名了两个。迹象是一个会话一次性问完所有问题且没有建议。这意味着模型在即兴发挥一场访谈，而不是运行这个技能。直接询问 agent 是否加载了 grilling 和 domain-modeling 通常可以恢复它。

如果它正在正常工作¶

• 一轮以编号列表形式到达，每个问题及其建议位于单独的 ➡️ 行，你可以按编号回答整轮。
• 一轮中的任何内容都不需要先回答同一轮中的另一个问题。
• 后续轮次会问第一轮无法问到的事情。
• 它会去查找事实（读取文件、派发一个子 agent），而不是问你本可以自行查到的事情。
• 在后台运行的研究不会卡住这一轮；只有依赖它的问题会等待。
• 它会在结束时停下来，请你确认理解一致，而不是开始工作。
• 问题数量保持较高，而轮次数量保持较低。

它在哪里适用¶

grilling 是一个原语，而不是你调度的一个步骤：它是访谈技术的唯一事实来源，保存在一个地方，以便每个需要访谈的技能都使用它，而不是自己发明一个。grill-me 和 grill-with-docs 是它的两个用户调用入口，grill-with-docs 是主构建链的起点，位于 to-spec 之前。wayfinder 运行它来解决决策工单，triage 用它把一个模糊的报告 grill 成可执行的报告，improve-codebase-architecture 在你选定一个要深入的候选项后用它遍历树。当你不确定哪个入口点合适时，ask-matt 会引导你。