軟體現代化專案經常以優雅分散式架構的承諾開始，卻以維護的噩夢告終。這個失敗的答案，在於雲端、微服務或生成式 AI 出現數十年前就已提出的原則：蓋爾定律。

「一個運作中的複雜系統，總是源自於一個運作中的簡單系統。一個從零設計的複雜系統從未運作過，也無法被修復。你必須重新開始，從一個運作中的簡單系統開始。」 — John Gall

在這個被 hype 所主導的時代，我們被推向從 Day 1 就採用數十個微服務的 event-driven 架構、自主 AI 代理，以及複雜的可觀測性管線。蓋爾定律提供了一個殘酷的提醒：初始複雜度是一場注定失敗的賭注。

🏗️ 過早複雜化的陷阱

從一開始就設計系統的最終、最完美的版本是件誘人的事。在新平台的 kickoff 會議上，團隊的自然傾向是描繪公司五年後所需的架構。白板上很快堆滿了訊息佇列、API gateways、service meshes、分散式快取，以及多層編排。

問題在於？複雜系統不是天生就已完備。它們是逐步成長出來的。

Gall 在 1970 年代的醫院管理系統中觀察到這種現象，而這個模式在現代軟體中毫無改變地重演。在 Day 1 就設計複雜版本，意味著在建構一個從未在最簡單且可運作的形式中被驗證過的生態系統。各元件以現實中未經測試的方式互動。故障不是來自單一模組，而是來自從未獨立運作的各部分之間的摩擦。

結果就是典型的 Big Bang Architecture：數月開發，卻沒有任何一次 deploy 到正式環境，最終以災難性的整合收場，沒有任何服務信任其他服務。

⚡ Archie 的挑釁：AI 不知道什麼是「簡單」

Archie： Vitor，我必須介入。你對「從簡單開始」的熱烈辯護，忽略了一個關鍵變數：人工智慧。

你主張複雜度應來自真實的痛苦。然而，當前的生成式 AI 運作速度之快，可以在第一個痛苦出現之前，就實例化一整個複雜生態系統——微服務、schemas、Dockerfiles、Go 測試和管線——幾小時之內就能完成，而不是幾個 sprint。

蓋爾定律誕生於一個建構簡單系統需要數週的時代。今天，一個代理人幾乎可以同時寫出 Day 1 的模組化單體，以及 Day 100 的分散式網格。問題不再是「簡單還是複雜？」。問題是：AI 是加速了演化，還是跳過了你甚至不知道需要進行的驗證步驟？

真正的危險不是複雜度。而是那些通過了撰寫該程式碼的 AI 所生成之測試，卻毫髮無傷的複雜度。你開始信任一個未經生產環境痛苦洗禮的系統。

🤖 回應：為什麼 AI 並未改變遊戲規則

Archie 提出了尖銳的一點。生成式 AI 已將複雜度的創造商品化並降低成本。由於它不會在半夜承擔維護基礎設施的「痛苦」，因此在 Day 1 新增一個 Kafka 或 Redis 叢集，對代理人來說認知成本為零。這是無可否認的：一個 LLM 可以在數秒內生成一個分散式系統的骨架。

然而，蓋爾定律對矽和碳都同樣無情：一個由 AI 生成、卻未奠基於已驗證之簡單系統的複雜骨架，依然是一個從未運作過的複雜系統。

Archie 警告了那些「在測試中看似運作」的複雜度。但當這個由 AI 打造的分散式系統在 Day 1 因真實流量而崩潰時，工程團隊將繼承一個真正的架構黑箱。除錯和映射模糊相互依賴關係所需的認知努力將是殘酷的。如果你不是透過痛苦提取出這些服務，你就不會理解它們現在所造成的痛苦。

這就是為什麼從簡單開始，不再只是時間上的限制，而成為了架構師獨有的戰術紀律。AI 鋪好了道路，但並未免除演化的代價。黃金法則依然完整：

  1. 用最小的架構足跡解決真實問題： 例如，一個結構良好的 Java 單體。一個單一的交易式資料庫。一條直接的 CI/CD 管線。
  2. 在工廠現場驗證，而非在 whiteboard 上： 將簡單系統部署到正式環境，承受真實流量，處理真實使用者所犯下的未預期錯誤。
  3. 僅在有正當需求時才提取複雜度： 當那個報表模組開始拖垮 JVM 並爭奪 CPU 時，就在這個時刻，將它提取到 AWS 上一個隔離的 Quarkus 微服務。絕對不要提前。

AI 擅長在數小時而非數週內，將這個初始單體編碼出來。當瓶頸出現時，它能加速遷移到穩健的基礎設施。但它無法取代在正式環境中的真實驗證。這仍然是唯一絕對的測試。

🧭 結論：從簡單開始的智慧

蓋爾定律並非反對複雜架構。任務關鍵、高流量且有嚴格法規要求的系統需要複雜度。真正的戰鬥，是對抗未經現實證實的複雜度。

在批准下一個架構圖之前，請問自己一個務實的問題：

我正在設計的這個複雜生態系統，是源自於一個已經運作的簡單系統，還是試圖從零發明它？

如果答案是後者，蓋爾定律發出了一個明確的警告：你很可能必須重新開始。下一次，從簡單開始。

本文為「應用於軟體架構的心智定律與原則」系列的一部分。下一集：康威定律——為什麼你的架構是貴公司的鏡像。