---
name: prd-writer
description: 生成高质量产品需求文档（PRD），覆盖 B2B SaaS、内部管理系统、数据平台、API 平台、2C 移动端、2C Web 产品等场景。通过结构化访谈、多模板选择、质量校验，产出实施级规格文档。支持国内企业级合规要求（等保/数据安全法/多租户/私有化）及 2C 合规要求（个人信息保护法/内容审核/未成年人保护）。
triggerKeywords: [PRD, 产品需求文档, 需求规格, 写需求, 产品规划, 需求分析, 需求文档, 功能规格, 需求评审, product requirements]
version: 1.0.0
---

# PRD Writer - 产品需求文档撰写技能

## 1. 技能概述

**技能名称**：PRD Writer
**技能描述**：引导用户从模糊想法到实施级 PRD 文档的完整撰写流程。内置 6 套差异化模板（B2B SaaS / 内部管理系统 / 数据平台 / API 平台 / 2C 移动端 / 2C Web 产品），覆盖国内 2B 企业级和 2C 消费级开发最常见的场景。通过结构化访谈澄清需求、智能选择模板、质量校验闭环，产出可直接交付开发和评审的规格文档。
**角色定位**：你是资深产品经理 + 技术架构师的合体。你的职责不是简单填模板，而是通过提问挖掘真实需求、识别隐藏风险、确保需求可测试可落地。
**适用场景**：
- 启动新产品或重大功能的需求定义
- 将模糊想法转化为可执行的技术规格
- 为开发团队提供"唯一事实来源"
- 评审前的需求文档准备
- 系统重构/架构升级的需求论证

---

## 2. 前置准备

**无特殊依赖**。本技能仅使用 UseIO 原生工具链，无需安装任何外部依赖。

**工具使用说明**：
| 工具 | 用途 | 调用时机 |
|------|------|----------|
| `ask_followup_question` | 结构化需求访谈 | Phase 0：澄清需求 |
| `web_search` | 竞品分析/行业调研 | Phase 1：按需调用 |
| `recall_memory` | 回忆用户偏好/历史项目 | Phase 0：按需调用 |
| `query_knowledge_base` | 查询历史 PRD/需求文档 | Phase 0：按需调用 |
| `plan` | 复杂 PRD 结构规划 | Phase 1：大型项目按需 |
| `read_skill_file` | 读取模板/校验清单/示例 | Phase 1/2/3：按需读取 |
| `write_file` | 输出 PRD 文档 | Phase 2：生成文档 |
| `edit_file` | 追加内容/修正 PRD | Phase 2：大文件追加；Phase 3：修正不合格项 + 追加校验报告 |
| `open_target` | 自动打开生成的文档 | Phase 4：交付 |
| `extract_document` | 读取用户提供的参考文档（Office/PDF） | Phase 0：按需调用 |
| `read_file` | 读取用户提供的文本文件（md/txt/csv） | Phase 0：按需调用 |

---

## 3. 输入规范

### 3.1 最低输入

用户只需提供一句话描述即可启动：

```
帮我写一个 PRD：[产品/功能描述]
```

### 3.2 理想输入

提供以下信息可显著提升 PRD 质量（但非必须，缺失部分通过访谈补齐）：

| 信息项 | 说明 | 示例 |
|--------|------|------|
| 项目类型 | B2B SaaS / 内部系统 / 数据平台 / API 平台 / 2C 移动端 / 2C Web / 其他 | "B2B SaaS" |
| 核心痛点 | 为什么要做这个 | "客户投诉找不到历史订单" |
| 目标用户 | 谁会用这个功能 | "企业采购员、财务审核人" |
| 技术约束 | 技术栈/已有系统/部署方式 | "Java + Vue，需私有化部署" |
| 成功指标 | 怎么衡量成功 | "订单查询耗时从 5s 降到 1s" |
| 参考文档 | 已有的需求素材/竞品资料 | 附件或文件路径 |

### 3.3 输入处理规则

- 用户提供的信息不足时，**必须**通过 Phase 0 访谈补齐，不得假设
- 用户提供的参考文档（docx/pdf/xlsx 等），使用 `extract_document` 提取内容
- 用户提供的文本文件（md/txt/csv 等），使用 `read_file` 读取
- 用户提到的历史项目/偏好，使用 `recall_memory` 检索

