PRD vs RFC
何时写产品需求文档 vs 工程意见征求。
为什么
PRD 和 RFC 解决不同问题，用错浪费所有人时间。PRD 回答"该造什么、对用户为什么"——产品拥有、聚焦用户结果。RFC 回答"技术上该怎么造"——工程拥有、聚焦架构。为产品问题写 RFC 产出忽略用户价值的技术文档；为技术问题写 PRD 产出 PM 不该拥有的实现处方。知道用哪个能防止 PM 写技术 PRD、工程师写产品味 RFC 的常见失败。
何时使用
问题关于用户价值/行为时用 PRD；关于架构/实现时用 RFC。决定用哪个 10 分钟。大特性可顺序都用。
如何做
1. 问："未知是关于用户需要什么，还是怎么造？" - 什么 → PRD（产品拥有，用户结果） - 怎么 → RFC（工程拥有，技术设计） 2. 大特性顺序都用： a. 先 PRD——定义什么和为什么；获干系人签字 b. 后 RFC——提满足 PRD 的技术方案；获工程签字 c. ADR 记 RFC 的已接受决策 3. 保持它们是互相链接的独立文档 - PRD 不应处方"用 Kafka"；RFC 不应定义"注册转化目标" 4. PRD 是 RFC 的输入，而非反过来
示例
特性：发布说明实时协作 PRD（产品拥有）： - 问题：两个 PM 编同一发布说明，后存覆盖丢工作 - 需求：并发编辑合并不丢数据 - 指标：零"我的编辑去哪了"支持工单 RFC（工程拥有，链 PRD）： - 提议：CRDT 编辑器（Yjs）vs OT（ShareDB）vs 后写胜+diff - 权衡：Yjs（复杂、无服务端鉴权）vs ShareDB（需服务端、更简单） - 推荐：ShareDB——契合 鉴权模型，团队有 OT 经验 ADR-0015：协作编辑采用 ShareDB（链 PRD + RFC）
常见问题
- ⚠写一份混产品和技术的巨文档——太长没人读，归属不清。
最佳实践
- ✓PRD 和 RFC 双向链接，让读者能从用户问题追到技术决策。
- ✓RFC 评审限时 1 周；拖一个月的 RFC 失去动量，技术上下文在底下变了。