brainstorming

分类: 文档与知识管理 | 上传者: Minggnim-jpg | 下载: 0 | 版本: v1.0（最新）
需求澄清环节。在开始任何实现之前，通过多轮问答探索用户真实意图，输出独立的需求文档。
更新日志: Source: GitHub https://github.com/Minggnim-jpg/nanobot-task-pipeline
目录结构

当前层级: skills/brainstorming/
📄 SKILL.md 6.2 KB
SKILL.md

---
name: brainstorming
description: 需求澄清环节。在开始任何实现之前，通过多轮问答探索用户真实意图，输出独立的需求文档。
allowed-tools: Bash(read_file), Bash(write_file), Bash(edit_file)
---

# Brainstorming Skill - 需求澄清

## 核心原则

> **"看到需求后不直接写代码，先退一步问清楚用户真正想要什么。"**

### 强制规则

```
<HARD-GATE>
在需求文档获得用户确认之前，禁止：
- 调用任何实现类 skill
- 编写任何代码
- 搭建任何项目结构
- 采取任何实现行动

这适用于 EVERY 项目，无论看起来多简单。
</HARD-GATE>
```

### 反模式警示

⚠️ **"这个太简单了不需要设计"** —— 每个项目都需要需求澄清。"简单"项目恰恰最容易因为未检验的假设而浪费工作。

---

## 工作流程

### 阶段 1: 探索上下文

```markdown
1. 读取用户的原始任务描述 (original-task.md)
2. 检查相关工作区文件（如适用）
3. 评估范围：是否太大需要拆分？
4. 识别模糊点、假设、缺失信息
```

### 阶段 2: 多轮问答澄清

**核心规则**：
- ⚠️ **一次只问一个问题**，不要堆砌
- 📝 优先使用选择题（A/B/C），必要时开放问题
- 🎯 聚焦于：目的、约束、成功标准
- 📋 记录用户的每个回答

**提问示例**：

```
❌ 错误（一次问太多）：
"这个功能的目标用户是谁？有什么约束条件？
你希望用什么技术栈？预算是多少？什么时候要？"

✅ 正确（一次一个）：
"首先，能告诉我这个功能主要解决什么问题吗？
是面向内部团队还是外部用户？"

[等待用户回答]

"明白了。那在技术选型上有什么偏好吗？
比如必须用某个框架，或者有性能要求？"
```

### 阶段 3: 提出方案选项

当需求基本清晰后：

```markdown
1. 总结你理解的需求（1-2 段）
2. 提出 2-3 种实现方案
3. 说明每种方案的权衡
4. 给出你的推荐和理由
5. 询问用户选择或修改意见
```

### 阶段 4: 撰写需求文档

用户确认方案后，创建需求文档：

**文件路径**: `tasks/{task-id}/requirements.md`

**文档结构**：

```markdown
# 需求文档

**任务 ID**: {task-id}
**创建时间**: YYYY-MM-DD HH:MM
**状态**: draft → confirmed

---

## 1. 项目背景

[为什么要做这个功能，解决什么问题]

## 2. 目标用户

[谁会使用这个功能]

## 3. 功能需求

### 3.1 核心功能
- [功能列表]

### 3.2 边界情况
- [需要处理的特殊情况]

## 4. 非功能需求

### 4.1 性能要求
- [响应时间、并发等]

### 4.2 技术约束
- [必须使用的技术、禁止的技术等]

## 5. 成功标准

[如何判断这个功能完成了，可测试的标准]

## 6. 不在范围内

[明确说明不包含什么，防止范围蔓延]

---

## 变更记录

| 日期 | 修改内容 | 确认状态 |
|------|----------|----------|
| YYYY-MM-DD | 初始版本 | pending |
```

### 阶段 5: 用户确认

```markdown
1. 将需求文档内容呈现给用户
2. 询问："这个需求文档准确反映了你的想法吗？
        有什么需要修改或补充的？"
3. 用户确认 → 状态改为 confirmed → 进入技术方案阶段
4. 用户修改 → 更新文档 → 重新确认
```

---

## 与后续阶段的关系

```
brainstorming → requirements.md (confirmed) → technical-spec → coding
     │                    │                        │           │
     │                    └─→ 需求冻结              │           │
     │                                             │           │
     └─→ 禁止实现                                  └─→ 基于需求设计
```

**关键边界**：
- Brainstorming 只负责需求，**不负责技术方案**
- 技术方案由后续的 `technical-spec` 阶段负责
- 需求文档确认后，原则上不应修改（如有重大变更需重新 brainstorming）

---

## 使用示例

### 调用方式

```bash
# 在子代理中调用
claude "请使用 brainstorming skill 澄清这个需求"
```

### 对话示例

```
用户：我想做一个待办事项应用

AI: 好的！让我先了解一下这个待办事项应用的场景。

     首先，这个应用是给你个人使用，还是会给团队/公众使用？
     这会影响我们是否需要用户系统、权限管理等功能。

用户：主要是我个人使用，但可能以后会分享给朋友

AI: 明白了，个人使用为主，但需要考虑未来可能的分享需求。

     那在功能上，你最核心的需求是什么？比如：
     A) 简单的添加/完成/删除任务
     B) 需要分类、标签、优先级
     C) 需要日历视图、提醒功能
     D) 其他（请描述）

用户：B 和 C 都需要

AI: 好的，需要分类、标签、优先级，还要日历视图和提醒。

     关于技术实现，你有什么偏好吗？
     - 网页应用（可以在浏览器访问）
     - 桌面应用（安装在电脑上）
     - 移动应用（手机 APP）
     - 或者你不太在意，我来推荐？

用户：网页应用吧，方便访问

AI: [继续澄清其他方面...]

[需求清晰后]

AI: 根据我们的讨论，我总结一下需求：

     **项目背景**: 个人待办事项管理，未来可能分享给朋友
     **核心功能**: 任务 CRUD、分类、标签、优先级、日历视图、提醒
     **技术形式**: 网页应用
     **成功标准**: ...

     我创建了需求文档，你看看是否准确：
     [展示 requirements.md 内容]

     这个需求文档准确反映了你的想法吗？有什么需要修改的？

用户：看起来没问题，可以开始设计了

AI: 好的，需求已确认。接下来我会进入技术方案阶段...
```

---

## 输出产物

| 文件 | 路径 | 状态 |
|------|------|------|
| 需求文档 | `tasks/{task-id}/requirements.md` | draft → confirmed |
| 问答记录 | `tasks/{task-id}/brainstorming-log.md` | 可选 |

---

## 注意事项

1. **耐心**：不要急于进入实现，需求澄清越充分，返工越少
2. **记录**：重要的用户决策要记录在需求文档中
3. **边界**：需求确认后，超出范围的新需求需要重新评估
4. **灵活**：对于非常简单的任务，可以简化流程，但不能跳过
登录后下载/点赞/收藏 ❤ 8 | ★ 0
brainstorming

目录结构

SKILL.md

举报内容

提示
