35 lines
1.7 KiB
Markdown
35 lines
1.7 KiB
Markdown
# PRD 编写规范
|
|
|
|
## 1. 定位
|
|
|
|
PRD 是每个业务功能的产品需求事实来源，回答“为谁解决什么问题、为什么做、做到什么程度算完成”。技术设计回答“如何实现”，不能替代 PRD。
|
|
|
|
治理、重构和纯技术任务也需要简化 PRD，用于说明使用者、治理问题、目标和完成标准。
|
|
|
|
## 2. 必备章节
|
|
|
|
每份 `prd.md` 至少包含：
|
|
|
|
1. 文档信息：功能编号、版本、状态、作者、日期。
|
|
2. 背景与问题：当前状态、具体问题和证据。
|
|
3. 目标用户与场景：谁在什么时点使用。
|
|
4. 产品目标：用户能够完成什么，产品改善什么。
|
|
5. 非目标：本期明确不解决什么。
|
|
6. 用户流程：入口、关键步骤、结果和异常路径。
|
|
7. 功能需求：编号、优先级、行为与可观察结果。
|
|
8. 数据与口径：来源、时效、单位、缺失和过期处理。
|
|
9. 状态与异常：加载、空、部分数据、错误和降级。
|
|
10. 权限与合规：访问边界、隐私、声明和安全限制。
|
|
11. 成功指标：可以观测和验证的产品指标。
|
|
12. 验收标准：使用 Given/When/Then 或等价可测试描述。
|
|
13. 风险与依赖：外部数据、技术、成本和上线依赖。
|
|
14. 发布范围：本次、后续和回退触发条件。
|
|
|
|
## 3. 编写规则
|
|
|
|
- 需求使用 `FR-001` 等稳定编号，测试和 Review引用该编号。
|
|
- 禁止用“体验更好”“速度较快”等不可验证表达。
|
|
- UI 布局不是需求本身；应先写用户需要识别和完成的行为。
|
|
- PRD 发生实质变化时更新版本和变更记录，并重新确认设计与测试影响。
|
|
- 已发布 PRD 不删除旧结论，废弃需求标记 `superseded` 并说明替代项。
|