前言
Vibe Coding 圈子最近有个讨论很火：让 AI 写代码之前，到底该用 superpowers 还是 grill-me 来把需求聊清楚？
这两个工具经常被放在一起提，都走"先盘问需求再动手写"的路子。但要真说清楚差在哪，很多人心里其实没有硬答案--装是都装了，具体对比没跑过。
这个问题的价值在于，它问到了 Vibe Coding 的一个核心痛点：AI 写代码最大的浪费不是算力，是返工。 需求没聊清楚就让 AI 动手，写完发现方向错了，重新来一遍的 token 成本和时间成本远高于多问几个问题。superpowers 和 grill-me 代表了两种截然不同的"需求澄清哲学"，搞清楚它们的差异，比选哪个更重要。
为了把对比做扎实，我拿了一句刻意留白的需求，分别喂给挂载了这两个 skill 的同一个 Claude Code 实例。需求原文是"做个网页版地铁跑酷风格的小游戏，角色不停往前跑，躲障碍物、捡金币那类玩法"，至于俯视还是横视、键鼠还是触屏、什么画风、难度怎么递增，统统没说，就看两个 skill 各显神通把空白填上。
跑完以后的差距相当直观：一边交付的是蓝天白云下戴着红帽子的小人，连身影投射都画出来了；另一边则是深蓝夜色里，绿色方块躲避黄色方块的极简画面。完全相同的输入，产出的视觉完成度差了一个层级。
读完这篇文章，你能搞明白：
- superpowers 和 grill-me 根本不是一个物种：一个是单点工具，一整套工作方法论
- 提问数量的差异背后是设计哲学：12 问逐个拍板 vs 4 问打包默认，哪个更适合你的场景
- 需求共识落地方式的差异：对话即共识 vs 文档化归档，对后续可维护性的影响天差地别
- paper trail 的工程价值：为什么 superpowers 会自动 git init、写设计文档、拆测试任务
- 什么场景该装哪个：不是哪个更好的问题，是哪个更适合你当天要干的活
- Vibe Coding 需求澄清的通用原则：不管用哪个工具，需求澄清的核心逻辑是什么
不管你是 Vibe Coding 的日常用户，还是团队里要选 AI 编程工作流的技术负责人，这篇实测对比都值得收藏。
开搞！
一、这俩压根不是一个物种：工具 vs 方法论
讲过程之前，得先掰清一个误会：很多人以为 superpowers 和 grill-me 是同类工具，其实不是。
grill-me 这个 skill 的描述拢共就三句话，精髓可以概括为"死磕式追问、单次单问、代码能查的就别来烦人"。它的定位是一柄精准的手术刀--切口小、刃口利、切完即收。截至撰稿时，其社区源仓库 mattpocock/skills 在 GitHub 上的 star 数已突破十八万，堪称 Vibe Coding 领域流传度最高的轻量 skill。
superpowers 则是完全不同体量的存在。作者 Jesse Vincent 是海外资深开发者，这个插件包内含二十余个 skill，串起了一条覆盖全生命周期的开发流水线：先用 brainstorming 模块对齐需求，需求确认后自动产出设计文档，接着 writing-plans 把工作拆解为可执行的任务单元，再调度子代理逐个落地，过程中还硬性嵌入 TDD 和代码审查环节。截至撰稿时，其主仓库 obra/superpowers 的 GitHub star 已超二十六万，并已被收录进 Claude Code 官方插件目录。
翻译成大白话：grill-me 是一把趁手的工具，superpowers 是一套带纪律性的工作方法论。 装前者等于给自己配了个随叫随到的助手，装后者等于给 Claude Code 聘了一位流程严苛的工程经理。
装法也不一样。grill-me 是社区 skill，一行 npx 命令跑完勾上就行。superpowers 进了官方插件市场，也是一行命令的事。
所以这场对比里，真正跟 grill-me 同台的是 superpowers 里负责问需求的那个 skill，叫 brainstorming。它俩干的是同一件事：在写代码之前，把你脑子里的糊涂账逼出来。
二、grill-me 怎么审：12 问逐个拍板
先测 grill-me，把那句模糊需求原样丢给它。
它上手第一件事是扫描工作目录。发现是空目录后，主动表态"当前是全新项目、没有可参考的代码，那就从设计层面把方案敲定"，随即切入提问模式。
第一问就是最上游的岔口：伪 3D 三车道，还是 2D 横版？它推荐前者，理由是"三车道左右切换是这个玩法的灵魂"。
后续的追问节奏，就是 grill-me 的招牌打法：严格保持单次单问，每个问题都附带推荐选项，沿着设计决策树自顶向下逐层推进。视角敲定了才问渲染方案，操作动作集确定了才问障碍物分类，前一个回答自然约束后一个问题的可选范围。这轮测试它一共抛出 12 个问题，其中 11 个我直接采纳了它的推荐。
唯一一次没同意，是第 9 问：美术风格。
这一问值得单独说。它给了三个选项：明快日间卡通、霓虹夜跑、像素风。它给出的推荐项是霓虹夜跑风，附带的理由相当坦率："这其实是扬长避短的策略，手头没有美术素材、全凭代码绘制，暗色调刚好能遮掩远处场景细节不足的问题。"
这套逻辑确实站得住脚，但我偏要原版那种阳光明媚的视觉调性，于是整场测试里头一回驳回了它的建议，选了日间卡通路线。它没有反复劝阻，而是爽快应下："行，那我会在细节层面多做文章来弥补质感，给角色和障碍物加投影，列车补上车窗和光泽线条，天空用渐变色配云朵。"
记住这个瞬间，后面有用。
12 问用了 16 分钟。问完它给了一张"设计共识总览"，把定下来的东西和明确不做的东西（排行榜、角色商店、迎面列车全部留二期）列了一遍，回"确认"就行。
然后等待不到十分钟，一个 51KB 的 index.html 一次成型。从发需求到验证完毕，全程 30 多分钟，其中有一半时间花在审问上了。
成品就是开头你看到的那版蓝天白云。有一点很好笑：做出来的下滑操作动作设计有一种很滑稽的感觉，撞到障碍物时也有挂掉的表情。
完工后我专门检查了工作目录，除了那个孤零零的 html 文件外别无他物--没有版本库、没有文档、没有任务清单。换句话说，前面 12 轮问答敲定的所有设计决策，全程没有落盘成任何文件，仅存活在对话上下文里。对话记录还在，共识就在；一旦记录丢失，这些决策就只能靠反推代码来还原了。
三、superpowers 怎么审：4 问打包默认
轮到 superpowers。另开一个空目录，敲命令，同一句需求原样发出。
它同样从目录扫描起步，但提问的交互形态截然不同。不是逐行文字来回，而是以选项卡片呈现，用方向键选中后回车确认，甚至支持多选。
最关键的差别是数量：它只问了 4 个问题。视角、目标设备、要哪些附加功能、技术栈，完事。
问得少不代表有遗漏，它其实把大量决策隐式折叠进了选项描述里。以技术栈这个问题为例，推荐选项的备注里藏着一句"画面全部走 Canvas 程序化绘制，无需图片素材"。
注意到关键点了吗？grill-me 那边花了整整一轮专门追问、还被我驳回重选的美术风格决策，在 superpowers 这边仅仅是选项备注里的半句附带说明。游戏的视觉长什么样，它直接替你拍板了。
前面埋的那个伏笔，答案就藏在这半句话中。两版游戏视觉层级的巨大落差，和模型能力无关，根源在于一边把美术风格视为必须由你确认的决策项，另一边把它归入不值得打扰你的默认配置。
4 问之后，它先甩出三个技术方案让挑，然后一口气输出了完整设计：文件结构、玩法机制、渲染方案、错误处理、测试策略，一屏都放不下。
回"确认"。接下来发生的事，grill-me 那边一件都没有。
四、superpowers 的流水线：从设计文档到 git 归档
它第一步把设计要点整理成文档，写入 specs 子目录，并自动做了一轮一致性自检。值得强调的是，全程没有人提过版本管理，它却主动执行了 git init 和首次提交，连 commit message 都写得有模有样。
紧接着它无缝切换到计划编写模块，输出了 10 个任务分解、54 条单元测试用例、16 项浏览器端人工验证条目，每个任务都遵循"先写红色测试、再写绿色实现"的 TDD 循环。计划生成完毕后询问执行模式，我选了它建议的子代理并行方案。
随后它创建了一条功能分支，进入流水线作业模式。每个任务由一个专属子代理负责实现，完成后另一个子代理接管审查，发现瑕疵再调度第三个子代理修补。那一晚它累计派出了 24 个子代理，我基本没有介入的余地，也不需要介入。
到了半夜，它在第 5 个任务处陷入了停滞。子代理停止响应，随后 API 连接也中断了。等了一阵未见恢复，我便去睡了。次日清晨发了句"继续任务"，它清理掉残留的中间文件、重新调度了一个子代理，不到一分钟就完成了卡住的任务，随后继续推进。
全部跑完后，交付物就是开头提到的深蓝夜色版。游戏确实可玩，跳跃、下滑、变道操作都很流畅，但和 grill-me 那版放在一起比较，画面就是几个纯色几何体在移动，视觉上明显素淡。
不过这一版游戏难度相对较高，跑没多久提速特别快，障碍物越来越密集，跑没一分钟就容易挂。
完工后我同样检查了它的产出目录，景象截然不同--一套规整的工程化结构展现在眼前：入口文件、依赖清单、样式目录、js 模块目录（10 个子模块各司其职）、测试目录（8 个测试文件 55 条用例全部通过）、文档目录（包含 specs 下的设计规格和 plans 下的任务拆解）、以及 .superpowers 配置区（记录了每个子代理的任务简报、完成报告和审查差异）。
docs 目录是其中的亮点：当初对齐需求时敲定的每一项设计决策、后续拆解出的任务计划，全部以文档形式沉淀在项目内。叠加 14 条 git 提交记录，这个游戏从零到一的演进路径随时可追溯。日后要调整玩法，把设计文档喂给一个全新的会话就能接续，不必把需求从头复述。
五、体验差异的三层拆解：目的、归谁、配合谁
两边跑完，数据摆在一起是这样的：
| 维度 | grill-me | superpowers |
|---|---|---|
| 提问数 | 12 问，一次一问 | 4 问，选项卡片 |
| 拍板次数 | 13 次 | 8 次 |
| 留下的东西 | 只有代码文件 | 代码+测试+设计文档+git提交记录 |
| 耗时 | 32 分钟 | 约 2 小时（不算卡死那一晚） |
但数字背后的差别，我觉得是三层。
第一层差异在提问的意图。 grill-me 的 12 轮追问，目的是把每项决策都推到你面前，强制你逐一确认每个细节。superpowers 的 4 轮提问，目标只是收集开工所需的最少信息，其余部分用"合理默认值"自动填补。因此两版游戏视觉效果的鸿沟，不源于模型能力高下，而源于一边问了一边没问。
第二层差异在问完之后的主导权归属。 grill-me 问完即撤，不写文件、不碰版本库，设计共识仅存在于对话上下文中，接下来直接写代码还是切到 Plan Mode 全凭你定。superpowers 问完才是开始：规格文档、任务拆解、强制 TDD、双重审查，一整条流水线整装待发。它留下的文档和提交记录，海外社区称之为 paper trail（纸质痕迹），事后回溯决策、跨会话接续开发全指望这些。
第三层也是最根本的差异，在于谁迁就谁。 grill-me 随叫随到、用完即走，你既有的工作节奏完全不受影响。superpowers 则自带一套规矩：它会自行初始化版本库、自行决定开分支、自行要求测试先行。安装它，就意味着接纳它的工作范式。更关键的是，按其设计意图，这套流程会在你表达需求时自动激活--正常使用时你说一句"我想做某某"，它就自动跳出来接管全局。
也有人说它最狠的就是这点：没有复杂度阈值，改个小东西它也想给你走全套流程。有个总结很到位--"干大活是真行，干小活是真折磨"。
六、什么场景反而不该用 superpowers？边界在哪里
superpowers 看起来很强大，但并不是所有场景都适合上它。实测下来，以下几个场景用它反而会拖后腿。
场景一：一次性脚本和原型验证。 你就想快速验证一个想法，写个几十行的脚本跑一下看看效果。superpowers 会给你走全套：写设计文档、拆任务、写测试、派子代理审查。等它把流程跑完，你手动写早就验证完了。这种场景 grill-me 甚至都不需要，直接说需求让 AI 写就行。
场景二：已有项目的局部修改。 项目已经有了完整的代码结构和开发规范，你只是要改个 bug 或者加个小功能。superpowers 的自动 git init 和分支策略可能和项目现有的 git flow 冲突，它生成的 spec 文档也未必符合项目已有的文档规范。这种场景用 grill-me 问清楚改哪里、怎么改就够了。
场景三：对产出风格有强控制需求的场景。 你对代码风格、文件结构、技术选型有明确偏好，不希望 AI 替你做这些决定。superpowers 的"合理默认值"机制会替你做很多决定，虽然质量不低，但不是你的决定。grill-me 的逐个拍板模式在这种场景下更可控。
场景四：时间敏感的快速迭代。 superpowers 的全套流程耗时是 grill-me 的 4-5 倍。如果是在做快速原型验证或者黑客松这种时间紧迫的场景，花两小时走完整流水线不现实。
场景五：学习和探索阶段。 你刚开始学一个新技术，不确定该怎么做，需要边写边试。superpowers 的 TDD 流程要求你先写测试再写实现，但学习阶段你连实现长什么样都不知道，写测试无从下手。
一句话总结边界：superpowers 适合"目标明确、改动面大、返工代价高"的项目级开发；grill-me 适合"快速验证、局部修改、风格强控"的日常开发。
七、给一线技术人的几条选型建议
不管你最终选哪个，以下几个通用原则在 Vibe Coding 的需求澄清阶段都适用。
建议一：commit 时间比 star 数更重要。 选 skill 的时候别只看 star 数，看最近 commit 时间。一个半年没更新的 skill，再高的 star 也可能已经和最新版 Claude Code 不兼容。grill-me 和 superpowers 截至撰稿时都在活跃维护，但选其他 skill 时这条一定要查。
建议二：先试小项目再上大项目。 不管选哪个 skill，先拿一个你熟悉的小项目跑一遍完整流程，摸清它的脾气。直接上大项目，万一 skill 的风格和你的预期不匹配，返工成本很高。实测发现 superpowers 的"自动接管"行为在小项目上更可控，因为你能看清楚它每一步在干什么。
建议三：issue 区是隐藏的金矿。 选 skill 前去 GitHub issue 区翻一圈，看看大家踩过什么坑。superpowers 的 issue 区有人提到"复杂度阈值缺失导致小任务也走全套流程"的问题，这和实测体验完全一致。这些信息比看任何测评文章都真实。
建议四：别用 skill 替代你的判断。 grill-me 的推荐答案和 superpowers 的默认值都是基于通用经验的，不一定适合你的具体场景。实测中 grill-me 推荐霓虹夜跑风格，但我知道我要的是日间卡通风格，拒绝了它的推荐。AI 给的默认值是起点不是终点，最终决定权在你手上。
建议五：两个都装，按场景切换。 这俩不冲突，可以共存。日常小活用 grill-me，正经项目用 superpowers。关键是你得清楚每个 skill 适合什么场景，别拿着锤子看什么都是钉子。
总结
- 不是同类工具：grill-me 是单点工具（问完就走），superpowers 是一整套工作方法论（问完才开始）
- 提问哲学不同：grill-me 12 问逐个拍板逼你想清楚，superpowers 4 问打包默认替你做决定
- 产出物差异巨大：grill-me 只留代码文件，superpowers 留下代码+测试+设计文档+git 提交记录
- paper trail 的价值：superpowers 的文档归档让项目可回溯、可交接、可跨会话续接
- 边界要分清：superpowers 适合项目级开发，grill-me 适合快速验证和局部修改
- 选型看场景不看排名：没有更好的工具，只有更适合当天要干的活的工具
grill-me 问完，活还是你的。superpowers 问完，活就是它的了。一个逼你把心思想清楚，一个只需要你点头。哪个更好？看你那天想当谁。
你在 Vibe Coding 时用过这两个 skill 吗？欢迎评论区聊聊你的体验。
