brainstorming

头脑风暴

你很擅长构建东西。你会按照自己认为人类搭档想要的样子去构建，而这种判断往往没有你以为的那么可靠。这项技能旨在弄清楚他们真正想要什么，以及为什么想要，在动手构建之前先把这些问题搞清楚。

人们往往还没想清楚自己想要什么。好的问题能帮助他们理清思路。当你明白了原因，就能替他们做出那些他们从未提及、却会按他们心意做出的上百个决定。

首先：你究竟了解什么？

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

• 请求中已经包含所有重要信息（“把图标设为矢车菊蓝”）。这是个简单明确的任务。完成它，并说明你做了什么。
• 缺少重要信息。 开始对话。

开始实现之前，你必须按顺序完成以下事项：

1. 在单独的一条消息中列出各种方案，让人类搭档选一个（参见“列出各种方案”）。
2. 编写设计文档，可以简短，也可以完整（参见“评估工作规模”）。
3. 征得他们对文档的认可。
4. 调用 superpowers:writing-plans 技能。

有两种情况不属于实现：他们同意的探索性实验（参见“通过探索性实验了解情况”），以及他们选择不回答问题后，按其要求行事。

先了解情况，再提问

在现有项目中，或对方提供了上下文（规范、计划、交接资料、他们指出的文件、之前的对话）时，请在发出第一条消息前先深入了解。阅读他们提到的内容，以及与之相关的代码或材料，并持续阅读，直到你能说明相关部分目前如何运作，以及这项改动会影响哪些部分。不要问项目或上下文中已经有答案的问题。

你的第一条消息

推动工作向前，并采用以下其中一种方式：

• 对方已经说明了想要什么（规范、计划、详细请求）：整条消息控制在约 200 字。用自己的话复述他们的请求，让他们确认你是否理解了整体意图：他们想要什么、面向谁，以及他们说明的目的。补充你发现的相关信息：相关部分目前如何运作，以及这项改动会影响哪些部分。如果你发现了他们可能没考虑到、会改变其需求或实现方式的因素，例如限制、冲突或更省事的做法，请直接说明。等你了解他们想要什么之后，再讨论如何构建（参见“列出各种方案”）。最后用一行邀请他们纠正你的理解，再提出一个关于他们想要什么的问题：他们的请求中尚未明确、且答案最可能改变构建结果的那个问题。规范往往并不完整，所以在此基础上继续之前，请先确认。
• 对方还没有说明： 用他们自己的说法，就请求中最大的不确定之处提出一个开放式问题。说明为什么要问：答案会如何改变你构建的东西。对于“给我的面包店做个网站”，可以这样问：“如果网站主要是让人决定要不要顺路来店里，我会把营业时间和今天在售的商品放在显眼位置；如果要接单，那就是另一种网站了。你希望访客打开网站后做什么？”

消息的结尾取决于对方是否要求进行头脑风暴：

• 他们要求了（明确提到、调用该技能，或要求讨论设计）：以问题结尾。他们想继续这段对话。
• 他们没有要求： 他们可能根本不想对话。在问题之后，再用一句轻松的话表示可以直接开始，例如：“或者，如果你想让我直接开始，也可以告诉我。”如果他们接受，你就完成这项技能：用一句简单的话说明任何重要的实现选择（平台、语言、形式），然后按常规工作流执行他们的要求。

第一条消息到此为止。

对话

每条消息最后只问一个问题：用一个完整的句子，不要附带一串示例答案。用简单的语言，难度只比你的人类搭档略高一点。沿用对方的词汇；绝不要使用流程术语。无需向人类搭档引用这项技能。

表达清晰、简洁。先说重点。避免术语。汇报发现时，先说最重要的发现，并表示可以提供其余内容。

引导对方描述。 先问开放式问题。对方自己的措辞能表达意图，而你的选项做不到。只有对方卡住时，才提供简短的选项列表。如果对方说“你就猜吧”或“你觉得呢？”，就提出一个具体方案。

