Back to Details

brainstorming

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Brainstorming Ideas Into Designs

将头脑风暴想法转化为设计

Overview

概述

Help turn rough ideas into fully formed designs through collaborative dialogue. Don't jump to solutions - explore the problem space first.
Core principle: Understand what to build BEFORE designing how to build it.
Violating the letter of this process is violating the spirit of brainstorming.
通过协作对话帮助将粗略想法转化为完整设计。不要直接跳到解决方案——先探索问题领域。
核心原则： 在设计如何构建之前，先明确要构建什么。
违反此流程的字面要求即违反头脑风暴的核心精神。

The Iron Law

铁律

NO DESIGN WITHOUT UNDERSTANDING PURPOSE AND CONSTRAINTS
If you can't articulate why the user needs this and what success looks like, you're not ready to design.
NO DESIGN WITHOUT UNDERSTANDING PURPOSE AND CONSTRAINTS
如果你无法明确用户为什么需要这个功能以及成功的标准是什么，说明你还没准备好开始设计。

When to Use

适用场景

ALWAYS before:
  • Creating new features
  • Building new components
  • Adding new functionality
  • Modifying existing behavior
  • Making architectural decisions
Signs you need to brainstorm:
  • Requirements feel vague
  • Multiple approaches seem valid
  • Success criteria unclear
  • User intent ambiguous
以下场景前必须使用：
  • 创建新功能
  • 构建新组件
  • 添加新功能
  • 修改现有行为
  • 制定架构决策
需要进行头脑风暴的迹象：
  • 需求模糊
  • 存在多种可行方案
  • 成功标准不明确
  • 用户意图不清晰

Spec File Workflow (Optional)

规格文件工作流（可选）

If user references a spec file (SPEC.md, spec.md, plan.md):
  1. Read existing spec - Use as interview foundation
  2. Interview to expand - Fill gaps using Phase 2 questions
  3. Write back - Save expanded design to same file
undefined
如果用户提及规格文件（SPEC.md、spec.md、plan.md）：
  1. 阅读现有规格 - 作为访谈基础
  2. 访谈以补充内容 - 使用第二阶段的问题填补空白
  3. 回写内容 - 将补充后的设计保存到同一文件
undefined

Check for existing spec (permission-free)

检查现有规格文件（无需权限）

Read(file_path="SPEC.md") # or spec.md if that doesn't exist
undefined
Read(file_path="SPEC.md") # 如果不存在则尝试spec.md
undefined

The Process

流程步骤

Phase 1: Understand Context

第一阶段：理解上下文

Before asking questions:
  1. Check project state (files, docs, recent commits)
  2. Understand what exists
  3. Identify relevant patterns
undefined
提问前需完成：
  1. 检查项目状态（文件、文档、最近提交记录）
  2. 了解现有内容
  3. 识别相关模式
undefined

Check recent context (permission-free)

检查最近上下文（无需权限）

Bash(command="git log --oneline -10") Bash(command="ls -la src/") # or relevant directory
undefined
Bash(command="git log --oneline -10") Bash(command="ls -la src/") # 或相关目录
undefined

Phase 2: Explore the Idea (One Question at a Time)

第二阶段：探索想法（一次一个问题）

Use 
AskUserQuestion
tool - provides multiple choice options, better UX than text questions.
Ask questions sequentially, not all at once.
Question 1: Purpose
"What problem does this solve for users?"
Options format:
A. [Specific use case 1] B. [Specific use case 2] C. Something else (please describe)
Question 2: Users
"Who will use this feature?"
Question 3: Success Criteria
"How will we know this works well?"
Question 4: Constraints
"What limitations or requirements exist?" (Performance, security, compatibility, timeline)
Question 5: Scope
"What's explicitly OUT of scope for this?"
使用
AskUserQuestion
工具 - 提供多选选项，比文本问题的用户体验更好。
按顺序提问，不要一次性全部抛出。
问题1：目的
"这能为用户解决什么问题？"
选项格式：
A. [具体用例1] B. [具体用例2] C. 其他（请描述）
问题2：用户群体
"谁会使用这个功能？"
问题3：成功标准
"我们如何判断这个功能效果良好？"
问题4：约束条件
"存在哪些限制或要求？" （性能、安全、兼容性、时间线）
问题5：范围界定
"明确不属于本次范围的内容是什么？"

