型別化後設資料

在實踐中

這裡的區別，是配置檔案和契約的區別。一個 YAML 或 JSON 配置檔案，你往裡寫什麼它就收什麼；讀它的程式在執行時自己決定認哪些鍵，剩下的默默忽略。這個預設行為正是「聲明瞭但沒生效」的來源：有人寫下 `requireApproval: ture`，沒有任何東西報錯，而那條被宣告出來的審批從來沒有跑過。型別化後設資料把這個預設反了過來：schema 是公開發布的，每個鍵都有型別，一個沒人認識的鍵是錯誤而不是聳聳肩——於是檔案說的和系統做的，不可能在沒有任何東西先大聲失敗的情況下悄悄走散。

型別帶來的不止是擋住拼寫錯誤，因為 schema 不只給校驗器讀，也給工具鏈讀。同一份宣告可以在寫定義時驅動編輯器補全，在持續整合裡充當校驗關卡，還能生成讀者事後要查的文件。一份公開契約，三個消費者——這也是為什麼 schema 值得當成一等產物來維護，而不是散落在各處讀檔案的程式碼裡的校驗邏輯。

當作者是 Agent 時，這個論證會更鋒利。一個被要求「加一條審批規則」的模型，失敗方式有明顯特徵：它產出的是看起來合理、且很接近的東西——一個像模像樣、但這份 schema 並沒有定義的鍵；一個從它在訓練資料裡見得更多的另一個平臺借來的權限值。沒有型別的配置會默默把它吞下去然後上線。而 schema 會在編寫的那一刻拒絕它，Agent 在同一個迴圈裡就能讀到錯誤並改正；更進一步，公開的型別本身就在錯誤發生之前引導生成——因為「已釋出的型別」恰好是模型最能遵守的那種約束。

型別做不到什麼同樣要說清楚，因為把它吹過頭，正是「用校驗替代審閱」的開始。schema 約束的是形狀，不是意圖。一個權限集可以完全合法，同時把薪資資料開放給了錯誤的人；一個流程可以通過型別檢查，同時把審批路由給了一個已經離職的人。型別化後設資料把一整類錯誤從生產環境挪到了校驗關卡，並讓剩下的部分更小、更好讀——但它不判斷這份宣告對不對，工具鏈裡也沒有任何東西能替代那個簽字的人。