Prd Writer

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

1. 技能概述

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

• 启动新产品或重大功能的需求定义
• 将模糊想法转化为可执行的技术规格
• 为开发团队提供"唯一事实来源"
• 评审前的需求文档准备
• 系统重构/架构升级的需求论证

2. 前置准备

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

工具使用说明：

3. 输入规范

3.1 最低输入

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

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

3.2 理想输入

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

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 文档 + 质量校验结果摘要