今年 2 月，我們在 QCon 上分享了《組織級架構治理的正确落地方式》，其背後的一個核心思想是：架構即代碼。圍繞這個核心思想，我們建構了 ArchGuard 的治理功能，即架構規範轉換為代碼。
今年 5 月，我們在 QCon 上分享了《探索軟體開發新工序：LLM 賦能研發效能提升》，一次關于 LLM 與研發效能的試驗、探索與洞察等。
而如果你對于 AI 代碼生成的進一步探索，你也會發現：
- 編碼速度（自動生成代碼）加快，架構/骨架的合理性和牢靠性更加重要。
- 架構設計及演進的速度将成為研發速度的新瓶頸。
- 架構知識需要工具化，以充分利用大模型能力。
于是乎，圍繞着上述的幾點，我們開始探讨：如何改善代碼生成的品質？如何避免架構成為 AIGC 的瓶頸？什麼是 AIGC 友好的軟體架構？如何利用 AIGC 來更好的賦能軟體架構？
引子：架構規範内建，改善生成品質
“衆所周知” GitHub Copilot 在生成代碼時，會根據 IDE/編輯器的編輯曆史、檔案資訊，動态建構所需要的上下文，以此生成貼近使用者編碼習慣的代碼。但是呢，如果原有的代碼不規範，那麼生成的代碼也就是不符合規範的。
幸運的是，在國内的大部分公司是用不了 GitHub Copilot；不幸的是，我們需要找到一個更貼近的工具。
于是乎，在四月份，我們建構了一個 IDE 插件 AutoDev ，其中的一部分内容便是探索：結合架構風格（三層架構）的自動化需求分析與編碼。而在 ArchGuard Co-mate 中建構架構治理和架構設計功能時，我們提倡的是動态的上下文管理，也就是圍繞不同的場景，所需要的上下文是不同的。
是以，我們也可以将架構規範直接內建到編碼工具中，如下圖是開發中的 AutoDev 新功能（新版本正在稽核中）：
即将規範直接内建到工具中，便可以直接生成更貼近架構規範的代碼。不過，要生成符合業務需求的代碼，還依賴于具體的需求，也就是由先前讨論研發效能時的話題。
設計思想：LLM 增強的架構全生命周期
談及架構的全生命周期，我們定義了 "三态兩方" 這一概念。這裡的“三态”指的是設計态、開發态和運作态，它們代表架構發生變化時會經曆的三個階段；“兩方”則指的是團隊方和互動方，它們代表了架構的主要利益相關者：架構的維護團隊和架構的使用者。在這個全生命周期中，大型語言模型 (LLM) 能夠在各個階段發揮其獨特的作用，進一步增強架構并使得各利益相關者受益。
設計态：自然語言處理能力輔助快速模組化
設計态是架構生命周期中的第一階段，在這個階段，架構師需要根據諸多業務需求進行架構設計。LLM 的自然語言處理能力在此階段顯得尤為重要。它可以從需求描述中準确地提取出業務概念（名詞）和業務行為（動詞），并識别出它們之間的關系。這樣，架構師就可以更友善地進行架構模組化，進而提高設計效率。
除此之外，我們還可以 Think big，例如利用 LLM 的推理能力進行架構設計的預先驗證。假設LLM 可以向團隊提供更多的模拟場景，那麼它就可以在一定程度上預測架構在這些模拟場景和負載下的表現，為優化設計提供重要參考。
開發态：按架構圖索骥，生成符合規範的代碼
在開發态階段，LLM 通過将軟體架構規範轉化為實際的代碼，為“按圖索骥”這一理念賦予了實際的工作效能。這主要依賴于LLM的兩大關鍵能力：抽象了解和模式識别。
- 抽象了解，從模型到DSL：LLM 能夠了解架構設計中的抽象概念和模型，包括各類設計模式、接口、元件及其間的互動關系等。這使得 LLM 能夠了解架構設計師的意圖，并将其轉化為符合特定程式設計語言和風格的待填充「模版」。
- 模式識别，填充符合規範的代碼：LLM 能夠識别和學習大量現有的編碼規範和模式。這使得LLM能夠生成的代碼不僅符合架構設計，而且遵循最佳的程式設計實踐和規範。這樣可以保證生成的代碼不僅功能正确，而且代碼品質高，便于閱讀和維護。
充分運用 LLM 的這兩大能力，可以使得在開發态階段，架構設計與代碼生成相輔相成，減輕開發團隊的工作負擔，提高開發效率，并且保證明際代碼與架構設計的一緻性和可維護性。
運作态：動态拓展架構的開放能力成為可能
在運作态階段，自然語言處理的接口有可能成為未來架構的一個重要組成部分，為機器到機器API提供了全新的範式。這種範式讓架構的開放層能力在被調用時具有更大的靈活性和拓展性。
具體來說，在運作态階段，LLM 的自然語言處理能力能夠了解外部系統或使用者的請求意圖，識别并處理涉及綜合資源的複雜請求。這些請求可能涉及到未明确開放的多個服務或子產品。LLM了解請求後，會建構相應的上下文并确認資源權限，確定所有相關資源的安全通路。之後，LLM将利用其深度學習和推理能力，分析、整合這些資源，生成滿足請求需求的響應。如此，LLM即使面對綜合化資源或服務的請求，也能動态擴充架構的開放層，提供所需功能。
這種動态擴充架構的開放能力，讓架構能夠更靈活地應對各種複雜的請求，提供更豐富的服務，同時保證了系統的安全性和可控性。這無疑為架構的運作态提供了全新的可能。
除此之外，在軟體運作階段，系統會遇到各種預期内或預期外的問題，這就需要對架構進行調整和優化。LLM可以輔助這一過程，提供智能化的解決方案，包括且不限智能優化及自動修複等能力。并且随着軟體系統的運作和需求的變化，LLM還可以幫助了解和适應新的架構，生成符合新架構的代碼，以及驗證和優化新架構。
面向兩個幹系方，LLM 在架構全生命周期中的橫向價值
在闡明了 LLM 如何在架構的不同階段提供增強效果之後，我們可以進而思考從兩大幹系方，即團隊方和互動方的角度出發，将如何在架構全生命周期中，從 LLM 的應用中受益。
- 對于團隊方而言，LLM 的能力可以幫助團隊在知識傳遞和共享方面帶來顯著的提升。例如，LLM可以利用其自然語言處理和知識圖譜的技術，以直覺易懂的方式描繪出架構設計中的重要概念和關系，進而加強團隊間的知識傳遞。此外，LLM 可以作為協調者，幫助團隊成員了解架構設計的決策，進而提升整個團隊的協作效率。
- 對于互動方，LLM 的應用可以帶來使用者體驗的躍遷。這包括更自然的互動方式，使用者可以通過自然語言來描述他們的需求；架構的動态擴充能力，使得使用者可以更靈活地使用系統，不再受限于固定的接口和服務；以及系統在面對複雜請求時所展現出的強大自适應性。這些都将為使用者帶來了前所未有的體驗。
綜上，通過在架構的不同階段引入 LLM，不僅可以增強架構的設計、開發和運作效果，也為架構的幹系方帶來了明顯的橫向受益。
設計原則：适配于軟體架構的 AIGC
随着，LLM 能力的逐漸提升，我們相信國内會有接近于 ChatGPT 的 LLM 出現。而現在為了進一步提升 AIGC 代碼的可用性，我們需要讓 AIGC 能适配軟體架構（諸如于分層、編碼等等）。
是以，根據我們的探索經驗，總結了三個核心要素：
- 架構知識顯性化，除去約定俗成
- 借助 DSL 精煉架構上下文
- 全流程引導 AIGC，朝向目标架構
未來，随着我們的進一步探索以及 LLM 的演進，相信會出現一些新的變化。
要素：架構知識顯性化，除去約定俗成
動機：若想借助 AIGC 來生成代碼，就需要将隐性的架構知識顯性化表達出來，以文本、DSL 等形式表示。
在軟體開發中，架構知識包含了架構決策記錄、架構設計文檔、架構規範等等，它們分散于組織的不同團隊中：
- 架構規範。在統一的架構庫或者團隊知識庫中。
- 代碼規範。在流水線平台、IDE 插件中等。
- 分層規範。隐藏在代碼中，以約定俗成的方式存在。
- ……
更慘的是，在我們建構ArchGuard 的初期，與不同公司的架構師進行了交流，發現架構規範在多數組織裡是空中樓閣，或者說隻能是沒人看的參考建議。有點類似于電器産品的說明書，你翻一下隻是為了看一下：保修卡有沒有在裡面。
是以，我們會把團隊對架構規範的采納度分為三類：
- 沒有顯性化規範。對于小團隊來說，規範化的代碼、分層等，依賴于個人的能力、技術追求；又或者是靠約定俗成，結合 code review 的方式所完成的。
- 有規範，不落地。對于中大型公司的開發團隊來說，他們都有非常多的規範，但是沒人看。
- 規範工具化。這個便是我們在 ArchGuard 時的核心關注點，特别是不易顯形的分層架構、MyBatis 中的 SQL、API 規範等。
架構規範是架構知識中最易于 LLM 相結合的，也是最适合去實踐落地的。
要素：借助 DSL 精煉架構上下文
動機：代碼生成時，需要一系列的代碼上下文、架構知識等等。在多數場景下，都可能超出 LLM 的上下文邊界，或者上下文過長可能會迷失，是以需要精煉出上下文，而 DSL 是一種比較理想的方式。諸如于生成 Controller-Service 代碼時，需要提供 Entity、DTO、Mapper 等代碼資訊，并要結合業務系統的規範。
架構 DSL 示例：在 2022 年，我們嘗試建構 Fklang 作為一個架構描述語言。它是一個基于軟體開發工業化思想，設計的架構設計 DSL。以確定軟體系統描述與實作的一緻性。通過顯式化的軟體架構設計，用于支援 AI 代碼生成系統的嵌入。
我們将分層架構的規範，變成了簡化的 DSL 形式，并且它是可以直接在 IDE 中執行的。在沒有 LLM 時，它需要人去編寫這個 DSL，而現在可以直接由 LLM 根據模闆生成，直接降低人的學習成本。
PS：由于 Fklang 是一個外部 DSL，是以我們在 Co-mate 中使用 Kotlin DSL 重新設計成内部 DSL。
要素：全流程引導 AIGC，朝向目标架構
架構設計是貫穿在整個軟體開發生命周期裡，是以我們的挑戰也會變成了，如何在全流程中融入我們的架構設計？
諸如于，在先前的分享裡，我們繪制了一個大緻的軟體開發生命周期：
我們需要在需求階段考慮架構設計，諸如于根據需求的軟體模組化、模型設計、表設計等等。在我們拿到一個大的特性之後，便可以結合 AIGC 進行設計：
- 在需求系統，讓 AIGC 進行初步的設計，由人去 review 這個設計。
- 從 IDE 中擷取架構設計系統中的表設計、規範等。
- 按不同的分層（諸如 Controller-Entity-Service-Repository），內建對應的規範
- ……
稍有差異的是，與 GitHub Copilot 相比，在固定分層的業務系統之下，我們更容易調配出适合于組織上下文的 AI 輔助生成代碼工具。
示例：LLM 賦能的架構生成探索
在有了上述的示例和思考之後，我們就可以做一些探索性的嘗試。
示例 1：端到端架構生成工具設計
在 AutoDev 中，我們便想做這方面的嘗試，接入 GitHub issue 作為一個簡單的需求系統；結合編碼規範，在不同的分層中，接入不同的規範，以更貼切于對應的上下文。
而我們所要做的就是，更拆解規範，讓他們在各自的上下中工作。如在梳理軟體開發的工序，将規範配置到不同的場景中：
- Controller 編寫。結合 API 設計規範、分層規範等。
- Service 編寫。結合 Service 編碼規範。
- Repository 編寫。結合 …… 規範。
上述的三條規則是我從網上 copy/paste 的，完全沒有任何的惡意。是以，如果幸運的話，LLM 就能一次性生成符合規範的代碼；不幸運的話，你就再生成一次吧。
示例 2：LLM 輔助架構治理
如我們在先前的《語言接口：探索大模型優先架構的新一代 API 設計》所總結的，在 ArchGuard Co-mate 中，我們所做的嘗試便是：将規範轉換為 DSL，并根據不同的團隊來動态生成。
同樣的場景，适用于架構分層規範、API 規範、模型設計等等的 DSL 化。
示例 3：AIGC 輔助架構設計
相似的，為了有限控制上下文，我們也在 ArchGuard Co-mate 中建構了用于轉換需求的 DSL，以借助于大模型的能力，将完善需求。并将需求壓縮到 DSL 中，以更好地控制上下文。
當然，生成這樣的使用者旅程 DSL 是不夠的，還需要提供一個 UI 界面來互動。
總結
來自 ChatGPT 的總結：
本文介紹了利用大型語言模型改善軟體架構的方法。關鍵點包括架構即代碼、LLM在設計、開發和運作階段的應用、團隊和互動方的受益、顯性化架構知識、DSL精煉架構上下文、全流程引導AIGC朝向目标架構。這些思想和工具為提高代碼生成品質和軟體架構效能提供了指導。