後設資料驅動開發

在實踐中

這個想法並不新，裝作它很新是最快被誤讀的方式。企業級平臺從 2000 年代中期就開始用「宣告而非程式碼」來描述應用，今天這套詞彙正是從那條脈絡來的：用物件而不是表，用權限集而不是鑑權中介軟體，用流程而不是定時腳本。那一代人立住的東西值得保留——在定義裡加一個欄位，API、列表檢視、詳情表單、匯出和權限模型會同時出現它，因為這些都是從同一條宣告推匯出來的，而不是靠人手工保持一致。

真正變了的，是誰在寫這份宣告。當宣告由人在視覺化控制台裡點出來時，收益是速度和一致性，格式本身可以是一種沒人直接閱讀的私有 XML 方言。當宣告由 AI Agent 編寫時，格式本身就變成了決定產出可不可信的約束：一個完整業務應用用後設資料表達是幾千行而不是幾十萬行，Agent 可以在一個上下文窗口裡裝下整個系統，而不是對著一個看不到邊界的程式碼庫抽樣閱讀；而審閱這次改動的人讀到的是一份宣告的 diff——哪個欄位動了、哪條權限變了、哪一步現在需要審批——而不是去審計生成出來的控制器、模板、遷移腳本和測試。

這個詞一旦裸著說出來，就會塌回低程式碼的那種讀法，並且直接輸掉論證，所以差別值得說清楚。拖拽式搭建器最佳化的是「不想寫程式碼的人」；這裡說的後設資料驅動開發最佳化的是「不是我寫的、但要我簽字的審閱者」。這兩件事會長出不同的格式。前者可以把定義藏在介面背後，因為介面就是入口。後者不行：定義必須是一份可讀、進版本庫、能 diff 的檔案——因為 diff 就是審閱面，而寫它的是 Agent，不是一張表單。

它並不適合所有工作，說明這一點不是自謙。本質是演算法的問題——定價最佳化、路徑規劃、解析器——不會因為被「宣告」出來就變小或變安全；它們該被寫成程式碼，然後由定義去呼叫。這套方法誠實的失敗形態是表達力天花板：當宣告面表達不了某個需求時，團隊就會去找逃生艙口，而逃生艙口的程式碼一多，系統就退回原點——邏輯落在了執行時管不到、審閱者也看不見的地方。