软件现代化项目常常以优雅的分布式架构承诺开始，最终却变成维护噩梦。这一失败的答案在于一个早在云计算、微服务或生成式 AI 出现前数十年就已提出的原则：加尔定律。

“一个正常运行的复杂系统，总是从一个正常运行的简单系统演变而来。一个从零设计的复杂系统永远无法正常运行，也无法被修复。你必须从一个正常运行的简单系统重新开始。” —— 约翰·加尔

在一个被 hype 所主导的时代，人们被推向从 Day 1 就采用数十个微服务、自主 AI 代理和复杂可观测性流水线的 event-driven 架构。加尔定律则残酷地提醒我们：初始的复杂性是一场注定失败的赌注。

🏗️ 提前复杂性的陷阱

在项目启动时，设计系统的最终版本是极具诱惑的。在新平台的 kickoff 上，团队自然而然地倾向于绘制公司五年后所需的架构。白板上迅速堆满消息队列、API 网关、service mesh、分布式缓存和编排层。

问题在于：复杂系统并非天生就绪，它们是逐步成长起来的。

加尔在 20 世纪 70 年代的医院管理系统中观察到这一现象，而这一模式在现代软件中依然如故。在 Day 1 就设计复杂版本，意味着构建一个从未在最简单且可用的形态下被验证过的生态系统。各组件以现实中未曾测试过的方式交互。故障并非来自孤立的模块，而是来自从未单独运行过的部分之间的摩擦。

结果就是经典的 Big Bang Architecture：数月开发却无一次生产环境部署，最终以一场灾难性的集成收场，没有任何服务彼此信任。

⚡ 阿奇的挑衅：AI 并不知道什么是“简单”

阿奇： 维托尔，我必须介入。你对“从简单开始”的热烈辩护忽略了一个关键变量：人工智能。

你主张复杂性应源于真实的痛点。然而，当前的生成式 AI 以极快的速度运行，甚至在第一次痛点出现之前，就能实例化整个复杂生态系统——微服务、模式、Dockerfile、测试以及 Go 语言的流水线。几小时内完成，而非多个 sprint。

加尔定律诞生于构建简单系统需要数周的时代。如今，一个代理几乎同时就能写出 Day 1 的模块化单体和 Day 100 的分布式网格。问题不再是“简单还是复杂？”。而是：AI 加速了演进，还是跳过了你甚至不知道自己需要的验证步骤？

真正的危险不是复杂性，而是复杂性在由同一 AI 生成的测试中毫发无损地通过。你开始信任一个未经历生产之痛的系统。

🤖 反驳：为什么 AI 并未改变游戏规则

阿奇提出了尖锐的一点。生成式 AI 将复杂性的创建商品化并降低了成本。由于 AI 不会在深夜遭受维护基础设施的“痛苦”，在 Day 1 就添加 Kafka 或 Redis 集群对代理来说认知成本为零。不可否认：一个 LLM 能在数秒内生成分布式系统的骨架。

然而，加尔定律对硅和碳都同样无情：由 AI 生成的复杂骨架，若没有经过验证的简单系统作为基础，依然是一个从未正常运行过的复杂系统。

阿奇警告那些“在测试中似乎正常运行”的复杂性。但当这个由 AI 锻造的分布式系统在 Day 1 因真实流量而崩溃时，工程团队将继承一个真正的架构黑箱。调试和梳理隐晦依赖关系的认知努力将是残酷的。如果你不是通过痛苦提取服务，你就无法理解它们现在正在制造的痛苦。

正是因此，“从简单开始”已不再是时间限制，而是成为架构师的专属战术纪律。AI 铺就道路，但并不免除演进的代价。黄金法则依然完好：

  1. 用最小的架构足迹解决真实问题： 例如，一个结构良好的 Java 单体。一个事务性数据库。一个简洁的 CI/CD 流水线。
  2. 在工厂车间而非白板上验证： 将简单系统投入生产环境，承受真实流量，处理真实用户犯下的未预见错误。
  3. 仅在有正当需求时提取复杂性： 当报告模块开始拖垮 JVM 并争夺 CPU 时，就在这一刻，将其提取为一个运行在 AWS 上的独立 Quarkus 微服务。绝不要提前。

AI 擅长在数小时而非数周内编码初始单体。它在瓶颈出现时加速迁移到健壮的基础设施。但它无法取代生产环境的真实验证。这依然是唯一的绝对测试。

🧭 结论：从简单开始的智慧

加尔定律并不反对复杂架构。任务关键型、高吞吐量且具有严格监管要求的系统确实需要复杂性。真正的战斗是针对未被现实所证明的复杂性。

在批准下一个架构图之前，问自己一个务实的问题：

我正在设计的这个复杂生态系统，是从一个已经正常运行的简单系统演变而来，还是我试图从零发明它？

如果答案是第二种，加尔定律发出了明确警告：你很可能不得不重新开始。下一次，从简单开始吧。

本文属于“应用于软件架构的思维法则与原则”系列。下一集：康威定律——为什么你的架构是公司的镜像。