跟 AI 说话比跟同事说话还累？Grill Me 帮你把每一句都变成有效沟通

Grill Me 的本质：不是让 AI 多提问，而是把想法变成可验收的任务

前言

最近研究了 Matt Pocock 的 grill-me Skill。它的内容非常短，核心逻辑说白了就是：让 AI 围绕一个计划持续追问，每次只问一个问题，并且给出推荐答案，直到双方对这件事形成共同理解。

第一眼看上去，这不就是让 AI 多问几个问题吗？好像自己在提示词里加一句“如果有不清楚的地方先问我”，也能达到差不多的效果。

但小编认为，grill-me 真正值得学习的地方，并不在“追问”这两个字，而在于它改变了人与 AI 的协作顺序：不是先让 AI 开发，再看结果对不对；而是先把需求讨论清楚，再逐层沉淀成产品文档、开发文档、开发任务和验收标准。

换句话说，grill-me 表面上是一个访谈 Skill，背后其实是一条需求收敛流水线：

这篇文章不讨论它如何安装，也不准备逐行翻译 SKILL.md。我们重点看一件事：grill-me 为什么能帮助我们更正确地使用 AI。

一、很多人不是不会使用 AI，而是太早让 AI 开工

假设我们准备开发一个 AI 内容生产工具，只给 AI 一句话：

帮我做一个可以配置 AI 员工和工作流的应用。

对于现在的大模型来说，这个需求已经足够它开始工作了。它可以马上生成菜单、页面、数据结构，甚至顺手给你搭一套前后端代码。

问题是，能开始做，不代表知道应该做什么。

“AI 员工”究竟是什么？它能不能独立创建任务？员工之间是否需要通信？一个项目只能绑定一个工作流，还是可以绑定多个？工作流失败以后怎么处理？当前是本地单机应用，还是一开始就要设计账号和云同步？

这些问题没有答案，AI 也不会停在那里发呆。它通常会根据训练数据和常见产品经验，替我们选一个看起来合理的答案，然后继续向下生成。

最后的结果往往很尴尬：页面很完整，代码也能运行，甚至还带着漂亮的动画，但做出来的东西不是我们想要的。

这时候很多人会认为 AI 不够聪明。其实真正的问题是：我们只给了 AI 一个主题，却默认它已经理解了需求。

传统开发里面，需求不清楚，团队会开评审会；方案不清楚，会做技术设计；范围不清楚，会拆任务和验收条件。到了 AI 编程这里，很多人反而把这些步骤全部省略，只留下一句需求，然后希望 AI 一步到位。

AI 的确把开发速度提高了，但它并没有替我们消灭需求分析。

二、Grill Me 的第一步，不是提问，而是头脑风暴

grill-me 会围绕一个主题持续追问，沿着决策树逐个处理分支。从形式上看，它像一个不肯轻易放过你的产品经理。

但头脑风暴不是让 AI 随便发散，也不是一次抛出二十个问题让用户填写调查问卷。它首先要确定一个主题，然后围绕主题寻找那些会改变产品结果的关键决策。

例如，我们确定的主题是“构建 AI 员工团队”，AI 接下来应该关心的是：

• 员工在产品中承担什么职责；
• 员工与工作流是什么关系；
• 用户如何触发一次执行；
• 节点之间如何传递输入和输出；
• 失败以后由谁处理；
• 用户最终根据什么判断任务完成。

这些问题不是为了显得专业，而是因为不同答案会把产品带向完全不同的方向。

如果员工可以独立创建任务，那么系统需要任务中心、调度机制和权限边界；如果员工只能绑定在工作流节点上，它就更像一个稳定的流水工，产品模型会简单很多。

所以，grill-me 中有一个非常重要的设计：每次只问一个问题，并等待用户回答以后再继续。

因为后一个问题，往往依赖前一个答案。

这和填写一张固定表单不同。固定表单的问题早就写好了，而 grill-me 的下一个问题，是根据当前已经确认的决策动态生成的。它不是在收集孤立答案，而是在逐步建立一棵完整的决策树。

三、头脑风暴的目的，是形成产品文档

如果讨论结束以后，所有结论仍然散落在聊天记录里，那么这次头脑风暴只完成了一半。

聊天记录适合沟通，不适合作为产品事实来源。

同一个问题可能前面回答过一次，后面又补充了新的条件；某个方案可能被提出过，但最终已经否决；有些内容是 AI 的建议，有些才是用户正式确认的决定。如果直接让 AI根据整段聊天继续开发，很容易把讨论过程和最终结论混在一起。