Phase 3: Explore Approaches

第三阶段：探索实现方案

Always present 2-3 options with trade-offs:
markdown
undefined
必须提供2-3个带有权衡分析的选项：
markdown
undefined

Approaches

实现方案

Option A: [Name] (Recommended)

方案A：[名称]（推荐）

Approach: [Brief description] Pros: [Benefits] Cons: [Drawbacks] Why recommended: [Reasoning]
思路：[简要描述] 优点：[优势] 缺点：[不足] 推荐理由：[论证]

Option B: [Name]

方案B：[名称]

Approach: [Brief description] Pros: [Benefits] Cons: [Drawbacks]
思路：[简要描述] 优点：[优势] 缺点：[不足]

Option C: [Name]

方案C：[名称]

Approach: [Brief description] Pros: [Benefits] Cons: [Drawbacks]
Which direction feels right?
undefined
思路：[简要描述] 优点：[优势] 缺点：[不足]
哪个方向更合适？
undefined

Phase 4: Present Design Incrementally

第四阶段：逐步呈现设计

Once approach chosen, present design in sections (200-300 words each):
  1. Architecture Overview - High-level structure
    "Does this architecture make sense so far?"
  2. Components - Key pieces
    "Do these components cover what you need?"
  3. Data Flow - How data moves
    "Does this data flow work for your use case?"
  4. Error Handling - What can go wrong
    "Are these error cases covered?"
  5. Testing Strategy - How to verify
    "Does this testing approach give you confidence?"
After each section, ask if it looks right before continuing.
选定方案后，分部分呈现设计（每部分200-300字）：
  1. 架构概述 - 高层结构
    "目前这个架构逻辑合理吗？"
  2. 组件说明 - 核心模块
    "这些组件是否覆盖了你的需求？"
  3. 数据流 - 数据流转方式
    "这个数据流是否符合你的使用场景？"
  4. 错误处理 - 可能出现的问题
    "这些错误场景是否都已覆盖？"
  5. 测试策略 - 验证方法
    "这个测试方案能让你放心吗？"
每部分呈现后，先确认没问题再继续下一部分。

Key Principles

核心原则

One Question at a Time

一次一个问题

✅ "What problem does this solve?"
   [Wait for answer]
   "Who will use it?"
   [Wait for answer]

❌ "What problem does this solve, who will use it,
    what are the constraints, and what's the success criteria?"
✅ "这能解决什么问题？"
   [等待回答]
   "谁会使用它？"
   [等待回答]

❌ "这能解决什么问题、谁会使用它、有哪些约束条件、成功标准是什么？"

Multiple Choice Preferred

优先使用多选形式

✅ "Which approach fits better?
    A. Simple file-based storage
    B. Database with caching
    C. External service integration"

❌ "How do you want to handle storage?"
✅ "哪种方案更合适？
    A. 简单的基于文件的存储
    B. 带缓存的数据库
    C. 外部服务集成"

❌ "你想如何处理存储？"

YAGNI Ruthlessly

严格遵循YAGNI原则（You Aren't Gonna Need It）

✅ "You mentioned analytics - is that needed for v1
    or can we defer it?"

❌ Adding analytics, caching, and multi-tenancy
   because "we might need them later"
✅ "你提到了分析功能——这是v1版本必需的，还是可以延后？"

❌ 因为"以后可能需要"就添加分析、缓存和多租户功能

Explore Alternatives

探索替代方案

✅ Presenting 3 approaches with trade-offs
   before asking which to pursue

❌ Jumping straight to your preferred solution
✅ 先呈现3个带有权衡分析的方案，再询问选择哪个

❌ 直接跳到你偏好的解决方案

Incremental Validation

逐步验证

✅ "Here's the data model [200 words].
    Does this match your mental model?"

❌ Presenting the entire design in one 2000-word block
✅ "这是数据模型[200字]。
    这和你预想的模型一致吗？"

❌ 一次性呈现2000字的完整设计文档

