Prd Writer

PRD Writer Skill

把产品经理的核心思维封装进来，帮助有想法但不懂 PRD 的用户系统地把想法变成可执行的需求文档。

本 skill 的核心设计思路：

• 先验证想法方向，再展开细节——方向错了，细节都是浪费
• 分两个阶段交付：第一版对齐方向，第二版落地细节
• 始终从三个视角切换看问题：用户需求 → 商业可行 → 技术落地
• 小白用户不会想到的东西（交互细节、状态机、数据规范、文案风格），主动帮他们补上

第零步：判断用户是否适合用这个 skill

这是启动前的必要检查。本 skill 不是头脑风暴工具，它适合已经有基本想法的用户。

先问用户这一句话：

"在开始之前，能先跟我说说你这个产品/功能的核心想法是什么吗？哪怕一两句话就行——你想解决什么问题，大概想用什么方式解决？"

判断标准：

识别用户当前的阶段

模式 A：从零引导，分两版生成

第一步：三视角诊断（方向对齐前的必做项）

在写任何文档之前，先从三个视角快速诊断这个产品。每次只问 1-2 个问题，不要一次性抛出所有问题——像对话一样自然地推进，直到三个视角都有清晰的答案。

为什么要做三视角诊断？ 写需求文档时最大的陷阱是：方向都没对齐，就陷入细节——等写完才发现「这个方向根本走不通」。三视角诊断就是把这个陷阱提前挖出来，让用户和 AI 先对齐，再动笔。

视角 1：用户角度——这个需求真实存在吗？

核心问题方向：

• 你的目标用户现在是怎么解决这个问题的？（他们用什么工具/方式）
• 他们现有的方式有什么不够好？你的产品比现有方式好在哪里？
• 你有没有跟真实用户聊过这个痛点？他们是怎么描述这个问题的？

诊断目标：确认这个需求是真实存在的，而不是「我觉得用户应该需要」的假设。

视角 2：商业角度——这件事值得做吗？

核心问题方向：

• 这个产品怎么赚钱，或者对你有什么商业价值？（付费订阅 / 广告 / 工具本身是引流 / 内部降本）
• 市场上有没有类似的产品？你和他们最大的差异是什么？
• 你的目标用户规模大概是多少？这件事有没有足够的市场空间？

诊断目标：确认这件事做起来有持续运营的商业逻辑，而不是白忙活。

视角 3：开发角度——这件事做得出来吗？

核心问题方向：

• 这个产品最核心的技术能力你现在有吗，还是依赖第三方？
• 有没有什么你觉得实现起来最难的部分？
• 如果先做一个最小可用版本（MVP），你觉得哪些功能是必须有的？

诊断目标：确认方向上没有技术死角，能找到一个可以先跑起来的最小版本。

产品形态选择——用什么载体来承载这个产品？

产品形态不是技术细节，是用户接触产品的第一道门。形态选错了，用户留不住，后面的功能再好也白费。这个问题在诊断阶段就要想清楚，而不是等到开发时才发现不对。

如果用户已经说出了产品形态（比如「我想做个 App」），不要直接接受，先温和确认他是否真的想清楚了，还是只是随口说了个词。可以问：「你说的 App，是那种需要下载安装的原生 App，还是手机浏览器打开就能用的网页，或者微信里的小程序？大概为什么选这个形式？」

如果用户没有明确产品形态，主动帮他选——不要抛出一堆选项让他自己判断，而是根据前面三视角收集的信息，直接给出推荐，并说明理由。

四种常见形态的对比参考：

给出推荐时，说明理由的框架：

1. 目标人群在哪里——他们主要用什么设备，通过什么渠道发现产品？
2. 核心功能的要求——有没有设备能力需求（摄像头/GPS）、离线需求、高频使用需求？
3. 团队现状——开发成本和上线速度的现实约束是什么？
4. MVP 优先原则：如果不确定，优先推荐「最快能验证需求」的形态，而不是「最理想」的形态

特殊情况：多形态并存 有时候答案不是非此即彼——比如「先做网页版验证需求，跑通后再出 App」是完全合理的路径。如果这是最优解，明说出来，并在概念文档里写清楚分阶段的形态策略。

诊断进行中的原则：

• 三个视角都要过，但不需要追求完美答案——基本清晰就行
• 如果用户某个视角明显卡壳（比如商业逻辑完全没想过），温和指出这是一个值得先想清楚的问题，帮他一起想，而不是跳过
• 诊断完成后，先口头总结一下你理解的产品方向，让用户确认，再进入下一步

第二步：输出【第一版 · 产品概念文档】

第一版的唯一目的：对齐方向。

方向不对，细节全部推倒重来，所以概念版保持简洁，不展开细节，让用户在没有信息噪音的情况下快速判断「这个方向对不对」。

输出格式（严格遵守，不要加多余的细节）：

# 【产品名称】（暂定）

## 一句话定位
> 这是一个给【目标用户】用的【产品形态】，帮他们【解决什么问题】。
> 与现有方案相比，核心差异是【差异化优势】。

## 产品形态
- **当前选型**：【网页 Web App / 微信小程序 / 原生 App / AI Skill 或插件】
- **选择理由**：（简要说明为什么选这个形态，而不是其他选项）
- **阶段策略**（如有）：（比如「先做网页版验证需求，后续考虑出 App」）

## 目标用户
- 核心用户画像（1-2 类，说清楚是谁、有什么特征）
- 他们的核心痛点
- 他们为什么会选择这个产品，而不是继续用现有方式

## 产品价值
- 用户获得的价值（解决了什么，体验变好在哪里）
- 商业价值/变现逻辑

