當我們希望把 AI 整合進公司軟體或系統時，如果 AI 回傳的是「一大段自由發揮的文字」，電腦程式會很難讀取與解析。這時候我們需要讓 AI 使用 JSON（結構化資料格式） 進行溝通：

• JSON 輸出/輸入 Schema（結構清單）：就像給 AI 一張「規格明確的欄位扣繳憑單」。我們明確規定欄位名稱（如product_name）、資料型態（字串、數字、陣列、日期格式等），AI 就會乖乖填入相應欄位，不會瞎編無關的欄位。
• JSON Repair（JSON 自動修補技術）：JSON 雖然好用，但它需要寫很多引號與括號，會消耗大量的 Token。當 AI 的回答達到 Token 長度上限而被硬性截斷（Truncation）時，常會因為「少寫了結尾括號}或]」而變成壞掉的 JSON，導致後端程式當機。JSON Repair 就像是一個「自動修補工具」，能自動補齊殘缺的括號與語法瑕疵，讓系統順利解析資料。

🎯 核心重點

1. JSON 輸出的關鍵優勢：
   • 輸出樣式恆定：方便軟體直接解析，無需手動切割字串。
   • 聚焦於核心數據：避免模型輸出無關的贅詞。
   • 有效抑制幻覺（Less chance for hallucinations）：強迫模型遵守結構欄位，能降低模型瞎編資料的機率。
   • 具備關聯性與型態：支援資料型態（Data types）定義，且資料可自動排序（例如處理 Datetime 時間物件非常方便）。
2. JSON Schema 作為輸入指引（Working with Schemas）：
   • JSON 不僅能用於輸出，也能用於預處理輸入資料（Input）。
   • 透過 JSON Schema 為輸入數據建立明確藍圖（Blueprint），能幫助模型將注意力聚焦在關鍵屬性上，減少誤讀風險。
   • 加入特定格式的日期/時間欄位（如format: "date"），能使模型具備「時間感知能力（Time-aware）」。
3. JSON 輸出的隱患與截斷（Truncation）：
   • 代價與成本高：JSON 的結構符號多，相比純文字會消耗顯著更多的 Token，導致處理時間變長與運算成本增加。
   • 截斷導致語法失效：當 Token 達到上限時，模型會在半途中斷生成，導致 JSON 缺乏閉合括號（Missing closing braces/brackets），變成無效格式。
4. JSON Repair 自動修復技術：
   • 在真實工程環境中，可搭配如 PyPI 上提供的json-repair等第三方程式庫，自動修復缺損或格式不齊全的 JSON 物件，確保系統運作不中斷。

💡 實際例子（電商商品資料庫建置）

1. 提供 JSON Schema 與輸入（Input Schema）：

我們向 AI 提供定義良好的產品規格 Schema，並傳入產品資料：

{ "name": "Wireless Headphones", "category": "Electronics", "price": 99.99, "features": ["Noise cancellation", "Bluetooth 5.0", "20-hour battery life"], "release_date": "2023-10-27" } 

1. 要求輸出 JSON 格式（Output）：

AI 能精準抓取屬性，並輸出結構化 JSON，方便後端直接寫入資料庫：

{ "products": [ { "name": "Wireless Headphones", "price": 99.99, "in_stock": true } ] } 

1. 發生截斷與 JSON Repair 修復：

• AI 輸出到一半被截斷（壞掉的 JSON）： {"name": "Wireless Headphones", "price": 99.99 (缺少右括號}__)
• 經過 json-repair 工具處理後： {"name": "Wireless Headphones", "price": 99.99} (自動補全右括號，使程式能成功編譯！)

❌ 常見錯誤

