別把 AI 交付當成「寫程式」：為什麼 AI Lab 需要一套「工程化交付」的 SOP

在很多 AI Lab 的交付現場，我經常看到一種極其普遍的誤區：團隊習慣性地將 AI 專案的交付邏輯等同於傳統的軟體開發。

傳統的軟體開發邏輯是：需求 $\rightarrow$ 設計 $\rightarrow$ 編碼 $\rightarrow$ 測試 $\rightarrow$ 上線。在這個鏈路裡，只要程式邏輯正確，輸入 A 必然得到 B，確定性是最高優先級。

但在 AI 交付中，這種思維會導致嚴重的災難。因為 LLM 的本質是機率分佈，而非確定性邏輯。如果你試圖用「寫程式」的方式去交付一個 AI 應用，你很快會陷入一個死循環：微調 Prompt $\rightarrow$ 發現新 Bug $\rightarrow$ 修改 Prompt $\rightarrow$ 舊 Bug 回歸 $\rightarrow$ 崩潰。

真正的 AI 工程化交付，不應該關注於如何寫出那個「完美的 Prompt」，而應該關注於如何建構一套能夠容納不確定性的 SOP（標準作業程序）。

1. 從「單點調優」轉向「資料集驅動」

很多開發者在交付時最喜歡做的事情就是：在 Playground 裡試了 10 次，覺得效果不錯，然後直接把 Prompt 貼進程式碼裡提交。

這在工程上叫「倖存者偏差」。你看到的成功是隨機抽樣的結果，而不是系統性的能力。

工程化 SOP 要求：
- 建立黃金資料集 (Golden Dataset)：在開始任何調優前，必須先定義一個包含 50-100 個典型 Case 的測試集（包含正例、負例和邊界 Case）。
- 量化評估指標：不要說「感覺好多了」，要說「在 Golden Set 上，準確率從 65% 提升到了 82%，且沒有出現嚴重幻覺」。
- 迴歸測試機制：每一次 Prompt 的修改，必須全量跑一遍資料集。如果為了解決 Case A 而導致 Case B 退化，這次修改就是失敗的。

2. 建構「可干預」的中間層

AI 應用最忌諱的是「黑盒端到端」。如果你把所有邏輯都塞進一個巨大的 System Prompt 裡，一旦輸出出錯，你根本無法定位是哪個環節出了問題。

工程化 SOP 要求：
- 原子化任務拆解：將複雜的任務拆分為多個微小的 Step（例如：提取實體 $\rightarrow$ 查詢知識庫 $\rightarrow$ 生成草稿 $\rightarrow$ 自檢修正）。
- 顯式狀態傳遞：每個 Step 的輸出應該是結構化的（JSON），方便在中間層進行攔截和審計。
- 人工干預錨點 (Human-in-the-Loop)：在關鍵節點（如發送給客戶前）預留人工審核介面。AI 完成 90% 的工作，人類完成最後 10% 的確認。這比追求那永遠無法達到的 100% 全自動要高效得多。

3. 處理「機率性失效」的容錯設計

在傳統軟體中，Bug 是需要被修復的；但在 AI 應用中，某些機率性的失效是不可避免的成本。

工程化 SOP 要求：
- 優雅降級 (Graceful Degradation)：當 LLM 輸出格式錯誤或觸發安全過濾時，系統應該能自動切換到預設的範本回覆，而不是直接拋出 JSON 解析異常導致頁面崩潰。
- 自省循環 (Self-Reflection)：引入一個輕量級的檢查步驟（例如用更小、更快的模型檢查輸出是否符合格式要求），如果不符合則重新生成一次。
- 回饋閉環 (Feedback Loop)：在產品介面提供簡單的 👍/👎 回饋按鈕，將使用者認為「差」的 Case 直接回流到 Golden Dataset 中進行迭代。

寫在最後

AI Lab 的核心競爭力不在於誰能寫出最精妙的 Prompt，而在於誰能將這種不確定性的能力，「封裝」成一個確定性的產品體驗。

當你不再試圖透過一次性地編寫完美指令來解決問題，而是開始建構資料集、拆解任務鏈、設計容錯機制時，你才真正從一個「Prompt 工程愛好者」變成了一個「AI 工程專家」。