requirements-clarity

# 需求澄清技能 ## 描述 通过 100 分评分系统的系统化澄清，自动将模糊需求转化为可执行的 PRD。 ## 指令 当被调用时，检测模糊需求： 1. **模糊的功能请求** - 用户说：“添加登录功能”、“实现支付”、“创建仪表板” - 缺失：如何实现、使用什么技术、有什么约束？ 2. **缺失技术背景** - 未提及技术栈 - 未识别集成点 - 无性能/安全约束 3. **不完整的规范** - 无验收标准 - 无成功指标 - 未考虑边界情况 - 未提及错误处理 4. **模糊的范围** - 边界不清（“用户管理”——具体指什么？) - 未区分 MVP 和未来增强功能 - 缺少“不包含的内容” **请勿在以下情况激活**： - 提到具体文件路径（例如：“auth.go:45”） - 包含代码片段 - 引用现有函数/类 - 具有明确复现步骤的 Bug 修复 ## 核心原则 1. **系统化提问** - 提出聚焦、具体的问题 - 每次只关注一个类别（每轮 2-3 个问题） - 基于之前的回答进行构建 - 避免让用户感到不知所措 2. **质量驱动的迭代** - 持续评估清晰度得分 (0-100) - 系统地识别差距 - 迭代直到达到 ≥ 90 分 - 记录所有澄清轮次 3. **可执行的输出** - 生成具体规范 - 包含可衡量的验收标准 - 提供可执行的阶段 - 支持直接实施 ## 澄清流程 ### 第 1 步：初步需求分析 **输入**：用户的需求描述 **任务**： 1. 解析并理解核心需求 2. 生成功能名称（kebab-case 格式） 3. 确定文档版本（默认为 `1.0`，除非用户另有指定） 4. 确保 `./docs/prds/` 目录存在以输出 PRD 5. 执行初步清晰度评估 (0-100) **评估标准**： 功能清晰度：/30 分 - 清晰的输入/输出：10 分 - 定义了用户交互：10 分 - 说明了成功标准：10 分 技术特异性：/25 分 - 提及技术栈：8 分 - 识别集成点：8 分 - 指定了约束条件：9 分 实施完整性：/25 分 - 考虑了边界情况：8 分 - 提及错误处理：9 分 - 指定了数据验证：8 分 业务背景：/20 分 - 问题陈述清晰：