从流程门禁到决策盘问：brainstorming 与 grill-me 该怎么选

让 Coding Agent 写代码越来越容易，难的是在它动手前确认目标没有错。brainstorming 和 grill-me 都是高热度的 Agent Skill：它们不负责生成代码，而是把需求对齐、方案审查和决策澄清前移到实现之前。

问题在于：Agent 越能干，错误方向上的执行速度也越快。真正昂贵的失败往往不是某一行代码写错，而是 Agent 在目标、边界、取舍尚未对齐时就进入实现。brainstorming 与 grill-me 都在处理这个问题，但它们处理的不是同一种不确定性。

结论先行：brainstorming 处理“需求尚未成型”的不确定性，grill-me 处理“方案看似成型”的伪确定性。前者是阶段治理，回答“现在是否可以进入实现”；后者是决策治理，回答“这个方案是否经得起追问”。使用者真正要选的不是更强的 Skill，而是更匹配当前任务成熟度的认知刹车。

背景：为什么这两个 Skill 值得比较

截至 2026-06-03 访问 skills.sh 时，grill-me 和 brainstorming 都已经是高安装量 Skill：

Skill	来源仓库	skills.sh 页面展示 installs	skills.sh 页面展示 GitHub stars	首次收录
grill-me	mattpocock/skills	254.1K	115.5K	2026-03-13
brainstorming	obra/superpowers	198.7K	215.9K	2026-01-19

这些数字只能作为热度信号，不能直接当作质量排名。安装量受曝光、仓库声誉、分发渠道和时间窗口影响，很难证明“哪个 Skill 更好”。但它们足以说明一个更有意思的事实：两个并不直接写代码的 Skill，都获得了相当高的使用热度。

这些数据提示，实现前约束类 Skill 至少获得了可见关注和安装，但不能证明具体用户规模或安装动机。在真实使用中，工程师不只需要 Agent 写更多代码，也需要约束 Agent 何时不要写代码、何时必须先问问题、何时应该把设计变成可复核产物。Agent Skill 的价值在这里体现得很清楚：它不是把一句“先想清楚”写得更礼貌，而是把实现前的协作规则固化为可重复触发的工作流。

brainstorming 和 grill-me 之所以值得放在一起比较，正因为它们都位于实现之前。brainstorming 更偏 planning 之前，用来把模糊需求收敛成设计；grill-me 可以发生在 planning 之前，也可以发生在 plan 或 design 草案之后，用来压测已有方案。计划写得好不好，很大程度取决于计划生成之前或进入实现之前，需求、约束和决策有没有被充分暴露。

核心判断：阶段治理 vs. 决策治理

brainstorming 的核心是阶段治理。它把“从想法进入实现”这一步设置为受控阶段切换：Agent 必须先理解上下文、澄清需求、比较方案、展示设计，并在获得用户批准后，才能继续进入后续计划或实现流程。来自 Superpowers 的 brainstorming 明确把这个过程写成 hard gate：没有设计确认，就不能写代码、不能 scaffold、不能调用实现类 Skill。

grill-me 的核心是决策治理。它假设你已经有了一个计划或设计，但这个计划里仍然埋着未命名的分支、依赖和取舍。来自 Matt Pocock Skills 的 grill-me 要求 Agent 围绕计划持续盘问，一次只问一个问题，沿设计树逐个解决依赖，并为每个问题给出推荐答案。

这两个治理对象不同，导致它们的使用时机也不同。

brainstorming 问的是：这个需求是否已经足够清楚，足以进入下一阶段？

grill-me 问的是：这个方案里有哪些看似已经决定、实际仍未被审查的判断？

前者像流程门禁，重点是防止过早进入实现；后者像方案压力测试，重点是防止带着隐含假设进入实现。

一个使用者选择框架：你面对的是哪种不确定性？

选择这两个 Skill 之前，先不要问“哪个更强”。更好的问题是：当前任务的不确定性在哪里？

第一类不确定性是需求尚未成型。你知道大概想做什么，但目标、约束、成功标准、边界条件和可选方案还没有被系统化表达。比如“帮我做一个仪表盘”“把登录体验优化一下”“给这个项目加一个导入功能”。这些请求看起来能直接开工，但里面其实有大量待确认内容：用户是谁、成功标准是什么、是否有兼容性要求、有没有现有模式要复用、哪些行为不能改变。

