Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming

头脑风暴

Core Principle

核心原则

Design before code. Always.
Don't jump into implementation. Tease out the spec through conversation first.
先设计，再编码。务必遵循。
不要直接进入实现阶段。先通过沟通梳理清楚需求规格。

The Brainstorming Process

头脑风暴流程

Step 1: Understand the Goal

步骤1：明确目标

Ask clarifying questions:
  • What problem are we solving?
  • Who is the user?
  • What does success look like?
  • What are the constraints?
One question at a time - Don't overwhelm with multiple questions.
提出澄清问题：
  • 我们要解决什么问题？
  • 用户是谁？
  • 成功的标准是什么？
  • 有哪些约束条件？
一次只提一个问题 - 不要用多个问题让对方不知所措。

Step 2: Explore the Space

步骤2：探索方案空间

  • What are the possible approaches?
  • What are the trade-offs?
  • What similar problems exist?
  • What patterns apply?
  • 有哪些可行的方法？
  • 各方法的权衡是什么？
  • 存在哪些类似问题？
  • 可以应用哪些模式？

Step 3: Propose Alternatives

步骤3：提出备选方案

Always present 2-3 approaches before settling:
markdown
undefined
在确定最终方案前，务必提供2-3种方法：
markdown
undefined

Option A: [Name]

Option A: [Name]

  • Pros: ...
  • Cons: ...
  • Best when: ...
  • Pros: ...
  • Cons: ...
  • Best when: ...

Option B: [Name]

Option B: [Name]

  • Pros: ...
  • Cons: ...
  • Best when: ...
  • Pros: ...
  • Cons: ...
  • Best when: ...

Option C: [Name]

Option C: [Name]

  • Pros: ...
  • Cons: ...
  • Best when: ...
Recommendation: Option [X] because...
undefined
  • Pros: ...
  • Cons: ...
  • Best when: ...
Recommendation: Option [X] because...
undefined

Step 4: Incremental Validation

步骤4：渐进式验证

Present design in digestible chunks:
  • Show one section at a time
  • Get sign-off before moving on
  • Allow for course corrections
将设计拆分为易于理解的模块展示：
  • 一次展示一个部分
  • 获得确认后再进行下一步
  • 允许中途调整方向

Step 5: Document the Design

步骤5：记录设计文档

Save to: 
docs/plans/YYYY-MM-DD-<topic>-design.md
保存至：
docs/plans/YYYY-MM-DD-<topic>-design.md

YAGNI Ruthlessly

严格遵循YAGNI原则

During brainstorming, actively remove:
  • Features that "might be nice"
  • Edge cases that "could happen"
  • Abstractions for "future flexibility"
  • Optimizations for "scale we might need"
Ask: "Do we need this for the MVP?"
在头脑风暴过程中，主动剔除以下内容：
  • “可能有用”的功能
  • “也许会发生”的边缘情况
  • 为“未来灵活性”设计的抽象
  • 为“可能需要的规模”做的优化
提问：“我们的MVP需要这个吗？”

Question Techniques

提问技巧

Multiple Choice Preferred

优先使用选择题

Instead of: "How should we handle errors?" Ask: "For error handling, should we: A) Return error codes, B) Throw exceptions, C) Use Result types?"
不要问：“我们应该如何处理错误？” 而是问：“对于错误处理，我们应该选择：A) 返回错误码，B) 抛出异常，C) 使用Result类型？”

Constrained Questions

限定范围的问题

Instead of: "What should the API look like?" Ask: "Should this be REST, GraphQL, or RPC?"
不要问：“API应该是什么样的？” 而是问：“这个应该用REST、GraphQL还是RPC？”

Assumption Surfacing

明确假设

  • "I'm assuming X. Is that correct?"
  • "This depends on Y. Is that available?"
  • "The constraint seems to be Z. Agreed?"
  • “我假设X成立，对吗？”
  • “这取决于Y是否可用，Y目前可用吗？”
  • “约束条件似乎是Z，大家同意吗？”

Output: Design Document

输出：设计文档

markdown
undefined
markdown
undefined

[Feature Name] Design

[Feature Name] Design

Problem Statement

Problem Statement

What problem are we solving?
What problem are we solving?

Goals

Goals

  • Goal 1
  • Goal 2
  • Goal 1
  • Goal 2

Non-Goals

Non-Goals

  • Explicitly out of scope item 1
  • Explicitly out of scope item 2
  • Explicitly out of scope item 1
  • Explicitly out of scope item 2

Proposed Solution

Proposed Solution

Overview of the approach
Overview of the approach

Alternatives Considered

Alternatives Considered

Why we didn't choose other approaches
Why we didn't choose other approaches

Technical Design

Technical Design

Component A

Component A

...
...

Component B

Component B

...
...

Open Questions

Open Questions

  • Question 1
  • Question 2
  • Question 1
  • Question 2

Next Steps

Next Steps

  1. Step 1
  2. Step 2
undefined
  1. Step 1
  2. Step 2
undefined

Transition to Implementation

过渡到实现阶段

After design is approved:
  1. Ask: "Ready to set up for implementation?"
  2. Use 
    using-git-worktrees
    skill to create isolated workspace
  3. Use 
    writing-plans
    skill to create detailed implementation plan
设计方案获批后：
  1. 询问：“是否准备好进入实现阶段的环境搭建？”
  2. 使用
    using-git-worktrees
    技能创建独立工作区
  3. 使用
    writing-plans
    技能创建详细的实现计划

Anti-Patterns

反模式

Don't Do This

切勿这样做

  • Start coding before design is clear
  • Present only one option
  • Ask open-ended questions when specific ones work
  • Skip validation of each section
  • Assume requirements are complete
  • Over-engineer the initial design
  • 在设计明确前就开始编码
  • 只提供一种选项
  • 当可以用具体问题时却问开放式问题
  • 跳过对每个部分的验证
  • 假设需求已经完整
  • 过度设计初始方案