头脑风暴 (brainstorming)

头脑风暴（brainstorming）

概述

brainstorming 是 Superpowers 里最关键的“任务启动型” Skill 之一。它的目标不是直接产出代码，而是把一个模糊想法、一个功能请求、一个设计愿望，逐步转化成：

明确的问题定义
边界清晰的范围
2~3 种可比较的方案
得到用户确认的设计
最终可写入 spec 的设计文档

简单说，它解决的是：

很多失败不是因为实现差，而是因为还没真正想清楚就开始做。

这个 Skill 强制你在实现前停下来，通过自然对话把需求压实、把方案展开、把设计讲清楚、把规格写下来，再进入下一步 writing-plans。

工作流程

原文把 brainstorming 定义成一个严格的漏斗流程：

graph TD
  A[探索项目上下文] --> B{是否涉及视觉问题？}
  B -->|是| C[单独发消息提供 Visual Companion]
  B -->|否| D[逐个提澄清问题]
  C --> D
  D --> E[提出 2-3 种方案与取舍]
  E --> F[分段呈现设计]
  F --> G{用户是否认可？}
  G -->|否，继续修订| F
  G -->|是| H[写设计文档]
  H --> I[Spec 审查循环]
  I --> J{Spec 是否通过？}
  J -->|否| H
  J -->|是| K[让用户审阅 spec]
  K --> L{用户是否批准？}
  L -->|否| H
  L -->|是| M[进入 writing-plans]

步骤 1：先探索上下文

不要一上来就问需求。先看：

当前项目结构
已有文档
最近提交
已有模式和边界

这是为了避免“脱离现有系统想当然设计”。

步骤 2：逐个问清问题

原文非常强调：

一次只问一个问题
优先多项选择题
重点理解目的、约束、成功标准

这背后的理由很强：如果一次问太多，用户会答得混乱；如果问题太开放，AI 会得到一堆难以落地的信息。

步骤 3：给出 2~3 个方案

不是直接给唯一答案，而是：

给不同路线
说明 trade-off
明确推荐哪个以及为什么

这一步很重要，因为 brainstorming 的目的不是“套模板”，而是要让用户真正参与到方向判断中。

步骤 4：分段呈现设计并逐步确认

原文不建议一口气把整个设计文档扔给用户，而是：

一段一段讲
每讲完一段确认一次
如果有偏差就回退调整

这是一种非常实用的协作方式，因为很多设计问题不是“有没有写出来”，而是“用户是否真的认可”。

步骤 5：写 spec，并进入审查循环

当设计被认可后，不是直接开干，而是：

写到文档里
做 spec review loop
再让用户审一次
最后才进入 writing-plans

这说明 brainstorming 的终点不是“讨论结束”，而是“形成被审查过的设计资产”。

模拟场景

场景 1：用户说”加一个登录功能”

❌ 错误：直接开始写登录页面
✅ 正确：先问清需求、目标用户、现有系统，再给 2-3 个方案

场景 2：用户要给现有功能加新字段

❌ 错误：直接改数据库和 API
✅ 正确：先理解现有架构，给出前端/后端/数据库的完整方案

核心命令

# 1. 探索项目上下文
ls -la
git log --oneline -5
cat CLAUDE.md

# 2. 逐个问澄清问题（一次只问一个）
# 3. 提出 2-3 个方案并说明 trade-off
# 4. 分段呈现设计，每段确认

避坑指南

坑	表现	解决
跳过设计直接做	”很简单，直接做吧”	必须先设计确认
一次问很多问题	用户回答混乱	一次只问一个
只给一个方案	用户没得选	给 2-3 个方案

速查卡片

何时使用

新功能设计
组件/页面设计
行为改动
新系统或子系统规划

何时不用

不是实现前的设计问题
纯执行型子任务且已有明确 spec

关键要点

先设计，后实现
一次只问一个问题
必须给出 2~3 个方案
设计通过后才能进入 writing-plans

常见错误

觉得任务太简单不用设计
还没确认就开写代码
一次问太多问题
跳过设计文档与审查循环

关键概念

英文术语	中文翻译	解释
Brainstorming	头脑风暴 / 方案发散	在实现前通过结构化对话把需求与方案打磨清楚。
HARD-GATE	硬门禁	在用户批准设计前，不得进入任何实现动作。
Visual Companion	可视化辅助	在需要展示 mockup、布局、图示时，借助浏览器进行可视化协作。
Spec review loop	规格审查循环	写完 spec 后，通过 reviewer 子代理反复检查到可进入 planning 为止。
YAGNI	你不会需要它	设计时严格砍掉不必要功能，避免过度设计。

常见错误与红旗

错误行为	为什么是错的	正确做法
“这个功能很小，直接做吧”	小任务最容易藏着未验证假设	至少做最小设计确认
一上来就写代码或搭骨架	违反 HARD-GATE	用户批准设计前不得进入实现
一次提很多澄清问题	会让对话失焦，答案也不稳定	一次一个问题
只给一种方案	用户无法比较 trade-off	至少给 2~3 个方案
spec 写完就直接进实现	缺少审查和用户确认	先 review，再 user gate，再写计划

深度解读

原文的设计哲学

这个 Skill 的设计哲学非常明确：

实现前的“想清楚”本身就是工作，不是浪费时间。

很多团队嘴上承认这一点，但在实际开发里常常跳过：

觉得需求很简单
觉得先做出来再说
觉得文档太重

而 Superpowers 则反其道而行之：它明确规定，任何创造性工作都必须先经过设计漏斗。

这说明作者不是把 brainstorming 看成“灵感交流”，而是把它看成一个严肃的工程前置流程。

与日常开发的关联

你在真实工作中一定见过这几类情况：

PM 说“就改一下按钮”，结果牵动权限、状态、交互流
以为只是一个小表单，最后发现要接多套验证逻辑
以为是前端调整，做着做着变成数据结构问题

这些都说明：

任务之所以变复杂，往往不是实现太难，而是起步时没有拆清楚。

brainstorming 的价值就在于，它逼你在“动手之前”先把这些隐性复杂度暴露出来。

实际使用场景举例

场景 1：新增一个多步骤表单

错误做法：

直接写页面和状态切换

正确做法：

先问这个表单的业务目标是什么
再问步骤是按什么逻辑划分
给 2~3 套交互方案
确认后再写 spec

场景 2：做一个内部 dashboard

错误做法：

直接把用户说的模块堆进去

正确做法：

先理解 dashboard 的核心使用者是谁
他们最重要的判断动作是什么
哪些信息必须首屏、哪些可以后置
先确定信息架构，再动手实现

场景 3：修改系统行为

错误做法：

直接按字面需求改逻辑

正确做法：

先确认原行为、预期行为、边界行为
给出多种修改路径
让用户确认“真正想要的结果”

关联 Skill

前置：using-superpowers，因为你必须先判断该不该进入 brainstorming。
后续：writing-plans，这是 brainstorming 明确指定的下一步。
互补：systematic-debugging（当问题是 bug）、test-driven-development（当进入实现阶段）、subagent-driven-development（当设计要落到多代理执行时）。

这份文档的重点不是“总是用浏览器”，而是： 只在视觉问题真的更适合用视觉方式表达时才用。

它给出的判断标准很清楚：

如果问题本身是视觉内容：用浏览器
如果问题本身是概念或取舍：用终端

适合浏览器的包括：

UI mockup
架构图
布局对比
视觉层级比较

不适合浏览器的包括：

范围确认
概念解释
取舍分析
技术决策

这份文档的价值在于，它把“视觉协作”从一种炫技能力，变成一种有边界的沟通工具。

查看源文件: GitHub原始文件