需求与 PRD

PRD（Product Requirements Document） 把战略与发现翻译成工程、设计能执行的规格。好 PRD 说清 Why 与 What，少管 How。与 /roadmaps/product-manager 需求节点对齐。

学习目标

背景与目标 — 为什么做、成功指标是什么
用户与场景 — Persona + 主路径
范围 — In Scope / Out of Scope（同样重要）
功能说明 — 分模块，含边界与异常
非功能 — 性能、安全、兼容性
依赖与风险 — API、第三方、法务
里程碑 — MVP vs 后续迭代

MVP 原则：最小可验证价值，不是「最小能跑」的半成品。

格式	适用
As a [用户], I want [能力], so that [价值]	功能型需求、B 端权限场景
When [情境], I want to [动机], so I can [结果]	探索动机、创新功能

Acceptance Criteria（AC） 必须可测试：

Given 用户已登录且未完成任何 lesson
When 打开 track 详情页
Then 显示「继续学习」按钮，跳转至上次 lesson 或第一课
And 7 日内再次访问仍保留进度

PM 提供 问题、约束、验收标准；工程评估 方案、工期、技术债。PRD 评审不是念文档，而是对齐 风险与切割方式（能否拆成两个 Sprint？）。

CodeRoadMap 示例：POST /api/tracks 已在线；新需求应写清与现有 API 的兼容性与迁移策略。

PRD 是团队的共同契约：目标清晰、范围有界、验收可测。 下一课进入路线图与优先级。