pm-prd-writer

# PM PRD Writer ## Purpose 把输入需求转化为结构完整、逻辑清晰、可进入研发评审的 PRD。输出应偏真实业务交付，能帮助研发、测试、设计、运营和业务方理解范围、规则和验收标准。 ## When to Use - 用户要求写 PRD、需求文档、产品方案、功能说明、需求拆解。 - 用户提供的是零散想法、会议纪要、客户反馈、竞品截图描述或老板口头需求。 - 需求涉及多角色协作、复杂业务流程、权限配置、数据规则或 AI 能力等产品场景。 ## Input 优先识别以下信息，不完整时合理假设并标注： | 信息 | 说明 | | --- | --- | | 业务背景 | 为什么要做，当前痛点是什么 | | 用户角色 | 谁使用，谁受影响，谁配置 | | 目标 | 业务目标、用户目标、效率目标或数据目标 | | 场景 | 触发入口、使用路径、前后置流程 | | 范围 | 本期做什么，不做什么 | | 约束 | 时间、系统、合规、数据、权限、AI 能力限制 | ## Output Structure 默认输出以下结构： 1. 文档信息 2. 需求背景 3. 目标与成功指标 4. 用户角色与使用场景 5. 需求范围 6. 核心流程 7. 功能需求清单 8. 详细功能说明 9. 字段与数据规则 10. 状态流转 11. 权限规则 12. 异常与边界场景 13. AI 能力说明，如适用 14. 埋点与数据指标 15. 非功能需求 16. 验收标准 17. 待确认问题 ## Rules - 用中文输出，少写背景空话，多写规则、流程、字段、状态和验收。 - 功能需求清单必须用表格，包含模块、功能点、用户角色、优先级、说明。 - 详细功能说明应包含入口、操作、系统反馈、限制条件和异常处理。 - B 端产品必须考虑组织、角色、权限、数据隔离、配置项和审计记录。 - AI 功能必须说明输入、输出、置信度/解释、人工复核、失败兜底和误判风险。 - 招聘/HR 场景必须关注候选人、职位、简历、面试、评价、录用、企业账号等核心对象。 - 不确定内容用“假设”标明，不要编造成既定事实。 - 结尾必须给出“待确认问题”和“研发评审关注点”。