129 lines
3.5 KiB
Markdown
129 lines
3.5 KiB
Markdown
|
---
|
|||
|
|
name: brainstorming
|
|||
|
|
description: 在任何创造性工作之前必须使用 - 创建功能、构建组件、添加功能或修改行为时。探索用户意图、需求和设计，然后再实现。
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 头脑风暴：将想法转化为设计
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
通过自然的协作对话，帮助将想法转化为完整的设计和规格。
|
|||
|
|
|
|||
|
|
首先了解当前项目上下文，然后**每次只问一个问题**来细化想法。一旦你理解了要构建什么，以小节（200-300 字）呈现设计，每节之后确认是否正确。
|
|||
|
|
|
|||
|
|
## 流程
|
|||
|
|
|
|||
|
|
### 理解想法
|
|||
|
|
|
|||
|
|
- 首先查看当前项目状态（文件、文档、最近的提交）
|
|||
|
|
- **每次只问一个问题**来细化想法
|
|||
|
|
- 尽可能使用多选题，但开放式问题也可以
|
|||
|
|
- 每条消息只问一个问题 - 如果一个主题需要更多探索，拆分成多个问题
|
|||
|
|
- 关注理解：目的、约束、成功标准
|
|||
|
|
|
|||
|
|
### 探索方案
|
|||
|
|
|
|||
|
|
- 提出 2-3 种不同的方案及其权衡
|
|||
|
|
- 以对话方式呈现选项，并给出你的推荐和理由
|
|||
|
|
- 先说推荐的选项并解释原因
|
|||
|
|
|
|||
|
|
### 呈现设计
|
|||
|
|
|
|||
|
|
- 一旦你认为理解了要构建什么，呈现设计
|
|||
|
|
- 将设计分成 200-300 字的小节
|
|||
|
|
- 每节之后询问是否正确
|
|||
|
|
- 涵盖：架构、组件、数据流、错误处理、测试
|
|||
|
|
- 如果有不清楚的地方，准备返回澄清
|
|||
|
|
|
|||
|
|
## 设计完成后
|
|||
|
|
|
|||
|
|
### 文档
|
|||
|
|
|
|||
|
|
- 将验证过的设计写入 `docs/plans/YYYY-MM-DD-<topic>-design.md`
|
|||
|
|
- 提交设计文档到 git
|
|||
|
|
|
|||
|
|
### 输出
|
|||
|
|
|
|||
|
|
完成后输出：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
设计文档已完成并保存到 docs/plans/YYYY-MM-DD-<topic>-design.md
|
|||
|
|
|
|||
|
|
下一步：执行 /vibe-plan 创建实现计划。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## 核心原则
|
|||
|
|
|
|||
|
|
- **每次只问一个问题** - 不要用多个问题淹没用户
|
|||
|
|
- **多选题优先** - 在可能时比开放式问题更容易回答
|
|||
|
|
- **严格遵循 YAGNI** - 从所有设计中移除不必要的功能
|
|||
|
|
- **探索替代方案** - 在确定之前总是提出 2-3 种方案
|
|||
|
|
- **增量验证** - 分节呈现设计，验证每一节
|
|||
|
|
- **保持灵活** - 当某些内容不清楚时返回澄清
|
|||
|
|
|
|||
|
|
## 常见错误
|
|||
|
|
|
|||
|
|
| 错误 | 正确做法 |
|
|||
|
|
|------|----------|
|
|||
|
|
| 一次问多个问题 | 每条消息只问一个问题 |
|
|||
|
|
| 假设用户意图 | 询问澄清 |
|
|||
|
|
| 跳过方案探索 | 总是提出 2-3 种方案 |
|
|||
|
|
| 设计完直接开始编码 | 等待用户确认设计 |
|
|||
|
|
| 添加"可能有用"的功能 | 严格遵循 YAGNI |
|
|||
|
|
|
|||
|
|
## 危险信号 - 停下来
|
|||
|
|
|
|||
|
|
如果你发现自己想：
|
|||
|
|
- "用户可能想要这个功能"
|
|||
|
|
- "我先开始编码，边做边设计"
|
|||
|
|
- "这个设计很明显，不需要确认"
|
|||
|
|
- "我可以跳过方案探索"
|
|||
|
|
|
|||
|
|
**所有这些都意味着：停下来。遵循流程。**
|
|||
|
|
|
|||
|
|
## 示例工作流
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
用户: 我想添加一个用户认证功能
|
|||
|
|
|
|||
|
|
你: 让我先了解一下项目情况...
|
|||
|
|
[查看项目文件和结构]
|
|||
|
|
|
|||
|
|
你: 关于认证方式，你倾向于哪种？
|
|||
|
|
1. 用户名/密码（传统方式）
|
|||
|
|
2. OAuth（第三方登录，如 Google、GitHub）
|
|||
|
|
3. 两者都支持
|
|||
|
|
|
|||
|
|
用户: 先支持用户名/密码
|
|||
|
|
|
|||
|
|
你: 关于密码存储，你有特定的安全要求吗？
|
|||
|
|
1. 使用 bcrypt 哈希（推荐，安全性高）
|
|||
|
|
2. 使用 SHA-256（较快，安全性中等）
|
|||
|
|
3. 有其他要求请说明
|
|||
|
|
|
|||
|
|
用户: 用 bcrypt
|
|||
|
|
|
|||
|
|
你: 好的，让我呈现设计的第一部分...
|
|||
|
|
|
|||
|
|
## 1. 用户模型设计
|
|||
|
|
|
|||
|
|
用户表结构：
|
|||
|
|
- id: UUID
|
|||
|
|
- username: 唯一字符串
|
|||
|
|
- password_hash: bcrypt 哈希
|
|||
|
|
- created_at: 时间戳
|
|||
|
|
- updated_at: 时间戳
|
|||
|
|
|
|||
|
|
这部分设计是否正确？
|
|||
|
|
|
|||
|
|
用户: 是的
|
|||
|
|
|
|||
|
|
你: [继续下一部分...]
|
|||
|
|
|
|||
|
|
[设计完成后]
|
|||
|
|
|
|||
|
|
你: 设计文档已保存到 docs/plans/2026-01-19-user-auth-design.md
|
|||
|
|
|
|||
|
|
请审查设计，确认后我将创建实现计划。
|
|||
|
|
```
|