換了大模型，原來能用的AI功能為什麼出錯了？

一、先記錄變化，不要在生產中反覆試提示詞

從一個失敗任務開始儲存輸入、預期結果、實際輸出、時間和任務編號。記錄模型供應商、實際使用版本、生成配置、提示模板、知識索引、工具定義與應用提交。若使用別名或自動更新服務，向供應商核實是否變化，不假定同一名稱始終代表同一能力。日誌先脫敏，生產憑據不能出現在公開討論或諮詢截圖中。保留舊配置，才能讓後續排查有對照。

把同期變更列成時間線：模型更新、文件匯入、切分規則調整、提示釋出、介面欄位變化和許可權調整。若多個變數一起變了，先在測試環境恢復可比較組合，再逐項排查。生產資料不能拿來盲目重複寫入。業務已經受影響時，先暫停高風險自動動作，保留查詢或人工草稿入口，說明臨時處理方式與恢復負責人，而不是邊試邊讓所有使用者繼續使用。

二、用固定任務比較，不用幾次聊天代替驗收

樣本應來自經過授權和脫敏的真實任務，覆蓋常見工作與低頻高損失例外。每條樣本寫明正確欄位、允許引用的資料、可以執行的動作和必須交人工的條件。業務負責人確認預期答案，研發人員負責可重複執行。模型自己給自己評分只能作輔助，不能代替金額、日期、歸屬和許可權的明確檢查；含糊爭議樣本先人工澄清，再進入固定任務集。

相同輸入也可能出現不同結果。對容易波動的關鍵任務按事先約定重複執行，記錄每次結果，而不是挑出最好的一次截圖。比較質量之外，還要檢查拒答、許可權、工具呼叫、延遲、人工修改與成本。不同環境或資料版本的結果不能直接相減當成升級收益。測試透過只證明約定樣本與條件下的表現，不等於承諾所有未來任務都正確。

三、合同資訊提取的迴歸設計示例

以下是流程設計示例，不是知華客戶實測案例。某合同工作臺提取簽約主體、金額、到期日和續約條件，並生成待審提醒。準備常規合同、掃描不清、補充協議修改日期、無到期日和無權訪問五類樣本。新模型能讀出更多文字，卻把補充協議日期當成原始到期日，這類錯誤不能被“整體準確率提高”抵消。系統應展示欄位來源，由業務人員確認後才建立正式提醒。

示例測試集若有20條，其中18條正確、2條錯誤，只能說明本次這20條的結果；若錯誤涉及其他公司資料洩露，就應停止釋出，而不是用90%的平均值作透過理由。重複試驗次數、樣本組成和模型配置都應在記錄中可查。這些數字是驗收口徑算例，不是專案成果或承諾。實際專案由雙方根據業務損失定義嚴重錯誤與透過條件，不能套用統一比例。

窄屏可左右滑動表格檢視全部列。

四、灰度釋出要能停，也要知道怎樣恢復

先在不寫生產資料的測試或旁路環境比較，再選擇已授權的小範圍使用者試用。旁路執行仍會產生呼叫費用和日誌，也不能繞過資料授權。設定觀察範圍、稽核負責人、停止條件和回訪時間，不能無限期讓試點處於無人負責狀態。員工應能看到當前結果是否為草稿、是否需要確認，以及舊流程在哪裡，避免介面先換了但操作責任沒有說明。

恢復計劃區分應用版本、模型配置、知識索引和業務資料。舊模型若已停止服務，不能承諾一鍵回退；已傳送提醒或寫入記錄也不能靠換回模型撤銷。停止接收新任務後，記錄正在處理、已完成和狀態不明的任務，分別完成、暫停或人工核對。再次開放前複測受影響樣本，向相關使用者說明哪些結果需要重新檢查，儲存事件經過與後續預防措施。

五、員工報錯後，負責人具體看哪些記錄

員工報“這次答案不對”，處理入口應允許標記對應任務與錯誤型別，而不是要求複製所有聊天。負責人先核對輸入是否改變、是否使用有效知識、是否檢索到必要條款，再看模型輸出與工具結果。合同提醒日期錯了，可能是資料識別問題，也可能是日期解釋或時區轉換錯誤；按階段檢視證據，才能確定修哪個模組。結果記錄要顯示原始依據、處理版本和人工修改，員工不應承擔技術定位責任，只需說明哪裡與業務預期不同。

覆盤不要只留下“模型不穩定”四個字。為失敗記錄歸因狀態、影響使用者、臨時措施、下一位負責人和複查條件；確認缺少資料時補資料，確認規則不清時由業務人員澄清，確認介面錯誤時修改介面。暫時無法解釋的故障應標為待驗證，不編一個原因關閉。修復之後把對應失敗轉成迴歸樣本，並檢查同類場景，但不要把未經授權的客戶原文直接複製到團隊公共樣本庫。保留資料範圍與有效期，避免測試本身成為洩露入口。

六、費用比較要按完成的業務任務計算

便宜的單次呼叫並不一定使系統整體便宜。一個任務若先失敗、重複呼叫，再需要人工重新核對，最終成本包括模型、檢索、工具與員工工時。對比時固定任務範圍、測試環境和樣本，分別列首次完成、重試後完成、人工接管和最終未完成的數量，不把失敗任務從統計中刪掉。人工處理時間用約定方式記錄，沒有測量就註明未統計；不能把AI每次生成的字數直接折算成節省了多少人力。

模型價格下降但輸出變長，或者工具規劃增加多輪呼叫，都可能改變費用。預算應包含試驗呼叫與正式執行，並約定限額、告警和超過限額後的行為。沒有足夠業務樣本時，先報告試驗成本，不把試驗平均數直接承諾為未來所有月份的賬單。客戶關心的是在可接受錯誤與處理時長下完成了什麼，而不是只聽到某款模型更便宜。方案可以先鎖定一個高價值任務，確認整體成本，再決定是否擴大使用部門。

七、報價、維護責任與接管資料怎麼約定

把變更診斷、固定任務集、適配整改、灰度和後續維護分開報價。已經有版本與日誌的專案，定位範圍通常更明確；沒有測試基線、知識來源和介面說明時，需要先補資料。模型呼叫、測試環境及第三方訂閱由誰承擔，應與研發費用分開列。先限定受影響模組和可檢查成果，不在尚未看到系統時承諾全部問題都能一次解決。

交付資料包含版本差異、固定任務集、逐項結果、嚴重失敗、修復記錄、釋出與恢復步驟和已知限制。把模型變更、客戶資料更新、新需求和原有缺陷分別記錄，按協議確認責任，不把所有變動都叫質保。維護人員應能重複執行評測並找到正在使用的配置。諮詢時先提供故障現象、開始時間與脫敏樣本，我們協助判斷需要排查哪一層，首次溝通不必提供生產賬號。

官方資料與核對範圍

參考資料核對日期：2026-10-06。平臺能力會隨版本、套餐、地區和許可權變化；資料用於說明技術能力，不代表搜尋量、知華客戶成果或原廠合作資質。

• Anthropic：成功標準與評測設計（外部參考）