JSON 提示不是祕密武器：OpenAI 與 Gemini 的結構化輸出實務

要求模型「請用 JSON 回答」很方便，但它不是 GPT 或 Gemini 的祕密武器，也不是把文字變成可靠系統的充分條件。對人類閱讀而言，格式漂亮的 JSON 已經很有幫助；對程式而言，還需要明確欄位、型別、允許值、錯誤處理與後續驗證。這也是為什麼今天的模型 API 多半把 JSON 提示與結構化輸出分成不同層次。

本文聚焦在實務上的選擇：什麼時候只是提示模型輸出 JSON、什麼時候應使用 API 的結構化輸出，以及在 OpenAI 與 Gemini 等不同供應商之間，如何把資料契約設計得比較容易維護。若想先理解 JSON Schema 與應用程式驗證的基本觀念，可先閱讀本站的〈JSON 提示與結構化輸出：讓 LLM 結果可驗證、可串接〉。

JSON 提示、結構化輸出與工具呼叫，差在哪裡？

JSON 提示（JSON prompting）是以自然語言要求模型採用 JSON 格式，例如「請回傳 title、summary、tags 三個欄位」。這對快速原型或人工檢視很方便，但模型仍可能遺漏欄位、加入說明文字，或輸出不符合預期的型別。

結構化輸出（structured outputs）則把 schema 提供給 API，要求模型回覆符合指定結構。OpenAI 的文件將它描述為讓文字回覆遵守開發者提供的 JSON Schema；Gemini 也提供以 schema 指定 JSON 回覆的能力，但各平台支援的 JSON Schema 範圍與 API 寫法可能不同。OpenAI Structured model outputs　Gemini Structured outputs

工具／函式呼叫（function calling）則用於模型需要提出「下一步要呼叫哪個工具、帶哪些參數」的情境。工具呼叫不是讓模型直接取得執行權；應由應用程式驗證參數、檢查權限，再決定是否真的執行。

先從「結果要被誰使用」設計 schema

不要從「模型能產生什麼」開始，而要從下游程式需要什麼開始。例如客服分流流程需要的可能不是一段漂亮摘要，而是可被路由規則使用的 intent、優先級與需要人工處理的旗標。JSON Schema 的作用就是描述資料的結構與限制；它本身不是商業規則或真實性判定。JSON Schema：What is a schema?

{
  "type": "object",
  "properties": {
    "intent": {"type": "string", "enum": ["billing", "technical", "other"]},
    "priority": {"type": "string", "enum": ["low", "normal", "high"]},
    "needs_human_review": {"type": "boolean"}
  },
  "required": ["intent", "priority", "needs_human_review"],
  "additionalProperties": false
}

這個例子限制了可用分類與必填欄位，但它仍無法保證模型把每一封信分對類。應用程式仍要依實際情境驗證：輸入是否完整、使用者是否有權看到相關資料、high priority 是否符合組織規則，以及遇到不確定案例時是否交給人員覆核。

設計可維護的結構：六個原則

1. 讓欄位服務明確動作

每個欄位都應對應到顯示、儲存、搜尋、路由或人工審核需求。若下游沒有使用方式，就不要為了「資料完整」任意增加欄位。

2. 型別與列舉越明確越好

當值只能是幾種狀態時，用 enum 比自由文字更容易驗證；數字、日期、布林值與陣列也應使用相應型別。描述欄位語意可以協助模型理解，但描述不能取代程式驗證。

3. 把未知與缺失設計進去

不要逼模型在證據不足時猜答案。視情況允許 null、unknown 或 needs_human_review，並讓流程知道該如何處理這些狀態。這比看似完整但不可靠的資料更安全。

4. schema 保持小而可測

過深的巢狀結構、大量互相依賴的條件與一次塞進所有未來需求的 schema，都會提高理解與相容成本。先支援一個可驗證的任務，並保留版本號與測試案例，再逐步擴充。

5. 為供應商差異預留轉接層

OpenAI、Gemini 與其他服務的 request 欄位、支援的 schema 子集、拒答與串流行為都可能不同。把共同 schema、模型呼叫轉接、回應解析與驗證分開，能讓日後換模型或 API 版本時，不必改動整個業務流程。

6. 先驗證，再授權，再執行

即使回覆通過 JSON Schema，也只代表其結構符合要求。若結果會建立工單、寄信、修改資料或呼叫外部 API，流程至少應有結構驗證、商業規則／語意驗證、權限檢查與可追溯紀錄；高影響動作還應加入人工核准或明確的自動化界線。

如何選擇：三種常見情境

只用 JSON 提示：適合教學、快速探索、內容仍由人閱讀，或沒有任何自動化下游動作的情境。程式若要解析，仍須做好重試與失敗處理。

使用結構化輸出：適合資料擷取、分類、生成 UI 所需欄位、建立草稿紀錄等需要穩定資料形狀的流程。它能減少格式不一致的處理，但不會替你判斷事實正確性。

使用函式呼叫：適合模型需要提出資料查詢、建立草稿或要求下一步工具操作的流程。應把「模型提出請求」與「系統批准並執行」視為兩個不同步驟。

上線前應該測什麼？

• 正常、空白、矛盾、超長與多語輸入能否產生可處理的結果。
• schema 不符、模型拒答、逾時、部分串流內容與供應商錯誤時，介面與後端如何退回安全狀態。
• 分類、抽取或工具參數是否符合實際任務；這需要標註資料或人工抽查，而不只是 JSON parse 成功。
• schema、提示、模型版本與驗證規則更新後，舊資料與下游程式是否仍可相容。

常見問題

結構化輸出能保證答案正確嗎？

不能。它主要讓輸出結構更可預期；事實、推論、分類與權限仍需由資料來源、商業規則、測試與人工覆核共同驗證。

同一份 JSON Schema 能直接用在所有模型嗎？

不一定。JSON Schema 是共同語言，但不同 API 支援的關鍵字與限制可能不同。應把 schema 視為核心資料契約，並以供應商轉接層與整合測試處理差異。

能否讓模型產生 JSON 後直接呼叫內部 API？

不應直接把模型輸出當作授權。先做格式與語意驗證，再依目前登入者權限、環境與動作風險決定是否執行，並保留稽核紀錄。

結語

JSON 提示是很好的起點，結構化輸出則讓應用程式有更清楚的資料契約；兩者都不是取代驗證與授權的捷徑。先定義下游需要的資料、用小而明確的 schema 測試真實案例、把模型輸出與實際行動隔開，才能讓 OpenAI、Gemini 或其他模型成為可靠流程中的一個元件。

資料來源與延伸閱讀：

• OpenAI：Structured model outputs
• Google AI for Developers：Gemini Structured outputs
• JSON Schema：What is a schema?