brainstorming

头脑风暴

核心原则

先设计，再编码。始终如此。

不要急于开始实现。先通过对话梳理出规格。

头脑风暴流程

步骤 1：了解目标

提出澄清问题：

• 我们要解决什么问题？
• 用户是谁？
• 什么样的结果才算成功？
• 有哪些约束？

一次只问一个问题——不要一次抛出多个问题。

步骤 2：探索可能性

• 有哪些可行方案？
• 各自有哪些权衡？
• 存在哪些类似问题？
• 可以应用哪些模式？

步骤 3：提出备选方案

确定方案前，始终先提出 2-3 种方案：

## Option A: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option B: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

## Option C: [Name]
- Pros: ...
- Cons: ...
- Best when: ...

**Recommendation:** Option [X] because...

步骤 4：逐步验证

分块展示设计，确保易于理解：

• 一次展示一个部分
• 获得认可后再继续
• 允许调整方向

步骤 5：记录设计

保存到：docs/plans/YYYY-MM-DD-<topic>-design.md

严格遵循 YAGNI 原则

头脑风暴时，主动删除：

• “有了也不错”的功能
• “可能会发生”的边缘情况
• 为“未来灵活性”而设计的抽象
• 为“可能需要的规模”而做的优化

请问：“MVP 需要这个吗？”

提问技巧

优先采用选择题

不要问：“我们应该如何处理错误？” 而应问：“错误处理应该采用哪种方式？A）返回错误代码，B）抛出异常，C）使用 Result 类型？”

限定问题范围

不要问：“API 应该是什么样的？” 而应问：“应该采用 REST、GraphQL 还是 RPC？”

明确假设

• “我假设 X。对吗？”
• “这取决于 Y。Y 是否可用？”
• “约束似乎是 Z。你同意吗？”

输出：设计文档

# [Feature Name] Design

## Problem Statement
What problem are we solving?

## Goals
- Goal 1
- Goal 2

## Non-Goals
- Explicitly out of scope item 1
- Explicitly out of scope item 2

## Proposed Solution
Overview of the approach

## Alternatives Considered
Why we didn't choose other approaches

## Technical Design
### Component A
...
### Component B
...

## Open Questions
- Question 1
- Question 2

## Next Steps
1. Step 1
2. Step 2

转向实现

设计获批后：

1. 询问：“准备好开始实现的准备工作了吗？”
2. 使用 using-git-worktrees 技能创建隔离的工作区
3. 使用 writing-plans 技能制定详细的实现计划

反模式

请勿这样做

• 设计尚未明确就开始编码
• 只提出一个方案
• 明明可以提出具体问题，却仍提出开放式问题
• 跳过对各部分的验证
• 假设需求已经完整
• 对初始设计过度工程化