PRD 撰写者 — 多轮需求收集

概述

通过一次只提出一个聚焦问题的方式，引导用户完成一份专业的 PRD。目标是产出一份完整、可执行的 PRD，作为团队唯一的事实来源（Single Source of Truth）。

流程

阶段 1：问题发现（2–3 个问题）

首先深入理解核心问题：

1. 问题陈述：“您具体要解决什么问题？请描述用户的痛点。”
2. 为何是现在：“为什么这个问题必须现在解决？如果不解决，会发生什么？”
3. 现有解决方案：“用户当前如何解决该问题？（例如临时方案、竞品等）”

阶段 2：用户与市场（2–3 个问题）

4. 目标用户：询问主要用户是谁，并提供常见角色类型供选择：

   • 终端消费者（B2C）
   • 企业用户（B2B）
   • 内部团队成员
   • 开发者/技术用户
   • 其他（请说明）

5. 用户使用场景：“用户将在何种情境下遇到此功能？（例如：移动端通勤途中、办公桌面端、特定工作流）”

6. 市场规模 / 影响范围：“该功能将影响多少用户？这是核心功能还是锦上添花的功能？”

阶段 3：成功指标（1–2 个问题）

7. 成功定义：询问“怎样的结果才算成功？”，并提供常见指标类型：

   • 用户参与度（DAU、留存率、使用时长）
   • 业务指标（收入、转化率、成本降低）
   • 技术指标（性能、可靠性、错误率）
   • 用户满意度（NPS、CSAT、支持工单量）

8. 具体目标值：“哪些具体数值可作为成功的标志？（例如：‘将加载时间缩短至 <2 秒’、‘提升转化率 15%’）”

阶段 4：范围定义（2–3 个问题）

9. 核心功能：“v1 版本中 MUST-have 的功能有哪些？请列出上线所需的绝对最小功能集。”

10. 明确排除项：“本阶段中我们明确不做的功能有哪些？（此举可防止范围蔓延）”

11. 未来考虑项：“v2/v3 版本中可能包含哪些功能？（暂存，留待后续迭代）”

阶段 5：约束条件与依赖项（1–2 个问题）

12. 技术约束：询问以下限制条件：

    • 现有技术栈要求
    • 集成依赖项
    • 性能要求
    • 安全/合规性要求
    • 预算/资源限制

13. 时间节点：“目标上线日期或截止时间是什么？是否存在外部依赖？”

阶段 6：优先级排序（1 个问题）

14. MoSCoW 排序：呈现已收集的功能列表，请用户分类：
    • Must（必须）：上线必备功能
    • Should（应该）：重要但必要时可延后
    • Could（可以）：锦上添花的功能
    • Won’t（不会）：明确排除的功能

提问指南

• 一次只问一个问题 —— 切勿一次性抛出多个问题造成信息过载
• 在选项明确时使用 AskUserQuestion 工具，并提供多选选项
• 为开放式回答保留 “其他” 选项
• 每阶段结束后总结确认：确保理解无误再进入下一阶段
• 支持回溯修改：若用户希望修订前期答案，请予以支持
• 跳过已提供信息的问题：若用户已在初始输入中说明相关内容，则无需重复提问

示例提问流程

Q1: “您要解决什么问题？”
→ 用户描述痛点

Q2: “为什么这个问题现在亟需解决？”
→ 用户说明时机背景

[总结]：“因此我们要解决 [X]，原因是 [Y]。是否正确？”
→ 用户确认或修正

Q3: “主要用户是谁？”
→ 使用 AskUserQuestion 提供多选选项

... 按阶段依次推进 ...

输出：PRD 文档

完成全部信息收集后，生成结构完整的 PRD，格式如下：

# PRD: [产品/功能名称]

## 元数据
| 字段 | 值 |
|-------|-------|
| 作者 | [用户姓名] |
| 状态 | 草稿 |
| 创建时间 | [日期] |
| 最后更新 | [日期] |

## 1. 问题陈述
[对问题及其重要性的清晰描述]

### 为何是现在？
[紧迫性与时间窗口的合理性说明]

## 2. 目标与成功指标
### 目标
- [SMART 目标 1]
- [SMART 目标 2]

### 成功指标（KPI）
| 指标 | 当前值 | 目标值 | 时间节点 |
|--------|---------|--------|----------|
| [指标 1] | [基线值] | [目标值] | [达成时间] |

## 3. 用户与市场
### 目标用户
[主要用户画像描述]

### 用户故事
- 作为一个 [用户类型]，我希望 [行为]，以便 [获益]

### 竞争格局
[当前用户如何解决该问题]

## 4. 范围
### 已涵盖（v1）
- [必须功能 1]
- [必须功能 2]

### 明确排除
- [明确排除项 1]
- [明确排除项 2]

### 后续考虑（v2+）
- [暂缓功能 1]

## 5. 功能需求
### 功能：[名称]
**优先级**：Must/Should/Could  
**描述**：[该功能的作用]  
**验收标准**：  
- [ ] [标准 1]  
- [ ] [标准 2]  

## 6. 技术约束
- [约束 1]  
- [约束 2]  

### 依赖项
- [外部依赖 1]  

## 7. 时间线与里程碑
| 里程碑 | 目标日期 |
|-----------|-------------|
| 设计完成 | [日期] |
| 开发启动 | [日期] |
| Beta/测试 | [日期] |
| 上线 | [日期] |

## 8. 待解问题
- [未决问题 1]  
- [未决问题 2]  

## 9. 附录
[任何额外背景、线框图引用、调研链接等]

PRD 生成后

步骤 1：保存与共享

1. 保存 PRD：询问保存位置（docs/prd/、docs/specs/ 或自定义路径）
2. 提交至 Git：为 PRD 文档创建一次提交
3. 发起评审：建议发送给相关干系人获取反馈

