| 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 的本质是把用户脑中的产品想法转化为开发团队可执行的需求文档。这意味着：
- 所有需求必须来自用户，不替用户做业务假设。 你不知道用户的业务规则——猜出来的需求上线必出错。
- 站在产品经理的位置。 定义"做什么"和"为什么"，不定义"怎么实现"。接口的 URL、数据库表结构、前端组件选型留给开发团队。
- 输出 .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 个，根据回答追问，像对话而不是填表。
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 获取各章节的详细模板。
撰写原则：
-
产品经理边界： 定义"做什么"，不定义"怎么实现"
- ✅ 写：接口名称（业务含义）、调用场景、输入输出（业务字段）、性能要求
- ❌ 不写：URL 路径、HTTP 方法、数据库表名、字段类型、CSS 样式、代码实现
-
判断原则： 写 PRD 时问自己——"这个信息换一个开发团队来做，他们需要知道吗？"
- 如果是"业务上必须这样" → 应该写
- 如果是"技术上可以这样也可以那样" → 不该写
-
不超出 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 文件。
生成前必须执行：
- 读取
docx skill 获取 docx-js 的完整 API 和排版规范
- 读取
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）
- 页眉：右对齐文档标题，底部细线分隔
- 页脚：居中页码
交付物清单：
补全模式
用户已有半成品文档时：
- 导入文档：读取用户提供的文件（.docx / .md / 粘贴的文本）
- 差距分析：对照标准章节结构，标注哪些章节已有、哪些缺失、哪些不够详细
- 定向追问：只针对缺失和不足的部分执行 Phase 1 的三维度追问
- 补写内容：补全后执行 Phase 4 自评审
- 输出 .docx：整合原有内容和新补充内容，统一格式输出
调研模式
只收集领域背景，不写 PRD。适用于产品规划早期。
- 了解用户要调研的领域和方向
- 收集资料（用户提供的文档 + MCP 搜索 + 对话中的信息）
- 输出调研摘要：行业现状、竞品分析、用户痛点、机会点
- 保存到
<当前工作目录>/docs/prd-knowledge/<领域名>/<模块名>.md，后续写 PRD 时直接复用
