PRD 评审与生成

要解决什么问题

产品侧常见输入是截图、Excel、口头描述或半成品 Word，信息分散且容易在边界、异常态和「为什么要做」上留白。下游若要把需求交给原型生成 Agent，自然语言概述往往不够：组件树、状态机、响应式断点一旦缺失，Agent 只能猜。

技能如何工作

本技能按 解析 → 评审 → 澄清 → 生成 四阶段执行：

1. 解析与理解：从多模态输入中提取产品名、用户群、功能列表、流程与约束，并按场景（客户反馈 / 战略规划 / 技术债）调整评审侧重；按页面与模块规模选择 完整版 / 精简版 / 增量 PRD 模板。
2. 需求评审：遵循「问题优先于解决方案」「验证而非假设」等原则，对照 REVIEW-CHECKLIST.md 的七个维度检查，并额外核对原型可行性（布局是否到组件级、交互是否有事件与状态、是否有断点规则）。
3. 问题澄清：评审发现的问题必须在对话中 分批提问（每批最多 4 个，先 P0 再 P1），禁止跳过澄清或把未答问题写进 PRD 当 [待确认]；P0 未清完不得进入生成阶段。
4. 生成 PRD：在 P0 全部澄清后，按 PRD-TEMPLATE.md 输出；页面规格要求 组件级精度、状态机描述、响应式与动效参数，多页面时采用 主文档 + pages/page-*.md，并生成 README.md 索引。

适用边界与注意点

• 适合需要从杂乱输入收敛到 可给原型 Agent 直接消费 的 PRD，而非仅做会议纪要式记录。
• 增量场景需有可引用的现有 PRD 基线；规模无法判断时默认完整版，可在澄清阶段与用户确认。
• 生成草稿后仍会邀请你迭代修改；文中对仍有疑问处可用 [待确认] 标注，但 不应 用该方式替代阶段三的对话澄清。