PRD 生成与审核
基于产品规划文档的完整10章规范框架，将初版需求整理细化为可直接交付开发的标准化PRD，或对已有PRD按规范进行审核并输出改进建议。
工作流程
模式一: PRD生成 (输入=初版需求)
当用户提供粗糙/不完整的需求描述时，按以下步骤生成完整PRD:
- 加载规范框架 — 阅读
references/prd-framework.md，确保覆盖全部10章要素 - 分析现有输入 — 提取用户需求中已明确的信息，找出缺失的关键要素
- 主动提问补全 — 对缺失的 [M]=必须有级别要素，逐项向用户确认。必要时主动追问:
- 涉及哪些角色？每个角色在本功能中是什么身份(创建者/审批者/查看者)？(Ch.2)
- 触发条件是否明确？(Ch.3)
- 异常路径是否全覆盖？(Ch.3)
- Non-goals 是否明确？(Ch.4)
- 功能挂在哪个菜单层级下？哪些角色可见？(Ch.5.1)
- 页面边界是否写全(访问条件/数据量/字段/操作/时间)？(Ch.6)
- 每个角色能做什么操作、不能做什么操作？数据范围是什么？(Ch.7.2) - 生成完整PRD — 按10章结构输出，用 [M]=必须有 [R]=推荐有 标签标注每项要素
模式二: PRD审核 (输入=已有PRD)
当用户提交已完成编写的PRD时，按以下步骤进行审核:
- 加载规范框架 — 阅读
references/prd-framework.md - 逐章对照检查 — 标记:
- 缺少的 [M]=必须有 要素 → 硬伤，必须补充
- 缺少的 [R]=推荐有 要素 → 建议补充
- 已有但表述模糊/不完整的要素 → 需明确化 - 五问自检 — 模拟一个不了解需求的人，能否回答:
- 这个功能解决谁的什么问题？
- 主流程+所有异常分支分别怎么处理？
- 页面挂在哪个菜单下？哪些角色能看到？
- 每个角色能做什么操作、不能做什么操作？
- 提交按钮什么条件下能点、什么条件下不能点？ - 输出审核报告 — 格式:
- 总体评分 (10分制)
- 硬伤清单(必须修复)
- 建议改进清单
- 模糊点清单(需进一步明确)
核心原则
- Why优先于What — 生成PRD前必须讲清楚问题背景和业务目标，不直接罗列功能
- Non-goals必写 — 每个功能都明确"不做什么"并附原因，防止范围蔓延
- 角色必须穷举 — 列出所有涉及角色，定义每个角色的职责和功能参与身份
- 菜单路径必须明确 — 功能挂在哪个菜单层级、哪些角色可见、面包屑路径
- 权限矩阵必须覆盖四维 — 角色 x 操作 x 资源 x 状态，用矩阵表清晰表示
- 用户故事标准格式 —
作为 [角色], 我希望 [行为], 以便 [价值] - 边界必须明确 — 访问条件、数据量、字段校验、操作限制、时间环境都要覆盖
- 状态机必须完整 — 有状态流转的功能，必须枚举全部状态+流转条件+回退规则
- 验收标准用 Given-When-Then — 每个用户故事配验收条件
- 医疗/金融场景强化合规 — 数据加密字段、日志保留周期、权限矩阵、审计追溯为强制项
- 沟通看对象 — 给高管的要点1页纸，给工程的详细实现，给客服的场景化材料
输出格式
PRD 生成输出格式: 按 references/prd-framework.md 的10章结构逐章输出，每项要素标注 [M]/[R]/[O] 级别。
PRD 审核输出格式:
## 审核报告: [PRD名称]
**总体评分**: X/10
### 硬伤(必须修复)
1. [缺失项] 章节X: 具体缺失什么
2. [不完整] 章节Y: 哪里不完整
### 建议改进
1. [R] 章节X: 建议补充什么
### 模糊点(需进一步明确)
1. 章节X: 当前描述的问题是什么，建议如何明确
