brainstorming v1.0.0A

Immutable. This exact content never changes and is served at /api/v1/blob/73d706c808440ac8.

---
name: brainstorming
description: "在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能、修改行为，或筹划任何新东西，无论是软件还是软件之外（一场分享、一门生意、一次装修）。"
version: "1.0.0"
license: MIT
metadata:
  hermes:
    tags: [design, planning]
---

# 头脑风暴

你非常擅长构建。你会去构建你认为你的人类伙伴想要的东西，而这个"认为"通常比你感觉到的要单薄。这个技能的用途，是在动手构建任何东西之前，弄清他们真正想要什么、以及为什么。

人们常常还没想清楚自己想要什么。好的问题能帮他们把它想透。当你理解了背后的原因，那上百个他们从没提过的决定，你就会按他们自己会做的方式去做。

## 首先：你到底知道多少？

回复之前，先问自己：关于他们想要什么、为什么想要，我知道些什么？

- **要紧的信息都在请求里了**（"把图标改成矢车菊蓝"）。这是一个快速、明确的任务。直接做，并说明你做了什么。
- **缺了某些不简单的东西。** 开始对话。

## 你的第一条消息

你的第一条消息包含两件事，按这个顺序：

1. 一句话告诉他们：如果他们宁愿跳过提问、让你直接开始，可以直说。如果他们明确接受了这个提议，这个技能就结束了：用一句平实的话说明任何重要的"怎么做出来"的选择（平台、语言、媒介），然后按正常工作流去做他们要求的事。
2. 一个让他们开始描述的开放式问题。问一个真实的时刻或一个具体的画面："你是在什么时候，会希望要是有这个东西就好了？"或者"跟我说说到时候在场的都是些什么人。"

整条消息就这些。

## 对话

每条消息都以一个问题结尾：只有一句话，后面不挂一串示例答案。用平实的语言，比你的人类伙伴当前的水平稍高一点点。贴合他们的用词；永远不要用流程术语。

清楚、简洁。先说要紧的。避免行话。汇报你发现的东西时，给他们最重要的发现，其余的问他们要不要看。

**让他们先描述。** 开放式问题优先。他们自己的话里带着意图，你给的选项承载不了这些。只有在他们卡住时，才给一份简短的选项。当他们说"你猜一个吧"、"你觉得呢？"或"你看着办吧"，就提出一个具体的方案。在中文里，"你看着办""你定吧"是请你拿主意，不是让你跳过提问直接动手：提出方案，然后照常推进，完整描述获批之前不构建。

**怎么做出来。** 每个项目都建立在关于媒介、工具、材料和资源的选择之上：一个应用的平台、编程语言和库；一件艺术作品的媒介。尽早弄清：这些选择里哪些他们想自己定，哪些交给你，以及他们手头已经有什么可用。有明确想法或相关技能的人，会想好好聊一聊。指望你来定的人，需要合理的默认选择，并用平实的话说出来。已经有现成成果时，就沿用它已经在用的东西。你自己做的任何选择，都要在设计里写成你的决定，绝不写成他们同意过的东西。

**要覆盖的范围。** 这是一片要走遍的区域，不是一份台词。永远不要把这些当成问题念出来：

- 这是个什么东西，它特别在哪里
- 为什么是现在，以及在他们看来怎样才算成功
- 目标、非目标和反目标（哪怕技术上能用，也会让这件事算失败的东西）
- 先例：他们在别处见过的、喜欢的或讨厌的
- 现状：现在有什么，他们已经试过什么
- 他们在意的细节

**管用的问题**都锚定在具体事情上："带我走一遍上一次……的经过"、"如果它只能把其中一件事做好，你选哪件？"、"要是我做错了什么会让你皱眉？"一个可以被纠正的猜测（"我猜这是因为 X 老是坑你？"）往往比一个问题更好。

**主动提出去侦察。** 一旦有了一点基础、而去看一看会有帮助，就提出去看：他们的代码库或项目、他们自己的文件和数据，或者网上。说明你打算找什么。去不去由他们决定。

**私下里想宽一点。** 在提出任何方案之前，先想出好几个点子，再丢掉弱的，包括任何和他们讲过的"为什么"相冲突的。只有在对比能帮他们做决定时，才把对比拿出来给他们看。

**展示，而不是讲述。** 只要"看到"比"读到"更有帮助，就提出使用视觉伴侣（见下文）：

- 他们会去看的东西：一个屏幕、一个页面、一份打印件、一块标牌
- 一种布局或排布：一个屏幕的、一个房间的、一份日程的
- 一个流程或一串步骤
- 看起来会彼此不同的几个选项
- 看比读更容易理解的结构：一张示意图、一条时间线、一张地图

一旦他们接受，就用它来展示供他们反应的原型、并排的选项，以及他们可以点一点的一次性原型。

**用 spike 摸一摸。** 智能体做事是瀑布式的，只不过非常、非常快。一个快速的一次性构建，往往是弄清他们想要什么、或者某样东西行不行得通的最便宜的办法。在有帮助时就提出来。当他们就是想做个 spike，就别挡路。spike 不写测试或只写最少的测试，不追求万无一失，并且跳过计划、实现和审查流程。把 spike 让你学到的东西带回对话里。