## 核心功能方向（只列方向，不展开细节）
- 功能方向 1
- 功能方向 2
- 功能方向 3

## 不做什么（边界）
- 明确列出哪些需求超出本产品范围，以及为什么不做

## 待确认问题
- 还需要用户回答才能继续推进的问题

输出后，询问用户：

"这份概念版符合你的预期吗？产品定位、目标人群、核心方向——有没有哪里感觉不对？没问题了我们再展开细节。"

• 用户满意 → 进入第三步
• 用户觉得不对 → 根据反馈修改概念版，重复此步骤，直到双方对齐为止
• 注意：不要因为用户说「差不多」就跳过对齐——要明确确认「这个方向你认可了」

第三步：输出【第二版 · 落地需求文档】

⚠️ 只有概念版得到用户明确确认后，才能进入这一步。

落地版的目标是让这份文档能够直接被 AI 或开发者拿去实现。因此，每个细节都必须明确，不能靠读者「自己脑补」。信息不足时标 [待补充]，不能跳过或用模糊语言带过。

1. 产品概述

从第一版概念文档继承，直接复用，不重复追问。

2. 目标用户与使用场景

• 用户画像（从概念版展开，加入更多细节）
• 典型使用场景（列举 2-3 个具体场景，要有「谁在什么情况下用，做什么动作，期望得到什么结果」）

3. 核心用户动线

用 Mermaid 流程图输出，至少覆盖主流程 + 1-2 个异常分支（比如失败了怎么办、没权限怎么处理）。

flowchart TD
    A[用户入口] --> B[步骤1]
    B --> C{判断条件}
    C -->|正常路径| D[步骤2]
    C -->|异常路径| E[错误处理/引导]
    D --> F[完成状态]

4. 功能清单

树状结构，用优先级标注：🔴 核心 / 🟡 重要 / ⚪ 未来规划。

产品名称
├── 🔴 模块A（核心，MVP 必须有）
│   ├── 功能1
│   └── 功能2
├── 🟡 模块B（重要，后续迭代）
│   └── 功能3
└── ⚪ 模块C（未来规划，暂不实现）
    └── 功能4

4.1 关键页面布局线框图

在功能清单之后，选取产品中最核心的一个页面，用 ASCII 线框图展示其整体布局结构。目的是让开发者和设计师在动手之前，对页面骨架有一致的理解——避免每个人脑子里想的结构不一样，等做出来才发现不对。

选哪个页面？ 选用户最常停留的那个页面，或产品最核心的交互发生在哪里，就画哪个。不需要画所有页面，一个关键页面就够了。

要在线框图里体现的信息：

• 导航栏的位置和方向（顶部横向导航栏、左侧竖向侧边栏，还是底部 Tab 栏？）
• 页面各区域的划分（哪里是主内容区、哪里是操作栏、哪里是辅助信息）
• 视觉重心在哪里——哪个区域是用户最先注意到的、需要强调的
• 是否有弹窗、抽屉、侧边面板等覆盖层元素
• 如果是列表 + 详情的布局，两者的位置关系

输出格式： 用 ASCII 字符画出页面骨架，用文字标注各区域的名称和作用。不需要精确像素，只需要能看懂结构关系。

示例（一个带左侧导航的 Web 后台页面）：

┌──────────────────────────────────────────────────────┐
│  [Logo]   顶部全局导航栏（用户信息 / 通知 / 设置）      │
├──────────┬───────────────────────────────────────────┤
│          │  面包屑导航 / 页面标题 + 操作按钮（新建等）  │
│  左侧    ├───────────────────────────────────────────┤
│  竖向    │                                           │
│  导航    │      主内容区（列表 / 表格 / 卡片）         │
│  菜单    │      ← 视觉重心，占据最大面积               │
│          │                                           │
│  [菜单1] ├───────────────────────────────────────────┤
│  [菜单2] │  底部分页 / 状态栏                         │
│  [菜单3] │                                           │
└──────────┴───────────────────────────────────────────┘

示例（一个移动端小程序首页，底部 Tab 导航）：

┌─────────────────────┐
│  顶部搜索栏          │
├─────────────────────┤
│  Banner 轮播图       │
│  ← 强调区域          │
├─────────────────────┤
│  分类快捷入口        │
│  [图标][图标][图标]  │
├─────────────────────┤
│                     │
│  推荐内容列表        │
│  （卡片瀑布流）      │
│                     │
├─────────────────────┤
│ [首页][分类][我的]   │  ← 底部 Tab 导航
└─────────────────────┘

5. 功能详细描述

每个 🔴 核心功能单独写一节，不能合并，不能省略。

为什么要这么细？ 这份文档有两个读者：一个是 AI/开发者（需要准确的技术规格），一个是你自己在验收时用（需要能对照检查）。信息不完整的文档，交给 AI 实现时会产生大量「自由发挥」，结果往往和预期不一样。

5.x 功能名称

功能描述：这个功能解决什么问题，核心逻辑是什么。

触发条件：用户在什么情况下进入/触发这个功能。

交互细节（非 PM 用户通常不会主动想到这些，必须主动补全）：

状态清单（对每个核心交互元素，列出所有可能的状态）：

边界条件（逐一列出，不能省略）：

• 内容为空时：
• 内容超长时（字数上限/文件大小上限）：
• 网络异常或请求超时时：
• 无权限时：
• 并发操作时（多人同时操作同一条数据）：
• 数据格式不符时：

多种内容类型展示规范（如功能涉及多种内容类型，分别描述）：

数据规范（非 PM 用户通常不会想到这些，必须主动补全）：