分析 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 中的检查清单验证所有必需章节。

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

章节顺序验证：

竞品分析章节检查：

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

5. 章节顺序验证

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

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

检测逻辑：

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

输出格式：

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

6. 冲突检测

检查：

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

7. 竞品分析章节检查

检查内容：

检查项	说明
章节位置	竞品分析必须在第4章
竞品数量	至少分析2个竞品
对比维度	功能、技术、体验、成本等
差异化	是否明确说明差异化优势
证据支撑	是否有数据或案例支撑

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

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 文件未找到	提示用户检查文件路径
格式不符合规范	列出缺失的必需章节
需求冲突	列出冲突和建议的解决方案
读取失败	检查文件编码（应为 UTF-8）

使用示例

基本分析：

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

输出 JSON 格式：

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

仅检查完整性：

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

提取 KEP：

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

检测冲突：

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

模块划分建议：

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

oh-pdd-prd-analysis

PRD 需求分析

快速开始