一段提示詞能在聊天視窗裡得到好答案，不代表團隊已經擁有一項可長期使用的資產。真正進入客服、行銷、內部知識問答或文件處理後，提示詞會被多人修改、套用不同資料，也會遇到模型升級與需求改變。若只把「目前有效的那一版」貼在群組裡，幾週後往往沒人知道誰改了什麼、為何改、出了問題要退回哪裡。
這也是AI 提示詞管理的起點：把提示詞當成可維護的工作元件，而不是某位同事的個人技巧。做法可以很小：固定模板、分離變數、留下版本紀錄，再用代表性測試題檢查改動。
OpenAI 的提示詞工程文件提醒，模型甚至同一家族的不同 snapshot 也可能有不同表現，因此生產環境宜在支援時固定模型版本，並建立測試與評估套件來監測提示詞或模型變更的影響。這個原則同樣適用於沒有 API 的團隊，只是記錄方式可以更簡單。
先把模板和每次輸入分開
可維護的提示詞模板，應該把穩定的規則和每次才會變動的資料拆開。模板負責角色、任務、輸出格式與限制；變數則放入客戶問題、文件內容、語言、產品名稱或日期。這樣做的好處不是讓答案必然一致，而是讓團隊知道究竟改了規則，還是換了輸入。
一份提示詞卡固定寫下五件事：用途、輸入、輸出、限制、維護負責人。輸入列出必填欄位，輸出寫清楚格式與口吻，限制說明遇到未知資料時怎麼處理；維護負責人負責審核與更新。
用途：把客服來信整理成可供人工覆核的繁中回覆草稿。
輸入：問題內容、已確認的產品資訊、客戶希望的語言；若缺少關鍵資訊，請先列出要追問的項目。
輸出：先給「問題摘要」，再給「回覆草稿」，使用禮貌、簡潔口吻；不要捏造退款期限、承諾或不存在的政策。
限制：只能根據提供的資料回答；不確定時明確標示「待確認」。
變數可以用表格欄位、表單欄位或程式參數表示，例如「客戶問題」與「已確認政策」兩個欄位。OpenAI 的文件也以模板語法示範，把測試資料中的動態欄位插入評估；在一般團隊中，使用一致的欄位名稱已足夠，不必一開始就建立複雜平台。
Prompt 版本控制不是只改檔名
每次修改提示詞，都留下簡短的變更紀錄：版本號、日期、修改人、改動原因、影響範圍、是否通過測試，以及可以回復的上一版。像「v1.3：把缺資料時直接回答改為先追問」比「最新版」有用得多。若技術同事已使用 Git，可把模板、測試題與結果一起提交；非技術團隊則可用共享文件的版本紀錄，但要指定維護負責人和審核節點。
同一筆紀錄還應保存模型 ID 或 snapshot、溫度等可用參數、系統提示的其他設定、知識來源版本與測試日期。這是為了在結果變差時分辨原因：若提示詞沒改，但模型換代或知識文件更新，就不能把影響誤判成提示詞改動。固定模型版本是增加可比性的手段，並不等於每次輸出都會 100% 相同。
平台功能會變動。OpenAI 的提示詞工程文件目前建議新的工程工作把生產提示詞放在應用程式碼中，搭配型別化輸入、程式碼審查、測試與部署流程，並說明既有 reusable prompt objects 的退場與遷移。因此，不宜籠統宣稱每個 API 平台或一般聊天介面都支援固定版本或 pin 模型。先查自己使用的產品文件，再選擇適用的版本功能、共享文件或 Git；如果介面無法固定模型，就把顯示的模型名稱與使用日期記下來，並承認比較仍有限制。
測試題要故意包含「不順的情境」
提示詞測試不是找三個漂亮案例證明新版本很好，而是建立能揭露風險的題目。一組起始測試可以分成四類：正常資料、缺資料、模糊要求、互相衝突的指示。正常題看任務是否完成；缺資料題看模型會不會先問；模糊題看它是否指出需要釐清；衝突題看它是否遵守工作規則，而不是照單全收。這四類只是起點，不代表已涵蓋所有使用情境。
測試前先寫判定準則，避免看完答案才臨時改標準。例如：不得編造承諾或政策；資料不足時先提出必要問題；輸出必須符合指定欄位；口吻要一致；若引用知識來源，不能把來源沒有的內容說成已確認。可用「通過／不通過」搭配一句理由，也可對格式、事實、完整性與語氣分別評分。Anthropic 官方建議成功標準要具體、可衡量且貼近真實用途，評估資料也要納入邊界情境，而不只測理想案例。
測試集不必一開始就很大，但不要只挑成功例。保留曾經失敗的輸入，將它變成下一次修改的回歸題；每次版本都用同一批核心題比較，另外加入未用於調整模板的新題，降低過度迎合舊題的風險。不要把真實客戶個資、密碼、API key 或其他憑證放進測試集，優先使用合成資料；其他資料也要先確認授權與去識別處理。
比較版本時，先鎖定條件再看結果
比較 v1 和 v2 時，盡量固定模型 ID、參數、輸入資料、知識來源、工具設定與測試方式，否則你看到的差異可能來自模型升級或資料變動。OpenAI 的 Evals 文件將流程概括為描述任務、用測試輸入執行、分析結果再迭代；這個思路也可以用試算表手動落地。API 團隊可採用仍受支援的評估工具或自建測試，非工程團隊則可在共享文件中保留輸入、兩版輸出、判定與人工覆核。
自動檢查適合驗證固定格式、必要欄位等明確條件；人工覆核則適合判斷語氣、是否真的回答問題、是否不當延伸。必要時可用另一個模型輔助評分，但先用人工抽查它的可靠性。少量樣本通過，不代表全面變好；若 v2 在正常題更順，卻在缺資料題開始亂猜，就不能只看平均印象。
讓團隊採用一個可回復的最小制度
第一週不必建立大平台。選一個高頻、風險可控的工作，建立一張提示詞卡、初始測試集與變更紀錄。先讓一小組使用，收集失敗例；通過人工覆核後再逐步擴大。任何新版本都保留舊版與回復方法。
這種制度的價值，在於把「我覺得這版比較好」變成可討論的證據：哪類題改善、哪類題退步、改動是否值得。它不保證輸出完全穩定，也不會消除模型判斷的不確定性，但能讓團隊少花時間重複試錯，並在問題發生時找回背景。
FAQ：團隊開始管理提示詞前常見疑問
一定要用 Git 才算版本控制嗎？
不一定。技術團隊可用 Git 取得審查、比較與回復能力；一般團隊先用有版本歷史的共享文件也可以，重點是版本號、維護負責人、變更原因與測試紀錄不能缺。
固定模型版本後，答案是不是就完全一樣？
不是。輸入、上下文、服務設定與模型本身的非決定性都可能影響結果。固定版本是方便比較和定位，不是輸出一致性的保證。
測試題越多越好嗎？
數量重要，但代表性更重要。起始測試應包含正常、缺資料、模糊與衝突情境，並保留失敗例做回歸；少量全對不能推論所有情況都可靠。
虛構客服回信範例
以下僅供示意，不代表任何服務的真實政策，不能未經人工覆核就直接寄給客戶：
問題摘要：客戶詢問帳單中的一筆加購項目。
回覆草稿：您好，感謝您的來信。目前提供的資料不足以核對該項目的啟用紀錄與付款明細，需要由負責人透過核准管道查核。現階段無法先承諾退款或完成時間，相關結果仍待確認。
要做好團隊 AI 協作，把提示詞當成團隊資產，並不是把創意變成僵硬規則，而是讓每次改進都有脈絡、有測試、有退路。從一個用途清楚的模板開始，逐步累積版本與失敗案例，通常比一開始追求一套龐大的管理系統更容易持續。