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

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

# [产品名] 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

用户确认后保存。

下一步推荐

附加资源

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