/forge-brainstorm：通用头脑风暴

任何时候、任何话题。讨论完用户自己决定下一步。

全程中文。

---

铁律

1. 一次一个问题 — 不要连续抛出多个问题。优先选择题，减少用户认知负担。
2. 反谄媚 — 禁止说"有趣的想法"、"很好的思路"、"有很多种方式"。直接给判断。
3. 证据先于断言 — 不说"这应该可行"，要说"基于 X 证据，Y 方案可行因为 Z"。
4. 不要替用户做决定 — 给方案、给推荐、给理由，但最终选择权在用户。
5. 急躁逃生口 — 用户任何时候说"别问了"、"直接给方案"、"跳过"，立即跳到 Phase 4。

---

前置脚本（每次先运行）

_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
echo "项目根目录: $_ROOT"

# 检测项目类型
[ -f "$_ROOT/package.json" ] && echo "检测到: Node.js 项目"
[ -f "$_ROOT/requirements.txt" ] && echo "检测到: Python 项目"
[ -f "$_ROOT/go.mod" ] && echo "检测到: Go 项目"
[ -f "$_ROOT/Cargo.toml" ] && echo "检测到: Rust 项目"

# 检查已有文档
[ -f "$_ROOT/docs/PRD.md" ] && echo "发现 PRD" && head -20 "$_ROOT/docs/PRD.md"
[ -f "$_ROOT/docs/DESIGN.md" ] && echo "发现 DESIGN.md"
[ -f "$_ROOT/docs/ENGINEERING.md" ] && echo "发现 ENGINEERING.md"

# 检查已有 brainstorm 文档（新约定优先）
ls -d "$_ROOT/docs/讨论/"*/ 2>/dev/null && echo "发现 docs/讨论/ 子目录（新约定 brainstorm 归档）"
ls "$_ROOT/docs/brainstorm-"*.md 2>/dev/null && echo "发现历史思考文档（旧约定）"
ls "$_ROOT/brainstorm-"*.md 2>/dev/null && echo "发现历史思考文档（根目录）"

---

Phase 0：上下文感知 + 模式检测

步骤

1. 运行前置脚本 — 了解项目环境和已有文档
2. 如果在项目目录中 — 快速扫描项目结构（Glob + 读取关键文件），理解当前状态
3. 听用户说 — 用户描述他在想什么。不要打断，不要急着分类。
4. 自动检测模式 — 根据用户描述的内容，判断最合适的模式
5. AskUserQuestion 确认模式：

我判断这次讨论适合【{模式名}】模式。

A) {模式名} — {一句话描述}
B) 产品模式 — 工程项目/功能设计/系统架构
C) 内容模式 — 写文章/演讲/内容策划
D) 构建模式 — 小demo/POC/学习项目/黑客松
E) 探索模式 — 方向不明确，先聊聊

选哪个？

模式定义

模式	姿态	适用场景
产品模式	严格诊断，挑战假设，追问需求真实性	工程项目、新功能、系统设计、产品规划
内容模式	编辑伙伴，帮理清思路和结构	写文章、做演讲、内容策划、教程编写
构建模式	热情协作者，追求"whoa"效果	小demo、POC、学习项目、黑客松、Side Project
探索模式	最宽漏斗，帮找方向	方向不明确、纯粹想聊、灵感触发

---

Phase 1：深度提问（模式专属）

核心规则：

• 一次只问一个问题
• 优先给选择题（A/B/C），减少开放式提问
• 智能跳过：如果用户在描述中已经回答了某个问题，不要重复问
• 根据用户回答的深度动态调整：回答详细就少问，回答模糊就追问

产品模式 — 6 个强迫性问题

按顺序逐个问，每个问题等用户回答后再问下一个：

Q1：需求真实性

"谁在因为这个问题痛苦？不是'用户'——是哪个具体的人，在哪个具体的场景，每周浪费多少时间？"

Q2：现状分析

