企业官网建设流程全解析

Superpowers 太重之后，这个只有几行的 Grill Me 火了

过去一段时间，只要搜索 Coding Agent Skills，Superpowers 几乎绕不过去。它把头脑风暴、工作树、计划、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又要求先走自己的设计审批
• 模型会自行选择 Skill，using-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 到共同理解形成时就停手。

三种方式的对比：

② 我的轻量组合

这次个人网站，我用的是更轻的组合：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 模式关心的是：基于当前目标，需要查看哪些文件，按什么顺序改，怎么验证，哪里可能失败。它的产物是一条可执行路线。

② 我的分工方式

因此我更愿意把它们串起来，而不是二选一：

1. 想法有骨架但还有隐含取舍时，先用 Grill Me
2. 决策稳定后，用 Plan 模式组织实施、验证和回滚
3. 进入执行后，让测试、浏览器和用户验收说话

小任务不需要把链路拉满。改一个错别字、调整现成文案、修复已经定位清楚的 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 TypeScript：Matt Pocock 的 TypeScript 教学项目^[3]
• Matt Pocock：skills 仓库说明^[4]
• Superpowers：完整 Agent 软件开发方法论^[1]
• Superpowers：brainstorming Skill 源文件^[2]
• Superpowers：2026 年发布记录与上下文隔离改进^[5]
• Matt Pocock：grilling Skill 源文件^[6]
• Matt Pocock：grill-me Skill 入口^[7]
• Codex 官方最佳实践：Plan first for difficult tasks^[8]
• 被 Grill-Me 追问到崩溃？可能是你用错了
• 如何看待 grill-me（拷问我）这个 Skill？
• Superpowers 太重了？日常开发更建议试试 grill-me
• Grill 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