需求澄清与分析#

触发条件#

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

核心目标#

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

执行流程#

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

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

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

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

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

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

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

text

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

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

4. 等待用户补全#

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

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

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

输出风格#

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

边界说明#

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

澄清清单模板#

markdown

## 需求澄清清单

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

### 需要澄清的问题

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

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

示例#

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

澄清输出：

text

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

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

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

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

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

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