別把「Prompt 調優」當成工程能力：在 AI 交付中建立「確定性契約」的實戰思考

在 AI Lab 的實際交付過程中，我觀察到一個非常普遍的誤區：很多工程師將大部分精力投入到了所謂的「Prompt 調優」中。他們透過不斷地嘗試不同的措辭、增加範例（Few-shot）、甚至在 Prompt 中加入「你是一位資深專家」這類心理暗示，試圖透過這種方式來提高模型輸出的穩定性。

然而，從工程化交付的角度來看，依賴 Prompt 調優來保證品質是一種極其危險的行為。因為 Prompt 本質上是一種「軟約束」，它在面對模型版本升級、輸入分佈漂移或長文本干擾時，表現出的是極強的隨機性。

真正的 AI 工程能力，不應該是如何寫出更好的 Prompt，而應該是如何在不確定的模型輸出與確定的業務需求之間，建立一套「確定性契約」。

從「希望它正確」到「強制它正確」

在一個典型的 AI 任務流中，如果你的驗收標準是「輸出看起來像那麼回事」，那麼你永遠無法實現真正的自動化交付。我們需要將關注點從 Prompt 的措辭轉移到**結構化契約**上。

1. 強類型輸出契約 (Schema Enforcement)

不要指望模型透過 \`Please output in JSON format\` 來保證格式。在生產環境中，必須使用 JSON Schema 或 Pydantic 等工具進行強校驗。如果模型輸出不符合 Schema，直接觸發重試機制或回退到預定義的安全模板，而不是試圖在程式碼裡用複雜的正則表達式去解析一個可能缺失欄位的 JSON。

2. 狀態機驅動的鏈路拆解

一個複雜的 AI 任務如果被塞進一個巨大的 Prompt 裡，其失敗率會隨著邏輯複雜度呈指數級增長。實戰經驗告訴我們，應該將任務拆解為多個微小的、可驗證的狀態節點。

- **節點 A**：僅負責提取實體 $\rightarrow$ 透過正則/Schema 校驗 $\rightarrow$ 進入節點 B。

- **節點 B**：基於實體進行邏輯推理 $\rightarrow$ 透過預設的知識庫比對 $\rightarrow$ 進入節點 C。

這種方式將一個巨大的「黑盒」變成了多個可觀測的「灰盒」，任何環節的失效都可以被精準定位並針對性優化。

「負面樣本集」比「正向範例」更重要

很多團隊在做 Few-shot 時，傾向於給模型提供幾個完美的正確範例。但在實際工程中，**定義什麼是「錯誤」比定義什麼是「正確」要高效得多**。

我們建立了一套名為 \`Negative-Case Library\` 的機制：記錄所有導致系統崩潰、產生幻覺或違反安全策略的真實輸入及其對應的錯誤輸出。在迭代過程中，我們不追求模型能寫出多麼驚豔的答案，而追求模型能夠穩定地避開這些已知的坑。

當一個新的 Prompt 版本發布時，它必須通過所有歷史負面樣本的回歸測試（即：不再產生之前的錯誤），才能被認為具備上線資格。這才是真正的品質底線。

總結：工程化的本質是消除隨機性

AI 的魅力在於其創造力（隨機性），但工程的本質則是消除隨機性。

如果你發現自己每天花 4 個小時在調整 Prompt 裡的一個形容詞，那麼你可能陷入了「煉金術師」的陷阱。請試著把目光移向：

- 如何定義更嚴苛的輸出 Schema？

- 如何將長鏈路拆解為可驗證的狀態機？

- 如何建構一套覆蓋全場景的負面樣本回歸集？

只有當我們將 AI 模型視為一個「不可靠但強大的元件」，並為其建構一套可靠的工程外殼時，AI Lab 的交付才能真正從「Demo 階段」走向「生產階段」。