name: grilling description: "深入追问用户的计划、决定或想法。用户要检验自己的思考，或使用与 grill 有关的触发说法时使用。"
第 03 课 / grilling
按问题的依赖关系开展问答
提问的顺序由决策依赖决定。当前版本是一轮问完已经具备前提的问题，再根据回答推进下一轮。
还不清楚 Skill、Agent、安装和调用？先读 从零开始的6节入门课。
一 / 读这一课之前
先把必要的概念讲清楚
这一课把“多问几个问题”变成有依赖顺序的澄清方法。你要学习判断哪些问题现在能回答、哪些必须等待别的决定，以及哪些事实应由 AI 自己查。
下面是老师补充的入门说明；原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。
frontier｜当前可推进的事项集合
任务存在先后依赖时，前置条件已满足、现在能处理的那些事项。先决定是否登录，才能决定收藏记录如何归属用户；配色可能不受这个决定影响，可以先讨论。前沿不是所有未完成事项，更不是凭直觉挑一个开始做。
context｜Agent 当前可用的上下文
模型这一轮实际能使用的请求、对话、指令和已读文件内容。它不是电脑上所有资料，也不是永久记忆。文件存在但没被读到，就不一定参与推理。交接文档应指明当前目标、进度、关键证据位置和下一步，让新会话能够恢复必要背景。
repo / repository｜项目代码仓库
保存项目源代码、配置、测试和文档，并通常用 Git 记录修改历史的地方。把它理解为“可追溯的项目工作档案”。探索仓库就是查看现有系统，不等于开始改代码。例如新增课程收藏前，应先看已有课程数据、用户身份和保存接口，避免另造一套。
二 / 中英全文对照与精讲
读原文，理解每一步为什么这样做
左右内容按小节对应；窄屏先中文、后英文。两种语言均完整展示，对应讲解紧接在小节之后。译文传达原文要求；老师讲解补充概念、原因、例子与适用边界。
中文译文English · 英文原文
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.
持续深入地提问，直到双方形成共同理解。把相关决定组织成一棵设计决定树：某个选择确定后，会引出依赖它的下一层问题。
按轮次推进。当前可问的问题，是那些前提已经确定、无需猜测其他未回答问题就能提出的问题，这一集合称为 frontier。每轮把当前可问的事项一起列出，为每个问题编号并附上推荐答案。然后等待用户回答，再进入下一轮。
每轮使用如下格式：
❓ **Q1** — **<问题标题>**：<具体问题，可以分段，也可以包含选项>
➡️ <你的推荐答案>
---
❓ **Q2** — **<问题标题>**：<具体问题，可以分段，也可以包含选项>
➡️ <你的推荐答案>
每轮回答都会改变后续问题：已确定的决定，让依赖它的问题具备提问条件。重新判断这一轮可以问什么。若一个问题仍依赖本轮另一个尚未回答的问题，就应放到后面一轮，不要提前问。
查找事实是你的工作。需要了解文件、工具等环境事实时，安排一个子 Agent 调查；自己可以查到的内容，不要让用户代查。调查尚未结束，只表示依赖它的问题还需等待，不必阻塞其他已经可以讨论的问题。
作出决定则是用户的职责。把选择交给用户，并等待回答。
当各分支都已讨论，当前没有尚待解决的问题，也没有默默保留的假设时，这场讨论才算完成。用户确认双方已形成共同理解之前，不要依据这份设计开始执行。
Interview the user relentlessly until you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Format a round like so:
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
---
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The decisions are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
老师讲解 · 对应上方原文 · 含教学举例
设计树：为什么不能同时问所有问题
设计树不是要求一定画一张漂亮图，而是表示决定之间的依赖。先决定网站面向自己还是多人，再决定是否需要各自账号；账号方案未定时，询问跨用户权限细节可能过早。
反过来，文章是否保留英文原文，可能不依赖账号决定，可以同轮讨论。所谓前沿，就是这些前置条件已经足够明确的问题集合。
这份当前版本采用“一轮多个相互独立的问题”，不是文章宣传中一概说的“一次只问一个”。读 skill 必须以具体版本为准。
推荐答案提供专业支持，但决定仍要落到用户意图
每轮问题编号，并附推荐答案。推荐的价值是说明工程上的默认取舍，让初学者不必在完全不懂时盲选。比如“建议先只支持你个人阅读，因为尚未提出多人学习记录需求”。
如果“是否多人”与“多人权限怎样分层”放同一轮，后一个答案很可能建立在尚未收到的假设上。正确做法是先解决前者，再重算下一轮问题。
你也可以回答“我没有这个偏好，请按目标选一种并说明理由”。本 skill 对人决策的要求较强，但使用时仍应尊重实际授权，不能把你已授权的普通技术选择反复退回给你。
事实让 AI 查，取舍让人明确
已有文件在哪里、项目用什么框架、测试能否运行，是可调查的事实。你是否愿意公开学习记录、是否接受先不支持手机，是涉及目标或偏好的决定。
例如 AI 能读取配置，却问你“项目是不是用某个框架”，就在把探索工作转嫁给你。反过来，AI 查到某框架方便公开发布，也不能因此替你决定公开个人笔记。
探索未完成时，只等待依赖该事实的问题，其余独立问题可继续。结束的标准是必要决定已经清楚并得到共同确认，不是问够固定数量。
一轮问多个问题，也要先分清哪些问题现在能回答
这里并非把所有问题一次性抛给用户。 它先整理前后依赖，再一轮一轮问。
例如讨论课程收藏，当前可以问：“收藏课程还是单个课时？”以及“是否必须登录？”这两项可以独立回答。但“游客的收藏怎样合并到登录账号”要等允许游客收藏之后才有意义；前提尚未确定，先不要逼用户设计合并规则。
用户回答以后，AI 重新计算可问事项，这就是 frontier 不断向外推进。它不要求你记住“前沿”这个术语，只需理解为“目前已经有足够前提可以讨论的问题”。
查事实与做决定也要分开。 仓库是否已有登录模块，应由 AI 查代码；是否允许游客收藏，是产品选择，应与你讨论。AI 不能把自己能查的事情都变成对你的提问，也不能将你的选择偷偷替你定下。
推荐答案帮助你看见专家判断，但它仍是建议。好的追问还应解释为什么推荐，让你有依据接受或拒绝。最后判断是否问清楚，要看共同目标和边界，而不是问题数量是否很多。
三 / 你问我答
先作答，再看参考思路
Q1 · 理解
用自己的话说明：它解决什么问题，完成后会留下什么？
请各用一句话回答。若它只做规划或解释，不要把“已开发”“已部署”写成产物。
Q2 · 判断
如果两个问题互相独立，可以同一轮问吗？如果 B 依赖 A 呢？
我已思考，查看参考思路
独立且前提已满足时可以并列；B 依赖 A 时，先得到 A，再问 B。能查到的事实先查，不伪装成人工决策。
Q3 · 追问
原文中哪条要求在你的环境下可能不成立？
说出具体一句及其前提，例如工具不可用、资料缺失、已有项目约定冲突，或它只是作者偏好。把你的答案带回课堂，我们据此继续讨论。
课堂回传格式：第 03 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材；实时问答在我们的对话中进行。
四 / 应用场景讨论
把方法放进一个具体情境
教学案例：教材的“先讲后练”已经确定，教师不再问一次。可以并列讨论读者基础和示例偏好；确定后再决定代码讲解深度。这种顺序减少无效回答。
边界与容易误读的地方
当前原文与“一次只问一个”的旧介绍不同。若你的交互环境限制问题数量，需调整每轮大小，但保留依赖顺序。推荐答案也不能替用户回答。
讨论后再实践：先判断上述情境是否适用，再选择真实任务。现在无需安装、运行命令或修改现有项目。