因此，第二步应该把已经确认的内容整理成产品文档。

产品文档不是把聊天记录换一种格式复制过去，而是对讨论结果进行第一次收敛，至少需要回答这些问题：

内容	需要回答的问题
产品目标	这个产品最终解决什么问题
用户角色	谁会使用，分别能做什么
核心对象	项目、工作流、员工等对象是什么关系
业务规则	哪些行为允许，哪些明确不允许
主流程	用户如何从开始走到结果
异常流程	失败、中断、重试如何处理
范围边界	当前版本做什么，暂时不做什么

例如，“员工不能创建任务”只是一句对话结论。进入产品文档以后，它应该成为一条明确的产品规则，并影响任务入口、页面操作、权限设计和工作流运行方式。

这一步完成以后，我们才算从“我大概想做个什么”走到了“产品应该怎么运行”。

四、产品文档之后，还需要开发文档

产品文档解决的是产品规则，开发文档解决的是系统如何实现。

这两个文档不能混在一起。

产品文档里说：“一个项目可以绑定多个工作流。”

开发文档则要继续回答：

• 项目与工作流是一对多还是多对多；
• 绑定关系保存在哪里；
• 删除工作流时如何处理已有项目；
• 工作流版本变化后，项目引用最新版本还是固定版本；
• 本地数据使用什么方式持久化；
• 页面状态与执行状态如何同步。

这就是从产品语言向工程语言的翻译。

很多人使用 AI 开发时，会让它直接从一句产品描述跳到代码。中间缺少开发文档，模型只能一边写一边设计。数据库结构、模块边界、状态流转和异常处理全部临场决定，最后自然容易出现前后不一致。

小项目可能暂时看不出问题，因为代码量还没有大到让矛盾爆发。等功能越来越多，就会发现每个页面对同一个概念都有自己的理解。

所以，开发文档的意义不是增加流程，而是把那些原本会隐藏在代码里的设计决策，提前拿出来确认。

五、开发文档还不是开发任务

有了开发文档以后，也不建议直接丢给 AI 一口气完成整个系统。

开发文档描述的是整体方案，开发任务描述的是下一次具体执行什么。

一个合格的开发任务，应该具有清晰的输入、改动范围和完成条件。例如：

实现项目与多个工作流的绑定能力。新增项目工作流关联数据结构；项目详情页支持添加和移除工作流；删除关联只解除绑定，不删除工作流；本任务不包含工作流执行功能。

这里有几个关键点：

1. 任务只处理一个能够闭环的问题；
2. 明确需要改动的业务范围；
3. 明确不会顺手实现什么；
4. 能够单独验证结果；
5. 完成后可以安全进入下一项任务。

如果一个任务的描述还是“完成整个 AI 员工系统”，那它实际上并没有被拆解，只是把大需求换了一个地方保存。

AI 开发速度越快，任务边界越重要。因为模型可以在很短时间内生成大量代码，一旦方向错误，返工规模也会跟着放大。

六、最后必须回到验收标准

很多 AI 编程工作流停在“代码生成完成”。只要页面能打开、接口不报错，就认为任务结束了。

但代码生成完成只是执行动作结束，不代表产品目标已经实现。

真正的完成，需要验收标准。

以前面的绑定任务为例，验收标准可以包括：

• 一个项目能够绑定多个工作流；
• 同一个工作流不能被重复绑定；
• 用户可以解除某一条绑定关系；
• 解除绑定不会删除工作流本身；
• 重新进入项目详情页后，绑定关系仍然存在；
• 不属于本任务的工作流执行入口不会出现。

验收标准最好在开发前确定，而不是等 AI 写完以后，再根据现有实现临时总结。

否则很容易出现一个问题：AI 做了什么，我们就验收什么。原本是拿标准检查结果，最后变成拿结果反推标准。

这也是 grill-me 背后最关键的一步：持续追问不是为了得到更多文字，而是为了让最后的结果可以被判断。

如果一项需求没有明确的验收标准，那么 AI 只能判断自己“做完了”，用户却无法判断它“做对了”。

七、Grill Me 为什么要一次只问一个问题

理解了前面的链路，再看 grill-me 的几条核心规则，就会发现它们都在服务需求收敛。

1. 一次只问一个问题

一次抛出十几个问题，看起来效率很高，实际上容易得到十几个互相没有依赖关系的浅答案。

