Brainstorming skill

Brainstorming Skill — 产品经理使用指南

一句话定义

Brainstorming Skill 是一个强制门控型设计前导技能，要求 AI 在执行任何创造性工作前，必须先通过结构化对话完成需求澄清、方案探索和设计文档输出，确保"想清楚再动手"。

Skill 的十个核心功能

自动触发与强制激活
当 AI 检测到用户提出创建功能、构建组件、添加行为等创意性任务时，自动激活该技能，要求必须先完成头脑风暴再写代码。
项目背景探索
启动后先理解项目现状——自动查看文件结构、文档和最近的 Git 提交记录，确保后续建议都基于当下项目实际而非凭空发挥。
一次一问式澄清对话
每次只问一个问题，优先提供选择题形式，避免像传统 AI 那样一次性输出大量问题让用户不知所措，逐步厘清目的、约束和成功标准。
多方案对比与探索
针对需求提出 2-3 个不同方案，每个方案都附带优缺点和权衡分析，并给出带有理由的明确推荐，防止用户被锁定在第一个想到的方案上。
增量式分段呈现设计
将最终设计拆分为 200-300 字的小段落逐步呈现，每段结束后主动确认用户是否认可，避免大幅返工，且随时可回退重新澄清。
构建可靠的对话锚点（anchor）
通过每轮确认构建起一个逐步收敛的安全决策链——一旦某个设计段落被用户批准，后续讨论就以此为锚点继续深入，不会发生“聊着聊着把前面定好的东西又推翻了”的情况。
设计文档自动生成与归档
对话完成后自动将设计写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md，提交到 Git 进行版本追踪，形成可追溯的知识资产。
规范自检与子代理审查
文档生成后先快速自查占位符、矛盾、歧义和范围问题，随后调度专门的子代理进行规范审查，审查未通过就自动修复、重新审查，超过 5 轮则上升给人工判断。
视觉伴侣支持
当话题涉及 UI 或视觉问题时，Agent 会主动询问是否启用视觉伴侣，可将 HTML 原型、图表或对比页面写入浏览器端展示，实现“边聊边看”。
无缝衔接后续工作流
设计批准后，自动过渡到 writing-plans 技能创建实施计划，再配合 subagent-driven-development 进行逐任务实施，形成 brainstorm → plan → TDD 的完整链条。

15 个产品经理日常用法

1.PRD 需求澄清对话	拿到一句“优化用户注册流程”这种模糊需求时，不走查→问→写→审→改的循环，而是由 AI 主动以选择题形式逐一轮询目标用户群、核心痛点、转化率指标，生成一份经过三轮追问验证的需求草案。
2.竞品功能拆解与方案生成	输入竞品名称或截图，AI 自动拆解其功能模块、交互模式，然后基于自家产品定位生成差异化方案选项，不用再手动整理竞品分析表格。