1. 以為 JSON 輸出完全沒有缺點：忽略了 JSON 會消耗大量 Token、增加延遲與成本，且在長文輸出時極易因為 Token 限制被截斷。
2. 模型輸出截斷後直接用json.loads()解析：直接解析被硬性截斷的 JSON 會導致程式直接拋出 Parsing Error 崩潰，應在後端加入 JSON Repair 工具或 Retry 機制。
3. 只寫「請給我 JSON」，卻沒提供 Schema：如果沒有提供具體的 JSON Schema 或欄位範例，模型可能會自行創造欄位名稱（如這次叫cost，下次叫price），導致系統編譯失敗。

📖 來源依據

內容依據《Prompt Engineering》教材：

• JSON 輸出優點與降低幻覺：第 21 頁、第 60–61 頁
• JSON Repair 與 Token 截斷問題：第 61 頁
• Working with Schemas（JSON Schema 輸入結構與時間感知）：第 62–63 頁

📝 3 題理解測驗

第 1 題（單選題） 關於在提示詞中使用 JSON 格式 進行資料處理的敘述，下列何者不正確？ (A) 要求模型輸出 JSON 格式有助於建立結構，並有效降低「幻覺（Hallucinations）」。 (B) JSON 格式非常簡潔，消耗的 Token 數量遠比純文字少，因此能顯著降低 API 成本。 (C) 使用 JSON Schema 可以為輸入數據建立藍圖，幫助模型關注重點欄位。 (D) 加入日期或時間格式的欄位（如 release_date），有助於讓模型具備「時間感知」能力。

第 2 題（單選題） 在真實工程系統中，為什麼我們常需要搭配 json-repair 等第三方程式庫？ (A) 因為 LLM 完全看不懂 JSON 格式，需要靠它翻譯。 (B) 因為當模型達到 Token 長度限制而被硬性截斷時，輸出的 JSON 會缺少結尾括號變為無效格式，json-repair 能自動修復殘缺的 JSON。 (C) 因為它能把模型 Temperature 自動調整為 0。 (D) 因為它能自動刪除 JSON 中的所有數字欄位。

第 3 題（應用簡答題） 如果你的軟體系統需要呼叫 LLM 幫忙抽取文章中的「人名、日期、事件」，為了確保每次 LLM 回傳的資料欄位名稱都一模一樣（不會這次回傳 Date，下次回傳 Time），你在撰寫提示詞時應該採取什麼做法？

測驗答案：（參考）
第1題：B。它需要寫很多引號與括號，會消耗大量的 Token。
第2題：B 。因為當模型達到 Token 長度限制而被硬性截斷時，輸出的 JSON 會缺少結尾括號變為無效格式，json-repair 能自動修復殘缺的 JSON。
第3題：

• 提示詞使用JSON格式。
• 例如：
  {
  "name": "Wireless Headphones",
  "date": "2023-10-27",
  "event": "Financial Statements"
  }

要求輸出 JSON 格式（Output）

註1：
這「學習系列」的文章，是記錄自己與AI一起探索知識的過程，也是我將AI做為私人家教的一項實驗。對於如何藉由Ai輔助自我學習，請參考這篇：
https://blog.udn.com/tku_89056/192561353
https://goldenbird-willy.blogspot.com/2026/09/gemini-notebook-ai.html

學習教材：《Prompt Engineering》
本書探討了提示工程的核心概念、多種進階技巧、以及最佳實務（use cases）。內容涵蓋如何設定大型語言模型的輸出長度與取樣參數，並且介紹零樣本、少樣本、角色扮演、思維鏈、以及如何結合外部工具的推理與行動等實用策略。此外，本書也示範了如何利用人工智慧來編寫、解釋、翻譯和除錯程式碼。最後，本書提供了多項專業的建議，例如簡化提示設計、優先使用正面指令、利用如JSON的結構化格式、以及落實詳盡的版本記錄與迭代。
本書作者Lee Boonstra是一名人工智慧軟體工程師、技術主管和系統架構師，在谷歌全球首席技術官辦公室（OCTO）、應用創新工廠等擁有10年以上的資歷。
免費下載：https://www.kaggle.com/whitepaper-prompt-engineering