一次只解决一个决策，AI 才能根据答案调整后续问题。它处理的是决策树，不是一份提前写死的调查问卷。

2. 每个问题给出推荐答案

AI 不能只负责提问，也应该承担参谋职责。

推荐答案可以帮助用户快速判断。如果建议合理，用户直接确认；如果不合理，用户指出差异。双方不需要每个问题都从空白开始讨论。

当然，推荐不等于替用户决定。AI 可以说明利弊，但最终的产品决策仍然属于用户。

3. 能查到的事实不要询问用户

项目使用 React 还是 Vue、当前有哪些页面、数据结构如何定义，这些事实可以通过代码和文件查到。

如果 AI 连这些问题也拿来询问，所谓的“深度访谈”很快就会变成低效率的人工检索。

正确的分工应该是：

• 客观事实由 AI 主动调查；
• 产品取舍由 AI 提供建议；
• 关键决策由用户最终确认。

4. 达成共同理解之前不要实施

这是整套流程的闸门。

如果一边讨论，一边修改代码，前面的临时想法很可能已经进入实现。后面即使推翻了方案，也会留下大量无效改动。

先把决策收敛，再进入开发，表面上慢了一点，实际上减少了大量返工。

八、正确使用 AI，不是把所有事情都交给 AI

grill-me 很容易被误解成：“以后需求不清楚，就让 AI 一直问。”

但追问本身不是目的，形成可执行的共识才是目的。

我们需要避免两个极端。

第一个极端是完全不讨论。给 AI 一句话，让它从产品设计一直做到代码实现。这样虽然很快，但大量关键决定被模型静默完成。

第二个极端是无限讨论。所有细节都要提前问清楚，连按钮文案和边距都要在开发前确认。这样会把需求分析变成一场没有终点的审讯。

正确的做法是优先解决那些会影响后续设计的阻塞性问题：

• 产品目标是否明确；
• 核心对象和关系是否明确；
• 关键业务规则是否明确；
• 当前范围和非目标是否明确；
• 技术方案是否存在不可逆选择；
• 任务是否能够独立交付；
• 结果是否能够被验收。

当这些问题已经形成共同理解，就应该停止追问，进入下一阶段。剩余的局部细节，可以在对应任务中继续确认。

所以 grill-me 并不是要求我们在开发前预测所有事情，而是要求我们不要带着关键的不确定性进入开发。

九、从 Grill Me 看 Skill 为什么有价值

单独看 grill-me 的内容，它并不复杂，甚至可以说短得有点不像一个“正式技能”。

但这恰好说明了 Skill 的价值不取决于文件有多长。

一个好的 Skill，可以只沉淀几条关键规则，却稳定改变 AI 的工作方式：

• 从直接回答切换到持续澄清；
• 从一次性列问题切换到沿决策树推进；
• 从只提问切换到同时提供建议；
• 从让用户提供所有信息切换到主动调查事实；
• 从边讨论边实施切换到确认以后再执行。

这些规则组合起来，形成了一套可以重复使用的协作方法。

如果只是临时写一句“有问题先问我”，AI 可能问两三个问题就开始执行，也可能一次抛出一长串问题。Skill 的作用，就是把我们已经验证有效的方法固定下来，让不同任务、不同会话甚至不同执行者，都尽量遵循同一套工作协议。

说白了，grill-me 沉淀的不是几个提问句式，而是一个需求分析角色。

十、总结

小编认为，grill-me 真正想解决的问题，不是 AI 会不会写代码，而是我们是否在 AI 写代码之前，把正确的问题讨论清楚。

它背后的完整逻辑可以归纳成五步：

1. 通过头脑风暴确定主题，挖掘用户真正的需求；
2. 把已经确认的决策整理成产品文档；
3. 把产品规则翻译成开发文档；
4. 把整体方案拆成可以独立执行的开发任务；
5. 在开发前定义验收标准，最后根据结果判断是否完成。

AI 可以帮助我们搜索事实、分析方案、补充遗漏、生成文档和执行任务，但它不应该在用户毫不知情的情况下，替用户决定产品应该是什么。

以前开发慢，我们还有时间在写代码的过程中慢慢想。现在 AI 写代码越来越快，需求中的一点偏差，很快就会被放大成一堆看起来很完整的错误结果。

所以 AI 时代真正需要提高的，不只是生成速度，还有需求收敛的速度。

grill-me 的本质，不是让 AI 问得更多，而是让人和 AI 在开工之前，先对“什么才算做对”达成共识。