別在 AI 交付中迷信「Prompt 調優」：為什麼「結構化輸出 (Structured Output)」才是工程化的分水嶺

在 AI Lab 的實際交付過程中，很多團隊在面對模型輸出不穩定、格式亂跳時，最本能的反應是：寫更長的 Prompt。

他們會花數小時甚至數天去打磨一段極其複雜的指令，比如：「請嚴格按照 JSON 格式輸出，不要包含任何解釋文字，確保 key 是 lowercase_snake_case，如果缺失欄位請填 null...」。結果是，模型在 90% 的情況下表現良好，但在剩下的 10% 中，它依然會偶爾加上一句 「Here is the JSON you requested:」，或者在某個深層嵌套的欄位裡漏掉一個引號。

對於 Demo 來說，這沒問題；但對於要跑在生產環境、被下游程式碼解析的工程化專案來說，這 10% 的不確定性就是災難。

從「祈禱」到「約束」

Prompt 調優本質上是一種「機率性祈禱」。你試圖透過增加上下文權重，讓模型在機率分佈上傾向於某種格式。而真正的工程化分水嶺在於：將對 Prompt 的依賴，轉化為對 Schema 的約束。

在實際的 AI 工程實踐中，我們建議採取以下三層遞進的約束策略：

1. 第一層：強類型 Schema 定義 (Pydantic/JSON Schema)

不要在 Prompt 裡描述 JSON 長什麼樣，而是直接定義一個 Pydantic 模型（或 JSON Schema）。
- 痛點：Prompt 描述的欄位名可能會被模型微調（例如 user_id 變成了 userId）。
- 方案：使用支援 response_format={"type": "json_schema", "json_schema": ...} 的 API（如 OpenAI 或最新的本地路由模型）。這在推理層面強制模型遵循特定的語法樹。

2. 第二層：輸出截斷與強制修復 (Post-processing Guardrails)

即便有了 Schema，網路傳輸或極端 Token 截斷仍可能導致 JSON 不完整。
- 工程實踐：引入輕量級的修復層（如 json-repair 或自訂正規表示式截斷）。
- 邏輯：先嘗試標準 json.loads $\rightarrow$ 若失敗 $\rightarrow$ 正規表示式提取第一個 { 和最後一個 } $\rightarrow$ 若仍失敗 $\rightarrow$ 呼叫極小規模的模型進行格式修復 $\rightarrow$ 最後才報錯。

3. 第三層：少樣本 (Few-Shot) 的結構化範例

與其告訴模型「不要做什麼」，不如給它三個「正確且極端」的例子。
- 關鍵點：範例中必須包含邊界情況（Edge Cases）。例如，如果某個欄位可能為空，範例中必須有一個該欄位為 null 的樣本。這比寫一萬字指令有效得多。

實戰教訓：一個關於「狀態機」的坑

我們在為一個自動化維運 Agent 建構狀態轉換邏輯時，最初使用了複雜的 Prompt 來要求模型輸出 {"next_state": "...", "action": "..."}。結果發現模型在處理複雜鏈路時經常產生幻覺，輸出一個不存在的狀態名。

我們將其改為：
1. 列舉約束：將所有合法狀態定義為 Enum 類型並傳給 API 的 Schema 參數。
2. 驗證閉環：解析出 next_state 後立即與狀態機定義比對 $\rightarrow$ 不匹配則立即觸發一次帶有錯誤資訊的重試（Retry with Error Feedback），而不是讓下游程式碼崩潰。

給工程團隊的建議

如果你發現你的團隊正在陷入「為了讓 AI 輸出正確格式而不斷修改 Prompt」的死迴圈中，請立刻停止這種行為。

記住：Prompt 是用來引導邏輯的，而 Schema 是用來保證交付的。

把精力從「如何寫更好的指令」轉移到「如何建構更魯棒的解析管道」上。當你不再需要祈禱模型「這次千萬別多說一句話」的時候，你的 AI 專案才真正進入了工程化階段。