技术方案评审框架（RFC 怎么写、怎么评）

一句话速记

RFC（Request for Comments）的目标不是”写出完美的方案文档”，而是在写代码之前，用最低成本暴露方案的缺陷和遗漏。写 RFC 的四个必须回答的问题：① 要解决什么问题（为什么现在必须解决）；② 怎么做（核心设计，不超过一页纸）；③ 为什么不那么做（不在方案里的备选方案 + 被拒绝的理由）；④ 变了什么（对现有系统的破坏范围 + 迁移 Plan）。评审时关注”这个方案会怎么失败”，而不是”这个方案好不好”。

通俗解释（5 分钟版）

RFC 的本质：在写代码之前花 1 小时写文档 + 大家花 30 分钟读 + 
开会花 45 分钟讨论 = 省掉写代码 2 周后发现方向错了重新做的痛苦

没有 RFC：
  一个哥们花 2 周写了一套方案，MR 提出来：
  审查者："你这个设计在 X 场景下会挂。为什么不直接 Y？"
  工程师："…我没想过 Y。"
  审查者："重构吧。"
  工程师：（内心崩溃，又要花 1 周重写）
  → 浪费了 3 周，团队矛盾 + 1

有 RFC 轻量流程：
  工程师花 1 小时写了一份 2 页的方案概要（RFC），发到团队群：
  "新需求的设计思路，大家帮忙看看有没有坑。"
  3 个人 async 评论了 5 条建议，其中有 2 条直接避免了架构陷阱。
  作者修改了方案，2 天后开始写代码。
  → 省了 2 周返工时间

关键细节

RFC 的结构

一份好的 RFC 应该在一页内解决大部分可预见的疑问：

1. 元信息（3 行）
   标题："RFC: XX 功能的方案设计"
   作者 + 日期
   状态：Draft / In Review / Approved / Rejected

2. 问题定义（3-5 行）
   - 解决什么问题？谁受这个问题影响？
   - 为什么现在要做？（做了能带来什么，不做的代价是什么）
   - 成功标准：怎么判断这个方案"达到了目标"？

3. 核心设计思路（半页）
   - 不是完整的架构文档，是"关键设计决策"
   - 数据怎么流（画一个简单的流程图）
   - 如果有接口变更，放接口定义
   - 如果有 DB schema 变更，放新表结构

4. 备选方案（至少一个，半页）
   "我们考虑了以下方案但没有采用：
    方案 A：XXXX
      优点：
      缺点：XXX 决定不采纳
    方案 B：同上"
   为什么这个部分重要：
     - 让审查者知道你想过其他路
     - 防止审查者提出一个你考虑过但已经排除的方案
       （节省至少 10 分钟的讨论时间）

5. 影响范围（3-5 行）
   - 这个改动会影响哪些现有功能？
   - 有没有 breaking change？
   - 迁移策略：一次性切还是灰度？

6. 风险（3-5 行）
   "这个方案最可能失败的三个方式是什么？"
   （如果作者自己说不出来风险 = 作者还没想清楚；
    如果能说出来 = 审查者可以帮忙评估风险程度）

评审 RFC 的方法

评审者的角色：

不是"我来挑毛病"，是"我来帮作者找到 TA 没看到的维度"。

评审的四个角度：
  1. 正确性：这方案在核心场景下能工作吗？
  2. 边界：极端/边缘/失败场景下呢？
  3. 影响：它会破坏什么现有的东西？
  4. 演进：3 个月后如果有新需求，这个设计还能容纳吗？
     还是需要推翻重来？

评审流程：

1. Async review（至少 1 天）
   作者发 RFC 到群里/文档里，审查者 async comment。
   不要在开会时才第一次看。

2. 同步讨论（45 分钟，可选）
   只在以下情况下开：
    - async 讨论出现了分歧
    - 方案确实复杂需要当面对齐
   如果 4 个审查者都没有在 async 阶段提任何问题 →
   不用开会了，直接 Approve。

3. Approve 标准
   方案不需要"完美"，只需要：
    ✓ 核心场景能 work
    ✓ 没有已知的导致线上事故的风险
    ✓ 未来 6 个月内不太可能需要推翻重来

什么情况下不需要 RFC

✗ CRUD 小功能——任何一个靠谱的 IC 都能独立搞定
✗ Bug fix——修 bug 不需要设计评审
✗ 配置变更——但如果是影响多个团队的配置，要通知

✓ 跨服务的新接口设计
✓ 数据库 schema 变更（特别是线上已有大量数据的情况）
✓ 引入新技术栈/新中间件
✓ 架构重构（改核心模块的实现方式）
✓ 影响安全/隐私的设计（需要安全同学 review）

延伸追问

• Q：RFC 应该写到多详细？ → 一页纸原则。如果审查者要花超过 15 分钟读完，太长——过于详细的方案里往往藏着”还没想清楚所以写很多细节来充数”的陷阱。越不确定的地方越要写详细（因为你最需要在那上面获得反馈），确定的地方一句话带过就行。
• Q：如果有人一直不 Review RFC 怎么办？ → 设一个 deadline。（“周五前给意见，没给默认为 No Objection”）。如果超过 3 次完全不 review，1on1 里问问是不是有顾虑或者沟通障碍。
• Q：RFC 被 Reject 了怎么跟作者沟通？ → 不要用 Reject 这个词。方案被拒绝 ≠ 人不行。说：“这个方案目前情况下风险大于收益。我们一起看看有没有其他路？“或者”这个方案在另一个时机/另一个前提下是可以的，但现在 XX 条件不具备”。

我的记法

• RFC 六个要素：元信息、问题定义、核心设计、备选方案、影响范围、风险
• 评审看四点：正确性、边界、影响、演进
• 不需要 RFC：CRUD、bug fix、简单配置
• 一页纸原则：15 分钟内读完 = 刚好；写成小论文 = 还没想清楚
• 一句话：「RFC 不是为了写完美的方案——是为了用最低成本在你还没写代码的时候暴露缺陷」

状态

• 已背速记
• 能讲通俗版
• 能答追问