
后台有人留言问:grill-me、grill-with-docs、Superpowers,这三个到底什么关系?
不是一条,是好几条,换个问法问的是同一件事。有人刚把 grill-me 装到 Codex CLI,被追着问了十分钟,想知道 grill-with-docs 是不是体验更好。有人 Star 了 obra/superpowers,看 README 里说「subagent-driven development」,不太确定这个和 grill 系列是一个东西还是两个东西。
问题的共性很明显——这三个名字听起来像一家人,但 star 数不一样、仓库不一样、用起来的体验也完全不一样。
那就写清楚。
先把结论撂在前面:grill-me 和 grill-with-docs 是同一类东西——需求澄清工具,区别只在一个从嘴里掏、一个从文档里掏。Superpowers 是另一类东西——软件工程方法论加执行引擎,管的是从 spec 到代码再到 review 的整条流水线。
三者不是谁替代谁。grill 想清楚了,Superpowers 替你跑完。哪个阶段用哪个,顺序不能乱。
话虽这么说,不把三个工具各自跑一遍,光看结论没感觉。下面用同一个场景穿一遍,看看它们分别在做什么。
讨论工具之前,先看一下这三样东西在 GitHub 上的实际存在形态。
grill-me 和 grill-with-docs 的源头都在一个仓库里:mattpocock/skills,⭐ 161,872。Matt Pocock 把他日常使用的 Claude Code skills 开源了,grill 系列就长在这个仓库里。
仓库里的结构很清晰:
skills/productivity/grill-me/SKILL.md — 就一行:Run a /grilling session.skills/productivity/grilling/SKILL.md — 这才是 grilling 的真正实现,一套审讯式的计划审查流程skills/engineering/grill-with-docs/SKILL.md — 工程版的 grilling,先读文档再提问也就是说,grill-me 其实就是 grilling 的快捷入口。真正的逻辑在 grilling 里:Agent 拿到你的方案之后,像高级工程师做 code review 一样逐条追问,直到你说清楚为止。grill-with-docs 加了一层——先吃 spec/README/design doc,然后问文档空白处。
Codex CLI 把这两个模式做进了终端里(codex 选 grill-me 或 grill-with-docs),但它们的思想源头是 Matt Pocock 这套 skill。
Superpowers 是另一个仓库、另一套思路。
obra/superpowers,⭐ 250,193,Jesse Vincent(obra)创建。支持的平台包括 Claude Code、Codex App、Codex CLI、Cursor、GitHub Copilot CLI、Kimi Code、Antigravity、OpenCode、Pi、Factory Droid——几乎覆盖了所有主流 coding agent。
它的 README 里有一段话很准确:
★It starts from the moment you fire up your coding agent. As soon as it sees that you're building something, it doesn't just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do. Once it's teased a spec out of the conversation, it shows it to you in chunks short enough to actually read and digest. After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. Next up, once you say "go", it launches a subagent-driven-development process, having agents work through each engineering task, inspecting and reviewing their work, and continuing forward.
obra/superpowers ⭐250,193,mattpocock/skills ⭐161,872 —— 同一个量级。Vue.js 25 万,React 23 万,Spring Boot 7 万当参照。Matt Pocock 的 grill 方法论和 obra 的 Superpowers 执行引擎,一个管「想清楚」,一个管「做完」,两个仓库加起来 41 万 star。agent 驱动的开发方法论的渗透速度远超传统框架,不是说说而已。
把 grill 和 Superpowers 摆在一起看,很容易陷入「161k vs 250k,Superpowers 更大所以更好」的直觉。但这不是谁大谁小的问题。
它们的本质区别不在 star 数,在角色定位。