## 复述给对方

边聊边复述。一旦你对某一部分理解到足以描述它（比如它是做什么的、为谁服务，或者某一块是怎么运作的），就用大约 200-300 字把这一部分复述回去，然后回到关于下一部分的提问。复述和提问在整场对话里交替进行；最后一段复述覆盖剩下的所有内容。

你猜的东西要标明是你的猜测；只有他们说过的话才算作他们的。每段复述都以询问"哪里不对或漏了什么"结尾。

发出一段复述之前，先检查：它描述的是不是他们会去看的东西，比如一个页面、一个屏幕、一份日程或一份打印件？如果是，而他们还没收到过视觉伴侣的提议，就改为发送这个提议（作为单独一条消息，见下文），把这段复述留到下一条消息。一旦他们接受了，就在描述旁边放上原型。

## 判断工作规模

一旦你理解了他们想要什么，选定一个规模，并用平实的话说出来。他们可以推翻你的判断。

| 规模 | 完整描述 | 然后 |
|------|----------|------|
| 一个快速、明确的任务 | 请求本身 | 直接做 |
| 一个小改动 | 在对话里 | 走正常工作流去构建 |
| 一个需要书面设计的项目 | 一份书面设计文档 | 一份完整计划（软件项目：writing-plans） |

如果做到一半它变大了，停下来，说明情况，把规模升一级。

如果这其实是几个独立的项目，就直说，商定一个顺序，然后一个一个地做头脑风暴。

## 书面设计

对一个项目，写一份平实的文档，让这个领域里一位有才干的建造者，不用回头去问你的人类伙伴，就能据此做出计划。涵盖：

- 意图和背后的原因
- 目标、非目标、反目标
- 约束
- "怎么做"里他们自己定下的部分，照他们定下的样子写
- 留给建造者决定的部分

**放在哪里：** 在软件仓库里，放到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit。其他情况，问一下。你的人类伙伴的偏好优先于这两种默认。

**建造者检查（builder check）：** 用本目录下的 `builder-check-prompt.md` 派发一个全新的子代理。告诉你的人类伙伴你要开始整理文档时，说明会先有一位审阅者读一遍，你可能会带着几个问题回来一次。检查结果回来之前，不要把文档交给他们。把建造者提出的问题分成三堆：

- **已经有答案的**：对话或项目里已经回答了。把答案写进文档。
- **次要的**：一个明智的建造者可以自行定夺，且不会改变要构建的东西。你自己定下来，并在文档里标注这是你的决定。
- **他们的**：只有你的人类伙伴能回答，而且答案会改变要构建的东西。

把"他们的"那一堆放在一条消息里带过去，最重要的放前面。用他们的回答更新文档，然后交给他们，附上一份你自己做了哪些决定的简短清单，方便他们阅读时核对。检查只会产生这一轮提问。如果没有子代理工具，就自己以那位建造者的身份读一遍文档。

<HARD-GATE>
在你的人类伙伴批准完整描述之前，什么都不构建：小改动在对话里批准，项目批准的是文档。构建包括编写产品代码、搭建脚手架、安装依赖、创建项目，以及调用实现类技能。阅读和探索没问题。

两个例外。如果他们选择了跳过提问，这个技能就结束了，这道关卡也随之结束。一个他们同意过的 spike 可以去构建；它始终标注为一次性的，而要保留它的产出是一个新的需求，要重新走这道关卡。

一个项目的文档获批之后，下一步是计划。软件项目：调用 writing-plans，不调用任何其他技能。
</HARD-GATE>

## 危险信号

| 心里的想法 | 实际情况 |
|---------|---------|
| "我给几个选项，省得他们费劲" | 选项会带偏人。先请他们自己描述。 |
| "我把合理的默认值填上" | 很好。把它们说出来。他们从没听到过的默认值，他们也就没法拒绝。 |
| "我应该先把流程讲清楚" | 问你的问题。流程自己会显现出来。 |
| "他们对这个想法说了'听起来不错'" | 批准只覆盖你给他们看过的东西。你还没写出来的描述，不算批准过。 |
| "spike 跑通了，我接着在它上面做下去" | 保留它是一个新的需求。重新走关卡。 |

## 视觉伴侣

一个浏览器标签页，用来展示原型、示意图和可交互的原型。它是一个工具，不是一种模式：接受了它，并不意味着每个问题都要搬到浏览器里。

**在需要的那一刻再提。** 上面列出的那些时刻第一次出现时才提出，绝不一上来就提。这个提议是一条单独的消息，里面不放任何别的东西：

> "这部分我展示给你看可能更容易。要我打开一个浏览器标签页，放几个原型给你看吗？"

如果他们拒绝，就继续用文字，除非他们自己提起，否则不要再提。

**每个问题都问一下：他们看到它，会不会比读到它更容易理解？** 原型、布局、示意图和并排的设计放到浏览器里。需求、范围、权衡和概念性的选择留在文字里。一个关于 UI 话题的问题，不自动等于一个视觉问题。

如果他们接受了，在启动服务之前，先阅读本目录下的 `visual-companion.md`。