PRD 文档处理专家

问题从哪来

很多团队把「需求」直接丢给开发：背景和目标一笔带过，异常路径和 Non-goals 没写，菜单挂在哪、谁能点提交也不清楚。结果评审会上反复追问，实现阶段还在改范围。已有 PRD 也常是章节齐全但硬伤（缺 [M] 级要素）和表述模糊并存，工程无法据此拆任务、写验收。

技能怎么工作

本技能围绕 references/prd-framework.md 的十章规范框架，分两种模式运行。

模式一：PRD 生成（输入为初版/粗糙需求）

1. 加载规范框架，对照十章要素。
2. 从用户输入中提取已明确信息，标出缺失项。
3. 对缺失的 [M] 必须有 项主动提问补全（角色与身份、触发条件、异常路径、Non-goals、菜单层级与可见角色、页面边界、权限与数据范围等）。
4. 按十章结构输出完整 PRD，每项标注 [M] / [R] / [O] 级别。

模式二：PRD 审核（输入为已有 PRD）

1. 逐章对照框架，区分硬伤（缺 [M]）、建议项（缺 [R]）、需明确化的模糊表述。
2. 用五问自检模拟「不了解需求的人」能否答清：为谁解决什么问题、主流程与异常、菜单与角色可见性、各角色能做/不能做什么、提交按钮的启用条件。
3. 输出审核报告：10 分制总分、硬伤清单、建议改进、模糊点清单。

核心原则贯穿两种模式：Why 优先于 What、Non-goals 必写、角色穷举、菜单路径明确、权限四维矩阵（角色 × 操作 × 资源 × 状态）、用户故事与 Given-When-Then 验收；医疗/金融场景会强化合规项（加密字段、日志保留、审计追溯等）。

适用边界

• 依赖你提供的 prd-framework.md 与对话中的补全信息；未确认的 [M] 项不应被模型静默编造。
• 审核输出是结构化检查与改进建议，不替代产品决策或与业务方签字。
• 「沟通看对象」在原则里提到（高管一页纸、工程细稿、客服场景化），具体裁切仍需你按受众手动调整篇幅。