PRD生成器

本Skill负责将上游阶段的产出（用户洞察、机会定义、创意发散）自动转化为符合质量标准的PRD文档，为后续产品设计（IA、流程、原型）提供结构化输入。需求收集、理解和优先级排序已内建于 design-prd 的 Step 1-3 中，无需单独的需求管理阶段。支持PRD-L/S/X三级分层，自动进行4道质量门禁检查，确保文档完整性、一致性、歧义消除和可追溯性。

核心原则

1. 质量门禁不可绕过——4道门禁是PRD质量的底线，任何情况下不得跳过
2. 分层匹配复杂度——PRD-L/S/X对应不同复杂度，避免过度或不足
3. 追溯链必须贯通——每个功能点可追溯到上游输出和业务目标
4. 人类决策权优先——AI判断置信度<0.7时强制人类确认，PM可覆盖AI分级

执行步骤

1. 确定PRD分层级别（L/S/X）——基于Effort估算和团队数量自动分级，PM可覆盖
2. 按对应层级结构生成PRD文档——PRD-L使用简化模板，PRD-S使用完整9节结构，PRD-X使用增强版9节结构
3. 执行4道质量门禁检查——完整性/一致性/歧义消除/可追溯性，不通过则自动修正
4. 版本生命周期管理——创建→评审→定稿→变更，每次变更记录变更日志
5. 上下游衔接——确保PRD可追溯到上游需求，下游设计可直接消费PRD输出

详见下方各章节详细说明。

1. PRD分层体系

1.1 分层定义

1.2 自动分级规则

分级判定算法：
1. 提取上游输出的Effort估算（单位：人天）
2. 统计涉及团队数量（开发、设计、测试、运营等）
3. 应用分层决策树：
   IF Effort < 2 AND 团队数 ≤ 1 THEN PRD-L
   ELSE IF Effort <= 20 AND 团队数 ≤ 3 THEN PRD-S
   ELSE PRD-X

1.3 人类可覆盖AI判断

• PM可手动指定分层级别，无需遵循自动判断
• 覆盖时需在文档元信息中记录覆盖原因
• 自动判断置信度 < 0.7时，强制要求人类确认

2. PRD-S完整9节结构

以下为PRD-S（Standard）的标准结构，PRD-L和PRD-X在此基础上按比例调整。

完整结构定义：详见 Reference/prd-structure.md

结构概览

3. 质量门禁

门禁1：完整性检查

检查清单：

• [ ] 9节结构全部存在
• [ ] 所有必填字段已填充
• [ ] MoSCoW分级已标注
• [ ] Given-When-Then验收标准已覆盖主流程
• [ ] 状态设计覆盖5种特殊状态
• [ ] 非功能需求包含4个维度

失败处理：

• 阻塞生成流程
• 输出缺失项清单
• 提示补充方向

门禁2：一致性检查

检查规则：

• OKR目标 → 成功指标 一致性
• 指标 → 功能需求 一致性
• 功能需求 → 验收标准 一致性
• 上下游引用是否存在

追溯链：

战略目标 → OKR → 关键结果 → 主指标 → 功能需求 → 验收标准

失败处理：

• 标识不一致位置
• 提供修正建议
• 记录为待确认项

门禁3：歧义检查

自动检查项：

• 模糊量词检测（"快速"、"大量"、"偶尔"等）
• 悬空引用检测（引用不存在的图表、字段、接口）
• 逻辑矛盾检测（前置条件与结果矛盾）

人类复核项：

• 业务规则合理性
• 用户场景真实性
• 技术方案可行性

失败处理：

• 自动修正可识别歧义
• 标记需人类确认项
• 生成歧义澄清问题清单

门禁4：可追溯性检查

追溯要求：

• 每个功能点可追溯到上游输出
• 每个验收标准可追溯到具体指标
• 每个指标可追溯到业务目标

失败处理：

• 生成追溯链断点报告
• 提示缺失的追溯路径
• 要求补充上游证据

4. 版本生命周期

4.1 版本状态机

┌─────────────────────────────────────────────────────────────┐
│                                                             │
│   v0.1 AI初稿  →  v0.2 PM精炼  →  v0.3 评审修改             │
│       ↓                ↓               ↓                    │
│   自动生成         人工修订        评审反馈                  │
│                                                             │
│   v1.0 定稿  →  v1.x 开发变更  →  v2.0 上线更新             │
│       ↓               ↓               ↓                    │
│   评审通过       开发中调整      上线后复盘                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.2 版本定义

4.3 状态流转

5. 执行决策逻辑

5.1 生成顺序依赖图

拓扑排序规则：

生成优先级（从高到低）：
1. 元信息（Section 1）- 无依赖
2. 背景与目标（Section 2）- 依赖上游探索输出
3. 方案设计（Section 3）- 依赖Section 2和设计输出
4. 边界与约束（Section 4）- 依赖Section 3
5. 非功能需求（Section 5）- 依赖Section 3
6. 数据埋点（Section 6）- 依赖Section 3
7. 验收标准（Section 7）- 依赖Section 2, 3
8. 发布与运营（Section 8）- 依赖Section 7
9. 附录（Section 9）- 依赖其他所有Section

