在使用 AI Agent 完成代码开发、内容生成、方案设计等任务时，一个常见问题是：用户给出一个高度概括的需求，Agent 立即开始执行，最终产出却偏离真实意图。

例如：

帮我改造一下首页。

这类需求看似明确，实际上隐藏了大量未决策信息：首页的核心目标是什么，主要服务哪些用户路径，哪些模块应该保留，哪些应该降级，转化入口是否需要强化，内容排序规则是否需要调整。若 Agent 在这些问题没有被确认前直接执行，它只能依赖上下文和模型偏好进行补全。

这会带来一个典型的工程问题：Agent 过早进入执行阶段，在需求尚未收敛时产生实现结果，导致返工成本增加。

grill-me 这个 skill 解决的正是这个问题。它不是增强 Agent 的代码生成能力，而是改变 Agent 的工作流入口：在执行之前，先通过连续追问把用户需求澄清到可执行状态。

问题：AI Agent 容易在需求不完整时自行决策

在传统软件开发流程中，需求澄清通常发生在实现之前。工程师会追问产品目标、用户场景、边界条件、优先级和验收标准。只有当关键决策达成一致后，才进入设计和编码阶段。

但在很多 AI Agent 使用场景中，这个过程被压缩甚至省略了。

用户输入一句自然语言指令后，Agent 往往会立即执行。由于大模型具备很强的补全能力，它会自动填补需求空白。例如在“改造首页”这个任务中，Agent 可能自行决定首页主视觉内容、模块顺序、订阅入口位置、内容卡片布局以及哪些旧模块可以删除。

问题不在于这些决策一定错误，而在于它们没有经过用户确认。

对于 Agent 来说，这些只是合理推断；对于用户来说，这些却可能是关键产品决策。两者的错位会直接导致结果不可用，后续需要通过多轮反馈修正，甚至完全重做。

因此，AI Agent 协作中的核心风险之一是：

模型把“未明确的信息”当成“可以自行补全的信息”。

grill-me 的设计目标，就是把这些隐含决策显式化。

grill-me 的核心机制：执行前的交互式需求收敛

grill-me 是 Matt Pocock 的 skills 仓库中的一个 skill。它的核心行为非常简单：在 Agent 开始执行任务前，持续向用户追问计划中的关键问题，直到双方对目标和方案形成共识。

它的重点不是生成内容，而是构造一个“需求澄清阶段”。

从工作流角度看，grill-me 可以理解为一个前置的需求对齐器：

模糊需求
  ↓
上下文读取
  ↓
关键决策识别
  ↓
逐项追问
  ↓
用户确认 / 修正
  ↓
形成共识
  ↓
进入执行

这个流程将 Agent 的执行从“直接响应式生成”改为“先澄清、再执行”。

这对于复杂任务尤其重要。因为复杂任务通常不是缺少实现能力，而是缺少明确约束。只有当目标、边界和取舍被确认后，Agent 的生成能力才能稳定发挥。

设计原则一：一次只问一个问题

grill-me 的第一个重要设计是：一次只问一个问题。

很多需求澄清工具会一次性列出大量问题，例如目标用户、页面结构、核心转化、视觉风格、技术约束、验收标准等。虽然这些问题都合理，但一次性抛出会增加用户负担。

grill-me 采用的是对话式决策树。

它不会一次性生成一张调查问卷，而是基于当前上下文和用户上一次回答，选择下一个最关键的问题。这样做有两个好处。

第一，用户的认知负担更低。用户不需要一次性组织完整需求，只需要回答当前最重要的问题。

第二，问题之间可以形成依赖关系。前一个回答会影响后一个问题的方向。例如，如果用户确认首页的目标是提升博客阅读，那么后续问题就会围绕文章展示、订阅入口、内容优先级展开；如果用户确认目标是课程转化，后续问题则会转向课程介绍、案例证明和购买路径。

这种方式更接近真实的软件需求讨论，而不是静态表单。

设计原则二：每个问题附带推荐答案

grill-me 的另一个关键设计是：提问时给出推荐答案。

例如，它不会只问：

首页改造的核心目标是什么？

它更可能这样问：

这次首页改造，你最希望访客完成的动作是什么？是阅读最新文章、了解你本人，还是进入课程/咨询转化路径？基于当前站点主要更新博客的情况，我建议把博客阅读作为首页主目标。

