AI之后的软件架构

随着时间的推移，软件架构的定义一直难以捉摸，但《构建演进式架构》一书中提出的一个定义却颇具洞察力：架构从本质上来说就是那些难以改变的东西。这一定义最诚实也最简洁，它承认，一个决策之所以被视为“架构性”的，并非因为其概念上的重要性，而是因为其逆转成本和对业务的影响力。而“难以改变”归根结底是关于墙上时钟时间：协调成本、事故缓解、认知负荷和交接摩擦。软件架构一直以来都是一个伪装成设计问题的劳动问题。

如今，AI已经大幅压缩了进行重大代码级更改所需的墙上时钟时间。过去需要数月的事情现在只需数天。当逆转大多数代码级决策的成本下降了一个数量级时，架构会发生什么变化？答案是，架构的边界发生了移动，在某些情况下甚至非常显著。大多数代码级决策不再属于架构范畴，因为它们的逆转成本已大幅降低，出错后果仅需数天而非数月即可修复。仍然属于架构范畴的是数据、服务边界和用户信任，因为它们的困难从未在于代码本身。此外，一些曾被代码级争论所掩盖的问题现在变得更加突出，例如可观测性随着功能交付速度的提升而值得重新审视。

几十年来，代码级决策确实是架构性的。语言、框架、模块结构和持久化策略都是值得争论和投入的决策，因为重新审视它们可能耗费大量时间，并对团队生产力产生长期影响。改变这些决策可能需要数月甚至数年的时间和精力，公司可能因此兴衰。然而，软件从业者几十年来一直在将架构决策降级为常规决策。通过直面而非回避痛点，团队构建工具来解决这些问题，从而将原本的架构问题转变为普通工程师日常可处理的事务。

在数据库迁移变得普遍之前，模式决策是不可逆转的，通常需要DBA来协调。随后，《演进式数据库设计》一书问世，迁移功能被集成到各大框架中，DBA的角色逐渐淡化。他们的判断和专业知识是真实的（且重要的），但其市场价值被机械瓶颈所夸大。一旦瓶颈被移除，专职守门的成本变得显而易见，判断能力被吸收到普通工程角色中，从而为许多团队提供了更多杠杆。持续交付对部署和发布工程师也产生了同样的影响。每一次工具效率的小幅提升，都将原本需要专家的决策变为机械性操作，揭示了专业化判断往往是被机械成本所困的通用工程技能。

AI仅仅是这一趋势的最新例证，但它最为戏剧性，因为它一次性压缩了大多数剩余的代码级决策，而不是一次一个类别。一个最近的个人例子：我在一个现已倒闭的初创公司中使用了一家也是初创公司的NoSQL数据库，结果它也倒闭了。我让Claude Code处理这件事，给予一些指导后，它几乎完美地将整个数据层移植到了传统的RDBMS上，只用了几个小时。我知道这类事情已变得司空见惯，但它仍让我感到惊讶：介于这项工作的单调性和我的日常工作，我可能永远无法在宇宙热寂之前完成它。

这并非孤例。Cloudflare团队在不到一周的时间内，以约1100美元的API成本重新实现了Next.js API的94%。Christopher Chedeau在一个月内将10万行TypeScript代码移植到了Rust。许多读者可能也经历了类似的变化。

从某种程度上说，这些例子证明了良好结构的重要性：我之所以能够轻松迁移数据层，是因为我之前就对接口边界进行了清晰设计。但即便没有清晰的边界，这种变化本质上也是机械性的：找到所有调用点，更改所有实现，验证正确性。更多的令牌、更多的时间以及更多的人工干预，但差异并不大；也许从数天缩短到数小时。而代理式开发的二阶效应是，你可以在此基础上自动化验证，将正确性检查内嵌到流程中。

这些例子显然偏向于简单情况：清晰的接口、明确的边界和可机械验证的正确性。具有微妙语义、不明确边界和深度纠缠业务逻辑的系统仍然难以更改，即使有AI的帮助。但趋势线很重要。AI并没有消除耦合、迁移风险或部署复杂性，但它确实将许多过去感觉永久的代码塑造决策降级，并使其余决策更易于监控和修复。这越来越多地将改变归入“不再是架构”的范畴。

如果代码已移出架构边界，那么什么仍然在内？由于定义上不可能提供全面的软件架构分类，我列出了以下六个类别，并试图按照两个维度进行分类：决策错误的后果和逆转成本。这是直觉层面的东西，而非硬数据。

