PRD 生成与审核

基于产品规划文档的完整10章规范框架，将初版需求整理细化为可直接交付开发的标准化PRD，或对已有PRD按规范进行审核并输出改进建议。

工作流程

模式一: PRD生成 (输入=初版需求)

当用户提供粗糙/不完整的需求描述时，按以下步骤生成完整PRD:

1. 加载规范框架 — 阅读 references/prd-framework.md，确保覆盖全部10章要素
2. 分析现有输入 — 提取用户需求中已明确的信息，找出缺失的关键要素
3. 主动提问补全 — 对缺失的 [M]=必须有级别要素，逐项向用户确认。必要时主动追问:
   • 涉及哪些角色？每个角色在本功能中是什么身份(创建者/审批者/查看者)？(Ch.2)
   • 触发条件是否明确？(Ch.3)
   • 异常路径是否全覆盖？(Ch.3)
   • Non-goals 是否明确？(Ch.4)
   • 功能挂在哪个菜单层级下？哪些角色可见？(Ch.5.1)
   • 页面边界是否写全(访问条件/数据量/字段/操作/时间)？(Ch.6)
   • 每个角色能做什么操作、不能做什么操作？数据范围是什么？(Ch.7.2)
4. 生成完整PRD — 按10章结构输出，用 [M]=必须有 [R]=推荐有 标签标注每项要素

模式二: PRD审核 (输入=已有PRD)

当用户提交已完成编写的PRD时，按以下步骤进行审核:

1. 加载规范框架 — 阅读 references/prd-framework.md
2. 逐章对照检查 — 标记:
   • 缺少的 [M]=必须有 要素 → 硬伤，必须补充
   • 缺少的 [R]=推荐有 要素 → 建议补充
   • 已有但表述模糊/不完整的要素 → 需明确化
3. 五问自检 — 模拟一个不了解需求的人，能否回答:
   • 这个功能解决谁的什么问题？
   • 主流程+所有异常分支分别怎么处理？
   • 页面挂在哪个菜单下？哪些角色能看到？
   • 每个角色能做什么操作、不能做什么操作？
   • 提交按钮什么条件下能点、什么条件下不能点？
4. 输出审核报告 — 格式:
   • 总体评分 (10分制)
   • 硬伤清单(必须修复)
   • 建议改进清单
   • 模糊点清单(需进一步明确)

核心原则

1. Why优先于What — 生成PRD前必须讲清楚问题背景和业务目标，不直接罗列功能
2. Non-goals必写 — 每个功能都明确"不做什么"并附原因，防止范围蔓延
3. 角色必须穷举 — 列出所有涉及角色，定义每个角色的职责和功能参与身份
4. 菜单路径必须明确 — 功能挂在哪个菜单层级、哪些角色可见、面包屑路径
5. 权限矩阵必须覆盖四维 — 角色 x 操作 x 资源 x 状态，用矩阵表清晰表示
6. 用户故事标准格式 — 作为 [角色], 我希望 [行为], 以便 [价值]
7. 边界必须明确 — 访问条件、数据量、字段校验、操作限制、时间环境都要覆盖
8. 状态机必须完整 — 有状态流转的功能，必须枚举全部状态+流转条件+回退规则
9. 验收标准用 Given-When-Then — 每个用户故事配验收条件
10. 医疗/金融场景强化合规 — 数据加密字段、日志保留周期、权限矩阵、审计追溯为强制项
11. 沟通看对象 — 给高管的要点1页纸，给工程的详细实现，给客服的场景化材料

输出格式

PRD 生成输出格式: 按 references/prd-framework.md 的10章结构逐章输出，每项要素标注 [M]/[R]/[O] 级别。

PRD 审核输出格式:

## 审核报告: [PRD名称]

**总体评分**: X/10

### 硬伤(必须修复)
1. [缺失项] 章节X: 具体缺失什么
2. [不完整] 章节Y: 哪里不完整

### 建议改进
1. [R] 章节X: 建议补充什么

### 模糊点(需进一步明确)
1. 章节X: 当前描述的问题是什么，建议如何明确