本文目录导读：
设计文档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流程的本质是：先写下来，让所有人想清楚，再动代码，它是一个“慢思考、快行动”的决策过滤器。
如果你想落地RFC流程,建议先从一个具体项目开始试点（例如一个API重构），写一份符合模板的RFC，强制要求5天评论期，然后全员复盘改进流程本身，逐步让团队习惯这种“文档驱动”的协作方式。
