從 JSON 回覆到可靠的工作流程

先從接收系統開始

在要求模型輸出 JSON 之前，先決定下一個系統需要什麼。選擇欄位名稱、型別、必填欄位，以及缺失資訊的表示方式。一個可預測的物件只有在其意義符合任務時才有用。與使用端應用程式一起維護一個小型的版本化結構描述。

要求明確的結構

在試驗場中選擇 JSON，並描述預期的欄位。例如，要求一個摘要字串、一個 next_steps 字串陣列，以及一個 missing_information 陣列。說明結果必須使用提供的來源，而非外部猜測。以下物件僅為示意，並非模型產生的結果。

程式碼

{
  "summary": "The launch date has not been supplied.",
  "next_steps": ["Confirm the owner and launch date."],
  "missing_information": ["owner", "launch_date"]
}

驗證語法、結構與證據

先解析 JSON。然後拒絕非預期的型別、遺漏的必填欄位，或超出業務限制的字串。最後根據來源檢查事實欄位。結構描述驗證的是物件的形式；它無法證明日期或負責人是真實的。如果下一步需要可追溯性，請保留來源識別碼。

失敗情況	復原方式
無效的 JSON	使用解析器錯誤和原始任務重試一次
缺少欄位	要求必填的結構或回傳驗證錯誤
不支援的事實	標記為未知；要求提供來源證據
輸出被截斷	增加預算或縮小擷取範圍

將不完整的輸出視為不完整

停止的回應可能會在字串或物件中途結束。不要執行它，也不要默默將其修復成看似確定的結果。在供應商整合中，檢查完成狀態並保留錯誤。使用高投入時，推理會消耗輸出 token，請 accordingly 編列預算。API 指南說明回應處理方式。

在副作用之前設下邊界

解析後的物件不應自動寄送電子郵件、變更訂單或執行指令。獨立驗證權限與業務動作。在應用程式需要時使用核准步驟。在啟用自動化之前，測試負面案例——錯誤的型別、未知的識別碼、額外的欄位，以及中斷的串流。請閱讀工具呼叫章節，了解應用程式的責任。