想象一下：你是个天才厨师，但有个坏习惯——一有灵感就冲进厨房乱炒菜。结果常常是：盐放成糖、火候全乱、客人吃了一口就跑了。后来你学乖了：先问清楚客人想吃什么，再设计菜谱，最后才动手。Brainstorming Skill 就是给 AI 的这个“先设计后实现”的纪律。
🎯 核心原理：为什么必须“先想后做”？
大多数 AI 一收到“帮我建个待办清单”就立刻开始写代码。但 Brainstorming 说：停！ 你得先弄明白：
- 用户要的是 Web 版还是手机版？
- 需要截止日期提醒吗？
- 数据存哪？本地还是云端？
否则你吭哧吭哧写完了，用户说“我要的是拖拽排序，不是按按钮”。你白干了。
所以 HARD-GATE 铁律：未获设计批准前，禁止写任何代码、建任何项目、做任何实现动作。哪怕“简单到不用设计”的待办清单也不行——简单项目里隐藏的假设最多，返工最浪费。
📦 三个核心文档（就是你提供的三个文件）
| 文件 | 作用 | 类比 |
|---|---|---|
SKILL.md | 总流程手册：从探索→提问→设计→写文档→转交实施 | 厨师的操作 SOP |
visual-companion.md | 浏览器可视化辅助：画界面草图、布局对比、架构图 | 给客人看的效果图册 |
spec-document-reviewer-prompt.md | 设计文档自检清单：检查遗漏、矛盾、歧义 | 主厨试吃环节 |
🔄 完整时序图：从“想法”到“实施计划”
🎭 用故事解释每个步骤
1️⃣ 探索项目上下文（侦探阶段）
AI 先翻你的代码仓库、文档、最近的 git 提交记录。比如看到你项目里已经有 Tailwind，它就不会再推荐你用 Bootstrap。目的：不瞎猜，不重复造轮子。
2️⃣ 视觉伴侣（给用户看画板）
如果问题涉及界面布局、颜色、图标排列，AI 会问：“想不想打开浏览器看看草图？” 你同意后，它启动一个本地服务器，生成 HTML 页面（里面是几个布局选项），你点一点就能选。好处：一张图胜过千言万语，避免“我以为你说的是这种按钮”的误解。
关键规则：
- 每次只问一个视觉问题，不把多个混在一起。
- 你点完后，浏览器会把选择记录存到文件，AI 下一轮读取。
- 不需要浏览器时，AI 会推一个“等待中”页面，不让你看着旧图发呆。
3️⃣ 逐个提问（像医生问诊）
每次只问一个问题，且尽量用选择题。比如：“需要支持多人协作吗？A. 单人 B. 团队” 而不是开放式的“你想怎么协作？”——因为选择题省脑力。这阶段主要搞清楚：目的、限制、成功标准。
4️⃣ 提出 2-3 种方案（点菜环节）
AI 会给出不同路线，附带优缺点和推荐。比如：
- 方案A：极简，三天做完，但无统计
- 方案B：适中，一周，含本地统计（推荐）
- 方案C：豪华版，两周，云端同步
用户拍板后，AI 才细化设计。
5️⃣ 展示设计（画施工图）
设计分为：架构、组件、数据流、错误处理、测试策略。每个部分都会问你“这样对吗？”——像你盖房子，每砌一堵墙都让你验收。规模匹配：简单项目可能就三五句话，复杂项目几百字。
6️⃣ 写设计文档（留底）
保存到 docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md 并自动 git commit。以后你忘了当初为什么这么设计，翻文档就行。
7️⃣ 自检 + 用户审阅（双重把关）
- 自检：AI 自己检查有没有“TODO”、“TBD”，有没有前后矛盾，有没有范围过大（比如把番茄钟和记账本揉在一起）。
- 用户审阅：AI 把文档链接发给你，你确认没问题才继续。这步是最容易被跳过的，但恰恰是防止翻车的关键。
8️⃣ 转交 writing-plans 技能（终于要动手了）
Brainstorming 的终极目标不是写代码，而是生成一份清晰的实施计划。writing-plans 技能会接手，把设计拆成一个个可执行的任务（比如“第1步：初始化 Vite 项目”“第2步：创建 Timer 组件”）。注意：Brainstorming 绝不允许直接调用 frontend-design 或 mcp-builder 等实现技能。
🧪 最佳用法（给小白用户的建议）
✅ 什么时候用 Brainstorming？
- 任何新功能、新组件、新页面，哪怕你觉得“超简单”
- 改动现有代码，但可能影响多个文件
- 不确定用户真实需求时
✅ 怎么配合 AI 让流程最顺？
- 主动提供上下文：先把相关文件拖进对话，说“这是我的项目，我想在登录页加个验证码”
- 回答选择题：别偷懒打“随便”，AI 会纠结
- 认真看视觉伴侣：如果 AI 问要不要开浏览器，说“好”——点两下比打一堆字快
- 审阅设计文档：一定要点开看，发现问题当场说，别等代码写完了再后悔
❌ 常见错误
- 跳步：直接说“别问了，直接写代码”——那 Brainstorming 就没意义了
- 一次性回答所有问题：AI 一次只问一个，你全答了它可能忽略后面的
- 不点浏览器：纯文字描述“我要那种清爽的布局”，AI 只能猜，大概率猜错
🔧 视觉伴侣的实战技巧（进阶）
当你同意使用浏览器后，AI 会生成类似这样的 HTML 片段：
<h2>哪种计时器风格更符合你的 App？</h2>
<div class="options">
<div class="option" data-choice="circle" onclick="toggleSelect(this)">
<div class="letter">A</div><div class="content"><h3>圆形进度环</h3><p>类似苹果手表</p></div>
</div>
<div class="option" data-choice="bar" onclick="toggleSelect(this)">
<div class="letter">B</div><div class="content"><h3>水平进度条</h3><p>经典下载风格</p></div>
</div>
</div>
你点击后，toggleSelect 函数会记录你的选择，并高亮选项。AI 下一轮读取 $STATE_DIR/events 文件，就知道你选了“圆形”。无需任何后端，纯前端 + 文件记录。
🧩 与普通对话的区别
| 普通对话 | Brainstorming |
|---|---|
| 用户：“做个待办” → AI 直接写代码 | 用户：“做个待办” → AI 先问列表视图、优先级、截止日期 |
| 可能做错返工 | 设计通过后再实现，一次到位 |
| 没有文档记录 | 自动生成设计文档并提交 git |
| 视觉问题全靠文字猜 | 可启动浏览器展示真实 mockup |
| 直接跳到实现 | 最终交给 writing-plans 生成任务清单 |
🎬 总结一句
Brainstorming 就像给 AI 戴上“设计师眼镜”——在它拿起键盘之前，先画好蓝图、问清需求、让你签字确认。虽然多花五分钟，但能省下五小时的改 bug 时间。
下次你对着 AI 喊“帮我写个聊天室”时，如果它开始问你“需要消息已读回执吗？”——别烦，它正在用 Brainstorming 救你的项目呢。
