prd-writer

# PRD 撰写指南 ## 依赖 Skills 本 skill 需要配合以下 skill 使用： - **docx** — Word 文档生成能力（生成 .docx 文件必需） - **docx-chinese-fix** — 中文文档生成防护规则（中文 PRD 必需，防止中文引号导致 JS 语法错误） 如果这两个 skill 未安装，Phase 5 输出 .docx 时可能失败或出现编码问题。 ## 核心理念 PRD 的本质是把用户脑中的产品想法转化为开发团队可执行的需求文档。这意味着： 1. **所有需求必须来自用户，不替用户做业务假设。** 你不知道用户的业务规则——猜出来的需求上线必出错。 2. **站在产品经理的位置。** 定义"做什么"和"为什么"，不定义"怎么实现"。接口的 URL、数据库表结构、前端组件选型留给开发团队。 3. **输出 .docx 文件。** 最终交付物是专业排版的 Word 文档，不是 Markdown。 ## 模式判断 | 用户意图 | 模式 | |---------|------| | "我要写一个新的 PRD" / 从零开始描述产品想法 | **新建模式** | | "帮我补全/整理这个需求文档" / 已有半成品 | **补全模式** | | "帮我收集一下这个领域的背景资料" / 先调研 | **调研模式** | 判断不了就问："你是要从零写 PRD、补全已有文档、还是先做领域调研？" --- ## 新建模式 ### Phase 0: 领域背景收集 写 PRD 前先确保理解业务领域。纯工具类产品（计算器、文件转换）可跳过。 **0.1** 问用户一句话描述要做什么产品/功能，判断涉及哪个业务领域。 **0.2** 检查是否已有该领域的知识： - 查看 `<当前工作目录>/docs/prd-knowledge/` 下是否有对应领域文件 - 用户是否提供了竞品文档、行业报告、现有系统文档？ - 是否有 MCP 工具可以搜索相关知识库？ - 当前对话中是否已包含业务上下文？ 如果已有领域知识文件，读取后直接进入 Phase 1。 **0.3** 如果背景不足，向用户要： - 相关的竞品截图或文档 - 现有系统的业务流程说明 - 目标用户群体的描述 从提供的资料中提取：业务对象和概念、专业术语、关联模块、用户角色。记录到当前项目的 `docs/prd-knowledge/<领域名>/<模块名>.md`，后续追问时参考。 **知识存储结构：** ``` docs/prd-knowledge/ ├── 财务一体化/ # 领域目录 │ ├── _index.md # 领域总览（模块清单、通用术语、模块间关联） │ ├── 财务报表.md # 模块知识 │ └── 总账管理.md ├── 供应链/ │ ├── _index.md │ └── 采购管理.md └── ... ``` - 按领域分目录，领域下按模块分文件 - 每个领域有 `_index.md` 记录模块清单、通用术语和模块间关联 - 目录不存在时自动创建 - 知识跟着项目走，换项目时是干净的 **不提取具体业务规则**——规则在 Phase 1 中通过追问获取。 --- ### Phase 1: 需求深挖 目标：把模糊的产品想法拆解到每个功能点都有明确的用户故事、数据来源和异常处理。 **1.1 启动问题（必问）：** 1. **这个产品/功能要解决什么问题？** 用户痛点是什么？不解决会怎样？ 2. **目标用户是谁？** 有几类角色？各自的核心诉求？ 3. **给一个最典型的使用场景** —— 从用户打开到完成任务，端到端走一遍 4. **成功长什么样？** 上线后怎么衡量这个功能成功了？（引导用户想指标） 5. **明确不做什么？** 哪些看起来相关但这次不做的？（越早划清边界越好，避免做着做着范围膨胀） 注意：不要一次性把所有问题倒给用户。先问最重要的 1-2 个，根据回答追问，像对话而不是填表。 **1.2 递归追问 —— 三维度结构化：** 对每个功能点/流程步骤，必须明确回答以下三个问题后才算完成： | 维度 | 追问 | 完成标准 | |------|------|----------| | **数据来源** | 这个信息从哪来？ | 已明确为：用户输入 / 系统查询 / 第三方接口 / 固定配置 | | **业务规则** | 怎么判断/怎么计算/怎么流转？ | 已明确为：固定规则（列出规则）/ 用户选择 / 系统自动（说明依据） | | **异常处理** | 数据缺失/冲突/超限怎么办？ | 已明确为：默认值 / 报错提示 / 降级方案 / 人工介入 | **追问方式：** - 每轮列出当前已识别的功能点，标注哪些维度已明确 ✅、哪些待追问 ❓ - 只问待追问的，已明确的不重复 - 用户说"AI 自行判断"的，在 PRD 中标注"系统根据上下文自动判断"，不编造具体规则 **1.3 识别子模块：** 如果某个功能点足够独立且复杂（如审批流程、权限体系），标记为子模块，同样执行三维度追问。 **1.4 终止检查：** 结束 Phase 1 前输出完整的功能点检查表： ``` ## 需求完整性检查 | # | 功能点 | 数据来源 | 业务规则 | 异常处理 | |---|--------|---------|---------|---------| | 1 | 用户注册 | ✅ | ✅ | ✅ | | 2 | 订单创建 | ✅ | ❓待确认计价规则 | ✅ | | 3 | 支付流程 | ✅ | ✅ | ❓待确认超时处理 | ``` 所有功能点三个维度都 ✅ 后，才进入 Phase 2。 --- ### Phase 2: PRD 结构设计 根据深挖结果，确定 PRD 的章节结构。给用户看目录大纲，确认后再写正文。 **标准章节（通用）：** | 章节 | 内容 | 必须 | |------|------|------| | 一、文档信息 | 版本号、作者、日期、审批人、变更记录 | ✅ | | 二、产品概述 | 背景、目标（Goals）、**非目标（Non-Goals）**、定位、目标用户 | ✅ | | 三、用户角色与权限 | 角色定义、权限矩阵 | ✅ | | 四、功能需求 | 用户故事、需求优先级（P0/P1/P2）、**验收标准（Given/When/Then）**、业务规则 | ✅ | | 五、业务流程 | 核心流程图（文字描述）、状态流转 | ✅ | | 六、数据需求 | 核心数据对象、字段定义（业务含义）、数据来源 | ✅ | | 七、接口需求 | 接口名称（业务含义）、调用方向、输入输出（业务字段）、调用场景 | 视情况 | | 八、非功能需求 | 性能、安全、兼容性、可用性 | ✅ | | 九、效果度量 | **领先指标**（上线后快速验证）+ **滞后指标**（长期观察）、具体目标值 | ✅ | | 十、风险与约束 | 已知风险、技术约束、依赖项、**范围管理**（防止需求蔓延的规则） | ✅ | | 十一、**待决事项** | 未解决的问题，标注**责任人**（产品/设计/开发/法务/数据） | ✅ | | 附录 | 术语表、竞品参考、原型链接 | 建议 | **新增章节说明：** - **Non-Goals（非目标）** 和 Goals 同等重要——明确不做什么，防止做着做着范围膨胀。每个非目标要说明为什么不做。 - **验收标准用 Given/When/Then 格式**——比"预期结果"更精确，开发和测试直接可用。 - **效果度量分领先/滞后指标**——领先指标（采纳率、任务完成率）上线后几天就能看，滞后指标（留存、满意度）需要几周。两者都要设具体目标值。 - **待决事项带责任人**——不是笼统的"待确认"，而是"谁来确认、什么时候需要答案"。 **根据产品类型调整：** - **AI/智能体产品**：增加"模型能力边界"、"效果评估指标"章节 - **To B 企业应用**：增加"审批流程"、"组织架构适配"章节 - **数据产品**：增加"数据源说明"、"指标定义"、"看板设计"章节 - **移动端产品**：增加"离线策略"、"推送策略"章节 **小需求简化规则：** 如果功能点 ≤3 个且不涉及多角色/多系统交互，以下章节可省略： - 三、用户角色与权限（只有一种角色时） - 六、数据需求（无新数据对象时） - 七、接口需求（无外部接口时） - 十一、待决事项（无遗留问题时） 省略前问用户确认："这个需求比较小，我建议省略 XX 章节，你觉得呢？" **必须等用户确认目录结构后再写正文。** --- ### Phase 3: 撰写 PRD 按确认的目录结构逐章撰写。撰写时读取 `references/chapter-templates.md` 获取各章节的详细模板。 **撰写原则：** 1. **产品经理边界：** 定义"做什么"，不定义"怎么实现" - ✅ 写：接口名称（业务含义）、调用场景、输入输出（业务字段）、性能要求 - ❌ 不写：URL 路径、HTTP 方法、数据库表名、字段类型、CSS 样式、代码实现 2. **判断原则：** 写 PRD 时问自己——"这个信息换一个开发团队来做，他们需要知道吗？" - 如果是"业务上必须这样" → 应该写 - 如果是"技术上可以这样也可以那样" → 不该写 3. **不超出 Phase 1 收集范围：** Phase 1 没问到的需求，不在 Phase 3 自行补充。发现遗漏时回到 Phase 1 追问。 **撰写完成后执行自评审（见 Phase 4）。** --- ### Phase 4: 自评审 以资深产品经理角度评审初稿，输出评审报告： | 维度 | 检查要点 | |------|----------| | **需求完整性** | 所有功能点是否都有用户故事？异常场景是否覆盖？ | | **逻辑一致性** | 流程是否自洽？数据流转是否闭环？权限是否匹配？ | | **可落地性** | 开发团队能否直接基于此文档排期？是否有歧义？ | | **用户体验** | 操作流程是否顺畅？异常提示是否友好？ | | **验收可测** | 每个功能是否有明确的验收标准？ | | **边界清晰** | 功能范围是否明确？不做什么是否说清？ | 评审发现的问题分级： - **P0 必须修复**：逻辑缺陷、需求遗漏 - **P1 建议补充**：体验优化、边界说明 - **P2 后续迭代**：锦上添花的内容 将 P0 问题修复后，将评审报告和问题清单呈现给用户确认。 --- ### Phase 5: 输出 .docx 用户确认内容无误后，使用 docx-js（Node.js `docx` 库）生成 .docx 文件。 **生成前必须执行：** 1. 读取 `docx` skill 获取 docx-js 的完整 API 和排版规范 2. 读取 `docx-chinese-fix` skill 获取中文字符串处理规则（核心：所有中文字符串必须用反引号 `` ` `` 而非双引号 `"`） **排版要求：** - 封面页：标题居中，深蓝主色调，包含版本号和日期 - 目录：使用 `TableOfContents`，用户在 Word 中右键可更新 - 字体：正文 Arial/微软雅黑 12pt，标题层级用颜色区分（H1 深蓝 / H2 蓝 / H3 灰） - 行距：1.5 倍（段后间距 120） - 页边距：上下 2.54cm（1440 DXA），左右 3.17cm（1800 DXA） - 表格：三线表风格（上下粗线 `size:6` + 表头下细线 `size:2`，无左右竖线，表头灰底 `D9D9D9`） - 页眉：右对齐文档标题，底部细线分隔 - 页脚：居中页码 **交付物清单：** - [ ] PRD 文档（.docx） - [ ] 评审报告（在对话中呈现，不单独出文件） - [ ] 需求追溯表（功能点 ↔ 用户故事 ↔ 验收标准，包含在 PRD 内） --- ## 补全模式 用户已有半成品文档时： 1. **导入文档**：读取用户提供的文件（.docx / .md / 粘贴的文本） 2. **差距分析**：对照标准章节结构，标注哪些章节已有、哪些缺失、哪些不够详细 3. **定向追问**：只针对缺失和不足的部分执行 Phase 1 的三维度追问 4. **补写内容**：补全后执行 Phase 4 自评审 5. **输出 .docx**：整合原有内容和新补充内容，统一格式输出 --- ## 调研模式 只收集领域背景，不写 PRD。适用于产品规划早期。 1. 了解用户要调研的领域和方向 2. 收集资料（用户提供的文档 + MCP 搜索 + 对话中的信息） 3. 输出调研摘要：行业现状、竞品分析、用户痛点、机会点 4. 保存到 `<当前工作目录>/docs/prd-knowledge/<领域名>/<模块名>.md`，后续写 PRD 时直接复用