用「一次一问」的斜杠命令澄清欠定义需求
Matt Pocock 分享：问题极度欠定义时，用 /grill-me 让 AI 一次只问一个问题来做需求澄清。
原始内容
I still sometimes say: /grill-me about this, one question at a time Usually when I REALLY have no idea what I'm building. When the problem is hugely underspecified and a single Q&A round could send us in massively different directions
中文译文
机器翻译，保留原文供核对。
我有时还是会说： /grill-me 就这个，一次一个问题 通常是在我真的完全不知道自己要做什么的时候。也就是问题严重缺乏明确说明，而仅仅一轮问答就可能把我们带向截然不同的方向。
深度解析
是什么 Matt Pocock 分享了一个个人高频但仍会使用的对话手法：在提示词中追加“/grill-me about this, one question at a time”，也就是让 AI 反过来审问自己，并且严格一次只问一个问题。他明确说明使用时机——当你“真的不知道自己到底在做什么”、问题极度欠定义时。
核心设计 这条命令的价值不在命令本身，而在两个约束：(1) 角色反转，把 AI 从“给答案的人”变成“提问的人”；(2) 节奏约束，一次一问，强制串行。他给出理由：在信息严重不足的场景下，一轮问答就足以把方向带到完全不同的分支上，因此必须用单问单答把决策树逐层收敛，而不是让模型一次性输出一份看似完备的方案。
关键洞察 这是典型的“先对齐问题空间，再谈解空间”的工程习惯。多数人用 Agent 的失败模式是过早索要实现，得到的是对错误问题的漂亮回答；而追问式对话把模型的先验变成澄清工具，把人的隐性问题显性化。他的表述也暗示这属于“方法”而非“配置”：命令是可自定义的，真正可复用的是“单问题、串行、以收敛为目的”的对话结构，这一点可迁移到任何支持自定义命令或系统提示的 Agent 平台。
边界与风险 第一，适用区间窄——作者自己说通常只在“真的一无所知”时才用，若需求已较清晰，反复追问会拖慢节奏；第二，追问质量取决于模型的领域先验，模型可能只问表面问题，需要人主动纠偏；第三，一次一问意味着轮次成本高，长会话下上下文管理与结论沉淀（例如每轮后落一条决策记录）必须自己补上，否则澄清完就忘。
精选追评与案例
原作者补充了 /wayfinder 的适用边界，说明它与逐问盘问的分工。
For folks asking, I use /wayfinder as an escape valve for when a task will obviously take more than one session to plan
中文译文 · 机器翻译
对于提问的人：当一个任务显然需要不止一次会话才能规划好时，我会把 /wayfinder 当作一个备用出口。
用“五个为什么”的经典方法解释了逐问顺序为何能挖出隐藏问题。
Toyota has a version of this: "Naze naze bunseki." Why-why analysis. Taiichi Ohno taught people to ask "why" five times in a row. The point is the order. Each answer decides what the next "why" should be. Ask them all up front and you're just guessing at the path. One question at a time is how you find the problem you didn't know you had.
中文译文 · 机器翻译
丰田有一个类似的做法：“Naze naze bunseki”，也就是“为什么-为什么”分析。 大野耐一教人们连续问五次“为什么”。重点在于顺序。每个答案决定下一个“为什么”该问什么。 一次性全问出来，你只是在猜路径。 一次问一个问题，才能发现你原本不知道自己有的问题。
给出可复用做法：把逐问答案沉淀到决策文件，避免上下文重置后重复盘问。
@mattpocockuk Pairs well with having it write each answer into a decisions file as it goes. The grilling survives a context reset, and the next session starts from your answers instead of asking them all again.
中文译文 · 机器翻译
让它把每个答案随手写进一个决策文件，会与之配合得很好。这样盘问过程能在上下文重置后保留下来，下一次会话从你的答案开始，而不是把所有问题再问一遍。
展示了把盘问结果集中到 GitHub Issue 的实操工作流。
@mattpocockuk I use /grill-with-docs and tell the agent to write all decisions and notes to a single GitHub Issue. This way, I can usually just point an agent at it for the feature and revise the decisions or explore different directions, all from a single issue.
中文译文 · 机器翻译
我用 /grill-with-docs，并让智能体把所有决策和笔记写进同一个 GitHub Issue。这样一来，针对该功能，我通常只要让智能体去看这个 Issue，就能修改决策或探索不同方向，全都基于同一个 Issue。
提醒长访谈可能把猜测固化为需求，并给出“最小实验”的替代路径。
@mattpocockuk A useful escape hatch is “I don’t know yet—what’s the smallest experiment that would answer this?” Otherwise a long interview can turn guesses into requirements. Some answers only exist after somebody tries the thing.
中文译文 · 机器翻译
一个有用的退路是：“我还不知道——能回答这个问题的最小实验是什么？”否则，冗长的访谈会把猜测变成需求。有些答案只有在有人实际试过之后才会出现。