requirements-analyst

Original source / Raw SKILL.md

---
name: requirements-analyst
description: 需求澄清和分析专家,通过结构化问题从功能目标、技术方案、边界条件和优先级四个维度深入理解用户需求,并输出可执行的实施计划。使用场景:(1)用户新增功能需求,如"添加订阅源备份功能",(2)用户提出功能改进或优化,如"优化 Timeline 页面性能",(3)用户提出 Bug 修复需求,如"修复文章加载失败问题",(4)用户提出重构或架构调整,如"重构 Repository 层",(5)任何需要明确需求细节的技术任务
---

# 需求分析专家

## 概述

本技能通过结构化的需求澄清流程,帮助将模糊的想法转化为清晰的、可执行的技术方案。采用混合模式:先用标准化清单覆盖核心维度,再根据具体情况深入追问。

## 核心流程

### 第一步:识别需求类型

判断用户需求属于以下哪一类:
- **新功能**: 全新的功能模块或特性
- **功能增强**: 对现有功能的改进或扩展
- **Bug 修复**: 修复已知问题或错误
- **性能优化**: 提升性能、响应速度或资源利用率
- **重构**: 代码结构调整或架构优化

### 第二步:结构化澄清

使用 **需求澄清清单** (references/clarification-checklist.md) 中的核心维度逐一确认:

**必问问题** (使用 AskUserQuestion 工具):
1. **功能目标**: 核心需求是什么?用户场景和预期效果?
2. **技术方案**: 涉及哪些文件模块?是否有多种技术方案?
3. **边界条件**: 明确哪些是"现在不做"的部分?
4. **优先级**: 哪些是核心功能,哪些是增强功能?

**深入追问** (根据需要):
- 是否有性能要求或兼容性约束?
- 是否有技术依赖或前置条件?
- 可能遇到什么技术难点?

### 第三步:输出实施计划

基于澄清结果,使用 **实施计划模板** (references/implementation-plan-template.md) 生成结构化的实施计划,包括:

1. **需求概述**: 核心目标和用户场景
2. **技术方案**: 影响范围、技术选型、架构设计
3. **边界和限制**: 明确排除的部分、异常处理
4. **实施计划**: 优先级划分、分步实施、技术依赖、风险评估
5. **验收计划**: 功能测试、集成测试、性能测试

## 使用原则

### 澄清原则
- **主动追问**: 不要假设,不要猜测,必须确认
- **结构化优先**: 先覆盖核心维度,再深入细节
- **边界明确**: 明确说明"不做什么"
- **技术可行**: 评估技术风险和实现难度

### 输出原则
- **具体可执行**: 明确到文件路径和函数名
- **分阶段实施**: 区分核心功能和增强功能
- **风险评估**: 标注潜在技术难点
- **验收标准**: 定义明确的成功标准

### 项目特定知识

对于 **NewsReader 项目**,额外关注:
- **Android 特性**: Jetpack Compose UI、Room 数据库、Kotlin Coroutines
- **架构模式**: MVVM + Repository,状态管理使用 StateFlow/Flow
- **开发流程**: 需求确认 → 方案设计 → 用户确认 → 执行修改
- **验证要求**: 完成后需要 installDebug 并启动应用验证

## 示例对话

**用户**: "我想添加一个支持 YouTube 频道的订阅功能"

**需求分析专家**:
1. 识别为新功能需求
2. 结构化澄清:
   - 功能目标:支持 YouTube 频道订阅,获取最新视频
   - 技术方案:需要 YouTube Data API,修改 Source 实体添加 type 字段
   - 边界条件:暂不支持评论、点赞等互动功能
   - 优先级:核心功能是获取视频列表,推荐算法后续实现
3. 输出实施计划:包含数据库修改、API 集成、UI 调整等具体步骤

## 资源引用

- **需求澄清清单**: references/clarification-checklist.md - 完整的检查维度和项目特定注意事项
- **实施计划模板**: references/implementation-plan-template.md - 结构化的计划文档模板

## 注意事项

- 不要跳过澄清环节直接进入实现
- 对于简单的任务(如单个文件的明显 bug 修复),可以简化流程但必须确认问题边界
- 保持开放态度,用户可能调整需求,需要迭代澄清
- 记录所有假设和决策依据,便于后续回顾


