11-document-writing

name	11-document-writing
description	撰写产品文档（PRD/MRD/技术文档）。当用户说"写PRD"、"产品文档"、"需求文档"、"技术方案"时使用。

Document Writing

何时使用

• 需要撰写 PRD、MRD 或其他产品文档
• 需要写技术方案或架构文档
• 需要优化文档结构和表达
• 需要建立文档规范或模板

工作流程

Step 1: 确认文档类型与读者

不同文档有不同重点：

• PRD（产品需求文档）→ 研发/测试读
• MRD（市场需求文档）→ 管理层/业务方读
• 技术方案 → 架构师/开发读
• 明确读者最关心什么

Step 2: 组织文档结构

使用金字塔原理组织内容：

• 结论先行：第一段说清楚"做什么、为什么"
• MECE 原则：分类不重不漏
• 用表格和图代替大段文字

Step 3: 撰写内容

用落地模板生成文档框架，注意：

• 背景≤3句话，假设对方知道基本背景
• 功能描述要有验收标准
• 边界条件和异常情况不要遗漏
• 非功能需求（性能/安全/兼容）要明确

Step 4: 评审与迭代

文档完成后的检查清单：

• 新人能否看懂？
• 边界条件是否完整？
• 有没有描述不清可能引发歧义的地方？
• 版本号和变更记录是否更新？

关键原则

原则	说明
一页纸原则	任何人看第一页就知道要做什么、为什么做
读者优先	工程师需要边界条件，设计师需要场景，老板需要价值
写清"不做什么"	明确排除的范围比写清要做的更重要
可验收	每个需求都有明确的验收标准
活文档	PRD 不是一次性产物，是随项目演进的活文档

落地模板

# PRD：[功能名称]
> 版本：v1.0 | 作者：[PM姓名] | 日期：[YYYY-MM-DD]
> 状态：草稿/评审中/已确认/开发中/已上线

---

## 一、概述（1分钟读完）

### 一句话描述
[用用户能听懂的话说清楚这个功能是什么]

### 为什么做
- 用户问题：[用户遇到了什么问题——数据/反馈来源]
- 业务目标：[对业务的价值——影响什么指标]
- 战略意义：[在产品路线图中的位置]

### 成功指标
| 指标 | 当前值 | 目标值 | 衡量方式 |
|------|--------|--------|---------|
| [核心指标] | | | [怎么看数据] |
| [护栏指标] | | | [防止优化A导致B下降] |

### 不做什么（明确排除）
- ❌ [明确列出不在本次范围的内容]
- ❌ [...]

---

## 二、用户故事

### 核心场景
> **用户画像**：[谁]
> **场景**：[在什么情况下]
> **需求**：[想做什么]
> **现状**：[现在怎么做的]
> **痛点**：[现在的方案哪里不行]

### 用户流程
[用文字或流程图描述用户的操作路径]

1. 用户打开 [页面]
2. 看到 [...]
3. 点击 [...]
4. 系统 [...]
5. 用户看到 [结果]

---

## 三、功能规格

### 3.1 [功能模块A]
**描述：** [这个模块做什么]

**规则：**
| 条件 | 行为 | 展示 |
|------|------|------|
| 当[条件1] | 系统[做什么] | 展示[什么] |
| 当[条件2] | | |

**边界情况：**
- 如果[异常情况1] → [怎么处理]
- 如果[异常情况2] → [怎么处理]
- 数据为空时 → [展示什么]
- 网络中断时 → [怎么处理]

**验收标准：**
- [ ] [具体的、可测试的标准1]
- [ ] [具体的、可测试的标准2]

### 3.2 [功能模块B]
（同上结构）

---

## 四、交互设计

### 页面/组件清单
| 页面 | 入口 | 核心操作 | 设计稿链接 |
|------|------|---------|-----------|
| | | | [Figma链接] |

### 关键交互说明
[对设计稿中不明显的交互进行补充说明]

### 文案规范
| 场景 | 文案 | 说明 |
|------|------|------|
| 成功提示 | "..." | |
| 失败提示 | "..." | |
| 空状态 | "..." | |
| 确认弹窗 | "..." | |

---

## 五、技术要点（PM视角）

### 数据需求
| 字段 | 类型 | 来源 | 说明 |
|------|------|------|------|
| | | [API/前端/第三方] | |

### 埋点需求
| 事件名 | 触发时机 | 参数 | 说明 |
|--------|---------|------|------|
| | [用户做了什么时上报] | | |

### 权限/灰度
- 上线策略：[全量/灰度X%/白名单]
- 灰度条件：[按用户群/地区/版本]
- 回退方案：[如果出问题怎么关掉]

---

## 六、排期与里程碑

| 里程碑 | 日期 | 负责人 | 交付物 |
|--------|------|--------|--------|
| 需求评审 | | PM | 本文档 |
| 设计评审 | | 设计师 | 设计稿 |
| 技术评审 | | 工程师 | 技术方案 |
| 开发完成 | | 工程师 | 可测版本 |
| 测试通过 | | QA | 测试报告 |
| 上线 | | PM | 数据监测 |

---

## 七、风险与依赖

| 风险 | 概率 | 影响 | 应对方案 |
|------|------|------|---------|
| [技术风险] | 高/中/低 | | |
| [业务风险] | | | |
| [依赖方风险] | | | |

---

## 八、附录
- 竞品参考：[链接]
- 用户研究报告：[链接]
- 数据分析报告：[链接]

---

## 变更记录
| 版本 | 日期 | 变更内容 | 作者 |
|------|------|---------|------|
| v1.0 | [日期] | 初版 | [姓名] |

参考资料

详细理论基础、原则解析和推荐书目见 references/knowledge.md。