brainstorming

头脑风暴

你非常擅长构建。你会构建你认为人类伙伴想要的东西，而这种判断通常比你感觉到的更不可靠。本技能用于在动手构建之前，弄清他们真正想要什么，以及为什么想要。

人们往往还没有想清楚自己要什么。好的问题能帮助他们理清思路。当你理解了"为什么"，那些他们从未提及的上百个决定，你就能按他们本会做出的方式来做。

首先：你究竟了解什么？

在回复之前，先问自己：关于他们想要什么、以及为什么，我了解多少？

• 所有关键信息都已包含在请求中（"把图标改成矢车菊蓝"）。这是一个简单明确的任务。直接完成，并说明你做了什么。
• 缺少某些重要信息。 开始对话。

你的第一条消息

你的第一条消息包含两部分，顺序如下：

1. 一行话，告诉他们：如果不想回答问题，只想让你直接开始，可以直接说明。如果对方选择这样做，本技能即结束：用一行简单的文字说明所有重要的实现方式选择（平台、语言、载体），然后通过常规工作流完成对方的请求。
2. 一个开放式问题，引导对方描述具体情况。例如："你在什么时刻会希望有这样一个东西？"或"说说会参与其中的人都是谁。"

整条消息就这些内容。

对话

每条消息都以一个问题结尾：一句话，后面不附带一列示例答案。用朴素的语言表达，比对方的理解水平略高一点。使用对方的词汇，不要使用流程术语。

保持清晰、简洁。先说最重要的内容。避免行话。汇报你的发现时，先给出最重要的结论，其余部分提供选项供对方选择。

让对方描述。 开放式问题优先。对方自己的措辞承载着他们的意图，这是你给出的选项无法替代的。只有当对方卡住时，才提供一个简短的选项菜单。当对方说“随便猜”或“你觉得呢？”时，就提出一个具体的方案。

如何落地。 每个项目都建立在媒介、工具、材料和资源的选择之上：应用的平台、编程语言和库；艺术作品的媒介。尽早弄清楚哪些选择由对方自己做，哪些交给你来定，以及他们已经有哪些可用的东西。对某个方面有强烈看法或技能的人，会希望把这些选择细致地讨论一遍。依赖你的人则需要合理的默认值，并用直白的语言说明。如果已有现成的工作成果，就沿用它已经在用的技术。你做出的任何选择，都要在设计中标注为你的决定，而不能写成对方已经同意的内容。

需要覆盖的范围。 这是一个范围，不是剧本。绝不要把下面这些内容逐条当作问题念出来：

• 这是一件什么样的事物，它的独特之处在哪里
• 为什么是现在，对他们而言成功是什么样子
• 目标、非目标，以及反目标（即使技术上行得通，什么会让它算作失败）
• 已有的参照：他们在别处见过什么，喜欢或讨厌什么
• 当前状态：现在已经存在什么，他们尝试过什么
• 他们在意的细节

有效的问题要锚定在具体情境中：“带我回顾一下上一次……的经历”，“如果它只能把其中一件事做好，你会选哪一件？”，“如果我做错了，什么会让你最难受？”。一个可以被对方纠正的猜测（“我猜这是因为 X 一直在困扰你？”）往往比提问更有效。

主动提议侦察。 当你已经有了一定的背景了解，而且实际查看会有帮助时，提议去看一看：他们的代码库或项目、他们自己的文件和数据，或者网络。说明你会查找什么。由他们决定要不要去。

私下多方思考。 在提出任何方案之前，先想出几种思路，并舍弃较弱的，包括那些与对方所说的初衷相冲突的思路。只有当比较结果有助于对方做决定时，才展示这种比较。

展示，而非告知。 只要看到比读到更有帮助，就提议使用可视化辅助（见下文）：

• 对方需要查看的东西：屏幕、页面、打印稿、标识牌
• 布局或排列方式：屏幕、房间、日程安排的布局
• 流程或步骤序列
• 彼此差异明显、需要对照的选项
• 更适合看而不是读的结构：图表、时间线、地图

一旦对方同意，就用它来制作可供对方评价的原型图、并排对比的选项，以及可以点击体验的快速原型。

通过试做摸清情况。 Agent 式工作本质上是瀑布式的，只是速度非常非常快。一个快速的一次性试做，往往是了解对方真正需要什么、或某个方案是否可行的最低成本方式。当试做有帮助时，就提议做一个。当对方只想试做时，就不要多加干预。试做不需要测试，或只需极少的测试，不追求稳健，也跳过规划、实现和评审流程。把试做学到的东西带回对话中。

边做边回放

