# Prd Writing

> 通用 PRD 写作流程，分步骤走：读取/建立产品上下文 → 一页纸骨架确认 → 分档展开正文 → 埋点与成功指标。 触发词：写PRD、起草需求文档、prd-writing、做个策划案、需求评审前梳理、把这个功能写成PRD。 产品上下文按 PRODUCT-CONTEXT.md 协议管理（多产品共用一套 skill）；埋点部分调用 tracking-plan skill。

- Skill: `timi-fish/prd-writing` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add timi-fish/prd-writing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timi-fish/prd-writing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Timi-Fish (https://skillmd.com/u/timi-fish)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timi-fish/prd-writing

---


# PRD Writing Skill

产出一份结构完整、可评审的 PRD。skill 本体不含任何产品特有信息——
产品差异（覆盖端、知识库、输出格式、产品特性）全部来自产品上下文文件，见同目录 `PRODUCT-CONTEXT.md`。

## 阶段 0：产品上下文（先读，缺了才问）

按本 skill 同目录的 `PRODUCT-CONTEXT.md` 协议定位 `product.md`：

1. cwd 下有 `.prd/product.md` → 用它（repo 场景）
2. 否则在 PM 工作区（默认 `~/Documents/PM`，可在首次访谈中改）下按产品名匹配 `<产品名>/product.md`
3. 都没有 → **这是该产品首次使用，做一轮明确询问**（AskUserQuestion，一次问完不反复）：
   - 产品名 + 一句话定位
   - 覆盖哪些端（自由填写，不预设枚举）
   - 有没有产品知识库/资料库？在哪（路径或 URL）？没有就记"无"
   - PRD 默认输出格式：markdown 还是 html
   - 产品关键特性假设（离线优先？实时协作？单机工具？——决定异常场景章节写什么）
   - 产品资料与产出放哪（默认 PM 工作区 `~/Documents/PM`）
   然后把答案写入工作区的 `<产品名>/product.md`，之后所有 PM 类 skill 共享，不再问。

> 如果 requirement-eval 或 tracking-plan 已在这个产品上跑过访谈，product.md 已存在——直接读，
> **只补问缺失字段，绝不重复已回答的问题**。

另外每次询问本单 PRD 的信息：需求名、目标版本、是新增能力还是梳理现有能力、有无交互稿链接。

## 阶段 1：一页纸骨架（先确认再展开——万字 PRD 的解药）

不许直接开写全文。先产出一页纸给用户确认：

- 需求背景一句话 + 核心目标（编号列，末尾「一句话说清楚需求」）
- 章节骨架（列到二级标题）
- **分档建议**，三档字数是硬预算不是参考值：

| 档位 | 适用 | 正文预算 |
|------|------|----------|
| Lite | 单功能小改动、内部梳理 | ≤1500 字，元信息层只留版本记录+涉及面 |
| Standard | 常规新功能 | ≤4000 字 |
| Complex | 跨端大需求 | 分端专章，每章 ≤2500 字 |

用户确认骨架和档位后才进阶段 2。展开时超预算 = 回头砍字，优先砍成段的描述，改表格。

## 阶段 2：正文展开

核心原则：

1. **能表格化就表格化**——涉及面、支持端、菜单项、埋点事件全用表；同一信息不许在两处成段重复。
2. **跨端先勾版本线**——覆盖端矩阵表（端的枚举来自 product.md），✅/⬜ 勾选（避免 🗹/🞎，多数字体渲染成方框）。
3. **危险/异常显式写**——删除类操作单独标样式文案；异常场景单列一节，写什么由 product.md 的产品特性决定（离线优先的写离线/弱网/冲突，在线服务的写超时/降级/限流）。
4. **区分「新增能力」还是「梳理现有能力」**——写进背景，避免开发误判工作量。
5. **有产品知识库就先查**——product.md 里登记了知识库的，写背景/竞品/现状前先去查，别凭空编。

章节顺序（Lite 档可裁剪）：

1. frontmatter（title/author/type: PRD）+ 版本记录表
2. 版本线矩阵表 + 范围说明
3. 涉及面表（模块｜是否涉及｜说明）
4. 协作同学、相关资源、名词解释（Lite 档可省）
5. 需求背景 → 用户场景（编号列：谁+什么情况+做什么）→ 核心目标
6. 功能概述（逻辑原则 + 入口表）→ 需求详情（表格化）
7. 异常场景处理
8. Complex 档：分端专章，每端列任务清单

## 阶段 2.5：配图

纯文字墙不可评审。以下位置**默认配图**，不等用户要求：

- 主流程 → flowchart
- 有状态流转的功能 → stateDiagram
- 多角色/多端交互 → sequenceDiagram

实现方式按输出格式。markdown PRD 的常见导入目标（在线文档类产品）既不渲染 mermaid fence、
也不渲染 `![]()` 图片链接和 `<details>` 标签——唯一在所有环境稳定的是**等宽代码块**，所以：

- **markdown 产出（默认）** → 徒手 ASCII，放 ```text fence，画法规格：
  1. **结构字符只用纯 ASCII**（`| v + - = \ /`）——box-drawing（`─│┌└├▼`）是 East Asian Ambiguous
     宽度，字体不同宽度不同，本身就是塌陷源；纯 ASCII 宽度恒为 1，永不飘
  2. 需垂直对齐的字符尽量放在该行第一个中文之前（结构在左、文本在右）；不画封闭框（不写右边线）
  3. 双列并排流**默认不用**（读者字体 CJK 非严格 2:1 时右列与轨道脱节）；product.md 里记录过
     "导入环境实测双列 OK"的产品可以用——视觉确实更好
  4. 居中对称、条幅、行尾装饰性右列（事件名/数值）允许——坏字体下只偏移不散架
  5. 行宽 ≤ 80 显示列（中文算 2）
  6. **漏斗：四列布局**——事件名（ASCII，定宽左列）｜bar（在定宽字段内居中）｜百分比（右对齐）｜
     中文标签（行尾）。中文只出现在行尾，前三列纯 ASCII，任何字体下都稳；bar 居中给出漏斗对称感：
     - bar 字段总宽 32 格；bar 宽 = 比例 × 32 **取偶数**（左右 padding 才完全相等），最小 4 格
     - bar 字符用 `▇`；读者环境里 %/标签列上下歪了（说明该字体 `▇` 非 1 宽）就换纯 ASCII `#`
     ```
     fav_panel_show   ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇  100%  面板唤起
     fav_add_click           ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇          56%  收藏操作
     fav_tab_show                ▇▇▇▇▇▇▇▇▇▇               31%  收藏Tab曝光
     fav_item_paste                 ▇▇▇▇                  12%  收藏条目粘贴
     ```
     普通占比对比（非漏斗）用左对齐条形图（termgraph 范式，比长短需要公共基线），中文标签同样放行尾
  写完跑本 skill 的校验器：`python3 <本 skill 目录>/scripts/ascii_guard.py check <文件.md>`，
  不过就按报错改、改完重跑，绿了这张图才算存在。
- **product.md 里「PRD 配图方式」明确为 mermaid fence**（读者环境确认渲染 mermaid：Obsidian/GitHub 等）→ 用 ```mermaid fence
- **html 产出** → 调 diagram-design 产 inline SVG（不用 mermaid，观感和可控性都更好）；简单小图可手写 inline SVG

## 阶段 3：埋点与成功指标 —— 调用 tracking-plan skill

只要功能会产生新的用户行为路径，就必须做这一步；纯内部梳理类需求可只写成功指标。
读 tracking-plan skill 的 SKILL.md（它同样读 product.md 拿埋点体系配置），
产出「数据埋点与成功指标」章节附到 PRD 末尾。

## 阶段 4：落盘与自检

产出写到产品文件夹（product.md 所在目录）的 `prd/<需求名>.md|.html`（repo 场景写 cwd 的 `.prd/`）。

- [ ] 骨架和档位经过用户确认了？正文没超预算？
- [ ] 版本线矩阵表勾了？核心目标后有「一句话说清楚需求」？
- [ ] 危险操作、异常场景单独写了？能表格化的都表格化了？
- [ ] 主流程有图？`ascii_guard.py check` 对最终 md 跑过且是绿的？
- [ ] 带了「数据埋点与成功指标」章节（非纯梳理需求）？