决策类别 | 状态 | 原因 本地代码结构 | ↓降级 | 模块、框架、持久化、集成连接。AI使机械性重构变得廉价；现在出错只需数小时而非数季度。 可扩展性和部署姿态 | ↓降级 | 基础设施拓扑和性能策略。仍比普通代码难，但借助AI辅助工具，常规工程即可处理。 数据架构 | →仍为架构 | 所有权、一致性、模式演进。数据具有引力；困难从未在代码，也未真正移动。 信任和服务边界 | →仍为架构 | 安全姿态和下游消费者依赖的契约。违规几乎不可逆；契约约束的是组织而非系统。 可观测性和行为验证 | ↑提升 | 代码量上升而理解力下降。验证行为是捕捉无法阅读之问题的方式。 业务战略和能力对齐 | ↑提升 | 一直高后果；现在终于可见。随着代码级争论成本降低，架构师有了思考工作存在意义的空间。

三个运动，三种不同原因。

一些决策被降级是因为AI降低了其逆转成本。本地代码结构（模块、框架、持久化、集成连接）过去需要认真的架构关注，因为逆转糟糕决策可能耗费数月；现在不再需要。可扩展性和部署姿态紧随其后：基础设施拓扑和性能重构仍比普通代码难，但借助AI辅助工具，常规工程即可处理。这些决策仍需判断力，但判断力不再被机械成本所困，错误后果以小时和令牌而非季度和人力来衡量。

一些决策保持不变是因为困难从未在代码。数据架构（所有权、一致性模型、模式演进）没有移动，因为数据具有引力：它随时间积累质量，依赖其当前形状的事物多于任何人能列举的。信任和服务边界也没有移动：安全违规和契约违规实际上是不可逆的（尽管大公司在这方面经常逃脱惩罚），逆转它们需要与人协调、重塑累积状态或撤销代码更改无法触及的实际后果。

两个决策被提升，原因不同。可观测性和行为验证上升是因为代码量在增加：如果每行缺陷率保持不变但代码量增加五倍，那么未能验证系统实际行为的后果随之增加。此外，如果行级理解力同样崩溃（如在黑暗软件工厂），你需要能够验证系统做了什么，无论你是否理解每一行。监控的实施是廉价的；决定监控什么以及如何验证行为正确性则不是。相反，业务战略和能力对齐在图表上根本没有移动；它们一直高后果，逆转战略失误一直昂贵。改变的是架构师终于有空间去处理它们。随着代码级争论成本降低，哪些边界创造竞争优势的问题不再被框架争论所掩盖。

有人可能会合理争辩说，代码结构正是我所称的架构的执行机制。良好的模块边界有助于执行API契约；良好的类型系统有助于保护数据不变量。如果你不再关心代码结构，难道不会危及你所关心的契约吗？我认为这混淆了决策与其实现。契约的形状和保证是困难部分；更改它们需要实际时间，因为需要与人协调。执行它们的代码是实现，而实现现在很便宜。你可以更换执行机制而不触及它所执行的契约；我的初创公司迁移工作正是这样做的。

还有一个相关反对意见值得考虑：中层设计决策（“这个业务逻辑应该放在服务A还是服务B？”）随时间累积成系统的整体可塑性，而这些累积的决策确实难以解开。这是事实，而且一直是事实。它从来就不是中央可控的：团队通常将东西放在看似合理的地方，优化本地自治和吞吐量，无论你如何试图中央管理，结果总会有一定程度的漂移。改变的是，配备代码库搜索索引（正迅速成为基准配置）的LLM可以真正找到所有内容，推理其为何如此，并帮助你重组。中层决策的累积影响虽然仍然重要且可能仍属架构范畴，但借助AI变得更容易处理；解开它的成本已经下降，即便没有消失。

你会听到相反的观点称AI使代码质量更重要，而不是更不重要，因为它会在量级上放大好和坏的决定。这有一定道理：AI输出的质量取决于其输入和提示。如果代码库一团糟，AI生成的代码也会一团糟，而且速度更快。但作者认为，模式放大并非宿命：你可以构建有针对性的约束提示、契约强制和自动化治理来引导输出，而无需预先完美化代码。正如微服务能够治理在没有中央治理的情况下趋同的本地边界一样，AI生成代码也可以被引导。

总结而言，AI正在从根本上重塑软件架构的格局。架构师的角色正从代码级决策的守护者转变为系统级特性的战略师，关注数据、信任、可观测性和业务对齐。那些适应这一转变的人将定义下一个时代的软件工程。