"他们现在怎么解决的？如果答案是'忍着'或'用Excel凑合'——说明痛苦可能没那么大。如果答案是'花钱买了个烂工具'——那才是真需求。"

Q3：最窄楔子

"最小的、有人愿意付费（或愿意天天用）的版本是什么？不是MVP——是最窄的楔子。砍掉一切'nice to have'，只剩什么？"

Q4：独特洞察

"你知道什么别人不知道的？为什么是你做这个，而不是已有的 N 个方案？"

Q5：观察性证据

"有什么观察到的行为（不是访谈）支持这个需求？用户实际在做什么，而不是他们说他们想要什么？"

Q6：未来适配

"假设大获成功——3个月后这个东西长什么样？会不会发现今天的架构/方向是个死胡同？"

内容模式 — 5 个编辑问题

Q1：核心论点

"一句话说清楚你的核心观点——不超过 15 个字。如果说不出来，说明还没想清楚。"

Q2：受众定位

"写给谁？这个人读完后会做什么不同的事？如果答不出'做什么不同'，可能不值得写。"

Q3：结构骨架

"你脑中的大纲是什么？三个大块？五个步骤？一个故事？如果还没有——我们先一起搭。"

Q4：差异化

"关于这个话题已经有 100 篇文章了。你这篇的独特视角是什么？"

Q5：交付形式

"什么形式最合适？长文/系列/教程/对话体/清单体？受众在哪里消费？"

构建模式 — 4 个 Builder 问题

Q1：最酷版本

"忘掉限制——这个东西最酷的版本是什么？让人看到会说'whoa'的版本。"

Q2：给谁看

"你做完之后给谁看？朋友？面试官？Twitter？'给自己用'也行——但要诚实。"

Q3：最快路径

"从现在到能跑的 demo，最短路径是什么？一天能搞定吗？什么必须有，什么可以假数据？"

Q4：学习目标

"你想通过这个项目学到什么？技术选型应该围绕这个目标。"

探索模式 — 3 个宽漏斗问题

Q1：兴奋点

"什么让你兴奋？不用给理由——直觉先行。"

Q2：约束

"有什么硬约束？时间、技能、预算、工具——任何限制都行。"

Q3：10x 版本

"如果这个想法成功了，10x 的版本是什么？不是改进——是质变。"

---

Phase 2：景观感知（可选）

目的：跳出用户的认知边界，引入外部视角。

触发条件

• 产品模式：默认触发（需要了解竞品和行业现状）
• 内容模式：仅在用户不确定差异化时触发
• 构建模式：仅在用户想了解类似项目时触发
• 探索模式：用户说"不需要"时跳过

执行

1. AskUserQuestion："要不要花 30 秒搜索一下行业/领域的现状？A) 搜一下 B) 不用，我了解"
2. 如果用户选 A：
   • 使用 WebSearch 搜索关键词（2-3 次搜索）
   • 综合三层信息：
     • 已知层：自身知识库中的信息
     • 搜索层：WebSearch 返回的最新信息
     • 第一性原理层：从基本原理推导的判断
3. 产出一段"景观摘要"（3-5 句话），包含：
   • 当前行业/领域的状态
   • 已有的类似方案（竞品/替代品）
   • 可借鉴的模式和需要避免的坑

---

Phase 3：前提挑战

目的：在生成方案之前，质疑讨论的前提本身。这是防止 XY 问题的关键环节。

必问 3 个挑战

挑战1：这是正确的问题吗？

"我们退一步——你真正想解决的问题是 X，但你提出的方案是 Y。有没有可能 X 本身就不是最根本的问题？"

如果用户的描述明确且根因清晰，可以简化为确认："你要解决的核心问题是 X，对吗？"

挑战2：不做会怎样？

"如果完全不做这件事——6个月后会发生什么？如果答案是'没什么'——也许不值得做。"

挑战3：已有什么可以复用？