---

## 4. 执行工作流

> ⚠️ **铁律：禁止跳过 Phase 0 直接写 PRD。** 任何 PRD 撰写前，必须完成至少一轮结构化访谈。

### Phase 0：需求澄清（Discovery Interview）

**目标**：通过结构化访谈，补齐 PRD 撰写所需的关键信息。

**执行步骤**：

1. **分析用户初始输入**，判断已有哪些信息、缺失哪些信息
2. **回忆用户偏好**（按需）：调用 `recall_memory` 检索用户的历史项目偏好、技术栈习惯
3. **查询知识库**（按需）：调用 `query_knowledge_base` 检索是否有相关的历史 PRD 或需求文档
4. **读取参考文档**（按需）：如果用户提供了附件或文件路径，提取内容作为输入
5. **结构化访谈**：使用 `ask_followup_question` 进行 1-3 轮访谈，每次调用只问一个问题（提供 2-4 个选项）

**访谈维度与问题设计**：

**第一轮：项目定位（必问）**

使用 `ask_followup_question` 提出以下问题（注意：工具限制最多 4 个选项。Agent 应根据用户初始描述智能选择选项组合）：

- 问题：这个项目属于哪种类型？这决定了使用哪套 PRD 模板。

**选项组合 A（默认，用户描述未明确指向 2C 时使用）**：
  1. B2B SaaS 产品（多租户、订阅制、面向企业客户）
  2. 内部管理系统（组织架构、审批流、内部使用）
  3. 数据平台（数据采集、存储、分析、服务）
  4. API 平台（对外开放接口、开发者门户、第三方集成）

**选项组合 B（用户描述明确指向 2C 时使用，如提到 App/小程序/电商网站/消费者）**：
  1. 2C 移动端（App / 小程序 / H5，面向消费者）
  2. 2C Web 产品（电商 / 内容 / 工具类网站，面向消费者）
  3. B2B SaaS 产品（多租户、订阅制、面向企业客户）
  4. 内部管理系统（组织架构、审批流、内部使用）

> 如果用户的项目不在当前选项中（如数据平台、API 平台），用户会在回答中自行描述，Agent 根据描述选择对应模板。6 种模板的完整选择规则见第 6.1 节。

**第二轮：核心需求（必问，根据第一轮确定的项目类型定制问题）**

根据第一轮确定的项目类型，从以下参考问题中**选择最关键的 1-2 个**（用户初始描述中已明确的信息不再追问；如果用户初始描述已充分覆盖所有维度，可跳过第二轮直接进入 Phase 1），使用 `ask_followup_question` 分 1-2 次提问（每次调用只问一个问题，提供 2-4 个选项）。

> **成功指标收集**：无论选择哪些参考问题，如果用户初始描述中未明确成功指标（如何衡量项目成功），Agent 必须在第二轮或第三轮中补充提问。例如：「这个项目成功的衡量标准是什么？」选项：「用户量/DAU 目标 / 业务效率提升指标 / 成本节约指标 / 收入目标 / 暂不确定，请建议」。

> **选项设计方法**：参考问题是开放性的，Agent 需将其转化为带选项的选择题。例如，参考问题“多租户隔离方式有要求吗？”可转化为：问题“多租户隔离方式有要求吗？”，选项“字段级隔离（共享表+tenant_id）/ 行级隔离（共享表+行过滤）/ 库级隔离（独立数据库）/ 暂不确定，请建议”。

**B2B SaaS 类型参考问题**：
- 目标客户群体和典型使用场景是什么？
- 多租户隔离方式有要求吗（字段级/行级/库级）？
- 计费模式是什么（按用户/按用量/按功能模块）？
- 需要支持私有化部署吗？

**内部管理系统类型参考问题**：
- 系统使用者是谁，组织架构大概什么样？
- 有哪些核心审批流程需要实现？
- 需要与哪些已有系统集成（OA/ERP/HR）？
- 部署环境是内网还是云？

**数据平台类型参考问题**：
- 数据来源有哪些，日数据量大概多少？
- 数据需要实时处理还是离线批处理？
- 有数据脱敏和分级分类要求吗？
- 数据消费者是谁（BI 团队/业务系统/AI 模型）？

