人们对 /grill-me 和 /grill-with-docs 的 9 个常见误解
掌握使用 /grill-me 或 /grill-with-docs 时最常见的 9 个错误，学习作用域管理、模型选择和规划策略。
本页目录
这个 /grill-with-docs Skill 已成为 Agent 工作流中颇受欢迎的 规划模式（Plan Mode） 替代方案。然而，很多人仍难以有效使用它。这个 Skill 会不断向你提问，直到双方形成共同理解，但 这要求你自己具备良好的规划能力.
这些 Skills 并不是为了取代工程师，而是为了帮助你。本指南会解析九种最常见的失败模式，帮助你真正掌握它们。
理解问题：低保真与高保真
进入一次 追问审视 会话时，你的目标是回答与即将构建的事物有关的问题。但并非所有问题都一样。
| 问题类型 | 定义 | 示例 | 适合追问吗？ |
|---|---|---|---|
| 低保真 | 无需详细原型或图片就能回答的问题 | “这个路由应该使用哪个 URL？” | ✓ 是 |
| 高保真 | 需要放大查看细节图片或原型才能回答的问题 | “这个 UI 使用起来应该是什么感觉？” | ✗ 否 |
表单字段布局就是一个典型的高保真问题。应该把字段拆到多个页面，还是使用一张很长的大表单？要正确回答这个问题，你确实需要看到原型，或把整个功能构建出来。
处理不适合追问的问题
第一种主要失败模式，是试图在追问会话中回答高保真问题。
遇到不适合追问、需要更高保真度才能理解的问题时，使用 交接 模式：
- 在第一个会话（蓝色会话）中继续追问低保真问题
- 遇到高保真问题时，将它交接给原型设计会话
- 在独立会话中构建功能或制作原型，以便更好地理解问题
- 再把结果交回原来的追问会话，继续处理适合追问的问题
这个模式如下： 追问 → 制作原型 → 再次追问。它让你无需打断追问流程，也能回答高保真问题。
选择合适的范围
范围——也就是你正在追问的事物有多大——至关重要。
如果范围过大，就会出现两个问题：
问题 1：隐藏的高保真问题 基于已知能够工作的东西继续构建，总比无休止地规划遥远未来更容易。当人们试图预先安排让 AI 连续工作数天的任务时，结果往往很差，因为他们并不是在自己理解的坚实基础上继续构建。
问题 2：上下文窗口限制 开始时，你的 上下文窗口可能几乎为空；但随着追问不断进行，你会进入模型的“迟钝区”——对大多数前沿模型而言，大约是 120k tokens。超过这个阈值后，模型的注意力关系会变得吃力，决策质量也会开始下降。
拆解大型范围
不要围绕一个庞大范围持续追问，而应一开始就让 Agent 将其拆解：
- 从大型范围开始
- 让 Agent 把它拆成更小、适合追问的部分
- 分别针对每个小范围进行追问
- 在各自独立的会话中回答所有问题
这样可以轻松停留在“聪明区”内，避免在会话进行到一半时撞上上下文窗口的硬墙。
主动参与，而不是被动回答
许多漫长的追问会话之所以失败，是因为人们面对 Agent 时过于被动。请记住： 这是一场对话，不是单向采访.
Agent 负责提问，但 你 需要做到：
- 弄清楚前进方向
- 理解工作范围
- 确保讨论不偏离轨道
- 主动引导对话
如果你过于被动，Agent 会用 540 个问题轮番轰炸你，还会围绕保真度低得过头的事项不断提出要求，让工作范围彻底膨胀。
但这里需要保持平衡。过于主动，可能会让你在本该编写代码时仍对低保真细节无休止地追问。如果只是一再规划、始终不动手构建，那就是追问过度了。
找到中间地带：积极参与并引导会话，同时清楚何时该停止规划、开始实施。
保留你的设计决策
这是一种至关重要却经常被忽略的失败模式。进行追问时，你会创造出一项极其宝贵的产物： 一个装满设计决策的上下文窗口.
等到追问结束时，你已经用数百个 tokens 作出了大量关于系统应如何工作的选择。这些内容价值极高。
你有以下选择：
- 如果上下文预算仍有余量：直接在同一次会话中实施，不要交接
- 如果上下文即将耗尽：使用
/2PRDSkill 创建 PRD（产品需求文档），将其作为交接产物
不要 仅仅为了编写 PRD 就清空上下文并重新开始。这样做等于扔掉全部设计工作。追问会话中的每项决策都有价值，都应该落实为代码，或记录在交接产物中。
使用更聪明的模型进行追问
使用“迟钝”的模型进行追问是一种常见错误。下面解释为什么模型选择很重要：
进行追问时，你依赖两类知识来源：
| 知识类型 | 来源 | 可靠性 | 发挥作用的阶段 |
|---|---|---|---|
| 上下文知识 | 你提供的文件、Prompt、工具结果 | 非常可靠 | 实施阶段 |
| 参数知识 | 模型的训练数据与参数 | 可靠性较低，但更有创造力 | 追问阶段 |
在追问阶段，你依赖的是模型的 参数化知识 ——也就是模型凭借对系统和应用的内在理解，提出你可能从未考虑过的事项。如果你已经想到了，自然会把它们作为上下文提供进去。
迟钝的模型不会给你带来好点子。 你需要参数量很大的模型——通常是大型前沿模型——才能获得有创造力的建议和发人深思的问题。
但在实施阶段，可以使用较小的模型，因为此时大部分信息都来自上下文（详细计划、代码库等）。
并行运行多个追问会话
最后，还有一项简单却强大的技巧： 并行进行多个追问会话.
具体做法如下：
- 你正在会话 A 中进行追问
- Agent 向你提出一个问题
- 你作出回答
- 在 Agent 思考期间，切换到会话 B
- 回答那里的问题
- 会话 A 准备好了，再切换回去
- 重复
这就像同时管理两个 Slack 讨论串。你并没有进行沉重的上下文切换，只是在管理彼此独立的对话。
好处包括：
- 吞吐量翻倍
- 用更少时间完成更多规划
- 让多条设计决策持续向前推进
大多数人可以轻松同时处理两个会话，这通常也是舒适上限。如果其中一个会话正在执行调研之类的长任务，你或许能处理三个。随着追问技巧提高，还可以继续增加并行度。
刚接触追问工作流？请从 /grill-with-docs 开始——在动手构建前，先通过文档达成一致。
要点总结
- 追问的核心是问题。 低保真问题适合追问；高保真问题需要制作原型
- 范围很重要。 选择更小的范围，避免耗尽上下文窗口
- 主动参与。 引导对话，同时清楚何时该停止规划、开始编码
- 保留价值。 追问过程中作出的每项决策，都应该记录在某个地方
- 使用聪明的模型。 你需要参数知识来获得有创造力的建议
- 并行运行。 理解每个会话的职责后，在它们之间高效切换
越充分地理解这些失败模式，就越能有效利用追问会话，在编码之前完成设计。