做架构评审这些年，我最大的感受是：很多团队不是不会设计分布式系统，而是不会“审”分布式系统。设计文档写得花团锦簇，一上线就出问题；评审会开了一大堆，风险却一个没拦住。问题就出在评审这件事本身——大部分评审流于形式，变成“讲PPT + 走个过场”，核心维度的审查没有章法，风险追踪也没有闭环。
这篇内容我打算把分布式架构评审这件事彻底拆开来讲。从评审前要准备什么、评审中要审哪些核心维度，到风险怎么分级、怎么清零、怎么避免评审变成撕扯大会，全部用实操经验说话。这篇文章适合正在带团队做技术方案评审的架构师，也适合每一次都被评审“折磨”的后端开发，当然，如果你是刚接触分布式设计的新人，看完也能知道一个合格的评审到底长什么样。
1. 评审不是走过场：先搞清楚评审到底在审什么
1.1 评审和代码审查、设计走查的边界
很多团队把架构评审和代码审查混在一起，这是第一个误区。代码审查解决的是“代码写对了没有”，架构评审解决的是“系统设计能不能撑住业务场景”。一个方案就算代码写得再漂亮，如果服务拆分的边界错了、数据一致性方案选错了、容量评估拍脑袋了，上线后照样会出事。评审的视野必须放在整个系统的生命周期上。
还有一类团队把评审做成“设计走查”，也就是架构师拿着文档从头到尾讲一遍，下面的开发点头说“懂了”，然后散会。这种走查连评审都算不上，因为没有对抗性提问、没有维度化审查、没有风险分级。真正的评审应该像一场“技术质询”——每个与会者都有义务从自己的专业视角对方案发起挑战，而不是单纯听讲。
评审的对象也要分类。新建系统的架构评审、存量系统的架构改造评审、引入中间件或新技术的专项评审，这三类关注点完全不同。新建系统要审全局设计，改造项目要审兼容性和迁移路径，专项评审要审技术选型和参数配置。很多团队一套评审模板用到底，这显然是不合理的。
1.2 评审的三个层次：方案层、实现层、运行层
我习惯把评审拆成三个层次来看，这能避免“只见树木不见森林”。
方案层评审关注的是设计决策本身：为什么用这个中间件而不是那个？为什么服务边界这么划？为什么数据一致性选了最终一致而不是强一致？这一层要看的是权衡和取舍，方案没有绝对的对错，但必须有明确的技术依据和业务依据。
实现层评审关注的是细节落地的可行性：接口定义、数据结构、事务边界、幂等设计、缓存策略。这一层经常暴露“看起来很美但根本写不出来”的设计，尤其是那些不考虑框架限制和中间件能力的理想化设计。
运行层评审关注的是系统上线之后要面对的现实：容量能不能扛住峰值流量？出故障了能不能快速定位？数据最终一致性的窗口会不会让业务出现严重资损？有没有对应的监控告警和降级预案？很多评审会在这层翻车，因为方案在PPT上跑得很顺畅，一到真实环境就开始露馅。
这三个层次在实际评审中会交叉进行，但评审组心里必须清楚，你们当前讨论的是哪一层。混在一起讨论的结果通常是：方案层的争议拖到了实现层才暴露，运行层的问题根本没有人想到。
1.3 评审输入的完整定义与前置条件
评审不是拿着一页PPT就能开始的。在我的实践里，一份合格的评审材料至少要包含：系统现状或业务背景说明、核心指标目标（延迟、吞吐、可用性、成本）、架构总览图、关键流程时序图、接口和数据模型设计、容量预估及依据、风险登记表。
我特别强调“容量预估及依据”这一点。太多方案的容量评估写的是“预计日活100万，所以需要50个节点”，完全没有说清楚这个数字是怎么算出来的。日活100万对应的峰值QPS是多少？请求分布曲线什么形状？单机单核能扛多少QPS？这些不写清楚，评审就丧失了量化基础，后续所有判断都在空中楼阁上建。
材料齐备还有一个前置条件：评审材料必须提前交给评审组阅读。我见过太多团队上午发材料、下午开评审会，评审组成员连文档都没点开就坐在了会议室里。这样的会基本可以判定无效。我的经验是提前三到五个工作日发材料，评审会上直接讨论“问题清单”而不是现场通读方案。
2. 评审前必须做好的准备：清单、人员与节奏
2.1 评审清单不是模板堆砌，是按风险维度组织的检查项
网上能找到很多架构评审检查表，动辄一两百项。但实际评审中，一两百项根本过不完，而且大部分检查项针对的是特定场景，换个场景就失效。我不建议直接抄模板，更合理的做法是围绕几个核心风险维度，自己定制问题清单。
我的清单通常围绕六个风险域来搭：可用性与容错、性能与容量、数据一致性、安全与权限、可观测性与恢复、成本与演进。每个风险域下面准备五到八个关键问题，这些问题不是泛泛的“有没有考虑高可用”，而是必须能引出具体设计的。比如问“服务依赖的下游如果挂掉，系统会怎样”，比问“有没有做降级设计”更能得到真实信息。
清单不是用来念的，是用来查漏的。真正的评审高手，脑子里有这些维度，嘴上问的是具体的场景化问题，清单只是防止遗漏的辅助工具。
2.2 评审组怎么搭：角色混搭比全员到场更有效
评审组的构成直接决定评审质量。全员参与的评审会往往是最无效的，人越多越没人说话，技术负责人怕说错话丢面子，开发觉得自己没资格发表意见，最终变成了设计者自说自话。
有效的评审组应该控制在五到七个人，角色上尽量混搭。必须包含：方案设计者（通常是被评审的架构师或开发负责人）、资深的业务开发（负责从实现角度挑战方案）、运维或SRE（负责从运行角度挑战方案）、存储或中间件专家（如果方案涉及特定组件）、产品经理（负责确认业务需求理解是否到位）。我自己还会拉一个“没参与过这个项目但技术功底过硬的旁观者”，这类人没有包袱，往往一句话就能点醒梦中人。
我在某公司参与过一个分布式事务改造的评审，方案设计者花了半小时解释自研的最终一致性方案如何优雅。评审组里一位没参与过项目的老开发只问了一句：“如果消息库本身也分库了，那消息表的路由规则和数据一致性怎么保证？”全场安静。这就是旁观者视角的价值。
2.3 评审节奏和时机的把握
评审时机也很讲究。太早评审，方案细节都没定，评审组提的问题设计者根本接不住；太晚评审，代码都快写完了，评审提出的任何修改意见都意味着返工，双方情绪都会极度对立。
我倾向在“概要设计定稿”和“详细设计进行中”之间插入评审。这个时机的特点是：整体方向已经明确，细节还有修正空间。评审意见如果合理，改动成本可控，设计者也更容易接受。
整个评审流程我建议分成三个阶段：预审、正式评审会、风险清零跟踪。预审阶段由评审组核心成员（通常是两三个人）提前阅读材料并汇总问题清单，把低级问题和非关键问题过滤掉。正式评审会聚焦于预审发现的核心争议点，逐项过。风险清零跟踪则是在会后通过文档和短期复查确保每一项风险都有明确的整改动作和截止时间。
3. 七个核心维度：分布式架构评审必须逐一过掉的检查项
3.1 可用性与容错设计
可用性审查最先要看的是依赖拓扑。分布式系统的可用性，本质是“最弱依赖的可用性”。我会让设计者画出系统运行时依赖的所有组件——数据库、缓存、消息队列、下游服务、外部API——然后逐个追问：如果这个依赖挂了，系统会怎样？
这里有一个典型的反模式：所有依赖都是强依赖，所有故障都会导致核心链路不可用。优秀的方案会明确区分强依赖和弱依赖，并为弱依赖准备降级路径。比如推荐服务挂了，主流程应该能跳过推荐逻辑继续完成下单；比如用户画像服务超时了，页面应该降级展示默认内容而不是报错。
超时和重试配置也在容错审查范围内。我见过用默认超时配置跑核心链路的系统，下游慢了一个量级，整个线程池都被拖死。重试次数和重试间隔更不能随意拍，尤其要警惕“重试风暴”——A超时重试B，B超时重试A，两边互相放大压力。
还要审故障隔离和故障恢复。物理隔离（分组、多机房）、逻辑隔离（线程池隔离、信号量隔离）各有没有覆盖？进程挂掉之后流量怎么切换？缓存重建的时候怎么防止雪崩？这些不是靠经验就能回答的，必须看设计者是否做了故障演练、有没有把演练中暴露的问题回写进方案。
3.2 性能与容量规划
性能评审如果没有数据支撑就会变成吵架大会。设计方案必须先定义清楚性能目标：TP99延迟、P99延迟、平均延迟、吞吐量、错误率。目标不明确，后面所有的优化和容量计算都没有基准。
容量规划方面，我要求设计者给出有依据的推导过程。从业务量预估峰值QPS，从峰值QPS和单机吞吐能力推算节点数。很多团队在单机吞吐能力上没有实测数据，全凭感觉，结果不是过度浪费资源就是上线被流量打爆。没有实测数据的时候，宁可按偏高估算，然后预留横向扩容通道。
性能评审还必须看热点和瓶颈。分布式系统最怕的不是平均负载高，而是热点集中。某个高频数据的缓存被穿透、某个分片的数据量远超其他分片、某个Redis实例背后的热key导致分片倾斜——这些都是评审时需要专门发问的地方。设计者如果对这些场景没有应对策略，方案就不能算完整。
3.3 数据一致性与分布式事务
一致性评审是评审中最容易吵起来的环节。核心原因是“一致性”本身有很强的业务语境差异。评审时首先要确认的是：业务到底需要多强的一致性？用户下单后立即查看订单状态，看到的延迟可接受范围是多少？跨服务的数据同步容忍多久的延迟？
明确了业务需求之后，再来审技术方案。缓存与数据库的一致性怎么保证？先更新库再删缓存，还是先删缓存再更新库？消息队列里的数据最终一致，是幂等消费还是事务消息？这些方案都有场景限制，评审任务不是选“哪个技术最牛”，而是确认“这个方案在你的场景下是否成立”。
分布式事务的评审我一直很谨慎，因为它的理论基础和技术实现之间存在很大的鸿沟。两阶段提交（2PC）真的适合你的并发场景吗？SAGA的补偿逻辑有没有人力和机制来保障？本地消息表方案会不会造成消息积压或者重复消费？我会专门安排一个环节，让设计者逐条讲清楚异常场景下的数据流向——任何一条链路讲不清楚，这个方案就需要再消化的时间。
3.4 安全与权限边界
安全维度经常因为“过于基础”而被评审忽略，这恰恰是最不应该忽略的。分布式系统把原来单机内的信任边界拉大了很多，服务间通信、数据访问、权限管理都是安全攻防的战场。
服务间通信的认证和鉴权必须审清楚。服务A调用服务B，B凭什么相信A？有没有统一身份认证方案？token的颁发和校验机制是什么？密钥怎么管理和轮换？很多团队在内部网络里不做服务间认证，等出了问题再补，代价就会非常大。
数据权限也要审。用户只能访问自己的数据，这个在单体系统里靠session和SQL条件就能实现，但到了分布式环境下，跨服务的权限判断经常出现漏洞。我做过一个评审，服务A负责订单，服务B负责支付，B的接口只校验了“支付单号存在”，没有校验“支付单号属于这个用户”，结果就是一个越权漏洞。这类问题的根源不是编码失误，而是设计阶段的边界定义不清。
3.5 可观测性与故障恢复
可观测性是被评审方案里最常被敷衍的部分。设计者会在文档里写“接入全链路追踪、配置Prometheus监控”，但细问下去，监控指标有哪些、告警阈值怎么设、日志规范是什么、链路追踪的采样率怎么定，全都语焉不详。
评审时我会要求设计者把核心链路的监控方案写细：每个服务的黄金指标（请求量、错误率、延迟）怎么采集和展示？有没有依赖组件的监控面板？告警是否分级别设置，紧急告警和普通告警的路由分别是什么？链路追踪是否接入，采样策略有没有兼顾性能和诊断需求？
日志维度也必须审。分布式系统排查问题的第一步是日志检索，如果各服务日志格式不统一、链路ID不传递，故障排查基本就是大海捞针。诊断我们做一次线上故障复盘，定位花了三个小时，其中有两个小时在翻各服务各自的日志格式，反复对齐时间戳和业务ID。这种成本完全可以靠设计阶段的日志规范来消除。
故障恢复能力也需要在评审中验证。假设核心数据库不可用了，多久能恢复？备库切换是自动还是人工？数据丢失的容忍上限是多少？恢复操作有没有预案、有没有演练过？这些问题没有明确答案，可用性目标就无从谈起。
3.6 成本与资源效率
成本和资源效率在业务快速迭代期经常被忽视，但在评审里应该是必须过的一道关卡。分布式架构的伸缩性带来了非常大的资源开销，同样一个需求，在单体架构里可能只需要加一台机器，但到了微服务架构里要新增服务、数据库、缓存、消息队列，成本成倍增长。
评审时我会让设计者预估硬件资源的月度成本，虽然预算数字不一定精确，但推导逻辑（流量预测→容量估算→实例数→单价）如果清晰，成本结构就能一眼看清。特别要警惕“每个服务都搞一个独享库”这种方案，数据库实例数量膨胀得太厉害，运维成本和资源浪费都会失控。
冷热分离和多级存储也是成本评审的重要内容。有的数据放在了高配数据库里，实际上一个月都查不了一次，这不光浪费成本，还会拖累核心数据表的性能。归档策略、TTL清理机制、冷热存储分层方案，都应该在评审阶段明确，等数据飞涨之后再回补就晚了。
3.7 演进性与技术风险
最后一个维度，也是最难量化的维度：这套架构能不能扛住未来的变化。评审时我会问几个方向性的问题：如果并发量涨五倍，这个方案需要做哪些改动？如果新增一类业务场景，架构的扩展点是哪些？如果某个核心技术组件被迫替换，迁移成本有多高？
技术风险还包括对新技术和自研方案的评估。分布式系统领域很多组件是开源社区驱动，版本迭代快、上游变化不可控。选型时有没有锁定版本？有没有在非核心链路做过灰度验证？有没有考虑组件停止维护的备选方案？这些问题在评审阶段答不出来，以后都会成为运维阶段的坑。
我记得有一次评审引入了某个较新的调度方案，评审组里一位问了一句：“如果这个开源组件半年不更新了，我们的系统能等吗？”设计者沉默了。后来我们决定构建一层薄的封装，把对具体组件的依赖降到最低。这是演进性维度的典型价值——不是否认新技术的价值，而是给技术变化留有缓冲带。
4. 评审流程怎么落地：从预审到风险清零
4.1 预审过滤：把评审会的时间留给真问题
预审是整个流程里性价比最高的阶段。核心评审成员提前两三天读完材料，各自列出问题清单。我对团队有一个要求：问题必须分类，分为“必须会上讨论的设计争议”“会前可以自行确认的事实问题”“明显笔误或者材料不完整的问题”。第三类直接会前反馈给设计者修正，第二类由评审组成员私下沟通确认，只有第一类才拿到正式评审会上讨论。
这样做的效果非常明显。正式评审会的时间从原来的两三个小时压缩到一个小时左右，而且这一个小时全部在推进度、解决真问题。不是让评审沦为“念材料大会”，而是让评审成为“决策大会”。
预审阶段还要做一件重要的事：确认评审目标。设计者希望通过评审解决什么争议？评审组关注的最高风险点是什么？这两个问题如果不在会前对齐，会上就会出现方向性漂移——大家讨论了半小时才发现讨论的根本不是同一个问题。
4.2 正式评审会：流程、规则与控场技巧
正式评审会的流程，我推荐按“先总后分再总”推进。先用十五分钟由设计者快速过一遍整体方案，不建议详细介绍，因为材料已经提前发过。然后按风险维度逐项讨论，每个维度由该领域的评审成员主导提问。最后留二十分钟做综合总结，明确每一项专题结论和风险归属。
评审会最让我头疼的不是技术问题，而是会议规则缺失导致的失控。我定了几条硬规矩：第一，不讨论“无关的架构理想”，一切评审基于当前业务场景；第二，不带情绪，所有“这个方案肯定不行”的观点必须附带替代方案；第三，不翻旧账，线上已有的问题在对应专题里集中讨论，不在设计讲解中反复打断。
控场技巧也很重要。当两个核心技术观点僵持不下时，我会引导双方把分歧点具体化——是这个技术选型不匹配，还是参数配置不合理，或者是团队能力不足？把问题细化之后，很多僵持自然化解。还有一个技巧是“记问题板上墙”，把未决问题、争议点、责任人和下一步动作用白板写清楚，避免会议结束时大家在“到底下一步干什么”上有分歧。
4.3 风险分级与清零：闭环的核心
评审的价值不在“开完会”，而在“风险清零”。每次评审结束后，我会要求设计者输出一份风险登记表，每一行记录一个风险条目，包含：风险描述、风险等级、影响范围、整改动作、责任人和截止时间。
风险等级我习惯用三级分法：
- P0级别的风险必须立即阻断，不整改不上线。通常包括严重的数据安全漏洞、无法降级的核心链路单点、容量评估明显不达标的场景。
- P1级别的风险要求在一定时间内整改完成，给出明确的Deadline和复查机制。这类风险常有变通方式，比如先上线但预设降级开关，或者先用简化方案过渡。
- P2级别属于“已知但可接受”的风险，明确记录下来并约定后续优化时间窗口。这类风险不强制阻塞上线，但必须有人持续跟进。
风险清零不是写个登记表就完了，真正的机制在于复查。我会要求设计者在整改完成后主动回填风险状态，评审组则组织一次简短的复查会议，确认整改效果而不是只看报告。这个闭环机制坚持半年后，团队的评审文化就会发生根本性变化——大家意识到评审不是“找茬”，而是“帮助系统在迈入生产环境之前变得更强”。
4.4 评审报告怎么写才能有决策价值
评审报告不是评审记录的简单整理。一份有价值的评审报告，核心是输出明确的决策项，我通常按三段式来写。
第一段写评审结论概览，包括：方案是否具备可行性的总体判断、必须整改的P0/P1风险列表、遗留争议事项及后续推进主体。这一段的受众是技术决策者，他们不需要细节，只需要知道“能不能用、有什么风险、谁去整改”。
第二段写风险详表。每条风险附上问题背景、讨论过程中提出的关键质疑、最终达成的共识、整改动作与责任人。这一段是评审过程中所有智力输出的沉淀，也是后续复查的依据。
第三段写技术决策备忘录，用来记录评审中达成的重大技术选型和设计约定。比如“确认了服务化拆分边界边界切割方式”“确认了分布式事务采用SAGA方案”“确认了缓存更新顺序为先更新DB后删除缓存”。这些决策是团队后续大量开发的输入，必须写得足够精确，避免后续理解分歧。
我见过太多团队评审报告写得比设计文档还长，但看完不知道要做什么。评审报告的使命是帮助人和项目做决策，不是存档。
5. 评审中踩过的坑和实战修复方法
5.1 评审沦为“人月神话”——直接给方案评级而不是给建议
尤其多出现在高标准、高压的团队里。评审组最容易犯的一个错，是拿“理想架构”去对照“被评审方案”，然后列出长长一串“差距清单”。这种方式的后果是设计者得到极大的挫败感，整改方向也不清晰——因为“差距”不等于“风险”，很多理想架构在原方案的实际场景里根本没有必要。
整改方式是我总结了这样一个原则：评审组给结论时必须区分“必须整改”“建议优化”“可接受，但记录在案”三个档次，每一条建议都要说清楚为什么。用某次消息队列选型评审为例，当时对比了RocketMQ和Kafka，RocketMQ在事务消息上确实更成熟，但我们最终保留Kafka方案，理由是这个场景的消息丢失容忍度很高，顺序性要求也没有那么严，Kafka的吞吐优势和生态优势更有价值。所以核心不是使用哪个中间件，而是用清晰的业务理由来支撑决策。
5.2 设计者“防御性过强”，评审变成对抗
有一次评审，被评审对象是团队里非常资深的开发，方案设计也很完整。但在评审会上，他习惯性地反驳每一个问题，哪怕问题只是常识性质疑。结果评审组其他成员越来越沉默，会后反馈质量也大幅下降。
后来我做了一个调整：在评审会开头，我明确一句“本次评审的目标是：找漏洞、补缺口，不考虑面子和权威性”。这句话听起来简单，但确实能有效切换氛围。再后来，我把评审组和设计者的关系定位成“共同在评审中设计加固方案”，而不是“专家审视方案”——这不仅是心理疏导，也能激发出更强的合作精神。
遇到特别固执的设计者时，还有一个小技巧：先肯定方案中确实合理的部分，再进入质疑环节。这不只是沟通技巧，而是建立在真实认知基础上的策略——大部分方案肯定有一些可取之处，先把共识点钉住，分歧部分再逐一击破，效率和氛围都会好很多。
5.3 “伪风险”挤占了评审时间，真实风险却被忽略了
伪风险是指那些听起来很严重、实际上在当前场景下不会出现的风险。比如讨论一个内部管理系统的架构评审时，有人反复追问缓存是否会面临极端热点访问，显然这超出了业务的实际场景。这类伪风险如果得不到及时识别，会议时间就会被大量消耗，核心问题反而没时间聊。
我惯用的应对策略是定义风险必须“能回答以下三个问题”：一是业务场景里什么条件会触发这个风险？二是万一触发，业务影响是什么？三是当前方案离触发条件是否还有很长的安全距离？回答不了这三个问题的，一律视为无效风险，拉出清单不谈。这个策略实施后，评审会的讨论密度和效率都有了明显提升。
5.4 风险清零流于纸面，整改无人推进
这是闭环环节最大的敌人。很多评审材料写得漂亮，登记表也填得完整，但一两个迭代之后，那些P2级别的风险就再也没人提起了。
我采用的机制是“风险逾期自动升级”。登记表里每一条风险都有对应的负责人和截止时间，如果截止时间到期风险仍未关闭，会自动同步给研发负责人。这种机制不一定需要复杂的管理系统，一个共享的在线表格加一个定时提醒脚本就能实现，团队规模不大的时候，表格加邮件通知就够用。
还有一个务实的经验：P2级别的风险不要强求当次迭代关闭。技术团队的工作容量是有限的，如果把所有风险都压在同一批次整改，既会拖慢正常迭代，也会让团队对风险管理制度产生反感。更现实的做法是把P2风险写进下个迭代的计划池里，跟业务需求一视同仁地竞争优先级，只要保证“不会无限期拖延”就行。
5.5 评审中“沉默的大多数”和信息不对称
一场评审会里，经常出现只有两三个人在讲话、其余人全程沉默的情况。这不代表其他人没有看法，而是有些人不好意思当众质疑，有些人担心问题太基础显得自己没水平，稍微内向一些的成员更是很难插话。
我做过一个改动：正式评审会之前，评审组先收集所有成员的书面问题和疑虑，匿名汇总后发给设计者。书面问题往往质量更高，因为写下来之前需要思考得更清楚，而且匿名会降低表达顾虑。正式会上再针对这些书面问题逐一回应和展开，效果比现场开麦好很多。
这一招在跨团队评审里尤其适用。涉及多个服务团队的架构调整，各方在上下文理解上天然有差异，书面预收集能提前拉动信息对齐，正式会也就不会浪费在互相解释背景上。
6. 这条路上还需要留意的几件小事
6.1 评审不只是技术活动，更是团队的信任建设
评审做得不好，会让设计者觉得“被审问”；做得好，会让整个团队觉得“我们的设计是经过认真思考的”。我见过好几个团队，从最开始评审时的戒备心很强，到后来主动要求“帮忙评审一下新方案再上线”，这背后是信任的建立。终于有一天，一位开发跟我说：“评审过之后上线，心里踏实多了。”这句话比任何KPI都有说服力。
想达到这个状态，关键是评审输出必须建设性。同样是“方案做得不好”，一个团队会收到“你这样设计不行”，另一个会收到“你这里的目标是X，我建议从Y角度考虑，A路径或B路径可能更合适”。后者的方式对团队激励和技术成长的价值是完全不同的。
6.2 评审文化的形成需要长效投入
营造良好的评审文化不是开一两次会能搞定的。新成员的加入会不断冲淡已有的评审节奏和规范，所以机制比个人更可靠。一套轻量级的评审指引（说清楚流程、清单和输出要求）比什么都管用。有了机制，即使具有核心评审能力的人短暂缺席，评审的整体质量也不会大幅下滑。
另外也要考虑评审的投入产出比。如果每次改建都走完整的大型评审流程，团队会因流程繁重而疲劳。我已经形成了“大评审”和“小评审”的双轨机制：新建系统和高风险改造走全流程的正式评审，低风险的小改动走轻量的快速评审。机制太重的必然结果是被团队成员用脚投票选择绕过。
6.3 架构评审的未来：从评审到持续演进的伙伴关系
最后说一点更宏观的感受。架构评审发展到今天，越来越不像一次性的“关口检查”，而更像架构治理的日常组成部分。系统上线之后，每个迭代都在改变系统的结构和行为，如果这些改变没有经过同样的审视，那么上线前的评审终将被时间腐蚀、被变化架空。
我现在更愿意把评审理解成“以评审会为节点、以风险追踪为连续性动作的端到端机制”。系统在演进，评审也在演进，两者共同构成质量保障的底色。真正健康的团队，不只是“上线前评审合格”，而是“每一次变更都带着设计和风险意识往前走”。这个过程很漫长，但对系统长期健康的回报也是实实在在的。
