Brainstorm Engine

Overview

脑力风暴执行引擎，使AI能够在项目前置决策阶段有章法地发现问题、发散方案、收敛决策。核心目标：让脑力风暴从"随便聊聊"变成"有产出的论证过程"。

Why This Matters

99.99%的软件项目失败源于第一步——脑力风暴阶段没有想清楚。常见问题：
- 只讨论方案，不发现问题
- 只发散不收敛，聊完没有结论
- 只看技术可行性，不看资源和约束
- 不记录决策理由，后续无法回溯

本Skill通过结构化流程解决这些问题。

Visualization Output (可视化产出)

> 经验教训 exp-risk_20260715_005：用户反馈"文字交流不如图描述的有意义"，文字信息密度低、不够直观。脑力风暴的每个关键环节必须配套可视化产出。
>
> 经验教训 exp-risk_20260715_006：v3虽然加了可视化要求，但只解决了"有没有图"的问题，没解决"图好不好"。用户要求：图不能是干巴巴的草图，要有美术功底；要能看到业务界面预览；要提供效果模板和参考样式。

核心原则：能用图说清楚的绝不用文字段落，文字只做图的补充说明。图本身也要有质量——不是草图，是能传递产品概念的视觉表达。

三层可视化体系

可视化产出分3个层次，脑力风暴过程中必须覆盖全部3层：

各环节可视化要求

可视化质量标准

1. 美术质量 — 图不能是干巴巴的草图。必须使用专业配色方案（非纯黑纯白）、层次分明的布局、语义化的图标标注。每张图应该看起来像专业的设计稿，不是草稿纸上的涂鸦。

2. 信息完整性 — 概念图要标注关键信息（模块名、数据流向、角色权限）；界面预览要标注交互元素（按钮、输入框、列表、跳转）；效果模板要标注风格特征（配色、字体、布局风格）。

3. 界面预览深度 — UI线框图至少画到以下程度：
   - 页面布局结构（头部/内容区/底部导航）
   - 核心交互元素位置（按钮、表单、列表项）
   - 数据展示方式（卡片/列表/表格/图表）
   - 关键操作流程（用户从A到B怎么走）
   - 移动端和PC端的差异展示

4. 效果模板价值 — 效果模板不是随便找几张图，必须：
   - 标注参考来源和适用场景
   - 说明每种风格与本项目的匹配度
   - 提供配色方案的具体色值
   - 让用户能做选择，而不是看完更迷糊

5. 最终产出标准 — 脑力风暴结束时，用户应该对以下问题有清晰的概念：
   - 系统的架构长什么样？（Layer 1）
   - 核心页面长什么样？（Layer 2）
   - 视觉风格走什么方向？（Layer 3）
   - 如果没有达到这个标准，脑力风暴不算完成

可视化规则

1. 每个Step至少产出1张图，不能只有文字
2. 方案对比必须用图，不能只靠表格评分——要让用户一眼看出方案的结构差异
3. 用户举的例子要即时图化，把隐性认知变成显性模型
4. 关键决策点必须有图支撑，不能"文字说了算"
5. 图要服务于理解，不是装饰——如果一张图不能比文字更清楚地表达，就不要画
6. Step 3结束时必须输出界面预览和效果模板——让用户看到"系统长什么样"

Workflow

Step 0: Value Interrogation (价值追问)

> 经验教训 exp-risk_20260715_003：第二次实战中AI没有问"为什么要做这个系统"，把全部精力放在流程架构上，忽略了系统的核心价值。Excel也能写计划，那为什么要做系统？这个"为什么"必须在一切方案讨论之前回答。

在需求拆解之前，必须先回答三个问题：

0.1 不做会怎样？
- 如果不做这个系统，用户现在怎么解决这个问题？（Excel？Word？口头沟通？）
- 现有方案的痛点是什么？
- 不做的代价是什么？（效率低？数据散？没法考核？）

0.2 做了能解决什么现有工具解决不了的问题？
- 系统相比现有工具（Excel/Word/邮件）的核心增量价值是什么？
- 如果只是"把纸质流程搬到线上"，那系统没有存在意义
- 核心价值点是什么？是效率提升？是AI辅助？是数据沉淀？是流程规范？

0.3 题目里已经圈出来的重点是什么？
- 重新审视用户的项目名称/描述，找出关键词
- 这些关键词指向的核心问题是什么？
- AI有没有忽略关键词、只关注次要部分？
- 特别注意：项目名称中的每个词都是重点，不能选择性忽略

