brainstorming

将创意构思转化为设计

概述

头脑风暴通过结构化的协作对话，将模糊的想法转化为经过验证的设计。它弥合了“我想要 X”和可交付给规划技能的具体设计之间的差距。此增强版本集成了自我学习技能，基于已知的项目上下文进行构思，并避免重复询问已经回答过的问题。

开始时宣布：“我将使用头脑风暴技能来探索这个想法，并在实现之前创建一份设计。”

触发条件

• 用户描述了一个新功能想法或目标
• 用户询问“我们应该如何构建 X？”
• 创作工作需要在规划之前进行设计探索
• 调用了 /brainstorm 命令
• 需要将模糊需求转化为结构化设计

---

阶段 1：加载上下文

目标： 在向用户提问之前，加载所有已知的项目信息。

1. 检查记忆文件（project-context.md、learned-patterns.md、decisions-log.md），了解已知模式、技术栈和惯例
2. 阅读相关的现有代码、文档和近期提交
3. 查看 docs/plans/ 中与之相关的既有设计
4. 确定现有架构中的约束
5. 记录你已经知道的内容——不要再次询问用户你可以自行查明的信息

上下文来源优先级

来源	提取内容	优先级
记忆文件	技术栈、惯例、过往决策	最高
CLAUDE.md	项目结构、硬性门槛	高
现有代码	当前模式、架构	高
近期提交	开发方向	中
docs/plans/	先前的设计和决策	中

停止——在进入阶段 2 之前，不要继续：

• 已检查记忆文件
• 已探索相关代码库区域
• 能够概述你已了解的该领域信息

---

阶段 2：探索想法

目标： 通过有针对性、一次一个的问题了解用户意图。

1. 每条消息只问一个问题——绝不同时提出多个问题
2. 尽可能优先使用选择题
3. 重点了解目的、约束和成功标准
4. 基于阶段 1 加载的上下文进行提问——跳过已有答案的问题
5. 将模糊的回答转化为具体、可测试的标准

问题流程决策表

需要了解的内容	问题类型	示例
核心目的	开放式	“这解决了用户的什么问题？”
范围界限	选择题	“这应该处理：（A）仅已登录用户，（B）所有用户，（C）视角色而定？”
技术约束	是/否 + 后续问题	“这需要支持离线工作吗？”
优先级权衡	强制排序	“请为以下各项排序：速度、正确性、简洁性”
成功标准	可衡量目标	“‘正常运行’是什么样的？能否描述一下理想流程？”
非目标	明确排除项	“本次迭代明确不应构建什么？”

提问规则

规则	原因
每条消息只问一个问题	避免认知过载
优先使用选择题	回答更快，减少歧义
提问前先研究	尊重用户的时间
利用记忆	不要重复询问已知信息
结果应可测试	模糊的成功标准会导致模糊的设计

停止——在进入阶段 3 之前，不要继续：

• 了解核心目的及其服务对象
• 了解约束条件（技术、时间线、范围）
• 已确定成功标准和非目标
• 关于意图不再存在关键歧义

---

阶段 3：方案探索

目标： 提出 2-3 种各不相同的方案，说明各自的权衡，并给出明确建议。

对于每种方案，请提供：

部分	内容
名称	简短且具有描述性的标签
架构概要	2-3 句话
关键权衡	优点和缺点
复杂度	低 / 中 / 高
风险	可能出现的问题
你的评估	说明为什么推荐或不推荐该方案

方案比较模板

## Approach A: [Name] (Recommended)
**Summary:** [2-3 sentences]
**Pros:** [list]
**Cons:** [list]
**Complexity:** [Low/Medium/High]
**Risk:** [What could go wrong]
**Why recommended:** [1-2 sentences]

## Approach B: [Name]
...

## Approach C: [Name] (if needed)
...

首先介绍你推荐的方案，并说明为什么它最符合阶段 2 中讨论的约束。

停止 — 在进入阶段 4 之前，请勿继续：

• 至少提出 2 种方案
• 明确说明每种方案的权衡
• 给出明确建议
• 用户已表明要采用哪种方案

---

阶段 4：设计展示

目标： 按章节展示详细设计，逐步征求用户批准。

1. 根据复杂度，按逻辑章节展示设计
2. 每展示完一个章节后，询问目前看来是否合适
3. 根据反馈，准备返回并修改任何章节
4. 涵盖所有相关的设计维度

按复杂度划分的设计章节

复杂度	必需章节	可选章节
简单（1-3 项任务）	架构、组件	—
中等（4-10 项任务）	架构、组件、数据流、错误处理	测试策略
复杂（10 项以上任务）	架构、组件、数据流、错误处理、测试策略、性能、安全	迁移计划

章节展示顺序

