/analyze-prd

分析 PRD 文档

从 Confluence Wiki 获取 PRD 内容，从前端开发视角一次性完成分析，生成两份报告：

• 分析报告.md — 功能点拆解，给开发团队看
• 疑惑点报告.md — 需要找产品经理确认的问题清单，可直接转发

不要与用户进行多轮问答。不要分步确认。读完 PRD 后一次性完成所有分析并生成两份报告。 疑惑和不确定的地方全部写入疑惑点报告，让用户拿去找产品确认。

第一步：提取 pageId

从用户输入中提取 Confluence pageId：

• 纯数字 → 直接作为 pageId
• URL 包含 pageId=(\d+) → 提取该数字
• URL 包含 /pages/(\d+) → 提取该数字
• 无法提取 → 告知用户格式不正确，要求重新输入

第二步：获取 PRD 内容

1. 调用 mcp__mbfe-docs__wiki_getMarkdown(pageId: "<pageId>") 获取完整 markdown
2. 如果获取失败，告知用户并终止
3. 从内容中提取 PRD 标题和一个简短英文主题词（如 invoice-management），用于目录命名

第三步：从前端视角一次性分析

阅读完整 PRD，按以下维度进行全面分析。不要向用户提问，所有不确定的点写入疑惑点报告。

分析维度

功能需求拆解：

• 逐条列出每个功能点，标注优先级（如 PRD 有提及）
• 识别功能点之间的依赖关系

页面与路由：

• 需要创建的页面/路由
• 页面间导航关系
• URL 结构建议

UI 组件拆解：

• 每个页面的组件列表和层级关系
• 可复用组件识别
• 组件 Props 接口初步设计

数据流与状态管理：

• 页面级状态 vs 全局状态
• 数据来源（API / 本地 / URL 参数）
• 表单数据流、缓存策略

API 依赖：

• 所有需要的后端 API（从 PRD 推断）
• 每个 API 的用途、请求参数、预期响应
• 调用时机（页面加载 / 用户操作 / 轮询）
• 标注 PRD 未明确但前端必需的 API

交互与 UX 细节：

• 加载状态、空状态、错误状态处理
• 表单校验规则
• 权限控制点

非功能性需求：

• 性能、兼容性、国际化、埋点/监控

疑惑点识别

分析过程中同时识别以下类型的疑惑点：

类型	含义
需求模糊	PRD 描述不清晰、有歧义、可多种理解
需求缺失	前端实现必需但 PRD 未提及（边界条件、异常流程、权限规则等）
需求矛盾	PRD 内部自相矛盾的描述
技术可行性	技术上难以实现或成本极高，需产品确认是否必要
设计缺失	提到了功能但没有 UI/交互设计

第四步：生成报告

创建输出目录：docs/superpowers/prd-analysis/YYYY-MM-DD-<topic>/

文件 1：分析报告.md

# <PRD 标题> — 前端功能分析报告

> 来源：<Wiki 链接>
> 生成时间：YYYY-MM-DD HH:mm
> 状态：待评审

## 1. 需求概述

（一段话总结 PRD 核心目标）

## 2. 功能点清单

| 编号 | 功能点 | 优先级 | 依赖 | 备注 |
|------|--------|--------|------|------|
| F001 | ...    | P0     | -    | ...  |

## 3. 页面与路由

| 页面名称 | 路由路径 | 入口 | 说明 |
|----------|----------|------|------|

## 4. 组件拆解

### 4.1 <页面A>

- ComponentX
  - Props: { ... }
  - 子组件: [...]
  - 状态: 本地 / 全局

（每个页面一个子章节）

### 4.N 可复用组件

| 组件名 | 使用页面 | 说明 |
|--------|----------|------|

## 5. 数据流与状态

### 5.1 全局状态
### 5.2 页面级状态
### 5.3 数据来源映射

## 6. API 依赖

| 编号 | API 用途 | 方法 | 路径(推测) | 调用时机 | PRD 是否明确 |
|------|----------|------|------------|----------|--------------|
| A001 | ...      | GET  | /api/...   | 页面加载 | 是/否        |

## 7. 交互细节

### 7.1 加载状态
### 7.2 空状态
### 7.3 错误处理
### 7.4 表单校验
### 7.5 权限控制

## 8. 非功能性需求

（性能、兼容性、国际化、埋点等）

## 9. 工作量预估

| 模块 | 预估人天 | 说明 |
|------|----------|------|

文件 2：疑惑点报告.md

这份报告要方便用户直接转发给产品经理。每个疑惑点必须有清晰的上下文、PRD 原文引用和具体问题。

# <PRD 标题> — 疑惑点报告

> 来源：<Wiki 链接>
> 生成时间：YYYY-MM-DD HH:mm
> 请产品经理逐条确认以下问题，确认后前端方可开始开发。

## 需求模糊（PRD 描述不清晰）

### Q001: <简短标题>
**PRD 原文：** "<引用 PRD 中的原文>"
**疑惑：** <具体哪里不清晰>
**可能的理解：**
- A: ...
- B: ...
**前端建议：** <倾向的方案，供产品参考>

---

## 需求缺失（前端必需但 PRD 未提及）

### Q00N: <简短标题>
**场景：** <什么情况下会遇到这个问题>
**需要确认：** <具体需要产品给出什么信息>
**不确认的影响：** <前端会如何处理 / 可能导致什么问题>

---

## 需求矛盾

### Q00N: <简短标题>
**矛盾点：**
- PRD 第 X 节说："..."
- PRD 第 Y 节说："..."
**需要确认：** 以哪个为准？

---

## 技术可行性

### Q00N: <简短标题>
**PRD 要求：** "..."
**技术评估：** <为什么难以实现或成本高>
**替代方案：** <建议的替代实现>
**需要确认：** 是否接受替代方案？

---

## 设计缺失

### Q00N: <简短标题>
**功能点：** <哪个功能>
**缺失内容：** <缺少什么设计/交互说明>
**需要补充：** <具体需要设计师/产品提供什么>

---

## 统计

共 N 个疑惑点：
- 需求模糊：X 个
- 需求缺失：X 个
- 需求矛盾：X 个
- 技术可行性：X 个
- 设计缺失：X 个

第五步：输出总结

生成报告后，向用户展示：

1. 两份报告的保存路径
2. 功能点总数
3. 疑惑点总数及分类统计
4. 提示：「建议将疑惑点报告发给产品经理确认后，再使用 /generate-code 命令进入代码生成阶段」