name: 需求收集 description: 在规划或实施之前系统化澄清用户需求、偏好和约束。分类工作类型、调查现有系统、发现边缘用例和集成点、解析假设并创建详细规格。用于构建功能、增强或集成时需要澄清需求的情况。
需求收集
何时使用
- 用户指定他们希望如何完成某事
- 澄清偏好或约束
- 理解需要构建什么
- 在工作开始前收集规格
- 基于现有系统构建（增强、集成）
核心工作流程
1. 分类请求类型
询问1-2个快速问题以理解上下文：
Q1: 工作类型是什么？
- 新功能 - 从零开始构建
- 增强 - 改进现有功能
- 集成 - 连接外部系统
- 重构 - 改变实现而不改变行为
Q2: 当前知识水平？
- 清晰愿景 - 用户确切知道他们想要什么
- 一般想法 - 目标清晰，实现细节模糊
- 探索选项 - 不确定方法
2. 预调查（如果需要）
何时首先调查：
- 增强现有功能（理解当前实现）
- 集成不清晰（探索现有模式）
- 技术约束未知（调查能力）
- 基于现有架构构建
何时跳过调查：
- 绿地功能（尚无现有内容）
- 已提供完整需求
- 简单、清晰范围，无依赖
委托异步调查代理以理解现有系统。结果保存在agent-responses/中。
将发现转化为知情问题：
- ❌ 通用：“您想要哪些认证方法？”
- ✅ 知情：“我看到JWT和刷新令牌。对于MFA：TOTP应用？短信代码？对所有用户必需还是可选？”
3. 通用发现问题
针对任何功能询问这些核心问题（适应上下文）：
UQ-1: 快乐路径 “从用户角度逐步描述成功场景。”
- 什么触发功能？
- 用户采取什么操作？
- 期望的结果是什么？
UQ-2: 边缘用例与约束 “对于这些场景应该发生什么？”
- 空状态（无数据）
- 巨大数据集（性能）
- 无效输入（验证）
- 网络故障（离线）
- 并发操作（冲突）
UQ-3: 性能期望 “这应该给用户什么感觉？”
- 即时（<100ms） - UI更新、简单操作
- 快速（<1s） - API调用、数据获取
- 最终（加载指示器） - 重处理
- 后台（无需等待） - 异步操作
UQ-4: 失败模式 “什么不应该发生？什么最会挫伤用户？”
- 数据丢失场景
- 破坏现有工作流
- 混淆错误状态
UQ-5: 范围边界 “在这个迭代中明确排除什么？”
- 未来增强
- 高级功能
- 延迟的边缘用例
UQ-6: 集成点 “这与以下如何交互：”
- 现有功能
- 外部API或服务
- 数据库或存储
- 认证/授权
- 第三方库
4. 功能特定发现
基于功能类型定制问题（选择相关）：
认证/授权：
- 凭据：邮箱/密码？社交登录？魔法链接？2FA/MFA？
- 会话：持续时间？记住我？
- 密码：长度/复杂度要求？
- 登录失败：通用错误/账户锁定/CAPTCHA/速率限制？
- MFA：TOTP应用？短信？邮箱？必需还是可选？
CRUD操作：
- 验证：必填字段？格式规则？长度限制？唯一约束？
- 并发编辑：最后写入胜出/显示冲突/锁定？
- 删除：硬删除/软删除/确认/撤销？
- 保存：等待服务器/乐观更新/显示保存中？
搜索与过滤：
- 范围：搜索特定字段/所有文本/元数据？
- 时机：输入时实时/暂停后/按Enter键？
- 匹配：精确/包含/模糊/全文？
- 排序：相关性/字母顺序/最近/用户可选？
表单与输入：
- 验证时机：失焦时/提交时/输入时？
- 错误显示：内联/摘要/提示？
- 未保存更改：警告/自动保存/允许丢失数据？
- 默认值：先前值/智能默认/空/预填充？
实时功能：
- 机制：轮询/WebSocket/服务器发送事件？
- 频率：1秒/5-10秒/1分钟/事件驱动？
- 离线：排队操作/阻止使用/显示离线模式？
- 冲突：显示通知/自动合并/手动解决？
文件上传：
- 类型与限制：仅图片/文档/任何文件？最大尺寸？
- 多个文件：一次一个/同时/批量？
- 进度：显示进度条/允许取消？
- 存储：存储位置？CDN？S3？本地？
数据可视化：
- 图表类型：柱状/线性/饼状/散点/自定义？
- 交互性：悬停提示/点击钻取/缩放/平移？
- 响应式：移动端行为？简化视图？
- 导出：下载为图片/CSV/PDF？
5. 解析所有未知项
步骤5a: 内部生成技术推断
用置信度记录假设：
- 高： 用户明确说明/唯一合理方法/行业标准/安全要求
- 中： 常见实践但存在替代/需求暗示/标准模式
- 低： 填充实现缺口/多种有效方法/偏好假设
步骤5b: 呈现推断供确认
"基于我们的讨论，这是我的技术假设：
高置信度（除非您反对将实施）：
- [带推理的假设]
中置信度（常见方法，存在替代）：
- [假设 - 替代：X]
低置信度（需要您的输入）：
- [带建议方法的问题]
有任何反对或偏好吗？"
步骤5c: 解析所有澄清
为剩余未知项询问跟进问题。直到所有推断被确认且所有澄清被解析，才进行到步骤6。
6. 创建需求规格
使用~/.claude/file-templates/requirements.template.md中的规范模板。
指令：
- 用已确认的信息填写每个部分
- 在"实现说明"中记录决策并附推理
- 在
docs/中交叉引用相关文档；如果缺失则创建存根 - 确保"相关文件"部分全面
- 包括引用现有系统发现的"工件"部分
7. 呈现并确认最终规格
"这是基于我们已确认决策的需求规格：
[显示或链接到需求文件]
所有技术决策和澄清已纳入。准备好进入规划/实现阶段吗？"
等待用户批准后再进入下一阶段。
8. 更新项目文档
如果项目有文档结构：
更新docs/product-requirements.md：
- 添加功能并分配下一个功能ID（F-##）
- 包括需求摘要
- 添加验收标准
- 链接到相关功能和集成点
参考：
docs/system-design.md- 架构上下文agent-responses/agent_<id>.md中的调查发现
快速参考
基本问题：
- 快乐路径场景
- 关键边缘用例与性能期望
- 失败模式
- 范围外项目
- 集成点
调查工件：
- 输入：
docs/product-requirements.md,docs/system-design.md - 输出：需求规格 + 更新的项目文档
置信度级别：
- 高：明确要求或最佳实践
- 中：标准实践但有替代
- 低：转化为用户问题
常见陷阱
- ❌ 在不理解现有系统的情况下提问
- ❌ 带着未解析的模糊性进入实现
- ❌ 混合假设与已确认需求
- ❌ 跳过边缘用例发现
- ✅ 首先调查 → 问知情问题 → 解析所有未知 → 记录 → 确认