Appearance
brainstorming skill 强制 AI 在写任何代码之前先和你对话：逐条澄清需求、提出多个方案、产出设计文档、等你点头确认。这不是一个可选的"建议步骤"，而是一道硬性闸门——无论任务看起来多简单，都必须走完这个流程。这样做的意义在于：绝大多数"写了一半才发现方向不对"的返工，根源都是没有在动手之前把需求搞清楚。
brainstorming skill：用对话驱动需求，而非直接跳进写代码
为什么需要这个 skill
你有没有遇到过这样的场景：把一个需求甩给 AI，它立刻开始写代码，洋洋洒洒输出了两三百行，结果你一看——方向完全不对。或者更隐蔽的情况：代码看起来能跑，但过了两天你才意识到它根本不是你想要的那个东西。
这种浪费的根源不在于 AI 写得不够好，而在于它在不理解你真正意图的情况下就开始执行了。brainstorming skill 是专门为解决这个问题而设计的：它把"先对话、再设计、最后才写代码"变成一个强制执行的工作流程。
什么时候会触发
按照 SKILL.md 中的定义，brainstorming 是任何创造性工作的强制前置步骤，包括但不限于：
- 开发新功能
- 构建新组件
- 添加新能力
- 修改已有行为
没有例外。就连"很简单的需求"也不例外——事实上，越是"看起来很简单"的需求，越容易因为没过脑子就开工而踩坑，因为你和 AI 双方都可能各自带着一个隐含假设，而这两个假设未必一致。
核心流程：九个步骤，一个都不能跳
brainstorming skill 的执行流程分为九步，严格按顺序走：
- 探索项目上下文：先读现有文件、文档和近期提交记录，搞清楚当前代码库的状态，而不是在真空中凭空设计。
- 判断是否需要视觉辅助：如果接下来的问题涉及界面布局、交互流程等视觉内容，先单独询问是否打开浏览器配套工具展示原型图。
- 逐条提问：每次只问一个问题，聚焦在目的、约束和成功标准上。问完等你回答，再问下一个。
- 提出 2-3 个方案：给出不同方向的选项，说明各自的权衡，并明确推荐哪一个以及理由。
- 分段展示设计：按复杂度决定每个部分写多少字，每讲完一段就询问你是否认可，再继续下一段。
- 写出设计文档：把经过确认的设计保存到
docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md，并提交到 git。 - 设计文档自查：检查文档中有无 TBD、前后矛盾、需求模糊或范围过大的问题，有的话直接修掉。
- 请你审阅文档：明确告诉你文档路径，请你看一遍，确认没有问题再继续。
- 移交实现阶段：调用 writing-plans skill 生成实现计划，而不是直接开写代码。
整个流程的终点是"进入 writing-plans"，而不是直接产出代码。
对话示例：一个真实场景
假设你说："帮我做一个关键词聚类工具。"
传统 AI 的反应：直接开始写 Python 脚本，用 TF-IDF 或 K-Means 实现一个通用的聚类算法，然后把代码甩给你。
brainstorming skill 的反应：
AI：我先看一下当前项目的目录结构……（读文件）。好的，我看到这是一个 SEO 内容框架项目，已经有 keywords 表和 clusters 表。
请问你希望聚类工具的输入是什么？
- A. 从数据库直接读取现有关键词
- B. 从 CSV 文件导入一批词
- C. 手动输入词列表
你：A，从数据库读。
AI：明白了。那聚类的依据是什么？
- A. 语义相似度（用 embedding 模型计算）
- B. 词根/词干匹配（规则方式）
- C. 让 LLM 直接判断哪些词属于同一主题
你：C，用 LLM 判断，这样更准。
AI：好。聚类完成之后，结果往哪里写？
- A. 自动更新数据库里每个词的
cluster_id - B. 输出到一个 JSON/CSV 文件让你手动确认再导入
- C. 直接在终端展示，不写入任何地方
这种一问一答的节奏，会把你真正的意图一层一层拎出来，而不是靠猜测把所有可能性都实现一遍。
方案提出：不是直接给答案，而是给选择
当 AI 通过提问积累了足够的信息，它不会直接说"好，我来实现"，而是会提出 2-3 个方向：
"基于你的需求，我有三种思路：
方案一（推荐）：批量调用 LLM，把所有待分组的词一次性喂进去，让它直接输出分组结果。优点是实现简单、结果直接可用；缺点是词太多时 token 费用会上涨，且单次 prompt 有长度限制。
方案二：先用 TF-IDF 做粗粒度分桶，再对每个桶内的词用 LLM 做精细分组。节省 token，但多了一个中间层，代码复杂度更高。
方案三：完全基于规则，对词做形态学分析（去掉停用词、提取词干），按词根分组。速度最快、成本为零，但对中文支持差，分组精度低。
我推荐方案一，因为你的关键词数量在几百个量级，成本可控，而且中文语义分组用规则方式误差太大。"
这种方式让你真正参与技术决策，而不是接受一个黑盒结果。
设计文档：对话的最终产出
对话结束之后，brainstorming skill 会把设计固化成一份文档，保存到 docs/superpowers/specs/ 目录下。文档覆盖的内容包括：
- 架构：整体结构是什么，各部分怎么组织
- 组件：有哪些模块，每个模块的职责是什么
- 数据流：数据从哪里来、经过哪些变换、最终写到哪里
- 错误处理：遇到 API 失败、数据库连接断开等情况怎么处理
- 测试策略：哪些部分需要单元测试，哪些需要集成测试
文档写完后，AI 会进行一次自查，检查有没有模糊的地方，然后把路径告诉你，等你确认没有问题之后才进入实现阶段。这份文档本身也是一份有价值的工程文档，未来的人（包括你自己）看这份文档就能理解当时为什么这么设计。
"太简单了，不需要设计"是个陷阱
SKILL.md 特别点名了一个反模式："这个需求太简单了，跳过设计吧。"
一个 todo list、一个单函数工具、一个配置项修改——这些看起来根本不需要设计的需求，恰恰是最容易因为"没想清楚就动手"而返工的地方。简单需求的设计文档可以很短（几句话就够），但必须存在，必须经过确认。
这条规则的逻辑是：你认为"简单"，通常是因为你还没有把它想清楚。
硬性闸门：代码必须等到设计被批准
整个 brainstorming skill 有一个不可绕过的约束：
在你展示设计并得到用户批准之前，不得调用任何实现 skill、不得写任何代码、不得搭建任何项目脚手架。
这不是一个"尽量遵守"的建议，而是一道硬性规则。即使你说"这个我知道怎么做，直接写就好了"，AI 也不会开始写代码——它会继续走完对话流程。
一句话总结
brainstorming skill 把"先想清楚再动手"从一个你需要时刻提醒自己的好习惯，变成了一个 AI 强制执行的工作流程。它的价值不在于让开发变慢，而在于让那些"走了一半才发现方向不对"的弯路提前消失。
FAQ
Q: 我的需求很明确，能不能跳过提问直接开始？
A: 不能。brainstorming skill 是强制前置步骤，没有"跳过"选项。但如果你的需求确实清晰，对话会很短——AI 问一两个问题确认细节，然后直接进入方案对比和设计阶段，整个过程可能只需要几分钟。
Q: 最终产出的设计文档存在哪里？
A: 默认保存在 docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md。如果你有偏好的位置，可以告诉 AI，它会按你指定的路径保存。文档同时会被 commit 到 git 仓库。
Q: 设计文档确认之后，下一步是什么？
A: brainstorming skill 会调用 writing-plans skill，生成详细的实现计划。注意：不是直接开始写代码，而是先有实现计划，再有代码。
Q: 如果我中途想改需求，怎么办？
A: 随时可以说。brainstorming skill 的设计本身就是可以回溯的——AI 会根据新的信息重新调整方案，必要时回到之前的某一步重新讨论，而不是强迫你把当前的方向走完。
Q: 对于超大型需求（比如"做一个完整的电商平台"），这个 skill 还适用吗？
A: 适用，但 AI 会先帮你分解。当需求覆盖多个独立子系统时，brainstorming skill 会先协助你把大需求拆解成若干子项目，然后对第一个子项目走完完整的对话-设计-文档流程，后续子项目依次进行。