grill-me 和 grill-with-docs 是同一维度的两个选项——需求澄清工具。
Superpowers 是完全独立的一个维度——软件工程方法论 + 执行引擎。
grill-me 和 grill-with-docs 解决的是同一个问题:你的需求说不清楚怎么办?
区别只在于 AI 从哪里找线索:
打个比方:
两个模式的核心动作是一样的:提问,逼你想清楚。只是提问时的上下文来源不同。
Superpowers 不做这件事。
Superpowers 不提问。或者说,它的提问是一段程序化的过程。它的核心工作流是:
spec(你描述意图)
→ design doc(AI 输出设计方案)
→ 你 sign-off(人工确认)
→ implementation plan(AI 产出实现计划)
→ subagent-driven-development(AI 自主执行,拆任务、派子代理、review、合入)
这里的关键转折点是你在 sign-off 那一环。一旦你说「go」,后面全是 AI 自己跑。它会派子代理写代码,派另一个子代理 review,遇到问题继续派子代理修,修完再 review,直到所有测试跑通。
Superpowers 的 README 说「It's not uncommon for your agent to work autonomously for a couple hours at a time without deviating from the plan」。翻译过来就是:它自己去忙几个小时,不跑偏。
这和 grill-me / grill-with-docs 有多大的区别?
grill 的功能是「帮你把事情想清楚」。Superpowers 的功能是「帮你想清楚,然后替你做完」。
grill 是设计阶段的工具。Superpowers 是设计阶段 + 实现阶段的工具。
回到 grill-me 和 grill-with-docs 的比较。这个问题其实有标准答案。
你手上有文档吗?
回答「有」→ 用 grill-with-docs。 回答「没有」→ 用 grill-me。
不会有第三种情况。因为两个模式的核心能力完全一样——追问、澄清、补全信息。唯一的变量是 AI 追问的信息来源。
但别把这个答案理解成「有文档就一定用 grill-with-docs」。还有一个隐藏条件:你的文档质量怎么样?
我在实际使用时碰到过一种坑人的情况。你的 spec 写得特别长、特别细,但很多内容是错的或者过时的。这时候 grill-with-docs 会基于错误的文档来提问。典型症状是它问的每个问题看上去都对,但问的方向是偏的。
遇到这种情况的识别方法是:AI 的问题是不是反复在某个方向上纠缠但始终到不了核心矛盾。如果是,说明你喂给它的文档在带着它绕路。
这时候应该怎么做?
不要修文档。先切回 grill-me,重新对一遍核心目标。等核心目标确认了,再回头修正文档,然后重新 grill-with-docs。
这是我踩过一次坑之后总结出来的操作序列:

这个流程的代价是多了一次「人肉输出文档」。但对于正式项目来说,这一步省不了。grill-me 没有记忆,你第一次被问到的那些关键决策,如果不在文档里固化下来,下一次换一个 session,AI 还会从头再问一遍。
grill-me 确认方向 → 产出 spec → grill-with-docs 补齐 → design doc
(不读文档) (人肉输出) (基于文档提问) (最终输出)
问题就出在这里。
很多团队把 grill 当成一次性工具。项目开始的时候 grill 一遍,产出文档,然后就丢一边了。下一次改需求,不再 grill,直接改文档。文档越改越长,质量越来越差,grill 的效果越来越弱。
grill 的正确用法是迭代式的——每次需求变更都要重新 grill。不是 grill 一次吃一辈子,而是每次都要重新过一遍门禁。这才是 Matt Pocock 把 grill-with-docs 放进流程的真正用意:它不是一个需求澄清工具,它是一个持续的需求质量门禁。
这里面还有一个容易被忽略的细节,helloxin 在一篇分析文章里把它讲透了。
grill-with-docs 和 grill-me 的本质区别,不是「问多少问题」,而是是否拥有一份持续维护的业务词典。Matt Pocock 在 grill-with-docs 里引入了 context.md——一个放在项目根目录的共享术语表,记录所有核心业务概念和关系。Agent 在每次会话开始时先读它,对话结束后自动更新它。
这背后的概念来自 Eric Evans 二十年前的 DDD 实践——统一语言(ubiquitous language)。业务人员、开发者和代码库,应该用同一套词描述同一个东西。但现实是:一个叫 courses 的表,API 层叫 lessons,产品经理叫"内容单元",数据库里写的是 items。四张嘴四个名字。AI 不来才怪,来了必疯。
grill-with-docs 解决的就是这个。它不是让 AI 每次多问几个问题,而是让 AI 先掌握你的领域词汇表,再在这个词汇表的基础上追问。这样一来,AI 问的问题不再是泛泛的「你想做什么」,而是「你刚才提到的 X 和 context.md 里定义的 Y 是什么关系」。追问的精度上了一个台阶。
还有个容易被忽略的点:ADR(架构决策记录)。grill-with-docs 在对话后会生成 ADR,记录那些术语表解释不了的不可逆决策——为什么选 PostgreSQL 而不是某个集中式设计、为什么服务边界切在这里、为什么状态机必须这么流转。三个月后回来重构,不用猜当初的动机。
但 helloxin 也指出了一个现实风险:context.md 谁来审?AI 自动更新如果拐进了歧义,后面所有对话都会被污染。建议每次 AI 改 context.md 之后至少做一次快速人工 diff。另外,新项目开始第二天就建 context.md 是过早设计——等出现两次「我居然忘了这个字段叫啥」的时候,术语混乱就到了该整理的临界点。
一句话总结:grill-with-docs 不是 vibe coding 的那条路。vibe coding 让你「别想,让 AI 干」。grill-with-docs 让你「先对齐语言,再让 AI 干」。前期多花十分钟对齐术语,后面所有会话都不用重解释。
回到 obra/superpowers。但你真正该问的是:凭什么?
答案是它的设计哲学不是「提供工具」,而是「定义了一套方法论」,然后让这套方法论自动走完整个软件工程流程。
Superpowers 的核心假设是:
说白了,grill-with-docs 和 grill-me 在解决「Agent 怎么和人配合」。Superpowers 在解决「Agent 怎么和自己配合」。