这时应该优先用 brainstorming。它的目标是把模糊意图压缩成设计合约，让后续 planning 有稳定输入。比如同样是“做一个导入功能”，brainstorming 的第一问更可能是：“这个导入功能要服务谁，成功标准是什么，哪些现有数据或接口不能被改变？”

第二类不确定性是方案看似成型。你已经有了方向，甚至已经写出一段计划，但你担心自己漏掉关键分支。比如“我打算新增一个缓存层”“我准备把状态迁到 URL query”“我想把这个模块拆成两个包”。这类问题最危险的地方在于它给人一种“已经想清楚”的错觉。实际上，缓存失效、迁移策略、边界 API、错误处理、回滚路径、兼容策略可能都还没有被问出来。

这时应该优先用 grill-me。它的目标不是从零生成方案，而是让已有方案经受系统性追问。如果用户已经说“我准备用批处理队列做导入”，grill-me 的第一问更可能是：“队列失败时你希望重试、跳过、回滚，还是让用户手动处理？我的建议是先支持可重试失败记录，而不是全量回滚。”

如果仍然拿不准，可以先问三个问题：

1. 我是否已经能清楚描述目标、成功标准和不可触碰边界？
2. 我是否已经有一个可以被挑战的具体方案？
3. 我是否需要留下正式设计产物，供后续计划、实现或复盘使用？

如果第一个问题答不上来，先用 brainstorming。如果第二个问题答得上来，但你不确定方案是否可靠，用 grill-me。如果第三个问题答案是“需要”，brainstorming 更适合作为主流程，grill-me 可以作为关键决策的补充压力测试。

brainstorming：处理“需求尚未成型”的不确定性

brainstorming 是一个强门禁型 Skill。它的价值不是“多问几个问题”，而是把需求澄清、方案比较、设计确认和规格文档沉淀组织成完整的前置流程。

从 brainstorming 的原文机制看，它包含九个顺序步骤：探索项目上下文、必要时提供可选视觉辅助、一次一个问题澄清需求、提出 2 到 3 个方案、展示设计、写设计文档、自检、用户复核，最后转入 writing-plans。这个流程的终点不是实现，而是进入实现计划。

关键在于，很多 Agent 失败不是因为不会写计划，而是计划输入本身已经错了。Agent Planning 需要目标、约束、依赖、验证方案和回滚路径；但如果需求阶段没有把这些信息收敛出来，计划就只是在包装一个未经验证的猜测。

brainstorming 在这个环节做了三件事。

第一，它强制 Agent 先读上下文。既有代码库里的真实约束通常不在用户的一句话需求里，而在目录结构、已有实现、近期提交、测试习惯和命名风格里。brainstorming 要求 Agent 在提方案之前先理解项目状态，这能减少凭空设计。

第二，它要求逐步澄清，而不是一次抛出一组问题。一次一个问题看似低效，实际是在降低对齐成本。多个开放问题混在一起时，用户容易漏答，Agent 也容易把未回答部分自行补全。逐步澄清让每个决策点都有明确回应。

第三，它要求比较方案并获得批准。这里的设计不是 Agent 的内部思考，而是用户可审阅的中间产物。对于新功能、跨模块改动、架构调整或用户体验设计，设计文档本身就是后续实现的合约。

所以，brainstorming 适合这些场景：需求描述还粗糙，任务影响范围不清，用户无法直接给出成功标准，改动跨越多个模块，或者团队需要留下正式设计记录。它的代价也很明显：流程重、交互多、节奏慢。对于一个低风险的单行配置修改，它可能过度；但对于任何“做错方向会很贵”的任务，这个成本通常是值得的。

grill-me：处理“方案看似成型”的伪确定性

grill-me 是一个极小交互型 Skill。它的正文很短，但抓住了一个高杠杆动作：持续盘问一个计划或设计，直到双方形成共享理解。

grill-me 的关键约束有三条。第一，Agent 要围绕计划的每个方面追问，沿设计树逐个解决依赖。第二，每次只问一个问题。第三，每个问题都要给出推荐答案。如果问题可以通过代码库探索回答，Agent 应该自己查，而不是把事实检索转交给用户。

这让 grill-me 和普通“你觉得还有什么问题吗”的澄清完全不同。它不是请用户补充需求，而是主动把隐藏决策显性化。

