a-share-analysis/docs/governance/prd-standard.md

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. 发布范围：本次、后续和回退触发条件。
15. 安全需求与信任边界：资产、数据、访问边界、滥用场景和残余风险。
16. 性能目标与容量假设：延迟、吞吐、新鲜度、数据量或资源预算中的适用目标。
17. 关联模块与同步修改：可能影响的功能、契约、数据、缓存、进程、部署、测试和文档。
18. 新增依赖评估：用途、替代、安全、许可证、体积或运行成本、维护和退出方式。

3. 编写规则

• 需求使用 FR-001 等稳定编号，测试和 Review引用该编号。
• 禁止用“体验更好”“速度较快”等不可验证表达。
• UI 布局不是需求本身；应先写用户需要识别和完成的行为。
• PRD 发生实质变化时更新版本和变更记录，并重新确认设计与测试影响。
• 缺陷修复也必须说明用户可观察问题、受影响范围、同步修改和安全性能边界，不能只记录代码位置。
• 已发布 PRD 不删除旧结论，废弃需求标记 superseded 并说明替代项。