別把 AI 交付當成「對話」，而應將其視為「狀態機」的遷移

在 AI Lab 的實際交付中，我發現一個最致命的認知偏差：很多團隊將 LLM 的呼叫視為一種「對話（Conversation）」。他們試圖透過優化 Prompt 來讓模型「聽話」，但忽略了一個核心事實——在生產環境下，AI 交付的本質是狀態遷移（State Transition）。

對話思維 vs 狀態機思維

當你用「對話思維」建構系統時，你的關注點是：「我該怎麼描述這個任務，才能讓模型一次性輸出正確結果？」 這導致了大量的 Prompt 堆疊和不可控的隨機性。

而當你切換到「狀態機思維」時，你的關注點變成了：「當前輸入的狀態 $S_0$ 是什麼？經過哪個算子 $\text{Op}_n$ 後，它應該遷移到什麼樣的結構化狀態 $S_n$？」

實戰：將複雜任務拆解為「原子狀態遷移」

以一個複雜的法律合約審核 Pipeline 為例，如果直接問 AI 「這份合約是否有風險」，你得到的是一個不可預測的文字區塊。

我的工程實踐是將此過程拆解為四個明確的狀態遷移：

1. $\text{S}_0 \rightarrow \text{S}_1$ (結構化映射)：將非結構化文字轉換為 $\text{JSON}$ 格式的條款清單。斷言：所有條款必須被索引且無遺漏。
2. $\text{S}_1 \rightarrow \text{S}_2$ (衝突檢測)：對比條款清單與標準合規庫。輸出為 $\text{Conflict_List}$。斷言：衝突項必須關聯到具體的條款 ID。
3. $\text{S}_2 \rightarrow \text{S}_3$ (風險量化)：根據衝突嚴重程度打分。輸出為 $\text{Risk_Score_Map}$。
4. $\text{S}_3 \rightarrow \text{Output}$ (自然語言合成)：將量化分數還原為人類可讀的審核報告。

在這種架構下，AI 不再是那個「全能的黑盒」，而是一系列確定性算子的組合。如果最終結果錯了，我可以立刻透過檢查 $S_1, S_2, S_3$ 的快照，定位出是哪個算子發生了失效。

為什麼這種方法能解決「幻覺」？

幻覺通常發生在模型試圖在一次推理中完成過多邏輯跳躍時。透過強制狀態遷移，我們將原本巨大的邏輯跳躍 $\Delta L$ 拆分為多個微小的步進 $\delta l_1, \delta l_2, \dots, \delta l_n$。

每一步遷移都伴隨著結構化校驗（Schema Validation）。如果 $S_1$ 的 JSON 格式不對，Pipeline 直接熔斷並觸發重試或人工介入，而不是帶著錯誤地進入 $S_2$ 產生更嚴重的幻覺疊加。

給交付團隊的建議

不要試圖尋找那個完美的 Prompt，因為不存在。你應該做的是：

• 定義清晰的狀態快照：每一個中間步驟必須有可持久化的、可審計的結構化輸出。
• 建立算子級監控：監控每個狀態遷移節點的成功率和延遲，而不是只看端到端的成功率。
• 擁抱確定性編排：用程式碼（Python/TypeScript）控制流程邏輯，讓 LLM 只負責局部的、非結構化的資訊處理轉換。

將 AI 交付從「藝術」轉變為「工程」，唯一的路徑就是把對話變成狀態機。