举个例子，用户说：“我打算给这个 API 加缓存。”一个普通 Agent 可能会直接问缓存时间多长，然后开始实现。grill-me 更应该追问的是：缓存键如何定义？是否区分用户权限？数据更新后如何失效？失败时是回源、报错还是使用陈旧数据？是否需要观测命中率？这是不是临时优化，还是要作为长期基础设施？每个问题背后都是设计树上的一个分支。

更重要的是，grill-me 要求 Agent 给推荐答案。这让它不是审问式信息收集，而是协作式设计评审。Agent 必须基于上下文给出自己的工程判断，用户只需要接受、修正或拒绝默认建议。这也符合好的 Agent 指令实践：不要只让 Agent 多问问题，还要让 Agent 区分哪些问题该问用户，哪些事实该自己查。

grill-me 适合这些场景：你已经有方案，但想暴露盲点；你要做架构调整，但不确定权衡是否充分；你准备进入实现前，希望有人沿依赖树逐个追问；你不一定需要正式设计文档，只需要让关键假设被检验。

它的代价也要看清楚。grill-me 没有像 brainstorming 那样的文档和复核 gate，结束依赖双方判断是否已经形成共享理解，也不自动产出规格文档。如果用户只有一个非常模糊的念头，grill-me 容易变成没有抓手的追问。它更像压力测试工具，而不是需求成型工具。

三个关键差异：对象、节奏、产物

把两个 Skill 放在一起看，最重要的差异可以压缩为三组：治理对象、交互节奏和产物形态。

维度	brainstorming	grill-me
治理对象	阶段状态：是否可以进入实现	决策节点：方案是否经得起追问
适用输入	模糊需求、初始想法、未成型任务	已有计划、已有设计、待压测方案
交互节奏	渐进收敛：上下文、问题、方案、设计、文档	连续下钻：沿决策树一次一个问题
主要产物	设计合约，可进入后续 planning	被检验过的取舍和显性化假设
主要风险	对小任务过重	对无方案任务缺少抓手

brainstorming 的节奏是从发散到收敛。它允许一开始存在模糊性，但会逐步把模糊性压缩为设计。这个过程天然适合“还不知道要怎么做”的任务。

grill-me 的节奏是从表层方案向深层假设下钻。它不负责帮你从零形成方案，而是要求你把已有方案放到桌面上，接受逐个决策节点的追问。这个过程天然适合“以为已经知道怎么做”的任务。

产物差异也决定了后续协作方式。brainstorming 的产物可以交给后续实现计划，成为 planning 输入；grill-me 的产物更像经过检验的决策记录，未必自动沉淀为文档。实际使用时，如果你希望把 grill-me 的结果带入执行，最好在盘问结束后主动整理为 spec、ADR（Architecture Decision Record）或 implementation plan。

长 Skill 与短 Skill：长度不是强弱，行为杠杆才是

从文件形态看，brainstorming 很长，grill-me 很短。一个自然误解是：长 Skill 更完整，短 Skill 更轻量，所以长的更适合严肃任务，短的更适合随手使用。这个判断只说对了一半。

Skill 的价值不由篇幅决定，而由它是否改变 Agent 在关键时刻的默认行为决定。这也是 Agent Skill 作为能力封装的关键：它把一类可重复触发的行为写成工作流，让 Agent 在特定场景中不再依赖临场发挥。

brainstorming 长，是因为它治理的是完整阶段转换。它必须规定触发条件、禁止事项、澄清方式、方案比较、设计展示、文档位置、自检和用户复核。这里的长度不是啰嗦，而是因为流程中每一步都在防止 Agent 过早进入实现。

grill-me 短，是因为它只固化一个行为杠杆：盘问方案。它不试图接管完整生命周期，也不规定文档模板、测试策略或后续实现。它的强度来自交互姿态，而不是流程覆盖面。

因此，使用者不应该用“长短”来判断选择，而应该看自己需要的是完整流程治理，还是局部行为增强。

如果你面对的是需求不成型、目标不稳定、上下文未读、后续需要正式计划的任务，长流程是价值。

如果你面对的是方案已形成、只差被挑战、需要快速暴露盲点的任务，短 Skill 反而更精准。

这也是两个 Skill 流行背后的共同启发：Agent 写代码的速度越快，越需要在少数高风险认知节点施加约束。真正稀缺的不是让 Agent 继续前进的能力，而是让 Agent 在错误阶段停下来的机制。

误用边界：什么时候它们会失效