这个推荐答案非常重要。

在 AI 协作中，很多用户并不是没有判断，而是不想从零开始表达判断。推荐答案提供了一个默认选项，用户只需要确认或修正即可。

这会显著提升对话效率。

如果推荐方向正确，用户可以直接回答“对”。如果推荐方向不符合预期，用户可以快速指出偏差。例如：

不，我这次更想提高订阅转化。

此时 Agent 就可以基于用户修正继续追问，而不是沿着错误假设继续执行。

从交互设计角度看，这相当于把开放式问题改造成带默认值的决策确认。它降低了用户输入成本，同时仍然保留用户的最终决策权。

设计原则三：事实自己查，决策才问用户

一个高质量的 Agent 不应该把所有不确定性都抛给用户。

grill-me 的有效之处在于，它区分了两类信息：事实信息和决策信息。

事实信息可以通过读取代码、文档、配置或现有内容获得。例如页面有哪些组件，订阅组件在哪里，最近文章列表是什么，当前路由结构如何。这些信息不应该反复询问用户。

决策信息则必须由用户确认。例如首页主目标是什么，是否强化订阅转化，哪些内容可以降级，是否接受固定展示长文而不是最新文章。

这一区分很关键。

事实信息：Agent 应自行检索
决策信息：Agent 应请求用户确认

如果 Agent 对事实信息也频繁提问，用户会觉得低效；如果 Agent 对决策信息不提问，就会产生越权决策。

grill-me 的价值在于，它让 Agent 只在真正需要用户判断的位置停下来。

案例：个人网站首页改造

假设用户的原始需求是：

帮我改造首页。

如果没有需求澄清，Agent 可能直接进入代码修改阶段。它会读取现有页面，然后根据自身理解调整布局、模块顺序和内容重点。

但这些改动背后其实包含多个未确认决策：

首页的主目标是什么？
博客、个人介绍、课程、咨询，哪个优先级最高？
订阅入口是否是核心转化路径？
哪些模块应该保留，哪些模块可以弱化？
首页主视觉应该展示最新文章，还是展示代表性内容？

在 grill-me 工作流中，Agent 会先读取项目上下文，然后逐步追问这些问题。

例如第一个问题可能是：

这次首页改造最希望访客完成的动作是什么？我建议把博客阅读作为主目标，因为当前站点主要更新博客内容。

用户确认后，Agent 再继续追问：

如果博客是主目标，现有首页模块中哪些需要保留，哪些可以降级？我建议弱化非核心介绍模块，把内容入口前置。

然后继续进入订阅入口、主视觉内容、文章排序策略等问题。

在这个过程中，Agent 可能会通过读取文章列表发现一个隐藏问题：如果首页大图默认展示最新文章，而最近十篇都是日报，那么首页最显眼的位置可能会被一篇并不具代表性的日报占据。

这类发现非常有价值。它不是单纯询问用户，而是在上下文分析的基础上提出风险：

如果继续使用最新文章作为首页主视觉，最显眼的位置会展示日报内容，而不是代表性长文。是否需要改为固定展示最新一篇长文？

这个问题将一个用户未意识到的产品风险显式化。用户确认后，Agent 才进入实现。

最终形成的共识可能是：

首页以博客内容为主
订阅入口需要前置并重复出现
主视觉不再直接使用最新文章，而是固定展示最新长文
非核心模块降级展示
旧的个人介绍和辅助入口保留但降低权重

这时再进入编码阶段，Agent 的实现方向会稳定得多。

grill-me 不只适用于代码任务

虽然 grill-me 在代码任务中非常实用，但它本质上并不是编程工具，而是决策澄清工具。

它适用于任何需要先明确取舍再执行的任务，例如选题规划、课程设计、技术方案评审、产品功能定义、文章大纲设计、项目优先级判断等。

以技术内容选题为例，用户可能输入：

下一期 Skills 系列该讲哪个？

如果 Agent 直接给结论，它会变成一个推荐系统。但通过 grill-me，这个问题会被拆成多个决策点：

下一期内容面向谁？
是面向入门用户，还是面向开发者？
目标是轻量介绍，还是深入分析？
主线是工具使用、设计原理，还是工程实践？
开头应该从问题场景切入，还是从项目背景切入？