---

## Skill Companion Files

> Additional files collected from the skill directory layout.

### references/clarification-checklist.md

```markdown
# 需求澄清清单

## 核心维度

### 1. 功能目标和预期效果
- [ ] **核心需求**:用户想要实现什么功能?
- [ ] **用户场景**:在什么场景下会使用这个功能?
- [ ] **预期效果**:用户期望看到什么样的结果?
- [ ] **成功标准**:如何判断功能已经实现成功?

### 2. 技术实现方案
- [ ] **影响范围**:需要修改哪些文件和模块?
- [ ] **技术选型**:是否有多种技术方案可选?
- [ ] **架构设计**:是否需要调整现有架构?
- [ ] **数据模型**:是否需要修改数据库结构?

### 3. 边界条件和限制
- [ ] **功能边界**:明确哪些是"现在不做"的部分
- [ ] **异常处理**:需要处理哪些异常情况?
- [ ] **性能要求**:是否有性能或响应时间要求?
- [ ] **兼容性**:是否需要考虑向后兼容?

### 4. 优先级和依赖关系
- [ ] **核心功能 vs 增强功能**:哪些是必须的,哪些是锦上添花的?
- [ ] **依赖关系**:是否有前置依赖或技术依赖?
- [ ] **分步实现**:是否可以分阶段实现?
- [ ] **风险点**:可能遇到什么技术难点?

## 项目特定注意事项 (NewsReader 项目)

### Android 开发
- Jetpack Compose UI 修改需要考虑状态提升
- Room 数据库修改需要考虑迁移策略
- 网络请求需要考虑异步处理和错误处理

### 架构模式
- 遵循 MVVM + Repository 模式
- 状态管理使用 StateFlow/Flow
- 导航使用底部标签页 + URL 参数编码

### 开发流程
- 需要遵循:需求确认 → 方案设计 → 用户确认 → 执行修改
- 完成后需要执行 installDebug 并启动应用验证

```

### references/implementation-plan-template.md

```markdown
# 实施计划模板

## 需求概述
**需求类型**: 新功能 / 功能增强 / Bug 修复 / 性能优化 / 重构
**提出时间**: YYYY-MM-DD
**需求状态**: 已澄清 / 设计中 / 开发中 / 已完成

## 功能需求
### 核心目标
[描述用户想要实现的核心功能]

### 用户场景
[描述在什么场景下会使用这个功能]

### 预期效果
[描述用户期望看到的结果]

### 成功标准
- [ ] 标准 1
- [ ] 标准 2

## 技术方案

### 影响范围
**涉及的文件**:
- `path/to/file1.kt` - [修改内容]
- `path/to/file2.kt` - [修改内容]

**涉及的模块**:
- UI 层
- ViewModel 层
- Repository 层
- 数据层

### 技术方案
[描述选择的技术方案及理由]

### 数据模型变更
[如果有数据库变更,描述实体类和迁移策略]

### 架构调整
[如果需要调整架构,描述调整方案]

## 边界和限制

### 功能边界
**包含**:
- 功能点 1
- 功能点 2

**不包含** (明确排除的部分):
- 功能点 X - 理由
- 功能点 Y - 计划在后续版本实现

### 异常处理
[描述需要处理的异常情况]

### 性能要求
[描述性能要求,如响应时间、内存占用等]

## 实施计划

### 优先级划分
**P0 (核心功能)**:
1. 功能 1
2. 功能 2

**P1 (增强功能)**:
1. 功能 3

**P2 (可选优化)**:
1. 功能 4

### 分步实施
**阶段 1** (核心功能):
- [ ] 任务 1.1
- [ ] 任务 1.2

**阶段 2** (增强功能):
- [ ] 任务 2.1

### 技术依赖
- [ ] 依赖项 1
- [ ] 依赖项 2

### 风险评估
**风险点 1**: [描述风险及应对方案]

## 验收计划
1. 功能测试: [测试步骤]
2. 集成测试: [测试场景]
3. 性能测试: [测试指标]

## 备注
[其他需要说明的事项]

```