prd-writer

name	prd-writer
description	产品需求文档(PRD)撰写工具。引导用户从模糊想法到完整PRD，通过递归追问深挖需求细节，输出专业的.docx格式文档。当用户提到写PRD、需求文档、产品需求、功能设计、需求规格说明书、方案文档时使用。也适用于用户有半成品文档需要补全、或需要整理散乱需求时。即使用户只说'帮我整理一下这个需求'也应触发。

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 时直接复用