rule-prd-generator

规则 PRD生成

目标

把业务材料转成一份跨职能团队能共同评审、据此设计研发、测试验收和运营交接的正式 PRD。文档首先服务人的判断和协作，不把实现提示词冒充产品需求。

核心原则

• 区分信息层级： 明确标注已确认需求、已知事实、产品建议、暂定方案和待决策项。不得把会议中的个人提议、演示效果或产品建议写成已定需求。
• 先收敛再补全： 合并重复表述，区分内容需求、交互建议和技术方案；对冲突项保留决策记录，不用模糊措辞掩盖分歧。
• 不凭空补业务规则： 缺少的信息如果会改变用户、范围、权限、数据来源或主流程，先提出一个最关键的问题；其他内容可用明确标注的假设继续整理。
• 保留产品边界： 区分 Demo、MVP 和生产系统；区分统一入口、统一身份、单点登录、数据同步和系统整合。未经验证，不得宣称外部系统已接通或权限已打通。
• 让需求可验收： 功能规则、权限、状态、异常和验收标准应能观察或测试。避免“体验良好”“操作方便”“尽量快”等无法判定的表述。
• 尊重现有文档： 修改已有 PRD 时先读取当前版本、目录、变更记录和相关章节，做增量修订；除非用户明确要求，不整篇推倒重写。

工作方式

1. 整理输入

先识别材料属于访谈记录、业务提案、现有 PRD、评审反馈还是版本新增需求。提取：

• 目标用户、使用场景和要解决的问题；
• 已确认范围、候选需求、明确不做和后续考虑；
• 业务规则、数据来源、权限、依赖、负责人和时间约束；
• 原始材料中的冲突、缺口和未经证实的结论。

用户要求保留来源时，为合并后的需求记录提出人或原始出处；否则不在正文堆叠聊天记录。

2. 先同步 Gap

起草前给出简短 Gap，优先暴露会影响方案的事项：

• 产品目标或成功标准不明确；
• 用户、角色或可见范围不明确；
• 主流程缺少前置条件或完成结果；
• 外部系统、数据源或接口能力未经确认；
• 负责人、内容维护机制、异常处理或回退方式缺失；
• 指标只有名称，没有口径、目标值或不达标动作。

只有必须由用户决定且不同答案会产生明显不同 PRD 时才暂停询问；一次问一个决定性问题。用户要求先出初稿时，用“暂定/待确认”继续，不擅自定案。

3. 选择文档粒度

• 新建正式 PRD、重构现有文档或跨多个模块时，读取并采用 正式 PRD 结构与检查表。
• 小范围改版时只更新受影响章节、版本记录、验收标准、风险和待确认项，避免为了套模板扩大改动。
• 用户提供参考 PRD 时，复用其信息组织方式和术语，不复制与当前产品无关的内容。

4. 写功能规则

每个核心功能按实际需要说明：

• 目的、使用角色和前置条件；
• 用户入口、主流程和完成结果；
• 展示内容、关键字段和交互规则；
• 数据来源、更新方式和数据归属；
• 可见范围、操作权限及附件/直达链接权限；
• 空状态、加载状态、失败状态和边界情况；
• 可观察的验收标准。

不要强行为简单功能填满所有字段；只保留会影响设计、研发、测试或业务验收的内容。

5. 完成交付检查

交付前确认：

• 目标、范围、角色、流程、页面和详细规则彼此一致；
• P0/P1/P2 或本期/后续/不做边界清楚；
• 敏感内容在列表、搜索、详情、直达链接和附件上使用一致权限；
• 外部依赖区分“已确认可用”和“待技术验证”；
• 指标包含口径、时间窗、目标值、负责人和不达标动作，未确认的目标明确标注为建议值；
• 每个 P0 主流程及关键异常都有验收标准；
• 待确认事项写明当前处理方式和最晚确认节点；
• 版本更新同步进入变更记录，没有残留旧口径。

输出要求

• 默认使用简体中文 Markdown，先给结论和 Gap，再给完整 PRD 或增量修订内容。
• 标题、表格和编号以便于评审与引用为准，不追求章节数量。
• 将业务确认项放在正文，将纯技术实现细节留给技术方案；只有技术约束会影响产品边界时才写入 PRD。
• 如果用户后续要交给编码 Agent，再基于已确认 PRD 单独生成实现任务，不把两类文档混在一起。