Brainstorming

Brainstorming

用途

• 把"直接跳到实现方案"改成"先发散探索、再收敛锁定"。
• 适合技术选型、架构方向、产品策略、用户体验方案等需要创造性思考的场景。
• 避免团队因锚定效应只看到第一个想到的方案。

默认做法

1. 框定问题

• 用一句话描述要解决的核心问题。
• 明确约束条件（时间、技术栈、团队能力、合规要求）。
• 明确成功标准：什么样的方案是"好方案"。

2. 发散阶段

• 产出至少 3 个差异化方案，每个方案包含：

  • 一句话概述：方案的核心思路
  • 关键假设：该方案依赖哪些前提
  • 优势：这个方案比其他方案好在哪
  • 风险：可能出什么问题
  • 成本估算：时间/人力/基础设施的粗略评估

• 强制对比维度（来自 gstack multi-perspective 方法论）：

  • 用户视角：哪个方案用户体验最好？
  • 工程视角：哪个方案最容易维护和扩展？
  • 商业视角：哪个方案 ROI 最高？
  • 风险视角：哪个方案最不容易出问题？

3. 分块展示（来自 gstack chunked design）

• 复杂方案不要一口气全部展示，而是分层递进：
  • 第一块：核心架构和关键决策（最高层）
  • 第二块：模块拆分和接口设计（结构层）
  • 第三块：技术细节和实现路径（执行层）
  • 每块展示后暂停，等用户确认方向再展开下一层
  • 用户可以在任意一层要求调整或切换方案

4. 收敛阶段

• 基于讨论结论，形成推荐方案的结构化输出：
  • 推荐方案及原因
  • 被排除的方案及排除原因
  • 关键假设和待验证项
  • 下一步行动建议

5. 产出

• 若用于 /team-plan 前置：产出写入 docs/artifacts/{slug}/brainstorm.md
• 若用于独立探索：产出写入对话上下文，由用户决定是否持久化
• 若产出涉及架构级决策：建议同步写入 ADR

触发信号

• 用户说"我们讨论一下方案"、"有哪些选择"、"brainstorm"、"头脑风暴"。
• /team-intake 或 discuss-phase 识别出存在多条可行技术路线。
• architect 在方案设计阶段需要对比多个选项。
• 技术选型、框架选择、产品策略等需要创造性探索的场景。

配套约束

1. 不替代正式决策：brainstorming 产出是输入，最终决策由 tech-lead 或 architect 在 /team-plan 或 ADR 中锁定。
2. 时间控制：单次 brainstorming 控制在 3-5 个方案以内，避免无限发散。
3. 独立性：brainstorming 可以独立调用，不依赖 /team-* 链路。
4. 对话友好：分块展示模式应在每块结束后给用户反馈点，不要一次性输出整个方案。