Product Requirements Document (PRD)

产品需求文档（PRD）

A Product Requirements Document is the primary specification artifact that communicates what to build and why. It bridges the gap between problem understanding and engineering implementation by providing clear requirements, success criteria, and scope boundaries. A good PRD enables engineering to build the right thing while maintaining flexibility on implementation details.

产品需求文档（PRD）是核心的规范工件，用于传达需构建的内容及其原因。它通过提供清晰的需求、成功标准和范围边界，填补了问题理解与工程实现之间的差距。一份优质的PRD能够让工程团队构建出正确的产品，同时在实现细节上保持灵活性。

When to Use

适用场景

After problem and solution alignment, before engineering work begins
When specifying features, epics, or product initiatives for handoff
When multiple teams need to coordinate on a shared deliverable
When stakeholders need to approve scope before investment
As reference documentation during development and QA

在问题与解决方案达成共识后、工程工作开始前
向工程团队移交工作时，指定功能、史诗（Epic）或产品计划
多个团队需要协调完成共同交付成果时
利益相关方需要在投入资源前批准范围时
作为开发和QA过程中的参考文档

Instructions

操作步骤

When asked to create a PRD, follow these steps:

Summarize the Problem Start with a brief recap of the problem being solved. Link to the problem statement if available. Ensure readers understand why this work matters before diving into what to build.
Define Goals and Success Metrics Articulate what success looks like. Include specific, measurable metrics with baselines and targets. These metrics should connect directly to the problem being solved.
Outline the Solution Describe the proposed solution at a high level. Focus on user-facing functionality and key capabilities. Include enough detail for stakeholders to evaluate the approach without over-specifying implementation.
Detail Functional Requirements Break down what the system must do. Use user stories or requirement statements. Each requirement should be testable . someone should be able to verify if it's met.
Define Scope Boundaries Explicitly state what's in scope, out of scope, and deferred to future iterations. Clear scope prevents scope creep and sets realistic expectations.
Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don't design the system, but surface considerations engineering needs to know.
Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.
Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.

当被要求创建PRD时，请遵循以下步骤：

总结问题 首先简要概述要解决的问题。如有可用的问题陈述，请附上链接。在深入介绍需构建的内容之前，确保读者理解这项工作的重要性。
定义目标与成功指标 明确成功的标准。包含具体、可衡量的指标，以及基准值和目标值。这些指标应直接关联到要解决的问题。
概述解决方案 从高层描述拟议的解决方案。聚焦于面向用户的功能和核心能力。提供足够的细节让利益相关方评估方案，同时不过度指定实现细节。
详述功能需求 分解系统必须实现的功能。使用用户故事或需求陈述。每项需求都应可测试——即有人能够验证是否满足该需求。
定义范围边界 明确说明哪些内容在范围内、哪些在范围外，以及哪些将推迟到未来迭代。清晰的范围可防止范围蔓延，并设定合理的预期。
考虑技术因素 记录任何技术约束、架构决策或集成要求。无需设计系统，但需列出工程团队需要了解的考量因素。
识别依赖项与风险 列出可能影响交付的外部依赖项、假设和风险。适用时包含缓解策略。
提出时间线与里程碑 概述关键阶段和检查点。这有助于利益相关方了解交付计划，同时避免过早承诺具体日期。

Output Format

输出格式

Use the template in

references/TEMPLATE.md

to structure the output.

使用

references/TEMPLATE.md

中的模板来构建输出内容。

Quality Checklist

质量检查表

Before finalizing, verify:

Problem and "why now" are clearly articulated
Success metrics are specific and measurable
Scope boundaries are explicit (in/out/future)
Requirements are testable and unambiguous
Technical considerations are surfaced without over-specifying
Dependencies and risks are documented with owners
Document is readable in under 15 minutes

定稿前，请验证：

问题和“为何现在推进”已清晰阐述
成功指标具体且可衡量
范围边界明确（包含/排除/未来迭代）
需求可测试且无歧义
技术考量已列出且未过度指定
依赖项和风险已记录并明确负责人
文档可在15分钟内读完

Examples

示例

See

references/EXAMPLE.md

for a completed example.

请查看

references/EXAMPLE.md

获取完整示例。

deliver-prd

Original

Translation