feat(GOV-002): 增加 PRD 与开发审查门禁

docs/governance/prd-standard.md

@@ -0,0 +1,34 @@
+# 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` 并说明替代项。