---
name: li-prd
description: |
  产品 PRD 生成工具。结合《创造》的产品故事方法论、product-position 的定位框架，
  以及 Lenny's Newsletter 的 PRD 最佳实践，帮你从想法生成一份可执行的产品需求文档。
  触发方式：/li-prd、「帮我写 PRD」「生成需求文档」「写产品文档」「把这个想法写成 PRD」
  「黑客松 PRD」「整理产品需求」「我要开始做了，帮我理清需求」
  即使用户没说"PRD"，只要他们想把一个产品想法整理成可执行的文档，也应触发本 skill。
  DO NOT trigger for: 内容脚本生成、选题分析、数据复盘等内容创作任务。
---

# li-prd：产品需求文档生成

把想法变成团队能执行的文档。

**核心原则：PRD 的第一读者是自己。** 写完不想读，工程师也不会读。

---

## 前置检查

启动后先问：

> 你现在有多少明确的信息？
> A. 只有一个想法，还很模糊
> B. 想法清晰了，但没整理过
> C. 基本想清楚了，帮我结构化输出

- **A** → 建议先跑 `/product-position` 做定位分析，再回来写 PRD。原因：PRD 是对已验证方向的结构化，不是用来帮产品方向找答案的。
- **B** → 进入引导模式
- **C** → 进入直接生成模式，先出草稿再修订

---

## 引导模式

每次只问一个问题，等回答后再问下一个。提问顺序固定，因为每个问题的答案会影响后续问题的质量。

**问题 1 — Why Now**
> 为什么是现在做这个，而不是三个月后？

如果答案是"因为有黑客松"或"因为想清楚了"——追问：产品本身的 Why Now 是什么？外部触发只是时间节点，产品逻辑上的紧迫性才是真正的 Why Now。

**问题 2 — Target User**
> 谁是你的第一个用户？命名一个真实的人，不是用户画像。

"内容创作者"不够，"已装 Claude Code、用手动维护 CLAUDE.md 的独立博主" 才是目标。用户越具体，功能越清晰。

**问题 3 — Status Quo**
> 这个用户现在怎么解决这个问题的？

产品必须比某个现有方案更好。说不出替代方案，说明痛点可能不够真实。

**问题 4 — Success Criteria**
> 三个月后，怎么知道做对了？给一个可量化的指标。

"用户喜欢"不算。"第二天还在用"、"有 10 个非创始人用户"才算。

**问题 5 — Out of Scope**
> 列出 2-3 件你故意不做的事。

边界清晰比功能完整重要。Out of Scope 是对团队和自己的承诺。

**问题 6 — MVP**
> 第一版要交付什么？用"用户能做到 X"描述，不用功能列表。

功能列表是实现路径，MVP 是用户能感受到的价值边界。

收集完 6 个答案后进入生成阶段。

---

## 生成 PRD

基于收集到的信息，填入以下模板。每个模块生成后暂停，确认无误再继续下一个。

```markdown
# [产品名] PRD
> 版本：v[X] | 日期：[YYYY-MM-DD] | 作者：[名字]
> 状态：草稿 / 评审中 / 已确认

---

## 一句话描述
[谁 + 用来做什么 + 解决什么问题，一句话]

示例：理理 Liri 是一个 Mac 桌面 App，让不会用 Claude Code 的创作者
也能通过"文件夹即 App"的方式使用 AI 管理自己的工作流。

---

## 为什么做

### 问题
[用户现在遇到的真实问题，用具体场景描述，不用抽象概念]

### 为什么现在
[为什么是现在，而不是三个月后或三个月前]

### 怀疑病毒
[一句让用户开始质疑现有方案的话]
示例："每次打开 Claude Code 都要重新解释你是谁，这件事会一直发生。"

---

## 目标用户

**主要用户：** [一个具体的人的描述]
**次要用户：** [可选]
**不是我们的用户：** [明确排除，防止范围蔓延]

---

## 客户旅程

| 阶段 | 用户做什么 | 产品做什么 |
|------|-----------|-----------|
| 发现 | | |
| 安装/启动 | | |
| 首次使用 | | |
| 持续使用 | | |
| 推荐他人 | | |

标出最薄弱的环节，并在功能范围里重点说明该环节的设计方案。通常"持续使用"是最容易被忽视的。

---

## 功能范围

### 必须做（Must Have）
[用"用户能做到 X"描述，不用技术实现语言]

- 用户能 ...
- 用户能 ...

### 不做（Out of Scope）

- 不做 ...（原因：...）
- 不做 ...（原因：...）

### 以后做（Future）
[想做但不是现在]

---

## 成功标准

**第一版验收（黑客松/MVP）：**
- [ ] [用户 A 能在 X 分钟内完成 Y，无需任何指导]
- [ ] [具体可测试的行为]

**3 个月目标：**
- [一个核心指标]

---

## 新闻稿

先写新闻稿，再写代码。如果写不出来，说明产品故事还没想清楚。

[假设产品已上线，写 3-5 句：
用户的痛点是什么 → 产品解决了什么 → 用户现在能做到什么]

---

## 开放问题

| 问题 | 影响 | 截止日期 |
|------|------|---------|
| | | |

---

## 风险

| 风险 | 概率 | 应对 |
|------|------|------|
| | 高/中/低 | |
```

---

## 生成后自检

生成草稿后，过以下四项，发现问题直接修改：

1. **Why Now 存在吗？** 去掉这段，PRD 还能说服人开始做吗？
2. **成功标准可测量吗？** 能不能让一个陌生人来验证？
3. **Out of Scope 写了吗？** 没有边界的 PRD 是灾难
4. **客户旅程最薄弱环节标出来了吗？** 没有针对性设计方案的薄弱环节是隐患

---

## 保存

确认 PRD 内容后，询问保存路径，默认建议：

```
[产品名]/[产品名]-PRD-v1.md
```

用户确认后保存。

---

## 下一步推荐

| 触发条件 | 推荐 |
|---------|------|
| PRD 写好，要让专家顾问强化 | `/li-prd-review` 托尼/YC/Lenny 找漏洞给方案 |
| PRD 写好，要验证方向 | `/product-position` |
| PRD 写好，要做内容传播 | `/li-topic` 把产品故事转成选题 |
| PRD 写好，要开始开发 | `/li-workflow` 检查工作流覆盖情况 |
| 商业模式不清晰 | `/dbs-diagnosis` |

---

## 附加资源

- **`references/prd-examples.md`** — 理理 Liri 黑客松 PRD 真实案例（按需加载）