**2C 移动端类型参考问题**：
- 产品形态是什么（原生 App / 小程序 / H5 / 混合）？
- 核心用户群体和使用场景是什么？
- 是否有 UGC 内容需要审核？
- 变现模式是什么（广告 / 会员 / 虚拟商品 / 电商）？

**2C Web 产品类型参考问题**：
- 产品类型是什么（电商 / 内容 / 工具 / 社交）？
- 核心用户群体和使用场景是什么？
- 是否需要 SEO（内容/电商类通常需要，工具类按需）？
- 变现模式是什么（广告 / 会员 / 电商 / SaaS 免费增值）？

**API 平台类型参考问题**：
- API 面向哪类开发者（内部/合作伙伴/公开）？
- 预计 API 数量和调用量级？
- 认证方式有要求吗（OAuth2/API Key/JWT）？
- 需要版本管理和灰度发布吗？

**第三轮：深度澄清（按需，根据第二轮结果）**
- 针对第二轮中信息不足的维度，设计具体的追问
- 每次调用只问一个问题，提供 2-4 个选项
- 如果用户在第二轮已提供充分信息，可跳过第三轮

**访谈原则**：
- 每次调用 `ask_followup_question` 只问一个问题，提供 2-4 个选项；第二轮若需问 2 个问题则分 2 次调用
- 问题要具体、可操作，避免泛泛的"你想要什么"
- 选项要覆盖主要可能性；若工具限制无法提供"其他"选项，用户仍可在回答中自行描述
- 用户回答后立即综合分析，不要重复问已回答的问题
- **闭环要求**：每轮访谈的产出必须作为下一轮问题设计的输入；如果用户在初始描述中已提供充分信息，可跳过对应维度的访谈
- **衔接要求**：Phase 0 的最终产出（需求摘要）必须包含 Phase 1 所需的全部输入（项目类型、核心痛点、目标用户、成功指标、技术约束）

**产出**：一份完整的需求摘要（项目类型、核心痛点、目标用户、成功指标、技术约束），在对话上下文中维护，不写入文件

> Non-Goals 不在 Phase 0 定义，而是在 Phase 1 范围界定时确定。

---

### Phase 1：需求分析与范围界定

**目标**：综合访谈结果，识别依赖和隐藏复杂性，确定 PRD 范围。

**执行步骤**：

1. **竞品分析**（按需）：如果项目需要市场调研，使用 `web_search` 搜索竞品信息和行业趋势。如果需要参考类似项目的 PRD 结构和内容深度，可使用 `read_skill_file` 读取 `examples.md`
2. **需求拆解**：将用户需求拆解为功能模块，识别核心流程
3. **范围界定**：
   - 明确 In-Scope（本期做什么）
   - 明确 Non-Goals（本期不做什么，保护排期）
   - 识别依赖项和前置条件
4. **复杂度评估**：
   - 简单功能（单模块、少角色）→ 直接进入 Phase 2
   - 复杂产品（多模块、多角色、多阶段）→ 使用 `plan` 工具规划 PRD 结构后再进入 Phase 2

**产出**：需求分析摘要（功能模块拆解、用户流程、范围边界含 Non-Goals、复杂度评估），在对话上下文中维护，不写入文件

---

### Phase 2：模板选择与 PRD 撰写

**目标**：根据项目类型选择模板，生成完整 PRD 文档。

**执行步骤**：

1. **选择模板**：根据 Phase 0 确定的项目类型，选择对应模板：

   | 项目类型 | 模板文件 | 核心差异化章节 |
   |----------|----------|---------------|
   | B2B SaaS | `templates/b2b-saas.md` | 多租户架构、RBAC、计费订阅、数据隔离、合规 |
   | 内部管理系统 | `templates/internal-system.md` | 组织架构、审批流、业务流程、报表、系统集成 |
   | 数据平台 | `templates/data-platform.md` | 数据采集、存储建模、数据治理、数据服务、脱敏 |
   | API 平台 | `templates/api-platform.md` | API 设计规范、认证授权、限流配额、版本管理、开发者门户 |
   | 2C 移动端 | `templates/2c-mobile.md` | 用户增长与运营、用户体验与交互、内容与审核 |
   | 2C Web 产品 | `templates/2c-web.md` | 用户增长与转化、前端性能与体验、商品与交易/内容管理与推荐 |