> Quality Gate (Step 0)：
> - [ ] 是否回答了"不做会怎样"？
> - [ ] 是否识别出系统的核心增量价值（相比现有工具）？
> - [ ] 是否重新审视了项目名称中的关键词？
> - [ ] 核心价值点是否作为后续方案探索的主要方向？

只有Step 0通过后，才能进入Step 1。

Step 1: Problem Discovery (发现问题)

脑力风暴的第一步不是想方案，而是找问题。从用户给出的项目需求描述出发，逐层挖掘：

1.1 需求拆解

将用户的一句话/一段话需求描述拆解为：
- 核心目标：这个项目要解决什么问题？
- 核心价值：系统相比现有工具（Excel/Word/邮件）的核心增量价值是什么？（Step 0的产出）
- 隐含假设：用户预设了哪些前提？这些前提成立吗？
- 利益相关方：谁会用？谁会受影响？谁付钱？
- 约束条件：时间、预算、人力、技术栈限制
- 内容生产：系统中的核心内容（如计划、成果、报告）是怎么产生的？用户写起来难不难？有没有AI辅助空间？

1.2 场景穷举（关键环节，不可跳过）

> 经验教训 exp_20260715_001/002：首次实战中跳过场景穷举导致用户评分20分。任何涉及人使用系统的需求，必须做场景穷举。

在需求拆解后、问题清单生成前，强制对"使用场景"做穷举式拆解。每个维度必须逐一与用户确认，不能AI自己假设完就往下走。

1.2.1 五类场景穷举清单

1.2.2 场景确认规则

• 每类场景列出后，必须等待用户确认或补充，不能自问自答
• 如果用户说"结合场景"但没展开，必须追问："你说的场景具体指什么？至少包括设备、地点、时间、角色、业务五个方面，你分别说说"
• 场景确认完成后，才能进入问题清单生成
• 特别注意：任何涉及人使用系统的需求，必须考虑移动端，除非用户明确说"只用电脑"

1.2.3 场景-需求映射

确认场景后，将每个场景映射到具体需求：
- 每个场景下，用户需要什么功能？
- 每个场景下，有什么特殊约束？（如手机端网络不稳定、屏幕小）
- 不同场景之间是否有冲突？（如移动端要简洁 vs PC端要功能全）

1.3 问题清单生成

对拆解结果和场景穷举结果进行提问式审查，生成问题清单：

Q1: 用户说的"需求"是真需求还是伪需求？
Q2: 有没有未被提及但必须解决的问题？
Q3: 这个问题的本质是什么？（表面问题 vs 根本问题）
Q4: 如果不做这个项目，会怎样？（验证必要性）
Q5: 做了这个项目，可能引发什么新问题？（二阶效应）
Q6: 这个问题有没有已经被验证的解决方案？（避免重复造轮子）
Q7: 场景穷举中有没有发现遗漏的需求？（基于1.2的结果）

1.4 问题优先级排序

将问题按以下维度排序：
- 阻塞性：不解决就无法推进
- 影响面：影响多少功能/用户
- 紧迫性：时间窗口压力
- 可解性：当前条件下能否解决

产出：问题优先级矩阵，标注哪些问题必须在脑力风暴阶段解决。

Step 2: Solution Exploration (方案探索)

针对Step 1识别的高优先级问题，进行方案发散。

2.1 方案生成

对每个关键问题，生成至少3个候选方案：
- 方案A：常规方案（业界标准做法）
- 方案B：创新方案（非传统但有潜力的做法）
- 方案C：保守方案（低风险但可能不是最优）

方案生成时主动检索 self-evolution 的经验库：
- 检索 exp-pattern-library：过去类似项目选了什么方案
- 检索 exp-risk-library：过去类似方案踩过什么坑
- 在方案描述中标注"基于过往经验"的部分

2.2 方案维度分析

每个方案从以下维度分析（注意：不仅看技术，必须看业务场景覆盖度）：

> 经验教训 exp_20260715_001：首次实战方案矩阵全从技术视角出发，缺少业务场景和用户体验维度，导致方案评估脱离实际。

2.3 方案对比矩阵

将所有候选方案横向对比，产出决策矩阵：

         | 技术可行性 | 资源匹配 | 风险 | 扩展性 | 维护成本 | 团队匹配 | 总分
方案A    |    4      |    3    |  3  |   4   |    3    |    4    |  21
方案B    |    3      |    4    |  4  |   5   |    4    |    2    |  22
方案C    |    5      |    5    |  5  |   3   |    5    |    5    |  28

Step 3: Convergence (收敛决策)

3.1 淘汰与优选

