Brainstorming — 设计门控与创意打磨 v2.0
来源：
- Superpowers brainstorming skill（设计门控 HARD-GATE）
- Anthropic idea-refine skill（创意提炼 3 阶段流程）
核心理念：
- 设计未批准，不写代码（HARD-GATE）
- 简单是终极的复杂（从用户体验出发，反向推导技术）
- 对 1000 件事说不（聚焦胜过广度）
🔴 铁律
NO CODE BEFORE DESIGN APPROVAL
如果任务涉及创建新功能、修改现有行为、构建组件，必须先完成设计审批，才能进入编码阶段。
触发条件
| 场景 | 是否触发 |
|---|---|
| 创建新功能 / 修改现有行为 / 构建组件 | ✅ 必须触发 |
| 想法模糊，需要探索可能性 | ✅ 触发完整流程 |
| 纯查询 / 阅读 / 分析（不涉及文件修改） | ❌ 跳过 |
| 对已有设计的 bug 修复（设计已存在） | ❌ 跳过 |
| 用户显式说"直接写，不需要设计" | ❌ 跳过 |
流程（6 个阶段，可根据情况裁剪）
Phase 0: 门控检查
判断是否需要设计审批：
任务到达
│
├─ 是否涉及创建/修改功能？
│ ├─ 否 → 跳过门控，继续
│ └─ 是 → 进入 Phase 1
│
└─ 用户是否明确豁免？
├─ 是（微小改动）→ 跳过门控
└─ 否 → 进入 Phase 1
Phase 1: 探索项目上下文
目标：理解当前代码库架构、模式、约束
动作：
- 扫描相关代码文件（如果存在）
- 识别现有架构模式
- 理解技术栈和约束
- 记录关键发现
输出：上下文摘要（用于后续阶段参考）
Phase 2: 澄清问题
目标：明确需求、约束、成功标准
问题清单（融合 brainstorming + idea-refine）：
| 问题 | 来源 |
|---|---|
| 目标是什么？ | brainstorming |
| 约束是什么（时间/技术/资源）？ | brainstorming |
| 成功标准是什么？ | brainstorming |
| 这是给谁用的？（具体用户） | idea-refine |
| 成功长什么样？ | idea-refine |
| 以前尝试过什么？ | idea-refine |
| 为什么是现在？ | idea-refine |
规则：不要继续，直到你理解这是给谁的以及成功长什么样。
Phase 3: 发散生成方案（来自 idea-refine）
目标：生成 5-8 个想法变体
7 个视角：
| 视角 | 问题 |
|---|---|
| 反转 | "如果我们做相反的？" |
| 约束消除 | "如果预算/时间/技术不是因素？" |
| 受众转换 | "如果这是给[不同用户]的？" |
| 组合 | "如果我们把它与[相邻想法]合并？" |
| 简化 | "10 倍简单的版本是什么？" |
| 10x 版本 | "大规模这会是什么样？" |
| 专家视角 | "[领域]专家会发现什么是外行人不会的？" |
如果在代码库中运行：使用搜索工具扫描相关上下文——现有架构、模式、约束、先前作品。将变体扎根于实际存在的东西。
轻量模式：如果上下文清晰，可缩减到 2-3 个变体。
Phase 4: 评估与收敛（融合）
目标：压力测试，聚类为 2-3 个方向
4.1 压力测试（来自 idea-refine）
| 标准 | 关键问题 |
|---|---|
| 用户价值 | 谁受益，多少？这是止痛药还是维生素？ |
| 可行性 | 技术和资源成本是什么？最难的部分是什么？ |
| 差异化 | 什么使这真正不同？人们会从当前方案切换吗？ |
止痛药 vs 维生素：
- 止痛药：解决急性的、频繁的问题。用户会主动寻找。他们会从当前方案切换。
- 维生素：锦上添花。让东西稍微好一点。用户不会特意去找。
4.2 假设审计（来自 idea-refine）
| 层 | 含义 | 行动 |
|---|---|---|
| Must Be True | 如果错，杀死想法 | 构建前必须验证 |
| Should Be True | 显著影响成功但不杀死 | 可以调整方法 |
| Might Be True | 关于次要功能 | 核心证明前不验证 |
4.3 权衡分析（来自 brainstorming）
对每个方向：
- 优点
- 缺点
- 风险
- 依赖
Phase 5: 锐化与输出
目标：输出统一的设计文档
输出文件：.superpowers/design-approval.md
内容结构：
# [想法名称]
## 问题陈述
[一句话"How Might We"框架]
## 推荐方向
[选择的方向和原因——最大 2-3 段]
## 要验证的关键假设
- [ ] [假设 1 — 如何测试]
- [ ] [假设 2 — 如何测试]
- [ ] [假设 3 — 如何测试]
## MVP 范围
[测试核心假设的最小版本。包含什么，不包含什么。]
## Not Doing（及原因）
- [事情 1] — [原因]
- [事情 2] — [原因]
- [事情 3] — [原因]
## 权衡记录
| 方向 | 优点 | 缺点 | 风险 |
|------|------|------|------|
| ... | ... | ... | ... |
## 批准记录
- Date: YYYY-MM-DD HH:MM
- Status: APPROVED
- User confirmed: "yes" / "approved" / "go ahead"
Phase 6: 设计审批（HARD-GATE）
目标：获得用户明确批准
流程：
- 展示设计文档
- 等待用户明确批准（"yes" / "approved" / "go ahead"）
- 若未批准，返回 Phase 2/4 调整
- 批准后，记录到
design-approval.md
反模式警告：
| 你的想法 | 现实 |
|---|---|
| "这太简单了，不需要设计" | 简单项目正是未经审视假设最浪费时间的地方 |
| "我知道用户想要什么" | 知道 ≠ 确认。展示设计，获得批准 |
| "设计会拖慢速度" | 返工更慢 |
| "只是个小改动" | 小改动也可能破坏现有行为。确认设计 |
| "用户很急，先写再说" | 写错了更急 |
快速路径
当用户明确表示"我已经有了初步想法，只需要评估"时：
跳过 Phase 1-3 → 直接进入 Phase 4（评估与收敛）
规则：
- 用户必须明确表示已有想法
- 仍需完成 Phase 4-6（评估 + 输出 + 审批）
- HARD-GATE 不能跳过
与 coding-framework 的关系
| 组件 | 职责 |
|---|---|
| coding-framework Step 0.5 | 门控（决定是否需要设计审批） |
| brainstorming skill | 流程（如何完成设计审批） |
调用方式：
coding-framework Step 0.5 检测到需要设计
→ 加载 brainstorming skill
→ 按其流程执行
→ 完成后回到 coding-framework 继续编码阶段
哲学
- 简单是终极的复杂 — 推向仍能解决真正问题的最简版本
- 从用户体验出发，反向推导技术
- 对 1000 件事说不 — 聚焦胜过广度
- 挑战每个假设 — "通常怎么做"不是理由
- 展示未来 — 不只是给人们更好的马
- 看不见的部分应该和看得见的部分一样美
任务完成后
完成任务后，做任务总结，将操作记录更新到 record.md 中。
Version 2.0.0 — 整合 Superpowers brainstorming（设计门控）+ Anthropic idea-refine（创意提炼）