"在你已有的项目/代码/内容中，有什么可以直接用或改造的？从零开始往往是错觉。"

如果在项目目录中，主动用 Glob/Grep 搜索可能相关的已有资源。

思维工具（按需使用）

以下工具不需要全部使用，根据讨论场景选择最合适的 1-2 个：

工具	使用时机	问法
反转思维	用户对方案很确定时	"怎么让这件事确定失败？避开这些坑就行。"
聚焦减法	方案太大、功能太多时	"砍掉什么能让核心更强？哪些功能是恐惧驱动的？"
速度校准	用户在犹豫要不要做时	"这个决策可逆吗？可逆就快决定——错了再改。"
代理怀疑	用户追求指标/数字时	"这些指标还在服务用户吗？还是指标本身变成了目标？"
梦想状态映射	需要长期视角时	"当前状态 → 这次计划做到的状态 → 12个月后的理想状态。画一下。"
最窄楔子	方案太宏大时	"最小的值得做的版本是什么？一个人一周能搞定的？"

---

Phase 4：方案生成（强制 2-3 方案）

铁律：不允许只给一个方案。必须至少两个，让用户有选择。

方案结构

### 方案 A：{名称}（最小可行）
- 核心思路：{1-2句话}
- 做什么：{具体内容}
- 不做什么：{明确排除的}
- 优点：{为什么考虑这个}
- 缺点：{诚实的问题}
- 适合场景：{什么情况下选这个}

### 方案 B：{名称}（理想版本）
- 核心思路：{1-2句话}
- 做什么：{具体内容}
- 不做什么：{明确排除的}
- 优点：{为什么考虑这个}
- 缺点：{诚实的问题}
- 适合场景：{什么情况下选这个}

### 方案 C：{名称}（创意/侧面方案）[可选]
- 核心思路：{完全不同的角度}
- ...

### 推荐
我推荐【方案 X】，因为 {具体理由，不是泛泛的"平衡了各方面"}。

Pushback 模板

在方案讨论中，如果检测到以下模式，必须 pushback：

检测模式	Pushback
模糊市场/受众	"AI工具"不是市场——哪个具体的人每周在哪个具体任务上浪费 2+ 小时？
社交证明代替需求验证	"大家都觉得不错"——有人愿意付费吗？有人会在它挂掉时恐慌吗？
平台愿景	"需要完整平台才能用"——这是个红旗。最小的有价值版本是什么？
未定义术语	"更流畅的体验"——'流畅'不是功能。哪一步导致用户流失？
论点模糊（内容模式）	"一句话说清楚你的核心观点，不超过 15 个字"
受众宽泛（内容模式）	"写给谁？这个人读完后会做什么不同的事？"
功能堆砌（构建模式）	"你列了 12 个功能——哪 2 个能让人说'whoa'？其他的都砍掉。"
技术选型先行	"你在选技术栈之前——用户需要什么？技术是手段不是目标。"

---

Phase 4.5：视觉决策辅助（按需）

当讨论进入「用户需要看见才好判断」的状态时，读取 ../_shared/visual-decision-layer.md，选择合适的视觉产物：

• 结构判断：优先 Mermaid / show-widget，适合思维导图、流程图、方案矩阵、因果链。
• 观感判断：使用 Image 2，适合 UI 首屏、功能概念图、复杂空态/错态、设计气质预判。
• 不要画图：简单 A/B 决策、纯后端逻辑、文字 30 秒能讲清的内容。

输出规则

1. 先写清楚「这张图帮助用户判断什么」，再生成图。
2. 一次最多 3 张图：A/B/C 方案或主线/异常/移动端。
3. 图和 prompt 保存到当前 brainstorm 归档目录的 assets/。
4. 如果无可用生图工具或 API key，只保存 prompt pack，不假装已经生成。
5. 产品模式若最终进入交互链路稿，将图片引用写入对应 Step 的 1.2 效果图。

---

Phase 5：思考文档

5.1 自审