边做边回放。每当你对某一部分理解得足够深，能够描述它（例如它的用途和服务对象，或某个部分的行为方式），就用约 200-300 字把该部分描述回去，然后再回到关于下一部分的问题。回放和提问在整个对话中交替进行，最后一块覆盖剩余的全部内容。

凡是你在猜测的内容，都要标明是你的猜测；只有对方说过的内容，才能作为对方的意见写入。每块结束时，询问哪里有误或遗漏。

发送一块内容之前，先检查：它是否描述了对方会去查看的东西，比如页面、界面、日程或打印稿？如果是，并且对方还没有看到可视化伴侣的提议，就改为发送该提议（作为单独一条消息，见下文），并把这一块保留到下一条消息。对方接受后，把原型图放在描述旁边。

评估工作量

理解对方的需求后，确定规模并用简单的话说明。对方可以覆盖这一判断。

规模	完整描述	之后
简单清晰的任务	请求本身	直接执行
小改动	在对话中	通过常规工作流构建
已有书面设计的项目	书面设计文档	完整计划（软件类：superpowers:writing-plans）

如果任务在执行中途变大，停下来说明这一点，并上调一个规模。

如果这实际上是几个相互独立的项目，就直接说明，商定顺序，然后逐个进行头脑风暴。

书面设计

对于项目，编写一份通俗的文档，使熟悉该领域的实施者无需回头询问你的人类搭档，就能据此制定计划。文档应涵盖：

• 意图与原因
• 目标、非目标、反目标
• 约束条件
• 你所做决定的实现思路，以及你当时是如何决定的
• 留给实施者自行决定的内容

存放位置： 在软件仓库中，放在 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，并提交到版本库。否则，请先询问。你的人类搭档的偏好优先于以上两者。

实施者检查： 使用本目录中的 builder-check-prompt.md 派发一个全新的子代理。告诉你的人类搭档你正在撰写文档时，说明会有一位审阅者先阅读，你之后可以回来一次，提出少量问题。在检查结果返回之前，不要交出文档。对实施者提出的问题进行三类分拣：

• 已有答案：对话或项目中已经给出答案的，把答案写入文档。
• 次要问题：一位通情达理的实施者无需改变最终构建内容即可自行判断的问题。由你自己决定，并在文档中标明这是你的判断。
• 需要对方决定：只有你的人类搭档能回答，且答案会改变最终构建内容的问题。

把“需要对方决定”这一类问题放在同一条消息中一并提出，按重要性从高到低排列。根据对方的回答更新文档，然后交付文档，并附上一份简短的清单，列出你所做的判断，方便对方在阅读时逐条核对。这是检查所产生的唯一一轮提问。若没有子代理工具，则由你自己以实施者的身份阅读文档。

在你的人类搭档批准完整描述之前，不得开始构建：小改动以对话为准，项目以文档为准。构建包括编写产品代码、搭建脚手架、安装依赖、创建项目以及调用实现技能。阅读和探索不受限制。

有两种例外。如果对方选择跳过提问，则该技能即告完成，此门禁也随之失效。对方同意的探索性原型可以构建；它必须标注为一次性；保留其产出属于新的请求，需要重新经过此门禁。

项目文档获批后，下一步是计划。软件项目请调用 superpowers:writing-plans，且不得调用其他技能。

危险信号

想法	实际情况
"我提供几个选项，省得他们费心"	选项会引导对方。应先请他们描述需求。
"我补上合理的默认值"	这样可以。但要说出来。对方从未听过的默认值，他们也就无从拒绝。
"我应该先解释流程"	直接提问。流程自然会显现。
"他们对这个想法说了'听起来不错'"	批准只涵盖你展示过的内容。你还没写出的描述，并不算获得批准。
"原型能跑，我就在它上面继续开发"	保留它就是一个新请求，需要重新走一遍审批关口。

视觉伴侣

一个用于展示原型图、示意图和原型的浏览器标签页。它是一种工具，而不是一种模式：接受它并不意味着所有问题都会发送到浏览器。

及时提出。 只有在上述某个时刻首次出现时才提出，绝不预先提出。该提议单独成一条消息，其中不包含其他内容：

"这件事如果我直接展示给你看，可能会更容易理解。要我打开一个浏览器标签页，给你看一些原型图吗？"

如果对方拒绝，就继续使用文字交流，除非对方再次提起，否则不要再次提出。

逐个问题判断：看到之后，对方会不会理解得更好？ 原型图、布局、示意图和并排的设计方案适合放在浏览器中。需求、范围、权衡取舍和概念性选择应保留在文字中。涉及 UI 的问题不一定就是视觉问题。

如果对方接受，请先阅读此目录中的 visual-companion.md 文件，然后再启动服务。