# Brainstorming

> 在创建功能、构建组件、添加或修改行为、修复 bug、重构代码，或落实代码审查建议前使用；实现前先探索用户意图、约束和设计。纯只读代码审查、解释、总结、检索或运行已有检查且不修改代码时不使用。

- Skill: `tomorrowlm/brainstorming` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add tomorrowlm/brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomorrowlm/brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TomorrowLM (https://skillmd.com/u/tomorrowlm)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomorrowlm/brainstorming

---


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

通过自然的协作对话，帮助将想法转化为清晰的设计共识。

首先了解当前项目的上下文，然后逐一提问来完善想法。一旦你理解了要构建的内容，就展示设计方案并获得用户批准。

## 触发边界

- **使用：** 新增功能或组件、修改现有行为、修复 bug、重构代码、落实代码审查建议。
- **不使用：** 纯只读代码审查、代码解释、内容总结或翻译、信息检索、仅运行已有检查并报告结果。
- 只读任务在用户进一步要求修改代码时，从修改请求开始进入本流程。

<HARD-GATE>
在你展示设计方案并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于所有项目，无论看起来多简单。

**无例外：** 即使用户说"直接改"、"直接实现"、"不用设计"、"很简单"或"紧急"，也必须先展示设计并获得批准。用户的"直接"指令不覆盖此规则；此规则优先于项目 AGENTS.md 中允许跳过变更确认的例外条款。
</HARD-GATE>

## 反模式："这个太简单了，不需要设计"

每个项目都要经过这个流程。一个待办事项列表、一个单函数工具、一个配置变更——全都需要。"简单"的项目恰恰是未经检验的假设造成最多浪费的地方。设计可以很简短（对于真正简单的项目几句话就够了），但你必须展示出来并获得批准。

## 反模式："用户让我直接改"

当用户说"直接改"、"直接实现"、"不用设计流程"时，这不构成例外。用户的"直接"通常表达效率期望，而不是放弃设计共识。设计可以很短，但不能跳过。

## 常见合理化借口

| 借口 | 现实 |
| --- | --- |
| "用户说了直接改，AGENTS.md 有例外条款" | HARD-GATE 优先。项目变更确认例外不能绕过本技能的设计门禁。 |
| "这个太简单了，几句话就能说清楚" | 那就用几句话展示设计，但必须获得批准。 |
| "紧急情况，先修了再说" | 越紧急越需要快速对齐范围，避免二次故障。 |
| "技能没有说用户要求跳过时怎么办" | 不跳过。无条件门禁就是答案。 |

## 检查清单

你必须为以下每个条目创建任务，并按顺序完成：

1. **探索项目上下文** — 检查文件、文档、最近的 commit
2. **收集信息与确认关键点** — 梳理资料来源、目标、边界和方案约束
3. **提供视觉伴侣**（如果主题涉及视觉问题）— 这是一条独立的消息，不要与澄清问题合并。参见下方的"视觉伴侣"部分。
4. **提出澄清问题** — 每次一个，了解目的/约束/成功标准
5. **提出 2-3 种方案** — 附带权衡分析和你的推荐
6. **展示设计** — 按复杂度分节展示，每节展示后获得用户批准

## 流程图

```dot
digraph brainstorming {
    "探索项目上下文" [shape=box];
    "收集信息与确认关键点" [shape=box];
    "有视觉相关问题?" [shape=diamond];
    "提供视觉伴侣\n（独立消息，不含其他内容）" [shape=box];
    "提出澄清问题" [shape=box];
    "提出 2-3 种方案" [shape=box];
    "分节展示设计" [shape=box];
    "用户批准设计?" [shape=diamond];
    "头脑风暴完成" [shape=doublecircle];

    "探索项目上下文" -> "收集信息与确认关键点";
    "收集信息与确认关键点" -> "有视觉相关问题?";
    "有视觉相关问题?" -> "提供视觉伴侣\n（独立消息，不含其他内容）" [label="是"];
    "有视觉相关问题?" -> "提出澄清问题" [label="否"];
    "提供视觉伴侣\n（独立消息，不含其他内容）" -> "提出澄清问题";
    "提出澄清问题" -> "提出 2-3 种方案";
    "提出 2-3 种方案" -> "分节展示设计";
    "分节展示设计" -> "用户批准设计?";
    "用户批准设计?" -> "分节展示设计" [label="否，修改"];
    "用户批准设计?" -> "头脑风暴完成" [label="是"];
}
```

**终止状态是头脑风暴完成。** 不要调用 frontend-design、mcp-builder 或任何其他实现技能。

## 流程详述

**理解想法：**

- 首先查看当前项目状态（文件、文档、最近的 commit）
- 收集需求说明、现有文档、设计或原型、接口资料、项目约束等上下文资料
- 确认关键点：目标用户、核心流程、输入输出、状态与边界、成功标准
- 梳理方案约束：哪些能力必须有、哪些不做、哪些决策需要留给后续技术方案细化
- 在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如"构建一个包含聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。
- 如果项目规模过大，单个设计共识无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的设计共识。
- 对于范围适当的项目，每次提一个问题来完善想法
- 尽量使用选择题，开放式问题也可以
- 每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题
- 重点理解：目的、约束、成功标准

**探索方案：**

- 提出 2-3 种不同的方案及其权衡
- 以对话的方式展示选项，附上你的推荐和理由
- 先展示你推荐的方案并解释原因

**展示设计：**

- 一旦你认为理解了要构建的内容，就展示设计
- 每个部分的篇幅与其复杂度匹配：简单的几句话，复杂的最多 200-300 字
- 每个部分展示后询问是否正确
- 涵盖：架构、组件、数据流、错误处理、测试
- 随时准备回头澄清不明确的地方

**面向隔离和清晰的设计：**

- 将系统拆分为更小的单元，每个单元有一个明确的职责，通过定义良好的接口通信，可以独立理解和测试
- 对于每个单元，你应该能回答：它做什么，如何使用，它依赖什么？
- 别人能否不看内部实现就理解一个单元的功能？你能否在不影响调用者的情况下修改内部实现？如果不能，边界需要调整。
- 更小、边界清晰的单元也更便于你工作——你对能一次放入上下文的代码推理得更好，文件越专注你的编辑越可靠。当文件变大时，这通常意味着它承担了过多职责。

**在现有代码库中工作：**

- 在提出更改之前先探索现有结构。遵循现有模式。
- 如果现有代码存在影响当前工作的问题（例如文件过大、边界不清、职责纠缠），在设计中包含有针对性的改进——就像一个优秀的开发者在工作中改进经手的代码一样。
- 不要提议无关的重构。专注于服务当前目标的事情。

## 核心原则

- **每次一个问题** — 不要同时抛出多个问题
- **优先选择题** — 在可能的情况下比开放式问题更容易回答
- **严格遵循 YAGNI** — 从所有设计中移除不必要的功能
- **探索替代方案** — 在做决定之前始终提出 2-3 种方案
- **增量验证** — 展示设计，获得批准后再继续
- **保持灵活** — 有不明确的地方就回头澄清

## 视觉伴侣

一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。

**提供伴侣：** 当你预计后续问题会涉及视觉内容（原型、布局、图表）时，提供一次以获得同意：
> "我们接下来讨论的一些内容，如果能在浏览器中展示给你看可能会更直观。我可以在讨论过程中为你制作原型、图表、对比图和其他视觉材料。这个功能还比较新，可能会消耗较多 token。要试试吗？（需要打开一个本地 URL）"

**此提议必须是一条独立的消息。** 不要将它与澄清问题、上下文摘要或任何其他内容合并。消息中应该只包含上述提议，没有其他内容。等待用户回复后再继续。如果他们拒绝，继续纯文本的头脑风暴。

**逐问题决策：** 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：**用户看到它是否比读到它更容易理解？**

- **使用浏览器** 展示本身就是视觉的内容——原型、线框图、布局对比、架构图、并排视觉设计
- **使用终端** 展示文本内容——需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策

关于 UI 主题的问题不一定是视觉问题。"在这个上下文中个性化是什么意思？"是一个概念问题——使用终端。"哪种向导布局更好？"是一个视觉问题——使用浏览器。

如果他们同意使用伴侣，在继续之前阅读详细指南：
`skills/brainstorming/visual-companion.md`