別讓「Prompt 調優」成為你的心理安慰：AI 交付中的「確定性」陷阱

在 AI Lab 的交付現場，最常見的一個場景是：工程師面對一個失敗的 Case，迅速修改 Prompt，增加一條約束（例如：「請確保輸出格式為 JSON，不要包含任何解釋」），然後重新執行。當這個 Case 通過後，工程師會產生一種「問題已解決」的錯覺。

但事實是，這種基於單點 Case 的「打補丁」式調優，往往是在用一個 Bug 掩蓋另一個 Bug。

確定性陷阱：從「看起來對了」到「真的對了」

很多團隊在交付 AI 功能時，衡量標準是「抽樣驗證」。隨機抽 10 個 Case，如果 8 個對了，就認為可用。這種方法在傳統軟體工程中是不可想像的——你不會因為 80% 的程式碼行能跑通就發布版本。

AI 工程化的核心挑戰在於其機率性。當你為了修復 Case A 而修改 Prompt 時，你實際上是在高維空間中移動模型的決策邊界。這個移動可能會在不經意間破壞原本正常的 Case B 和 C。

這就是所謂的「確定性陷阱」：你追求的是區域正確性（Local Correctness），而犧牲了全域穩定性（Global Stability）。

實戰方案：建構「黃金資料集」 (Golden Dataset)

要擺脫這種焦慮，唯一的路徑是將 AI 的驗證從「感官判斷」轉向「量化度量」。

1. 定義黃金資料集

不要依賴隨機抽樣。你需要建構一個包含 50-200 個典型場景的黃金資料集。這個資料集必須包含：
- Happy Path: 標準輸入 $\rightarrow$ 標準輸出。
- Edge Cases: 空輸入、極端長文本、非法格式、矛盾指令。
- Regression Cases: 歷史上出現過的所有 Bug Case。

2. 實現自動化評測流水線

每次修改 Prompt 或更換模型版本後，必須強制執行全量評測：
- 硬匹配 (Exact Match): 對於格式要求嚴格的輸出（如 JSON key）。
- 語義匹配 (LLM-as-a-Judge): 使用更高階的模型（如 GPT-4o 或 Claude 3.5）作為裁判，根據預設的評分維度（準確性、完整性、語氣）給結果打分。
- 業務指標 (Business Metric): 例如提取出的實體是否在資料庫中真實存在。

3. 建立「回歸基準線」 (Baseline)

在任何優化開始前，先跑一遍當前版本的得分（例如：準確率 72%）。只有當新版本的得分 $\ge$ 基準線且關鍵 Case 全部通過時，才允許合併程式碼。

工程化反思：Prompt 是臨時方案，流程才是長期資產

很多開發者把 Prompt 當成程式碼來寫，試圖透過極其複雜的指令集來實現所有邏輯。但經驗告訴我們：Prompt 的複雜度與系統的脆弱性成正比。

真正的 AI 工程化應該是：
- 盡量簡化 Prompt: 只負責核心推理和格式轉換。
- 將邏輯外移: 能用 Python 程式碼實現的校驗邏輯（如正規表示法檢查、類型轉換），絕對不要交給 LLM 做。
- 閉環回饋: 將用戶回饋的 Bad Case 直接轉化為黃金資料集的新條目 $\rightarrow$ 觸發評測 $\rightarrow$ 指導調優 $\rightarrow$ 回歸驗證。

當你不再說「我覺得這次改對了」，而是說「這次修改讓黃金資料集的通過率從 82% 提升到了 85%，且沒有引入回歸 Bug」時，你才真正進入了 AI 工程化門檻。