产品需求文档（PRD）撰写

在 https://www.zangwei.dev/prompts/product-execution/product-requirements-document-prd-prompt 有一个提示词指南。请提取并遵循该提示词来创建文件 /docs/handbook/product/{version|feature}/prd.md

你是一名资深产品负责人，需要为当前阶段的产品撰写 PRD
（Product Requirements Document，产品需求文档）。

【目标读者】
- 产品、运营、研发、测试等相关人员
- 目的：让所有人清楚知道
  1）要做什么（做哪些功能、核心与非核心是什么）
  2）怎么做（交互、流程、业务逻辑细节）
  3）什么时间内做完（里程碑与交付节奏）

【PRD 核心定位】
- PRD 是产品与研发之间的“可执行契约”
- PRD 不仅要说明“做什么”，还要说明“怎么做（交互与逻辑）”
- 所有需求必须可验证、可验收、可交付

【总体要求】
- 严格遵守已定义的产品边界（不做什么）
- 避免愿景化语言与模糊表述（如“支持/优化/提升”）
- 对每项需求给出清晰的完成标准与验收方式
- 交互与逻辑描述尽量具体，确保研发与测试可据此实现与验证
- 若信息不足导致无法写清楚“怎么做”，请明确列为风险与待澄清项

---

【PRD 输出结构】

一、背景与目标
- 本次 PRD 对应的 Roadmap 阶段与版本范围
- 本版本要解决的核心问题是什么？
- 本版本成功后，对应的成功判据或指标（北极星/护栏指标中相关项）

二、交付计划与里程碑（时间内做完）
- 预期交付周期与关键里程碑（如：开发完成、联调、测试、上线）
- 每个里程碑的交付物是什么
- 不可发布条件（哪些问题出现时必须延期或回滚）

三、产品概述（产品要做什么）
- 产品在本版本中“具体是干嘛的”（一句话）
- 功能列表（按模块或用户任务划分）
- 核心功能 vs 非核心功能（明确标注）
- 本版本明确不包含的功能（延续产品边界）

四、目标用户与核心使用场景
- 本版本服务的核心用户是谁？
- 用户在什么具体场景下使用？
- 本版本只聚焦解决哪一个核心任务？
- 用户从进入到获得结果的主路径概述（简版）

五、需求范围说明（Scope）
- 本 PRD 明确包含的需求范围
- 本 PRD 明确不包含的需求（以及原因：不属于 MVP / 延后 / 不做）
- 与其他系统/团队的边界与协作范围

六、详细需求说明（产品要怎么做：交互与逻辑）
请按“功能模块 → 功能点”逐条描述。每条需求必须包含：

1）需求描述（用户视角）
- 用户要完成什么任务？得到什么结果？

2）交互流程（越详细越好）
- 页面/入口（从哪里进入）
- 操作步骤（用户点击/输入/选择什么）
- 系统反馈（加载、提示、成功/失败反馈）
- 状态变化（操作前后状态如何变化）
- 关键文案或提示（如影响理解/转化，需写出示例）

3）业务逻辑与规则
- 触发条件与前置条件
- 权限/角色差异（如有）
- 数据规则（校验、去重、优先级、默认值）
- 约束与限制（频次、大小、格式等）

4）边界与异常处理
- 常见异常场景如何处理
- 失败时的降级策略（如返回默认值、提示重试、保底流程）
- 明确哪些异常本版本不处理（并说明原因）

5）验收标准（可测试）
- Given/When/Then 或等价格式描述
- 通过标准与不通过标准分别是什么

七、非功能性需求（Non-Functional Requirements）
仅列出与本版本成功直接相关的内容，例如：
- 性能下限（响应时间、吞吐、并发）
- 稳定性（可用性、错误率阈值）
- 安全与合规底线（隐私、权限、审计）
- 可用性要求（关键路径可理解性、提示清晰度）

八、依赖、假设与风险
- 关键依赖（外部接口、第三方服务、数据准备、人员）
- 需求成立的前提假设
- 风险清单（含影响、概率、缓解措施）
- 待澄清问题列表（无法写清“怎么做”的部分必须列出）

九、测试与验收计划（QA & Acceptance）
- 测试范围（功能、回归、兼容、性能等）
- 验收 Checklist（核心路径必过项）
- 上线前必须满足的门槛
- 上线后需重点观察的指标与告警信号

---

【输出要求】
- 技术实现方案可点到为止，但不写成技术设计文档（详细架构放到技术方案文档）
- 交互与逻辑必须足够具体，可直接指导研发实现与测试验证
- 不加入未验证的新需求
- 每一条需求都必须能被测试或验收

请在最后用 3–5 条要点总结：
“这个 PRD 是否足以让产品、研发、测试、运营在无需反复确认的情况下协同推进并按期交付？”