首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从「说不清需求」到「AI替你写完代码」:grill + Superpowers 的正确打开方式

从「说不清需求」到「AI替你写完代码」:grill + Superpowers 的正确打开方式

作者头像
java金融
发布2026-07-13 16:24:39
发布2026-07-13 16:24:39
410
举报
文章被收录于专栏:java金融java金融

后台有人留言问: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-megrill-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 从哪里找线索:

  • grill-me:直接从你嘴里掏。不读任何文档,一轮又一轮追着你问。适合你脑子里有东西、但没写文档的场景。
  • grill-with-docs:先读完你的 spec/README/design doc,然后问文档空白处。适合已经有文档、但文档不完整的场景。

打个比方:

  • grill-me 像面试官不看你的简历,直接问「你做过什么项目」,你现场组织语言。
  • grill-with-docs 像面试官先仔细读完你的简历,然后指着上面「主导过微服务架构改造」问「你说一下具体拆了几个服务,每个服务的 QPS 范围是多少」。

两个模式的核心动作是一样的:提问,逼你想清楚。只是提问时的上下文来源不同。

Superpowers 不做这件事。

Superpowers 不提问。或者说,它的提问是一段程序化的过程。它的核心工作流是:

代码语言:javascript
复制
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 的两个模式:什么时候该用哪一个

回到 grill-me 和 grill-with-docs 的比较。这个问题其实有标准答案。

你手上有文档吗?

回答「有」→ 用 grill-with-docs。 回答「没有」→ 用 grill-me。

不会有第三种情况。因为两个模式的核心能力完全一样——追问、澄清、补全信息。唯一的变量是 AI 追问的信息来源。

但别把这个答案理解成「有文档就一定用 grill-with-docs」。还有一个隐藏条件:你的文档质量怎么样?

我在实际使用时碰到过一种坑人的情况。你的 spec 写得特别长、特别细,但很多内容是错的或者过时的。这时候 grill-with-docs 会基于错误的文档来提问。典型症状是它问的每个问题看上去都对,但问的方向是偏的。

遇到这种情况的识别方法是:AI 的问题是不是反复在某个方向上纠缠但始终到不了核心矛盾。如果是,说明你喂给它的文档在带着它绕路。

这时候应该怎么做?

不要修文档。先切回 grill-me,重新对一遍核心目标。等核心目标确认了,再回头修正文档,然后重新 grill-with-docs。

这是我踩过一次坑之后总结出来的操作序列:

  1. grill-me 确认方向(5-10 分钟)
  2. 根据 grill-me 的结果产出或修正 spec
  3. grill-with-docs 补齐细节
  4. 产出最终 design doc

这个流程的代价是多了一次「人肉输出文档」。但对于正式项目来说,这一步省不了。grill-me 没有记忆,你第一次被问到的那些关键决策,如果不在文档里固化下来,下一次换一个 session,AI 还会从头再问一遍。

代码语言:javascript
复制
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 干」。前期多花十分钟对齐术语,后面所有会话都不用重解释。


Superpowers 为什么是 25 万 star

回到 obra/superpowers。但你真正该问的是:凭什么?

答案是它的设计哲学不是「提供工具」,而是「定义了一套方法论」,然后让这套方法论自动走完整个软件工程流程。

Superpowers 的核心假设是:

  1. Agent 不会自己设计流程。 大多数 agent 一看到需求就跳进去写代码。Superpowers 强制它先退一步——spec → design → plan → execute。
  2. Agent 的执行质量需要 review。 它设计了子代理 review 机制——写完就 review,review 不过就重写。不需要人介入。
  3. Agent 需要有纪律。 它内置了 TDD、YAGNI、DRY 的原则。不是建议,是强制执行。
  4. Agent 需要跨平台。 同一套技能,在 Claude Code、Codex CLI、Cursor 上都能跑。

说白了,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 执行完的工具。它们在链条上是上下游关系,不是竞争关系。」

然后拆三层:

  1. grill-me vs grill-with-docs 的本质区别是信息来源。 一个从人嘴里问,一个从文档里读。文档质量决定了 grill-with-docs 的上限,所以生产环境里通常是 grill-me 先定方向 + grill-with-docs 后续迭代。
  2. Superpowers 的核心设计是 spec → design → plan → subagent-driven-development 四段流水线。 它的创新点不在代码生成,在于流程纪律——TDD、子代理 review、YAGNI 原则不是建议而是强制执行。
  3. 三者完整的协作链路是 grill → spec → grill-with-docs → design → Superpowers execute。 每一步的输出是下一步的输入。中间任何一环跳过,都会被下一环放大问题。

如果你面试的是 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 替你做到。

参考资料:

  • mattpocock/skills — grill-me、grilling、grill-with-docs
  • obra/superpowers — Superpowers
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-07-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 java金融 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 先把实物摆出来
  • 它们根本不在同一个维度
  • grill 的两个模式:什么时候该用哪一个
  • Superpowers 为什么是 25 万 star
  • 工程上怎么落地
  • 面试怎么答
  • 回到开头那个问题
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档