為什麼 Prompt 需要版本控制
很多團隊一開始會把 Prompt 放在程式碼裡、環境變數裡，或甚至直接存在後台欄位。這在驗證概念時很快，但進入生產環境後會出現幾個問題：誰改了 Prompt、為什麼改、影響哪些使用情境、能不能回到前一版，通常都說不清楚。AI 功能不像傳統規則引擎，輸出結果受到 Prompt、模型、檢索資料、工具呼叫與輸入內容共同影響。只改一段指令，就可能讓客服回答變得更保守，也可能讓內部助理開始引用不該引用的欄位。
我們通常建議把 Prompt 視為產品邏輯的一部分，而不是文案資產。它應該有版本、審查、測試、發佈紀錄與回滾方式。這不代表每一次標點調整都要走冗長流程，而是要讓重要變更有清楚邊界。尤其在 RAG、LINE 客服、ERP 查詢、CRM 摘要、報價輔助等場景中，Prompt 會決定模型如何解讀資料與如何拒答，因此管理方式會直接影響營運風險。
把 Prompt 拆成可維護的層次
生產環境中的 Prompt 不應該只是一大段文字。比較穩定的做法，是依照責任拆成幾個層次：系統角色、任務指令、輸出格式、領域規則、安全限制、範例、以及從資料庫或檢索系統帶入的上下文。拆分的好處是每個變更都有明確目的。例如，調整輸出格式不應該同時改變拒答規則；新增產品知識也不應該混在模型行為規範裡。
版本設計也要跟這個拆分一致。常見做法是為每個 Prompt 模組建立名稱與版本，例如 customer_support.system.v3、quote_summary.format.v2。應用程式呼叫時記錄實際使用的 prompt_id、prompt_version、model、retrieval_policy 與工具版本。當使用者回報某次回答不正確時，工程團隊才有辦法重建當時條件，而不是靠記憶猜測。
- 系統指令應該相對穩定，放入角色、語氣、安全邊界與不可違反的規則。
- 任務指令描述這次要完成的工作，例如整理會議紀錄、查詢訂單、產生 LINE 回覆草稿。
- 輸出格式要盡量明確，特別是後端會解析 JSON、欄位或狀態碼時。
- 領域規則適合獨立維護，避免散落在多個 Prompt 裡造成不同功能回答不一致。
- 範例要少而精準，並標記它們是格式示範、語氣示範，還是決策示範。
變更前要先定義測試與評估方式
Prompt 變更最容易犯的錯，是只用幾個手動問題看起來正常就上線。比較務實的方式，是為每個重要 AI 功能建立一組固定測試案例，包含常見問題、邊界問題、惡意或越權輸入、資料不足的情境，以及必須拒答的情境。測試不一定一開始就要完全自動化，但至少要能在每次改版時重跑，並保存輸入、檢索內容、模型輸出與人工判斷。
評估標準也要比「答案好不好」更具體。客服助理可以看是否引用正確政策、是否沒有承諾不存在的服務、是否能要求補充資訊；ERP 查詢助理可以看是否使用正確欄位、是否避免猜測數字、是否把查詢限制說清楚；內部知識助理可以看是否標註來源、是否承認資料不足。只要標準具體，Prompt 討論就會從主觀喜好轉成工程判斷。
在模型升級時，測試更重要。同一份 Prompt 在新模型上通常會變得更能遵循格式，也可能變得更主動推論。這不一定是壞事，但需要被看見。建議把模型版本也納入發佈紀錄，避免把模型行為改變誤判成 Prompt 退化。
發佈流程要支援灰度、回滾與觀測
Prompt 上線不應該只有覆蓋舊文字這一種方式。實務上，我們會希望有開發版、測試版與生產版，並讓少量內部使用者或特定流程先使用新版本。若系統允許，也可以依照客戶、部門、渠道或功能開關指定 Prompt 版本。這對企業整合尤其重要，因為 LINE 客服、網站表單、內部後台與業務助理可能共用一部分邏輯，但承受風險的方式不同。
觀測資料應該包含 Prompt 版本與輸出結果的關聯。只看整體滿意度或錯誤率通常不夠，因為問題可能只出現在某一類輸入或某個資料來源。最基本的紀錄包含請求時間、使用者或租戶識別、Prompt 版本、模型、檢索命中的文件、工具呼叫結果、輸出摘要與人工回饋。涉及個資或商業機密時，紀錄要先做遮罩或只保存必要片段。
回滾也要被事先設計。若新 Prompt 造成格式解析失敗、回答過度承諾、成本明顯增加，團隊應能快速切回上一個穩定版本。這就是為什麼 Prompt 不適合只存在無版本的管理後台。可以存在後台，但後台背後仍應有版本、審核與發佈狀態。
治理不是讓團隊變慢，而是讓變更可控
Prompt 管理最好的狀態，是產品、客服、法務或營運能提出修改需求，但最終變更仍能被工程化地驗證。對小團隊而言，用 Git 管理 Prompt 檔案、加上簡單的測試案例與發佈紀錄，通常已經足夠。對多租戶或多部門系統，則可能需要 Prompt registry、審批流程、版本別設定、環境隔離與稽核紀錄。
是否導入完整平台，取決於幾個條件：AI 功能是否直接面對客戶、輸出是否會觸發交易或系統動作、是否需要符合內部稽核、是否有多個團隊同時維護、是否經常更換模型或資料來源。風險越高，Prompt 就越接近程式碼與設定管理；風險較低時，也至少要保留版本與基本測試。
企業 AI 專案真正難的地方，常常不是第一版 Prompt，而是半年後還能知道每個 AI 行為從哪裡來、為什麼這樣回答、如何穩定改善。把 Prompt 納入版本控制、測試與發佈流程，是讓 AI 助理從展示走向可營運系統的基本工程工作。