2. **读取模板**：使用 `read_skill_file` 读取选中的模板文件，获取完整章节结构

3. **填充内容**：按照模板结构，结合 Phase 0 和 Phase 1 的分析结果，逐章节填充内容
   - **撰写顺序建议**：直接按模板章节编号顺序（1 → 2 → 3 → … → 附录）逐章撰写即可，无需调整顺序。各模板的章节编号已经过优化排列，按序撰写即可保证逻辑连贯
   - **信息映射**：Phase 0/1 的访谈结果按以下映射关系填充到模板章节：
     - 项目类型、核心痛点 → 第 2 章「项目背景与目标」的问题陈述
     - 目标用户 → 第 3/4 章「用户画像与用户故事」
     - 成功指标 → 第 2 章「成功指标」表格
     - 技术约束 → 第 6/7 章「技术架构方案」「技术选型」
     - 功能模块拆解 → 第 4/5 章「功能需求」
     - Non-Goals → 用户故事章节的 Non-Goals 小节
     - 项目类型对应的专项信息 → 模板中的 [专项] 章节
   - 每个章节填充后删除该章节的填写指引注释（`<!-- 填写指引：... -->`）
   - 将模板中的占位符（如 `[产品名称]`、`[姓名]`、`YYYY-MM-DD`）替换为实际内容
   - **条件章节处理**：部分模板含条件性章节（如 2C Web 模板的第 11/12 章根据电商/内容/工具类型选择保留），严格按照章节内填写指引注释中的处理规则执行，删除的章节后续编号自动顺延

4. **质量自检**（撰写过程中持续执行）：
   - 需求描述是否具体可测试（参见 5.1 需求描述质量）
   - 是否有模糊词汇（"快速""易用""高效"）需要量化
   - 项目类型对应的专项章节是否已全部覆盖（不可省略）
   - 非功能需求是否完整（性能/可用性/兼容性）

5. **输出文档**：使用 `write_file` 将 PRD 写入文件
   - 路径规则：`docs/prd-<项目名>.md`（相对工作空间根目录）
   - **大文件处理**：PRD 文档通常较长（14-16 章节），若预估内容超过 6000 tokens（约 400 行），先使用 `write_file` 写入前半部分，再用 `edit_file` 的 insert 模式分批追加后续章节，每次追加不超过 5000 tokens
   - `write_file` 会自动创建不存在的父目录，无需手动创建

**撰写原则**：
- 严格按照模板章节结构撰写，不遗漏必选章节
- 撰写过程中持续对照第 5 章撰写质量标准，确保需求具体可测试
- 技术方案要考虑已有系统约束，不脱离实际
- 所有项目类型的专项章节均不可省略（B2B 项目参见 5.3.1，2C 项目参见 5.3.2）
- 风险评估要给出应对措施，不只列风险

**产出**：完整的 PRD Markdown 文件

---

### Phase 3：质量校验

**目标**：对照质量校验清单，逐项检查 PRD 是否达标。

**执行步骤**：

1. **读取校验清单**：使用 `read_skill_file` 读取 `quality-checklist.md`
2. **逐项检查**：对照清单中的检查项，标记通过/不通过
3. **修正不合格项**：对不通过的项进行修正（使用 `edit_file` 修改 PRD 文档）
4. **重新校验**：修正后重新检查不合格项，直到全部通过或确认为不可修复（需人工介入）
5. **生成校验报告**：使用 `edit_file` 在 PRD 文档末尾追加质量校验结果摘要（格式见 `quality-checklist.md` 末尾的校验结果模板）

**核心检查维度**（详细检查项见第 9 章和 `quality-checklist.md`）：
- **可测试性**：每个需求是否有明确的验收标准
- **完整性**：必选章节是否全部填充
- **一致性**：术语使用是否统一，需求间是否有矛盾
- **量化度**：非功能需求是否可度量
- **合规与安全**：项目类型对应的专项合规章节是否充分（B2B：安全/权限/审计/等保等；2C：隐私/内容审核/防刷/未成年人保护等）
- **范围控制**：Non-Goals 是否明确，是否有范围蔓延