PRD 需求澄清对话
拿到一句“优化用户注册流程”这种模糊需求时，不走查→问→写→审→改的循环，而是由 AI 主动以选择题形式逐一轮询目标用户群、核心痛点、转化率指标，生成一份经过三轮追问验证的需求草案。
竞品功能拆解与方案生成
输入竞品名称或截图，AI 自动拆解其功能模块、交互模式，然后基于自家产品定位生成差异化方案选项，不用再手动整理竞品分析表格。
用户故事自动拆解
输入一个 Epic（如“提升用户留存”），AI 自动拆解为多个 User Story，并为每个 Story 标注优先级建议和对应的验收标准，可直接入库到项目管理工具。
功能回归影响分析
当需要修改某个核心功能时，AI 先列出该功能涉及的所有页面、接口、数据字段，再逐一评估“改了这里会影响哪里”，输出影响范围矩阵。
A/B 测试方案设计
告诉 AI 你要测试哪个页面或功能，它会生成 2-3 套变量设计方案（如不同按钮文案、不同流程步骤数），并给出每种方案的预期指标变化方向和建议流量分配比例。
技术可行性快速评估
把初步产品想法描述给 AI，它从“前端能不能做、后端接口是否支持、第三方服务有没有现成方案”三个维度做可行性判断，输出评分或红绿灯标记。
功能优先级排序会议准备
AI 根据预设的 RICE 或 ICE 评分框架，自动拉取各功能的需求背景、预估影响面、实现成本，生成排序建议表格，PM 只需微调而非从零搭建。
异常流程穷举
告诉 AI 一个功能的正常路径，它反问“这一步如果用户断网 / 输入非法字符 / 超时 / 接口返回异常怎么办”，自动生成异常场景 checklist。
数据埋点方案设计
AI 根据页面或功能描述，自动输出需要埋点的用户行为列表（点击、曝光、提交等），并给出每个事件的触发条件和上报参数建议。
版本发布说明（Release Notes）提炼
将设计文档或多条 commit 信息输入，AI 自动提炼出面向用户的功能描述、修复内容，输出可直接粘贴到应用商店或公告页面的发布说明草稿。
产品 Roadmap 头脑风暴
输入当前产品现状和业务目标，AI 分三个阶段逐步收敛：先发散生成大量种子想法，再合并筛选保留 3-5 个方向，最后为每个方向生成可进入下季度的路线草案。
用户反馈分类与行动建议
批量丢入原始用户反馈（问卷、评论、工单），AI 自动按“Bug / 体验问题 / 新功能建议”分类，并为每个类别生成优先级排序的 actionable 任务列表。
跨部门需求对齐
市场、运营、客服各提一种“我想要的方案”时，AI 先将各方语言翻译成标准化功能描述，再对齐找出表层分歧背后的共同底层需求，输出一份可让各方签字确认的对齐文档。
新市场/新人群适配评估
当产品要进入新市场（如海外某国家）时，AI 从语言、文化习惯、法规、支付方式、网络环境五个维度做适配评估，输出需要改动的功能清单和影响预估。
产品命名与文案创意
输入产品功能和目标人群，AI 生成多组命名候选（含域名可用性检查提示）和不同风格的文案方案（理性卖点型 / 情感故事型 / 极简 Apple 风），PM 可直接进入内部投票。

核心流程（9 步）

步骤	内容	关键行为
1	探索项目上下文	读文件、文档、最近提交，摸清现状
2	提供 Visual Companion	单独一条消息询问是否需要浏览器可视化（可选）
3	逐一提问澄清	每次只问一个问题，优先选择题
4	提出 2-3 个方案	附带权衡分析和推荐
5	分段呈现设计	按复杂度缩放，每段即时确认
6	写入设计文档	保存到 docs/superpowers/specs/ 并 git commit
7	Spec 自审	检查 placeholder、矛盾、歧义、范围
8	用户审阅文档	等待确认，有修改则迭代
9	转交 writing-plans	唯一出口，开始实施计划

文件结构

文件	作用
SKILL.md	主技能文件，定义流程和规则
visual-companion.md	浏览器可视化辅助工具指南
spec-document-reviewer-prompt.md	Spec 自审子代理模板
scripts/server.cjs	本地 HTTP 服务器
scripts/frame-template.html	可视化页面的 HTML 模板
scripts/helper.js	浏览器端交互脚本

10 个产品经理使用场景

场景 1：写 PRD 前的需求梳理

痛点：PRD 写到一半发现遗漏了边界条件，回头补了又发现和前面的逻辑矛盾。

做法：在正式写 PRD 之前，先把需求丢给 brainstorming skill。它会逐条提问，把"用户可以支付"这种模糊描述细化为"支持哪些支付方式、失败重试策略、退款流程、并发限制"等具体规格。

产出：一份经过自审的 spec 文档，直接作为 PRD 的骨架。

场景 2：新功能方向决策

痛点：团队对"下一步做什么"有分歧，开会讨论两小时没结论。

