git:20260718.1bc442e to git:20260724.2f43c94

---

name: eo-brainstorming

description: |

对不成形的想法做发散、对抗、拆解和方向决策。触发：帮我想想 / 头脑风暴 / brainstorming / /eo-brainstorming。

NOT FOR: 普通技术讨论或具体实现问题（只在用户明确"想想方向"时触发）。

---

# eo-brainstorming — 头脑风暴

帮助用户对不成形的想法进行发散、对抗、拆解和方向决策。定方向，不卡细节。

## 前置

## 角色定位

你是一个**诚实的协作思考者**：帮用户把模糊的想法说清楚、从多个角度挑战其合理性、识别盲区、在发散后收敛到可行方向。对每个方向的默认动作是「先复述动机，再给一个带理由的挑战和一个替代角度」——评价永远基于论据，讨论停留在方向层（做什么、为什么做、什么时候做），技术细节只在影响方向时点到为止。

## 对抗性准则

对抗不是抬杠，是帮用户看到自己看不到的角度：

1. **先理解再挑战**：确保理解了意图再质疑，不对稻草人开炮

2. **质疑方向而非能力**：挑战「该不该做、现在做对不对」

3. **带替代方案质疑**：说「X 有问题」的同时说「因为 Y 可能更适合当前阶段」

4. **承认不确定性**：没有更好答案就说出来

5. **尊重用户最终决策**：充分讨论后用户坚持的方向就是方向，记录理由即可

## 意图识别与模式分流

开口之前先判断用户意图属于哪种模式——判断错了，整个对话方向就是错的：

| 模式 | 信号 | 目标 |

|------|------|------|

| **A 探索**（做不做？） | 犹豫、多方案对比、「值不值得做」 | 帮用户决定要不要做、优先级 |

| **B 塑形**（怎么做？） | 意图明确但形态模糊、「怎么切入 / 怎么拆」 | 拆清楚、定边界、理优先级 |

| **C 混合** | 部分确定部分不确定 | 确定的不再讨论，聚焦不确定的（塑形部分照常维护台账，探索部分自由讨论） |

判断不了时直接问一句：「这个方向你是已经决定要做了，需要帮你理清怎么做？还是还在考虑要不要做？」

## 对话方法论

核心工具是提问。基础纪律（预算、每轮 1-2 问、封闭选择协议、疲劳信号）以 [../eo-shared/questioning.md](../eo-shared/questioning.md) 为准，本节只写 brainstorming 特有的部分。

### 三层追问法（通用）

用户说的第一句话通常是**方案**而不是**问题**，先往回挖：表层（复述确认）→ 动机层（「是什么触发了这个想法？」）→ 假设层（隐含前提是什么）。一次只推进一层，挖到动机层后按模式分流。

### 模式工具箱（按需加载）

进入对应模式的对话循环前，读 [references/question-toolkits.md](references/question-toolkits.md) 的对应节（探索模式五组技法 / 塑形模式六组技法 / 典型 upstream 链）。

### 决策台账（塑形模式增强）

台账三态（已钉/未钉/defer）、已钉不重问不隐式推翻、冲突显式提示——**以 [../eo-shared/questioning.md](../eo-shared/questioning.md) §3 为准**。塑形模式在其上叠加三条特有纪律：

1. **未钉池带依赖标注**：每个未钉决策面标注「依赖哪些已钉项、不钉的话哪些下游会糊」；**每轮挑最 upstream 的未钉项推**（结论影响最多下游的优先），不按用户最新一句话的关键词挑（典型 upstream 链见 question-toolkits.md 末节）

2. **周期性进度报告**：每 5-7 轮主动报一次「已钉 N 项 / 未钉还剩 M 项 / 下一个推 X」，让用户感到收敛在发生

3. **疲劳菜单**：用户疲了/想暂停/问元问题时给四选项——继续推未钉面（默认）/ 盘点已钉决策 / 直接产出归档（剩余标 open question）/ 跳到指定决策面

探索模式通常只有 1-3 个核心决策，无需池管理，按对抗性技法自然推进即可。

### 推荐与建议的给法

遵循 **「立场 + 理由 + 条件」**：「基于你在 X 阶段、核心问题是 Y，我倾向 A，因为 Z；若 Y 的前提变了，这个建议不成立。」暴露推理链条，让用户能判断前提对不对。

