別讓「Prompt 調優」成為工程化的遮羞布：AI Lab 交付中的結構化輸出與 Schema 強制約束

在 AI Lab 的實際交付中，很多團隊在面對模型輸出不穩定時，最習慣的反應是：「再寫幾句 Prompt，給它幾個 Few-Shot 範例，應該能搞定。」

這種思維方式在 Demo 階段非常有效，但在真正的工程化交付（Production-ready）中，過度依賴 Prompt 調優往往成了掩蓋系統架構缺陷的「遮羞布」。當你試圖透過增加 Prompt 長度來解決一個機率性的格式錯誤時，你實際上是在用一種不可預測的手段去對抗另一種不可預測性。

從「希望它輸出 JSON」到「強制它符合 Schema」

在早期的 Agent 開發中，我們經常在 Prompt 末尾加上：Please output in JSON format. Ensure the keys are 'status' and 'reason'.

結果是：模型在 95% 的時間裡表現完美，但在剩下的 5% 時間裡，它可能會突然加上 ```json 的 Markdown 標籤，或者在 JSON 結尾多出一個逗號，導致下游解析器直接崩潰。

工程化的底線是：不要信任 LLM 的自覺性。

在 AI Lab 的成熟交付鏈路中，我們採取的是「Schema-First」策略：
1. 定義嚴格的 Pydantic 模型/JSON Schema：首先定義資料結構的真理來源（Source of Truth），而不是在 Prompt 中描述它。
2. 利用 Function Calling / Tool Use：將輸出目標定義為工具呼叫。這迫使模型進入一種特定的解碼模式，其格式穩定性遠高於純文字生成。
3. 強校驗與自動重試機制：在解析層引入嚴格的驗證邏輯。如果輸出不符合 Schema，立即觸發一次帶有錯誤資訊的重試（Error-feedback loop），而不是簡單地報錯。

實戰教訓：為什麼 Few-Shot 不能替代結構化約束？

我曾見過一個處理複雜金融報表的專案，團隊嘗試透過提供 10 個完美的 Few-Shot 範例來引導模型提取資料。結果發現，隨著輸入文件長度增加，模型開始在長文字的干擾下丟失對格式的記憶。

當我們把這套邏輯改為 Structured Output (如 OpenAI 的 json_schema 或本地模型的 Constrained Decoding) 後，解析成功率從 88% 直接提升到了 99.9%。

核心差異在於： Few-Shot 是在給模型提供「參考答案」，而結構化約束是在給模型安裝「護欄」。前者依賴於模型的模仿能力（機率），後者依賴於解碼時的 token 過濾（確定性）。

給 AI 工程實踐者的三條建議

1. Prompt 是用來定義邏輯的，不是用來定義格式的。如果你發現自己在 Prompt 裡花了大量篇幅描述 JSON 的 key 該怎麼寫，請立刻轉向 Function Calling 或結構化輸出介面。
2. 建立「解析失敗 $\rightarrow$ 回饋 $\rightarrow$ 重試」的閉環。不要試圖一次性寫出完美的 Prompt 來消除所有錯誤，而要建構一個能夠自我修復的 pipeline。
3. 脫離對特定模型的依賴。當你使用結構化約束而非特定模型的 Prompt Trick 時，你的系統將更容易在不同規模的模型（如從 GPT-4o 到 Llama-3）之間遷移。

真正的 AI 工程化，就是把 LLM 當成一個極其聰明但極不守規矩的員工——你不能指望他每次都記得格式要求，你得給他一套他無法繞過的填表系統。