| name | requirement-clarifier |
| description | 需求澄清。功能:检测并澄清用户模糊描述,确保需求可拆解为具体任务。当出现以下场景时必须调用此skill:1)描述只有动作无对象(如"优化一下");2)缺少明确标准(如"做得更好");3)范围不明确(如"处理一下");4)存在冲突需求(如"要简单但功能全");5)缺少目标、范围或输出格式。 |
需求澄清
触发条件
显式模糊模式:
- 动作无对象:"优化一下"、"改一下"、"调整一下"
- 动作无标准:"做得更好"、"提高性能"、"加快速度"
- 范围不明确:"处理一下"、"看看这个问题"
- 冲突需求:"要简单但功能全"、"要快但不要改架构"
- 缺失关键信息:无目标、无范围、无输出格式
隐式模糊判断:
- 先结合上下文(代码、历史对话、文件结构)推断意图
- 仅在推断后仍存在不确定项时才询问用户
可拆解标准
需求必须同时满足以下条件才算"可拆解":
- 目标明确:知道要达成什么结果
- 范围明确:知道涉及哪些文件/模块/功能
- 输出格式明确:知道最终交付物的形式
- 无歧义:不存在多种合理解读
澄清机制
阶段一:主动追问(同一模糊点最多2次)
- 必须主动提供选项 + 支持自定义输入
- 追问模板:"关于「{模糊描述}」,我的推断是{推断结果}。请确认或补充:1)目标:{选项A/选项B/自定义} 2)范围:{选项A/选项B/自定义} 3)输出格式:{选项A/选项B/自定义}"
阶段二:计划确认(追问2次后仍不清晰)
- 按最佳理解生成执行计划展示给用户
- 用户可在此基础上修改,最多再修改2次
- 修改后重新展示计划供确认
阶段三:直接执行
- 计划确认阶段修改也达2次上限时,按当前最佳理解直接执行
输出格式
澄清完成后输出标准化需求描述:
- 目标:{明确目标}
- 范围:{涉及文件/模块}
- 输出:{交付物格式}
- 约束:{性能/兼容性等要求}
- 澄清记录:{简要记录推断和确认过程}
规则
- 不过度追问;上下文推断是核心优势,优先使用
- 用户表现出不耐烦(如"就这样吧"、"别问了")→ 立即进入阶段二
- 同一模糊点:最多2次追问 + 2次计划修改