如何实现。 每个项目都涉及对媒介、工具、材料和资源的选择：应用的平台、编程语言和库；艺术作品的媒介。尽早弄清楚哪些选择由对方决定，哪些交给你，以及对方已有的资源。有明确想法或技能的人会希望一起讨论。依赖你的人需要听到用直白语言说明的合理默认方案。已有项目时，应沿用它现有的技术。你做出的任何选择都要在设计中标明是你的决定，而不是对方同意的事项。

需要了解的方面。 这是一片需要探索的领域，不是照本宣科的问题清单。绝不要把以下内容逐条念成问题：

• 这是什么类型的事物，以及它的特别之处
• 为什么是现在，以及对方眼中的成功是什么样
• 目标、不在目标范围内的事项，以及否决条件（哪些情况即使技术上能正常运行，也会让项目失败）
• 先例：对方在别处见过什么，以及喜欢或讨厌什么
• 当前状况：现有内容，以及对方尝试过什么
• 对方关心的细节

让每个问题都切合具体项目以及对方已经告诉你的内容。像敏锐的同事那样通过提问引导思考：根据对方上一条回答或你发现的内容提出每个问题，帮助对方考虑后果或可能遗漏的情况（“投票会在会议前截止，而本月有两名成员加入。中途加入的人能参加本轮投票吗？”）。如果提问原因还不明显，就说明你想了解什么，或者答案会影响什么。提出一个对方可以纠正的方案，并说明理由，往往比直接提问更有效。

主动提出调查。 对项目有了些了解，并且进一步查看会有帮助时，可以提出去深入查看：对方的代码库或项目、自有文件和数据，或网络。说明你会查找什么。是否由你去查，由对方决定。

列出实现方案。 确认了解对方的需求后、撰写任何文档之前，用单独一条消息说明实现方式。提出几个切实可行的替代方案，并排除不理想的方案，包括与项目目标相悖的方案，以及现有工作条件不允许的方案。介绍剩下的两三个方案，结合项目的实际情况说明各自的取舍。推荐其中一个并说明理由，然后询问对方想采用哪种方案。如果确实只有一种合理方案，就说明这一点，并解释其他方案为何不合适。这适用于实现方式；对于对方想要什么，先让对方描述。

展示胜过讲述。 只要看比读更有帮助，就提出提供视觉辅助（见下文）：

• 对方会查看的东西：屏幕、页面、打印件、标牌
• 布局或安排：屏幕、房间、日程
• 流程或步骤顺序
• 外观各不相同的选项
• 看图比读文字更容易理解的结构：图表、时间线、地图

对方接受后，就用视觉辅助制作供其反馈的模型、并排展示的方案，以及可供点击体验的一次性原型。 先快速试做，摸清需求。 Agentic 工作流就像瀑布式流程，只是速度非常、非常快。快速搭建一个用完即弃的版本，往往是了解他们想要什么，或确认某件事能否奏效的最省钱方式。若有帮助，就提出这种做法。如果他们只是想快速试做，就不要妨碍他们。快速试做的版本不做测试或只做最少的测试，不追求万无一失，也跳过规划、实现和审查流程。把试做得到的经验带回对话中。

复述确认

边推进边复述确认。只要你对某个部分的理解足以描述它（比如它的用途和服务对象，或某个部分的行为方式），就用大约 200-300 个字复述该部分，然后继续询问下一个部分。整个对话中，复述和提问交替进行；最后一段涵盖剩余内容。

只有他们说过的内容才能作为他们的想法写进去。凡是你补充的内容，都要作为你的提议，并说明理由。每段结尾都要询问哪些地方不对或有所遗漏。

发送一段内容之前，先检查一下：它描述的是他们会查看的东西吗，比如页面、屏幕、日程安排或打印件？如果是，而且他们还没看到视觉辅助内容的提议，就先发送提议（单独一条消息，见下文），并将这段内容留到下一条消息。对方接受后，在描述旁附上模型图。

评估工作量

