架构评审应当是持续性的
传统的架构评审很彻底、很昂贵，每个季度顶多进行几次。问题在于，架构决策每天都在发生——在拉取请求、配置更改和依赖更新中。
为什么门禁式评审无法扩展
门禁式评审是为“变更成本高昂”的世界设计的。你在前期做评审，是因为事后改方向代价很大。这个假设正在瓦解。AI 使得持续验证架构成为可能，而无需为每一次变更都设立人工评审委员会。
持续验证是什么样的
一个持续性的系统会对照你的架构标准检查每一次变更。它在决策发生的那一刻——而不是几周之后——就在 PR 中标出违规。它会追踪随时间的漂移，并浮现出反复出现的违规，从而提示某条标准需要更新。
人类架构师专注于设定标准、审阅例外情况并做出判断。AI 负责持续监控。人类不再是守门人，而开始成为系统设计者。
从哪里开始
挑一条你的团队最常违反的架构标准。把它编码成一条评审规则。将其应用于每一次相关变更。看看当违规在 commit 时就被捕获、而不是等到评审时才被发现，会发生什么。结果将是更干净的架构、更快的评审，以及把时间花在架构上而非守门上的架构师。
周期性评审的问题
周期性架构评审有一个根本缺陷。它们只评审人们记得提交上来的决策。危险的决策恰恰是那些没被评审的——看似无害的配置更改、引入新模式的依赖更新、跨越责任边界的 refactor。
持续性评审能抓住这些问题，因为它不依赖人类对“哪些重要到需要上报”的判断。它用同样的标准检查一切。大多数变更都没问题。有问题的会被标出来。架构师只需审阅例外，而不是全部。
这对团队文化的影响
转向持续性架构评审的团队报告了一个意想不到的好处。工程师开始更仔细地思考架构，因为他们知道每一次变更都会被检查。重点不是抓违规，而是建立意识。当工程师知道架构标准在 commit 时就会被执行时，他们会更快地内化这些标准。
结果是随着时间的推移违规越来越少，不是因为系统抓得更多，而是因为工程师学会了好的架构长什么样，并自然而然地构建它。这是任何评审流程都无法企及的更好结果。
持续性评审的真正 ROI
我见过的采用持续性架构评审的团队，都一致报告同样的好处。架构违规更早被捕获。评审周期缩短。架构师把更多时间花在架构上，更少花在守门上。
但最大的好处更难衡量。团队因为有了持续反馈而做出更好的架构决策。他们学得更快。他们培养了架构判断力。久而久之，违规率下降不是因为系统抓得更多，而是因为工程师已经内化了这些标准。
这才是真正的 ROI。不是更快的评审——而是更好的工程师。