决策不靠吼，靠RFC和ADR——别再开会扯皮了！本文介绍用RFC和ADR做架构决策的流程，强调优先级排序替代简单利弊清单，异步评审加聚焦会议，避免无休止争论和文档无人读的悲剧。
写代码做决策就像选今天中午吃啥，随便拍拍脑袋就能定。但是做架构决策，那就完全不一样了，它就像决定你未来三年住哪座城市、跟谁结婚、要不要生孩子这种级别的终身大事。你选错了，后面几个月甚至几年都得哭着还债。
我自己就亲身经历过这两种极端。有一次，我在走廊里跟同事随口聊了两句，拍脑袋定了个技术方案，结果那个决定像个幽灵一样缠着我们团队整整半年，所有人都得加班加点重写代码，那感觉就像你随手扔了个香蕉皮，结果自己踩上去滑倒了，爬起来发现前面还有一百个香蕉皮在排队等你。
还有一次，我们团队花了好多天写了一份特别漂亮、特别详细的架构文档，图文并茂，表格齐全，所有人都觉得这次稳了。
结果呢？根本没人看。大家还是各干各的，最后做出来的东西跟文档里写的完全两样，跟没决策一个样，白白浪费了所有人的感情和时间。
那为什么架构决策这么麻烦呢？
因为它跟普通的代码决策压根就不是一回事。普通代码决策，你写错了，改两行代码，重新部署一下，分分钟搞定。
架构决策呢？你选了一个数据库，后面想换，那简直比离婚还难，数据迁移能把人折腾到怀疑人生。而且架构决策影响的人特别多，前端、后端、测试、运维、产品经理，甚至销售和老板都可能被波及。
更重要的是，架构决策从来不是纯粹的技术问题，它里面全是各种乱七八糟的权衡。比如说，你想让系统跑得快，那可能就得花更多钱买服务器。你想省钱，那可能就得接受系统偶尔卡一下。你想让代码好维护，那可能就得牺牲一点开发速度。
这些东西没有一个标准答案，全靠团队一起商量。所以你需要所有人都点头同意，你需要把对的人拉到同一个房间里，你还需要一个流程，这个流程不能变成那种开起来没完没了、大家都在讨论自行车棚颜色这种破事的会议地狱。
在我做技术顾问和自己带团队的过程中，我试过好多方法，最后发现下面这套流程是真的管用。
四步流程
这套流程的核心其实特别简单，就四步：先写RFC，然后让大家异步评论，接着开一个决策会议，最后写ADR。
RFC全称是Request for Comments，翻译过来就是征求意见稿。别被这个名字吓到，它其实就是一份文档，用来解释当前遇到了什么问题，你大概想到了哪些解决办法，然后邀请大家给你提意见。这一步是异步准备的阶段，你写文档大概花一到两天。
第二步是异步评审，给大家两到三天的时间去读文档、在评论区里吵架或者点赞。
第三步是决策会议，大家坐到一起，花个三十分钟到一个小时，把最终方案定下来。
第四步是写ADR，全称Architecture Decision Record，就是架构决策记录，把你到底定了啥、为啥这么定，白纸黑字写下来，永久保存。
这四步走完，你就能从一团乱麻中理出头绪，而且整个过程不会浪费太多时间。
咱们先说说第一步，写RFC。
这一步是最累的，也是最关键的，就像盖房子打地基一样，你前面偷懒，后面就得塌。写RFC逼着你自己先把问题想清楚，而不是稀里糊涂地把所有人拉进会议室，然后大家一起迷茫。我见过太多团队跳过这一步，直接开会，结果两个小时过去了，大家还在原地转圈，谁也不知道该往哪走。那RFC应该放哪儿呢？其实放哪儿都行，Confluence、Notion、Google Docs，甚至在一个专门的代码仓库里放个Markdown文件都行。关键是这个位置要固定，所有人都知道去哪里找，而且大家都能评论。我建议你建一个专门的文件夹，比如叫斜杠Architecture斜杠RFCs，然后给每个RFC起个好认的名字，比如RFC-2026-001-事件驱动架构，RFC-2026-002-数据库分片策略，RFC-2026-003-认证服务迁移。这样一眼就能看出是啥时候的事、啥主题。
那RFC里面具体要写啥呢？我给你一个模板，这个模板你直接复制粘贴就能用。注意看，这个模板里面的格式是给RFC文档本身用的，跟咱们这篇文章的格式不一样，你千万别搞混了。
RFC模板代码如下：
RFC: [标题] |
开放问题 |
复制完这个模板，你就有了一个RFC的骨架。但是注意，这个模板故意没用优点缺点列表那种老掉牙的格式，因为优点缺点列表基本是废话。我给你举个例子你就明白了。方案A写优点快、能扩展，缺点是没有权限管理。
除非大家一致同意快比权限管理重要，否则这个列表就是个摆设。不同的人读同样的列表会得出完全相反的结论，最后谁嗓门大谁赢，而不是谁的想法对谁赢。正确的做法是先定优先级，然后用优先级去衡量每个方案。比如优先级第一条是必须支持权限管理，那方案A连第一关都过不了，直接淘汰，根本不用讨论后面的事。当优先级排得清清楚楚，决策往往变得特别明显，大家争论的焦点也从模糊的权衡变成了实实在在的重要事项。这就是真正的共识建立方式。
写RFC的时候还有一个特别重要的事，就是艾特对的人。
你要艾特所有会被这个决策影响的人、所有有相关专业知识能帮你完善决策的人、所有对受影响领域有决定权的人，以及所有会动手实现这个方案的人。但是千万不要艾特全公司所有人，那样只会浪费大家的时间。你要具体一点，在通知里明确写出来：请在某个日期之前读完RFC并留下评论，我们将在某个日期开决策会议。你要让大家清楚你具体需要他们做什么，不是每个人都要深入分析每一个方案，有些人只需要从自己的角度看看有没有明显的障碍就行。
第二步是异步评审阶段。
给大家两到三天的时间去读文档和写评论。这一步是魔法发生的地方，因为异步评论让大家有时间思考，不用在会议里被当场逼着表态。大家可以去做研究，可以睡一觉再回复，这样产生的反馈质量比会议里临时想出来的高太多了。你要鼓励大家提澄清性的问题，比如这个方案遇到某个极端情况会怎么处理。也要鼓励大家提出担忧，比如这个方案可能会跟另一个项目冲突。还要鼓励大家提供额外背景，比如我们以前试过类似的东西，结果踩了某个坑。
大家也可以直接表达偏好，比如我倾向于方案B因为什么什么。甚至有人会提出完全没考虑过的新方案。作为RFC的作者，你要主动回复每一条评论，回答问题，承认合理的担忧，如果有人指出了你遗漏的点，你要及时更新RFC文档。这样在开会之前，你就已经跟大家在很多问题上达成了共识。
那如果没人评论怎么办呢？这种情况确实会发生。可能有几种原因。
第一种是这个决策其实没那么重要，那就不用走这么正式的流程，直接拍板就行了。
第二种是大家太忙了，没空看，那你就单独私聊那些人，说嘿，我在第三部分真的很需要你的意见。
第三种是你的RFC写得太长太复杂了，大家一看就不想读，那你就简化一下，在开头加一个太长不看版的摘要。
第四种是大家其实都同意，只是懒得说话，那你就直接问，同意的请加一。总之别让评论区空着，主动去推动。
第三步是决策会议。
现在进入同步讨论环节了。但是注意，这个会议绝对不是用来做演示的。每个人都应该在会前就读完RFC和所有评论，如果谁没读，那是他自己的问题，不是你的责任。我推荐的会议形式是工作坊模式，而不是演示模式。会议时长控制在三十分钟到一个小时，绝对不要超时。会议议程很简单，先花两分钟快速说一遍背景，我们今天就是要决定X，大家已经都读过RFC了。然后花十到十五分钟过一遍开放问题和没有解决的评论。接着花十五到三十分钟讨论各种方案，提出新的担忧。最后花五到十分钟做决策。谁应该来开会呢？RFC的作者主持会议，在评论区有过重要意见的关键利益相关者，还有最终拍板的那个人如果不是你自己的话。人数控制在五到八个人，最多不要超过八个。人一多，会议就变成了状态同步会，而不是决策讨论会。
那到底怎么拍板呢？
有几种方法。
第一种是全体一致同意，这是最理想的，但现实中很难做到。
第二种是全体无人反对，这个跟一致同意不一样，你不要求大家说这是我的最爱，你只要求大家说我能够接受这个结果，不会因此辞职或者罢工。
第三种是指定一个人做最终决定，这个人叫直接负责人，他听完所有人的意见之后自己拍板。
对于架构决策来说，这种方式往往是最好的，因为总得有个人对结果负责。第四种是投票，在小事情上可以用，但是投票容易制造赢家和输家，用多了团队氛围会变差。那如果实在达不成一致怎么办？也有办法。
第一种是升级到更高层，找上面的大老板或者经理来拍板，这不丢人，这就是领导该干的事。
第二种是限定时间，比如咱们先按方案A试三个月，三个月后再重新评估，不是所有决定都要做一辈子的。
第三种是做更多调研，如果大家争论的是事实问题，比如这个方案到底能不能扩展，那你就需要先做个原型验证一下再决定。
第四种是缩小范围，比如长期方案大家有分歧，但是第一步怎么走大家都没意见，那就先把第一步定了。
第五种是承认权衡，直接说出来你在乎速度，我在乎可维护性，那咱们看看在这个具体场景下哪个更重要。
无论如何，不要让分歧在那里发酵。没解决的架构决策会变成技术债务，因为不同的人会按自己的想法分头实现，最后拼都拼不到一起。
第四步是写ADR。
决策做完了，马上写文档。架构决策记录是你的永久档案，它跟RFC不一样，RFC是用来探索各种选项的，里面有很多讨论和不确定的东西，而ADR是用来记录最终拍板的结果的。ADR的模板特别简单，你直接复制下面这段代码就能用。
ADR模板代码如下：
ADR-[编号]: [标题] |
我个人的建议是，ADR一定要写得短小精悍。它们是给人查资料用的参考文档，不是长篇大论的学术论文。如果读者想要完整的上下文，你可以在ADR里面贴个链接指回原来的RFC就行。不过话说回来，怎么写ADR这事儿每个团队都有自己的习惯，你完全可以按你们团队的口味调整。
最后
决策做完了，文档写完了，这事儿就完了吗？远远没有。做决策只打赢了半场仗。一个理想的RFC里面应该包含一个具体的上线计划，不是说咱们回头就把它实现了这种空话，而是一条从现状走到目标状态的清晰路线图。很多架构决策失败，根本原因不是决策本身错了，而是实现路径不清晰或者步子迈得太大。大家反对大规模范式迁移，往往不是因为不认可方向，而是因为看不到怎么小步快跑地走过去。谁负责写这个上线计划呢？RFC的作者应该先起草一份，但是真正会动手实现的人，也就是团队负责人、架构师、技术负责人，他们应该来帮你打磨这份计划。只有他们才知道什么现实、什么不现实。把上线计划直接写进RFC里面，它本身就是决策的一部分，不是独立的实现细节。很多时候，这里收到的反馈反而是最重要的。
注意
那是不是每一个架构决策都需要走这一整套流程呢？当然不是，那样就太蠢了。我给你一个粗略的判断标准。
第一类，直接拍板就行，连RFC都不用写。这种情况包括只影响你自己团队的事、很容易撤销的事、改起来成本很低的事。
第二类，写个轻量级RFC就够了，只走异步评论，可能连会都不用开。这种情况包括影响两到三个团队的事、影响中等的事、有人可能会有意见的事。
第三类，需要走完整的流程，RFC加会议加所有利益相关者。这种情况包括跨领域的问题，比如安全、性能、成本，很难撤销的事，比如选数据库、定API接口，需要大量投入的事，需要申请预算或者招人的事。
第四类，需要高管介入。这种情况包括影响公司战略的事、预算影响巨大的事、跟外部供应商签合同的事、涉及合规或者法律的事。
对于那些真正的大决策，你可能还需要给领导层做个汇报摘要，但那跟技术决策会议不是一回事，那是去要预算和批准的，不是去争论技术权衡的。