1. 架构 — 高层结构和关键决策
2. 组件 — 包含哪些部分，以及它们之间的关系
3. 数据流 — 数据如何在系统中流动
4. 错误处理 — 可能出现的问题以及处理方式
5. 测试策略 — 如何验证正确性
6. 性能 — 仅在存在相关约束时讨论
7. 安全 — 仅在处理敏感数据或身份验证时讨论

每次只展示一个章节。等待用户确认后再继续。

停止 — 在进入阶段 5 之前，请勿继续：

• 已展示所有相关的设计章节
• 用户已批准每个章节（或已根据反馈完成修改）
• 完整设计连贯一致，并满足所有要求

---

阶段 5：文档编写与交接

目标： 保存设计并将任务交接给规划技能。

1. 将已验证的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
2. 提交设计文档
3. 更新自学习记忆：
   • memory/decisions-log.md — 记录已做出的架构决策
   • memory/learned-patterns.md — 记录讨论过的新约定
4. 调用 planning 技能，创建详细的实施计划

设计文档模板

# [Topic] Design Document

**Date:** YYYY-MM-DD
**Status:** Approved
**Approach:** [Which approach was chosen]

## Problem Statement
[What problem this solves and for whom]

## Design

### Architecture
[High-level structure]

### Components
[Key pieces and their relationships]

### Data Flow
[How data moves through the system]

### Error Handling
[What can go wrong and how it is handled]

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

## Non-Goals
- [What was explicitly excluded and why]

## Next Steps
Invoke planning skill to create implementation plan.

停止 — 完成以下事项后方可继续：

• 设计文档已保存到 docs/plans/
• 记忆文件已更新，记录新的决策和模式
• 用户已确认设计完整

---

反模式 / 常见错误

反模式	失败原因	正确做法
“这个项目太简单，不需要头脑风暴”	每个项目都需要设计，即使是简单项目	设计可以简短，但必须存在
“用户已经知道自己想要什么”	用户知道要做什么，而不知道如何做	通过不同方案探索如何实现
“我可以直接开始编码”	没有设计就开始写代码，从第一行起就会产生技术债	先设计，再编码
“我们没有时间头脑风暴”	我们没有时间因糟糕的假设而返工	头脑风暴可以避免代价高昂的返工
“需求已经很明确了”	需求不等于设计——你仍需探索不同方案	即使需求明确，也要探索取舍
一次问 5 个问题	会让用户应接不暇，得到的回答也很浅显	每条消息只问一个问题
跳过上下文加载	会重新询问已经知道的事情	先检查记忆文件
不提出备选方案	会过早认定第一个想法，错过更好的选择	始终提出 2-3 个方案
一次性展示完整设计	内容太多，不便评审，用户会草草浏览	按章节逐步展示并征求认可
不保存决策	未来的会话会重复讨论相同内容	更新记忆文件

---

防止自我合理化的守则

在展示设计并获得用户批准之前，严禁调用任何实现技能、编写代码、搭建项目骨架或采取任何实现行动。无论项目看起来多么简单，这一要求都适用。

如果你发现自己在想：

• “我先搭个项目骨架……”——不行。先做设计。
• “这个设计显而易见……”——那记录下来很快。去做。
• “用户似乎不耐烦了……”——糟糕的设计比头脑风暴更浪费时间。

---

集成点

技能	关系	时机
self-learning	上游——从记忆中提供项目上下文	阶段 1：加载上下文
planning	下游——接收已批准的设计	阶段 5：转入规划
task-decomposition	互补——将设计拆解为工作任务	当设计揭示复杂范围时
spec-writing	互补——可将设计整理为规范	需要正式规范时
verification-before-completion	下游——验证设计的完整性	声称设计已完成之前

---

具体示例

示例：简单功能头脑风暴

User: "I want to add dark mode to the app"

Phase 1: [Check memory — React app, Tailwind CSS, no current theme system]
Phase 2: "Should dark mode (A) follow system preference automatically,
          (B) be a manual toggle only, or (C) both with manual override?"
Phase 3: Approach A: CSS variables + Tailwind dark: prefix
         Approach B: Theme context provider with CSS-in-JS
         Recommend A — aligns with existing Tailwind usage
Phase 4: Section 1: Architecture — Tailwind dark mode with class strategy
         Section 2: Components — ThemeToggle component, layout wrapper
Phase 5: Save design doc, invoke planning skill

示例：转入规划

Design approved and saved to docs/plans/2026-03-15-dark-mode-design.md.
Updated memory/decisions-log.md with theme system decision.
Invoking planning skill to create implementation plan.

---

核心原则

• 一次只问一个问题——不要让用户应接不暇
• 优先采用选择题——更容易回答
• 严格遵循 YAGNI——移除不必要的功能
• 探索备选方案——始终提出 2-3 个方案
• 增量验证——分章节展示并获得认可
• 利用现有上下文——使用 self-learning 记忆，避免重复询问已知信息

---

技能类型

RIGID——严格遵循此流程。每个想法都要经过全部五个阶段。简单项目的设计可以简短，但必须在任何实现开始前记录并获得批准。