头脑风暴：将想法转化为设计

概述

通过自然的协作对话，帮助将想法转化为完整的设计和规格说明。

首先了解当前项目的上下文，然后一次提出一个问题来完善想法。一旦理解了要构建的内容，呈现设计并获得用户批准。

反模式："这太简单了，不需要设计"

每个项目都要经历这个过程。一个待办列表、一个单功能工具、一个配置更改——所有这些都要。"简单"的项目正是未经审视的假设造成最多浪费工作的地方。设计可以很简短（真正简单的项目几句话即可），但你必须呈现它并获得批准。

检查清单

你必须为以下每个项目创建任务并按顺序完成：

1. •检查需求文档 — 扫描 docs/requirements/ 目录，避免重复讨论已有需求
2. •探索项目上下文 — 检查文件、文档、最近的提交
3. •提出澄清问题 — 一次一个，理解目的/约束/成功标准
4. •提出 2-3 种方案 — 附带权衡取舍和你的推荐
5. •呈现设计 — 根据复杂程度分章节展示，每章后获得用户批准
6. •编写设计文档 — 保存到 docs/plans/YYYY-MM-DD-<topic>-design.md 并提交

进度追踪（文件式规划）

在开始头脑风暴时，同步创建进度追踪文件：

1. •创建进度文件 docs/plans/progress.md（如果不存在）：

# 项目进度追踪

## 当前任务

| 任务 | 阶段 | 状态 | 更新时间 |
|------|------|------|----------|
| [任务名] | brainstorming | 🔄 进行中 | YYYY-MM-DD |

## 最近活动

| 时间 | 活动 | 说明 |
|------|------|------|
| YYYY-MM-DD HH:MM | 开始 | 开始头脑风暴：xxx |

1. •每个阶段完成后更新进度：

• •更新任务状态（pending → in_progress → complete）
• •记录完成时间和活动
• •添加下一步计划

1. •文件位置：docs/plans/progress.md

流程

【重要】深度分析需求： 在开始分析用户需求时，不要只停留在表面理解，而是要从更高维度分析：

1. •

   这是真正的核心问题吗？

   • •用户说的具体问题是什么
   • •真正要解决的是什么
2. •

   从多维度分析：

   • •技术维度：技术方案是否合理
   • •价值维度：解决这个问题价值有多大
   • •架构维度：对项目整体有什么影响
3. •

   分析后再开始：

   • •先和用户确认理解是否正确
   • •如果发现更深层的问题，先讨论清楚
   • •不要急着进入细节

开始前 - 检查需求文档：

• •扫描 docs/requirements/ 目录
• •如果发现与当前主题相关的已有需求，提醒用户
• •确认是新建需求还是复用/扩展已有需求
• •避免重复讨论已确认的需求

理解想法：

• •首先检查当前项目状态（文件、文档、最近提交）
• •一次提一个问题来完善想法
• •尽可能选择封闭式问题，开放式也可以
• •每条消息一个问题——如果一个主题需要更多探索，分成多个问题
• •重点理解：目的、约束、成功标准

功能范围确认（在探索想法后、呈现方案前）：

• •明确功能模块：从用户描述中提取实体（模块）
• •明确操作类型：每个模块需要哪些操作（列表、新增、编辑、删除等）
• •记录到设计文档的"功能范围"章节
• •注意：细节补充在 writing-plans 阶段完成

探索方案：

• •提出 2-3 种不同方案，附带权衡取舍
• •会话性地呈现选项，说明你的推荐和理由
• •先说出推荐选项并解释原因

呈现设计：

• •一旦相信理解了要构建的内容，就呈现设计
• •根据复杂程度调整每个部分：简单的几句话，复杂的多达 200-300 字
• •每个部分后询问是否正确
• •涵盖：架构、组件、数据流、错误处理、测试
• •当事情不对劲时，准备好回去澄清

设计文档模板

# [功能名称] 设计文档

## 概述
[2-3 句话总结]

## 功能范围

| 模块 | 功能点 | 优先级 |
|------|--------|--------|
| [模块名] | 列表查看 | P0 |
| [模块名] | 新增 | P0 |
| [模块名] | 编辑 | P0 |
| [模块名] | 删除 | P0 |
| [模块名] | 批量操作 | P1 |
| [模块名] | 导入/导出 | P2 |

**常见功能点参考：**
- P0（必须）：列表、新增、编辑、删除、详情
- P1（建议）：搜索、分页、批量删除、状态变更
- P2（可选）：导入导出、审计日志、统计分析

## 背景
- 问题描述：
- 期望结果：
- 成功标准：

## 方案选择

### 方案 A: [名称]
- 优点：
- 缺点：
- 适用场景：

### 方案 B: [名称]
- 优点：
- 缺点：
- 适用场景：

### 推荐方案
[说明为什么推荐这个方案]

## 架构设计

### 数据模型
[数据库表结构]

### API 设计
[API 端点]

### 组件设计
[前端组件]

## 用户流程

1. [步骤 1]
2. [步骤 2]
3. [步骤 3]

## 错误处理
[异常情况]

## 测试策略
- 单元测试：
- 集成测试：
- E2E 测试：

## 风险与缓解
- **风险**：[描述]
  - 缓解措施：

## 验收标准
- [ ] 标准 1
- [ ] 标准 2

与需求讨论的关系

流程：

1. •需求不明确 → 使用 discuss-requirements
2. •需求明确 → 使用 brainstorming
3. •设计完成 → 使用 writing-plans

之后做什么

文档：

• •将验证后的设计写入 docs/plans/YYYY-MM-DD-<topic>-design.md
• •提交设计文档

实施：

• •调用 writing-plans skill 创建详细实施计划
• •不要调用任何其他 skill。writing-plans 是的下一步。

关键原则

• •一次一个问题 - 不要用多个问题淹没用户
• •优先封闭式问题 - 比开放式更容易回答
• •YAGNI 原则 - 从所有设计中删除不必要的功能
• •探索替代方案 - 在确定之前总是提出 2-3 种方案
• •增量验证 - 呈现设计，获得批准后再继续
• •保持灵活 - 当事情不对劲时回去澄清