Superpowers 的名字取得确实好。它不是给了你一个新工具,而是给了你的 coding agent 一套超能力。不是让你变强,是让你的 agent 变强。
但 Superpowers 也不是银弹。它的前提是你的 spec 写得足够清楚,否则 subagent-driven-development 阶段会不断返工。而 spec 写清楚这件事,恰好又是 grill-with-docs 在做的事。
这就是三者真正的协同关系。
如果你现在就想用这三样东西,落地顺序不应该按 star 数来排。应该按你项目当前的状态来。
阶段 1:你没有像样的 spec
从 grill-me 开始。把你脑子的东西倒出来。这个过程很痛苦——你会发现自己以为想清楚的东西其实没想清楚。忍着。这是把模糊需求变成可执行 spec 的必要过程。
这个阶段做完的标志是:AI 再追问你三到五轮,你没有新增信息可给了。
阶段 2:你有了一版 spec
切 grill-with-docs。把 spec 喂进去,让 AI 基于 spec 提问。这一步输出的不是问你「要做什么」,而是「你没写清楚的地方」。这比 grill-me 高效得多,因为不再需要你从头解释每一件事。
这个阶段做完的标志是:AI 问不出新问题了,所有问题你都能一句话回答。
阶段 3:你有了 solid spec + design doc
上 Superpowers。spec 交给它 → 生成 design doc → 你确认 → 生成 implementation plan → 你确认 → subagent-driven-development → 等结果。
这个阶段的关键不是「让 AI 替你写代码」,而是「AI 写代码的过程中你不参与决策」。你前面的 grill + spec + design 已经把所有决策做完了,实现阶段只需要执行。
阶段 4:需求变更
重新从阶段 1 或 2 开始。不要在阶段 3 的状态下直接改需求然后强行让 Superpowers 执行,这是最危险的用法——subagent 会基于旧 spec + 新描述做出你预期之外的事。
说一个我之前观察到的典型翻车场景:
团队 A 在阶段 3 里跑得很好,Superpowers 两个小时自主完成了三个模块。然后 PM 说「用户登录这里,能不能再加个微信扫码」。团队 A 直接在 design doc 里加了一行「支持微信扫码登录」,没有重新 grill-with-docs,就重新跑了 Superpowers。
结果:subagent 把微信扫码登录做成了一个新的登录方式,但没有处理「已绑定手机号的用户用微信扫码登录后,要不要合并账户数据」。这个问题在 grill 阶段一定会被问到,但因为跳过了 grill,implementation plan 里根本没出现这个决策点。上线以后用户发现两个账号重复,数据对不上。
教训很简单:任何需求变更都要重新过 grill。

如果你是候选人,面试官问「你对 AI agent 的 grill 模式和 Superpowers 了解吗」,怎么答。
别上来就解释概念。先给一个一句话判断:
「grill 是帮你把 spec 写清楚的工具,Superpowers 是帮你把 spec 执行完的工具。它们在链条上是上下游关系,不是竞争关系。」
然后拆三层:
如果你面试的是 agent 工程相关的岗位,这段回答已经够用了。因为面试官追问的方向通常是「你怎么保证 agent 不跑偏」,你能直接回答「Superpowers 的子代理 review + TDD 门禁」,这个答案比「我们增加了 prompt 约束」强得多。
我朋友后来问我:「所以你觉得 grill-with-docs、grill-me、Superpowers 哪个最好?」
我说这个问题的问法就有问题。
grill-me 和 grill-with-docs 出自 mattpocock/skills(⭐161,872),Superpowers 出自 obra/superpowers(⭐250,193)。star 数差不多,但它们解决的是完全不同的问题。
grill 解决的是「怎么让 AI 理解你真正要什么」。这个问题的成本,在 Superpowers 的 subagent-driven-development 阶段会被放大——spec 质量差一分,实现阶段的返工可能是十倍。
Superpowers 解决的是「怎么让 AI 在理解你之后替你执行到位」。它不管你的 spec 对不对。spec 对,它能做对。spec 没写清楚,它也能按一个错误的方向「做对」。它不管你的 spec 对不对。spec 对,它能做对。spec 没写清楚,它也能按一个错误的方向「做对」。
所以这不是「哪个更好」的问题。是你在哪个阶段、缺什么的问题。
缺方向感 → grill-me。 缺完整性 → grill-with-docs。 缺执行力 → Superpowers。 三个都缺 → 从头按顺序来。
最后说一句 Matt Pocock 的原话。他说过一段我非常认同的观点:「The goal of grill-with-docs isn't to question your code. It's to question your thinking.」
grill 逼你做的事,不是让代码变好。是让你先想清楚。
然后 Superpowers 替你做到。
参考资料: