Brainstorming Zh

---
name: brainstorming-zh
description: 需求头脑风暴、把想法谈成设计与 spec、动手写任何代码之前先澄清意图与约束、按探针式与有界与架构级三条路线定投入、方案批准前绝不开写。当用户说「我想做个功能」「帮我理一下这个想法」「这个需求该怎么设计」「先别写代码，我们先聊方案」「能不能实现」「给我几个方案比比」「写份设计文档」时使用。硬门禁是在你说明打算怎么做、并拿到用户认可之前，不得调用任何实现类技能、不得写代码、不得搭脚手架。三条路线：探针式只回答可行性、产出是结论不是要留的代码；有界改动问关键问题后在对话里给一段短设计、批准后直接实现、不写计划文档；架构级走完整流程——探索现状、逐条提问、给 2 到 3 个方案对比、分节呈现设计、写 spec、自查、请用户复核、再进入写实施计划。拿不准就走更重的那条，中途发现复杂度只升不降。
author: Captain
version: 0.1.0
display_name: "需求头脑风暴与设计"
display_name_en: "Brainstorming Ideas Into Designs (zh)"
description_zh: "动手前把想法谈成设计：先按探针式/有界/架构级分级，再逐条提问、给方案对比、分节确认设计、写 spec 并自查；任何路线都必须先拿到用户批准才能实现。"
description_en: "Turn an idea into a design before any code: classify as spike, bounded, or architectural, ask one question at a time, offer trade-offs, present the design in sections, write and self-review the spec, and never implement before approval."
examples_zh:
  - "我想做个功能，帮我理一下这个想法"
  - "先别写代码，我们先聊方案"
  - "给我几个方案比比，然后写份设计文档"
examples_en:
  - "I have an idea, help me turn it into a design"
  - "Do not write code yet, let us agree on the approach first"
  - "Give me two or three approaches with trade-offs"
metadata:
  { "openclaw": { "requires": { "bins": [] }, "os": ["darwin", "linux", "windows"], "emoji": "💡" } }
---

# 需求头脑风暴与设计

通过自然的协作式对话，把想法谈成成形的设计与 spec。

先给请求定级（决定这次要投入多少流程），再沿着对应的路线走：理解上下文 → 打磨想法 → 呈现设计 → 拿到用户批准。

> **硬门禁**
>
> 在你说明打算怎么做、并且用户认可之前，**不得**调用任何实现类技能、**不得**写代码、**不得**搭脚手架、**不得**采取任何实现动作。
> 这条对下面**每一条路线上的每一个任务**都成立：仪式感随任务大小缩放，**批准这道门永远不缩放**。

## 何时用

任何创造性工作之前——新建功能、搭组件、加能力、改行为——都先用它。用户已经明确给出完整设计、或只是问一个事实性问题时，不用。

## 三条路线

**在你问第一个问题之前**，先给请求定级并**把定级说出来**（「这看起来是有界改动，所以我直接在对话里给一段短设计，不写 spec」），好让用户能推翻你：

- **探针式（Spike）** —— 可行性问题（「能不能……」「有没有可能……」「糙一点也行」），产出是**一个答案**，不是要留下的代码。用 2 到 3 句话说明问题和你打算怎么试，得到点头后，用不损害正确性的最低成本去试。不写设计文档，不写 spec 文件。以建议的形式汇报结论；试出来的东西一律标注为一次性产物。
- **有界（Bounded）** —— 对**本仓库里已经存在的代码**做范围明确的改动：加个开关、加个小接口、改一个文件。只知道这是个什么类型的应用**不算**有界——有界的意思是**你要改的那条流程已经在这儿、可以读**。没有现成流程可改，这个任务就不是有界的。问那些真正要紧的澄清问题，**在对话里**给一段短设计（几句话到几小段），然后**停下**。用户对这段设计说「可以」之后才开始实现——有界任务的批准门和架构级一样硬。不写 spec 文件，不写实施计划文档。
- **架构级（Architectural）** —— 新项目、新子系统、会改变组件拼装方式或改动别人依赖的接口。走完整流程：提问 → 方案对比 → 分节设计 → 写 spec → 再进入编写实施计划技能。

**两条之间拿不准，走更重的那条。** 棘轮是单向的：中途发现隐藏复杂度就升级路线——停下来，说明，然后升。**任何情况下都不降级。**

## 反模式：「太简单了不用批准」

每条路线的终点都是用户批准你的意图。待办清单、一个工具函数、一次配置改动——设计也许就是对话里的两句话，但你**必须**说出来并拿到批准。「简单」任务恰恰是未经检验的假设造成最多无用功的地方。**随简单度缩放的是产物，永远不是批准。**

