# Proj Analyze Req

> 需求分析与确认（阶段一）。用于理解用户需求、澄清细节、明确功能边界，生成需求分析文档。

- Skill: `zhangloveyan/proj-analyze-req` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhangloveyan/proj-analyze-req`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhangloveyan/proj-analyze-req/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhangloveyan (https://skillmd.com/u/zhangloveyan)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhangloveyan/proj-analyze-req

---


# 需求分析（阶段一）

> **目标**：理解用户真实需求，明确功能边界和业务逻辑，生成需求分析文档。
> **产出**：需求分析文档（用户确认后进入阶段二）

---

## 执行流程

```
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 提问原则

1. **先思考再提问** - 根据需求类型，预判可能涉及的细节点（如：是否多端、是否有状态流转、是否需要关联用户等）
2. **一次性列出** - 将所有待确认问题整理后一次性提出，减少交互轮次
3. **不要假设答案** - 不确定的必须问
4. **追问细节** - 用户回答模糊时继续追问
5. **确认理解** - 复述用户的回答确保理解正确

### 3.3 提问示例

```
我来帮您分析这个需求。为了准确理解，请回答以下问题：

**1. 功能范围**
- 这个功能给谁用？Web后台管理端？小程序端？还是都需要？

**2. 用户角色**
- 涉及哪些角色？各角色分别能做什么操作？

**3. 功能清单**
- 需要哪些具体功能？（如：列表查询、详情查看、新增、编辑、删除、导出...）

**4. 业务流程**
- 主要的业务流程是怎样的？
- 是否有状态流转？（如：待处理→处理中→已完成）

**5. 数据要求**
- 需要记录哪些信息/字段？
- 哪些是必填项？

请逐一回答，我会根据您的回答进一步澄清。
```

---

## Step 4: 输出需求文档

在充分澄清后，使用模板输出需求分析文档。

**模板文件**：[需求文档模板](templates/req-doc.md)

**保存位置**：`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：{场景名称}
{用户角色}在{什么情况下}需要{做什么事情}，期望{达到什么目标}。
```

### 文档完整性要求

必须包含以下章节：
1. 功能概述（业务背景、功能定位、核心价值）
2. 用户角色与场景（角色定义、典型场景）
3. 功能需求详述（每个功能的详细描述）
4. 业务流程（主要流程的Mermaid图）
5. 数据需求（业务视角的数据实体）
6. 非功能性需求（性能、安全、兼容性）
7. 约束条件（技术约束、业务约束）
8. 验收标准（功能验收、性能验收）
9. 风险评估（技术风险、业务风险）

### 技术实现澄清点

需求文档中应澄清以下技术相关问题：
- **消息通知方式**：是否需要实时推送？轮询频率要求？
- **数据实时性要求**：哪些数据需要实时查询？
- **数据保留策略**：永久保存 vs 定期清理？业务数据 vs 日志数据？
- **系统集成方式**：与现有系统如何集成？
- **性能要求**：并发量？响应时间？数据量？

---

## 注意事项

1. **禁止假设** - 用户没说的不要自己编
2. **禁止跳过** - 必须完成澄清才能输出文档
3. **禁止合并** - 需求确认前不要开始技术方案
4. **保持耐心** - 复杂需求可能需要多轮澄清
5. **记录变更** - 如果澄清过程中需求有变化，及时更新文档
6. **严格边界** - 需求文档不能包含技术实现细节
7. **业务导向** - 从用户和业务角度描述需求，不涉及技术如何实现
8. **任务文档** - 需求开始必须创建并持续更新全流程任务文档