用途：将调研发现、干系人信号、竞争背景与产品想法整理成完整且无歧义的产品需求文档（PRD），内容需精确到工程可据此开发、清晰到客户可据此验证。
输入：可接受任意组合，包括干系人情报简报、竞争研究报告、创意生成输出、纯语言的问题陈述或功能请求、待扩充或完善的既有 PRD 草稿、粗略的用户故事或验收标准、工程或设计约束。若只有原始输入而无结构化简报，会先做轻量综合。
写前综合：提取核心问题、目标用户（角色、场景、行为）、成功条件、范围边界（明确不做什么）、关键约束（时间线、技术、合规）。若核心问题含糊，应请求澄清后再继续。
PRD 结构共 12 节：文档头（状态、版本、作者、日期、目标发布、干系人、相关文档）；执行摘要（3–5 句，供 CEO 60 秒内做 go/no-go）；问题陈述（客户问题、业务问题、现状与期望状态）；目标与非目标；用户画像与待办任务（JTBD）；用户故事与验收标准（MoSCoW 优先级、Given/When/Then、边界情况）；功能需求（编号、可测试、无歧义、可追溯）；非功能需求（性能、扩展性、安全、无障碍、可用性、数据保留及测量方式）；依赖与风险（含缓解计划）；成功指标（30/60/90 天，含反指标）；待解决问题；附录（竞争背景、研究数据、设计探索、技术验证、被否决方案及理由）。
质量规则：每个目标必须可衡量；每个非目标必须明确；验收标准必须可测试；每个风险必须有缓解计划；不写实现细节而写行为；不填充凑数；被否决方案部分为必填。
适用场景：产品经理撰写或完善 PRD、将零散调研与想法整理为可交付文档。
限制：仅提供 PRD 撰写框架与方法，不提供自动生成工具、收费信息、价格或平台细节；官方资料未提供具体安装命令与代码示例。