別把 Prompt 當成程式碼：在 AI 工程化中建立「設定-邏輯」的分離機制

在很多 AI Lab 的交付現場，我經常看到一種極其危險的模式：開發者將複雜的業務邏輯、資料清洗規則、甚至部分條件判斷，全部透過一個巨大的 Prompt「硬編碼」在 LLM 的輸入中。

這種做法在 Demo 階段非常高效——你只需要修改一段話，就能讓 AI 表現出截然不同的行為。但當專案進入生產環境，面對成千上萬次請求和多變的業務場景時，這種「Prompt-as-Code」的模式會迅速演變成一場維護噩夢。

1. 「Prompt 膨脹」帶來的工程危機

當業務邏輯被塞進 Prompt 時，你會發現自己陷入了以下循環：
- 不可預測的回歸：為了修復 A 場景的一個 Bug，你微調了 Prompt 中的一句話，結果導致原本正常的 B 場景突然崩潰。
- 除錯黑盒：當輸出結果不符合預期時，你無法透過中斷點或日誌知道是哪個「指令」失效了，只能透過不斷嘗試不同的措辭（Prompt Engineering）來祈禱它生效。
- 版本管理缺失：Git 對程式碼的 Diff 非常清晰，但對一個 2000 字 Prompt 的微小措辭修改幾乎沒有語意上的追蹤能力。

2. 核心方案：設定與邏輯的徹底分離

真正的 AI 工程化應該是：LLM 只負責執行原子化的認知任務，而流程控制、狀態管理和資料驗證由確定性的程式碼（Python/TS）掌控。

A. 將「指令」轉化為「參數化範本」

不要寫 如果使用者是 VIP 請用禮貌語氣，而應該在程式碼層判斷使用者等級，然後向 LLM 傳遞一個明確的參數：{ "tone": "polite", "user_status": "VIP" }。
Prompt 應該是一個純粹的範本（Template），所有的變數在執行時由程式碼注入。這樣你可以獨立地對範本進行版本控制（例如儲存在資料庫或設定檔中），而無需觸動核心邏輯程式碼。

B. 用「結構化輸出」替代「自然語言約定」

很多團隊習慣在 Prompt 裡寫 請以 JSON 格式回傳，不要包含任何解釋。這依然是不穩定的。
工程化的做法是強制要求 LLM 輸出嚴格的 Schema（如使用 JSON Mode 或 Function Calling），並在接收端立即進行 Pydantic 等強類型驗證。如果驗證失敗，直接觸發重試機制或回退到備援方案，而不是讓錯誤的結果流向下一個環節。

C. 建構「認知原語」而非「全能助手」

不要試圖建構一個能處理所有事情的「超級 Agent」。將複雜的任務拆解為一系列原子化的認知原語（Cognitive Primitives）：
- 原語1：提取實體 $\rightarrow$ 輸出 JSON $\rightarrow$ 程式碼驗證 $\rightarrow$ 儲存資料庫。
- 原語2：根據資料庫上下文生成摘要 $\rightarrow$ 輸出文字 $\rightarrow$ 程式碼過濾敏感詞 $\rightarrow$ 回傳使用者。

3. 實戰教訓：從「調優措辭」到「優化鏈路」

在一個實際的法律文件分析專案中，我們最初嘗試透過一個超長 Prompt 讓 AI 完成【閱讀 $\rightarrow$ 分類 $\rightarrow$ 提取條款 $\rightarrow$ 對比差異】的所有步驟。結果是模型經常遺漏細節且極不穩定。

我們將其重構為一條流水線：
1. 分段切片（確定性程式碼）$\rightarrow$ 2. 關鍵資訊提取（原子 Prompt）$\rightarrow$ 3. 結構化儲存（資料庫）$\rightarrow$ 4. 對比演算法（程式碼 + LLM 定點分析）。

重構後，系統的穩健性提升了 40%，且每次出錯都能精準定位到是哪個環節的問題——是切片太碎？還是提取原語失效？還是對比邏輯有誤？

結語

AI 工程化的本質不是研究如何寫出完美的 Prompt，而是研究如何用確定性的軟體工程手段去包裹不確定性的模型輸出。當你開始把 Prompt 當成一種可替換的「設定」，而不是不可觸碰的「黑盒邏輯」時，你的系統才真正具備了規模化交付的能力。