头脑风暴与设计
在写任何代码之前，先理解你要构建的内容。
硬性关卡规则
这是 Superpowers 中最重要的单一规则：
在用户批准设计之前，不得写任何实现代码。
这不是建议。这是一个硬性关卡。当你开始任何创造性工作——新功能、新组件、新行为——时，必须首先完成头脑风暴会话。没有例外。
为什么需要头脑风暴
从事编程工作的人知道一个痛苦的规律：越早触及代码，问题发现得越晚。
如果你在理解需求之前开始实现，你会：
- 构建错误的东西（然后扔掉）
- 构建对的东西但方式错误（然后重构）
- 在代码结构上做出影响一切的决策，而你甚至没有意识到自己在做决策
头脑风暴会话在没有任何人编写一行代码的情况下，将这些决策明确化。
7 步头脑风暴流程
第 1 步：问题陈述
AI 用自己的话重述问题。这一步验证理解正确——发现误解的时机是在代码编写之前，而不是之后。
问题陈述：用户需要一种 [X] 的方式，以便 [Y]。
关键约束：[Z]。
第 2 步：一次一个澄清问题
AI 每次提一个问题。不是一次列出七个问题的清单。就一个问题。
为什么是一次一个？
因为答案往往会影响后续问题。如果你先问"这需要支持哪些用户角色？"，答案可能会使某些后续问题变得多余，或者揭示一个你没有想到要问的新问题。
每次一个问题会产生一个更好的对话，而不是一份问卷调查。
第 3 步：探索问题空间
在提出解决方案之前，探索问题本身：
- 边缘情况是什么？
- 失败模式是什么？
- 与现有系统有哪些约束？
- 用户体验是什么样的？
第 4 步：提出 2–3 种方案
AI 提出两到三种不同的实现方案。每种方案都伴有权衡分析。
方案格式：
方案 A：[名称]
描述：[做什么]
优点：[这种方案的优势]
缺点：[这种方案的代价]
适合当：[什么时候选这个]
方案 B：[名称]
描述：[做什么]
优点：[这种方案的优势]
缺点：[这种方案的代价]
适合当：[什么时候选这个]
不要：
- 提出一个"明显正确"的方案和两个稻草人
- 将个人偏好伪装成客观分析
- 提出超过三种方案（更多选择会产生麻痹）
第 5 步：等待用户决策
这是硬性关卡。AI 等待用户做出决策。AI 不会：
- 假设用户会选择某个方案
- 在未经批准的情况下开始实现
- "试探性地"写一些代码来展示某个方案的样子
如果用户说"这两个方案我都不喜欢"——AI 提出新方案。如果用户说"让我先想想"——AI 等待。
第 6 步：记录决策
用户做出选择后，AI 生成一份简短的设计文档：
设计决策：[方案名称]
理由：[为什么选这个]
关键权衡：[我们接受的代价]
超出范围：[我们明确不做的事]
这份文档成为实现计划的基础（参见撰写计划）。
第 7 步：进入计划阶段
只有在设计文档经过批准之后，才能进入计划阶段。头脑风暴直接输出到计划阶段——没有"我们直接开始写代码吧"这个选项。
Visual Companion（可视化伴侣）
在 v5.0 中引入，Visual Companion 将头脑风暴过程渲染为交互式视觉图表。
当你激活 Visual Companion 时，头脑风暴会话产生：
- 思路和连接的可视化图表
- 方案比较的决策树
- 涉及多个组件的架构决策的系统图
这对以下情况特别有用：
- 复杂的架构决策，涉及许多组件
- 系统设计工作，需要可视化服务之间的关系
- 向利益相关者解释权衡，直观地呈现比文字更清晰
要激活：
/brainstorming --visual [功能描述]
反模式
以下是头脑风暴中最常见的失败模式：
| 反模式 | 它是什么样的 | 为什么有害 |
|---|---|---|
| 直接跳去编码 | "我知道该做什么，我们直接开始吧" | 把架构决策埋进代码，而不是明确处理 |
| 走过场 | 敷衍地走完流程，但预设方案已经决定 | 浪费时间，同时跳过了真正的探索 |
| 问卷清单 | 一次提出七个澄清问题 | 使对话变成问卷，而不是探索 |
| 稻草人方案 | 提出一个好方案和两个明显糟糕的 | 剥夺用户真正的选择 |
| 无限细化 | 永远不结束头脑风暴，继续添加细节 | 阻止到达计划和执行阶段 |
| 设计蔓延 | 在头脑风暴中添加功能，超出原始范围 | 范围扩大而没有用户明确批准 |
进入计划阶段前的检查清单
在结束头脑风暴并进入计划阶段之前，验证：
只有在所有项都勾选之后，才能开始撰写计划。
核心原则： 头脑风暴不是减慢开发速度的行政负担。它是消除最昂贵的错误的系统——那种你在正确实现了错误的东西之后才发现的错误。