做法：描述当前产品状态和几个候选方向，让 brainstorming 提出 2-3 个方案并附带权衡分析。每个方案会列出优势、代价和适用条件。

产出：结构化的方案对比，附推荐方案及理由，作为决策会议的输入材料。

场景 3：竞品功能分析后的差异化设计

痛点：分析完竞品后，容易陷入"他们也做了我们也做"的跟随模式。

做法：把竞品分析结果和自身产品定位一起输入，brainstorming 会基于 YAGNI 原则帮你区分"必须做的差异化"和"可以忽略的跟风功能"。

产出：一份聚焦差异化的设计方案，附带明确的"不做清单"。

场景 4：用户反馈驱动的功能迭代

痛点：用户提了 50 条反馈，不知道哪些该优先处理、哪些是同一类问题。

做法：把用户反馈列表输入，brainstorming 会逐一提问帮你分类、排序、识别核心需求。它会追问"这条反馈背后的真实需求是什么"，帮你透过表象看本质。

产出：按优先级排列的需求列表 + 每个需求的简要设计方向。

场景 5：跨团队协作的需求对齐

痛点：后端说"你要什么接口"，前端说"后端没给数据"，PM 夹在中间反复传话。

做法：用 brainstorming 先把完整的数据流和接口需求设计出来。分段呈现时，可以把每段发给对应团队确认，确保所有角色在同一页面上。

产出：包含数据流、接口定义、错误处理的完整设计文档，三方可直接以此为共识。

场景 6：MVP 范围界定

痛点：老板说"先做个最小版本"，但"最小"的定义众说纷纭。

做法：列出所有想要的功能，brainstorming 会通过逐一提问帮你区分核心路径和锦上添花。YAGNI 原则会主动挑战每个功能："没有这个功能，用户能完成核心任务吗？"

产出：明确的 MVP 功能清单 + 被砍功能的记录（附砍掉理由，方便后续讨论）。

场景 7：现有功能的改版设计

痛点：改版容易陷入"改动越多越好"的陷阱，或者忽略已有用户的习惯。

做法：先让 brainstorming 探索现有项目上下文（读代码、文档、提交历史），理解当前实现的约束。然后基于这些约束提出改版方案，避免设计出技术上难以落地的方案。

产出：考虑了技术约束的改版设计，附带迁移策略。

场景 8：API / 接口设计

痛点：PM 不一定懂技术细节，但接口设计直接影响开发效率和下游使用方体验。

做法：描述业务场景和数据需求，brainstorming 会提问帮你明确：请求格式、响应格式、错误码策略、分页方案、版本管理等。

产出：一份面向开发者的接口设计 spec，减少 PM 和开发之间的来回沟通。

场景 9：产品上线 check list 设计

痛点：上线前总遗漏关键环节，出了问题才想起来"忘了配监控/忘了做数据迁移/忘了通知客服"。

做法：描述产品功能和上线环境，brainstorming 会逐一追问帮你覆盖：数据迁移、监控告警、回滚方案、用户通知、客服话术、灰度策略等。

产出：结构化的上线 check list，附带每个环节的具体要求。

场景 10：数据分析需求设计

痛点：提了数据需求，分析师跑出来的数据不是你想要的，或者漏了关键维度。

做法：先和 brainstorming 对话明确：分析目的是什么、需要回答哪些问题、数据粒度是什么、对比维度有哪些。每个维度都会被追问"为什么需要"。

产出：一份精确的数据需求文档，分析师拿到即可开工。

5 个高级使用场景

高级 1：多子系统大型项目拆解

当项目包含多个独立子系统时（例如"做一个平台，包含聊天、文件存储、计费、分析"），brainstorming 会主动拦截，不会逐条细化需求。而是先帮你：

识别独立子系统及其依赖关系
确定建设优先级（哪些先做、哪些依赖前置系统）
然后只对第一个子系统进入完整设计流程

