brainstorming

Brainstorming 会在任何非简单功能、组件或行为变更之前，采用设计优先、未经批准不编写代码的流程：探索项目背景，逐个提出澄清问题，使用具名技巧发散出 6-8 种方案，再收敛为 2-3 种并用权衡表呈现，提交设计以供明确批准，将其保存到 `docs/plans/`，然后连同已收集的研究结果一起移交给 APEX Analyze（这样 Analyze 就不会重复研究）。

对于简单修复、拼写错误或简单重命名，完全跳过此流程——这些直接交给 APEX。

Brainstorming 技能

设计优先：设计获批前不编写代码。

---

Agent 工作流（强制）

每次 Brainstorming 之前，都要并行启动 Agent，每个 Agent 调用一次，并指定 name：

1. fuse-ai-pilot:explore-codebase - 了解项目背景、模式和限制
2. fuse-ai-pilot:research-expert - 查找最佳实践和文档

设计获批后，转入 APEX Analyze 阶段，在移交时一并传递 explore-codebase 和 research-expert 的发现（不能只传设计文档）。APEX Analyze 默认会重新运行这两个 Agent——沿用本流程已收集的内容，可避免重复开展相同研究。

---

概览

场景	操作
新功能	完整 Brainstorming（6 个步骤）
重大变更	完整 Brainstorming（6 个步骤）
创建组件	完整 Brainstorming（6 个步骤）
简单修复（1-3 行）	跳过 Brainstorming，转到 APEX
简单重命名/拼写错误	跳过 Brainstorming，转到 APEX

---

6 步流程

步骤 1：探索项目背景

提问前先收集背景信息：

• git log --oneline -20 - 近期变更和发展方向
• 现有代码模式和约定
• 相关文档和既有决策
• 技术栈和依赖限制

步骤 2：提出澄清问题（一次一个）

依次提出有针对性的问题。每次都要等对方回答后再问下一个。

类别：目的、限制、成功标准、用户、集成。

问题类别请参阅 workflow.md

步骤 3：发散思考，然后收敛为 2-3 种方案

使用具名技巧（SCAMPER / 逆向头脑风暴 / 类比）生成 ≥6-8 种不同方案，暂缓评判——不能只是同一个想法的 3 种规模。只有完成发散后，才能收敛为 2-3 种方案，并用表格列出权衡：

方案	优点	缺点	推荐
选项 A	...	...	...
选项 B	...	...	...
选项 C	...	...	...

始终给出明确推荐并说明理由。

步骤 4：提交设计以供批准

将设计拆分成易于理解的部分：

1. 架构概览
2. 关键组件及其职责
3. 数据流和状态管理
4. 边缘情况和错误处理

继续之前必须等待用户明确批准。

步骤 5：保存设计文档

将获批的设计保存到：docs/plans/YYYY-MM-DD-<topic>-design.md

步骤 6：转入 APEX

将获批的设计作为输入，移交给 APEX Analyze 阶段。

---

参考指南

主题	参考资料	查阅时机
工作流	workflow.md	问题类别、方案格式、设计模板
反模式	anti-patterns.md	识别为跳过 Brainstorming 而寻找的借口

---

快速参考

1. Explore   → git log, codebase, docs (agents in parallel)
2. Question  → ONE AT A TIME, wait for answers
3. Diverge   → 6-8 options (named technique), converge to 2-3 with trade-offs table
4. Design    → Present sections, get approval
5. Save      → docs/plans/YYYY-MM-DD-<topic>-design.md
6. Handoff   → APEX Analyze with approved design + prior research (no re-research)

---

关键规则

1. 设计获批前绝不编写代码 - 始终先做设计
2. 一次只问一个问题 - 绝不一次性抛出 10 个问题
3. 始终提出替代方案 - 至少 2 种方案，并说明权衡
4. 保存设计文档 - 留下审计记录和共享参考
5. 获得明确批准 - 继续之前要得到“看起来不错”或类似的确认