proj-analyze-req

name proj-analyze-req description 需求分析与确认（阶段一）。用于理解用户需求、澄清细节、明确功能边界，生成需求分析文档。 需求分析（阶段一） 目标 ：理解用户真实需求，明确功能边界和业务逻辑，生成需求分析文档。 产出 ：需求分析文档（用户确认后进入阶段二） 执行流程 Step 0: 初始化任务文档 → Step 1: 需求理解 → Step 2: 规模判断 → Step 3: 需求澄清（与用户交互） → Step 4: 输出需求文档 → Step 5: 用户确认 Step 0: 初始化任务文档 在用户输入需求后，必须创建全流程任务文档骨架： 文件位置 ： docs/task/{YYYYMMDD}_{中文模块名}_任务.md 内容要求 ：仅记录流程状态、产物清单、上下文快照、下一步指令 禁止写细节 ：不写技术实现与字段设计 Step 1: 需求理解 从用户描述中初步提取： 维度 提取内容 功能目标 要实现什么功能 使用角色 谁来使用 涉及端 Web后台/小程序/App/开放接口 涉及模块 影响哪些现有模块 关键操作 核心功能点 注意 ：此步骤仅做初步理解， 禁止假设任何细节 。 Step 2: 规模判断 规模 特征 后续流程 简单 改字段、加接口、改配置 可简化澄清，但仍需确认 中等 新模块、独立功能 标准流程 复杂 跨模块、架构调整、核心流程 完整流程，详细文档 判断依据 ： 涉及 1 个文件 → 简单 涉及 1 个模块（多文件） → 中等 涉及多个模块 → 复杂 Step 3: 需求澄清（必须执行） 3.1 必问问题清单 AI 必须 向用户询问以下问题，根据需求复杂度选择性提问： 维度 问题 说明 功能范围 这个功能给谁用？Web端？移动端？都需要？ 明确端类型 用户角色 涉及哪些角色？各角色能做什么操作？ 明确权限边界 功能清单 具体需要哪些功能点？ 列表/详情/创建/编辑/删除/导出/审批... 业务流程 主要业务流程是怎样的？有哪些状态流转？ 明确流程节点 业务规则 有哪些业务限制或校验规则？ 明确约束条件 数据要求 需要记录哪些信息/字段？ 明确数据结构 关联关系 与现有哪些模块有关联？ 明确依赖关系 参考资料 有没有参考产品或原型图？ 获取更多上下文 3.2 提问原则 先思考再提问 - 根据需求类型，预判可能涉及的细节点（如：是否多端、是否有状态流转、是否需要关联用户等） 一次性列出 - 将所有待确认问题整理后一次性提出，减少交互轮次 不要假设答案 - 不确定的必须问 追问细节 - 用户回答模糊时继续追问 确认理解 - 复述用户的回答确保理解正确 3.3 提问示例 我来帮您分析这个需求。为了准确理解，请回答以下问题： **1. 功能范围** - 这个功能给谁用？Web后台管理端？小程序端？还是都需要？ **2. 用户角色** - 涉及哪些角色？各角色分别能做什么操作？ **3. 功能清单** - 需要哪些具体功能？（如：列表查询、详情查看、新增、编辑、删除、导出...） **4. 业务流程** - 主要的业务流程是怎样的？ - 是否有状态流转？（如：待处理→处理中→已完成） **5. 数据要求** - 需要记录哪些信息/字段？ - 哪些是必填项？ 请逐一回答，我会根据您的回答进一步澄清。 Step 4: 输出需求文档 在充分澄清后，使用模板输出需求分析文档。 模板文件 ： 需求文档模板 保存位置 ： docs/req/{YYYYMMDD}_{中文模块名}_需求.md 同步更新任务文档 ： 将“需求分析”状态标记为进行中/已完成 在产物清单中记录需求文档路径 更新上下文快照与下一步指令 Step 5: 用户确认 5.1 确认话术 输出需求文档后， 必须 使用以下话术请求确认： 以上是我对需求的理解，请确认： 1. 功能范围是否完整？ 2. 业务流程是否正确？ 3. 是否有遗漏的功能点或业务规则？ 确认后我将进入技术方案设计阶段（/proj-analyze-design）。 5.2 用户反馈处理 用户反馈 处理方式 "确认"/"没问题"/"可以" 进入阶段二： /proj-analyze-design "需要补充xxx" 更新需求文档，再次确认 "需要修改xxx" 修改对应内容，再次确认 "取消"/"不做了" 结束流程 确认后同步更新任务文档 ： 标记“需求确认”状态为已完成 更新“下一步指令”为进入技术方案设计 文档规范要求 需求文档 vs 技术文档边界 需求文档应包含 ： 业务背景和目标 用户角色和使用场景 功能需求详述（做什么） 业务流程和规则 数据需求（业务视角） 非功能性需求 验收标准 需求文档禁止包含 ： 数据库表设计 接口定义（URL、参数、响应格式） 技术架构设计 代码结构设计 具体技术选型 业务流程图要求 简单流程（≤3步）：用文字描述 复杂流程（>3步或有分支）：必须使用Mermaid流程图 流程图必须体现业务逻辑，不是技术实现 用户场景描述 每个主要功能都要有典型使用场景： 场景X：{场景名称} {用户角色}在{什么情况下}需要{做什么事情}，期望{达到什么目标}。 文档完整性要求 必须包含以下章节： 功能概述（业务背景、功能定位、核心价值） 用户角色与场景（角色定义、典型场景） 功能需求详述（每个功能的详细描述） 业务流程（主要流程的Mermaid图） 数据需求（业务视角的数据实体） 非功能性需求（性能、安全、兼容性） 约束条件（技术约束、业务约束） 验收标准（功能验收、性能验收） 风险评估（技术风险、业务风险） 技术实现澄清点 需求文档中应澄清以下技术相关问题： 消息通知方式 ：是否需要实时推送？轮询频率要求？ 数据实时性要求 ：哪些数据需要实时查询？ 数据保留策略 ：永久保存 vs 定期清理？业务数据 vs 日志数据？ 系统集成方式 ：与现有系统如何集成？ 性能要求 ：并发量？响应时间？数据量？ 注意事项 禁止假设 - 用户没说的不要自己编 禁止跳过 - 必须完成澄清才能输出文档 禁止合并 - 需求确认前不要开始技术方案 保持耐心 - 复杂需求可能需要多轮澄清 记录变更 - 如果澄清过程中需求有变化，及时更新文档 严格边界 - 需求文档不能包含技术实现细节 业务导向 - 从用户和业务角度描述需求，不涉及技术如何实现 任务文档 - 需求开始必须创建并持续更新全流程任务文档