设计文档RFC流程如何运作

本文目录导读：

1. 第一阶段：发起与起草
2. 第二阶段：公开评议
3. 第三阶段：决策与批准
4. 第四阶段：实施与跟踪
5. 第五阶段：回顾与归档
6. 成功RFC流程的关键原则
7. 常见误区
8. 总结一句话

设计文档RFC（Request for Comments，请求评议）流程，是一种在技术团队（尤其是软件开发、基础设施、架构团队）中广泛使用的协作决策机制，其核心目标是在实施重大变更前，通过结构化的文档和公开评议，达成共识、暴露风险、记录决策。

以下是RFC流程的典型运作步骤,分为五个阶段，不同公司（如Google、Amazon、Mozilla）的流程细节不同，但核心逻辑一致。

第一阶段：发起与起草

识别需求

• 当有新的功能、架构重构、API设计、流程变更或技术选型需要跨团队评审时，发起人（通常为工程师或技术负责人）决定撰写RFC。
• 触发条件：涉及重大影响、不可逆决策、跨团队协作、或具有争议性的方案。

撰写RFC文档

• 使用模板：团队应有一个标准模板，通常包含以下章节：
  • 元数据：作者、状态（草稿/审议中/已通过/已拒绝）、创建日期、更新历史。
  • 摘要：用一两句话概括本RFC要做什么。
  • 背景与动机：为什么需要这个变更？当前问题是什么？没有这个变更会怎样？
  • 目标与范围：明确要达成什么目标（非目标也要写清，防止范围蔓延）。
  • 详细设计：技术方案、系统架构图、数据流、接口定义、关键算法。这是核心部分。
  • 替代方案：解释了为什么要选这个方案，而不是其他方案（比如为什么不用A技术而用B技术）。
  • 副作用与风险：性能影响、安全风险、兼容性问题、回滚方案、运维成本。
  • 实施计划：分几步走？预计时间表？依赖哪些前置条件？
  • 向下兼容性：是否破坏现有API？需要数据迁移吗？

提交与通知

• RFC文档被放入团队约定的位置（如：项目根目录下的 /docs/rfcs/、Google Doc、Confluence、GitHub Pull Request）。
• 发起人通过邮件、Slack或项目管理系统通知所有相关方“请求评议”。

第二阶段：公开评议

默认评论期

• 时间窗口：通常为 3-7个工作日（根据项目紧急程度和复杂度调整）。
• 异步讨论：所有参与者通过评论（如GitHub评论、Google Doc批注、邮件组）提出意见。
• 关键提问：
  • “这个方案是否解决了根本问题？”
  • “是否有更简单的实现？”
  • “这里忽略了边缘情况吗？”
  • “这个设计对下游系统的影响是什么？”

作者回应与修订

• 作者需要积极回应每一条有价值的评论（“已采纳”、“已拒绝并提供理由”、“需要讨论确定”）。
• 根据反馈,作者对RFC进行修订（更新文档、调整方案、补全细节），并标注修订版本（如 v1 -> v2）。

同步会议（必要时）

• 如果讨论陷入僵局或评论过多,可以发起一次线下或线上会议，会议前必须所有人已阅读文档。
• 目的：解决争议点，而非重读文档，会议得出结论后需更新到RFC中。

第三阶段：决策与批准

决策者审批

• 每个团队或项目应明确一位决策者（通常为技术主管、架构师或项目负责人）。
• 决策者阅读最终版RFC,确保：
  • 所有重大问题已被讨论和解决。
  • 方案在技术上可行,且风险可接受。
  • 有足够的资源和时间表。
• 三种结果：
  • 批准（Accepted）：按计划实施。
  • 拒绝（Rejected）：理由写入文档。
  • 搁置（Deferred）：当前优先级不够或有外部依赖，暂不实施。

状态更新与公告

• RFC的元数据状态被更新（如从 Draft 改为 Accepted）。
• 在全团队范围内宣布结果（人人可见，不仅仅是参与讨论的人）。

第四阶段：实施与跟踪

开发与实现

• 获批的RFC作为“技术合同”指导开发。
• 如果实施过程中发现设计缺陷,发起人必须发起RFC修订（而不是偷偷绕过），流程进入“补充评议”阶段。

代码审查与测试

• 代码审查（Code Review）必须引用RFC文档编号或链接，对照设计检查。
• 单元测试、集成测试、性能测试均需覆盖RFC中提到的风险点。

第五阶段：回顾与归档

事后回顾（Post-mortem）

• 项目上线后一段时间（如一个月），团队开会对照RFC评估：
  • 实际结果是否达到预期？
  • 有哪些意料之外的问题？
  • RFC流程本身有什么可以优化？（评论期太短？模板缺漏项？）

归档为知识库

• 所有RFC（包括被拒绝的）被永久保留，它们是有价值的决策日志：
  • 新人可以看到“为什么选了这个方案”。
  • 未来遇到类似问题时,可以参考旧RFC。
  • 维护一份“RFC目录”索引，方便搜索。

成功RFC流程的关键原则

常见误区

• 过度设计：在RFC中试图解决未来所有可能的问题，导致文档庞大、评审困难，建议按“最小可行改变”来写。
• 绕过评审：认为自己的方案绝对正确，不认真回复提问，破坏流程公信力。
• 决策权不明确：所有人都可以提意见，但最终需要有一个技术决策者拍板，否则容易陷入“议而不决”。
• 文档与实际脱节：代码仓库中的实现与RFC描述严重不符，导致后续维护混乱。

总结一句话

RFC流程的本质是：先写下来，让所有人想清楚，再动代码，它是一个“慢思考、快行动”的决策过滤器。

如果你想落地RFC流程,建议先从一个具体项目开始试点（例如一个API重构），写一份符合模板的RFC，强制要求5天评论期，然后全员复盘改进流程本身，逐步让团队习惯这种“文档驱动”的协作方式。