## 红线

| 你的念头 | 现实 |
|----------|------|
| 「这太简单了，不需要设计」 | 简单意味着设计很短，不是没有设计。对话里两句话，然后拿批准。 |
| 「就叫它有界，跳过 spec 吧」 | 为了跳过工作去够一个标签，这本身就是那份犹豫——走更重的那条。 |
| 「是有界的，设计也显而易见，我边讲边开写」 | 门禁是批准，不是设计的长度。讲完就停，等到「可以」为止。 |
| 「这类应用我懂，所以算有界」 | 有界衡量的是仓库，不是你的熟悉度。新项目没有现成流程，属于架构级。 |
| 「探针跑通了，代码留着吧」 | 探针的产出是答案。要留下代码是一个新请求——重新定级。 |
| 「做大了，但快完了，不用重新定级」 | 隐藏复杂度会升级路线。停下来，说出来。 |
| 「探针他们批了，那后续改动也算批过了」 | 每个任务各自定级，各自拿批准。 |

## 流程：按路线的清单

先定级、宣布路线，然后为你那条路线上的每一项建一个待办，按顺序完成。

**探针式：**

1. **探索项目现状** —— 够用来框定这次试探即可
2. **给出问题 + 试探方案** —— 2 到 3 句话
3. **拿批准** —— 点头即可
4. **动手查证** —— 用不损害正确性的最低成本
5. **汇报结论** —— 以建议形式；试出来的东西标注为一次性产物

**有界：**

1. **探索项目现状** —— 看文件、文档、近期提交
2. **提澄清问题** —— 一次一个，只问要紧的
3. **在对话里给短设计** —— 思路、会动哪些文件、怎么测
4. **拿批准** —— **停下来等一个明确的「可以」**；讲完设计顺手就开始，等于跳过门禁
5. **实现** —— 走正常研发流程（TDD 照常适用），不写计划文档

**架构级：**

1. **探索项目现状** —— 看文件、文档、近期提交
2. **按需提议可视化辅助** —— **不要一上来就提**，见下文
3. **提澄清问题** —— 一次一个，弄清目的、约束、成功标准
4. **给 2 到 3 个方案** —— 带取舍，并给出你的推荐
5. **呈现设计** —— 分节，每节篇幅随其复杂度缩放，**每节都拿一次用户确认**
6. **写设计文档** —— 存到 `docs/specs/YYYY-MM-DD-<主题>-design.md` 并提交
7. **Spec 自查** —— 就地检查占位符、自相矛盾、歧义、范围（见下文）
8. **用户复核 spec** —— 请用户看过写好的 spec 文件再往下
9. **转入实现** —— 调用「编写实施计划」技能（`writing-plans-zh`）生成实施计划

**终点状态是按路线绑定的。** 架构级：头脑风暴之后**唯一**可以调用的技能是编写实施计划——不是前端设计，不是任何其他实现类技能。有界：批准后直接走正常研发流程，不写计划文档。探针式：终点是一条汇报出来的建议。

## 具体做法

下面几小节服务有界与架构级两条路线（探针式停在「讲清试探方案、拿到点头」）。「探索方案」及其后各节属于架构级的深度——对有界工作来说，现状 + 几个问题 + 一段短设计就是全部流程。

**理解想法：**

- 先看项目当前状态（文件、文档、近期提交）。任何路线的第一步都是这个，别凭印象开口：

  ```bash
  ls -la && cat README.md 2>/dev/null | head -60
  git log --oneline -20
  git ls-files | head -80          # 看目录结构与命名约定
  rg -n "<跟这个需求相关的关键词>" --max-count 3   # 确认「要改的那条流程」是否已经存在
  ```

  最后一条尤其重要：**找不到现成流程，这个任务就不是有界的**。
- 在问细节之前先评估范围：如果这个请求描述的是多个彼此独立的子系统（比如「做一个带聊天、文件存储、计费和分析的平台」），**立刻指出来**。不要把提问额度花在一个本该先拆解的项目的细节上。
- 项目大到一份 spec 装不下，就帮用户拆成子项目：独立的部分有哪些、彼此什么关系、该按什么顺序建？然后按正常设计流程对**第一个**子项目做头脑风暴。每个子项目各走一轮 spec → 计划 → 实现。
- 范围合适的项目，**一次问一个问题**来打磨想法
- 能用选择题就用选择题，开放式也可以
- **每条消息只问一个问题**；一个话题需要展开就拆成多个问题
- 聚焦于理解：目的、约束、成功标准

**探索方案：**

