用途：把一个模糊的产品想法或一句话提示词，转化为工程、设计、QA 和产品负责人可直接执行的 PRD。标准不是“草稿够用”，而是交付团队能据此从零到一完成构建。
主要能力：先理解产品想法，再进行结构化澄清，暴露缺失的业务决策，只问高价值问题，对用户不清楚或不关心的部分做显式假设，尽量消除歧义，最后输出含可测试需求的完整 PRD。即使只有一句话想法，也会主动推进流程。
使用方式：按工作流执行。第一步解读提示词，推断产品类型、主要用户、业务目标、工作流和风险，并用一段话复述概念供确认。第二步做分轮澄清：仅问影响范围、流程、权限、合规或交付风险的问题，按类别分组，首轮建议 6-12 个高信噪比问题；用户说“用最佳实践”或只给部分回答时继续用假设推进，仅在关键歧义仍存时才追加轮次。
必覆盖的发现类别包括：产品目标、用户与角色、核心流程、数据与记录、业务规则、权限与访问、通知与自动化、报表与分析、集成、平台与体验、合规与安全、交付边界。提问须用业务语言，不要求用户设计数据库表、接口或技术内部结构；若存在两三个合理选项，简要列出并推荐一个。
假设策略：用户不知道、不回答或让 AI 决定时，做出合理的生产级假设并标注“Assumption: ...”，优先行业标准，偏向可审计性、安全性、运营清晰度和可维护性。仅当真正需要外部干系人决策且无法合理默认时，才保留开放问题。
完成标准：角色已定义、核心流程完整、需求具体可实现、验收标准可测试、失败场景已覆盖、权限清晰、报表日志与审计明确、非功能需求具体、范围边界显式、剩余问题极少且不阻塞。
PRD 命名规则为 prd-{feature-or-product-name}，例如 prd-employee-office-crm。必需结构按序为：概述、范围（含范围内、范围外、假设）、用户角色与权限（多角色时给权限矩阵）、用户旅程、详细用户故事（含 ID、角色、As a/I want/So that、优先级、前置条件、验收标准、校验规则、边界情况）、功能需求（FR 编号，原子化，含描述、校验、权限与错误处理）、数据模型与状态设计、集成与外部接口、边界情况与失败处理、非功能需求（NFR 编号，含性能、可扩展、安全、可靠、可访问、审计、可观测、隐私）、分析与审计日志、上线与迁移、测试与验收计划、开放问题（尽量写“No blocking open questions.”）。
限制与注意：输出为清晰 Markdown，详细但可读，面向工程与 QA 可执行，显式声明假设，避免空泛 PM 话术。不要跳过澄清，除非提示词已高度详细；不要产出浅层 PRD；不要假设仅前端范围，须包含后端、数据、安全和运维；运营敏感领域应偏向更强权限、审计日志和审批控制。资料未说明收费、价格、具体平台或安装命令。