步骤 2：设计（如涉及 UI/UX）

提问：“该功能是否需要 UI 设计？”

• 是 → 建议使用 /brainstorming 技能探索设计方案
• 是 + 需要原型图 → 建议使用 /frontend-design 生成线框图/原型
• 否 → 直接进入实施规划阶段

步骤 3：技术架构

提问：“该功能是否足够复杂，需要专门的技术架构设计？”

• 复杂功能 → 调用 architect 子智能体进行系统设计
  • 输出内容包括：组件拆分、数据流向、技术选型、接口设计
• 简单功能 → 直接进入任务拆解阶段

步骤 4：任务拆解

提问：“是否需要将 PRD 拆解为开发任务？”

• 是 → 调用 planner 子智能体生成实施计划
  • 基于架构设计进行拆解
  • 生成 TaskCreate 条目，包含：
    • 来自 PRD 的清晰验收标准
    • 已标注依赖关系（blockedBy）
    • 源自 MoSCoW 排序的优先级

步骤 5：实施

任务创建完成后：

1. planner → 为每个任务生成详细实施计划
2. 编写代码
3. code-reviewer → 提交前自动代码审查
4. test-creator → 自动生成测试用例
5. security-reviewer → 如涉及敏感代码则启用

步骤 6：验证

上线前执行：

1. e2e-runner → 执行端到端自动化测试
2. 对照 PRD 中的成功指标进行效果比对
3. 将 PRD 状态更新为 “Shipped”

工作流速查表

阶段 0：需求
/prd-writer          → 多轮问答收集需求，生成 PRD

阶段 1：规划
architect agent      → 技术架构设计（如何构建）
planner agent        → 拆解为实施任务（构建什么）

阶段 2：实施
[编写代码]

阶段 3：质量保障（并行）
code-reviewer + security-reviewer  → 并行审查
test-creator                       → 补充测试用例

阶段 4：验证
e2e-runner           → 端到端验证
doc-updater          → 更新文档

PRD 状态 → Shipped

交接提示语

PRD 完成后，向用户提供以下下一步操作选项：

PRD 已生成！您希望接下来做什么？

1. UI/UX 设计探索 (/brainstorming) — 若涉及界面
2. 技术架构设计 (architect) — 决定如何构建
3. 拆解为开发任务 (planner) — 决定构建什么
4. 暂存，稍后继续

使用 AskUserQuestion 工具让用户自主选择。

核心原则

• 先问题，后方案 —— 在透彻理解问题之前，绝不急于讨论功能
• 量化成功 —— 模糊的目标必然导致模糊的结果
• 明确排除项 —— “不做” 什么，与 “做” 什么同等重要
• 活文档 —— 提醒用户随需求演进持续更新 PRD
• YAGNI（You Aren’t Gonna Need It） —— 极其严苛地剔除 v1 非必需功能

Lenny 播客智慧整合

撰写 PRD 时，自动引入顶尖产品领袖的相关洞见，以丰富 PRD 过程：

阶段 1：问题发现

April Dunford：“真正出色的产品定位，让人感觉如此清晰、如此简洁——‘啊，原来它就是这样的！’”

• 提问：“有哪些竞争性替代方案（含现状本身）？”
• 谨记：40% 的 B2B 交易因“未做决策”而失败——您真正的对手可能是 Excel 表格！

Shreyas Doshi：“大多数执行问题，本质上其实是战略问题。”

• 若用户描述的是执行层面问题，应进一步深挖其背后的战略清晰度

阶段 2：为何是现在？

Brian Chesky：“如果你打造了一款优秀的产品，却无人知晓，那它真的存在吗？”

• 提问：“您将如何讲述这款产品的故事？”
• 把每一次发布都视为一个宏大叙事中的章节

阶段 3：范围定义

Brian Chesky：“五支团队专注一件事，胜过一支团队同时做五件事。”

• 严苛削减范围
• 提问：“为了更聚焦，您愿意砍掉哪些功能？”

Brian Chesky：“往项目里增加更多人，是拖慢进度最有效的方法。”

• 小团队 + 聚焦范围 = 更快交付

阶段 4：成功指标

Marty Cagan：“优化比创新容易；但唯有创新才能胜出。”

• 不要止步于指标优化——追问“创造了哪些全新价值？”
• 待办事项列表中的每一项都是一个赌注——请下更好的注

阶段 5：风险评估

Shreyas Doshi：预演式复盘（Pre-mortem）框架 PRD 初稿完成后，建议开展预演式复盘：

• 老虎（Tigers）：真实存在的、足以扼杀项目的威胁
• 纸老虎（Paper Tigers）：看似危险实则虚张声势的威胁
• 大象（Elephants）：大家心照不宣却无人提及的重大问题

提问：“哪 3 只‘老虎’（真实威胁）可能导致本项目失败？”

阶段 6：优先级排序

Shreyas Doshi：LNO 框架

• L（杠杆效应 Leveraged）：哪些功能可带来 10–100 倍回报？重点投入。
• N（中性 Neutral）：标准功能，预期 1 倍回报
• O（开销 Overhead）：投入产出比低于 1 的功能

参考：智慧来源

所有洞见均源自 Lenny’s Podcast。若您拥有本地播客文字稿，可搜索获取更多上下文。

快速模式

若用户提出 “quick PRD” 或 “lean PRD”，启用精简流程：

1. 问题（1 个问题）
2. 用户（1 个问题）
3. 成功指标（1 个问题）
4. 必须功能（1 个问题）
5. 生成一页纸（One-Pager）格式 PRD

作者

Canlah AI —— 在不损害品牌调性的前提下运行效果营销。

• GitHub：github.com/PHY041
• 全部技能：clawhub.ai/PHY041