prd-generation

PRD 生成

概述

通过引导式探索，将高层构想转化为结构化的产品需求文档。此技能将逐步梳理问题、解决方案和约束，生成包含可衡量目标和用户故事的专业 PRD，并在保存前确保获得利益相关者的批准。

开始时声明：“我正在使用 prd-generation 技能来创建产品需求文档。”

阶段 1：探索

逐一提问（尽可能优先采用选择题）。

**不要跳过探索阶段。**即使用户提供了详细说明，也至少要提出 3 个澄清问题，以确认理解无误。

探索结束后暂停——汇总已收集的答案，并在起草前征求确认。

问题空间

#	问题	重要性
1	这个产品要解决什么问题？	为整个 PRD 奠定基础
2	目标用户是谁？（用户画像、角色）	决定用户故事的构成
3	用户目前如何解决这个问题？	了解竞争格局
4	如果不解决这个问题，会有什么影响？	说明优先级的合理性

解决方案空间

#	问题	重要性
5	成功的标准是什么？（具体指标）	定义成功指标
6	哪些功能是必备的，哪些是锦上添花？	确定优先级层级
7	明确的非目标有哪些？	防止范围蔓延
8	是否有可供借鉴的现有解决方案？	为设计决策提供参考

约束问题

#	问题	重要性
9	时间安排如何？是否有硬性截止日期？	确定发布计划的范围
10	存在哪些技术约束？	缩小解决方案范围
11	有哪些可用资源？	设定切合实际的预期
12	是否有合规或监管要求？	识别非功能性需求

阶段 2：起草 PRD

使用下方模板生成 PRD。将收集到的答案交给 prd-writer Agent，以完成大量内容生成工作。

起草后暂停——在阶段 3 审查完成前，不要将其作为最终版本呈现。

PRD 模板

# [Product/Feature Name] — Product Requirements Document

## 1. Overview
One paragraph summarizing what this is and why it matters.

## 2. Problem Statement
- Current situation
- Pain points
- Impact of not solving

## 3. Goals & Non-Goals
### Goals
- [ ] Goal 1 (measurable)
- [ ] Goal 2 (measurable)

### Non-Goals
- Explicitly NOT doing X
- Explicitly NOT doing Y

## 4. User Stories
As a [persona], I want to [action], so that [benefit].

## 5. Functional Requirements
### FR-1: [Requirement Name]
- Description
- Acceptance criteria
- Priority (P0/P1/P2)

## 6. Non-Functional Requirements
- Performance: [specific targets]
- Security: [requirements]
- Accessibility: [standards]
- Scalability: [expectations]

## 7. Technical Constraints
- Platform/stack requirements
- Integration dependencies
- Data requirements

## 8. Success Metrics
| Metric | Current | Target | How to Measure |
|--------|---------|--------|----------------|

## 9. Timeline & Milestones
| Phase | Description | Target Date |
|-------|-------------|-------------|

## 10. Open Questions
- [ ] Question 1
- [ ] Question 2

## 11. Appendix
References, mockups, related documents

优先级分类

优先级	含义	规则
P0	发布必备	缺少此项，产品就无法发布
P1	重要，应在发布后尽快推出	价值显著，但不是发布的阻碍
P2	锦上添花	提升体验，可以稍后推出

阶段 3：审查

逐节呈现 PRD：

1. 每节结束后询问：“这符合你的意图吗？需要做哪些修改？”
2. 根据反馈进行修订，然后再进入下一节
3. 特别关注以下高信号章节：
   • 目标与非目标（范围是否一致）
   • 用户故事（用户画像是否准确）
   • 成功指标（是否可衡量）
   • 功能需求（验收标准是否完整）

审查结束后暂停——在保存前，必须明确获得“已批准”的确认。

阶段 4：保存并衔接

获得明确批准后：

1. 保存到 docs/prds/YYYY-MM-DD-<feature>.md
2. 使用提交信息 docs(prd): add PRD for <feature> 提交 PRD
3. 如果接下来要实施，则调用 brainstorming 技能
4. 如果需要规格说明，则调用 spec-writing 技能

衔接决策表

用户意图	下一项技能	原因
“我们来构建这个”	brainstorming → planning	先探索方案，再制定计划
“编写规格说明”	spec-writing	将 PRD 拆解为 JTBD 规格
“只需保存”	无	PRD 就是交付成果
“获取估算”	task-decomposition	将其拆解为可估算的任务

反模式／常见错误

错误	错在哪里	应该怎么做
跳过调研，直接开始起草	生成的 PRD 会基于假设	始终先完成阶段 1
目标没有指标	无法衡量成功与否	每个目标都需要一个数字
缺少非目标	必然导致范围蔓延	明确列出不在范围内的内容
用户故事没有验收标准	需求无法测试	为每个故事添加 Given/When/Then
成功指标过于笼统（“改善 UX”）	无法衡量	使用具体数字：“将加载时间缩短至 <2s”
一次性展示整个 PRD 供审查	用户会不知所措，并给出流于表面的批准	按章节逐一展示
原封不动地照搬竞争对手的功能	无法了解用户的实际需求	聚焦用户的问题，而不是解决方案

防止自我合理化的约束

• 不要因为“用户已经描述得足够清楚”就跳过调研
• 不要在任何章节中留下占位文本——填写每个章节，或标注为“TBD：[原因]”
• 不要在用户明确批准每个章节之前保存
• 不要编造成功指标——这些指标必须由用户提供

集成点

技能	关系
brainstorming	上游：在编写 PRD 之前探索想法；下游：在编写 PRD 之后探索实现方式
spec-writing	下游：PRD 提供高层需求；规格说明通过 JTBD 对其进行详细说明
planning	下游：计划引用 PRD 需求以拆分任务
task-decomposition	下游：将 PRD 拆分为可估算的工作项
tech-docs-generator	并行：PRD 提供编写所需文档的信息
acceptance-testing	下游：PRD 中的验收标准用于定义测试

验证关卡

在宣称 PRD 已完成之前：

1. 验证 11 个章节均已填写（不是占位文本）
2. 验证每个目标都有可衡量的指标
3. 验证非目标明确且有意义
4. 验证用户故事包含验收标准
5. 验证用户已逐一批准每个章节
6. 验证文件已保存并提交

具体示例：调研摘要

Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.

此摘要会在阶段 2 开始前提交给用户确认。

技能类型

灵活——根据项目背景调整调研深度和 PRD 结构，同时保留先调研再起草的原则以及逐章节审查流程。