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正在從根本上重塑軟體架構的格局。架構師的角色正從程式碼級決策的守護者轉變為系統級特性的戰略師，關注資料、信任、可觀測性和業務對齊。那些適應這一轉變的人將定義下一個時代的軟體工程。