# Rule Prd Generator

> 将访谈纪要、业务需求、现有 PRD、用户反馈或零散方案整理成写给业务、产品、设计、研发、测试和管理者评审的标准中文 PRD。触发于‘正常 PRD’‘正式 PRD’‘业务 PRD’‘写给人看的 PRD’或要求补全、改版现有 PRD；不用于直接发给编码 Agent 的实现 Spec 或 Vibe Coding PRD。

- Skill: `yishu5/rule-prd-generator` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add yishu5/rule-prd-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yishu5/rule-prd-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: YiShu5 (https://skillmd.com/u/yishu5)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yishu5/rule-prd-generator

---


# 规则 PRD生成

## 目标

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

## 核心原则

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

## 工作方式

### 1. 整理输入

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

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

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

### 2. 先同步 Gap

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

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

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

### 3. 选择文档粒度

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

### 4. 写功能规则

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

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

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

### 5. 完成交付检查

交付前确认：

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

## 输出要求

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