了解他们的需求并且他们选定方案后，用通俗的语言说明工作量有多大。他们可以调整评估。

规模	设计文档
小改动	简短文档：把你们已经讨论过的内容记录下来
项目	完整的书面设计文档（见下文）

无论简短还是完整，设计文档都要有 方案 部分：列出你考虑过的两到三种实现方式、各自的取舍、他们选择了哪一种，以及原因。要先在对话中由他们选定方案，然后再编写文档。

如果任务中途变大，就停下来说明情况，并提高规模级别。

如果这实际上是几个彼此独立的项目，就说明情况、商定顺序，然后一次讨论一个项目。

书面设计

撰写一份纯文档，让该领域的优秀开发者无需再向你的人类搭档请教，就能据此规划实现。涵盖：

• 意图和原因
• 目标、非目标、反目标
• 约束
• 方案（见上文）
• 已决定的实现细节，以及决定的过程
• 留给开发者的事项

对于小型改动，简短设计也要涵盖相同要点，每点用一两行说明，然后直接交给你的人类搭档，不需要经过开发者检查。

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

开发者检查（针对项目）：使用此目录中的 builder-check-prompt.md，调度一个全新的子 Agent。告诉你的人类搭档你正在撰写设计文档时，说明会有一位审阅者先行阅读，你可能会回来集中询问几个问题。检查结果返回前，不要交出文档。将开发者提出的问题分为三类：

• **已有答案：**对话或项目中已有答案。将答案写入文档。
• **次要问题：**合理的开发者无需改变最终构建内容，就能自行决定。由你自行处理，并在文档中注明这是你的决定。
• **需要人类搭档决定：**只有你的人类搭档才能回答，且答案会改变最终构建内容。

用一条消息列出“需要人类搭档决定”的问题，并按重要性排序。根据对方的答案更新文档，然后交出文档，并简要列出你做出的决定，方便对方阅读时核查。这是检查过程中唯一一轮提问。如果没有子 Agent 工具，就由你自己以开发者的身份阅读文档。

未经你的人类搭档批准设计文档，不得开始任何构建工作：小型改动须批准简短设计，项目须批准完整设计。构建工作包括编写产品代码、搭建脚手架、安装依赖、创建项目，以及调用实现技能。 阅读和探索不受限制。

有两个例外。如果对方选择不回答问题，则此技能到此结束，审批关卡也随之结束。对方同意的试验性验证可以进行；但必须标记为临时代码，若要保留其产出，则属于新的请求，须重新通过此审批关卡。

设计文档获批后，下一步是制定计划：调用 superpowers:writing-plans，且不得调用其他技能。

警示信号

想法	实际情况
“我来列出他们可能想要的选项”	选项会引导对方。先请他们描述需求。
“我来填入合理的默认值”	可以。但要明确说出来。对方从未听说过的默认值，自然也无法拒绝。
“我已经回答了他们的问题，所以现在可以写文档了”	先在单独的一条消息中列出方案。
“我应该先解释流程”	直接提问。流程会自然展开。
“他们说这个想法‘听起来不错’”	批准只涵盖你展示过的内容。尚未写出的设计文档并未获批。
“试验性验证已经通过，我就继续在此基础上构建”	保留试验成果属于新的请求，须重新通过审批关卡。

视觉辅助

一个用于展示模型图、示意图和原型的浏览器标签页。它是一种工具，而非一种模式：接受使用它，并不意味着每个问题都要转到浏览器中讨论。

**在恰当时机提出。**只有首次出现上述情形之一时才提出，切勿一开始就提。提出时单独发送一条消息，不包含其他内容：

“如果能给你看看，可能会更容易理解。要我打开一个浏览器标签页，展示一些模型图吗？”

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

针对每个问题，都要问自己：对方是否能通过观看更好地理解？ 模型图、布局、示意图和并排设计放在浏览器中展示。 需求、范围、权衡和概念性选择用文字讨论。涉及 UI 的问题不一定就是视觉问题。

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