brainstorming

设计门控与创意打磨 — 融合Superpowers HARD-GATE与Anthropic idea-refine的发散能力

Brainstorming — 设计门控与创意打磨 v2.0

来源：

• Superpowers brainstorming skill（设计门控 HARD-GATE）
• Anthropic idea-refine skill（创意提炼 3 阶段流程）

核心理念：

• 设计未批准，不写代码（HARD-GATE）
• 简单是终极的复杂（从用户体验出发，反向推导技术）
• 对 1000 件事说不（聚焦胜过广度）

---

🔴 铁律

text

NO CODE BEFORE DESIGN APPROVAL

如果任务涉及创建新功能、修改现有行为、构建组件，必须先完成设计审批，才能进入编码阶段。

---

触发条件

场景	是否触发
创建新功能 / 修改现有行为 / 构建组件	✅ 必须触发
想法模糊，需要探索可能性	✅ 触发完整流程
纯查询 / 阅读 / 分析（不涉及文件修改）	❌ 跳过
对已有设计的 bug 修复（设计已存在）	❌ 跳过
用户显式说"直接写，不需要设计"	❌ 跳过

---

流程（6 个阶段，可根据情况裁剪）

Phase 0: 门控检查

判断是否需要设计审批：

text

任务到达
    │
    ├─ 是否涉及创建/修改功能？
    │   ├─ 否 → 跳过门控，继续
    │   └─ 是 → 进入 Phase 1
    │
    └─ 用户是否明确豁免？
        ├─ 是（微小改动）→ 跳过门控
        └─ 否 → 进入 Phase 1

---

Phase 1: 探索项目上下文

目标：理解当前代码库架构、模式、约束

动作：

1. 扫描相关代码文件（如果存在）
2. 识别现有架构模式
3. 理解技术栈和约束
4. 记录关键发现

输出：上下文摘要（用于后续阶段参考）

---

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

内容结构：

markdown

# [想法名称]

## 问题陈述
[一句话"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）

目标：获得用户明确批准

流程：

1. 展示设计文档
2. 等待用户明确批准（"yes" / "approved" / "go ahead"）
3. 若未批准，返回 Phase 2/4 调整
4. 批准后，记录到 design-approval.md

反模式警告：

你的想法	现实
"这太简单了，不需要设计"	简单项目正是未经审视假设最浪费时间的地方
"我知道用户想要什么"	知道 ≠ 确认。展示设计，获得批准
"设计会拖慢速度"	返工更慢
"只是个小改动"	小改动也可能破坏现有行为。确认设计
"用户很急，先写再说"	写错了更急

---

快速路径

当用户明确表示"我已经有了初步想法，只需要评估"时：

text

跳过 Phase 1-3 → 直接进入 Phase 4（评估与收敛）

规则：

• 用户必须明确表示已有想法
• 仍需完成 Phase 4-6（评估 + 输出 + 审批）
• HARD-GATE 不能跳过

---

与 coding-framework 的关系

组件	职责
coding-framework Step 0.5	门控（决定是否需要设计审批）
brainstorming skill	流程（如何完成设计审批）

调用方式：

text

coding-framework Step 0.5 检测到需要设计
    → 加载 brainstorming skill
    → 按其流程执行
    → 完成后回到 coding-framework 继续编码阶段

---

哲学

• 简单是终极的复杂 — 推向仍能解决真正问题的最简版本
• 从用户体验出发，反向推导技术
• 对 1000 件事说不 — 聚焦胜过广度
• 挑战每个假设 — "通常怎么做"不是理由
• 展示未来 — 不只是给人们更好的马
• 看不见的部分应该和看得见的部分一样美

---

任务完成后

完成任务后，做任务总结，将操作记录更新到 record.md 中。

---

Version 2.0.0 — 整合 Superpowers brainstorming（设计门控）+ Anthropic idea-refine（创意提炼）