Superpowers 太重之后这个只有几行的 Grill Me 火了过去一段时间只要搜索 Coding Agent SkillsSuperpowers 几乎绕不过去。它把头脑风暴、工作树、计划、TDD、代码审查和分支收尾串成一条完整开发链给容易拿到需求就开写的 Agent 装上一整套工程纪律。但强模型正在让这套「全家桶」遇到一个新问题模型本身已经会规划、会选择 Skill、会执行外部流程再从头接管一次增量可能变小摩擦反而变大。我在这次实测前后正好看到一位 GPT-5.6 Sol 用户主动删除 Superpowers。他给出的理由不是它做得差而是新模型本身已经很 agentic再叠重流程可能带来误调用、上下文污染、Token 增加甚至两套流程互相卡住。这条帖子不是「Superpowers 已死」的证据。Superpowers 官方仍然支持 Codex也在持续更新。它真正暴露的是一个更值得实测的问题当整套 Superpowers 对当前任务显得太重能不能只留下最值钱的头脑风暴同一时期一个只有几行核心规则的 Grill Me 开始被反复讨论。它不接管 TDD、代码审查和分支收尾只在开工前不停追问直到 Agent 与用户形成共同理解。我拿一个真实个人网站试了一遍想看清楚三件事Grill Me 到底从 Superpowers 里保留了什么、它和 Codex Plan 模式为什么不是一回事以及这层轻量约束能不能真的减少方向性返工。标题里写「太重」必须先把适用范围说清楚Superpowers 不是设计失败恰恰是因为它把开发过程管得足够完整才会成为过去 Skills 推荐里的常客。Superpowers 不是设计失败而是管得太完整① Superpowers 是什么Superpowers[1]是 Jesse Vincent 和 Prime Radiant 团队维护的一套 Agent 软件开发方法论。它不是单独一个提示词而是一条完整链路头脑风暴、创建工作树、编写计划、子 Agent 执行、测试驱动开发、代码审查并完成分支收尾。早期 Coding Agent 最常见的问题是拿到一句需求就开写。Superpowers 的办法是给每个阶段加硬门槛没想清楚不能实现没写计划不能执行没跑验证不能宣布完成。模型能力还不够稳定时这种外部流程能把一次「凭感觉写代码」变成更可控的软件工程。② brainstorming 是最值钱的那块其中最重要的一块就是brainstorming[2]。它要求 Agent 先查看项目再一次只问一个问题随后给出 2—3 种方案和取舍分段展示设计得到用户批准保存设计文档获批后只能进入writing-plans。这也是为什么过去推荐 Skills 的文章经常绕不开 Superpowers它不是替模型补一个零散能力而是给不稳定的模型装上一整套纪律。复杂开发、多人协作、严格 TDD 和分阶段审查今天依然能从这套纪律里受益。③ 我自己的用法我自己的做法更极端一些。在 agentcoding 的工作流里Superpowers 我只用一样东西头脑风暴。实现、测试、审查 、归档 spec 文档这些流程全部交给 openspec 处理。这么做的原因是头脑风暴那一步确实能把需求从「我大概想要什么」逼成一组可以执行的决定这一步的增量很明显。但后面的 TDD、代码审查、分支收尾强模型配合 openspec 已经能处理得很好再叠一套 Superpowers 的流程摩擦大于收益。它为什么会在强模型上显得重① 默认加载整套流程的问题问题出在「默认加载整套流程」而不是某个 Skill 本身做得差。当模型已经具备较强的原生规划、工具选择和执行能力时Superpowers 的控制层可能与模型自己的控制层发生重叠原生 Plan 模式想先规划Superpowers 的brainstorming又要求先走自己的设计审批模型会自行选择 Skillusing-superpowers又要求每个任务先检查完整技能链小任务本来可以直接完成却也可能被头脑风暴、设计文档、计划和审查层层接管多套规则同时争夺下一步动作时原本为了防止模型乱跑的护栏也可能变成新的岔路口② 重叠带来的摩擦这种重叠不一定每次都会出问题但它会增加思考时间、上下文占用和流程摩擦。任务越小、模型越主动整套方法论的相对重量就越明显。这里必须补一条边界截至我核对时Superpowers 官方仍然支持 Codex而且还在持续更新。它的 2026 年发布记录甚至专门加入了子 Agent 上下文隔离用来减少上下文污染[5]。所以「GPT-5.6 不再推荐 Superpowers」不是官方结论更准确的说法是对于已经具备强规划和执行能力的模型不一定还要默认加载整套 Superpowers。重不等于无用它意味着流程的控制范围可能超过了当前任务真正需要的范围。这个只有几行的 Grill Me接住了什么① 来源和背景真正值得关注的不是把 Superpowers 从工具箱里扔掉而是问整套方法论里哪一段对强模型仍然有明确增量Grill Me 接住的正是开工前的需求对齐。它来自 Matt Pocock 的skills仓库[4]。Matt Pocock 是 Total TypeScript[3]的创办者和主要作者长期做 TypeScript 教学、课程和开发者内容。这个背景很重要。他不是从「怎么写一条更神的 Prompt」出发而是从开发者协作里的老问题出发需求方以为自己说清楚了执行者以为自己听懂了直到成品出来才发现两边理解的根本不是一件事。在skills仓库的官方说明里他把 Agent 最常见的第一类失败直接写成「Agent 没做我想要的东西」给出的修复就是进行一轮 grilling。官方还把/grill-me和/grill-with-docs称为仓库里最受欢迎的 Skills。② 核心规则这个最近很火的 Skill短得有点反常。我重新核对了官方仓库[7]。现在的grill-me本身只是一个很薄的用户入口真正的访谈规则已经拆到grilling[6]里。这套规则没有复杂提示词工程核心只有几件事把方案看成一棵决策树先解决上游决定再进入下游分支一次只问一个问题等待用户回答每个问题附上 Agent 自己的推荐答案代码库和文档里能查到的事实Agent 自己去查属于用户的取舍必须交还给用户双方没有确认形成共同理解之前不得开始行动③ 真正的约束这里最有价值的并不是「多问问题」。普通 Agent 和 Plan 模式本来也会问。真正的约束是不要把事实问题甩给用户也不要替用户偷偷做决定。比如「项目现在用什么框架」读package.json就能知道「这个网站是给招聘者看还是给同类开发者看」文件系统通常替你回答不了。前者应该由 Agent 查询后者才值得停下来问人。这条边界一旦划清访谈就不再像填问卷。它更像设计评审机器负责准备材料人负责暴露偏好并承担取舍。不装整套 Superpowers只拿走最值钱的头脑风暴① 两者的共同点和区别Superpowers 不该被一刀切地否定。严格 TDD、工作树隔离、分阶段审查和多人协作仍然需要它。可如果当前最缺的只是「别急着写先把需求问清楚」整套方法论就有点重了。这正是 Grill Me 可以接住的部分。两者最值钱的共同点都是把头脑风暴放在写代码之前。区别在于 Superpowers 要继续接管后面的开发流程Grill Me 到共同理解形成时就停手。三种方式的对比Plan 模式触发: 复杂任务范围: 实施计划停止: 计划确认Grill Me触发: 开工前范围: 需求追问停止: 共同理解Superpowers触发: 默认加载范围: 全流程停止: 分支收尾② 我的轻量组合这次个人网站我用的是更轻的组合Grill Me 负责头脑风暴和需求追问Codex Plan 模式负责编排实现测试与浏览器负责验收。因此Grill Me 不是 Superpowers 的平替。它只替代了我此刻最需要的那部分把一个已经很会输出的模型暂时按在输入端让它先确认自己究竟应该输出什么。我拿一个个人网站做了次实测① 需求和方法方法论说得再顺如果没有真实任务很容易变成另一篇 Skills 推荐清单。所以我拿正在开发的个人网站做了一次实测。最开始我给 Agent 的需求很短帮我开发个个人网页要有苹果玻璃的感觉展示我的 GitHub 作品集再放一个卡通形象。正常情况下这段话已经足够 Agent 打开 Vite、创建页面然后端出一个「深色背景 三张发光卡片」的标准答案。但我没有让它马上写。我先开了 Grill Me。② 追问过程接下来它一行代码没动开始一题一题追问。我要展示什么项目之间是什么关系首页最重要的动作是什么卡通形象承担品牌识别还是纯装饰动效做到什么程度代码放哪里最终部署到哪。我中间连续回了好几次a因为它每个问题都带了推荐答案合适就直接选。等我说「开始开始」最初那句模糊的「做个网页」已经变成了一组能实现、能验收、也能反悔的决定。网站最终真的上线了。更重要的是我终于搞清楚Grill Me 和 Plan 模式看起来都在「开工前多问几句」但它们处理的不是同一层问题。这一轮追问之后需求确实变丰富了但并没有变成「再加一个登录、再加一个后台」的功能膨胀。多出来的是原来藏在脑子里的判断这不是公司官网而是一个独立 Maker 的作品集视觉参考来自 Motion Sites但不是照抄某个模板主风格是深色液态玻璃中文标题要有编辑感GitHub 是明确入口不是藏在页脚的一行小字卡通形象要成为可识别的 GlassBot而不是随便贴一张头像项目要能放进现有腾讯云服务器同时保留原首页和贪吃蛇页面最终结果要在桌面、平板和手机上都能使用并照顾减少动态效果的系统设置③ 最终结果这些决定落地后项目用了 React 19、TypeScript、Vite 和 Motion页面有 Canvas 液态光带、原创 SVG 机器人和响应式布局。中文标题字体从 1.53MB 子集化到 49,444 bytes首屏静态资源实测约 440KB。如果只看结果很容易把功劳归给模型「审美不错」。但回头看视觉只是交付物的表层。真正决定页面长什么样的是开工前那些看起来有点烦的选择。Plan 也会提问但它更快走向「怎么做」① Plan 模式和 Grill Me 的区别把两者放在一起不是因为 Plan 不好用而是因为它们从相似的入口出发却朝不同的终点前进。Codex 官方最佳实践[8]对 Plan 模式的描述很清楚面对复杂、模糊或难以表达的任务可以先让 Codex 收集上下文、提出澄清问题并形成更强的实施计划。这里的关键词是「实施计划」。在我的使用里一旦 Plan 判断上下文已经足够它就会自然地把问题翻译成文件、步骤、验证方式和风险点。目标明确时这正是它的价值目标里还藏着没有说出口的取舍时它也可能为一个尚未真正决定的方向生成一份技术上很完整的计划。个人网站就是一个例子。Plan 可以安排 React 组件怎么拆、CSS 怎么写、部署怎么验证却无法只靠仓库判断网站究竟给谁看、几个项目是否应该串成故事、苹果玻璃感应该收敛到什么程度。如果这些选择没有先浮出水面后面的执行路线越完整走错方向时返工反而越彻底。Grill Me 补的正是这一段。它不急着把需求翻译成任务而是继续追问哪些是仓库里能查到的事实哪些是只有用户才能承担的取舍双方是否真的形成了同一种理解。因此我这次用下来的区别是Grill Me 的最小单位是「决定」Plan 模式的最小单位是「动作」。前者关心的是我们究竟在做什么哪条路不走谁来承担这个取舍。它的停止条件是双方确认已经形成共同理解。Plan 模式关心的是基于当前目标需要查看哪些文件按什么顺序改怎么验证哪里可能失败。它的产物是一条可执行路线。② 我的分工方式因此我更愿意把它们串起来而不是二选一想法有骨架但还有隐含取舍时先用 Grill Me决策稳定后用 Plan 模式组织实施、验证和回滚进入执行后让测试、浏览器和用户验收说话小任务不需要把链路拉满。改一个错别字、调整现成文案、修复已经定位清楚的 CSS直接做往往更合算。流程的重量应该匹配「做错了有多贵」而不是匹配今天安装了多少 Skill。它没有让我一次做对这反而是实测里最重要的部分① 方向性返工 vs 实现性错误如果文章写到这里就收尾Grill Me 会显得像一颗需求澄清仙丹。真实过程没有这么整齐。② 具体翻车案例网站第一版曾经把几个项目强行串成一条故事线。我看完直接指出各个项目独立没有故事性。后来页面才改成一个主展和三个彼此独立的展柜。这说明访谈虽然问得深但没进入问题树的分支仍然会漏掉。Agent 只会沿着它识别到的树往下走不会自动拥有你的全部审美和项目历史。上线后还有一次更具体的翻车在 2048×1024 的宽屏上cairn 项目的三块玻璃石被展台左边界裁掉了。最终定位是 Motion 写入的内联transform覆盖了 CSS 的水平居中。修复后我们重新验证了 2048×1024、1440×1000、390×844 三档视口并检查动画开始、中段和结束共 9 个状态。这个问题不是再追问十轮就能提前消失的。它需要真实浏览器、真实尺寸和回归检查。所以我的结论不是「用了 Grill Me 就不返工」而是方向性返工交给 Grill Me 减少实现性错误交给测试和验收发现。两件事不能互相代替。连续回答 a是效率也是风险① 推荐答案的好处它要求每个问题给推荐答案这一点非常适合我这种不想从空白选项开始的人。大多数时候我只需要同意、否决或补一句限制。② 锚定效应的风险但推荐答案也会制造锚定。当 Agent 给出的 A 看起来已经「挺合理」人很容易连续点头把访谈用成高级版默认配置。我这次连续回复多个a确实节省了时间首版项目关系被处理错也提醒我回答得快不等于决定已经被认真检查。③ 我会在哪里故意慢下来我现在会在三个地方故意慢下来涉及产品定位时先用自己的话复述一遍涉及不可逆架构或公开接口时要求再给一个反方案涉及视觉感受时不在文字里硬选先让 Agent 做原型再回来判断这也是第一篇参考文章里很有价值的一点有些问题适合低保真对话有些问题必须看到真实界面。Grill Me 可以把问题暴露出来但不能替你的眼睛完成选择。Superpowers 不必默认装Grill Me 也不会永远有效① Skill 的保鲜期另一篇我参考的测评提出了一个我很认同的疑问当 Agent 已经默认会给推荐答案、会在 Plan 模式里澄清需求这种 Skill 还有多久的保鲜期我的判断是某条提示词会过时但行为契约不一定过时。「给出推荐答案」可能已经成为强模型的默认习惯「一次只问一个」「事实自己查」「没有确认就不行动」却是在模型很兴奋、任务很赶、上下文很乱时仍然有用的护栏。② 怎么判断一个 Skill 还有没有必要判断一个 Skill 是否还有必要不要看它有多火也不要只看仓库 Star。直接做一个小实验同一个任务一次使用默认模式一次加 Grill Me比较它是否真的暴露了更多关键决定是否减少了方向性返工以及前置访谈的时间是否值得。如果默认 Agent 已经稳定做到这些删掉 Skill 也没问题。Skill 是工作方法的载体不是需要供起来的软件收藏品。我会在什么任务上继续用① 继续用的三类任务我会继续在三类任务前使用 Grill Me一句话里藏着多种合理结果例如作品集、后台、工作流和新产品早期方向偏一点后面会放大很多例如架构、数据模型、跨端协议最终好坏依赖个人偏好Agent 无法从仓库里自行查到答案② 不会用的场景我不会在目标、改法和验收都已经确定的小修复上使用它。那时继续追问只是在把开发时间变成一场礼貌而漫长的会议。③ 最终理解这也正是我对「Superpowers 太重」的最终理解不是它在所有任务里都太重而是默认加载整套流程对某些强模型和小任务可能太重。复杂协作、严格 TDD 和分阶段审查仍然适合 Superpowers方向含糊但执行能力已经足够时Grill Me 更像一把轻量的前置筛子目标和改法都已确定时直接做反而最合算。这次个人网站让我得到的不是一套万能流程而是一条更实用的分工先用 Grill Me 把「我大概想要什么」逼成决定再用 Plan 模式把决定排成路线并由测试证明路线真的走通。Agent 写代码越来越快以后人最容易犯的错不是不会描述按钮颜色而是还没决定方向就被一个看起来很完整的结果说服了。偶尔先别让它写。让它问到你真的愿意为答案负责再开工。很多时候大模型并不缺继续输出的能力它缺的是一份值得继续输出的输入。写在最后这篇文章不是在推荐「用 Grill Me 替代 Superpowers」。Superpowers 的完整链路在复杂协作和严格工程场景下仍然有价值。但在强模型已经具备原生规划能力的今天默认加载整套流程对某些任务来说确实太重了。Grill Me 的价值不在于它有多聪明而在于它划清了一条边界事实问题 Agent 自己查取舍问题交还给人双方确认形成共同理解后再开工。这条边界不一定永远有效。模型会继续进化今天需要 Skill 来约束的行为明天可能成为模型的默认习惯。但「在开工前先把决定逼出来」这个思路不会因为模型变强就自动消失。参考资料Total TypeScriptMatt Pocock 的 TypeScript 教学项目[3]Matt Pocockskills 仓库说明[4]Superpowers完整 Agent 软件开发方法论[1]Superpowersbrainstorming Skill 源文件[2]Superpowers2026 年发布记录与上下文隔离改进[5]Matt Pocockgrilling Skill 源文件[6]Matt Pocockgrill-me Skill 入口[7]Codex 官方最佳实践Plan first for difficult tasks[8]被 Grill-Me 追问到崩溃可能是你用错了如何看待 grill-me拷问我这个 SkillSuperpowers 太重了日常开发更建议试试 grill-meGrill Me Skill 深度测评让 Agent 先思考再 coding引用链接[1]Superpowers: https://github.com/obra/superpowers[2]brainstorming: https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md[3]Total TypeScript: https://www.totaltypescript.com/[4]skills 仓库的官方说明: https://github.com/mattpocock/skills/blob/main/README.md[5]Superpowers 2026 年发布记录: https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md[6]Matt Pocock grilling Skill: https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md[7]Matt Pocock grill-me Skill: https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md[8]Codex 官方最佳实践: https://learn.chatgpt.com/guides/best-practices.md
Superpowers 太重之后这个只有几行的 Grill Me 火了过去一段时间只要搜索 Coding Agent SkillsSuperpowers 几乎绕不过去。它把头脑风暴、工作树、计划、TDD、代码审查和分支收尾串成一条完整开发链给容易拿到需求就开写的 Agent 装上一整套工程纪律。但强模型正在让这套「全家桶」遇到一个新问题模型本身已经会规划、会选择 Skill、会执行外部流程再从头接管一次增量可能变小摩擦反而变大。我在这次实测前后正好看到一位 GPT-5.6 Sol 用户主动删除 Superpowers。他给出的理由不是它做得差而是新模型本身已经很 agentic再叠重流程可能带来误调用、上下文污染、Token 增加甚至两套流程互相卡住。这条帖子不是「Superpowers 已死」的证据。Superpowers 官方仍然支持 Codex也在持续更新。它真正暴露的是一个更值得实测的问题当整套 Superpowers 对当前任务显得太重能不能只留下最值钱的头脑风暴同一时期一个只有几行核心规则的 Grill Me 开始被反复讨论。它不接管 TDD、代码审查和分支收尾只在开工前不停追问直到 Agent 与用户形成共同理解。我拿一个真实个人网站试了一遍想看清楚三件事Grill Me 到底从 Superpowers 里保留了什么、它和 Codex Plan 模式为什么不是一回事以及这层轻量约束能不能真的减少方向性返工。标题里写「太重」必须先把适用范围说清楚Superpowers 不是设计失败恰恰是因为它把开发过程管得足够完整才会成为过去 Skills 推荐里的常客。Superpowers 不是设计失败而是管得太完整① Superpowers 是什么Superpowers[1]是 Jesse Vincent 和 Prime Radiant 团队维护的一套 Agent 软件开发方法论。它不是单独一个提示词而是一条完整链路头脑风暴、创建工作树、编写计划、子 Agent 执行、测试驱动开发、代码审查并完成分支收尾。早期 Coding Agent 最常见的问题是拿到一句需求就开写。Superpowers 的办法是给每个阶段加硬门槛没想清楚不能实现没写计划不能执行没跑验证不能宣布完成。模型能力还不够稳定时这种外部流程能把一次「凭感觉写代码」变成更可控的软件工程。② brainstorming 是最值钱的那块其中最重要的一块就是brainstorming[2]。它要求 Agent 先查看项目再一次只问一个问题随后给出 2—3 种方案和取舍分段展示设计得到用户批准保存设计文档获批后只能进入writing-plans。这也是为什么过去推荐 Skills 的文章经常绕不开 Superpowers它不是替模型补一个零散能力而是给不稳定的模型装上一整套纪律。复杂开发、多人协作、严格 TDD 和分阶段审查今天依然能从这套纪律里受益。③ 我自己的用法我自己的做法更极端一些。在 agentcoding 的工作流里Superpowers 我只用一样东西头脑风暴。实现、测试、审查 、归档 spec 文档这些流程全部交给 openspec 处理。这么做的原因是头脑风暴那一步确实能把需求从「我大概想要什么」逼成一组可以执行的决定这一步的增量很明显。但后面的 TDD、代码审查、分支收尾强模型配合 openspec 已经能处理得很好再叠一套 Superpowers 的流程摩擦大于收益。它为什么会在强模型上显得重① 默认加载整套流程的问题问题出在「默认加载整套流程」而不是某个 Skill 本身做得差。当模型已经具备较强的原生规划、工具选择和执行能力时Superpowers 的控制层可能与模型自己的控制层发生重叠原生 Plan 模式想先规划Superpowers 的brainstorming又要求先走自己的设计审批模型会自行选择 Skillusing-superpowers又要求每个任务先检查完整技能链小任务本来可以直接完成却也可能被头脑风暴、设计文档、计划和审查层层接管多套规则同时争夺下一步动作时原本为了防止模型乱跑的护栏也可能变成新的岔路口② 重叠带来的摩擦这种重叠不一定每次都会出问题但它会增加思考时间、上下文占用和流程摩擦。任务越小、模型越主动整套方法论的相对重量就越明显。这里必须补一条边界截至我核对时Superpowers 官方仍然支持 Codex而且还在持续更新。它的 2026 年发布记录甚至专门加入了子 Agent 上下文隔离用来减少上下文污染[5]。所以「GPT-5.6 不再推荐 Superpowers」不是官方结论更准确的说法是对于已经具备强规划和执行能力的模型不一定还要默认加载整套 Superpowers。重不等于无用它意味着流程的控制范围可能超过了当前任务真正需要的范围。这个只有几行的 Grill Me接住了什么① 来源和背景真正值得关注的不是把 Superpowers 从工具箱里扔掉而是问整套方法论里哪一段对强模型仍然有明确增量Grill Me 接住的正是开工前的需求对齐。它来自 Matt Pocock 的skills仓库[4]。Matt Pocock 是 Total TypeScript[3]的创办者和主要作者长期做 TypeScript 教学、课程和开发者内容。这个背景很重要。他不是从「怎么写一条更神的 Prompt」出发而是从开发者协作里的老问题出发需求方以为自己说清楚了执行者以为自己听懂了直到成品出来才发现两边理解的根本不是一件事。在skills仓库的官方说明里他把 Agent 最常见的第一类失败直接写成「Agent 没做我想要的东西」给出的修复就是进行一轮 grilling。官方还把/grill-me和/grill-with-docs称为仓库里最受欢迎的 Skills。② 核心规则这个最近很火的 Skill短得有点反常。我重新核对了官方仓库[7]。现在的grill-me本身只是一个很薄的用户入口真正的访谈规则已经拆到grilling[6]里。这套规则没有复杂提示词工程核心只有几件事把方案看成一棵决策树先解决上游决定再进入下游分支一次只问一个问题等待用户回答每个问题附上 Agent 自己的推荐答案代码库和文档里能查到的事实Agent 自己去查属于用户的取舍必须交还给用户双方没有确认形成共同理解之前不得开始行动③ 真正的约束这里最有价值的并不是「多问问题」。普通 Agent 和 Plan 模式本来也会问。真正的约束是不要把事实问题甩给用户也不要替用户偷偷做决定。比如「项目现在用什么框架」读package.json就能知道「这个网站是给招聘者看还是给同类开发者看」文件系统通常替你回答不了。前者应该由 Agent 查询后者才值得停下来问人。这条边界一旦划清访谈就不再像填问卷。它更像设计评审机器负责准备材料人负责暴露偏好并承担取舍。不装整套 Superpowers只拿走最值钱的头脑风暴① 两者的共同点和区别Superpowers 不该被一刀切地否定。严格 TDD、工作树隔离、分阶段审查和多人协作仍然需要它。可如果当前最缺的只是「别急着写先把需求问清楚」整套方法论就有点重了。这正是 Grill Me 可以接住的部分。两者最值钱的共同点都是把头脑风暴放在写代码之前。区别在于 Superpowers 要继续接管后面的开发流程Grill Me 到共同理解形成时就停手。三种方式的对比Plan 模式触发: 复杂任务范围: 实施计划停止: 计划确认Grill Me触发: 开工前范围: 需求追问停止: 共同理解Superpowers触发: 默认加载范围: 全流程停止: 分支收尾② 我的轻量组合这次个人网站我用的是更轻的组合Grill Me 负责头脑风暴和需求追问Codex Plan 模式负责编排实现测试与浏览器负责验收。因此Grill Me 不是 Superpowers 的平替。它只替代了我此刻最需要的那部分把一个已经很会输出的模型暂时按在输入端让它先确认自己究竟应该输出什么。我拿一个个人网站做了次实测① 需求和方法方法论说得再顺如果没有真实任务很容易变成另一篇 Skills 推荐清单。所以我拿正在开发的个人网站做了一次实测。最开始我给 Agent 的需求很短帮我开发个个人网页要有苹果玻璃的感觉展示我的 GitHub 作品集再放一个卡通形象。正常情况下这段话已经足够 Agent 打开 Vite、创建页面然后端出一个「深色背景 三张发光卡片」的标准答案。但我没有让它马上写。我先开了 Grill Me。② 追问过程接下来它一行代码没动开始一题一题追问。我要展示什么项目之间是什么关系首页最重要的动作是什么卡通形象承担品牌识别还是纯装饰动效做到什么程度代码放哪里最终部署到哪。我中间连续回了好几次a因为它每个问题都带了推荐答案合适就直接选。等我说「开始开始」最初那句模糊的「做个网页」已经变成了一组能实现、能验收、也能反悔的决定。网站最终真的上线了。更重要的是我终于搞清楚Grill Me 和 Plan 模式看起来都在「开工前多问几句」但它们处理的不是同一层问题。这一轮追问之后需求确实变丰富了但并没有变成「再加一个登录、再加一个后台」的功能膨胀。多出来的是原来藏在脑子里的判断这不是公司官网而是一个独立 Maker 的作品集视觉参考来自 Motion Sites但不是照抄某个模板主风格是深色液态玻璃中文标题要有编辑感GitHub 是明确入口不是藏在页脚的一行小字卡通形象要成为可识别的 GlassBot而不是随便贴一张头像项目要能放进现有腾讯云服务器同时保留原首页和贪吃蛇页面最终结果要在桌面、平板和手机上都能使用并照顾减少动态效果的系统设置③ 最终结果这些决定落地后项目用了 React 19、TypeScript、Vite 和 Motion页面有 Canvas 液态光带、原创 SVG 机器人和响应式布局。中文标题字体从 1.53MB 子集化到 49,444 bytes首屏静态资源实测约 440KB。如果只看结果很容易把功劳归给模型「审美不错」。但回头看视觉只是交付物的表层。真正决定页面长什么样的是开工前那些看起来有点烦的选择。Plan 也会提问但它更快走向「怎么做」① Plan 模式和 Grill Me 的区别把两者放在一起不是因为 Plan 不好用而是因为它们从相似的入口出发却朝不同的终点前进。Codex 官方最佳实践[8]对 Plan 模式的描述很清楚面对复杂、模糊或难以表达的任务可以先让 Codex 收集上下文、提出澄清问题并形成更强的实施计划。这里的关键词是「实施计划」。在我的使用里一旦 Plan 判断上下文已经足够它就会自然地把问题翻译成文件、步骤、验证方式和风险点。目标明确时这正是它的价值目标里还藏着没有说出口的取舍时它也可能为一个尚未真正决定的方向生成一份技术上很完整的计划。个人网站就是一个例子。Plan 可以安排 React 组件怎么拆、CSS 怎么写、部署怎么验证却无法只靠仓库判断网站究竟给谁看、几个项目是否应该串成故事、苹果玻璃感应该收敛到什么程度。如果这些选择没有先浮出水面后面的执行路线越完整走错方向时返工反而越彻底。Grill Me 补的正是这一段。它不急着把需求翻译成任务而是继续追问哪些是仓库里能查到的事实哪些是只有用户才能承担的取舍双方是否真的形成了同一种理解。因此我这次用下来的区别是Grill Me 的最小单位是「决定」Plan 模式的最小单位是「动作」。前者关心的是我们究竟在做什么哪条路不走谁来承担这个取舍。它的停止条件是双方确认已经形成共同理解。Plan 模式关心的是基于当前目标需要查看哪些文件按什么顺序改怎么验证哪里可能失败。它的产物是一条可执行路线。② 我的分工方式因此我更愿意把它们串起来而不是二选一想法有骨架但还有隐含取舍时先用 Grill Me决策稳定后用 Plan 模式组织实施、验证和回滚进入执行后让测试、浏览器和用户验收说话小任务不需要把链路拉满。改一个错别字、调整现成文案、修复已经定位清楚的 CSS直接做往往更合算。流程的重量应该匹配「做错了有多贵」而不是匹配今天安装了多少 Skill。它没有让我一次做对这反而是实测里最重要的部分① 方向性返工 vs 实现性错误如果文章写到这里就收尾Grill Me 会显得像一颗需求澄清仙丹。真实过程没有这么整齐。② 具体翻车案例网站第一版曾经把几个项目强行串成一条故事线。我看完直接指出各个项目独立没有故事性。后来页面才改成一个主展和三个彼此独立的展柜。这说明访谈虽然问得深但没进入问题树的分支仍然会漏掉。Agent 只会沿着它识别到的树往下走不会自动拥有你的全部审美和项目历史。上线后还有一次更具体的翻车在 2048×1024 的宽屏上cairn 项目的三块玻璃石被展台左边界裁掉了。最终定位是 Motion 写入的内联transform覆盖了 CSS 的水平居中。修复后我们重新验证了 2048×1024、1440×1000、390×844 三档视口并检查动画开始、中段和结束共 9 个状态。这个问题不是再追问十轮就能提前消失的。它需要真实浏览器、真实尺寸和回归检查。所以我的结论不是「用了 Grill Me 就不返工」而是方向性返工交给 Grill Me 减少实现性错误交给测试和验收发现。两件事不能互相代替。连续回答 a是效率也是风险① 推荐答案的好处它要求每个问题给推荐答案这一点非常适合我这种不想从空白选项开始的人。大多数时候我只需要同意、否决或补一句限制。② 锚定效应的风险但推荐答案也会制造锚定。当 Agent 给出的 A 看起来已经「挺合理」人很容易连续点头把访谈用成高级版默认配置。我这次连续回复多个a确实节省了时间首版项目关系被处理错也提醒我回答得快不等于决定已经被认真检查。③ 我会在哪里故意慢下来我现在会在三个地方故意慢下来涉及产品定位时先用自己的话复述一遍涉及不可逆架构或公开接口时要求再给一个反方案涉及视觉感受时不在文字里硬选先让 Agent 做原型再回来判断这也是第一篇参考文章里很有价值的一点有些问题适合低保真对话有些问题必须看到真实界面。Grill Me 可以把问题暴露出来但不能替你的眼睛完成选择。Superpowers 不必默认装Grill Me 也不会永远有效① Skill 的保鲜期另一篇我参考的测评提出了一个我很认同的疑问当 Agent 已经默认会给推荐答案、会在 Plan 模式里澄清需求这种 Skill 还有多久的保鲜期我的判断是某条提示词会过时但行为契约不一定过时。「给出推荐答案」可能已经成为强模型的默认习惯「一次只问一个」「事实自己查」「没有确认就不行动」却是在模型很兴奋、任务很赶、上下文很乱时仍然有用的护栏。② 怎么判断一个 Skill 还有没有必要判断一个 Skill 是否还有必要不要看它有多火也不要只看仓库 Star。直接做一个小实验同一个任务一次使用默认模式一次加 Grill Me比较它是否真的暴露了更多关键决定是否减少了方向性返工以及前置访谈的时间是否值得。如果默认 Agent 已经稳定做到这些删掉 Skill 也没问题。Skill 是工作方法的载体不是需要供起来的软件收藏品。我会在什么任务上继续用① 继续用的三类任务我会继续在三类任务前使用 Grill Me一句话里藏着多种合理结果例如作品集、后台、工作流和新产品早期方向偏一点后面会放大很多例如架构、数据模型、跨端协议最终好坏依赖个人偏好Agent 无法从仓库里自行查到答案② 不会用的场景我不会在目标、改法和验收都已经确定的小修复上使用它。那时继续追问只是在把开发时间变成一场礼貌而漫长的会议。③ 最终理解这也正是我对「Superpowers 太重」的最终理解不是它在所有任务里都太重而是默认加载整套流程对某些强模型和小任务可能太重。复杂协作、严格 TDD 和分阶段审查仍然适合 Superpowers方向含糊但执行能力已经足够时Grill Me 更像一把轻量的前置筛子目标和改法都已确定时直接做反而最合算。这次个人网站让我得到的不是一套万能流程而是一条更实用的分工先用 Grill Me 把「我大概想要什么」逼成决定再用 Plan 模式把决定排成路线并由测试证明路线真的走通。Agent 写代码越来越快以后人最容易犯的错不是不会描述按钮颜色而是还没决定方向就被一个看起来很完整的结果说服了。偶尔先别让它写。让它问到你真的愿意为答案负责再开工。很多时候大模型并不缺继续输出的能力它缺的是一份值得继续输出的输入。写在最后这篇文章不是在推荐「用 Grill Me 替代 Superpowers」。Superpowers 的完整链路在复杂协作和严格工程场景下仍然有价值。但在强模型已经具备原生规划能力的今天默认加载整套流程对某些任务来说确实太重了。Grill Me 的价值不在于它有多聪明而在于它划清了一条边界事实问题 Agent 自己查取舍问题交还给人双方确认形成共同理解后再开工。这条边界不一定永远有效。模型会继续进化今天需要 Skill 来约束的行为明天可能成为模型的默认习惯。但「在开工前先把决定逼出来」这个思路不会因为模型变强就自动消失。参考资料Total TypeScriptMatt Pocock 的 TypeScript 教学项目[3]Matt Pocockskills 仓库说明[4]Superpowers完整 Agent 软件开发方法论[1]Superpowersbrainstorming Skill 源文件[2]Superpowers2026 年发布记录与上下文隔离改进[5]Matt Pocockgrilling Skill 源文件[6]Matt Pocockgrill-me Skill 入口[7]Codex 官方最佳实践Plan first for difficult tasks[8]被 Grill-Me 追问到崩溃可能是你用错了如何看待 grill-me拷问我这个 SkillSuperpowers 太重了日常开发更建议试试 grill-meGrill Me Skill 深度测评让 Agent 先思考再 coding引用链接[1]Superpowers: https://github.com/obra/superpowers[2]brainstorming: https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md[3]Total TypeScript: https://www.totaltypescript.com/[4]skills 仓库的官方说明: https://github.com/mattpocock/skills/blob/main/README.md[5]Superpowers 2026 年发布记录: https://github.com/obra/superpowers/blob/main/RELEASE-NOTES.md[6]Matt Pocock grilling Skill: https://github.com/mattpocock/skills/blob/main/skills/productivity/grilling/SKILL.md[7]Matt Pocock grill-me Skill: https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md[8]Codex 官方最佳实践: https://learn.chatgpt.com/guides/best-practices.md