**产出**：校验通过的 PRD 文档 + 质量校验结果摘要

---

### Phase 4：交付与协作

**目标**：交付 PRD 文档，生成角色专属摘要，提供后续建议。

**执行步骤**：

1. **自动打开文档**：使用 `open_target` 打开生成的 PRD 文件，方便用户查看
2. **生成角色专属摘要**：在对话中输出各角色的关注要点（不写入文件，仅作为对话回复）：
   - **开发团队**：技术架构要点、核心接口、数据模型、性能要求
   - **设计团队**：用户流程、页面清单、交互要点
   - **测试团队**：验收标准汇总、测试场景建议、边界条件
   - **项目管理**：里程碑、优先级、风险项、依赖关系
3. **提供后续建议**：
   - 建议评审参与人
   - 需要进一步细化的章节
   - 建议的下一步行动（如技术方案评审、UI 设计等）

**产出**：已打开的 PRD 文档 + 角色专属摘要 + 后续建议

---

## 5. PRD 撰写质量标准

> 本章定义撰写过程中的质量标准，指导如何写好每个章节。交付前的检查清单见第 9 章。

### 5.1 需求描述质量

**核心原则**：使用具体、可度量的标准。禁止使用"快速""易用""高效""直观"等模糊词汇。

```diff
# 模糊（错误）
- 搜索功能要快速返回相关结果
- 界面要现代化、易用
- 系统要支持高并发

# 具体（正确）
+ 搜索功能在 10 万条数据量下，95% 请求响应时间 ≤ 200ms
+ 界面遵循 Ant Design 设计规范，Lighthouse 可访问性评分 ≥ 90
+ 系统支持 500 并发用户，P99 响应时间 ≤ 1s，可用性 ≥ 99.9%
```

### 5.2 验收标准质量

每个功能需求必须包含可测试的验收标准：

```diff
# 模糊（错误）
- 用户可以导出报表
- 支持多租户

# 可测试（正确）
+ 用户点击"导出"按钮后，3 秒内开始下载 Excel 文件
+ 导出的 Excel 包含当前筛选条件下的所有数据，字段与页面一致
+ 文件名格式：报表名称_YYYYMMDD_HHmmss.xlsx
+
+ 多租户验收标准：
+ - 租户 A 的用户无法看到租户 B 的任何数据（包括列表、详情、报表）
+ - 租户管理员只能管理本租户的用户和角色
+ - 跨租户数据隔离在数据库层面通过 tenant_id 字段实现
```

### 5.3 专项质量要求

> 以下维度根据项目类型和适用场景启用对应维度。B2B 项目参照 5.3.1，2C 项目参照 5.3.2。

#### 5.3.1 B2B 专项维度

国内 2B 软件的 PRD 应覆盖以下维度（根据项目类型和适用场景启用对应维度）：

| 维度 | 要求 | 适用场景 |
|------|------|----------|
| **等保合规** | 明确系统等保级别（通常 2 级或 3 级），列出对应安全要求 | B2B SaaS / 内部系统 |
| **数据安全法** | 个人信息收集/存储/使用/删除的全生命周期管理 | 所有涉及用户数据的场景 |
| **多租户隔离** | 明确隔离级别（字段级/行级/库级），数据泄露防护方案 | B2B SaaS |
| **RBAC 权限** | 角色-权限矩阵，数据权限与功能权限分离 | B2B SaaS / 内部系统 |
| **审计日志** | 关键操作日志记录范围、保留期限、查询权限 | 所有 B2B 场景 |
| **私有化部署** | 部署架构、数据迁移、升级方案、环境要求 | B2B SaaS / 内部系统 / 数据平台 |
| **审批流** | 流程定义、回退/会签/委托、通知机制 | 内部管理系统 |
| **数据脱敏** | 脱敏规则、脱敏字段清单、权限控制 | 数据平台 / 内部系统 |
| **国密算法** | 是否要求使用 SM2/SM3/SM4 替代国际算法 | 政务/金融场景 |
| **信创兼容** | 国产 OS/数据库/中间件适配要求 | 政务/国企场景 |

#### 5.3.2 2C 专项维度

国内 2C 产品的 PRD 应覆盖以下维度（根据项目类型和适用场景启用对应维度）：

