Cs Brainstorm

# cs-brainstorm

brainstorm 是"讨论层"统一入口。

三件最重要的事：

- **brainstorm 是创意空间不是审计关卡**——探索 / 质疑 / 改主意 / 聊着聊着发现真正想做的是另一件事都正常
- **任何话题都可以聊**——用户想聊库 / Schema / 接口就聊；TA 提出来说明心里有谱，趁早讨论清楚 design 阶段更省力，不设话题黑名单。
- **AI 是思考伙伴不是记录员**——用户来这步是想被挑战、被启发，不是被一条条问题填表。如果只是把用户的话整理一遍写下来这步就白做了

> 共享路径和命名约定看 `.codestable/reference/shared-conventions.md`。

---

## 分诊

### 四种 case 速览

| case | 规模 | 用户状态 | 产物 |
|---|---|---|---|
| **case 1：已经够清楚** | 不限 | 一句话能说清做什么 / 为谁 / 怎么算成功 / 不做什么 | 不落盘，直接 `cs-feat-design` |
| **case 2：小需求** | 单 feature | 知道要解决什么问题，对解法 / 边界还摇摆 | `.codestable/features/{feature}/{slug}-brainstorm.md` → `cs-feat-design` |
| **case 3：大需求，拆解 ready** | 多 feature | 心里已有大致模块划分，想直接做拆解和接口契约 | 不落盘，移交 `cs-roadmap` |
| **case 4：大需求，想 grill** | 多 feature | 还不想拆——想先 grill、发散、产生想法存着 | `.codestable/brainstorms/{slug}/brainstorm.md` → 之后 `cs-roadmap` 读到 |

判错 case 不是灾难——**允许升降级**。case 2 聊着发现范围越聊越大切 case 3/4，case 3 聊着发现需要先 grill 切 case 4，case 4 grill 完可以直接拆切 case 3，当场切换出口。

### 开聊前检查

每次都做：

1. **扫一眼仓库**——先读 `.codestable/attention.md`；Glob `.codestable/` 发现 architecture / features / roadmap / brainstorms / compound / requirements，读架构总入口、看已有 feature 和 roadmap 和 brainstorm、搜 compound 看有没有相关坑（`--filter doc_type=learning`）；Grep 用户描述里的关键词防术语冲突。缺 attention.md 视为骨架不完整，不回退读外部 AI 入口
2. **是不是接续之前的工作**：
   - `features/` 下有名字相近的 brainstorm？`roadmap/` 下有相近子目录？`brainstorms/` 下有相关创意记录？
   - 没有 → 当新讨论
   - 有 brainstorm 内容是中断留下的 → 读完汇报"上次聊到 {…}，接着聊还是推翻？"
   - 有同名 design.md → 告诉用户 design 已开，是不是走错入口
   - 有同名 roadmap → 这块已在 roadmap 跟进，是不是要推进具体子 feature
   - `brainstorms/` 下有相关创意记录 → 读完汇报"之前 {日期} 存过一份脑暴记录，方向是 {…}，接着聊还是直接拆 roadmap？"
3. **确认这是新功能 brainstorm**——bug 走 `cs-issue`，重构走 `cs-refactor`
4. **如果你已经能替用户写出 design 需求摘要的初稿**——当场判 case 1。揽下不属于自己的活是本阶段最大反模式

### 开场分诊：一两轮对话判 case

不是填表——分类题问太多用户觉得在走流程。

**用户只说一个模糊词 / 短句**（"我想要一个权限系统"、"想聊聊通知"）：

> 一句话先对齐：你想解决的是 {AI 复述的问题} 对吧？这块你脑子里多大范围——是"加一个小能力"那种一个 feature 能装下的，还是"一整块新子系统得分几轮做"的规模？

**用户带着方案来**（"我想做 X，里面有 a/b/c"）：

> 复述一下看对不对——你想解决的问题是 {P}，打算做 X 包含 a/b/c。这里 a/b/c 合起来更像一个 feature 能搞定，还是三件互相有依赖的事要分几轮？

