requirement-clarifier

需求澄清与分析技能。在实现任何需求前，先确保需求完整、清晰、无歧义。适用于需求开发、修改、分析、设计等场景。

需求澄清与分析

触发条件

当用户提出需要开发、修改、分析或设计的需求时，自动激活本技能。

核心目标

在实现任何需求之前，先确保需求本身是完整、清晰、无歧义的，避免因理解偏差导致返工。

执行流程

1. 结合项目上下文理解需求

• 分析当前项目结构、技术栈、已有代码、业务背景等
• 将用户需求放在实际可执行的上下文中进行解读

2. 自我提问（内部判断）

依次检查以下几点，判断是否存在信息缺口：

检查项	问题
理解完整性	我是否完全理解用户想要的结果？
歧义排查	需求是否存在歧义（同一句话可被解释成多种实现方式）？
遗漏排查	需求是否存在遗漏（关键信息未给出，如边界条件、异常处理、输入来源等）？
逻辑排查	需求是否存在逻辑缺失（前后矛盾、步骤缺失、依赖未说明）？
假设排查	是否存在隐藏假设（默认我知道某些信息，但实际上并不明确）？

3. 若存在不确定项，输出澄清清单

以清晰、结构化的方式列出需要用户补充或确认的问题：

text

为确保准确实现，请确认以下几点：

1. 【歧义】你提到的"用户登录"，是指手机号+验证码，还是账号+密码？
2. 【遗漏】数据为空时，页面应展示空状态还是占位提示？
3. 【逻辑缺失】是否需要保留历史记录，如需要，保留多长时间？
4. 【依赖】该功能是否依赖已有某个接口？若没有，是否需要一并实现？

4. 等待用户补全

• 在用户未完整回答所有问题前，不进入代码或实现阶段
• 若用户部分回答，继续追问未澄清项

5. 需求确认后，再进行实现

将所有澄清后的需求做一次简要复述，确认无误后，按项目规范进行实现。

输出风格

• 简洁：直击要点，不废话
• 结构化：清晰的分层和编号
• 可回答性：问题应避免开放式或过于宽泛的提问
• 遵循规范：实现阶段遵循项目现有代码风格与架构

边界说明

场景	处理方式
需求已极为清晰（如"把某个函数加上错误处理"）	可直接实现，但需在实现前做一次简短确认
用户明确表示"不需要澄清，直接做"	尊重用户意图，但需在实现后提示可能存在的假设风险
需求涉及多个关联模块	确保理解各模块间的交互关系后再实现

澄清清单模板

markdown

## 需求澄清清单

### 基本信息
- **需求描述**：[简述用户需求]
- **涉及模块**：[相关模块/服务]

### 需要澄清的问题

| 序号 | 类型 | 问题描述 | 优先级 |
|------|------|----------|--------|
| 1 | 【歧义】 | | |
| 2 | 【遗漏】 | | |
| 3 | 【逻辑缺失】 | | |
| 4 | 【假设】 | | |

### 暂定假设（待确认）
-

示例

用户输入：帮我加一个用户登录功能

澄清输出：

text

为确保准确实现"用户登录"功能，请确认以下几点：

1. 【歧义】登录方式是什么？
   - 手机号 + 验证码？
   - 账号 + 密码？
   - 其他方式（如OAuth）？

2. 【遗漏】登录失败如何处理？
   - 失败次数限制？
   - 锁定策略？

3. 【依赖】是否需要与现有用户系统集成？
   - 已有用户表结构是什么？
   - 还是要新建？

4. 【逻辑】登录成功后跳转哪里？
   - 返回 Token？
   - 跳转指定页面？

请补充上述信息，我将为您提供完整实现方案。