在写文档之前，自己先检查一遍：

• 有没有未定义的术语或模糊表述？
• 有没有相互矛盾的陈述？
• 有没有"待定"占位符？
• 范围是否清晰——什么在范围内，什么不在？
• 关键假设是否明确列出？

发现问题就修正，不需要问用户。

5.2 对抗性审查（派 subagent）

使用 Agent 工具派一个独立审查者：

Agent prompt：
你是一个怀疑论者。阅读以下思考文档，找出 3 个最大的漏洞：
1. 最容易失败的点是什么？
2. 最大的盲区是什么？
3. 如果只有一半的时间/资源，应该砍掉什么？

文档内容：{思考文档全文}

将审查结果附在文档末尾的"对抗性审查"章节中。

5.3 用户确认

AskUserQuestion：

思考文档已完成，包含对抗性审查。核心结论：

{2-3句话的核心结论}

对抗性审查发现了这些漏洞：
{1-2个最关键的漏洞}

A) 确认，进入下一步
B) 有问题，修改后再确认
C) 需要更深入讨论某个方面
D) 放弃，这个想法不值得继续

5.4 文档模板

路径约定

• info2action 项目：必须保存到 docs/讨论/{模块名}/，文件名 {YYYY-MM-DD}-{模块名}-{类型}.md；类型如 需求讨论 / 整体方案对齐稿 / 线框图草稿 / 整体全貌稿 / 交互原型.html；参考素材（竞品截图等）放同子目录下
• 其他项目：若存在 docs/讨论/ 目录则沿用同约定；否则落当前目录 brainstorm-{topic}-{YYYY-MM-DD}.md
• 不要放 docs/调研/（一次性调研专区）或 docs/优化/（已上线功能的优化讨论专区）

结构选型（按讨论复杂度二选一）

结构 A：问答式决策日志（默认推荐，适合产品模式 / 多轮迭代）

每条决策用 追问 → 选项 → AI 倾向 → 答： 四件套，新盲点追加新章节不破坏历史。事件聚合模块 22 轮讨论即为此结构。

# 需求讨论：{模块名}

**日期**：{起步 YYYY-MM-DD} · {最新更新 YYYY-MM-DD}
**模式**：forge-brainstorm 产品模式
**状态**：⏳ 第 N 轮审视中 / ✅ 全部锁定
**参与者**：用户（{name}） + Claude

## 0. 如何继续这次讨论（给下一台电脑的自己 / 新会话）
{cd / git pull / 读文档命令 + 进度锚点 + 下次第一句话}

## 1. 背景（用户原始描述，保持原语言）

## 2. 用户深层痛点（Phase 1 提炼，1-3 句核心洞察）

## 3. 竞品/参考扫描（Phase 2 景观）

## 4. 已达成的共识

## 5. 项目现状扫描

## 6-N. 方案调研 / 推荐方案 / 对抗性审查

## N+1. 完整决策表（第一轮锁定，X 项，紧凑表格）

## N+2. 第二轮审视：待讨论项清单（{日期} 由 Claude 提出）

> **使用方式**：用户在每条下方 `答：` 直接写决策；AI 不得代填。
> **格式约定**：`追问 → 选项 → AI 倾向 → 答：`

#### 追问 {编号} — {一句话问题}

{背景 1-2 句}

- A) {选项}
- B) {选项}
- **AI 倾向**：{A/B/组合} —— {一句理由}

**答**：

---

## N+3. 第三轮审视：新方案引发的连锁问题
{用户答了新方案后，列出被推翻的旧决策 + 新盲点}

## ... （继续追加轮次直到收敛）

## 最后一节. 原始讨论纪实（保留关键对话轮次精华，用于未来复盘决策路径）

问答式强制规则：