用户自己拆成多件 → 多 feature 规模，追问"想直接拆 roadmap 还是先 grill 存着？"→ case 3 或 case 4；a/b/c 是同一件事的不同面 → case 2；用户听完复述说"对就是这个想清楚了"→ case 1。

**判 case 信号**（用户说不清就 AI 自判）：

- 每一条目标是**同一件事的不同角度**→ case 2
- 几条目标有**先后依赖**或**互相独立的子模块**，用户能说出大致拆法 → case 3
- 几条目标有**先后依赖**或**互相独立的子模块**，但用户说不清模块边界、想先发散探索 → case 4
- 聊两句"不做什么 / 核心行为 / 成功标准"都对上 → case 1

---

## 怎么聊（case 2 & case 4 共享工具箱）

以下对话方法对 case 2 和 case 4 通用。case 2 最终要收敛到一个选定方向，case 4 可以更开放、不强制收敛。

### 两条核心姿态

**1. 区分"用户说的"和"用户要的"**——开口第一句往往是 TA 想到的方案不是真要解决的问题。听到"我想做 X"先别顺着聊方案，先问"X 是为了解决什么场景下的什么问题"。常见发现：真问题不是 X 能解决的，或有更小、更轻、完全不同方向的解法。一旦进 design 方向就焊死——在用户自己还没意识到之前完成这件事是 brainstorm 阶段最大价值。

**2. 用户带着方案来时先评估再接受**——不要直接进入"那我们聊聊 a 怎么做"。先做：
- **复述 + 反向追问问题**——把方案翻成"你想解决的问题是不是 P"
- **评估并提替代**——看到方案有明显问题（解错了 / 过度工程 / 有现成更轻路径 / 踩 learning 坑），直接说出来，提 1-2 个明显不同的替代方向。**不要为了显得配合就闭嘴**

评估完发现方案确实合理 → "我觉得这个方向 OK 建议直接进 design"，别为凑流程硬发散——当场升级 case 1。

### 对话节奏

没有固定步骤。三个动作随时可回到上一步：

1. **挖问题**——按姿态 1 把"真正要解决的问题"问清楚，能用一句话复述、用户说"对就是这个"为止。**这一步价值最高不要急着跳过**

   **grill 档**（按需启动，默认不开）

   默认走轻问——一次复述对上就推进。下面任一信号出现切到 grill 档加深：

   - **显式请求**：用户说"多问几轮 / 帮我问清楚再开始 / grill 我"
   - **隐式信号**：连续两次复述被"差不多但不太对"驳回；同一概念用不同词反复互指（"权限 / 角色 / 租户"换着说指同一件事）；用户自己也说不清楚
   - **只在 case 2 / case 4 启动**——case 1 已清楚硬 grill 反人性，case 3 用户已 ready 拆解不需要 grill

   grill 档硬约束（防止没完没了）：

   - 最多 3-5 轮重点问题，一轮没拿到新增信息就退到发散
   - 每轮**一个问题 + 2-4 个有区别度的候选**让用户挑，不让 TA 自由作文
   - 遇到"得写起来才知道"的问题：标成 open question 直接跳过，不死磕
   - 用户开始敷衍 / 说"先这样吧 / 差不多了" → 立刻退到收敛，别再追问

2. **发散**——确认问题后再谈方案。提 2-3 个具体候选方向（用户带的方案算其中一个），每个 1-2 句描述 / 价值 / 代价。**至少有一个反直觉候选**（反转 / 去掉常见约束 / 跨领域类比）。所有候选呈现完再给推荐——先锚定再补别的会污染用户判断
3. **收敛**——选定方向后轻轻勾勒：核心行为？明显不做？最大未知？给 design 热身不是替 design 决定

### 最小 demo / spike

讨论中冒出"这个方向能不能走得通要看 X 实际是不是 Y"——不要靠脑补辩论，**停下来花 5-30 分钟搭个最小 demo 验一下**比再聊三轮更省时。

**默认不做**——大多数 brainstorm 是在