別在 AI 交付中迷信「Prompt 最佳化」：為什麼「結構化資料流 + 狀態機」才是複雜業務的穩定性底線

在 AI Lab 的實際交付過程中，很多團隊在面對模型輸出不穩定、邏輯跳步或指令遺失時，第一反應通常是：「Prompt 寫得還不夠細」，於是開始在 Prompt 中加入大量的 Step-by-step、Do not do X 以及各種複雜的 Few-shot 範例。

這種做法在 Demo 階段非常有效，但在生產環境下，它是一個巨大的陷阱。

Prompt 的「邊際效用遞減」與「指令漂移」

當你試圖透過一個 2000 字的 Prompt 來覆蓋所有業務邊界情況時，你會發現兩個現象：
1. 指令漂移 (Instruction Drift)：模型在處理長文字輸入時，往往會對中間部分的指令產生忽略（Lost in the Middle），導致某些關鍵約束在特定輸入下失效。
2. 脆弱的穩定性：一次微小的模型版本更新或輸入分佈的變化，就可能讓原本精心調優的 Prompt 崩潰。

依賴 Prompt 來承載複雜業務邏輯，本質上是在用「自然語言」編寫一個沒有編譯器、沒有型別檢查且執行結果隨機的程式。

從「自然語言指令」轉向「結構化資料流」

真正工業級的 AI 交付，核心不在於如何寫出完美的 Prompt，而在於如何將業務邏輯從 Prompt 中剝離。

1. 將邏輯下沉到狀態機 (State Machine)

不要讓 LLM 決定「下一步該做什麼」，而應該由程式碼定義的有限狀態機（FSM）來驅動。
- 錯誤做法：Prompt 中寫 「如果你發現使用者在詢問價格，請跳轉到報價流程；如果使用者在抱怨，請跳轉到投訴流程」。
- 正確做法：LLM 只負責一個極小且純粹的任務——意圖識別 (Intent Classification)。它輸出一個結構化的 JSON（如 {"intent": "pricing_query"}），然後由後端程式碼根據這個標籤觸發對應的業務狀態轉移。

2. 用結構化 Schema 代替自然語言描述

與其告訴模型 「請輸出一個包含姓名、日期和金額的列表」，不如強制要求其遵循一個嚴格的 JSON Schema 或 Pydantic 模型。透過 json_mode 或 Function Calling，將 LLM 定位為一個非結構化資料到結構化資料的轉換器，而不是一個決策中心。

3. 建構「驗證-修正」閉環 (Verification Loop)

不要指望 LLM 一次性輸出正確結果。在生產環境中，每一個關鍵輸出都應該經過一個輕量級的驗證層：
- 格式校驗：JSON 是否合法？必填欄位是否缺失？
- 邏輯校驗：輸出的日期是否在合理範圍內？金額是否為正數？
- 自動修正：如果校驗失敗，將錯誤訊息回饋給模型進行一次快速重試（Self-Correction），而不是直接向使用者展示錯誤結果。

工程實踐總結：AI Lab 的交付金字塔

在建構複雜 AI 應用時，建議遵循以下優先順序：
1. 確定性程式碼 (Deterministic Code) $\rightarrow$ 處理所有能用 if/else 和正規表示式解決的邏輯。
2. 結構化路由 (Structured Routing) $\rightarrow$ 用 LLM 做分類 $\rightarrow$ 分發給不同的專項 Prompt/工具。
3. 原子化 Prompt (Atomic Prompts) $\rightarrow$ 每個 Prompt 只做一件事（例如：僅提取實體、僅潤飾語氣）。
4. Prompt 調優 (Prompt Tuning) $\rightarrow$ 最後才考慮透過措辭最佳化來提升那 5% 的效果。

結論： 文字鍊金術雖然迷人，但工程交付需要的是可預測性。把 LLM 當成一個強大的「機率性元件」而非「邏輯控制器」，才是從 Demo 到 Production 的唯一路徑。