brainstorming 的主要误用，是在采用这套 workflow 之前没有判断任务成本。它自己的原文强调即使简单任务也要设计，这在 Superpowers 的强流程哲学里是自洽的；但在具体项目里，仍然需要先判断是否值得采用完整流程。对于低风险、可逆、范围明确的小改动，如果已经有清楚目标和验证方式，完整的设计文档和多轮审批可能会拖慢节奏。这个判断只能发生在触发之前；一旦决定使用 brainstorming，就应该遵守它的 hard gate。

grill-me 的主要误用，是在没有方案时强行盘问。它需要一个可被挑战的对象。如果用户只有一句“我想优化系统”，Agent 很难沿决策树下钻，因为还没有明确的决策树。这时更应该先用 brainstorming 收敛问题空间，而不是让 grill-me 在空泛概念上追问。

两者还有共同边界。它们不能替代代码阅读，不能替代事实检索，不能替代测试验证，也不能替代用户的最终价值判断。grill-me 明确要求能由代码库回答的问题就由 Agent 自己探索，这一点尤其重要：不要把所有不确定性都伪装成需要用户回答的问题。用户应该决定目标和取舍，Agent 应该自行查证代码库事实。

更准确地说，这两个 Skill 不是提升模型能力的捷径，而是让 Agent 在关键阶段不要自作聪明的约束。

使用者选择指南：决策表与执行顺序

实际选择时，可以用“任务成熟度、风险等级、是否需要产物”三个维度判断。

场景	推荐选择	原因
只有想法，目标和成功标准还不清楚	brainstorming	先把意图、约束、方案结构化
已有明确方案，但担心遗漏边界	grill-me	让 Agent 沿决策树追问隐藏假设
新功能、跨模块改动、架构调整	brainstorming 优先	需要阶段门禁和设计合约
小改动、已有实现思路、只想快速校准	grill-me 优先	用较低成本压测关键取舍
经常遇到 Agent 做得很快但方向错	先固定使用 brainstorming	问题多半发生在需求输入阶段
经常遇到上线后才发现边界条件	在 planning 前加 grill-me	问题多半发生在方案审查阶段
高风险任务且方案也已初步形成	先 brainstorming，再 grill-me	先收敛目标和设计，再压测关键决策

更完整的执行顺序可以是：

1. 需求模糊时，用 brainstorming 形成设计合约。
2. 设计初步成立后，用 grill-me 压测关键取舍。
3. 盘问结束后，把结论整理进 spec、ADR 或 implementation plan。
4. 进入实现前，再用测试和验证计划锁定成功标准。

一个简单规则是：没有方案时，不要急着盘问；没有目标时，不要急着计划。这个顺序并不适合所有任务。它适合那些“实现成本低，但方向错误成本高”的任务。对于一次性、低风险、可快速回滚的改动，使用者完全可以只用较轻的 grill-me，甚至不使用这两个 Skill。

结论：成熟的 Agent 使用，是知道何时减速

brainstorming 和 grill-me 的共同价值，是把问题前置到实现前。区别在于它们前置的是不同问题。

brainstorming 让 Agent 在需求未成型时停下来，把意图、约束、方案和设计产物结构化。它适合治理阶段切换，防止 Agent 在不知道目标时就开始实现。

grill-me 让 Agent 在方案看似成型时停下来，把隐藏假设、依赖分支和工程取舍问出来。它适合治理关键决策，防止 Agent 带着未经审查的默认假设进入实现。

所以，最有价值的结论不是“应该选 brainstorming 还是 grill-me”，而是：你要先识别自己面对的是哪一种不确定性。

如果不确定性来自需求尚未成型，选 brainstorming。

如果不确定性来自方案未经压测，选 grill-me。

如果任务风险高、影响面大、后续需要可复核计划，先用 brainstorming 收敛设计，再用 grill-me 压测关键决策。

成熟的 Agent 使用，不是追求更高自动性，而是在高风险认知节点主动降低自动性。真正专业的使用者，不是让 Agent 永远更快，而是知道什么时候该让它停下来问对问题。

参考资料

1. skills.sh: grill-me，访问日期：2026-06-03。
2. skills.sh: brainstorming，访问日期：2026-06-03。
3. GitHub: grill-me/SKILL.md。
4. GitHub: brainstorming/SKILL.md。
5. GitHub: mattpocock/skills。
6. GitHub: obra/superpowers。