Red Flags - STOP and Ask More Questions

危险信号 - 停止并补充提问

If you find yourself:
  • Designing without knowing the purpose
  • Jumping to implementation details
  • Presenting one approach without alternatives
  • Asking multiple questions at once
  • Assuming you know what the user wants
  • Not validating incrementally
STOP. Go back to Phase 2.
如果你发现自己：
  • 不知道目的就开始设计
  • 直接跳到实现细节
  • 只呈现一种方案而不提供替代选项
  • 一次性提出多个问题
  • 假设自己知道用户需求
  • 没有逐步验证
立即停止。回到第二阶段。

Rationalization Prevention

避免自我合理化

ExcuseReality
"I know what they need"Ask. You might be wrong.
"Multiple questions is faster"Overwhelms. One at a time.
"One approach is obviously best"Present options. Let them choose.
"They'll say if it's wrong"Validate incrementally. Don't assume.
"Details can wait"Get details now. Assumptions cause rework.
借口现实
"我知道他们需要什么"提问确认。你可能错了。
"一次性问多个问题更快"会让用户不知所措。一次一个问题。
"显然有一种最佳方案"呈现选项，让用户选择。
"如果错了他们会说的"逐步验证。不要假设。
"细节可以之后再处理"现在就明确细节。假设会导致返工。

Output: Design Document

输出：设计文档

After brainstorming, save the validated design:
markdown
undefined
头脑风暴完成后，保存经过验证的设计：
markdown
undefined

[Feature Name] Design

[功能名称] 设计文档

Purpose

目的

[What problem this solves]
[解决的问题]

Users

用户群体

[Who will use this]
[使用人群]

Success Criteria

成功标准

  • [Criterion 1]
  • [Criterion 2]
  • [标准1]
  • [标准2]

Constraints

约束条件

  • [Constraint 1]
  • [Constraint 2]
  • [约束1]
  • [约束2]

Out of Scope

排除范围

  • [Explicitly excluded 1]
  • [Explicitly excluded 2]
  • [明确排除的内容1]
  • [明确排除的内容2]

Approach Chosen

选定方案

[Which option and why]
[选项及理由]

Architecture

架构设计

[High-level structure]
[高层结构]

Components

组件说明

[Key pieces]
[核心模块]

Data Flow

数据流

[How data moves]
[数据流转方式]

Error Handling

错误处理

[What can go wrong and how handled]
[可能的问题及处理方式]

Testing Strategy

测试策略

[How to verify]
[验证方法]

Observability (if applicable)

可观测性（如适用）

  • Logging: [what to log]
  • Metrics: [what to track]
  • Alerts: [when to alert]
  • 日志：[需要记录的内容]
  • 指标：[需要追踪的内容]
  • 告警：[触发告警的条件]

UI Mockup (if applicable)

UI原型（如适用）

[ASCII mockup for UI features]
[UI功能的ASCII原型]

Questions Resolved

已解决的问题

  • Q: [Question asked] A: [Answer given]
undefined
  • 问：[提出的问题] 答：[对应的回答]
undefined

UI Mockup (For UI Features Only)

UI原型（仅针对UI功能）

For UI features, include ASCII mockup in the design:
┌─────────────────────────────────────────┐
│  [Component Name]                       │
├─────────────────────────────────────────┤
│  [Header/Navigation]                    │
├─────────────────────────────────────────┤
│                                         │
│  [Main content area]                    │
│                                         │
│  [Input fields, buttons, etc.]          │
│                                         │
├─────────────────────────────────────────┤
│  [Footer/Actions]                       │
└─────────────────────────────────────────┘
Skip this for API-only or backend features.
对于UI功能，在设计文档中包含ASCII原型：
┌─────────────────────────────────────────┐
│  [组件名称]                             │
├─────────────────────────────────────────┤
│  [头部/导航]                            │
├─────────────────────────────────────────┤
│                                         │
│  [主内容区域]                            │
│                                         │
│  [输入框、按钮等]                        │
│                                         │
├─────────────────────────────────────────┤
│  [底部/操作区]                           │
└─────────────────────────────────────────┘
纯API或后端功能可跳过此部分。

