把 AI 接進客服分流、內容審核或內部工單時，最先遇到的通常不是模型會不會回答，而是回答能不能被程式穩定接手。若回覆有時是段落、有時夾著 Markdown，後面的系統就難以判斷下一步。AI 結構化輸出（Structured Outputs）的目的，是要求模型把結果放進預先約定的資料形狀，讓應用程式可以解析、驗證，再決定是否繼續流程。
這不等於「模型說的都是真的」。結構化輸出主要處理格式與欄位；事實是否正確，仍要靠資料來源、規則檢查與人工審核。以下用 JSON Schema 拆解概念，並示範一個可放進工作流程的簡化任務分流設計。
JSON Schema 在流程裡扮演什麼角色？
JSON Schema 官方入門把 schema 定義為描述與驗證 JSON 文件的詞彙。它可以宣告根資料型別是 object，並用 properties 描述欄位，用 required 指出必填欄位，也能加入 enum、日期格式或數值限制。被驗證的實際 JSON 稱為 instance；schema 是檢查它的規格，而不是資料本身。不同驗證器對日期 format 等關鍵字的檢查設定可能不同，不能只宣告就假設全部生效。
放到 AI 流程中，schema 就像介面契約。例如「任務類型」只能是 billing、technical 或 general，「優先級」只能是 low、normal 或 high。程式收到結果後先解析 JSON，再用驗證器檢查欄位、型別、枚舉與商業規則。通過不代表內容正確，只代表它符合這份資料契約。
JSON mode、schema 符合性與事實正確，三件事要分開
JSON mode 的目標是讓輸出成為可解析的 JSON，但不保證符合指定欄位或型別。OpenAI 官方文件把 Structured Outputs 視為 JSON mode 的進一步能力：前者要求輸出遵循提供的 schema，後者著重有效 JSON。若使用 JSON mode，還必須在提示中明確要求輸出 JSON，並處理可能因截斷等原因而不完整的結果。
schema 符合性也不能混同於事實正確。例如模型可以產生格式正確的 {"priority":"high","reason":"帳單已逾期"}，但原文可能根本沒有提到逾期。字串看似符合日期格式，也可能是不存在或與來源不符的日期；enum 值雖合法，也可能不符合當前情境。因此要再查詢權威資料，驗證日期是否存在、狀態是否一致、權限與金額是否符合商業規則。
更實務的分層是：第一層解析 JSON；第二層做 schema 驗證；第三層做語意、事實與商業規則驗證；第四層才進入動作。退款、刪除資料、寄出重要訊息或改變帳務等高風險動作，應保留適當核准，不要因為輸出「看起來很規整」就自動執行。
一個簡單的任務分流 JSON
以下例子使用虛構任務，不含個資或真實人物。假設輸入是一段待處理訊息，模型只負責分類與提出下一步建議：
{
"category": "technical",
"priority": "normal",
"needs_human_review": false,
"next_action": "send_troubleshooting_guide",
"reason": "訊息描述功能使用問題，未涉及付款或帳務"
}對應的小型 schema 可以長這樣：
{
"type": "object",
"properties": {
"category": {"type":"string","enum":["billing","technical","general"]},
"priority": {"type":"string","enum":["low","normal","high"]},
"needs_human_review": {"type":"boolean"},
"next_action": {"type":"string","enum":["send_troubleshooting_guide","request_more_info","route_to_human"]},
"reason": {"type":"string"}
},
"required":["category","priority","needs_human_review","next_action","reason"],
"additionalProperties": false
}這只是教學用的小 schema，不能保證所有平台或模型可以直接採用。實際送出前要依供應商 API 的欄位名稱、模型版本與支援範圍調整。例如 OpenAI 的 Structured Outputs 與 Gemini 的 structured output 都只支援 JSON Schema 的一部分，而且子集不同；完整 schema 在某平台可用，在另一平台可能被拒絕或無法落實相同約束。
特別注意：needs_human_review 與 next_action 都只是模型的建議，不是授權。應用程式仍須套用獨立的政策與權限檢查；不能因為模型回傳 false，就略過原本必須的人工核准。
response format 和 tool calling 有什麼不同？
response format（或 API 中相近名稱的結構化回應設定）是規定模型「最後回給應用程式的答案」長什麼樣子，適合把分類、抽取結果或介面所需資料交給後端。相對地，tool calling 是模型提出「請應用程式執行某個工具」及其參數，例如查詢資料庫、建立工單或呼叫計算服務；應用程式執行工具後，可以把結果送回模型或交給後續流程。
Gemini 官方文件將兩者區分為：structured outputs 著重格式化最終回應，function calling 著重在對話中採取行動。兩者可以組合，但不能把工具參數誤當成已完成的業務動作。執行前仍應驗證參數、權限、範圍與副作用；OpenAI 也建議需要連接工具或應用功能時使用 function calling，而需要規定模型回應形狀時使用結構化輸出。
平台限制、拒答與驗證失敗都要設計
不要把 strict 或 structured output 當成永不失敗的保證。OpenAI 文件說明應處理安全拒答、內容過濾或達到輸出上限等情況；應依使用的 API 檢查狀態、拒答欄位與不完整原因，再決定重試、轉人工或回傳可理解的錯誤。即使成功解析，也要做 schema 與語意驗證。
Gemini 文件說明 structured output 支援 JSON Schema 子集，部分約束仍須由應用程式自行驗證。過於龐大、深層或分支很多的 schema 也可能被服務拒絕。平台、模型與 API 版本會改變支援清單，所以部署時應把 schema 測試、錯誤分流與版本升級納入維護。
一個可採用的錯誤路徑是：解析失敗時保留受控的診斷紀錄，評估是否有限次重試；schema 驗證失敗就標為待修正；事實或商業規則失敗就要求補資料或轉人工；拒答則依安全政策提供替代回應。不要無限重試，也不要把錯誤值悄悄改成預設值。若紀錄原始回應，須先處理敏感資訊、存取權限與保存期限。
驗證器的責任邊界也要寫清楚。它可以判斷欄位是否存在、型別是否正確，卻不會自動知道某個日期是否與活動日程相符，也不會理解「高優先級」是否需要主管批准。把這些判斷拆成可測試的規則，才能在換模型或換供應商時維持一致行為。
導入前的實務檢查清單
- 先決定要約束的是最終答案，還是要呼叫的工具，再選結構化回應設定或 tool calling。
- schema 保持小而清楚，必要欄位使用明確型別與 enum。
- 應用程式端再次驗證日期、金額、狀態與權限。
- 為拒答、截斷、網路錯誤、驗證失敗與空值定義處理路徑。
- 保留適當的 request id 與驗證結果，避免無限制儲存敏感內容。
- 高風險動作停在獨立的政策檢查與核准點。
AI 結構化輸出的價值不是讓 AI 變得全知，而是把不確定的自然語言，轉成系統能檢查的資料，再由規則與人負責最後決定。
常見問題 FAQ
Q：有了 JSON Schema，就能保證答案正確嗎？
不能。它用來描述與驗證資料形狀及相關約束；事實、日期、枚舉意義和商業規則仍需外部驗證。
Q：JSON mode 和 Structured Outputs 要選哪個？
需要固定資料契約且平台支援時，可優先考慮 schema 約束。若使用 JSON mode，仍要搭配程式驗證與錯誤處理。
Q：什麼時候用 tool calling？
當模型需要請應用程式查資料或採取動作時用 tool calling；只想把模型回答交給程式解析時，用 response format 類的結構化輸出。
官方來源：