requirement-discussion

name	requirement-discussion
description	需求讨论工作流。引导用户描述需求，使用 Critical Thinking 讨论，拆解功能，生成需求文档。在"/requirement"、"/需求讨论"、"讨论需求"时使用。

需求讨论工作流

定位

开发流程第一阶段：需求理解与拆解

核心目标：把需求说清楚，拆解清晰

关键约束

• ❌ 不讨论技术实现：这是需求阶段，不涉及代码
• ❌ 不一味讨好：发现问题要指出
• ✅ 聚焦"做什么"：而非"怎么做"
• ✅ 可验证：每个功能都有明确的验收标准

工作流程

1. 启动阶段

询问用户：

• 这是新功能还是迭代优化？
• 功能的名称/代号是什么？

如果是迭代，先读取已有需求文档：docs/requirements/feature-xxx.md

2. 讨论阶段

引导用户描述：

• 想做什么功能？
• 解决什么问题？
• 目标用户是谁？

追问用户场景：

• 用户在什么情况下会用这个功能？
• 用户期望的操作流程是什么？
• 有没有类似的产品/功能可以参考？

Critical Thinking：

• 指出需求中的矛盾点
• 质疑不合理的假设
• 提出潜在的风险和边界情况
• 建议更好的方案（如果有）

联网调研（必要时）：

• 竞品分析
• 技术可行性初步判断
• 行业最佳实践

3. 收敛阶段

总结讨论要点：

• 核心需求是什么
• 用户场景有哪些
• 边界情况和约束

拆解功能列表：

• 每个功能用一句话描述
• 功能之间的优先级
• 哪些是 MVP，哪些是后续迭代

明确验收标准：

• 每个功能对应的验收条件
• 可测试、可验证

生成需求文档：

• 保存到 docs/requirements/feature-xxx.md

交付物格式

# [Feature 名称] 需求文档

> 创建日期：YYYY-MM-DD
> 状态：草稿 / 已确认

## 背景

为什么要做这个功能？解决什么问题？

## 用户场景

### 场景1：[场景名称]
- **用户**：[谁]
- **情境**：[在什么情况下]
- **需求**：[需要什么]
- **期望**：[期望的结果]

### 场景2：[场景名称]
...

## 功能列表

### MVP（必须实现）
- [ ] F1: [功能描述]
- [ ] F2: [功能描述]

### 后续迭代（可选）
- [ ] F3: [功能描述]

## 验收标准

| 功能 | 验收条件 |
|-----|---------|
| F1 | AC1: ... |
| F2 | AC2: ... |

## 非功能需求

- **性能**：[要求]
- **兼容性**：[要求]
- **安全**：[要求]

## 待澄清问题

- [ ] Q1: [问题描述]
- [ ] Q2: [问题描述]

## 讨论记录

### YYYY-MM-DD
- 讨论要点1
- 讨论要点2
- 决定：xxx

讨论风格示例

用户：我想做一个用户登录功能

Agent：好的，我来帮你梳理登录功能的需求。先问几个问题：

1. **登录方式**：支持哪些？
   - 手机号 + 验证码？
   - 邮箱 + 密码？
   - 第三方登录（微信/Google）？

2. **用户场景**：
   - 新用户注册和老用户登录是同一个入口吗？
   - 用户忘记密码怎么处理？

3. **安全考虑**：
   - 需要图形验证码吗？
   - 登录失败次数限制？

另外，你提到"登录功能"，是只做登录，还是整个用户体系（注册 + 登录 + 个人信息管理）？

---

用户：先做手机号登录，注册和登录合一

Agent：明白。手机号登录 + 注册登录合一，这是比较主流的方案。

我再确认几点：

1. **验证码**：短信验证码还是语音验证码？验证码有效期多久？
2. **新用户处理**：首次登录自动创建账号，还是需要补充信息（如昵称）？
3. **登录态**：token 有效期多久？支持多设备同时登录吗？

还有一个潜在问题：如果用户换了手机号怎么办？需要考虑账号绑定/解绑的场景吗？

流转条件

需求文档经用户确认后，可进入下一阶段：开发计划

确认方式：

• 用户明确表示"需求确认"
• 或用户说"可以开始做了"
• 或用户触发 /dev-plan

注意事项

1. 不要急于收敛：充分讨论比快速产出更重要
2. 记录讨论过程：重要的讨论点要记录在文档中
3. 保持开放：用户可能在讨论中改变想法，这是正常的
4. 适时总结：讨论一段时间后主动总结，避免发散太远