# Forge Brainstorm

> 通用头脑风暴：4 种模式（产品/内容/构建/探索）× 6 阶段，强制前提挑战和 2-3 方案，产出可跨会话续聊的思考文档；支持 Mermaid/图辅助判断。 触发方式：用户说"头脑风暴"、"brainstorm"、"讨论一下"、"我有个想法"、"帮我想想"、"画图梳理想法"。

- Skill: `yike-gunshi/forge-brainstorm` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add yike-gunshi/forge-brainstorm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yike-gunshi/forge-brainstorm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yike-gunshi (https://skillmd.com/u/yike-gunshi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yike-gunshi/forge-brainstorm

---


> **文档落地路径**：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见
> `~/.claude/skills/forge-doc-policy/doc-paths.md`。
> **当前文档加载顺序**：先读项目 `CLAUDE.md`、`docs/README.md`、`docs/INDEX.md`。
> 需要写入当前事实时进入根级当前真相源；brainstorm 原始讨论默认进入 archive/raw。
> 详细规则见 `~/.claude/skills/_shared/current-doc-loading.md`。

# /forge-brainstorm：通用头脑风暴

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

全程中文。

---

## 铁律

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

---

## 前置脚本（每次先运行）

```bash
_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/README.md" ] && echo "发现 docs/README.md"
[ -f "$_ROOT/docs/INDEX.md" ] && echo "发现 docs/INDEX.md"
[ -f "$_ROOT/docs/modules/doc-system.md" ] && echo "发现项目文档系统说明"
[ -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/archive/raw/discussions/"*/ 2>/dev/null && echo "发现 archive/raw discussions（当前推荐归档）"
ls -d "$_ROOT/docs/讨论/"*/ 2>/dev/null && echo "发现 legacy docs/讨论/ 子目录"
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 个强迫性问题**：需求真实性 / 现状分析 / 最窄楔子 / 独特洞察 / 观察性证据 / 未来适配。按顺序逐个问，答完再问下一个。
- **内容模式 — 5 个编辑问题**：核心论点 / 受众定位 / 结构骨架 / 差异化 / 交付形式。
- **构建模式 — 4 个 Builder 问题**：最酷版本 / 给谁看 / 最快路径 / 学习目标。
- **探索模式 — 3 个宽漏斗问题**：兴奋点 / 约束 / 10x 版本。
- **提问原文必读 [references/question-banks.md](references/question-banks.md) 对应模式节**——逐字使用原文问法，不要凭摘要即兴改写。

---

## 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 原文必读 [references/question-banks.md](references/question-banks.md) 的「Pushback 模板」节**——用原表的检测模式和话术。

---

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

当讨论进入「用户需要看见才好判断」的状态时，读取 `~/.claude/skills/_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：思考文档

讨论收敛后写思考文档（`brainstorm-{主题}-{日期}.md`）。**写之前必读
[references/thinking-doc-template.md](references/thinking-doc-template.md)**——
含完整文档结构（背景/深层痛点/共识/方案调研/逐轮决策表/原始讨论纪实）、
「给下一台电脑的自己」续聊指引、轻量版模板和字段扩展包。骨架只记住三条：
1. 决策表逐轮锁定，新一轮审视用追加不覆盖
2. 必须写「如何继续这次讨论」节，跨会话可续
3. 保留关键对话轮次精华，供未来复盘决策路径

## 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) 继续探索 — 还想聊别的方向
```

---

## 重要规则

### 交互规则（铁律见文件头，此处只列补充项）
- **智能跳过** — 用户在描述中已经回答的问题，不要重复问
- **最多 8 轮提问** — Phase 1 + Phase 3 合计不超过 8 个问题。问够了就停。

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

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

### 文档规则
- **优先按项目约定归档** — 有 `docs/modules/doc-system.md` 或 `docs/archive/raw/` 的项目，原始讨论走 `docs/archive/raw/discussions/{模块名}/`；legacy 项目才沿用 `docs/讨论/{模块名}/`
- **文件名包含日期** — `{YYYY-MM-DD}-{模块名}-{类型}.md` 或 `brainstorm-{topic}-{YYYY-MM-DD}.md`
- **当前事实另行沉淀** — brainstorm 原文不是当前事实源；用户确认后的结论才写入根级当前真相源、模块附录或 `.features`
- **产品模式默认用问答式结构 A** — `追问 → 选项 → AI 倾向 → 答：` 四件套，便于异步协作和多轮迭代
- **决策日志超过 2 轮审视时，额外产出"整体全貌稿"** — 面向通读场景
- **整体全貌稿确认后，产品模式额外产出"交互链路稿"骨架**（5.5 小节通用模板）— 跨 brainstorm/PRD/设计/工程 4 阶段演进的活文档
- **多轮新盲点追加新章节，不回填修改上一轮** — 保留决策溯源
- **AI 不得代填 `答：`** — 用户未答就留空
- **git 提交思考文档** — 完成后原子提交：`docs: brainstorm — {主题}`