- 提出 2 到 3 个不同方案，带取舍
- 用对话的方式呈现选项，并给出你的推荐与理由
- **先说你推荐的那个**，再解释为什么
- **无情地执行 YAGNI** —— 从每个方案和设计里删掉不必要的功能

**呈现设计：**

- 当你认为自己已经搞懂要建什么了，就把设计讲出来
- 每一节的篇幅随其复杂度缩放：直白的几句话，微妙的可以到两三百字
- **每讲完一节就问一句「到这儿看着对吗」**
- 覆盖：架构、组件、数据流、错误处理、测试
- 有讲不通的地方，随时准备退回去澄清

**为隔离与清晰而设计：**

- 把系统拆成更小的单元，每个只有一个明确目的、通过定义良好的接口通信、能被独立理解和测试
- 对每个单元你都应该答得出：它做什么、怎么用、依赖什么
- 别人不读内部实现，能明白这个单元干什么吗？你改内部实现，会不会弄坏调用方？答不上来说明边界还需要打磨
- 更小、边界更清楚的单元对你也更友好——一次能装进上下文的代码你推理得更好，文件聚焦时你的改动更可靠。文件变大，往往是它做得太多的信号。

**在既有代码库里工作：**

- 提改动之前先探索现有结构，**遵循既有模式**
- 既有代码里有影响本次工作的问题（文件过大、边界不清、职责纠缠），把**针对性**的改进作为设计的一部分——就像一个好开发者会顺手改善自己正在动的代码
- 不要提无关的重构，聚焦在服务当前目标的事情上

## 设计之后（架构级）

**文档：**

- 把确认过的设计（spec）写到 `docs/specs/YYYY-MM-DD-<主题>-design.md`（用户指定位置优先）
- 把设计文档提交进 git

**Spec 自查：** 写完之后用新鲜的眼睛再看一遍：

1. **占位符扫描：** 有「待定」「TODO」、没写完的小节、含糊的要求吗？改掉。
2. **内部一致性：** 有小节互相矛盾吗？架构和功能描述对得上吗？
3. **范围检查：** 这份 spec 聚焦到能对应一份实施计划了吗，还是需要继续拆？
4. **歧义检查：** 有哪条要求能被理解成两种意思？有就挑一种并写明确。

发现问题就地改掉，不用再审一轮。需要更强把关时，可以派评审子代理，模板见 `{baseDir}/references/spec-reviewer-prompt.md`。

**用户复核门：** 自查通过后，请用户复核写好的 spec 再往下：

> 「Spec 已写好并提交到 `<路径>`。请你看一下，在我们开始写实施计划之前，有什么要改的告诉我。」

等用户回应。要求修改就改，然后重跑一遍自查。**只有用户批准了才往下走。**

## 输出契约

- **探针式：** 一条带依据的建议 + 一次性产物的位置（明确标注为一次性）
- **有界：** 对话里的一段短设计（思路 / 会动的文件 / 怎么测）+ 用户的明确批准
- **架构级：** `docs/specs/YYYY-MM-DD-<主题>-design.md` 已提交 + 自查结论 + 用户复核通过 + 下一步移交编写实施计划

## 可视化辅助（可选）

如果你的平台有浏览器预览、画布或图片渲染能力，可以用它来展示原型图、示意图和可视化的方案对比。这是**一个工具，不是一种模式**。

**按需提议，不要一上来就提。** 等到某个问题**确实「看图比听描述更清楚」**时——是真正的原型图 / 布局 / 架构图问题，而不只是「话题跟 UI 有关」——第一次遇到时再提议，并且**单独发一条消息**：

> 「接下来这部分可能给你看更清楚——我可以把原型图、示意图和对比做成可视化的。要吗？」

**这条提议必须自成一条消息**，里面只有提议，不夹带澄清问题、总结或其他内容。等用户回应。用户拒绝就继续纯文本，除非他们自己再提起，否则不要再提。

**逐题判断：** 即使用户同意了，**每一个问题**都要单独判断用可视化还是用文字。判据是：**用户看图会不会比读文字理解得更好？**

- **用可视化**：内容本身就是视觉的——原型图、线框图、布局对比、架构图、并排的视觉方案
- **用文字**：内容是文字的——需求问题、概念选择、取舍清单、A/B/C/D 文字选项、范围决策

跟 UI 有关的话题**不等于**视觉问题。「这个场景下『个性化』指什么？」是概念问题，用文字；「这两种向导布局哪个更好？」是视觉问题，用图。

---
改编自 [obra/superpowers](https://github.com/obra/superpowers) 的 `brainstorming`（MIT）。改动见 ATTRIBUTION.md。