AI會讓我們困在2020年的架構中嗎？

每次使用AI編碼助手時，我都會注意到同樣的事情：它非常擅長Spring。註解、配置文件、@Autowired，以及整個回調棧驅動的bean注入舞蹈。AI已經見識了二十年的這種模式。即使需要推斷配置文件特定的bean如何在運行時被選擇，它也能很好地預測。這是因為它見過成千上萬個完全相同的模式實例。

這引發了一個令人不安的問題：如果AI如此精通2020時代的模式，我們整個行業是否會因為這些模式是模型所知的而被鎖定？AI是否是一種保守力量，悄悄地將軟件架構拉向其訓練數據的重心，無論新想法有多好？

我想通過自己的項目來找出答案。

賭注：顯式索引勝過隱式索引

OfficeFloor第4版添加了一個我認為在AI時代真正有趣的功能：REST端點現在可以在YAML文件中定義，與現有的Spring Boot代碼並存，目錄結構遵循URL結構。文件greeting.POST.yml定義POST /greeting。文件greeting/{name}.GET.yml定義GET /greeting/{name}。在該文件中，你可以組合處理請求的小函數：

每個函數仍然像往常一樣通過Spring注入依賴項。OfficeFloor不會取代Spring的依賴注入、持久化、安全或執行器設置。變化的是流程。在典型的@RestController中，驗證、業務邏輯和審計運行的順序是隱式的：它存在於調用棧中（在if語句以及哪個方法調用哪個方法中）。要理解它，你需要閲讀代碼。要改變它，你需要閲讀更多代碼，因為連接沒有作為數據寫下來；它被編譯成控制流。

在OfficeFloor YAML版本中，這個連接就是文件本身。條件分支、順序、錯誤流：它們被聲明，而不是隱藏。鏈中的任何函數都不知道其他函數。沒有註解在類內部描述關係。YAML是一個完整的、可讀的端點行為規範，就位於目錄樹中端點自己的URL路徑旁邊。

這本質上是函數注入，與依賴注入數十年前所做的動作相同，但提高了一個層次。依賴注入將“我依賴什麼”從命令式構造函數代碼中取出，使其成為顯式的、配置化的、一流的關注點。函數注入將“接下來發生什麼”從隱式調用棧中取出，也使其顯式化和可配置化。這是我多年來一直在寫的“控制耦合反轉”思想的延續：依賴注入只解決了耦合問題的一個切片。控制流耦合始終存在，只是不可見。

對於閲讀代碼的人類來説，這可能感覺像是洗牌，甚至可能是倒退。這正是業界首先選擇註解放在代碼旁邊的原因：開發者希望連接靠近實現，而不是在某個獨立的描述文件中。這種偏好當人類是主要讀者時是有意義的。

但AI助手不是從上到下閲讀的人類。AI助手試圖找到進行正確、精確更改所需的最小上下文，這是一個搜索和導航問題，而不是風格問題。一個YAML文件命名了端點執行路徑中的每個函數，按順序，帶有顯式條件分支，這就是一個搜索索引。AI無需閲讀代碼庫的其他部分就能確信它找到了與該端點相關的所有內容。它打開一個小的文件，該URL的整個行為契約就在那裏。

至少理論上是這樣。我想知道它是否真的能在幾乎完全以另一種方式訓練出來的模型上奏效。

實驗：轉換Spring PetClinic REST

為了真實測試，我採用了Spring PetClinic REST（Spring社區多年來使用的PetClinic示例應用的長期參考REST實現），並與AI合作將其端點轉換為OfficeFloor REST YAML方法。

第一次嘗試沒有成功。大約迭代了五次才得到乾淨的轉換，瓶頸不是OfficeFloor的運行時，也不是AI的編碼能力。而是文檔。每次嘗試都暴露出教程中的空白：一些我因為顯而易見而隱式保留的假設，YAML模式可能性未詳盡説明的地方，Spring @RestController風格行為應如何映射的邊緣情況。我利用AI的混淆作為信號：它猜錯或問錯的地方，正是教程需要另一段、另一個例子、另一條顯式規則的地方。經過五輪“AI卡住，教程修復，再試一次”，轉換終於順利通過。

我錄製了最終的轉換過程。你可以在這裏觀看：