核心概念

把現有提示詞遷移到新模型後，測試案例失敗可能出於兩種截然不同的原因：一是新模型有能力，但行為不同，可以透過調整 prompt 修正；二是新模型能力本身不足，無論怎麼改提示詞都無效。在動手調整之前，必須先建立評估套件來分辨這兩種情況。

Anthropic 倫敦辦公室 Applied AI 工程師 Margot Vanlar 用電信公司客服機器人 Meridian Mobile 作為示範，說明評估套件裡需要三種測試案例：

  • 控制案例：沒有歧義、模型本來就處理得好的基準任務，應永遠通過
  • 邊界案例：過去曾出錯的情況，靠提示詞裡的明確指令防止再犯
  • 能力邊界案例：確認模型知道自己的邊界——什麼時候該升級給人工，什麼時候該拒絕

她為 Meridian Mobile 設了五個案例：查基本方案流量上限（控制案例）、計算 prorated 帳單、回答政策問題、偵測帳單錯誤時升級人工、以及不隱瞞手上有的資訊。

在針對個別失敗案例之前，她優先做結構清理——典型客服機器人的毛病是多人協作維護、政策語氣流程全混在一起、夾雜針對舊模型的修補指令。她發現提示詞裡有「機器人被定義為人類」、有從網站直接複製的 cookies 文字、所有指令堆在一個大段落。

清理做法：用 XML 標籤分區（角色定義、一般指引、政策、語氣各自獨立），並在提示詞末尾加輸出合約（output contract），用 XML 標籤定義輸出格式，配合 API 的 stop sequence 確保一致性。她的經驗法則：「如果你閱讀提示詞時無法區分指引和政策、數據，模型很可能也做不到。」

關鍵要點

陷阱一：舊模型的修補指令在新模型過度擬合

客戶查 legacy plan 的 hotspot 配額，模型明明有準確資料，卻叫客戶自己去 URL 查。原因是提示詞裡有一條舊指令：「不要給客戶錯誤的方案詳情，改為引導他們到 URL。」這條指令原本是防止幻覺的修補，但新模型的指令遵循能力更強，反而把「不給錯誤資訊」過度擴展成「不給任何資訊」。

教訓：模型不只會幻覺，也會隱瞞它實際有權取得的資訊。修補指令應該用版本控制記錄原因，方便日後回溯並刪除過時防禦。

陷阱二：指令不會增加能力，工具才能

模型被要求精確計算 prorated 帳單，卻只給出模糊推理，不給確切數字。提示詞裡寫著「必須正確計算 prorated 金額」——但這沒有用。告訴模型「算得準確很重要」，不會讓它更擅長心算。正確做法是給它一個工具（calculate_proration），並在 API 層定義工具的 schema 與數學邏輯。

陷阱三：只說故事的一面，模型會過度擬合

偵測到帳單衝突時，模型應升級人工，卻反而自己診斷解釋。原因是提示詞告訴模型「每次升級花費 $8，會算進快速解決率」——只說了升級的成本，沒說不升級的代價。修正是補上另一面：「升級 $8，但如果搞砸了，除了退款，還會失去客戶信任。」

核心原則：模型會優化一個目標。隨著模型變得更聰明，必須陳述權衡的兩面，因為模型正在變得更擅長自己做取捨。

實務應用

建立評估套件的順序建議：

  1. 先跑現有案例，確認哪些通過、哪些失敗
  2. 做一般性結構清理（XML 分區、角色描述、輸出合約），觀察改善幅度
  3. 逐一處理失敗案例，每次只改一個變數，確認修正效果
  4. 每條防禦性修改都加版本控制備注，記錄原始問題和修補理由

清理結構本身往往就能帶來顯著改善，不一定需要逐條調整。複雜輸出格式（如巢狀 JSON）可用 structured outputs 程式化保證格式，不依賴文字指令。

延伸觀點

學術研究與實務社群對 prompt 遷移與回歸測試有幾個交叉驗證的共識：

評估套件應從失敗案例增量建構，而非一次性設計齊全。 多個來源（arXiv 回歸測試研究、Substack LLM 測試實務）都指出，LLM 開發不像傳統 ML，不需要從一開始收集大型訓練集。實務上從 1-5 個手工案例開始，每次失敗就把那個案例加進測試集，持續累積。這個「敏捷評估」方法比預先規劃大型測試集更符合 LLM 迭代速度。

系統性結構化比對比直覺測試找到兩倍多的問題。 RETAIN（CMU 研究）的用戶實驗顯示，使用結構化工具對比新舊模型輸出差異的開發者，找到的錯誤數量是靠直覺手動測試的兩倍，且 prompt 實驗次數高出 75%。這呼應 Margot 先做結構清理、建評估套件、再逐一修正的順序——有框架的調試比「感覺哪裡怪就改哪裡」更有效率。

模型 API 的靜默更新是隱患。 arXiv 研究指出，即使 prompt 完全沒改，模型供應商的靜默升級（silent update）也會導致行為漂移。這意味著評估套件不只是遷移時的工具，而是持續監控的必要基礎設施——部署後仍需定期跑，而非一次性使用。

相關頁面：Prompt Engineering 進階技術：CoT、Few-shot 與提示鏈 | Generate-Evaluate-Repair：代理式排班系統的迭代設計

反向連結

以下頁面引用了本頁：