2026 年再看 Superpowers：轻量需求对齐，grill-me 或许更合适

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 168 篇，AI 编程最佳实战「2026」系列第 54 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

Superpowers 与 grill-me 场景选型信息图

Agent 接到一个模糊需求，常见反应有两种：要么直接开工，要么甩出一张十问问卷。

前者容易带着错误假设一路写下去。后者则把梳理成本全推给用户。

我读完 Matt Pocock 的 Skills 源码后，有一个很明确的判断：会提问不算稀奇。

/grill-me 把查事实、问决策、等确认压进一个很窄的接口，并在共享理解形成前锁住执行权限。

代码不多。设计却很硬。

1. 7 行文件，行为藏在哪里

mattpocock/skills 把自己定位成一组小型、可修改、可组合的 Skills。

它没有接管整套开发流程，常见问题被逐个拆开。

/grill-me 只盯一件事：Agent 还没理解用户要什么，就急着行动。

先看入口。skills/productivity/grill-me/SKILL.md 的正文只有一行：

Run a `/grilling` session.

它的 frontmatter 设置了 disable-model-invocation: true。

按仓库 README 对 user-invoked 与 model-invoked 的区分，这意味着 /grill-me 是用户主动触发的入口。

真正定义访谈行为的，是可被其他 Skill 调用的 skills/productivity/grilling/SKILL.md。

这层拆分很像 CLI 与库函数：

• /grill-me 面向人，负责启动；
• /grilling 面向 Skill，负责保存访谈纪律。

README 还约束了调用方向：用户入口可以调用模型入口，但不应再调用另一个用户入口。

交互命令和可复用能力也就没有揉成一团。

调研所对应的源码版本里，grill-me 有 7 行，grilling 有 12 行。后面会讲到的 grill-with-docs 也是 7 行。

行数短只说明接口窄，不证明模型更省 token，也不证明执行效果更好。 当前材料没有这类对照实验。

grill-me 用户入口与 grilling 原语分层图

图 1：用户入口负责启动，可复用原语保存访谈纪律

2. /grilling 到底管了什么

/grilling 的规则不多，但每条都卡住一种常见跑偏方式。把它展开，大致是一台轻量状态机：

探索事实
→ 找到当前依赖链上靠前的决策
→ 提出一个问题，并给出推荐答案
→ 等待用户回答
→ 更新双方理解
→ 用户确认理解完整
→ 解锁行动

五条规则，分别卡住五种跑偏方式。

沿决策树推进

它要求 Agent 沿决策树逐个分支往下走。问题之间存在依赖时，先解决上游决策，再决定下一个问题是什么。

静态问卷做不到这一点。用户刚刚否掉方案 A，后续只服务于 A 的问题就可以消失。

对话在这里更像逐步求值：每个答案都会改变下一步。

一次只问一个

源码明确要求一次提出一个问题，并等待反馈。这个限制看着朴素，其实是控制流。

十个问题一起抛出来，Agent 只能提前猜测它们彼此独立。

逐问逐答则允许后一个问题消费前一个答案，避免用户回答已经失效的分支。

问题必须带推荐答案

/grilling 不允许 Agent 只说：请描述你想要的系统。

它要先完成分析，再给出一个推荐，让用户同意、反对或修正。

用户面对的输入，从空白页变成一份具体提案。

比如：我建议先保留现有认证层，因为本次需求只改变授权规则。你是否同意？

分歧会落在假设、边界或代价上，而不是困在泛泛讨论里。

人的决策权没有被拿走。Agent 承担查找与整理成本，人负责拍板。

事实和决策分开走

这是这套设计里我更看重的一条。

能从文件系统、源码或工具中查明的事实，Agent 自己去查。

涉及产品取舍、价值判断和偏好的决策，必须交给用户回答。

CHANGELOG 记录过这条规则的演进。旧表述只要求 Agent 自行探索代码库。

按变更记录，在嵌套调用时，这种写法曾让 Agent 连决策也自行回答。

2026 年 7 月 6 日的提交把两类问题拆开，明确了 HITL（human in the loop，人参与决策）的边界。

这同时堵住两种浪费：README 里写着的事实，不再拿来考用户。

Agent 觉得自己能推断的产品取舍，也不能擅自拍板。

共享理解是行动门禁

访谈什么时候结束？不是 Agent 自己觉得差不多了。

2026 年 7 月 3 日的提交把完成条件收紧为显式 stop-gate：只有用户确认双方已经形成共享理解，Agent 才能行动。

换句话说，理解没有验收，执行权限就不解锁。

这就是 /grill-me 和普通多问几句的区别。提问只是过程，权限门禁才是结果。

事实决策分流与共享理解行动门禁图

图 2：事实由 Agent 查，决策由用户确认，理解验收后才解锁行动

3. 为什么还需要 /grill-with-docs

/grill-me 默认追求共享理解，却不保证留下规格文件。

GitHub Issue #311 的提交者报告过一个具体问题：会话里形成了结构化决策，之后却不容易追溯理由。

这个案例与源码行为一致，但它只是单个反馈，不能外推成普遍体验。

Matt 的仓库没有把文档能力硬塞回 /grilling。

它另做了组合入口 /grill-with-docs，一边运行 /grilling，一边使用 /domain-modeling。

后者补上的工作包括：

• 挑战含混术语；
• 用边界场景压力测试领域关系；
• 用源码核对口头描述；
• 术语确定后写入 CONTEXT.md；
• 满足严格条件时再提出 ADR（Architecture Decision Record，架构决策记录）。

