PRD 需求分析

分析 HM Desktop PRD 文档并生成结构化的需求分析报告。

快速开始

提供 PRD 文件路径：

分析 PRD: {PRD文件路径}

或指定具体选项：

分析 PRD: {PRD文件路径}
- 输出格式：JSON
- 检查完整性：是
- 提取 KEP：是
- 检测冲突：是

分析流程

1. 文档元数据解析

提取以下信息：

• 文档版本（VX.X 格式）
• 创建日期（YYYY-MM-DD）
• 文档作者/团队
• 产品名称
• 目标版本

2. KEP（关键体验路径）提取

对每个找到的 KEP，提取：

• KEP ID：格式应为 KEP1-01、KEP1-02 等
• KEP 名称：简洁、包含动词的名称
• 优先级：P0（关键）、P1（重要）、P2（可选）
• 用户故事：用户场景描述
• 验收标准：明确的验证条件

3. 需求统计

• 需求总数
• P0 需求数量（发布必需）
• P1 需求数量（重要但不阻塞）
• P2 需求数量（未来增强）

4. 完整性验证

使用 references/completeness_rules.md 中的检查清单验证所有必需章节。

标准章节顺序：需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述

章节顺序验证：

• 第1章：需求来源
• 第2章：需求背景
• 第3章：需求价值分析
• 第4章：竞品分析（必需）
• 第5章：需求描述
• 后续章节是否符合规范

竞品分析章节检查：

• 是否存在独立的竞品分析章节（第4章）
• 竞品数量是否≥2个
• 是否包含竞品功能对比表格
• 是否包含竞品技术方案分析

5. 章节顺序验证

验证 PRD 文档章节是否符合标准顺序：

标准顺序：需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述

检测逻辑：

1. 提取文档中所有一级标题（# 开头）
2. 验证前5章的标题是否符合要求
3. 如顺序错误，列出问题并建议调整
4. 如缺失竞品分析章节，明确提示补充

输出格式：

章节顺序检查结果：
✅ 第1章：需求来源
✅ 第2章：需求背景
✅ 第3章：需求价值分析
❌ 第4章：竞品分析（缺失，需补充）
✅ 第5章：需求描述

6. 冲突检测

检查：

• 同一功能在不同章节描述不一致
• 优先级冲突（P0 项目过多）
• 技术可行性风险
• 矛盾的用户场景

7. 竞品分析章节检查

检查内容：

输出：如竞品分析缺失或不足，生成补充建议模板

8. 模块划分建议

按照 references/module_mapping.md 的指导将需求映射到服务模块。

输出格式

Markdown 报告（默认）

生成 prd_analysis_report.md，包含：

• 文档信息
• 需求概述
• KEP 列表
• 完整性检查结果
• 冲突检测结果
• 模块划分建议

JSON 格式

{
  "prd_info": {
    "file": "{PRD文件名}",
    "version": "VX.X",
    "date": "2026-01-31"
  },
  "requirements": {
    "total": 25,
    "p0": 8,
    "p1": 12,
    "p2": 5
  },
  "kep_list": [...],
  "completeness": {...},
  "conflicts": [...],
  "module_suggestions": [...]
}

参考文档

• PRD 格式要求: references/prd_format.md
• 完整性规则: references/completeness_rules.md
• KEP 验证: references/kep_validation.md
• 模块映射: references/module_mapping.md

报告模板

自定义报告格式，参见 assets/report_template.md。

错误处理

使用示例

基本分析：

分析 {PRD文件路径} 这个 PRD

输出 JSON 格式：

分析 {PRD文件名}，以 JSON 格式输出结果

仅检查完整性：

检查 {PRD文件名} 是否包含所有必需的 PRD 章节

提取 KEP：

从 {PRD文件名} 中提取所有 KEP 定义

检测冲突：

检查 {PRD文件名} 中是否存在需求冲突

模块划分建议：

根据 {PRD文件名} 的需求，建议如何划分服务模块