每个子系统独立走 spec → plan → implement 循环。这种分解能力是普通对话做不到的 — 它防止了在庞大项目里迷失细节。

高级 2：Visual Companion 驱动的 UI 方向探索

开启 Visual Companion 后，brainstorming 变成一个浏览器内的交互式设计探索工具：

推送 wireframe 对比到浏览器，你点击选择偏好
你的点击行为会被记录到 events 文件，agent 分析你的选择模式
如果你在 3 个布局间反复点击切换，agent 会注意到你的犹豫并主动追问

这种视觉交互比纯文字描述 UI 方向高效得多。特别适合：品牌视觉方向、首页布局选择、导航结构设计等。

高级 3：Spec 自审作为团队知识库

brainstorming 的 Spec 自审不只查错，它实际上在创建一份可追溯的决策记录：

每个设计决策都有"为什么"的解释
被砍掉的功能附带了砍掉理由
spec 文档提交到 git，形成完整的决策历史

这对团队的价值是：三个月后有人问"为什么当初没做 X"，不用翻聊天记录，直接看 spec 文件。

高级 4：设计评审会议的准备材料

用 brainstorming 生成的设计文档作为评审会议输入材料时，会议效率会显著提升，因为：

文档已经过自审（无 placeholder、无矛盾、无歧义）
分段结构让评审者可以逐段讨论，不用一口气消化整个方案
每段都附权衡分析，评审者可以直接针对权衡点发表意见
被砍功能有记录，避免会议中重复讨论已否决的方案

高级 5：跨产品线的设计标准对齐

当多条产品线需要统一设计标准时（例如统一错误处理、统一用户引导流程），可以：

用 brainstorming 先对标准本身做设计 — 每条标准都经过"为什么需要"的质疑
输出的 spec 文档作为标准文档发布
各产品线基于这份 spec 各自走 writing-plans → implement

这比"写个 Wiki 页面然后祈祷大家看了"有效得多，因为每条标准都有推导过程。

使用示例

推荐形式：对比式 walkthrough

最好的示例不是展示"完美流程"，而是展示没有 brainstorming vs 有 brainstorming 的差异。

第一步：选一个真实场景

挑一个 PM 真实会遇到的需求，例如：

"给电商 App 加一个商品收藏功能"

不要用假需求（"做一个 XXX 系统"），假需求看不出 skill 的价值。

第二步：录制两组对话

对比组	做法	展示重点
不用 brainstorming	直接让 AI 写代码	展示它很快产出代码，但遗漏了上限、分组、排序、离线等边界问题
用 brainstorming	先跑 brainstorming 再实现	展示每一步追问如何发现遗漏，最终产出的设计如何覆盖边界

第三步：关键节点截图

在 brainstorming 流程中截取 3-4 个关键时刻：

第一次提问 — 展示"每次只问一个问题"的体验
方案对比 — 展示 2-3 方案 + 权衡分析
Visual Companion — 展示浏览器 mockup（如果有视觉环节）
Spec 自审 — 展示自动检查发现了什么问题

第四步：强调一个"差点踩坑"的时刻

这是最打动人的部分。找一个 brainstorming 帮你发现盲点的具体瞬间，例如：

"我问了收藏上限，brainstorming 追问'达到上限后用户再收藏会发生什么' — 这是我完全没想到的。"

格式建议

格式	适合场景	优势
图文博客	详细教程	完整、可搜索、可引用
短视频	快速传播	2-3 分钟展示对比差异
实际 demo 文件	技术团队内部分享	读者可看到真实产出物

避免的误区

不要展示"完美配合"的流程 — 真实使用中会有"这个方向不对，重新来"的来回，这才是可信的
不要跳过"用户需要审阅 spec"这一步 — 这是 skill 的核心设计，省略它等于省略了 skill 的灵魂
不要只展示简单需求 — 简单需求看不出 skill 价值。选一个至少有 3 个边界条件的需求