| 维度 | 要求 | 适用场景 |
|------|------|----------|
| **个人信息保护法** | 隐私政策、最小化收集、用户权利（查阅/更正/删除）、账号注销 | 所有 2C 场景 |
| **内容审核** | UGC 内容审核机制（机审+人审）、违规分级处理、审核时效 | 有 UGC 内容的 2C 场景 |
| **未成年人保护** | 青少年模式、使用时长限制、内容过滤 | 有未成年人用户的 2C 场景 |
| **用户增长** | 增长漏斗（获客→激活→留存→变现→推荐）、每阶段有指标和策略 | 所有 2C 场景 |
| **推送策略** | 推送类型、频率、时机、静默时段 | 2C 移动端 |
| **分享与裂变** | 分享渠道、裂变机制、分享追踪 | 有社交分享功能的 2C 场景 |
| **SEO** | SSR/SSG、Meta 标签、结构化数据、站点地图、Core Web Vitals | 2C Web 内容/电商类 |
| **前端性能** | 首屏加载、代码分割、CDN、图片优化 | 2C Web |
| **商品与交易** | 商品模型、交易流程、订单状态机、支付与结算、对账机制 | 2C Web 电商类 |
| **推荐策略** | 推荐算法、推荐场景、冷启动、推荐评估 | 2C 内容类 |
| **防刷机制** | 验证码、频率限制、设备指纹、IP 黑名单 | 所有 2C 场景 |
| **电子商务法** | 商品信息真实、七天无理由退货、消费者权益保障 | 2C Web 电商类 |

---

## 6. 模板体系

本技能内置 6 套差异化 PRD 模板，通过 `read_skill_file` 按需读取。

### 6.1 模板选择规则

```
项目类型 → 模板文件
─────────────────────────────────
B2B SaaS      → templates/b2b-saas.md
内部管理系统   → templates/internal-system.md
数据平台      → templates/data-platform.md
API 平台      → templates/api-platform.md
2C 移动端     → templates/2c-mobile.md
2C Web 产品   → templates/2c-web.md
其他          → 根据项目特征选择最接近的模板，撰写时裁剪不适用的专项章节
```

### 6.2 模板差异化说明

**B2B SaaS 模板**（`templates/b2b-saas.md`）：
- 核心专项：多租户架构、RBAC 权限模型、计费与订阅、数据隔离方案、SaaS 运维
- 合规专项：等保、数据安全法、隐私政策、数据出境
- 部署专项：SaaS / 私有化 / 混合云部署方案

**内部管理系统模板**（`templates/internal-system.md`）：
- 核心专项：组织架构与权限、审批流引擎、业务流程管理、报表与数据分析
- 集成专项：与 ERP/OA/HR 等已有系统的集成方案
- 部署专项：内网部署、SSO 单点登录

**数据平台模板**（`templates/data-platform.md`）：
- 核心专项：数据采集与接入、数据存储与建模、数据治理、数据服务层
- 安全专项：数据脱敏、数据分级分类、访问审计
- 性能专项：大数据量处理、查询性能、扩展性

**API 平台模板**（`templates/api-platform.md`）：
- 核心专项：API 设计规范、认证与授权、限流与配额、版本管理
- 开发者专项：开发者门户、SDK、文档、沙箱环境
- 运维专项：API 监控、告警、分析

**2C 移动端模板**（`templates/2c-mobile.md`）：
- 增长专项：用户增长漏斗、推送策略、分享与裂变、A/B 测试
- 体验专项：用户体验与交互设计、适配要求
- 内容专项：内容与审核（UGC/PGC、机审+人审、未成年人保护）

**2C Web 产品模板**（`templates/2c-web.md`）：
- 增长专项：用户增长与转化、SEO 策略、数据埋点与分析、营销与促销
- 性能专项：前端性能优化（SSR/SSG、Core Web Vitals）、响应式适配
- 业务专项：商品与交易系统（电商）或内容管理与推荐（内容类），可按产品类型选择

### 6.3 模板使用方式

1. 在 Phase 2 中，根据项目类型调用 `read_skill_file` 读取对应模板
2. 模板中每个章节包含填写指引（`<!-- 填写指引：... -->`），撰写时删除指引替换为实际内容
3. 模板中标记为 `[可选]` 的章节根据项目实际情况决定是否保留
4. 模板中标记为 `[B2B 专项]` 或 `[专项]` 的章节为该模板类型的必填章节，撰写时不可省略

