为什么每次架构评审都应该从 AI 开始
大多数架构评审遵循一种可预测的模式：有人提出方案，人们根据自己的经验提问，观点被争论，最强有力的声音或最高头衔获胜。
当系统简单到任何有经验的工程师都能推理它们时，这种流程行得通。但当一项方案可能影响十六个服务、三条数据管道、两个外部 API，以及一条没人记得存在的合规边界时，它就行不通了。
AI 改变了架构评审可以是什么样子。评审不再依赖碰巧在房间里的人以及他们记得的东西，而是从事实开始。
那些事实长什么样
在任何人提出观点之前，AI 先浮出客观的约束条件：这个改动会触及哪些服务？它们当前的故障率是多少？有没有与此方法相冲突的历史架构决策？这会引入哪些依赖？这些依赖的可靠性记录又如何？
我见过一个团队花了四十五分钟争论该用 Kafka 还是一个更简单的消息队列。激烈的讨论围绕吞吐量、延迟和运营开销展开。终于有人让 AI 去查一下。AI 返回了实际的消息量、团队运营每个系统的经验，以及与这两项技术相关的三次过往事件。争论不到一分钟就结束了。事实摆上桌面后，答案显而易见。
这些事实不会替你做决定，而是给你一个做出更好决定的基础。
为什么开场问题很重要
评审会议中的第一个问题设定了框架。如果问题是“你为什么想用这项技术？”，评审就变成了关于技术偏好的争论。如果问题是“这里适用的已知约束和历史决策有哪些？”，评审就变成了在现实中寻找最佳解决方案。
AI 让第二种框架成为可能。因为它已经摄取了架构决策记录、事件历史、依赖图谱和组织标准，它能立即回答事实性问题。人类得以把时间花在只有人类才能做的事情上——评估涉及判断、不确定性或相互竞争优先级的权衡。
最难的调整
对有经验的架构师来说，最难的部分是承认：直觉虽有价值，但在现代规模下不足以作为架构决策的依据。你对某项方案有风险的本能感觉可能是对的，但理由比感觉更重要。
AI 提供了支持或挑战你直觉的证据。这让最终决定以本能感觉永远无法做到的方式变得可辩护。当六个月后有人问为什么选择了某条路径时，你不必说“当时感觉对”，而可以指向支撑该决定的数据。
让每次评审都这样开始
养成这个习惯。在第一个观点被提出之前、在第一场争论开始之前，问问 AI 对这个方案了解些什么。不是要取代人的判断——而是给判断一个事实基础。
答案不会替你做决定，但会让你的决定大幅变好。而你的团队离开会议室时会相信，他们没有漏掉任何显而易见的东西。
跳过事实会发生什么
我曾见过一个团队花了四十五分钟争论该用 Kafka 还是一个更简单的消息队列。讨论很热烈。人们基于对这两项技术的过往经验各持强烈观点。有人主张用 Kafka，因为它是行业标准；有人主张简单化，因为团队的运营经验有限。
终于有人让 AI 去查一下。AI 返回了实际的消息量、团队运营每个系统的经验，以及与这两项技术相关的三次过往事件。争论不到一分钟就结束了。事实摆上桌面后，答案显而易见。
那四十五分钟被浪费，不是因为团队不该争论——而是因为他们在没有事实的情况下争论。AI 本可以在开始时就提供那些事实，只是团队还没有养成询问的习惯。
真正的阻力
我最常听到的反对意见是“但 AI 可能会漏掉什么”。这没错，它确实可能。但房间里任何一个人也可能。区别在于，AI 会透明地呈现它所知道的，而人类可以质疑它。这比依赖碰巧对两年前某起相关事件记忆最强的那个人要好。
问题不在于 AI 有时是否会出错，而在于从事实出发是否比从观点出发能产生更好的结果。
以我的经验，事实胜出。
让它成为习惯
做得好的团队有一条简单的规则：在架构评审中，任何人在提出观点之前，AI 先给出它的发现。不是要取代判断，只是为判断提供基础。
这一条规则就能缩短会议、改善决策，并建立起“没有漏掉任何显而易见的东西”的信心。试一次，你会立刻看到差别。