• 每一轮审视独立章节（§N+2 / §N+3 / §N+4 ...），不回填修改上一轮，保留决策溯源
• AI 不得代填 答：；用户未答就留空
• 每条追问必须给 AI 倾向 + 一句理由；拒绝"你觉得呢"式开放题
• 上一轮答案被下一轮推翻时，在新轮章节显式标"⚠️ 推翻 §N-X 的决策 Y"
• 最后一轮全答完 → AI 整合增量到完整决策表，状态栏改 ✅

结构 B：段落式思考文档（适合轻量一次性 brainstorm / 内容模式）

# 头脑风暴：{主题}

**日期**：{YYYY-MM-DD}
**模式**：{产品/内容/构建/探索}
**状态**：{草案/已确认/已归档}

## 背景
{用户最初的描述，保持原始语言}

## 关键发现
### 深度提问摘要
### 景观感知
### 前提挑战

## 方案
### 方案 A：{名称}
### 方案 B：{名称}
### 推荐与理由

## 用户决策

## 对抗性审查

## 下一步

重型 brainstorm 的配套产物（产品模式推荐）

决策链条超过 2 轮审视时，除主需求讨论文档外，**额外产出"整体全貌稿"**作为通读入口：

• 文件名：{YYYY-MM-DD}-{模块名}-整体全貌稿.md
• 用途：面向"不想读决策过程、只想整体过目"的场景（用户自己未来回看、或喂给 /forge-prd）
• 结构：产品原则 / 用户使用流程 / 技术方案全貌 / 风险地图 / 指标与验收 / TL;DR 必答要点
• 原则：从问答式主文档里提炼结论，不复述讨论过程

可选配套：线框图草稿 .md / 交互原型 .html / 方案对齐稿 .md，同子目录归档。

5.5 交互链路稿（跨阶段活文档）

定位与生命周期

按用户交互链路串起来的"走查稿 + 技术实现手册"——每一步同时讲清楚：看到什么 / 能做什么 / 背后怎么实现。跨 4 个阶段持续演进，每阶段补一层字段：

阶段	补充字段	完成标志
brainstorm	主线 Step 骨架（触发 / 效果图占位 / 视觉数据 / 可交互元素）+ Mermaid 跳转总览	所有 Step 串联完整、跳转无断链
PRD	Given / When / Then 验收场景	验收场景覆盖 ≥ 80% 主线 Step
设计	视觉效果图（Image 2 / Figma / Sketch 导出）替换占位 + 空态 / 错态规范	每 Step 有高保真图
工程	API 与状态 + 技术要点 + 埋点 / 日志	全字段 filled，代码可直接据此实现
完成	真实截图（Playwright 或手动）替换 Image 2 占位	100% 真实图

与其他文档的分工：

• 不是 PRD（PRD 管"应该是什么"）
• 不是 DESIGN.md（设计稿管"视觉 token / 组件规范"）
• 不是 ENGINEERING.md（架构管"全局数据流"）
• 是 贯穿所有阶段的"按交互链路组织的单一真相源"

路径

• 文件：docs/讨论/{模块名}/{YYYY-MM-DD}-{模块名}-交互链路稿.md
• 图片：同模块 docs/讨论/{模块名}/assets/，命名 step{N}-{描述}.png / e{N.M}-{描述}.png（分支）/ overview.png（总览）

通用模板（未来模块直接拉一份空白副本填）

# {模块名} 交互链路稿

**日期**: {YYYY-MM-DD 起草} · {YYYY-MM-DD 最新}
**模块**: {模块名}
**当前阶段**: ⏳ brainstorm-骨架 / PRD-补验收 / 设计-补视觉 / 工程-补 API / ✅ 完成
**关联文档**: 需求讨论 / 整体全貌稿 / PRD / DESIGN / ENGINEERING

## 0. 使用方式

通读顺序: §1 跳转总览 → §2 主线链路 → §3 附录分支 → §4 字段扩展包 → §5 阶段状态表
批注方式: 每 Step 末尾 `❓ 问题区` 直接写疑问,AI 下一轮回来答