• 淘汰总分明显偏低的方案（低于最高分70%）
• 对剩余方案进行深度分析
• 检索 exp-calibration-library：过去类似决策的偏差记录，校准当前判断

3.2 风险预判

对优选方案做风险预判：
- 列出Top 5风险
- 每个风险标注：概率（高/中/低）、影响（高/中/低）、应对方案
- 检索 exp-risk-library：过去类似项目遇到过什么风险

3.3 交付物清单（Deliverables Definition）

> 经验教训 exp-risk_20260715_007：脑力风暴跑完却没明确"要交付什么"，后续设计开发全是空中楼阁。项目前期必须明确所有交付物，否则团队不知道目标，验收没有标准。

脑力风暴的核心产出之一就是交付物清单。如果跑完脑力风暴，连"要交付什么"都没说清楚，那脑力风暴等于白做。

3.3.1 交付物分类框架

必须从以下6个类别逐一梳理，不能遗漏：

3.3.2 交付物确认规则

• 每个交付物必须标注：名称、格式、负责人（角色）、交付时间节点、验收标准
• 必须与用户逐一确认，不能AI自己假设
• 特别注意：非技术交付物（如培训材料、运营方案）容易被遗漏，必须主动列出
• 交付物清单是后续项目计划的输入——没有交付物清单，就无法做项目排期

3.3.3 交付物优先级

将交付物分为：
- P0 必须交付：上线前提条件，不交付系统无法运行
- P1 应该交付：上线后短期内需补齐，影响使用体验
- P2 可以延后：非核心，可迭代补充

3.4 决策输出

产出脑力风暴总结报告，必须包含以下内容：

## 脑力风暴总结

### 项目背景
[1-2句话描述项目]

### 核心价值
[Step 0识别的系统核心增量价值——相比现有工具解决了什么不可替代的问题]

### 核心问题
[Step 1识别的Top 3问题]

### 方案决策
- 选择方案：[方案X]
- 选择理由：[基于对比矩阵和经验库的分析]
- 放弃方案：[方案Y/Z]及放弃原因

### 风险清单
| 风险 | 概率 | 影响 | 应对方案 |
|------|------|------|---------|

### 界面预览（Layer 2）
[≥3个核心业务页面的UI线框图，展示系统关键交互]
- 页面1：[核心页面名] — [线框图]
- 页面2：[核心页面名] — [线框图]
- 页面3：[核心页面名] — [线框图]

### 效果模板（Layer 3）
[2-3种设计风格方向，标注适用场景和配色方案]
- 风格A：[风格描述] — [适用场景] — [配色方案]
- 风格B：[风格描述] — [适用场景] — [配色方案]

### 待确认事项
[脑力风暴无法决定、需要进一步调研的事项]

### 交付物清单
[Step 3.3产出的完整交付物清单，按6类分列，标注优先级]

| 优先级 | 类别 | 交付物名称 | 格式 | 负责人角色 | 交付节点 | 验收标准 |
|--------|------|-----------|------|-----------|---------|---------|
| P0 | 文档类 | ... | ... | ... | ... | ... |
| P0 | 开发类 | ... | ... | ... | ... | ... |
| P1 | 设计类 | ... | ... | ... | ... | ... |
| P2 | 运营类 | ... | ... | ... | ... | ... |

### 经验引用
[本次决策引用了哪些过往经验，格式：exp_YYYYMMDD_NNN]

3.5 产品概念验证

脑力风暴结束时，必须确认用户对以下问题有清晰的概念：

1. 系统架构长什么样？ — 最终系统架构图（Layer 1）
2. 核心页面长什么样？ — ≥3个关键页面线框图（Layer 2）
3. 视觉风格走什么方向？ — 2-3种设计风格方向（Layer 3）
4. 关键交互流程是什么？ — 核心操作流程的可视化（Layer 1+2）
5. 系统在不同场景下怎么用？ — 场景-界面映射（Layer 1+2）
6. 项目要交付什么？ — 完整交付物清单（P0/P1/P2分级，含验收标准）

如果用户对以上任何一个问题没有清晰概念，脑力风暴不算完成。

Discussion Facilitation (讨论引导)

在脑力风暴过程中，AI应主动引导讨论方向：

引导技巧

• 追问法：当用户提出一个方案时，追问"为什么选这个？""有没有其他可能？"
• 反证法：主动提出反面观点"如果这个方案失败了，可能是什么原因？"
• 类比法：检索经验库，提供"上次类似项目我们是怎么做的"
• 极端法：提出极端场景"如果用户量突然增长10倍，这个方案还成立吗？"
• 约束法：引入约束"如果预算减半，方案要怎么调整？"