这些问题回答完之后，用户得到的不只是一个选题，而是一组可复用的内容决策。后续无论写脚本、写博客还是做技术分享，都可以直接基于这份上下文展开。

因此，grill-me 更像是一个通用的思考框架，而不是某个特定任务的辅助提示词。

与传统 Prompt 的区别

很多人会把 grill-me 理解成一个高级 Prompt，但它的价值并不在于措辞，而在于工作流。

普通 Prompt 通常是一次性输入：

请在执行前先问我问题，直到你理解需求。

这当然也能起到一定作用。但 grill-me 将这个模式固化成一个可复用的 skill，并强化了几个关键行为：

持续追问，而不是象征性问一两个问题
一次只问一个问题，而不是批量提问
每个问题给出推荐答案
能自行检索的事实不询问用户
只有达成共识后才进入执行

这些细节决定了它的实际体验。

它不是让 Agent “多问问题”，而是让 Agent 以更符合工程协作的方式管理不确定性。

grill-me 与 Superpowers 的区别

在讨论 grill-me 时，很容易把它和 Superpowers 放在一起比较。两者都属于 AI Agent 工作流增强工具，但它们解决的问题并不相同。

简单说：

grill-me 解决的是：开始执行前，需求有没有问清楚。
Superpowers 解决的是：整个 Agent 会话中，应该如何系统化使用一组能力。

grill-me 是一个非常聚焦的单点 skill。它的职责只有一个：在 Agent 动手之前，通过连续追问把用户的模糊需求收敛成明确共识。它不试图接管完整开发流程，也不负责规划、测试、重构或文档沉淀。它更像是 Agent 工作流里的“需求澄清闸门”。

Superpowers 则更像是一套完整的 Agent 方法论或技能体系。它关注的不是某一个具体问题，而是如何让 Agent 在整个会话中持续选择合适的工作方式，例如什么时候应该先研究代码，什么时候应该写计划，什么时候应该做测试驱动开发，什么时候应该调用子 Agent，什么时候应该沉淀文档。

两者最大的区别在于粒度。

grill-me：单一 skill，聚焦需求澄清
Superpowers：工作流体系，聚合多种 Agent 能力

如果把一次 AI 编程会话拆成几个阶段：

需求澄清 → 方案设计 → 实现 → 测试 → 重构 → 文档 → 复盘

那么 grill-me 主要作用在第一个阶段。它确保 Agent 不会在需求还不清楚时过早进入实现。

Superpowers 关注的是整条链路。它更像是在会话开始时给 Agent 装上一套“工作习惯”，让 Agent 在不同任务阶段主动匹配对应能力。

这会带来第二个重要区别：控制权。

grill-me 是用户主动触发的。用户输入 /grill-me，意思很明确：现在先不要执行，先来问我，把需求问清楚。它默认不会自动介入，因为“是否需要被追问”本身也是一种用户选择。

Superpowers 更偏向会话级别的自动化能力编排。它希望 Agent 在任务过程中主动识别当前应该使用哪种能力。这样做的好处是流程更完整，Agent 更像一个有方法论的工程协作者；代价是用户需要接受更多由系统主动发起的工作流判断。

可以用下面这个对比来理解：

grill-me：用户说“现在来拷问我”
Superpowers：系统说“当前任务可能需要这些能力”

第三个区别是适用场景。

grill-me 最适合需求不清、目标不稳、取舍较多的任务。例如改造首页、设计功能、确定技术文章主线、规划课程选题、制定产品方案。它的价值来自“先问清楚再做”。

Superpowers 更适合长任务、复杂工程任务和多阶段开发任务。例如从理解代码库开始，到制定计划、实现功能、补测试、修复问题、整理文档。它的价值来自“让 Agent 按一套更系统的方法工作”。

因此，两者不是替代关系，而是层级关系。

grill-me 可以是 Superpowers 工作流中的一个前置环节。
Superpowers 可以管理更完整的 Agent 开发流程。

如果只是想避免 Agent 在需求模糊时乱改，grill-me 更轻、更直接。如果想把 AI Agent 变成一个具备完整工程习惯的协作者，Superpowers 覆盖面更大。

也可以换一个更工程化的说法：

grill-me 是需求澄清协议。
Superpowers 是 Agent 操作系统。

grill-me 不追求“大而全”。它把一个很小但高频的问题做到极致：让 Agent 在执行前先关闭关键不确定性。

