关于 brainstorming
引导头脑风暴、先明确要构建什么再规划如何实现的 Skill，适用于需求模糊、方案不止一种或需要细化功能范围的情形。
主要功能
- 01评估需求清晰度
- 02逐个提问以了解意图
- 03比较具体方案
- 04结构化整理设计
- 05分阶段确认理解
适用场景
- 01澄清模糊的功能需求
- 02与相关方探讨方案取舍
- 03实现前细化功能范围
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/brainstorming确认已加载。
附带文件reference/examples.md
详细介绍
头脑风暴
此技能提供详细的流程知识，帮助开展有效的头脑风暴，在深入探讨如何构建之前，先明确要构建什么。
何时使用此技能
以下情况适合进行头脑风暴：
- 需求不明确或含糊
- 有多种方案可以解决问题
- 需要与用户探讨权衡取舍
- 用户尚未充分说明自己的需求
- 需要细化功能范围
以下情况可以跳过头脑风暴：
- 需求明确且详细
- 用户清楚地知道自己想要什么
- 任务只是简单的 Bug 修复或定义明确的改动
核心流程
阶段 0：评估需求清晰度
开始提问前，先评估是否需要头脑风暴。
需求明确的信号：
- 用户提供了具体的验收标准
- 用户提到了要遵循的现有模式
- 用户描述了预期的确切行为
- 范围有限且定义明确
需要头脑风暴的信号：
- 用户使用了含糊的说法（“改进一下”“添加类似这样的东西”）
- 存在多种合理的解释
- 尚未讨论权衡取舍
- 用户似乎不确定该采用哪种方案
如果需求明确，可以建议：“您的需求似乎已经很清楚。建议直接进入规划或实施阶段。”
阶段 1：理解想法
一次只问一个问题，了解用户的意图。避免一次提出多个问题，让用户应接不暇。
提问技巧：
-
存在自然选项时，优先采用多选形式
- 好的提问：“通知方式应该是：(a) 仅邮件、(b) 仅应用内通知，还是 (c) 两者都有？”
- 避免：“应该如何通知用户？”
-
先宽泛提问，再逐步缩小范围
- 首先：核心目的是什么？
- 然后：用户是谁？
- 最后：有哪些约束？
-
明确验证假设
- “我假设用户已经登录。对吗？”
-
尽早询问成功标准
- “您如何判断此功能运行良好？”
需要探讨的关键主题：
| 主题 | 示例问题 |
|---|---|
| 目的 | 这解决了什么问题？动机是什么？ |
| 用户 | 谁会使用？他们处于什么情境？ |
| 约束 | 有技术限制吗？时间安排呢？依赖项呢？ |
| 成功 | 如何衡量成功？理想流程是什么？ |
| 边缘情况 | 哪些情况不应该发生？需要考虑哪些错误状态？ |
| 现有模式 | 代码库中是否有类似功能可以借鉴？ |
结束条件： 持续探讨，直到想法清晰，或用户说“继续”或“我们进入下一步吧”
阶段 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
→ `/workflows:plan` for implementation details
输出位置： docs/brainstorms/YYYY-MM-DD-<topic>-brainstorm.md
阶段 4：交接
明确说明接下来可以采取哪些行动：
- 进入规划阶段 → 运行
/workflows:plan - 继续完善 → 继续探讨设计
- 暂时结束 → 用户之后再回来
YAGNI 原则
头脑风暴期间，应主动避免复杂化：
- 不要针对假设的未来需求进行设计
- 选择能够解决当前问题的最简单方案
- 优先采用平实、可靠的模式，而非巧妙的解决方案
- 复杂性出现时，询问“我们真的需要这个吗？”
- 推迟那些现在无需做出决定的事项
增量验证
每个部分保持简短——最多 200-300 个词。每输出一个部分后，暂停并确认理解是否正确：
- “这符合你的想法吗？”
- “继续之前需要做哪些调整吗？”
- “你希望朝这个方向推进吗？”
这样可以避免在设计方向不符时白费功夫。
应避免的反模式
| 反模式 | 更好的做法 |
|---|---|
| 一次问 5 个问题 | 一次问一个 |
| 直接跳到实现细节 | 聚焦于做什么，而不是怎么做 |
| 提出过于复杂的解决方案 | 从简单方案开始，只有在需要时才增加复杂性 |
| 忽略现有代码库的模式 | 先了解现有内容 |
| 未经验证就做出假设 | 明确说明假设并加以确认 |
| 创建冗长的设计文档 | 保持简洁——细节放在计划中 |
与规划的集成
头脑风暴回答要构建什么：
- 需求和验收标准
- 选定的方法及其理由
- 关键决策和权衡
规划回答如何构建：
- 实施步骤和文件变更
- 技术细节和代码模式
- 测试策略和验证
如果存在头脑风暴输出，/workflows:plan 应检测并将其用作输入，跳过自身的构想完善阶段。
评论
支持 Markdown