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卡住，教程修復，再試一次”，轉換終於順利透過。

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