防止跑偏

• 讨论偏离核心问题时，拉回："这个话题很重要，但不是今天脑力风暴的核心，我们先聚焦[核心问题]"
• 讨论陷入细节时，提升视角："我们退一步看，这个细节影响整体方案选择吗？"
• 讨论只发散不收敛时，强制收敛："我们已经讨论了X个方案，现在需要做选择了"

Experience Integration (经验集成)

本Skill与 self-evolution Skill的集成点：

读取经验（脑力风暴开始时）

1. 识别当前项目类型和场景关键词
2. 到 self-evolution 的子Skill库中检索相关经验：
   - exp-pattern-library → 检索方案模式
   - exp-risk-library → 检索风险预判
   - exp-calibration-library → 检索决策校准
3. 将匹配的经验作为上下文注入方案生成过程
4. 在方案分析中标注"基于经验 exp_YYYYMMDD_NNN"

写入经验（脑力风暴结束时）

1. self-evolution Skill的Phase 2会询问用户是否有收益
2. 若有收益，self-evolution 的Phase 3-4会自动总结并分类存储本次脑力风暴的经验
3. 本Skill提供脑力风暴的完整过程记录供 self-evolution 总结使用

Quality Gate (质量自检)

> 经验教训 exp_20260715_001 + exp-calibration_20260715_001：首次实战中AI自评"良好"但用户评分"20分"，根本原因是AI把"走完流程"等同于"做完了事"。

每个Step结束后，AI必须自问以下问题，全部通过才能进入下一步：

Step 1 质量自检

• [ ] 场景穷举的5类场景是否逐一与用户确认？（不能AI自己假设）
• [ ] 是否考虑了移动端？（除非用户明确说只用电脑）
• [ ] 每个高优先级问题是否追问到底？（不能点到为止）
• [ ] 用户的需求描述中有没有模糊词未展开？（"结合场景""实际情况"等）
• [ ] 是否深挖了"内容生产"环节？（系统核心内容怎么产生？用户写起来难不难？）
• [ ] 是否识别出AI辅助的空间？（哪些环节AI能帮忙？）
• [ ] 是否输出了场景-需求映射图和AI辅助流程图？（Layer 1）
• [ ] 关键场景是否有界面预览草图？（Layer 2，如"出差手机审批"界面）

Step 2 质量自检

• [ ] 方案矩阵是否包含"业务场景覆盖度"和"用户体验适配"维度？
• [ ] 每个方案是否说明了在不同场景下的表现？
• [ ] 是否检索了经验库（exp-risk-library等）？
• [ ] 方案探索是否围绕Step 0识别的核心价值展开？（不能只做流程架构）
• [ ] 是否包含"内容生产"维度的方案？（如AI辅助写计划、模板引导等）
• [ ] 每个候选方案是否有架构图？方案间是否有图对比？（Layer 1）
• [ ] 价值评估模型是否有可视化？（Layer 1）
• [ ] 价值评估结果展示是否有界面预览草图？（Layer 2，如领导评分面板）

Step 3 质量自检

• [ ] 风险预判是否包含"形式主义"风险？（控制导向系统必查）
• [ ] 决策输出是否基于场景确认结果，而非纯技术分析？
• [ ] 待确认事项是否列出？（不能假装全部搞定）
• [ ] 是否产出了完整交付物清单？（6类：文档/设计/开发/部署/数据/运营）
• [ ] 交付物清单是否标注了优先级（P0/P1/P2）、负责人、交付节点、验收标准？
• [ ] 非技术交付物（培训材料/运营方案/用户手册）是否被列出？（最容易遗漏）
• [ ] 交付物清单是否与用户逐一确认？（不能AI自己假设）
• [ ] 是否输出了最终系统架构图（含模块关系和数据流向）？（Layer 1）
• [ ] 是否输出了风险矩阵图？（Layer 1）
• [ ] 用户举的关键例子是否已图化？（Layer 1）
• [ ] 是否输出了核心业务页面线框图（≥3个关键页面）？（Layer 2）
• [ ] 是否输出了2-3种设计风格方向的效果模板？（Layer 3）
• [ ] 用户是否对"系统最终长什么样"有了清晰的概念？（最终产出标准）
• [ ] 用户是否对"项目要交付什么"有了清晰的概念？（交付物标准）
• [ ] 所有图是否有专业配色和标注，不是干巴巴的草图？（美术质量标准）

如果任何一项不通过，必须回到对应Step重新执行。

References

references/question-framework.md

问题发现的详细提问框架和示例。

references/decision-matrix-template.md

方案对比矩阵的模板和填写指南。