Superpowers - 08 在 AI 时代重写「需求评审会」：深入解读 Superpowers 的头脑风暴与设计规范机制

文章目录

Pre
一、主题与读者：这是给谁看的、解决什么问题？
二、整体结构：从理念到落地的完整链路
三、硬性门槛：无设计不实现
[四、九步检查清单：把「需求 → 设计 → 规格」拆成可执行步骤](#四、九步检查清单：把「需求 → 设计 → 规格」拆成可执行步骤)
五、端到端流程：两个关键反馈循环
[六、对话策略：把「对 AI 说」变成一种可控的工程活动](#六、对话策略：把「对 AI 说」变成一种可控的工程活动)
- [1. 每次只问一个问题](#1. 每次只问一个问题)
- [2. 先判断是否需要拆解](#2. 先判断是否需要拆解)
- [3. 方案探索与推荐](#3. 方案探索与推荐)
- [4. 设计的增量展示](#4. 设计的增量展示)
七、隔离与清晰度：设计的是「可推理的系统」
八、规格文档与自检：让「设计」真正进入代码库
- [自检协议：AI 给自己做的 Code Review（针对规格）](#自检协议：AI 给自己做的 Code Review（针对规格）)
- 用户审查门槛
九、视觉伴侣：在浏览器里进行「可视化头脑风暴」
- [1. 提供与激活协议](#1. 提供与激活协议)
- [2. 零依赖 Node.js 架构](#2. 零依赖 Node.js 架构)
- [3. 交互循环与用户体验](#3. 交互循环与用户体验)
- [4. CSS 组件库：为头脑风暴专门设计的 UI 语汇](#4. CSS 组件库：为头脑风暴专门设计的 UI 语汇)
- [5. 生命周期与多平台兼容](#5. 生命周期与多平台兼容)
[十、规格文档审查员：给规格再上一道「AI 审核」](#十、规格文档审查员：给规格再上一道「AI 审核」)
十一、六大核心原则：浓缩的工程协作指南
十二、如何在你的工程实践中落地类似机制？
[十三、结语：AI 不只是「更快的键盘」，而是「新的流程参与者」](#十三、结语：AI 不只是「更快的键盘」，而是「新的流程参与者」)

Pre

Superpowers - 01 让 AI 真正"懂工程"：Superpowers 软件开发工作流深度解析

Superpowers - 02 用 15 个技能给你的 AI 装上「工程大脑」：Superpowers 快速开始深度解析

Superpowers - 03 一文搞懂 Superpowers：面向多平台 AI 编码助手的安装与实践指南

Superpowers - 04 从"会写代码"到"会做工程"：Superpowers 工作流引擎架构深度剖析

Superpowers - 05 构建一个"会自己找插件用"的 Agent：深入解析 Superpowers 的技能发现与激活机制

Superpowers - 06 从文档到"结构契约"：Superpowers 技能剖析与 Frontmatter 深度解读

Superpowers - 07 从 SessionStart Hook 看 Superpowers：把「技能库」变成「行为操作系统」

在大模型辅助开发的时代，「如何写代码」已经不再是唯一关键问题，「在写任何一行代码之前怎么思考和设计」变得前所未有重要。

obra Superpowers 提出的「头脑风暴与设计规范」技能，本质上是在给「AI 参与的软件设计阶段」制定一套严格却实用的工程流程。它既约束模型，也保护开发者，把传统软件工程里的需求澄清、方案权衡和设计评审，系统化地搬到了 AI 协作工作流中。

一、主题与读者：这是给谁看的、解决什么问题？

面向三类读者：

日常用 Claude / ChatGPT / 各类代码助手写代码的工程师
想设计自己「Agent 工作流」的架构师与研究者
想用 AI 做严肃工程而不是玩具 Demo 的技术负责人

你可能已经遇到过这些典型痛点：

让模型「直接写代码」，结果越改越乱、返工次数惊人
需求说得也不算少，但最后落地的功能总跟预期有偏差
小变更感觉「简单到不需要设计」，结果最后花的时间比一个完整功能还多

Superpowers 的头脑风暴技能针对的就是这些问题：通过一套硬性门槛和可执行清单，强制 AI 在进入「实现阶段」前完成足够严谨的思考和沉淀。

二、整体结构：从理念到落地的完整链路

这个技能可以拆解为几大部分：

一个硬性原则：无设计不实现
一份必须按顺序执行的九步检查清单
一个带反馈循环的端到端流程图
面向对话的交互方法与拆解策略
一套强调「隔离与清晰度」的设计原则
规范化的规格文档、自检与审查流程
一个零依赖 Node.js 构建的视觉伴侣系统
专门的规格文档审查子 Agent
六条高度精炼的核心原则
与后续计划编写、子 Agent 开发的衔接方式

下面我们按工程实践视角，从理念到管线，把这套体系拆开讲透，并结合你在日常用大模型写代码时可以直接落地的做法。

三、硬性门槛：无设计不实现

在 Superpowers 中，每一次「头脑风暴」都被一个不妥协的规则约束：在展示设计并获得用户明确批准之前，AI 不得调用任何实现技能、不得写任何代码、不得初始化任何脚手架。

这有几点值得开发者特别注意：

适用范围极广：
不只是新项目，哪怕只是「修改单个配置值」「写一个小工具函数」，理论上也必须有一个与规模匹配的设计过程。
设计可以短，但不能缺席：
对于非常小的改动，可能只需要几句话说明意图、影响范围和边界条件，但这几句话必须被当作「设计」，并且要经过确认。
这是纪律的边界：
它人为拉开了「思考」与「编码」之间的时间，避免在模糊的前提下直接动手，从而把代价最高的错误卡在最前面。

如果你在自己的团队里引入类似实践，一条简单规则就够了：

在任何模型生成代码之前，必须先有一份被人看过并点头的设计描述，哪怕只有三个段落。

四、九步检查清单：把「需求 → 设计 → 规格」拆成可执行步骤

头脑风暴技能定义了一份九步检查清单，并要求严格按顺序完成，目的是防止对话乱跳、上下文丢失。

表：九步检查清单概览（已简化）

步骤	任务	说明
1	探索项目上下文	看代码、文档、近期提交，搞清当前状态
2	提供视觉伴侣	若预见有 UI/视觉问题，用浏览器伴侣辅助
3	提出澄清问题	每次只问一个，聚焦目的、约束和成功标准
4	提出 2--3 种方案	附权衡和推荐，允许用户选择或否决
5	展示设计	分块增量展示，每块后都要确认
6	编写设计文档	落到 `docs/superpowers/specs/YYYY-MM-DD--design.md`
7	规格自检	扫占位符、矛盾、范围失衡和歧义
8	用户审查书面规格	人审规格文件，有修改则循环
9	过渡到实现（写计划）	调用 `writing-plans` 技能，禁止直接跳到写代码

对开发实践的启示：

不要跳过上下文探索 ：

先读现有代码、最近的 PR 和文档，避免「凭空设计一个已经存在的轮子」，同时把变更约束在必要范围。
澄清问题要细而单点 ：

每次只问一个关键问题，并尽量设计成带选项的问题，让对方更容易响应，也方便大模型基于结构化回答调整后续方案。
方案空间要显式展开 ：

至少列出 2--3 种实现思路，附上复杂度、风险、可扩展性等维度的权衡，再给出推荐，而不是直接给唯一「解法」。
设计要有「节拍」 ：

不是一上来丢一个大而全的设计文档，而是分层分块展示：从整体架构到关键模块，再到接口和数据结构，每一块都确认「目前看起来对吗」。
一切通向可追踪的规格文档 ：

设计被批准后，必须写进 repo（比如 docs/superpowers/specs/...），并提交到版本控制系统，让后续计划和实现都有明确锚点。

五、端到端流程：两个关键反馈循环

在这份技能说明中，整个头脑风暴过程被抽象为一个有向图，其终态永远是调用 writing-plans 技能，而不是直接写代码。

流程中有两个特别关键的「循环点」：

设计批准循环：

发生在「展示设计」和「编写设计文档」之间。只要用户对设计有异议，就回到设计阶段调整，不进入规格固化。
规格审查循环：

发生在「规格自检」和「过渡到实现」之间。只要规格被发现有范围/一致性/歧义问题，就回到规格编辑，而不是在实现阶段边写边改规格。

这些循环都有两个特点：

没有最大迭代次数限制，只在「用户满意」时结束。
始终维持「先解决上游问题，再进入下游环节」的原则。

如果你在设计自己的 Agent 流程，可以直接把这两个循环当作「状态机」里的两个门槛状态；只有在状态通过时，Agent 才能请求代码执行类工具。

六、对话策略：把「对 AI 说」变成一种可控的工程活动

头脑风暴技能强调的是一种对话式而不是拷问式的交互方式。

1. 每次只问一个问题

Claude 在澄清阶段每次只问一个问题，原因有三：

减轻用户的认知负担
避免用户回答不完整或把多个答案混在一起
便于模型根据单一反馈调整内部假设

对我们日常使用大模型也有启发：如果你发现模型总是「理解偏了」，不妨把原本的一大段需求切成一系列单点问题回答，让它一步步更新对任务的 mental model。

2. 先判断是否需要拆解

对于包含多个子系统的需求（例如「做一个带聊天、存储、计费、分析的 SaaS 平台」），技能要求立刻把它拆成多个子项目，每个子项目走自己的「规格 → 计划 → 实现」周期。

这其实是在防止「在一个对话里设计一个单体大怪物」。对于人和模型来说，这种规模的设计一旦混在一起，很难保持全局一致性。

3. 方案探索与推荐

在需求澄清后，AI 会提出 2--3 种方案，附带权衡和推荐。这里有几个关键点：

推荐方案要排在第一，并给出推荐理由
用户有权明确拒绝推荐方案
AI 必须适应用户反馈，调整偏好

这和传统架构评审类似：你不会只提一个方案，而是会给出至少一个对照选项，用权衡过程本身提升团队对问题的理解。

4. 设计的增量展示

对于简单组件，设计描述可能只需要几句话；对于复杂架构决策，单个部分的描述上限通常在 200--300 字左右，以避免一次输出超出人类和模型的短期记忆容量。

每个部分都以一句「目前看起来对吗？」之类的检查点结束，强制对齐预期再继续，这也可以减少后面「发现根基错了」的推倒重来。

七、隔离与清晰度：设计的是「可推理的系统」

这一节可以看作是这套技能背后的工程哲学：系统应该被拆分成小而清晰的单元，每个单元都满足三个问题可回答：

它做什么（职责）
怎么用它（接口）
它依赖什么（依赖关系）

这样拆分的好处不止是「好看」，而是非常现实的：

更易被模型在有限上下文里理解，减少「误解」和错误编辑
更便于局部测试和重构
避免一个文件或模块同时承载过多职责

对于已有代码库，这个原则还有一个延伸要求：

优先遵循现有模式，只做与当前目标直接相关的改动，避免顺手重构整个世界。

用原文的表达：优秀的开发者改进他们正在处理的代码；糟糕的开发者则把每一次改动都当作重构一切的理由。

在 AI 协作场景下，这条原则尤为重要------你越鼓励模型大范围重构，就越难以验证其改动是否正确，也越容易引入隐含 Bug。

八、规格文档与自检：让「设计」真正进入代码库

当设计获得批准后，下一步不是直接写代码，而是将正式规格写入仓库中的文档文件，比如 docs/superpowers/specs/YYYY-MM-DD--design.md，并提交到 git。

这一步的意义在于：

把说过的话变成可版本化的文档
让后续计划编写、开发和测试都有一个共同的参照
便于未来审计与回溯，理解某个决策是如何形成的

自检协议：AI 给自己做的 Code Review（针对规格）

在向用户展示规格前，Claude 会做一次四点自检：

占位符扫描：消除「TBD」「TODO」和不完整段落
内部一致性：避免章节之间互相矛盾
范围检查：确认规格是否聚焦于单一实现计划
歧义检查：避免可以被两种方式解释的需求

所有问题都要求在文档中直接修复，而不是再走一轮「形式化审查」，目标是高效纠错而不是官僚流程。

用户审查门槛

自检之后，规格必须经过用户显式审查才能继续：

用户可以对某些段落提出修改要求
修改后需要重新进入审查循环
只有在用户明确批准后，才允许进入 writing-plans 阶段继续工作流

这一步相当于把传统「需求评审会」的精神，编码进了 AI 工作流里。

九、视觉伴侣：在浏览器里进行「可视化头脑风暴」

头脑风暴技能还带了一个非常有意思的扩展：一个可选的本地 Web 服务器，专门用于可视化模型、线框图、布局和架构图。

1. 提供与激活协议

这不是一个「随便用用」的附加功能，而是有严格协议的工具：

提供伴侣时必须使用一条单独消息，不能掺杂其他内容
提供文案是写死的，确保用户一眼看懂这是什么
用户必须明确同意，服务器才会被启动

即便如此，是否在某个具体问题上使用浏览器，也需要逐问题判断：

用户通过「看」是否比通过「读」更容易理解这个问题？如果是，就走浏览器；否则留在终端。

例如：

「在这个产品里，个性化意味着什么？」------概念性问题，适合文字讨论
「这两个引导向导的布局哪一个更好？」------视觉问题，适合用浏览器对比

2. 零依赖 Node.js 架构

视觉伴侣的服务器被刻意设计为一个零依赖的 Node.js 应用 ，只使用内置模块（http、crypto、fs、path），目的是消除来自第三方依赖的供应链风险。

核心组成包括：

HTTP 服务器：提供最新的 HTML、静态资源和等待页面
WebSocket 处理器：用纯代码实现 RFC 6455 协议
客户端 Helper：自动注入的脚本，用于点击捕获、选项选择和断线重连
框架模板：内置亮/暗主题和一套专为头脑风暴设计的 CSS 组件库

3. 交互循环与用户体验

整个伴侣的使用被抽象为一个固定循环：

检查服务器是否存活，不在则启动
用「写文件工具」在指定目录创建新的 HTML 屏幕
提醒用户访问对应 URL，并用文字总结屏幕内容
从事件目录读取浏览器交互，与终端文字反馈合并
根据反馈迭代屏幕或进入下一个问题

当对话回到纯文本讨论时，浏览器侧会显示一个简单的「Continuing in terminal...」等待页，避免用户盯着一个已经过期的选择画面发呆。

4. CSS 组件库：为头脑风暴专门设计的 UI 语汇

框架模板自带了一组组件，用于构建 A/B 选项卡片、UI 模型、分屏对比、优缺点列表、线框模块等。

例如：

.options + .option：展示多选项决策
.cards：以卡片形式展示不同设计方案
.split：并排比较两个布局（在窄屏改为上下排列）
.pros-cons：把优缺点视觉化呈现
.mock-nav、.mock-sidebar 等：快速搭建线框骨架

这意味着你可以用非常简单的 HTML 片段，快速构建出足够精细的「交互式设计提案」，让非工程角色也能通过「看图」参与决策。

5. 生命周期与多平台兼容

服务器通过一组 Shell 脚本管理，在不同平台（Claude Code 的 macOS/Linux、Windows、Codex、Gemini CLI、远程容器）上采用不同前后台运行策略，保证既不会被宿主环境随意杀死，也不会常驻不退出。

同时它内置了：

30 分钟空闲自动退出
进程树监控，当宿主进程结束时自动停止服务

这对任何想在本地集成「AI + 可视化协作」工具的开发者都有很高借鉴价值。

十、规格文档审查员：给规格再上一道「AI 审核」

在头脑风暴技能中，还有一个专门的子 Agent：「规格文档审查员」。

它的职责是：

检查规格的完整性、一致性、清晰度、范围，以及是否遵守 YAGNI（你不会需要它）原则
只拦截会在实现阶段造成真实问题的缺陷，刻意不对轻微措辞、风格偏好做「卡审」

审查结果是结构化输出，包括：

状态（批准 / 发现问题）
带章节引用和计划影响的具体问题
不阻断通过的建议性意见

这让整个「规格 → 计划 → 实现」链路在进入计划前有了一次自动化的质量门槛。

你可以类比为：

在写测试之前先对需求文档跑一遍「静态分析」，把明显的坑（范围太大、需求模糊、描述矛盾）先标出来。

十一、六大核心原则：浓缩的工程协作指南

技能最后给出了六条高度提炼的原则，可以当做你与大模型协作时的「行为守则」：

每次只问一个问题：降低认知负担
优先多选题：在可能的情况下用选项替代开放式问题
无情践行 YAGNI：从设计中删掉所有「也许以后会用到」的东西
总是探索备选方案：至少 2--3 种方案再做决策
增量验证：每一部分设计都要在继续前获得确认
保持灵活：当感觉哪里不合理时，允许回退和修正

同时，老的 commands/brainstorm.md 已被废弃，统一改为使用 superpowers:brainstorming 技能，这也是整个体系从「命令式接口」转向「技能系统」的一部分。

十二、如何在你的工程实践中落地类似机制？

结合上面这些内容，我们可以为「开发者 + 大模型」的日常工作提炼出一套可操作的实践清单：

建立「无设计不实现」的团队共识
- 任何模型生成的代码，都应该有对应的文字设计说明（哪怕很短）。
把「九步检查清单」改写成自己的工作流模板
- 用 Issue 模板或 PR 模板，强制包含：上下文、澄清问题、方案对比、设计草案、规格链接等。
规范规格文档的存放与命名
- 在仓库中专门划出 docs/specs/ 或类似目录，用日期 + 主题命名。
引入简单的自检规则
- 无「TODO / TBD」
- 无互相矛盾的描述
- 每份规格只对应一个实现计划（不要在一份文档里定义三件大事）。
尝试打造自己的「视觉伴侣」
- 不一定要完全复刻零依赖服务器，但至少可以用简单的 Web 页面 + 浏览器展示，帮助团队用视觉方式讨论 UI/流程/架构。
利用模型做规格审查，而不是只做代码审查
- 先让模型帮你 review 规格文档，再用它辅助写实现计划和代码，这样错误更容易拦截在上游。

十三、结语：AI 不只是「更快的键盘」，而是「新的流程参与者」

「头脑风暴与设计规范」这套技能并不是在教模型怎么写更好的代码，而是在教我们如何把大模型变成一个受约束、可协作的工程参与者。

它把传统软件工程中那些容易被忽略、又极其关键的环节------需求澄清、方案比较、设计沉淀、规格审查、可视化讨论------用流程化、工具化的方式封装起来，让 AI 能在其中扮演稳定角色，而不是随心所欲的「代码生成器」。

如果你希望你的项目不被「一键生成代码」带偏，而是用 AI 把工程实践拉到一个更高的层次，这套机制非常值得深入阅读、实践和本地化改造。你完全可以从今天开始，给自己的 AI 助手加上一条约束：

在我明确说「设计通过」之前，你不能写任何一行代码。

这将是你和 AI 真正「共同做工程」的起点，而不是简单的人机分工。