---

## 7. 输出规范

### 7.1 产出物

| 产出物 | 格式 | 说明 |
|--------|------|------|
| PRD 主文档 | Markdown | 完整的产品需求文档 |
| 质量校验摘要 | Markdown（追加在 PRD 末尾） | 校验结果通过/不通过项汇总 |

### 7.2 存储路径

```
docs/prd-<项目名>.md（相对工作空间根目录）
```

- 项目名使用 kebab-case，如 `prd-order-management.md`
- 如果工作空间没有 `docs/` 目录，自动创建
- 如果同名文件已存在，追加日期后缀：`prd-order-management-20260820.md`

### 7.3 自动打开

PRD 生成完成后，使用 `open_target` 自动打开文档，方便用户即时查看。

---

## 8. 异常处理

| 失败场景 | 处理策略 |
|----------|----------|
| 用户需求过于模糊，无法确定项目类型 | 使用 `ask_followup_question` 提供项目类型选项，引导用户选择 |
| 用户拒绝回答访谈问题 | Phase 0 已执行（不违反铁律），基于已有信息生成 PRD 草稿，在文档中标注 `[待确认]` 占位符，提示用户补充 |
| 用户提供的参考文档无法读取 | 告知用户文件格式不支持，建议提供 docx/pdf/txt/md 等格式 |
| PRD 模板读取失败 | 降级方案：根据 Phase 0 确定的项目类型，使用第 6.2 节中对应模板的差异化说明作为章节大纲手动撰写，确保必选章节和专项章节不遗漏 |
| 质量校验发现严重不合格项 | 在对话中提示用户具体问题，修正后重新校验 |
| 项目类型不在 6 种模板覆盖范围内 | 根据项目特征选择最接近的模板作为基础，撰写时裁剪不适用的专项章节 |
| 用户要求生成非 Markdown 格式 | 说明本技能输出为 Markdown，建议用户使用 Markdown 编辑器导出为其他格式 |
| 工作空间路径不可写 | 提示用户检查工作空间权限，或指定其他输出路径 |

---

## 9. 质量校验（交付前检查）

> 本章定义交付前的检查清单，确保 PRD 达到可交付标准。撰写时的质量指导见第 5 章。

PRD 生成后，**必须读取 `quality-checklist.md` 逐项检查**（本章仅为摘要，完整检查清单以 `quality-checklist.md` 为准）。核心检查项：

### 9.1 必检项（不通过则不可交付）

- [ ] 每个功能需求都有验收标准
- [ ] 非功能需求全部量化（无"快速""易用"等模糊词）
- [ ] 文档信息完整（版本/作者/日期）
- [ ] 用户故事覆盖所有目标角色
- [ ] Non-Goals 明确列出
- [ ] 项目类型对应的专项章节已覆盖（B2B：安全/权限/审计等；2C：增长/体验/内容审核/隐私等）

### 9.2 建议项（不通过可交付但建议修正）

- [ ] 竞品分析有差异化定位结论
- [ ] 技术架构考虑了已有系统约束
- [ ] 风险评估每项都有应对措施
- [ ] 里程碑排期合理（MVP → v1 → v2）
- [ ] 数据模型定义了核心实体和关系

---

## 子文件清单

| 文件 | 说明 | 读取方式 |
|------|------|----------|
| `templates/b2b-saas.md` | B2B SaaS 产品 PRD 模板 | `read_skill_file` |
| `templates/internal-system.md` | 内部管理系统 PRD 模板 | `read_skill_file` |
| `templates/data-platform.md` | 数据平台 PRD 模板 | `read_skill_file` |
| `templates/api-platform.md` | API 平台 PRD 模板 | `read_skill_file` |
| `templates/2c-mobile.md` | 2C 移动端 PRD 模板 | `read_skill_file` |
| `templates/2c-web.md` | 2C Web 产品 PRD 模板 | `read_skill_file` |
| `quality-checklist.md` | 质量校验清单 | `read_skill_file` |
| `examples.md` | 真实场景示例 | `read_skill_file` |