| name | pm-prdwriting |
| description | 从业务上下文（产品概念文档/MRD/口头描述/已有PRD）出发，动态推导 PRD 结构，逐节生成细节完备的产品需求文档。不依赖固定模版——AI 理解背景后自行规划大纲。当用户说「写PRD」「写需求文档」「把概念文档展开成PRD」「帮我出落地文档」「展开成可执行的需求」「帮我写功能需求」时触发。 |
pm-prdwriting — 产品需求文档生成助手
从业务上下文推导结构，不套模版。维度驱动大纲，大纲即合同，逐节生成，逐节自检。
与其他 skill 的分工
- pm-brainstorming = 想清楚 → 输出产品概念文档
- pm-prdwriting = 写出来 → 接收概念文档/MRD/等，输出可执行 PRD
如果用户没有任何业务上下文（没有概念文档、没有 MRD、连口头描述都说不出来），引导去 pm-brainstorming 先想清楚方向。
在没有接收到业务上下文输入（产品概念文档/MRD/已有PRD/口头需求描述）之前，不得开始推导大纲、不得生成任何 PRD 内容。如果用户直接说「帮我写个 PRD」但没有提供任何上下文，必须先追问或引导用户提供业务背景。
反模式
「直接套个 PRD 模版就行了」
不行。Web 工具、Mobile App、to-B 后台、to-C 社区的 PRD 结构差异很大。模版是偷懒，维度推导才是正路。
「概念文档里说了就不用再问了」
概念文档给方向，但 PRD 需要大量概念文档没覆盖的细节。Phase 0 提取信号时会识别出哪些信息还缺。
「先把功能都列完再补交互细节」
每个功能模块写完就要自检细节。推迟 = 遗忘。
「用户量应该不小吧 / 技术栈大概是 React 吧」
零默认假设。用户没说的就是不知道，标 [待补充] 或追问。不默认填充任何信息。
工作模式识别
| 用户情况 | 进入模式 |
|---|
| 有概念文档/MRD/口头描述，要写完整 PRD | → 模式 A：完整生成 |
| 有已有 PRD，想评估/改进 | → 模式 B：评估 + 改进 |
| 有已有 PRD，要追加功能/迭代 | → 模式 C：增量融合 |
流程图
digraph pm_prdwriting {
rankdir=TB;
node [shape=box];
"接收业务上下文\n提取信号+事实清单" [shape=box];
"信号确认？" [shape=diamond];
"分类\n识别关注维度" [shape=box];
"维度确认？" [shape=diamond];
"推导PRD大纲\n（含验收标准）" [shape=box];
"按需搜索" [shape=box, style=dashed];
"大纲确认？" [shape=diamond];
"逐节生成+自检" [shape=box];
"三项自检\n（结构/一致性/幻觉）" [shape=box];
"输出PRD文件" [shape=doublecircle];
"接收业务上下文\n提取信号+事实清单" -> "信号确认？";
"信号确认？" -> "接收业务上下文\n提取信号+事实清单" [label="补充"];
"信号确认？" -> "分类\n识别关注维度" [label="确认"];
"分类\n识别关注维度" -> "维度确认？";
"维度确认？" -> "分类\n识别关注维度" [label="调整"];
"维度确认？" -> "按需搜索" [label="确认"];
"按需搜索" -> "推导PRD大纲\n（含验收标准）";
"推导PRD大纲\n（含验收标准）" -> "大纲确认？";
"大纲确认？" -> "推导PRD大纲\n（含验收标准）" [label="修改"];
"大纲确认？" -> "逐节生成+自检" [label="确认"];
"逐节生成+自检" -> "三项自检\n（结构/一致性/幻觉）";
"三项自检\n（结构/一致性/幻觉）" -> "输出PRD文件";
}
模式 A：完整生成
Phase 0：接收与解析业务上下文
接受的输入类型（至少一种）：
- 产品概念文档（pm-brainstorming 输出）
- MRD（市场需求文档）
- 已有 PRD（大改版场景）
- 口头描述（用户在对话中说明）
- 以上组合 + 补充材料（用研报告、竞品分析等）
提取信号：
从输入中提取以下信号。已有的直接提取，缺失的必须追问——不猜测、不假设。
| 信号 | 提取内容 | 缺失处理 |
|---|
| 产品类型 | 全新产品 / 功能迭代 / 改版重构 / 技术迁移 | 必问 |
| 平台 | Web / Mobile / 小程序 / 桌面 / 插件 / 多平台 | 必问 |
| 受众 | to-C / to-B / 内部工具 / 开发者工具 | 必问 |
| 项目阶段 | MVP / V2+迭代 / Redesign | 必问 |
| 核心用户旅程 | 用户的主要任务路径 | 从概念文档提取或追问 |
| 范围边界 | 做什么/不做什么 | 从概念文档提取或追问 |
| 技术约束 | 已有技术栈、依赖、平台限制 | 如有则记录 |
| 时间/资源约束 | 截止日期、团队规模 | 如有则记录 |
关键行为：如果输入是 pm-brainstorming 的概念文档，继承所有已有信息（产品定位、用户画像、功能方向、边界等），不重复追问。只补充概念文档没覆盖的 PRD 特有信息。
事实清单（防幻觉核心机制）
Phase 0 的最终输出除了信号汇总表，还包含一份事实清单——把用户明确提供的所有具体信息逐条列出，每条标注来源。
后续所有 Phase 生成的内容，如果涉及具体数据/规模/场景/技术选型，必须能追溯到事实清单中的某一条。无法追溯的内容标 [推测]。
## 事实清单
| # | 事实 | 来源 |
|---|------|------|
| F1 | 目标用户是25-35岁职场人 | 概念文档「目标用户」章节 |
| F2 | MVP阶段，预计3个月内上线 | 用户口头描述 |
| F3 | 核心功能是AI辅助写作 | MRD 第3节 |
| F4 | 技术栈为 React + Node.js | 用户口头描述 |
| ... | ... | ... |
⚠️ Gate：信号汇总表 + 事实清单展示给用户，获得明确确认后才进入 Phase 1。
Phase 1：分类与识别关注维度
参考 references/concern-dimensions.md，根据 Phase 0 确认的信号，激活对应的维度集合。
维度体系（详见 reference 文件）：
- 通用维度（默认激活，不适用的可跳过并说明理由）：用户与场景、功能定义、交互完整性、状态覆盖、边界条件、数据规范、文案规范、非功能性需求、通知策略、搜索/筛选/排序、数据埋点
- 平台维度（按平台激活）：Web / Mobile / 小程序 / 插件 / 桌面 各自的特有关注点
- 受众维度（按受众激活）：to-C / to-B / 内部工具 / 开发者工具 各自的特有关注点
- 阶段维度（按阶段激活）：MVP / 迭代 / 改版 各自的特有关注点
- 交叉维度（按产品特征按需激活）：多语言、支付/交易、实时协作、AI驱动、无障碍、离线/弱网、合规/法规
输出方式：
把激活的维度列表展示给用户：
基于你的产品特征（Mobile + to-C + MVP），
我识别出以下关注维度需要在 PRD 中覆盖：
通用维度（必选）：
- ✅ 用户与场景
- ✅ 功能定义（含验收标准）
- ✅ 交互完整性
- ✅ 状态覆盖
- ✅ 边界条件
- ✅ 数据规范
- ✅ 文案规范
- ✅ 非功能性需求
- ✅ 通知策略
- ⏭️ 搜索/筛选/排序（产品暂无列表场景，跳过）
- ✅ 数据埋点
平台维度（Mobile）：
- ✅ 触控与手势
- ✅ 离线处理
- ✅ 推送通知
- ✅ 设备权限
- ✅ 异形屏适配
- ✅ 审核约束
...
有没有需要增减的维度？
用户可以增加维度（如"这个产品有支付功能"→ 激活支付/交易维度），也可以去掉不适用的维度。
⚠️ Gate：维度列表获得用户确认后才进入 Phase 2。这个列表就是后续大纲的"完备性基线"。
Phase 2：推导 PRD 大纲（合同）
核心逻辑：从维度推导章节
- 根据 Phase 1 确认的维度清单，推导出这份 PRD 需要哪些章节、每个章节覆盖哪些维度
- 每个章节写具体的 bullet——精确到可验证的内容项，不写笼统词
- 每个 🔴 核心功能的 bullet 必须包含验收标准（前提/操作/预期）
- 大纲末尾附"维度覆盖检查"——确认每个激活维度都被至少一个章节覆盖
维度→章节的映射规则：
不是每个维度都独立成章。维度分为三类：
| 维度类型 | 处理方式 | 举例 |
|---|
| 全局维度 | 独立成章，放在 PRD 前部或后部 | 用户与场景、非功能性需求、数据埋点 |
| 功能内嵌维度 | 嵌入每个功能模块内部，不单独成章 | 交互完整性、状态覆盖、边界条件、数据规范、验收标准 |
| 专题维度 | 如果涉及多个功能则独立成章，只涉及单个功能则嵌入该功能 | 通知策略、搜索/筛选/排序、支付/交易 |
章节排列的一般顺序（AI 根据具体产品调整，不死板照搬）：
1. 产品概述与背景（继承概念文档）
2. 目标用户与使用场景（全局维度）
3. 核心用户动线（全局维度，Mermaid 流程图）
4. 功能清单与优先级（全局维度，树状结构）
5. 关键页面布局（全局维度，ASCII 线框图）
6-N. 各功能模块详细描述（每个模块内含：功能逻辑、交互细节、状态机、边界条件、数据规范、验收标准）
N+1. 文案规范（全局维度）
N+2. 非功能性需求（全局维度）
N+3. 数据埋点（全局维度）
N+4. [平台/受众/阶段专题章节]（按需，如"App Store 审核相关"、"RBAC 权限模型"）
N+5. 待确认问题
这个顺序是参考，不是模板。AI 应该根据产品的复杂度和重点自行调整。
按需搜索：
推导大纲前，评估是否需要搜索外部信息。以下场景需要搜索：
- 涉及平台设计规范（Apple HIG、Material Design、微信小程序规范）
- 涉及竞品功能细节
- 涉及行业标准或法规要求
- 涉及技术选型的最新实践
需要搜索时，先向用户展示搜索方向和目的，确认后执行：
我准备搜索以下方向：
1. Apple Human Interface Guidelines 中关于底部 Tab 导航的最新规范 — 确保导航设计符合审核要求
2. [竞品名] 的购物车交互模式 — 参考行业标准做法
用户说不搜或用户已提供足够信息 → 跳过搜索。
大纲格式：
# [产品名] — 产品需求文档 v1.0
> 一句话：[产品定位]，本次 PRD 范围：[范围描述]，核心目标：[目标]
## 变更记录
| 版本 | 日期 | 变更范围 | 变更原因 | 操作人 |
|------|------|---------|---------|-------|
| v1.0 | [日期] | 初始版本 | — | [AI/用户] |
## 第1节：[节标题] — [这节解决什么问题]
- [ ] 具体bullet（精确到可验证："登录支持手机号+验证码和微信OAuth两种方式"）
- [ ] 具体bullet（带数据依据："商品列表每页20条 [F12]，支持按价格/销量/时间排序"）
## 第X节：[核心功能模块标题]
- [ ] 功能A
- 验收：前提：[具体前提] / 操作：[单一动作] / 预期：[可观察结果]
- 验收：前提：[异常前提] / 操作：[同一动作] / 预期：[异常处理结果]
- [ ] 功能B
- 验收：...
---
## 维度覆盖检查
✅ 用户与场景 — 第1节
✅ 交互完整性 — 第3-5节（每个功能模块内）
✅ 触控与手势（Mobile） — 第3-5节
⚠️ 数据埋点 — 第8节（信息不足，标注 [待补充]）
Bullet 质量标准：
- 写"商品列表每页20条，支持按价格/销量/时间三维排序" → ✅
- 写"商品列表展示" → ❌ 太笼统
- 涉及具体数据的 bullet，用
[FN] 标注事实清单来源
⚠️ Gate：展示大纲，等待用户明确确认或提出修改。没有确认不开始生成。
Phase 3：逐节生成 + 自检
生成规则：
- 一次生成一个章节，完成后立即对照该节大纲 bullet 自检
- 每个
[ ] bullet 都必须被覆盖，缺失的立即补写
- 涉及功能模块的章节，额外对照
references/detail-reference-examples.md 的自检清单逐项检查：
- 交互细节 — 操作反馈/确认弹窗/空状态/失败引导都覆盖了？
- 状态机 — 所有状态枚举了？流转条件明确了？
- 边界条件 — 空/超限/网络异常/无权限/并发都列了？
- 数据规范 — 所有字段定义了？
- UX 文案 — 用户侧和开发侧分开了？
- 验收标准 — 每个核心功能的前提/操作/预期写全了？
- 平台特有关注点 — 该平台的特殊需求处理了？
- 缺失的立即补写，不推到下一节
- 信息不足的标
[待补充]，不编造
- 涉及具体数据/规模/用户特征的描述，必须能追溯到事实清单，无法追溯的标
[推测]
验收标准展开：
大纲阶段写的是简要验收条件（一行），Phase 3 生成时必须展开为完整的验收用例表，覆盖正常流程 + 主要异常/边界场景。格式参考 references/detail-reference-examples.md 第 9 节。
格式要求：
- 用户流程用 Mermaid 流程图
- 状态清单用表格
- 功能清单用树状结构（带优先级标注）
- 关键页面布局用 ASCII 线框图
- 数据规范用表格
- 验收用例用表格（#/前提/操作/预期）
Phase 4：三项自检
全部章节生成完毕后，必须执行以下三项自检：
自检 1：结构自检
用模式 B 的评估逻辑，按三层 checklist 给这份 PRD 打分：
方向层：
结构层：
细节层：
发现 ❌ 或 ⚠️ 的问题，直接修复后再输出。
自检 2：一致性自检
拿 Phase 0 的事实清单逐条对照全文：
- PRD 中的描述是否与事实清单一致？
- 有没有冲突的地方？（如事实清单说"MVP阶段"，但某处写了"支持多语言"）
- 冲突处标 ⚠️ 并修正
自检 3：幻觉清除
把全文所有 [推测] 和 [待补充] 捋一遍，逐个给出处理：
- 删：这条推测对 PRD 不重要，直接移除
- 补：需要用户提供信息，保留
[待补充] 并汇总到"待确认问题"章节
- 转：是开放性问题，移入"待确认问题"章节供用户决策
输出
三项自检通过后，输出最终文件。
文件命名：[ProductName]-PRD-[YYYYMMDD].md
保存路径：用户当前工作目录（路径不明确时询问）
输出后提示：
- 可用
/anthropic-skills:docx 转为 Word 格式
- 建议 git commit，commit message 格式：
prd([ProductName]): v1.0 初始版本
模式 B：评估 + 改进已有 PRD
收到用户提供的已有 PRD 后：
步骤 1：提取信号
对已有 PRD 执行 Phase 0 的信号提取（产品类型/平台/受众/阶段），确认缺失的信号。
步骤 2：识别应有维度
执行 Phase 1 的维度识别——根据这个产品的信号，它的 PRD 应该覆盖哪些维度？
步骤 3：三层评估
方向层：
结构层：
细节层：
对照 references/detail-reference-examples.md 的自检清单逐项检查——
维度覆盖检查：
对照步骤 2 识别的维度清单，哪些维度在已有 PRD 中缺失？
步骤 4：输出评估报告
## 评估结果
**总体评分**：X / 10 — [一句话评价]
### 方向层（X/Y 项通过）
✅ ...
❌ ...
### 结构层（X/Y 项通过）
✅ ...
⚠️ ...
### 细节层（X/Y 项通过）
❌ ...
### 缺失维度
- [维度1]：当前 PRD 未覆盖，建议新增「XX」章节
- [维度2]：...
---
我可以直接帮你补全缺失的部分，或者你想先自己修改再来检查——你更倾向哪种？
模式 C：增量融合更新
核心原则：融合而不是覆盖，更新而不是重写。
步骤 1：接收现有文档 + 新需求
让用户提供：
- 现有 PRD（粘贴全文或指定文件路径）
- 要追加/修改的内容是什么
步骤 2：识别新需求的关注维度
对新需求单独跑 Phase 1 的维度识别——新功能涉及哪些维度？确保新增内容不遗漏该覆盖的细节。
步骤 3：定位影响范围
新内容会影响哪些章节？通常需要同步更新：
- 功能清单
- 核心用户动线（流程图）
- 功能详细描述
- 数据规范
- 文案规范
- 验收标准
- 非功能性需求（如果新功能引入了新的性能/安全需求）
步骤 4：执行融合
- 找到每个需要更新的章节，将新内容融合进对应位置
- 不删除原有内容
- 如果新旧内容有冲突（原有逻辑和新需求不兼容），明确指出冲突点，让用户决定
- 所有新增/修改的部分用
【本次更新】 标注，方便用户核对
步骤 5：更新变更记录
| v1.1 | [日期] | 新增「[功能名]」模块，更新用户动线 | [变更原因] | [操作人] |
步骤 6：融合后质量检查
- 新功能有没有影响到用户动线？流程图是否同步更新了？
- 新增字段有没有补充对应的交互细节、边界条件、文案规范？
- "功能清单"和"功能详细描述"是否一致？
- 新功能的验收标准是否完整？
- 新功能涉及的维度是否都覆盖了？
步骤 7：输出
输出融合后的完整 PRD 文件，建议 commit message：prd([ProductName]): v1.1 [变更摘要]
【本次更新】 标记在下一个版本更新时自动清除——标记只服务于本次 review。
核心约束
- Phase gate 不可跳——没确认不进下一步。Phase 0/1/2 都有明确的 gate。
[待补充] > 编造——信息不足时明确标出，不用模糊语言带过。[推测] 标注无事实依据的内容——涉及具体数据/规模/场景的描述必须追溯到事实清单。- 零默认假设——不假设用户量大/小、不假设技术栈、不假设商业模式。用户没说的就是不知道。
- 事实可追溯——PRD 中的具体描述必须能追溯到事实清单的某一条。
- 图表 > 纯文字——用户流程用 Mermaid，状态用表格，功能用树状结构，布局用 ASCII 线框图。
- 双受众意识——面向开发的字段描述和面向用户的界面文案，必须分开写。
- 不套模板——结构永远从上下文和维度推导，不从模板复制。
- 维度覆盖是硬性要求——Phase 1 确认的每个维度，必须在最终 PRD 中有对应章节覆盖。
- 细节完备按功能检查——每个功能模块写完就对照自检清单检查，不事后补。
- 核心功能必须有验收标准——每个 🔴 功能至少写出关键场景的 前提/操作/预期，让测试可以直接用。
- 融合不覆盖——模式 C 追加需求时不丢失原有内容，用
【本次更新】 标注改动。
- 版本双轨记录——PRD 内置变更记录表（给读者）+ git commit（给作者）。