Saving the Design (MANDATORY)

保存设计文档（强制要求）

Two saves are required - design file AND memory update:
需要完成两次保存——设计文件和内存更新：

Step 1: Save Design File (Use Write tool - NO PERMISSION NEEDED)

步骤1：保存设计文件（使用Write工具 - 无需权限）

undefined
undefined

First create directory

先创建目录

Bash(command="mkdir -p docs/plans")
Bash(command="mkdir -p docs/plans")

Then save design using Write tool (permission-free)

然后使用Write工具保存设计（无需权限）

Write(file_path="docs/plans/YYYY-MM-DD-<feature>-design.md", content="[full design content from template above]")
Write(file_path="docs/plans/YYYY-MM-DD-<feature>-design.md", content="[上述模板的完整设计内容]")

Do NOT auto-commit — let the user decide when to commit

不要自动提交——让用户决定何时提交

undefined
undefined

Step 2: Update Memory (CRITICAL - Links Design to Memory)

步骤2：更新内存（关键环节 - 将设计与内存关联）

Use Read-Edit-Verify with stable anchors:
undefined
使用带稳定锚点的Read-Edit-Verify流程：
undefined

Step 1: READ

步骤1：读取

Read(file_path=".claude/cc10x/activeContext.md")
Read(file_path=".claude/cc10x/activeContext.md")

Step 2: VERIFY anchors exist (## References, ## Recent Changes, ## Next Steps)

步骤2：验证锚点是否存在（## References、## Recent Changes、## Next Steps）

Step 3: EDIT using stable anchors

步骤3：使用稳定锚点编辑

Add design to References

将设计添加到References

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## References", new_string="## References\n- Design: 
docs/plans/YYYY-MM-DD-<feature>-design.md
")
Edit(file_path=".claude/cc10x/activeContext.md", old_string="## References", new_string="## References\n- Design: 
docs/plans/YYYY-MM-DD-<feature>-design.md
")

Index the design creation in Recent Changes

在Recent Changes中记录设计创建

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Recent Changes", new_string="## Recent Changes\n- Design saved: docs/plans/YYYY-MM-DD-<feature>-design.md")
Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Recent Changes", new_string="## Recent Changes\n- Design saved: docs/plans/YYYY-MM-DD-<feature>-design.md")

Make the next step explicit

明确下一步任务

Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Next Steps", new_string="## Next Steps\n1. Decide: plan vs build (design at docs/plans/YYYY-MM-DD-<feature>-design.md)")
Edit(file_path=".claude/cc10x/activeContext.md", old_string="## Next Steps", new_string="## Next Steps\n1. 决策：规划还是开发（设计文档路径：docs/plans/YYYY-MM-DD-<feature>-design.md）")

Step 4: VERIFY (do not skip)

步骤4：验证（不可跳过）

Read(file_path=".claude/cc10x/activeContext.md")

**WHY BOTH:** Design files are artifacts. Memory is the index. Without memory update, next session won't know the design exists.

**This is non-negotiable.** Memory is the single source of truth.
Read(file_path=".claude/cc10x/activeContext.md")

**为什么需要两者：** 设计文件是工件。内存是索引。如果不更新内存，下一次会话将不知道该设计的存在。

**这是硬性要求。** 内存是唯一的事实来源。

After Brainstorming

头脑风暴结束后

Ask the user:
"Design captured. What's next?" A. Create implementation plan (use planning-patterns skill) B. Start building (use build workflow) C. Review and refine further
询问用户：
"设计已记录完成。下一步是什么？" A. 创建实施计划（使用planning-patterns技能） B. 开始开发（使用构建工作流） C. 进一步评审和优化

Final Check

最终检查

Before completing brainstorming:
  • Purpose clearly articulated
  • Users identified
  • Success criteria defined
  • Constraints documented
  • Out of scope explicit
  • Multiple approaches explored
  • Design validated incrementally
  • Document saved
完成头脑风暴前，请确认：
  • 目的已明确阐述
  • 用户群体已确定
  • 成功标准已定义
  • 约束条件已记录
  • 排除范围已明确
  • 已探索多种替代方案
  • 设计已逐步验证
  • 文档已保存