## 1. 全局跳转总览

​```mermaid
flowchart LR
  S1[Step 1: 页面/组件] --> S2[Step 2: ...]
  S2 --> S3[Step 3: ...]
  S3 -.异常.-> E3[附录 E3.1]
​```

## 2. 主线链路

### Step 1 — {一句话标题}

#### 1.1 触发 & 入口
- **来源**: 用户从哪个页面/路由进入
- **前置状态**: 登录 / 未登录 / {其他用户状态}
- **触发条件**: 打开页面 / 点击 / hover / {其他事件}

#### 1.2 效果图

![Step 1](./assets/step1-{描述}.png)

> 图类型: {真实截图 | Image 2 占位 | Mermaid 线框}

#### 1.3 视觉元素与数据

| 元素 | 数据来源 | loading 态 | 空态 | 错态 |
|---|---|---|---|---|
| 元素 A | API `{path}` 的 `{field}` | 骨架屏 | "暂无数据" | "加载失败,重试" |
| 元素 B | 前端 store `{storeName}` | ... | ... | ... |

#### 1.4 可交互元素

| 元素 | 交互方式 | 下一步 |
|---|---|---|
| 按钮 X | 点击 | → Step 2 |
| 链接 Y | 点击 | → 新 tab 打开 Step 5 |
| 输入框 Z | 失焦 | 本步内刷新（不跳转）|

#### 1.5 API 与状态 (工程阶段补)

- **前端 store action**: `{storeName}.{action}()` → 改 `{state path}`
- **后端接口**: `{METHOD} {path}` - request / response schema
- **DB 变化**: `UPDATE {table} SET ...` / `INSERT INTO ...`
- **时序图** (如涉及并发/SSE)

#### 1.6 技术要点与风险 (工程阶段补)

- **组件选型**: {shadcn/ui Dialog / 自造组件 / ...}
- **性能考量**: {虚拟滚动 / 防抖 / 懒加载 / ...}
- **边界与已知问题**: ...
- **依赖**: {新增 npm 包 / 后端服务 / ...}

#### ❓ 问题区

<!-- 用户在此标疑问,AI 下一轮回来答,答完保留追溯 -->

---

### Step 2 — ...

## 3. 附录: 分支链路

### 异常 E3.1 — Step 3 的 {场景}

- **触发**: {什么条件走这里}
- **效果图**: ![](./assets/e3.1-{描述}.png)
- **可交互元素**: {简化版表格}
- **技术处理**: {降级/重试/提示}

### 边界 B1.2 — Step 1 的 {边界态}

## 4. 字段扩展包

### 4.1 验收场景 (PRD 阶段补)

| Step | Given | When | Then |
|---|---|---|---|

### 4.2 埋点 / 日志 (工程阶段补)

| Step | 事件名 | 字段 |
|---|---|---|

## 5. 文档阶段状态

- [ ] ⏳ brainstorm: 主线骨架 + 跳转总览
- [ ] ⏳ PRD: 验收场景
- [ ] ⏳ 设计: 视觉效果图
- [ ] ⏳ 工程: API + 组件 + 埋点
- [ ] ⏳ 完成: 真实截图替换占位

强制规则

• 主线独立 + 附录分支链路：异常/边界不塞主线内
• 每 Step 固定 6 字段（1.1-1.6）：不减，可留空；1.5/1.6 允许标 (工程阶段补) 占位
• 每 Step 末尾 ❓ 问题区：用户批注主入口；AI 答完保留历史不删
• 图归档到 assets/：brainstorm 期用 Image 2 占位，设计期用设计稿导出，完成期用真实截图；文件名不变只换内容
• 阶段状态表必填：§5 checkbox 反映文档当前演进阶段
• 不维护具体模块示例：skill 只存通用模板；未来模块拉空白副本填

何时产出

