JSON 提示與結構化輸出：讓 LLM 結果可驗證、可串接

要求 LLM「用 JSON 回答」很常見，但它不是讓應用程式可靠的魔法咒語。JSON 只能把輸出包成較容易讀取的資料格式；真正能讓流程穩定的，是清楚的欄位契約、結構驗證、業務規則檢查，以及把模型輸出當成不可信輸入來處理。

因此，JSON 提示最有價值的地方，不是讓模型看起來更工程化，而是讓模型與應用程式之間建立可測試的交接點。當輸出需要進入資料庫、表單、API、工作流或工具呼叫時，這個交接點尤其重要。

先分清楚：提示 JSON 與結構化輸出不是同一件事

最基本的做法是在提示中指定欄位，例如要求模型只回傳「標題、摘要、分類」。這有助於降低格式漂移，但模型仍可能加上說明文字、漏欄位、產生無法解析的 JSON，或把值填錯。

較進一步的做法是使用模型服務所提供的結構化輸出能力，將回應格式與 schema 一起交給 API。以 Gemini API 的文件為例，結構化輸出可依提供的 JSON Schema 產生可預期、型別安全的結果，適合資料擷取、分類與工具／API 工作流；但文件也明確提醒，即使輸出是語法正確的 JSON，應用程式仍要驗證值與處理語意正確性。Gemini API：Structured outputs

JSON Schema 解決的是結構，不是事實正確性

JSON Schema 是用來描述 JSON 資料結構與約束的宣告式語言。它可以定義物件有哪些欄位、哪些必填、型別是字串或整數、清單的項目格式，或某個值是否只能落在有限的 enum 之中。JSON Schema 官方說明

但 schema 通過不代表內容正確。例如：

• 日期是合法字串，不代表它真的是原始文件中的日期；
• 分類落在允許的 enum 內，不代表分類判斷合理；
• 金額是數字，不代表幣別、稅別或權限範圍正確；
• 工具呼叫參數符合格式，不代表該使用者有權執行那個動作。

JSON Schema 的文件也指出，複雜資料通常需要兩層驗證：一層檢查結構是否符合 schema，另一層以一般程式碼檢查欄位間的語意與業務規則。這正是 LLM 應用不能省略的第二道門。JSON Schema：結構與語意驗證

從自然語言需求開始設計輸出契約

與其先寫一段很長的提示，不如先回答四個問題：

1. 下游系統真正需要哪些欄位？
2. 每個欄位的型別、允許值與缺值規則是什麼？
3. 哪一些欄位可以由模型建議，哪一些必須由可靠資料來源提供？
4. 驗證失敗、資料不足或模型不確定時，系統要回傳什麼狀態？

例如，將客服來訊分流時，比起要求模型「分析後回 JSON」，更適合定義一個小而明確的契約：

{
  "intent": "billing | technical_support | account | other",
  "confidence": 0,
  "needs_human_review": false,
  "reason": "簡短、不可包含敏感資訊的說明"
}

這個格式仍需要配合 schema：把 intent 限制為 enum、把 confidence 限制為合理範圍、把所有必要欄位列為 required。更重要的是，應用程式應自行訂定何時必須人工覆核，例如低信心、含敏感資料、涉及帳務異動，或模型結果與既有規則衝突時。

提示內容應包含什麼？

在有 schema 的前提下，提示仍然很重要，因為 schema 只能說明形狀，不能完整表達任務意圖。實務上可將提示拆成幾部分：

• 角色與範圍：模型要做的是擷取、分類、摘要，還是提出待審核建議？
• 資料界線：哪些內容可作為來源，哪些欄位不得臆測或補寫？
• 判斷準則：分類定義、優先順序與遇到衝突時的處理方式。
• 未知狀態：資訊不足時，要求模型使用明確的 unknown、needs_review 或空值，而非猜測。
• 輸出約定：搭配 schema 使用欄位描述；不要把範例中的假資料誤當成唯一正解。

結構化輸出與工具呼叫如何分工？

結構化輸出通常用於「把最終答案交給程式」，例如要渲染一張 UI 卡片、寫入待審核紀錄或傳給下一個工作節點。工具呼叫則用於「模型希望系統做一件事」，例如查詢訂單或建立草稿。兩者可以配合，但不應混為一談。

如果模型提出工具呼叫，應用程式必須自己做驗證、授權與執行，而不是把 JSON 直接交給資料庫、shell 或內部 API。OWASP 將未妥善驗證與處理 LLM 輸出的情況列為風險，建議採零信任方式驗證模型回應、採用參數化查詢與情境化輸出編碼。OWASP：Improper Output Handling

一個穩健的處理流程

可將模型輸出接入下游系統的流程設計為：

1. 模型依提示與 schema 產生候選 JSON；
2. 應用程式先解析 JSON，再做 schema 驗證；
3. 檢查業務規則、資料來源、欄位關係與使用者權限；
4. 不通過時，回傳可診斷的錯誤或交給人工，而不是默默修正後直接執行；
5. 只有通過所有檢查的資料，才能進入工具、資料庫或外部服務；
6. 記錄 schema 版本、模型版本、驗證結果與必要的審核軌跡。

這種設計也讓測試變得具體：可以用正常輸入、漏欄位、額外欄位、惡意文字、跨語言內容與不合理值，確認系統每一層是否照預期拒絕或轉人工。

避免兩個常見誤區

誤區一：把 JSON 當成防呆機制

JSON 只是序列化格式。即使 API 保證回傳符合 schema 的結構，模型依然可能誤解原文、產生過時資訊，或在可選值之中選到錯誤項目。結構驗證要搭配來源驗證、商業規則、監測與人工覆核。

誤區二：讓 schema 無限膨脹

把所有判斷都塞進深層 schema，通常會讓模型、API 與維護者都更難處理。應先定義最小可用契約，將複雜的關聯檢查放在應用程式層。不同模型服務對 JSON Schema 的支援範圍也可能不同，因此上線前應以實際 API 與版本測試，而不是假設所有 schema 關鍵字都可用。

結語：把 JSON 視為契約，不是提示花樣

JSON 提示與結構化輸出能讓 LLM 更容易接進產品流程，但可靠性來自完整的交接設計：小而清楚的資料契約、schema 驗證、語意與權限檢查、受控工具執行，以及可觀察的錯誤處理。當這些層次都具備時，JSON 才不只是好看的格式，而是能讓 LLM 工作流更可測試、可維護的介面。