brainstorming · diff
v1.0.0 to v1.0.0
81 added, 167 removed. Audit A to A.
---
name: brainstorming
- description: "在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。"
+ description: "在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能、修改行为，或筹划任何新东西，无论是软件还是软件之外（一场分享、一门生意、一次装修）。"
version: "1.0.0"
license: MIT
metadata:
hermes:
tags: [design, planning]
---
- # 头脑风暴：将想法转化为设计
-
- 通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。
-
- 先判断这个需求需要多少流程，然后沿着对应的路径推进：理解上下文、完善想法、展示设计、获得你的人类伙伴批准。
-
- ## 建立共同理解
-
- 头脑风暴的产出，是一份你的人类伙伴能认出来、也能纠正的理解，它扎根于他们想达成的目标。
-
- 1. **弄清意图。** 用需求本身和手头的上下文，判断预期的结果、它是给谁用的、怎样才算成功。缺这些信息时，在提出功能或方案之前，先问一个聚焦于目的或预期用途的问题。知道这是个什么类型的应用，并不能告诉你你的伙伴为什么想要它。补齐缺失的需求，不等于请他们再授权一遍这个任务。
- 2. **把你的理解写回给对方。** 用一段简短的说明概括预期结果、相关约束和成功标准，让你的伙伴可以评估。把他们说过的话和你的假设分开写。请他们纠正，并在把它当作设计简报之前吸收他们的回答。
- 3. **把意图带进设计。** 在所选路径的设计产出物里保留这份达成一致的理解：架构级工作是书面规格，有界工作和探路是对话里的设计或试探方案。拿这份理解去核对提出的每个功能和技术选择。
+ # 头脑风暴
- 当需求本身已经交代了目的和约束，就把这份理解复述出来，而不是再把同样的问题问一遍。说明要简短；要紧的是它准确、以及对方有机会纠正它。
+ 你非常擅长构建。你会去构建你认为你的人类伙伴想要的东西，而这个"认为"通常比你感觉到的要单薄。这个技能的用途，是在动手构建任何东西之前，弄清他们真正想要什么、以及为什么。
- <HARD-GATE>
- 在采取任何实现行动之前——包括调用实现技能、编写产品代码、搭建脚手架、安装产品依赖、创建外部项目——先完成所选路径的前置条件：
+ 人们常常还没想清楚自己想要什么。好的问题能帮他们把它想透。当你理解了背后的原因，那上百个他们从没提过的决定，你就会按他们自己会做的方式去做。
- - 探路：你的人类伙伴批准了问题和试探方案。
- - 有界：你的人类伙伴批准了对话里的简短设计。
- - 架构级：你的人类伙伴审阅并批准了书面规格，然后审阅书面实现计划并选定执行方式。对话中对设计的批准只允许你去写规格；对书面规格的批准只允许你去调用 writing-plans。
+ ## 首先：你到底知道多少？
- 一次回复只批准实际呈现给对方的那个阶段。批准一个想法或功能范围，不等于批准还不存在的产出物。从最早一个未完成的阶段接着做；不要把一次批准变成跳过所选路径其余部分的许可。前置条件未完成期间，允许只读地探索项目。
- </HARD-GATE>
+ 回复之前，先问自己：关于他们想要什么、为什么想要，我知道些什么？
- ## 三条路径
+ - **要紧的信息都在请求里了**（"把图标改成矢车菊蓝"）。这是一个快速、明确的任务。直接做，并说明你做了什么。
+ - **缺了某些不简单的东西。** 开始对话。
- 在提出第一个问题之前，先给需求分类，并把分类**说出来**——"这个看起来是有界的，所以我会在这里直接给一份简短设计，而不是写规格文档"——好让你的人类伙伴能纠正你：
+ ## 你的第一条消息
- - **探路（Spike）** — 一个可行性问题（"我们能不能……"、"有没有可能……"、"糙一点没关系"），它的产出是一个**答案**，不是要留下的代码。用 2-3 句话说明问题和你打算怎么试，得到一个点头，然后用不牺牲正确性的最低成本去弄清楚。不写设计文档，不写规格文件。以建议的形式汇报发现；过程中搭的任何东西都明确标注为一次性的。
- - **有界（Bounded）** — 对**本仓库里已经存在的代码**做范围明确的改动：加一个开关、一个小接口、改一个文件的 bug。"知道这是个什么类型的应用"不算数——有界意味着**你要改的那条流程此刻就在仓库里、可以读**。如果没有现成的流程可改，这个任务就不是有界的。问那些真正重要的澄清问题，**在对话里**给出一份简短设计（几句话到几个短段落），然后**停下**。只有在你的人类伙伴对这份设计说"可以"之后，实现才开始——有界任务的批准和架构级任务的批准是同样硬的关卡。不写规格文件，不写实现计划文档。
- - **架构级（Architectural）** — 新项目、新子系统，以及会重构组件之间关系、或改动他人依赖的接口的改动。走完整流程：提问、方案对比、分节设计、书面规格，然后交给 writing-plans 技能。
+ 你的第一条消息包含两件事，按这个顺序：
- 在两条路径之间拿不准时，选更重的那条。这个棘轮只朝一个方向转：任务进行中发现隐藏的复杂度，就**升级**路径——停下来、说明情况、升上去。任何情况下都不在任务中途降级。
+ 1. 一句话告诉他们：如果他们宁愿跳过提问、让你直接开始，可以直说。如果他们明确接受了这个提议，这个技能就结束了：用一句平实的话说明任何重要的"怎么做出来"的选择（平台、语言、媒介），然后按正常工作流去做他们要求的事。
+ 2. 一个让他们开始描述的开放式问题。问一个真实的时刻或一个具体的画面："你是在什么时候，会希望要是有这个东西就好了？"或者"跟我说说到时候在场的都是些什么人。"
- ## 反模式："这个太简单了，不需要批准"
+ 整条消息就这些。
- 每条路径的终点都是你的人类伙伴在实现之前批准所要求的设计。一个有界改动可能只需要对话里的两句话。一个新的待办事项列表项目是架构级的，需要书面规格和计划交接。按所选路径缩放产出物；在实现之前走完该路径的所有审阅。
+ ## 对话
- ## 危险信号
+ 每条消息都以一个问题结尾：只有一句话，后面不挂一串示例答案。用平实的语言，比你的人类伙伴当前的水平稍高一点点。贴合他们的用词；永远不要用流程术语。
- | 心里的想法 | 实际情况 |
- |---------|---------|
- | "这个太简单了，不需要设计" | 按所选路径走：有界改动给一份简短的对话内设计；架构级改动走书面规格和计划交接。 |
- | "我就说它是有界的，跳过规格文档" | 为了少干活而去够一个标签，这本身就是"拿不准"——选更重的那条路径。 |
- | "它是有界的，设计也很显然——我一边让他们读一边开工" | 关卡是**批准**，不是设计的长度。展示完就停，直到听见"可以"。 |
- | "这类应用我很熟，所以它是有界的" | 有界衡量的是**仓库**，不是你的熟悉程度。新项目没有现成的流程可改——那是架构级。 |
- | "探路跑通了，那这些代码就留着吧" | 探路的产出是一个答案。要留下代码是一个**新的需求**——给它重新分类。 |
- | "范围是变大了，但我快做完了，不用重新分类" | 隐藏的复杂度会在任务中途升级路径。停下来，说明情况。 |
- | "他们批准了探路，那后续改动也算批准了" | 每个任务有自己的分类，也有自己的批准。 |
+ 清楚、简洁。先说要紧的。避免行话。汇报你发现的东西时，给他们最重要的发现，其余的问他们要不要看。
- ## 检查清单
+ **让他们先描述。** 开放式问题优先。他们自己的话里带着意图，你给的选项承载不了这些。只有在他们卡住时，才给一份简短的选项。当他们说"你猜一个吧"、"你觉得呢？"或"你看着办吧"，就提出一个具体的方案。在中文里，"你看着办""你定吧"是请你拿主意，不是让你跳过提问直接动手：提出方案，然后照常推进，完整描述获批之前不构建。
- 先分类，宣布路径，然后为你所在路径上的每个条目创建任务，并按顺序完成。
+ **怎么做出来。** 每个项目都建立在关于媒介、工具、材料和资源的选择之上：一个应用的平台、编程语言和库；一件艺术作品的媒介。尽早弄清：这些选择里哪些他们想自己定，哪些交给你，以及他们手头已经有什么可用。有明确想法或相关技能的人，会想好好聊一聊。指望你来定的人，需要合理的默认选择，并用平实的话说出来。已经有现成成果时，就沿用它已经在用的东西。你自己做的任何选择，都要在设计里写成你的决定，绝不写成他们同意过的东西。
- **探路（Spike）：**
- 1. **探索项目上下文** — 够用来框定这次试探即可
- 2. **展示问题 + 试探计划** — 2-3 句话
- 3. **获得批准** — 一个点头就够
- 4. **动手调查** — 用不牺牲正确性的最低成本
- 5. **汇报发现** — 以建议的形式；搭出来的任何东西都标注为一次性的
+ **要覆盖的范围。** 这是一片要走遍的区域，不是一份台词。永远不要把这些当成问题念出来：
- **有界（Bounded）：**
- 1. **探索项目上下文** — 检查文件、文档、最近的 commit
- 2. **提出澄清问题** — 每次一个，只问那些真正重要的
- 3. **在对话里展示简短设计** — 思路、会动哪些文件、怎么测
- 4. **获得批准** — **停下**并等待一个明确的"可以"；展示完设计顺口就开工，等于跳过了关卡
- 5. **实现** — 走正常的开发工作流（TDD 同样适用）；不写计划文档
+ - 这是个什么东西，它特别在哪里
+ - 为什么是现在，以及在他们看来怎样才算成功
+ - 目标、非目标和反目标（哪怕技术上能用，也会让这件事算失败的东西）
+ - 先例：他们在别处见过的、喜欢的或讨厌的
+ - 现状：现在有什么，他们已经试过什么
+ - 他们在意的细节
- **架构级（Architectural）：**
- 1. **探索项目上下文** — 检查文件、文档、最近的 commit
- 2. **在需要时才提供视觉伴侣** — **不要一上来就提**。第一次遇到"这个问题画出来比说出来更清楚"时，才在那一刻提供（作为独立的一条消息）；对方同意后，浏览器标签页会为你打开。如果自始至终没出现视觉问题，就永远不要提。参见下方"视觉伴侣"部分。
- 3. **提出澄清问题** — 每次一个，了解目的/约束/成功标准
- 4. **提出 2-3 种方案** — 附带权衡分析和你的推荐
- 5. **展示设计** — 按复杂度分节展示，每节展示后获得用户批准
- 6. **编写设计文档** — 保存到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit
- 7. **规格自检** — 快速内联检查占位符、矛盾、模糊性、范围（详见下方）
- 8. **用户审查书面规格** — 在继续之前请用户审查规格文件
- 9. **过渡到实现** — 调用 writing-plans 技能创建实现计划
+ **管用的问题**都锚定在具体事情上："带我走一遍上一次……的经过"、"如果它只能把其中一件事做好，你选哪件？"、"要是我做错了什么会让你皱眉？"一个可以被纠正的猜测（"我猜这是因为 X 老是坑你？"）往往比一个问题更好。
- ## 流程图
+ **主动提出去侦察。** 一旦有了一点基础、而去看一看会有帮助，就提出去看：他们的代码库或项目、他们自己的文件和数据，或者网上。说明你打算找什么。去不去由他们决定。
- ```dot
- digraph brainstorming {
- "分类：探路 / 有界 / 架构级" [shape=diamond];
- "展示问题 + 试探计划（2-3 句）" [shape=box];
- "提出澄清问题（有界）" [shape=box];
- "在对话里展示简短设计" [shape=box];
- "人类伙伴批准?" [shape=diamond];
- "动手调查；汇报建议" [shape=doublecircle];
- "走正常工作流实现（无计划文档）" [shape=doublecircle];
- "探索项目上下文" [shape=box];
- "提出澄清问题" [shape=box];
- "提出 2-3 种方案" [shape=box];
- "分节展示设计" [shape=box];
- "用户批准设计?" [shape=diamond];
- "编写设计文档" [shape=box];
- "规格自检\n（内联修复）" [shape=box];
- "用户审查规格?" [shape=diamond];
- "调用 writing-plans 技能" [shape=doublecircle];
- "发现隐藏复杂度? 升级路径" [shape=box];
+ **私下里想宽一点。** 在提出任何方案之前，先想出好几个点子，再丢掉弱的，包括任何和他们讲过的"为什么"相冲突的。只有在对比能帮他们做决定时，才把对比拿出来给他们看。
- "分类：探路 / 有界 / 架构级" -> "展示问题 + 试探计划（2-3 句）" [label="探路"];
- "分类：探路 / 有界 / 架构级" -> "提出澄清问题（有界）" [label="有界"];
- "分类：探路 / 有界 / 架构级" -> "探索项目上下文" [label="架构级"];
- "展示问题 + 试探计划（2-3 句）" -> "人类伙伴批准?";
- "提出澄清问题（有界）" -> "在对话里展示简短设计";
- "在对话里展示简短设计" -> "人类伙伴批准?";
- "人类伙伴批准?" -> "动手调查；汇报建议" [label="探路：是"];
- "人类伙伴批准?" -> "走正常工作流实现（无计划文档）" [label="有界：是"];
- "发现隐藏复杂度? 升级路径" -> "分类：探路 / 有界 / 架构级";
- "探索项目上下文" -> "提出澄清问题";
- "提出澄清问题" -> "提出 2-3 种方案";
- "提出 2-3 种方案" -> "分节展示设计";
- "分节展示设计" -> "用户批准设计?";
- "用户批准设计?" -> "分节展示设计" [label="否，修改"];
- "用户批准设计?" -> "编写设计文档" [label="是"];
- "编写设计文档" -> "规格自检\n（内联修复）";
- "规格自检\n（内联修复）" -> "用户审查规格?";
- "用户审查规格?" -> "编写设计文档" [label="要求修改"];
- "用户审查规格?" -> "调用 writing-plans 技能" [label="批准"];
- }
- ```
+ **展示，而不是讲述。** 只要"看到"比"读到"更有帮助，就提出使用视觉伴侣（见下文）：
- **终止状态跟着路径走。** 架构级：头脑风暴之后你唯一要调用的技能是 writing-plans——绝不调用 frontend-design、mcp-builder 或任何其他实现技能。有界：获得批准之后，直接走正常的开发工作流去实现，不写计划文档。探路：终止状态是一份汇报出去的建议。
+ - 他们会去看的东西：一个屏幕、一个页面、一份打印件、一块标牌
+ - 一种布局或排布：一个屏幕的、一个房间的、一份日程的
+ - 一个流程或一串步骤
+ - 看起来会彼此不同的几个选项
+ - 看比读更容易理解的结构：一张示意图、一条时间线、一张地图
- ## 流程详述
+ 一旦他们接受，就用它来展示供他们反应的原型、并排的选项，以及他们可以点一点的一次性原型。
- 下面这些小节服务于**有界**和**架构级**两条路径（探路在"展示试探计划、拿到点头"就停了）。从**探索方案**往后都是架构级路径的深度——对有界的工作来说，上下文加几个问题再加一份对话里的简短设计，就是全部流程。
+ **用 spike 摸一摸。** 智能体做事是瀑布式的，只不过非常、非常快。一个快速的一次性构建，往往是弄清他们想要什么、或者某样东西行不行得通的最便宜的办法。在有帮助时就提出来。当他们就是想做个 spike，就别挡路。spike 不写测试或只写最少的测试，不追求万无一失，并且跳过计划、实现和审查流程。把 spike 让你学到的东西带回对话里。
- **理解想法：**
+ ## 复述给对方
- - 首先查看当前项目状态（文件、文档、最近的 commit）
- - 在提出详细问题之前，先评估范围：如果需求描述了多个独立子系统（例如"构建一个包含聊天、文件存储、计费和分析的平台"），立即指出这一点。不要花时间用问题去细化一个需要先拆分的项目。
- - 如果项目规模过大，单个规格说明无法覆盖，帮助用户分解为子项目：有哪些独立的部分，它们之间有什么关系，应该按什么顺序构建？然后通过正常的设计流程进行第一个子项目的头脑风暴。每个子项目都有自己的规格 → 计划 → 实现周期。
- - 对于范围适当的项目，每次提一个问题来完善想法
- - 尽量使用选择题，开放式问题也可以
- - 每条消息只提一个问题——如果一个主题需要更多探索，拆分成多个问题
- - 重点理解：目的、约束、成功标准
+ 边聊边复述。一旦你对某一部分理解到足以描述它（比如它是做什么的、为谁服务，或者某一块是怎么运作的），就用大约 200-300 字把这一部分复述回去，然后回到关于下一部分的提问。复述和提问在整场对话里交替进行；最后一段复述覆盖剩下的所有内容。
- **探索方案：**
+ 你猜的东西要标明是你的猜测；只有他们说过的话才算作他们的。每段复述都以询问"哪里不对或漏了什么"结尾。
- - 提出 2-3 种不同的方案及其权衡
- - 以对话的方式展示选项，附上你的推荐和理由
- - 先展示你推荐的方案并解释原因
- - 严格遵循 YAGNI —— 从每个方案和设计里移除不必要的功能
+ 发出一段复述之前，先检查：它描述的是不是他们会去看的东西，比如一个页面、一个屏幕、一份日程或一份打印件？如果是，而他们还没收到过视觉伴侣的提议，就改为发送这个提议（作为单独一条消息，见下文），把这段复述留到下一条消息。一旦他们接受了，就在描述旁边放上原型。
- **展示设计：**
+ ## 判断工作规模
- - 一旦你认为理解了要构建的内容，就展示设计
- - 每个部分的篇幅与其复杂度匹配：简单的几句话，复杂的最多 200-300 字
- - 每个部分展示后询问是否正确
- - 涵盖：架构、组件、数据流、错误处理、测试
- - 随时准备回头澄清不明确的地方
+ 一旦你理解了他们想要什么，选定一个规模，并用平实的话说出来。他们可以推翻你的判断。
- **面向隔离和清晰的设计：**
+ | 规模 | 完整描述 | 然后 |
+ |------|----------|------|
+ | 一个快速、明确的任务 | 请求本身 | 直接做 |
+ | 一个小改动 | 在对话里 | 走正常工作流去构建 |
+ | 一个需要书面设计的项目 | 一份书面设计文档 | 一份完整计划（软件项目：writing-plans） |
- - 将系统拆分为更小的单元，每个单元有一个明确的职责，通过定义良好的接口通信，可以独立理解和测试
- - 对于每个单元，你应该能回答：它做什么，如何使用，它依赖什么？
- - 别人能否不看内部实现就理解一个单元的功能？你能否在不影响调用者的情况下修改内部实现？如果不能，边界需要调整。
- - 更小、边界清晰的单元也更便于你工作——你对能一次放入上下文的代码推理得更好，文件越专注你的编辑越可靠。当文件变大时，这通常意味着它承担了过多职责。
+ 如果做到一半它变大了，停下来，说明情况，把规模升一级。
- **在现有代码库中工作：**
+ 如果这其实是几个独立的项目，就直说，商定一个顺序，然后一个一个地做头脑风暴。
- - 在提出更改之前先探索现有结构。遵循现有模式。
- - 如果现有代码存在影响当前工作的问题（例如文件过大、边界不清、职责纠缠），在设计中包含有针对性的改进——就像一个优秀的开发者在工作中改进经手的代码一样。
- - 不要提议无关的重构。专注于服务当前目标的事情。
+ ## 书面设计
- ## 设计之后（架构级路径）
+ 对一个项目，写一份平实的文档，让这个领域里一位有才干的建造者，不用回头去问你的人类伙伴，就能据此做出计划。涵盖：
- **文档：**
+ - 意图和背后的原因
+ - 目标、非目标、反目标
+ - 约束
+ - "怎么做"里他们自己定下的部分，照他们定下的样子写
+ - 留给建造者决定的部分
- - 将验证通过的设计（规格说明）写入 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
- - （用户对规格位置的偏好优先于此默认值）
- - 如果可用，使用 elements-of-style:writing-clearly-and-concisely 技能
- - 将设计文档 commit 到 git
+ **放在哪里：** 在软件仓库里，放到 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` 并 commit。其他情况，问一下。你的人类伙伴的偏好优先于这两种默认。
- **规格自检：**
- 编写规格文档后，以全新的视角审视它：
+ **建造者检查（builder check）：** 用本目录下的 `builder-check-prompt.md` 派发一个全新的子代理。告诉你的人类伙伴你要开始整理文档时，说明会先有一位审阅者读一遍，你可能会带着几个问题回来一次。检查结果回来之前，不要把文档交给他们。把建造者提出的问题分成三堆：
- 1. **占位符扫描：** 有没有"待定"、"TODO"、未完成的章节或模糊的需求？修复它们。
- 2. **内部一致性：** 各章节之间有矛盾吗？架构和功能描述匹配吗？
- 3. **范围检查：** 这是否聚焦到可以用一个实现计划覆盖，还是需要进一步拆分？
- 4. **模糊性检查：** 有没有需求可以被两种方式理解？如果有，选择一种并明确写出来。
+ - **已经有答案的**：对话或项目里已经回答了。把答案写进文档。
+ - **次要的**：一个明智的建造者可以自行定夺，且不会改变要构建的东西。你自己定下来，并在文档里标注这是你的决定。
+ - **他们的**：只有你的人类伙伴能回答，而且答案会改变要构建的东西。
- 发现问题就直接内联修复。无需重新审查——修好继续推进。
+ 把"他们的"那一堆放在一条消息里带过去，最重要的放前面。用他们的回答更新文档，然后交给他们，附上一份你自己做了哪些决定的简短清单，方便他们阅读时核对。检查只会产生这一轮提问。如果没有子代理工具，就自己以那位建造者的身份读一遍文档。
- **用户审查关卡：**
- 规格自检完成后，请用户在继续之前审查书面规格：
+ <HARD-GATE>
+ 在你的人类伙伴批准完整描述之前，什么都不构建：小改动在对话里批准，项目批准的是文档。构建包括编写产品代码、搭建脚手架、安装依赖、创建项目，以及调用实现类技能。阅读和探索没问题。
- > "规格已编写并 commit 到 `<path>`。请审查一下，如果在我们开始编写实现计划之前你想做任何修改，请告诉我。"
+ 两个例外。如果他们选择了跳过提问，这个技能就结束了，这道关卡也随之结束。一个他们同意过的 spike 可以去构建；它始终标注为一次性的，而要保留它的产出是一个新的需求，要重新走这道关卡。
- 等待用户回复。如果他们要求修改，做出修改并重新运行规格自检。只有在用户批准后才继续。
+ 一个项目的文档获批之后，下一步是计划。软件项目：调用 writing-plans，不调用任何其他技能。
+ </HARD-GATE>
- **实现：**
+ ## 危险信号
- - 调用 writing-plans 技能创建详细的实现计划
- - 不要调用任何其他技能。writing-plans 是下一步。
+ | 心里的想法 | 实际情况 |
+ |---------|---------|
+ | "我给几个选项，省得他们费劲" | 选项会带偏人。先请他们自己描述。 |
+ | "我把合理的默认值填上" | 很好。把它们说出来。他们从没听到过的默认值，他们也就没法拒绝。 |
+ | "我应该先把流程讲清楚" | 问你的问题。流程自己会显现出来。 |
+ | "他们对这个想法说了'听起来不错'" | 批准只覆盖你给他们看过的东西。你还没写出来的描述，不算批准过。 |
+ | "spike 跑通了，我接着在它上面做下去" | 保留它是一个新的需求。重新走关卡。 |
## 视觉伴侣
- 一个基于浏览器的伴侣工具，用于在头脑风暴过程中展示原型、图表和视觉选项。它是一个工具——不是一种模式。接受伴侣意味着它可用于适合视觉呈现的问题；并不意味着每个问题都要通过浏览器。
-
- **提供伴侣（在需要时才提）：** **不要一上来就提。** 等到某个问题确实"画出来比说出来更清楚"时再提——要是真正的原型 / 布局 / 图表问题，而不仅仅是话题跟 UI 沾边。第一次出现这种情况时，就在那一刻提供，作为独立的一条消息：
- > "接下来这部分，我展示给你看可能更容易理解——我可以在讨论过程中，在一个浏览器标签页里做原型、图表和对比。这个功能还比较新，可能会消耗较多 token。要我打开吗？我来帮你打开。"
+ 一个浏览器标签页，用来展示原型、示意图和可交互的原型。它是一个工具，不是一种模式：接受了它，并不意味着每个问题都要搬到浏览器里。
- **此提议必须是一条独立的消息。** 只有这条提议——不含澄清问题、内容摘要或任何其他内容。等待用户回复。如果他们接受，用 `--open` 启动服务，浏览器会自动打开到第一屏。如果他们拒绝，继续纯文本进行，并且不要再提，除非他们自己提起。
+ **在需要的那一刻再提。** 上面列出的那些时刻第一次出现时才提出，绝不一上来就提。这个提议是一条单独的消息，里面不放任何别的东西：
- **逐问题决策：** 即使用户接受了，也要对每个问题单独决定是使用浏览器还是终端。判断标准：**用户看到它是否比读到它更容易理解？**
+ > "这部分我展示给你看可能更容易。要我打开一个浏览器标签页，放几个原型给你看吗？"
- - **使用浏览器** 展示本身就是视觉的内容——原型、线框图、布局对比、架构图、并排视觉设计
- - **使用终端** 展示文本内容——需求问题、概念选择、权衡列表、A/B/C/D 文字选项、范围决策
+ 如果他们拒绝，就继续用文字，除非他们自己提起，否则不要再提。
- 关于 UI 主题的问题不一定是视觉问题。"在这个上下文中个性化是什么意思？"是一个概念问题——使用终端。"哪种向导布局更好？"是一个视觉问题——使用浏览器。
+ **每个问题都问一下：他们看到它，会不会比读到它更容易理解？** 原型、布局、示意图和并排的设计放到浏览器里。需求、范围、权衡和概念性的选择留在文字里。一个关于 UI 话题的问题，不自动等于一个视觉问题。
- 如果他们同意使用伴侣，在继续之前阅读详细指南：
- `skills/brainstorming/visual-companion.md`
+ 如果他们接受了，在启动服务之前，先阅读本目录下的 `visual-companion.md`。