5.2 上游冲突决策规则

冲突类型与处理策略：

升级决策矩阵：

升级阈值：
- 来源数 ≥ 2 且结论不一致
- MVP范围变化 > 30%
- 涉及安全合规问题
- 涉及重大技术债务

升级路径：
1. 记录冲突详情
2. 召集相关方会议
3. 产出决策纪要
4. 更新PRD

5.3 上游数据不完整处理

缺失等级定义：

缺失处理流程：

检测缺失 → 判断等级 → 应用策略 → 输出结果

L0处理：
1. 标注"AI补充，待确认"
2. 提供置信度评分
3. 生成确认问题清单

L1处理：
1. 标注"待补充"
2. 使用默认值或模板填充
3. 阻塞相关下游生成
4. 生成补充清单

L2处理：
1. 标注"缺少核心输入"
2. 输出中断报告
3. 指定缺失字段
4. 要求重新输入

5.4 自校正循环

触发条件：

• 门禁检查失败
• 人类反馈修正
• 上游数据更新

循环限制：

• 最大自校正轮次：3轮
• 每轮超时时间：5分钟
• 超出限制后输出问题报告，人工介入

自校正流程：

第N轮校正：
1. 分析失败原因
2. 生成修正方案
3. 应用修正
4. 重新执行门禁检查
5. 若通过则结束，否则进入第N+1轮

6. 上下游衔接

6.1 上游消费

6.2 下游驱动

6.3 数据流向图

[洞察分析产出] → [机会定义产出] → [创意发散产出]
        ↓              ↓                ↓
        └──────────────┴────────────────┘
                      ↓
          PRD生成器（需求收集、理解、优先级排序已内建于 Step 1-3）
                      ↓
        ┌─────────┼─────────┐
        ↓         ↓         ↓
[IA设计]  [流程设计]  [原型设计]

交互模式

🤖→👤 AI建议人类审批

输入

完整输入数据结构与验证规则：详见 Reference/input-schema.md

输出

完整输出数据结构与模板：详见 Reference/output-schema.md

prd.json 结构定义

prd.json 是 PRD 的机器可消费版本，供 Backend/UI 下游 Skill 编程式消费，确保功能点、页面、实体、用户流程等核心信息可被自动解析和对齐。

{
  "prd_id": "string",
  "version": "string",
  "level": "L | S | X",
  "status": "draft | in_review | approved | released",
  "meta": {
    "title": "string",
    "owner": "string",
    "created_at": "ISO8601",
    "updated_at": "ISO8601"
  },
  "goals": [
    {
      "goal_id": "string",
      "description": "string",
      "okr_alignment": "string",
      "success_metrics": [
        {
          "metric_name": "string",
          "target_value": "string",
          "current_value": "string | null",
          "unit": "string"
        }
      ]
    }
  ],
  "features": [
    {
      "feature_id": "string",
      "name": "string",
      "description": "string",
      "priority": "must | should | could | wont",
      "status": "planned | in_progress | completed | cancelled",
      "goal_id": "string",
      "acceptance_criteria": [
        {
          "criterion_id": "string",
          "given": "string",
          "when": "string",
          "then": "string"
        }
      ],
      "dependencies": ["feature_id"],
      "related_pages": ["page_id"],
      "related_entities": ["entity_id"]
    }
  ],
  "pages": [
    {
      "page_id": "string",
      "name": "string",
      "route": "string",
      "description": "string",
      "data_requirements": [
        {
          "data_name": "string",
          "source": "api | local | cache",
          "api_endpoint": "string | null",
          "fields": ["string"]
        }
      ],
      "functional_areas": ["string"],
      "user_flows": ["flow_id"],
      "states": [
        {
          "state_name": "string",
          "description": "string",
          "triggers": ["string"]
        }
      ]
    }
  ],
  "entities": [
    {
      "entity_id": "string",
      "name": "string",
      "description": "string",
      "fields": [
        {
          "field_name": "string",
          "type": "string",
          "required": "boolean",
          "description": "string",
          "constraints": "string | null"
        }
      ],
      "relationships": [
        {
          "target_entity_id": "string",
          "type": "one_to_one | one_to_many | many_to_many",
          "description": "string"
        }
      ],
      "api_endpoints": [
        {
          "method": "GET | POST | PUT | PATCH | DELETE",
          "path": "string",
          "description": "string"
        }
      ]
    }
  ],
  "user_flows": [
    {
      "flow_id": "string",
      "name": "string",
      "description": "string",
      "entry_page": "page_id",
      "steps": [
        {
          "step_id": "string",
          "action": "string",
          "page_id": "string",
          "expected_outcome": "string",
          "error_handling": "string | null"
        }
      ],
      "alternative_paths": [
        {
          "condition": "string",
          "steps": ["step_id"]
        }
      ]
    }
  ],
  "non_functional_requirements": {
    "performance": [
      {
        "requirement": "string",
        "metric": "string",
        "target": "string"
      }
    ],
    "availability": [
      {
        "requirement": "string",
        "metric": "string",
        "target": "string",
        "measurement": "string"
      }
    ],
    "security": [
      {
        "category": "authentication | authorization | encryption | audit | compliance",
        "requirement": "string",
        "implementation": "string"
      }
    ],
    "observability": [
      {
        "dimension": "metrics | logs | traces",
        "indicator": "string",
        "alert_threshold": "string"
      }
    ]
  },
  "tracking_plan": {
    "events": [
      {
        "event_id": "string",
        "event_name": "string",
        "trigger": "string",
        "properties": [
          {
            "property_name": "string",
            "type": "string",
            "required": "boolean"
          }
        ],
        "related_metric": "string"
      }
    ],
    "validation": {
      "coverage_target": "number",
      "data_delay_threshold": "string"
    }
  },
  "traceability": [
    {
      "feature_id": "string",
      "goal_id": "string",
      "upstream_source": "string",
      "upstream_artifact_id": "string"
    }
  ]
}

