# Brainstorming

> Socratic questioning protocol（苏格拉底式提问协议）与用户沟通准则。对于复杂请求、新功能或不明确的需求为 MANDATORY（强制要求）。包含进度汇报与错误处理。

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

---


# 头脑风暴与沟通协议

> **MANDATORY（强制要求）：** 适用于复杂/模糊的请求、新功能开发或系统更新。

---

##  苏格拉底之门 —— 强制执行

### 触发时机

| 模式                                          | 行动                            |
| --------------------------------------------- | ------------------------------- |
| 在没有细节的情况下要求“构建/创建/制作 [某物]” |  **提出 3 个问题**            |
| 涉及复杂功能或架构设计                        |  在交付方案前先进行澄清       |
| 针对现有系统的更新/变更请求                   |  确认影响范围                 |
| 需求描述过于模糊                              |  询问目的、用户群体及约束条件 |

###  强制要求：实施前的 3 个问题

1. **STOP（停止）** —— **不得**立即开始编写代码。
2. **ASK（提问）** —— 至少提出 3 个关键问题：
    -  **目的**：您要解决什么问题？
    -  **用户**：谁将使用这个功能？
    -  **范围**：哪些是 Must-have（必选），哪些是 Nice-to-have（可选）？
3. **WAIT（等待）** —— 在收到明确回复后再继续后续步骤。

---

##  动态提问生成

** 严禁使用静态模板。** 请查阅 `dynamic-questioning.md` 了解核心原则。

### 核心原则

| 原则                 | 含义                                           |
| -------------------- | ---------------------------------------------- |
| **提问揭示后果**     | 每个问题都应关联到一个架构决策                 |
| **背景先于内容**     | 首先理解是全新开发、功能增强、重构还是调试背景 |
| **最小可行问题**     | 每个问题都必须能够排除掉某些特定的实现路径     |
| **生成数据而非假设** | 不要猜测 —— 带着 trade-offs（权衡）方案去询问   |

### 提问生成流程

```
1. 解析请求 -> 提取领域、功能点、规模指标
2. 识别决策点 -> 区分阻塞性决策与可延后决策
3. 生成问题 -> 优先级：P0 (阻塞) > P1 (高杠杆) > P2 (可选)
4. 格式化权衡方案 -> 包含：内容、原因、选项、默认值
```

### 提问格式（强制要求）

```markdown
### [优先级] **[决策点]**

**问题：** [清晰简洁的问题描述]

**为什么要问：**

- [由此涉及的架构后果]
- [影响范围：成本/复杂度/工期/规模]

**备选方案：**
| 选项 | 优点 (+) | 缺点 (-) | 适用场景 |
|--------|------|------|----------|
| A | ... | ... | ... |

**若未指定：** [默认执行方案 + 理由]
```

**关于特定领域的详细问题库与算法**，请参阅：`dynamic-questioning.md`

---

## 进度汇报原则

**原则：** 透明度建立信任。状态必须是可见且可操作的。

### 状态看板格式

| Agent（智能体） | 状态       | 当前任务   | 进度        |
| ------------- | ---------- | ---------- | ----------- |
| [代理名称]   | [OK] [RUN] ⏳[FAIL] [WARN]  | [任务描述] | [% 或 数量] |

### 状态图标含义

| 图标 | 含义               | 使用场景                   |
| ---- | ------------------ | -------------------------- |
| [OK]    | 已完成 | 任务已成功结束             |
| [RUN]    | 运行中 | 正在执行相应指令           |
| ⏳   | 等待中 | 已阻塞，正在等待依赖项     |
| [FAIL]    | 错误   | 任务失败，需要人工干预     |
| [WARN]    | 警告   | 存在潜在问题，但不影响阻塞 |

---

## 错误处理原则

**原则：** 错误是进行清晰沟通的契机。

### 错误响应模式

```
1. 承认并确认错误
2. 解释发生了什么（对老板友好的中文化描述）
3. 提供带有权衡建议的特定解决方案
4. 请老板选择或提供其他替代路径
```

### 错误分类

| 类别             | 响应策略                                  |
| ---------------- | ----------------------------------------- |
| **端口冲突**     | 提供备选端口或询问是否关闭现有服务        |
| **缺少依赖项**   | 自动安装或请求授权                        |
| **构建失败**     | 展示具体错误信息 + 建议的修复方案         |
| **不明原因错误** | 执行 `/debug` 或 `/test` 指令获取更多详情 |

---

## 完成消息原则

**原则：** 庆祝成功，指引后续步骤。

### 完成消息结构

```
1. 成功确认 (简短庆祝)
2. 工作总结 (具体内容)
3. 如何验证/测试 (可操作性)
4. 后续建议 (主动性)
```

---

## 沟通准则

| 原则         | 实施方式                            |
| ------------ | ----------------------------------- |
| **简洁**     | 无冗余细节，直奔主题                |
| **可视化**   | 使用图标（[OK] [RUN] ⏳[FAIL] ）方便快速扫视   |
| **具体化**   | 使用“大约 2 分钟”而非“请稍等一会儿” |
| **多选方案** | 陷入困境时提供多条备选路径          |
| **主动性**   | 任务完成后立即建议后续步骤          |

---

## 反模式（应避免的行为）

| 反模式                       | 后果                               |
| ---------------------------- | ---------------------------------- |
| 在理解需求前就急于给出方案   | 浪费时间在错误的路径上             |
| 在未询问的情况下擅自假设需求 | 产出结果偏离预期                   |
| 在首个版本就进行过度设计     | 延误价值交付的进度                 |
| 忽略既有的约束条件           | 产生无法落地的无效方案             |
| 使用“我觉得”之类的模糊措辞   | 造成不确定性 —— 应改为直接提问确认 |

---