brainstorming

将想法转化为设计

概述

通过协作对话，将想法转化为清晰且获认可的头脑风暴文档。

始终支持基于角色的头脑风暴：

• 如果用户指定了角色，就从该角色的视角出发（例如：产品经理、前端架构师、后端架构师、UX 设计师）。
• 如果未指定角色，则使用 general strategist 角色。

在呈现设计并获得用户批准之前，不得调用任何实现技能、编写代码、搭建任何项目，也不得采取任何实现行动。

范围规则

当用户希望在实施前专门探索设计、比较方案或梳理需求时，使用此流程。

对于简单的实现请求、小型修复或明确指定的变更，不要强行套用完整的头脑风暴流程。 如果只需要轻量的设计帮助，就保持简短，只询问消除歧义所需的最少问题。

检查清单

选择最符合请求的精简检查清单。

标准流程

1. 探索项目背景：仅检查与主题相关的文件、文档和近期变更。
2. 提出澄清问题：仍有歧义时，优先一次聚焦一个问题。
3. 存在权衡时，提出 2-3 种方案；并给出推荐方案。
4. 用简洁的章节呈现设计，只涵盖请求涉及的方面。
5. 如果主题侧重规划，明确询问头脑风暴针对哪个目标对象：roadmap、milestone、phase 或 generic topic。
6. 相关时，询问头脑风暴是否应基于现有对象或参考资料集展开。
7. 如果用户希望保存文档，写入前先询问保存位置。
8. 交付头脑风暴结果后即停止，除非用户明确要求继续。

轻量流程

针对范围较窄的需求梳理，使用此精简流程：

1. 确认目标和关键约束。
2. 首先给出推荐方案。
3. 只有在会实质性改变范围、风险或成本时，才提及其他方案。
4. 直接在对话中给出结果，除非用户要求保存。

流程

digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Choose save location" [shape=box];
    "Write brainstorming doc" [shape=box];
    "Deliver doc and stop" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Choose save location" [label="yes"];
    "Choose save location" -> "Write brainstorming doc" [label="default / custom"];
    "Choose save location" -> "Deliver doc and stop" [label="skip saving"];
    "Write brainstorming doc" -> "Deliver doc and stop";
}

终止状态为 Deliver doc and stop。 除非用户明确要求进行下一步，否则不要继续制定实现计划或开展实现工作。

保存位置规则（必需）

写入任何文件之前，始终先询问用户希望将头脑风暴文档保存在哪里。

标准选项

1. 默认目录：docs/brainstorming/
2. 自定义目录：用户提供的路径
3. 跳过保存：不写入任何文件

规划层级目标的额外选项

如果头脑风暴目标是 roadmap、milestone 或 phase，还应提供以下选项： 4. 目标对象目录：仅当用户明确希望文档与目标对象放在一起时，才将头脑风暴文档保存在目标对象主文件所在目录。

判断规则

• 如果用户没有要求将文档与目标对象放在一起，优先使用默认目录 docs/brainstorming/。
• 只有当用户明确希望头脑风暴文档附属于相应的路线图、里程碑或阶段时，才使用目标对象目录。
• 只有当用户明确提供自定义目录时，才使用该目录。
• 如果用户选择跳过保存，则不要写入任何文件。

文件名规则

如果用户选择默认目录、自定义目录或目标对象目录，请使用：

• <topic>-YYYY-MM-DD-brainstorming.md

对于默认目录，完整路径为：

• docs/brainstorming/<topic>-YYYY-MM-DD-brainstorming.md

对于目标对象目录，保留相同的文件名格式，并将文件放入该对象的目录中。

将主题放在文件名开头，这样在浏览目录时，相关的头脑风暴文档会更自然地归类在一起，同时仍保留日期以便按时间顺序排列。

对于自定义目录，请写入用户提供的确切目录，并使用相同的文件名格式。

如果用户选择跳过保存，则不要写入任何文件——仅在聊天中直接输出文档内容。

提问规则

• 每条消息只问一个问题。
• 尽可能优先使用选择题。
• 聚焦于目的、约束和成功标准。
• 如果回答含糊，请返回并再次澄清。

设计展示规则

• 只有在存在有意义的权衡时，才在最终确定前展示 2-3 种方案。
• 先介绍推荐方案并说明原因。
• 简单任务的每个部分应简洁，复杂任务则应详细。
• 对于轻量级头脑风暴，请一次性征求整体批准，而不是逐部分征求批准。
• 只有当设计规模较大、风险较高或存在重大歧义时，才逐部分征求批准。

文档内容指南

请包含：

• 头脑风暴所采用的角色（明确指定的角色或 general strategist）
• 相关时注明目标对象（roadmap、milestone、phase、task 或 generic topic）
• 问题陈述和目标
• 约束和假设
• 备选方案及其权衡
• 推荐设计
• 对于规划层主题，明确重申 task 仍是唯一的执行单元，规划产物是规划／展示对象
• 风险和缓解措施
• 验证／测试策略
• 未决问题（如有）

不要包含实现代码。

完成标准

只有在满足以下条件后才能结束：

1. 用户已批准设计。
2. 用户已为文档选择一个允许的保存位置（docs/brainstorming/、适用时的目标对象目录、自定义目录，或跳过保存）。
3. 头脑风暴文档已写入文件（默认目录／目标对象目录／自定义目录），或已直接输出（跳过保存），并已分享。