prd.json 与 prd.md 的关系

输出校验规则

• [ ] 9节结构完整：PRD-S完整9节结构全部存在
• [ ] 追溯链贯通：从OKR到验收标准的追溯链完整
• [ ] 门禁通过：4道质量门禁全部通过
• [ ] 无歧义残留：无模糊量词和悬空引用
• [ ] prd.json 完整性：features/pages/entities/user_flows 四个数组均非空
• [ ] prd.json 引用一致性：feature.related_pages 中的 page_id 在 pages[] 中存在，feature.related_entities 中的 entity_id 在 entities[] 中存在
• [ ] prd.json 追溯链完整：每个 feature 都有对应的 traceability 条目
• [ ] prd.json 与 prd.md 一致：prd.json 中的功能点名称、优先级、验收标准与 prd.md 一致
• [ ] prd.json tracking_plan 完整性：tracking_plan.events 非空，每个 event 的 properties 非空
• [ ] prd.json NFR完整性：non_functional_requirements 的4个维度数组均非空

决策规则（详细）

9.1 门禁通过规则

硬性条件：

• 4道门禁必须全部通过
• 任一门禁失败则阻塞进入开发阶段

门禁状态映射：

9.2 冲突升级规则

必须升级的情况：

1. 来源冲突：需求涉及 ≥ 2个上游来源，且结论不一致
2. 范围剧变：MVP范围变化 > 30%
3. 安全合规：涉及用户隐私、安全合规、金融监管等敏感领域
4. 资源超限：需求资源消耗超过原计划的50%
5. 技术风险：方案涉及技术架构重大调整

升级流程：

1. 识别升级触发条件
2. 生成升级报告（冲突详情+各方立场+影响分析）
3. 确定升级层级（PM/产品委员会/管理层）
4. 召开决策会议
5. 产出决策纪要
6. 更新PRD

9.3 开放问题管理

开放问题状态：

• Open：未解决
• In Progress：处理中
• Resolved：已解决
• Won't Fix：明确不做

定稿规则：

• 所有Open问题必须已解决或转为Won't Fix
• 定稿时输出问题闭环报告

质量检查（详细）

10.1 完整性标准

10.2 一致性标准

10.3 歧义消除标准

10.4 可执行性标准

降级策略

上游文件缺失降级方案

数据获取说明

当上游文件缺失时，需用户提供以下信息以支撑降级生成：

• 产品需求描述：核心需求是什么，解决什么问题
• 目标用户：产品的目标用户群体是谁
• 核心功能列表：需要实现的主要功能点

上游变更响应

当上游输入发生变更时，本Skill的响应策略：

当PRD自身变更时，对下游的通知机制：

变更记录

• v3.0: 将PRD完整9节结构、输入Schema、输出Schema拆分到Reference文件夹，SKILL.md保留核心逻辑和概览表格
• v3.1: 需求管理内建——输入新增insight_analysis和opportunity_definition引用（替代原requirements-collection/understanding/prioritization输入）；标注需求收集、理解和优先级排序已内建于Step 1-3；上游消费新增洞察分析和机会定义；降级策略新增insight_analysis/opportunity_definition缺失方案；数据流向图更新
• v3.2: 新增prd.json结构化输出——包含features[]/pages[]/entities[]/user_flows[]/goals[]/traceability[]，供Backend/UI编程式消费；下游驱动表新增消费来源列；输出校验规则新增prd.json完整性和引用一致性检查
• v3.3: prd.json补全——non_functional_requirements的availability/security/observability从空数组补全为完整Schema；新增tracking_plan数据埋点结构；input-schema.md补充insight_analysis/opportunity_definition字段；删除重复的质量检查和决策规则章节；prd-structure.md PRD-L/X调整规则具体化；OKR对齐格式与prd.json goals[]结构对齐