先把 Schema 當成系統契約，而不是提示詞附件
企業應用常要求模型從郵件、客服對話、報價單或維修紀錄中產生 JSON，接著寫入 CRM、ERP、工單系統或資料庫。真正的風險不只是 JSON 語法錯誤，更常見的是欄位缺漏、型別漂移、列舉值失控、日期格式不一致，以及模型自行加入下游不認識的欄位。人工閱讀時這些差異不明顯，進入自動化流程後卻可能造成錯誤路由、資料污染或 API 失敗。
因此，Schema 應由資料消費端的需求反推。先確認哪些欄位是必要值、哪些可以為 null、哪些只能使用固定列舉，以及不同版本如何相容。像「沒有資料」與「模型無法判斷」通常不該共用空字串；前者可用 null，後者則可搭配狀態欄位或原因碼。金額應拆成數值與幣別，日期應指定格式與時區，識別碼則應保持字串，避免前導零或長整數在不同語言中被改寫。
若平台支援 JSON Schema、函式呼叫或受限解碼，應優先使用，但不要把它們視為完整保證。不同模型與供應商只支援部分 Schema 關鍵字，對 format、pattern、oneOf 或複雜條件的執行程度也可能不同。上線前必須確認實際支援範圍，並保留應用層驗證。
可靠管線需要生成、驗證與業務規則三層防線
第一層是生成約束：限制模型只能輸出符合指定形狀的資料，關閉額外欄位，降低溫度，並提供清楚的欄位說明。第二層是語法與 Schema 驗證：確認輸出可解析，而且 required、type、enum、長度與巢狀結構全部符合契約。第三層是業務驗證：檢查 Schema 無法充分表達的規則，例如結束時間不得早於開始時間、訂單總額應能由明細計算，或客戶代碼必須存在於主資料。
實作時，建議將下列決策直接寫入契約與測試，而不是只放在提示詞裡：
- 缺值語意：區分 null、空字串、空陣列與未知狀態，避免下游自行猜測。
- 列舉策略：需要穩定路由的欄位使用受控 enum；開放描述則放在另一個文字欄位。
- 數值與單位：數值、幣別、百分比基準與計量單位分開儲存，不讓模型輸出「約十萬」之類混合值。
- 來源證據：重要欄位附上來源片段、文件頁碼或訊息識別碼，方便追查，但不可把模型產生的引文誤當原始證據。
- 信心與狀態：不要只依賴模型自評分數；搭配可驗證條件、缺值清單與人工覆核狀態更實用。
修復要分層處理，不能無限重試
驗證失敗後，第一步應採用確定性的修復，例如移除 Markdown 包裝、統一可安全轉換的日期格式，或將已知別名映射到正式列舉值。只有在轉換不會改變語意時才應自動修復；把任意文字強制轉成數字，或猜測缺少的客戶代碼，都可能製造比拒絕資料更危險的結果。
第二步才是模型修復。將原始輸出、Schema 與精簡的驗證錯誤交給模型，要求只修正違規部分，不重新解讀整份來源。修復後必須重新執行完整驗證，且設定明確的重試上限。若仍失敗，就應進入隔離佇列、人工覆核或降級流程，而不是持續呼叫模型。對會觸發付款、刪除、權限變更或對外通知的資料，即使通過 Schema，也應保留額外核准。
也要避免「靜默修復」。系統應記錄原始輸出、修復後資料、驗證錯誤、使用的 Schema 版本、模型版本與處理結果。這些資訊不一定都適合長期保存；若內容包含個資或商業機密，應先遮罩敏感欄位，並依資料政策設定保存期限。
用失敗樣本與版本治理維持長期穩定
結構化輸出不是一次設定後就永遠可靠。模型版本、提示詞、來源文件格式與業務欄位都會變動，因此測試集應包含真實世界的困難輸入：缺頁文件、表格錯位、中英混合、同名欄位、否定句、互相衝突的內容，以及完全找不到答案的情況。測試不只要確認 JSON 可解析，也要比較關鍵欄位的語意是否正確。
Schema 也需要版本化。新增可選欄位通常較安全；重新命名欄位、改變型別或縮小 enum 則可能破壞既有消費端。較穩健的做法是保留版本號，讓生產端與消費端能在過渡期間同時支援新舊格式，並透過契約測試確認 CRM、ERP、資料倉儲與自動化流程仍能正常運作。
日常監控應觀察驗證失敗類型、修復次數、人工覆核原因與各 Schema 版本的相容問題，而不只看模型 API 是否成功回應。當錯誤集中在特定欄位時，通常應先改善契約、來源資料或規則設計，而不是一味增加提示詞。若系統橫跨多個企業平台，讓熟悉資料契約與整合流程的工程團隊共同設計，往往比單獨調整模型更能維持穩定。