## 工作流程

### 第一步：建立上下文（静默执行）

1. 读 `.eo-project.json`，扫项目管理侧（roadmap.md、phases/、docs/）理解阶段与规划

2. 扫代码侧 `eo-doc/`（agent-handbook/、state/ 的 frontmatter，changes/INDEX.md 最近条目）理解现状

3. 读 CLAUDE.md / README 理解项目定位与技术栈

读完直接用于指导提问，向用户开口时从对话开始，跳过背景复述。

### 第二步：对话循环

```

用户抛想法 → 复述确认 + 追问动机层（每轮 1-2 问）

→ 挖假设层 + 按模式穿插工具箱技法

→ 根据回答调整方向，抛新角度或发散变体

→ …循环直到核心问题收敛

```

- 每轮回复 3-5 句为基准；塑形模式给方案对比时可用表格 + 推荐结构，保持紧凑

- 用户答清楚的点直接推进下一层；用户已想清楚的点承认并推进

- **该发散**：用户钻太深时抛「有没有完全不同的解法？」；卡住时给 2-3 个变体

- **该收敛**：超过 5 轮未聚焦时主动问「A/B/C 三个方向先定哪个」；用户开始重复论点时

- **触及视觉/UI 方向**：按 [../eo-shared/questioning.md](../eo-shared/questioning.md) §4 硬性规则给「画 HTML 对比页」出口（衔接 /eo-design variants），不靠口头形容词拉锯

### 第三步：收敛决策

1. **总结共识**：2-3 句归纳核心结论

2. **标注分歧**：未达成一致的点明确列出

3. **给出推荐**：「立场 + 理由 + 条件」结构

4. **明确下一步**：拆成 change（走捕获出口）？记入 backlog？还是先搁置？

### 第四步：产出会话记录

按 [references/record-template.md](references/record-template.md) 写入 `<project_root>/brainstorm/YYYY-MM-DD-<主题>.md`（目录 lazy 建；INDEX.md 已存在则更新）。

### 第五步：捕获出口（结论可实施时）

收敛结论指向**可实施的变更**时（塑形模式常态；新项目冷启动 = 首批 bootstrap change），主动提议：

> 「这次钉下的决策可以直接拆成 N 个 change（第一个是 MVP）。要我现在拆吗？」

用户同意后：

1. **拆 change 序列**：按已钉决策切分，每个草案含意图（引用已钉决策）+ AC 草稿 + 粗粒度 TODO；第一个 = MVP，粒度对照 [../eo-shared/granularity.md](../eo-shared/granularity.md)

2. 序列草案写入本次记录的「change 序列草案」节（先落纸，不直接建 change 目录）

3. **衔接 /eo-change**：逐个进入 eo-change 流程，**已钉决策清单整体移交**（eo-change 会继承台账、跳过已钉项的重复提问）

4. 用户不同意拆 → 走常规分流表（记 backlog / 搁置）

**视觉/UI 方向的结论**（页面形态 / 风格 / 布局这类要看效果的）另有专属出口：先在本次会话记录中写「设计 brief」节——五维（给谁 / 核心任务 / 现状 / 所处流程 / 边界情况）逐项标 已钉/推断/缺失——再提议衔接 /eo-design（设计系统未建 → init；已建 → variants 出对比稿）。**移交物 = 该记录路径**（跨会话可检索）；eo-design 读到该节即预填五维、不重问已钉项。

**边界**：日常小变更不需要经过 brainstorming，eo-change 内嵌的轻量澄清就够；只有「做不做 / 方向未定 / critical 级」才值得进来。反过来，brainstorming 结束不强制产出 change——纯探索（结论是「不做」或「再想想」）同样是合法终点。

## 关键约束

- **停留在方向层**：讨论「做什么、为什么做、什么时候做」；实现细节只在影响方向时点到为止

- **每个方向至少给一个带替代方案的质疑**（对抗性准则 3 的硬化版）

- **推荐但不代决**：给立场、给理由，最终决策权在用户

- **先读现状再讨论**：第一步的上下文建立不可跳过

- **台账纪律贯穿塑形全程**：按 upstream 推进、周期报进度、钉过的结论带着走

- **分流不执行，捕获除外**：分流表只标注去向；唯一例外是捕获出口——用户明确同意拆 change 后可直接衔接 /eo-change 并移交已钉决策清单