• 产品模式 brainstorm 阶段，整体全貌稿确认后拉交互链路稿骨架
• 轻量 brainstorm（内容/探索模式）不产出此文档
• 非 info2action 项目：若有 docs/讨论/ 目录沿用；否则落当前目录 {模块名}-交互链路稿-{YYYY-MM-DD}.md

---

Phase 6：下一步（用户决定）

思考文档确认后，建议但不强制下一步：

根据模式和讨论结果推荐

产品模式：

思考文档已确认。建议下一步：

A) /forge-prd — 将思考转化为正式 PRD + Feature Spec（推荐）
B) 存档 — 不立即行动，稍后再说
C) 继续讨论 — 还有没想清楚的，再聊一轮

⚠️ 产品模式不允许跳过 PRD 直接开发。
Feature Spec（含 Given/When/Then 验收场景）是开发和 QA 的行为契约，必须在开发前确认。

内容模式：

思考文档已确认。建议下一步：

A) 开始写作 — 我可以帮你按大纲写初稿
B) 存档 — 大纲留着，你自己写
C) 继续讨论 — 再打磨一下结构或论点

构建模式：

思考文档已确认。建议下一步：

A) /forge-dev — 直接进入开发（推荐，构建模式不需要完整PRD）
B) /forge-prd — 先写 PRD 再开发（适合想做扎实的情况）
C) 存档 — 想法留着，还没准备好动手
D) 继续讨论 — 再想想技术选型或架构

探索模式：

思考文档已确认。建议下一步：

A) 切换到其他模式 — 方向明确了，用产品/内容/构建模式深入
B) 存档 — 想法留着继续发酵
C) 继续探索 — 还想聊别的方向

---

重要规则

交互规则

• 一次一个问题 — Phase 1 的问题逐个问，不要一次抛出全部
• 优先选择题 — 减少"你觉得呢？"这种开放式问题
• 智能跳过 — 用户在描述中已经回答的问题，不要重复问
• 急躁逃生口 — 用户说"别问了"→ 立即跳到 Phase 4
• 最多 8 轮提问 — Phase 1 + Phase 3 合计不超过 8 个问题。问够了就停。

反谄媚规则

• ❌ "这是个有趣的想法" → ✅ "这个想法的核心价值在于 X"
• ❌ "有很多种方式可以实现" → ✅ "有两个方案：A 适合 X 场景，B 适合 Y 场景"
• ❌ "你的思路很好" → ✅ "你说的 X 部分成立，但 Y 部分有漏洞"
• ❌ "让我们一起探索" → ✅ "我认为方向应该是 X，因为 Y"
• ❌ "这取决于你的需求" → ✅ "基于你说的 X，我推荐 Y"

质量规则

• 所有方案必须诚实 — 不隐藏缺点，不夸大优点
• 推荐必须有具体理由 — "因为你说了 X，所以推荐 Y"，不是"综合考虑"
• 范围必须清晰 — 每个方案明确"做什么"和"不做什么"
• 假设必须显式 — 方案依赖的假设全部列出

文档规则

• 优先按项目约定归档 — info2action 必须走 docs/讨论/{模块名}/；其他项目若有 docs/讨论/ 目录同此；否则落当前目录
• 文件名包含日期 — {YYYY-MM-DD}-{模块名}-{类型}.md 或 brainstorm-{topic}-{YYYY-MM-DD}.md
• 产品模式默认用问答式结构 A — 追问 → 选项 → AI 倾向 → 答： 四件套，便于异步协作和多轮迭代
• 决策日志超过 2 轮审视时，额外产出"整体全貌稿" — 面向通读场景
• 整体全貌稿确认后，产品模式额外产出"交互链路稿"骨架（5.5 小节通用模板）— 跨 brainstorm/PRD/设计/工程 4 阶段演进的活文档
• 多轮新盲点追加新章节，不回填修改上一轮 — 保留决策溯源
• AI 不得代填 答： — 用户未答就留空
• git 提交思考文档 — 完成后原子提交：docs: brainstorm — {主题}