Superpowers 的目标则更宏观：让 Agent 在整个开发会话中持续使用正确的技能、流程和上下文管理策略。

所以，在实际使用中，选择方式可以很简单：

如果你已经知道要做什么，但担心自己没说清楚，用 grill-me。
如果你要让 Agent 接手一个复杂工程任务，用 Superpowers。
如果任务既复杂又模糊，可以先用 grill-me 澄清需求，再进入 Superpowers 式的完整开发流程。

为什么它能降低返工成本

返工的根本原因通常不是实现错误，而是前置决策错误。

如果首页目标本应是订阅转化，但 Agent 按照“作品展示”去设计，那么即使代码写得很干净，也仍然是错的。如果技术文章本应面向开发者，但 Agent 按照泛科普风格写，那么语言再流畅也不能满足需求。

grill-me 降低返工成本的方式，是把高成本错误前移成低成本对话。

在实现前回答一个问题，成本很低；在实现后推翻整套方案，成本很高。

执行前澄清：一次回答即可修正方向
执行后返工：需要重读、重写、重构或回滚

因此，grill-me 的效率并不是来自“少交流”，而是来自“把交流放在正确的位置”。

适合使用 grill-me 的场景

grill-me 特别适合需求模糊但影响面较大的任务。

例如：

改造一个已有页面
设计一个新功能
重构一段核心代码
写一篇有明确受众的技术文章
制定内容选题或课程大纲
生成产品方案或技术方案
确定项目优先级

这些任务都有一个共同特点：执行之前存在多个可行方向，并且不同方向会导致完全不同的产出。

如果任务非常简单，例如修复一个明确报错、替换一个字段名、调整一行样式，那么不一定需要 grill-me。但只要任务中存在目标、范围、优先级或取舍问题，先进行追问通常都是值得的。

grill-me、grill-with-docs 与 batch-grill-me

围绕这个模式，还有几个相关工具。

grill-me 本身只负责追问。它完成需求澄清后，不会额外沉淀文档，适合轻量级的一次性对话。

grill-with-docs 会在追问过程中同步记录项目术语和关键决策。对于长期项目而言，这更接近架构决策记录，也能减少后续协作中的上下文丢失。

batch-grill-me 则面向另一种交互模式：一次性列出当前可以提出的一批问题。它牺牲了一部分对话流畅性，换取更快的信息收集速度，适合用户希望批量回答、快速推进的场景。

可以简单理解为：

grill-me：轻量追问，适合对话式澄清
grill-with-docs：追问 + 文档沉淀，适合长期项目
batch-grill-me：批量问题，适合快速收集上下文

它们底层共享的是同一种理念：Agent 不应该在关键不确定性没有解决前贸然执行。

对 AI Agent 工作流的启发

grill-me 的流行说明了一个趋势：AI Agent 的能力不只取决于模型本身，也取决于任务执行流程。

在早期使用方式中，用户往往把 AI 当成一个即时生成器。输入请求，等待结果，然后反馈修正。

但对于复杂任务，更合理的模式应该是：

先澄清
再规划
再执行
最后验证

其中“澄清”是最容易被忽略的一步。

如果没有这一步，后面的规划可能建立在错误目标上，执行也只是更快地生成错误结果。grill-me 把澄清阶段显式化，让 Agent 在开始工作前先处理需求不确定性。

从工程实践角度看，这是一种非常实用的 Agent 设计模式：

不要让 Agent 直接从模糊需求跳到实现，而要先让它识别并关闭关键决策点。

这也是未来 AI 编程、AI 写作和 AI 产品设计工具中都值得保留的能力。

总结

grill-me 的核心价值不在于复杂实现，而在于它重新定义了 AI Agent 的起手式。

它让 Agent 在执行前先追问用户，通过一次一个问题、附带推荐答案、区分事实与决策等方式，把模糊需求逐步收敛成可执行共识。

对于代码开发，它可以减少方向性返工。对于技术写作，它可以提前确定受众、深度和主线。对于产品和内容规划，它可以把模糊判断拆解成一组明确决策。

在 AI 协作中，真正昂贵的不是多问几个问题，而是在错误方向上快速执行。

因此，grill-me 提供的并不是一个“更会提问的 Prompt”，而是一种更稳健的 Agent 工作流：

先把问题问清楚，再让 AI 开始工作。