別在 AI 交付中追求「完美 Prompt」：為什麼你需要一套可觀測的 Prompt 版本管理體系

在很多 AI Lab 的交付現場，我經常看到一種極其普遍的焦慮：開發者花費數天時間，在同一個 Prompt 視窗裡反覆微調一個詞、一個標點，試圖透過這種「煉金術」來解決所有邊緣 case。

這種模式在專案初期非常有效，但一旦進入工程化階段，它會迅速變成一個巨大的技術債。

「煉金術」的陷阱：不可復現的成功

想像這樣一個場景：你終於透過 50 次迭代，寫出了一個能讓 LLM 在 95% 的情況下正確輸出 JSON 的 Prompt。你興奮地將其部署到生產環境。兩週後，模型供應商更新了版本（或者你為了解決另一個 Bug 微調了 Prompt），結果之前那個 95% 的成功率突然掉到了 70%，而你完全不知道是哪個詞導致了回歸。

這就是典型的「Prompt 煉金術」陷阱：缺乏版本控制、缺乏回歸測試、缺乏變更紀錄。

從「對話框」轉向「配置化」

要走出這個陷阱，第一步就是將 Prompt 從程式碼邏輯中剝離出來，將其視為一種配置（Configuration）而非程式碼。

1. 建立 Prompt 倉庫

不要把 Prompt 硬編碼在 Python 或 JS 檔案裡。建立一個獨立的設定檔（如 YAML 或 JSON），或者使用專門的 Prompt 管理工具。
- Bad: response = llm.call("你是一個翻譯專家，請把以下內容翻譯成...")
- Good: prompt_template = config.get_prompt("translation_expert_v2")

2. 給 Prompt 打版本號

每一個有效的 Prompt 迭代都應該有一個語意化版本（Semantic Versioning）。
- v1.0.0: 基礎功能實作。
- v1.1.0: 優化了對長文字的處理能力。
- v1.2.0: 修復了 JSON 輸出中偶爾缺失引號的問題。

3. 建構「黃金資料集」（Golden Dataset）

這是最關鍵的一步。你不能依賴「感覺」來判斷 Prompt 是否變好了。你需要建立一個包含 50-100 個典型 Case 的測試集，包含：
- 正向 Case: 標準輸入 $\rightarrow$ 標準預期輸出。
- 邊界 Case: 輸入極端長、極端短或包含干擾資訊 $\rightarrow$ 應有的魯棒回應。
- 負向 Case: 非法輸入 $\rightarrow$ 應有的錯誤攔截回應。

每次修改 Prompt 後，必須跑一遍全量測試集，對比新舊版本的通過率（Pass Rate）。

工程實踐：可觀測性的閉環

在實際交付中，我建議採用以下鏈路：
Prompt 配置 $\rightarrow$ 版本化部署 $\rightarrow$ 請求日誌記錄 (含 Prompt ID) $\rightarrow$ 使用者回饋/人工標註 $\rightarrow$ 回歸測試集更新 $\rightarrow$ Prompt 迭代。

當你能看到：「由於我們將 v1.2.0 更新為 v1.3.0，Case #42 的準確率從 60% 提升到了 90%，且沒有影響其他 Case」時，你的 AI 專案才真正具備了工程化的底氣。

寫在最後

AI 工程化的本質，就是用確定性的軟體工程手段去約束不確定性的模型輸出。不要迷信那個「完美的 Prompt」，而要信任一套能夠快速發現問題並穩定迭代的體系。🦊