# Laowang Prd

> 把一句话需求或会议要点补全成大厂标准的工业级 PRD。输入功能点或零散会议记录， 输出含业务背景与衡量指标、用户故事与状态流转机、字段字典（含边界值校验）、 异常分支矩阵（高并发冲突／弱网抖动／过期撤销）、核心事件埋点字典表的完整 Markdown 文档。 用户说写 PRD、需求文档、产品需求文档、功能规格、评审文档、补需求、需求评审时使用。 适用于产品经理在评审前把口头需求落成研发挑不出刺的文档。 不编造业务数据与指标；不做竞品调研；不生成 UI 稿。

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

---


# 老王大厂 PRD 交付（laowang-prd）

一句话需求进去，一份研发挑不出刺的 PRD 出来。

核心不是「把话说漂亮」，而是**把漏洞扼杀在评审之前**：正常路径人人会写，值钱的是异常分支、边界值和埋点。

## 能力边界

| 能力 | 输入 | 产出 |
|------|------|------|
| **完整 PRD** | 一句话需求 / 会议要点 / 零散功能点 | 7 章标准 PRD（Markdown） |
| **增量补章** | 已有 PRD 草稿 | 缺失章节 + 补全说明 |
| **异常补全** | 已有主干流程 | 异常分支矩阵 + 兜底策略 |
| **字段字典** | 业务实体描述 | 字段表（类型／必填／边界／校验／默认值） |
| **埋点字典** | 功能点 + 衡量指标 | 事件表（事件名／触发时机／参数／口径） |
| **自检报告** | 已完成的 PRD | 闸门检查结果 + 待补清单 |

**不做**：编造业务数据、用户量、转化率（缺数据一律写 `[待补：需业务方提供]`）；代替竞品分析；生成视觉稿；代替技术方案设计。

## 启动必读

1. 本文件 `SKILL.md`
2. [references/prd-skeleton.md](references/prd-skeleton.md) —— 7 章固定骨架与每章硬要求
3. [references/self-check-gates.md](references/self-check-gates.md) —— 交付前 8 道闸门
4. [references/exception-matrix.md](references/exception-matrix.md) —— 异常四问与三大高频场景矩阵

按需再读：

- 写字段 → [references/field-dictionary.md](references/field-dictionary.md)
- 写埋点 → [references/tracking-dictionary.md](references/tracking-dictionary.md)
- 起手抄结构 → [assets/prd-template.md](assets/prd-template.md)
- 看完整实例 → [examples/coupon-issuance-prd.md](examples/coupon-issuance-prd.md)

## 路由规则

1. 用户给一句话需求或会议要点 → 走**完整 PRD**，7 章全出。
2. 用户给已有 PRD 草稿 → 走**增量补章**，只补缺的，重写已有章节要先问。
3. 用户只要字段规则 / 只要埋点 → 走对应单章，别硬塞整份 PRD。
4. 用户说「先给个大纲」→ 只出 7 章骨架 + 每章要点，不展开。
5. 信息不足 → 一次问 1–3 个高优先级问题（业务目标、核心用户、关键约束），**其余先按最合理假设往下写并标注**，不要用 10 个问题卡住用户。

## 工作流程

### 步骤 1：需求拆解

从输入里抽出四件事，抽不出的标注待补：

```text
业务目标：这个功能要让哪个指标动起来
核心用户：谁在用，什么场景下用
功能边界：做什么、明确不做什么
关键约束：时间、库存、权限、并发、合规
```

### 步骤 2：按 7 章骨架展开

严格按 [references/prd-skeleton.md](references/prd-skeleton.md) 的章节顺序与硬要求写。

### 步骤 3：递归补全（这是本 Skill 的核心价值）

对**每一个**功能点，逐层追问并补进文档：

| 追问 | 补进哪一章 |
|---|---|
| 做这件事的**前置条件**是什么？ | 用户故事的 Given |
| 做完的**后置状态**是什么？ | 状态流转机的目标态 |
| 涉及哪些**字段**？边界值多少？ | 字段字典 |
| 高并发 / 弱网 / 过期 / 重复点击会怎样？ | 异常分支矩阵 |
| 上线后怎么知道它有效？ | 埋点字典 + 衡量指标 |
| 什么情况下**不做**？ | 范围之外 |

**递归规则**：每条异常分支本身也要过一遍前置、后置、字段、埋点。一轮补完检查是否还有未展开的分支，直到收敛。

### 步骤 4：跑自检闸门

按 [references/self-check-gates.md](references/self-check-gates.md) 逐条检查。跑脚本：

```bash
python3 scripts/check_prd.py path/to/prd.md
```

未过闸门的章节不得交付。

### 步骤 5：交付

输出单份 Markdown，回复里附自检结果摘要与待补清单。

## 硬性规则

- **不编造数字**。用户量、转化率、库存量、SLA 缺失时写 `[待补：需业务方提供]`，不填看起来合理的假值。
- **每条异常分支必须有出口**：要么有兜底动作，要么明确写「不处理，接受该风险，原因：X」。
- **字段边界必须写具体数值**，不写「合理长度」「适当限制」。不知道就标待补。
- **埋点事件名用 `snake_case`**，且必须与衡量指标对得上；没有指标支撑的埋点不写。
- **状态流转必须闭合**：每个状态都要有进入条件和退出条件，不允许出现无法退出的状态。
- 不写「尽快」「适当」「若干」这类模糊词；替换成具体值或标待补。
- 不生成 UI 视觉稿；需要原型转 `laowang-prototype`，需要流程图转 `laowang-diagram`。

## 质量检查

交付前逐条过：

- 7 章是否齐全，章节顺序是否正确？
- 业务背景里是否有**可量化的衡量指标**，而不是「提升用户体验」？
- 每个用户故事是否都有 Given-When-Then，且 Given 覆盖了前置条件？
- 状态流转机是否每个状态都有入边和出边？是否有终态？
- 字段字典是否每个字段都标了类型、必填、边界值、校验规则、默认值？
- 异常矩阵是否覆盖了高并发冲突、弱网抖动、过期撤销这三类？
- 埋点事件是否每个都能对应到一条衡量指标？
- 是否出现编造的数值？（出现即不合格）
- 是否出现「尽快」「适当」这类模糊词？
- `check_prd.py` 是否通过？

## 产出说明模板

```text
已生成 PRD：<路径>
覆盖：<n> 个功能点、<m> 个用户故事、<k> 条异常分支、<j> 个埋点事件
自检：8 道闸门 <通过数>/8；待补项 <x> 条
待业务方确认：<列出关键待补>
```