brainstorming

头脑风暴

此技能提供详细的流程知识，帮助开展有效的头脑风暴，在深入探讨 如何 构建之前，先明确要构建 什么。

何时使用此技能

以下情况适合进行头脑风暴：

• 需求不明确或含糊
• 有多种方法可以解决问题
• 需要与用户探讨权衡取舍
• 用户尚未充分说明自己的需求
• 需要细化功能范围

以下情况可以跳过头脑风暴：

• 需求明确且详细
• 用户确切知道自己想要什么
• 任务是简单直接的 Bug 修复或定义明确的改动

核心流程

阶段 0：评估需求的清晰度

在开始提问之前，先评估是否需要进行头脑风暴。

需求明确的信号：

• 用户提供了具体的验收标准
• 用户提到了要遵循的现有模式
• 用户描述了预期的确切行为
• 范围有限且定义明确

需要进行头脑风暴的信号：

• 用户使用了含糊的措辞（“做得更好”“添加类似功能”）
• 存在多种合理的解读
• 尚未讨论权衡取舍
• 用户似乎不确定该采用什么方法

如果需求明确，可以建议：“您的需求似乎很清晰。可以直接开始规划或实现。”

阶段 1：理解想法

一次只问 一个问题，以理解用户的意图。避免一次提出多个问题，让用户应接不暇。

提问技巧：

1. 存在自然选项时，优先使用多选题

   • 好的问法：“通知方式应该是：（a）仅电子邮件、（b）仅应用内通知，还是（c）两者都有？”
   • 避免：“应该如何通知用户？”

2. 先宽泛，再逐步缩小范围

   • 首先：核心目的是什么？
   • 然后：用户是谁？
   • 最后：有哪些限制条件？

3. 明确验证假设

   • “我假设用户已经登录。对吗？”

4. 尽早询问成功标准

   • “您如何判断这个功能运行良好？”

要探讨的关键主题：

主题	示例问题
目的	这能解决什么问题？动机是什么？
用户	谁会使用它？他们处于什么情境？
限制条件	有任何技术限制吗？时间安排如何？是否有依赖项？
成功	如何衡量成功？理想的使用流程是什么？
边缘情况	哪些情况不应该发生？需要考虑哪些错误状态？
现有模式	代码库中是否有可供参考的类似功能？

退出条件： 持续探讨，直到想法明确，或用户说“继续”或“我们进入下一步吧”。

阶段 2：探索实现方案

理解想法后，提出 2-3 个具体方案。

每种方案的结构：

### Approach A: [Name]

[2-3 sentence description]

**Pros:**
- [Benefit 1]
- [Benefit 2]

**Cons:**
- [Drawback 1]
- [Drawback 2]

**Best when:** [Circumstances where this approach shines]

指南：

• 先给出推荐方案并解释原因
• 坦诚说明权衡取舍
• 考虑 YAGNI——通常越简单越好
• 相关时参考代码库中的模式

阶段 3：记录设计

以结构化格式总结关键决策。

设计文档结构：

---
date: YYYY-MM-DD
topic: <kebab-case-topic>
---

# <Topic Title>

## What We're Building
[Concise description—1-2 paragraphs max]

## Why This Approach
[Brief explanation of approaches considered and why this one was chosen]

## Key Decisions
- [Decision 1]: [Rationale]
- [Decision 2]: [Rationale]

## Open Questions
- [Any unresolved questions for the planning phase]

## Next Steps
→ `/ce:plan` for implementation details

输出位置： docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md

阶段 4：交接

清晰列出下一步选项：

1. 开始规划 → 运行 /ce:plan
2. 进一步完善 → 继续探讨设计
3. 暂告一段落 → 用户稍后会再回来

YAGNI 原则

进行头脑风暴时，要主动抵制复杂化：

• 不要为假设的未来需求进行设计
• 选择能解决既定问题的最简单方案
• 优先采用朴实、经验证的模式，而不是巧妙的解决方案
• 出现复杂性时，问一句“我们真的需要这个吗？”
• 推迟不必现在做出的决定

增量验证

每个章节保持简短——最多 200–300 个词。每输出一个章节后，暂停并确认理解是否一致：

• “这符合你的预期吗？”
• “继续之前需要做任何调整吗？”
• “你想要的方向是这样吗？”

这样可以避免在设计方向不一致时浪费精力。

应避免的反模式

反模式	更好的做法
一次提出 5 个问题	一次问一个问题
直接跳到实现细节	专注于做什么，而不是怎么做
提出过于复杂的解决方案	从简单方案开始，仅在需要时增加复杂度
忽略现有代码库的模式	先了解现有内容
未经确认就做出假设	明确说明假设并进行确认
编写冗长的设计文档	保持简洁——细节放在计划中

与规划的集成

头脑风暴回答要构建什么：

• 需求和验收标准
• 选定的方法及其理由
• 关键决策和权衡

规划回答如何构建：

• 实施步骤和文件变更
• 技术细节和代码模式
• 测试策略和验证

如果已有头脑风暴输出，/ce:plan 应检测到它并将其用作输入，跳过自身的想法完善阶段。