ADR 也不是逢决策就写。

调研报告对应的源码要求三个条件同时成立：决定难以逆转、缺少背景会让后来者意外、确实存在取舍。

源码分层表达了一个明确取舍：访谈纪律保持窄接口，默认不强制持久化；

需要文档产物时，由外层 Skill 叠加。

这是我基于源码分层做出的分析，不是 README 的原句。

作者公开课程页也给出了更具体的使用建议：在编码规划里，他已不再把 /grill-me 作为优先选项。

需要和代码库对齐时，推荐 /grill-with-docs 或更完整的 domain-model 流程；/grill-me 仍适合做轻量的计划压力测试。

所以，别把轻量误解成适合所有任务。规格落盘、领域词汇和计划交接，本来就不在这个入口的默认职责里。

grill-with-docs 文档能力组合关系图

图 3：访谈原语保持轻量，文档能力由外层入口按需叠加

4. 对照 Superpowers：访谈原语和规格流程

只看篇幅，/grill-me 短，Superpowers brainstorming 长。问题不在长短，而在于目标产物不同。

两者都要求先理解上下文、一次只问一个问题、给出具体建议，并在人确认前禁止实施。到这里，它们很像。

之后路径就分开了。

Superpowers 的 brainstorming 会要求比较 2 到 3 种方案，再分段展示设计。

随后写入设计文档、完成规格自检、等待用户审阅，并交给 writing-plans。

它是一条规格生产流程，不只是更长的访谈。

它为什么要写得这么重？Superpowers 的发布说明给出过项目自身的教训。

早期规格审阅循环虽然写在说明文字里，但因为没有进入 checklist 与流程图，模型会跳过。

后来项目把它补进强制清单和流程图，并增加集成测试。

这份证据的边界到此为止：Superpowers 遇到过这个问题，也做了修正。它不能证明所有模型都需要同样密度的约束。

我的判断是：Matt 的方案把少量纪律集中成可嵌入原语。

Superpowers 用重复编码的流程约束，换取更完整的规格产物和交接门禁。

前者默认缺少持久记录，后者则要承担更多流程与项目配置协调。

Superpowers Issue #939 就记录过一个具体摩擦：brainstorming 的默认输出路径压过了项目 CLAUDE.md 中的路径偏好。

它能提醒我们，规则越密，协调面越大；但单个 Issue 也不足以证明整个项目不遵循用户配置。

这里没必要分出谁全面胜出。先问自己要的是一场需求拷问，还是一份经过审阅、可以交接的规格。

grilling 与 Superpowers brainstorming 流程对照图

图 4：两者重合在访谈阶段，分开在目标产物与流程重量

5. 什么时候该用，什么时候别用

安装命令来自 mattpocock/skills README：

npx skills@latest add mattpocock/skills

安装需要的 Skills 后，由用户主动执行 /grill-me。

不过，disable-model-invocation 是具体运行环境的 frontmatter 能力，不同 Agent 工具是否支持，仍要看各自实现。

什么时候适合用 /grill-me，可以直接按边界判断：需求只有方向，边界还没定。

或者计划看着完整，里面藏着默认假设。

你希望 Agent 主动推荐，但关键决定仍由你确认；或者你正在写自己的 Skill，需要嵌入一段 HITL 访谈。

下面几类任务，我会换工具或叠加能力：

• 要正式规格文件：接 /to-spec，或走 Superpowers brainstorming；
• 要统一领域词汇、核对源码并记录 ADR：用 /grill-with-docs；
• 跨多个子系统，单次会话难以承载：按 README 和 CHANGELOG 的建议看 /wayfinder；
• 需求已经明确，只剩机械执行：没必要再跑完整 grilling；
• 要可审计的流程遵循：Superpowers 的清单、审阅门禁和测试更贴近这个目标。

边界也很明确：当前公开材料没有可复核的对照实验。

这些材料不能证明 /grill-me 或 Superpowers 在开发速度、成功率、返工率、耗时与 token 消耗上占优。

源码能证明流程差异，证明不了固定收益。

6. 怎么选

/grill-me 表面上只是一个 7 行入口，设计重心却落在它背后的 /grilling。

一次一个问题，附带推荐答案；事实由 Agent 查，决策留给人。

共享理解未经用户确认，行动就继续锁着。

需要文档时，/grill-with-docs 再把领域建模、CONTEXT.md 和条件式 ADR 叠上去。

需要完整规格与交接，则 Superpowers brainstorming 更贴近目标。

我的结论很具体：只想把模糊想法问清楚，选 /grill-me；要让理解落盘并和代码库对齐，选 /grill-with-docs。

要一条带审阅和计划交接的规格流程，再看 Superpowers。

工具的重量应该跟产物匹配。

本文依据 2026 年 7 月 15 日的调研报告与其列出的源码版本整理。

仓库仍会变化，实际规则请以当前 SKILL.md 为准。

说明：本文基于 Matt Pocock Skills 与 Superpowers 在 2026 年 7 月 15 日的本地源码、官方文档、变更记录及可追溯公开讨论整理，重点比较 /grill-me、/grilling 与 Superpowers brainstorming 的职责和流程边界，未对开发速度、成功率、返工率、耗时或 token 消耗做对照实测。文中的配置模板和参数建议仅供参考，实际效果请以你的业务数据和环境测试结果为准。如果你实际使用过这些工作流，欢迎在评论区分享体验与取舍。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！