程式沒有部署，電話客服背後的模型卻換了。SpaceXSI 在 2026 年 10 月 14 日發布 Grok Voice 3.0，並表示使用 grok-voice-latest 的 Agent 已自動切換。維運團隊即使沒有改設定，也需要重新確認原本驗過的對話行為。
本文於台北時間 10 月 15 日查核官方公告、API 文件與 Artificial Analysis 公開評測，沒有呼叫付費 API，也沒有實測電話、中文辨識或工具執行。下列驗收流程是工程建議，不能當成 Grok 已通過的測試結果。
API 相容，仍需重新驗證任務
官方 release notes列出兩項變動：3.0 上線、2.0 棄用。這份紀錄也保留了先前時序：2.0 在 7 月 29 日發布，latest 從 8 月 5 日開始指向它。別名本來就是會移動的設定，不能拿它充當固定基準。
Speech to Speech 文件明確允許透過連線的 model query parameter 指定版本。現在可選 grok-voice-3.0，而 grok-voice-latest 指向同一版本；2.0 已標示 deprecated。官方表示 endpoint、session 參數與事件介面不變。
這足以支持「客戶端整合介面相容」，尚不足以支持「退款確認、插話後續接與轉人工都維持相同行為」。我的判斷是，模型版本應跟 prompt、工具 schema 一起進入發布紀錄。版本固定能降低別名漂移，文件卻沒有在此承諾永久保留舊模型，因此不能把回到 2.0 當成必然可用的復原方案。
0.81 秒要跟舊版的 0.70 秒一起看
截至查核時，Artificial Analysis 的語音評測頁列出 Grok Voice 3.0 的綜合指數為 86.9，2.0 為 81.3；τ-Voice 任務表現從 56.5% 升至 71.6%。同頁的首段音訊時間卻從 0.70 秒變成 0.81 秒，多了 0.11 秒。
這個 Time to First Audio 是 Big Bench Audio 資料集上的平均值，定義為產生第一個音訊 token 所需時間。它沒有直接量到你的電話線路、播放緩衝與後端查單時間，也不是 p95 延遲。指數上升與首段回應變慢可以同時成立。
因此，升級報告要分開回答兩個問題：任務是否更容易完成，使用者等多久才聽到可用的回答。不能把競品比較中的速度優勢，改寫成相較前代全面加速；也不能由這 0.11 秒推定自己的客服一定退步。那需要相同音檔、設定與服務路徑的量測。
驗收集要包含會改變訂單的那一句話
以下是本文建議的測試設計。選一批去識別化或合成的客服對話，固定語音、prompt、工具回傳、音訊編碼與網路條件，保存每次測試的時間。若舊版已無法呼叫，就以先前留下的紀錄作參照，並註明不能重跑的限制；不要假裝完成雙版本對照。
測試案例可以從四種失敗開始：
- 使用者報完訂單編號又更正最後兩碼，確認查詢參數採用更正值。
- 使用者在退款說明中插話「先不要退」，確認後端沒有收到退款操作。
- 工具逾時後恢復，確認相同請求不會重複建立案件或寫入訂單。
- 資料不足或身分驗證未完成時，確認系統停在查詢、補問或轉人工。
同一案例最好重複執行，保留每次結果，不要挑一段最自然的錄音代表整批。固定版本仍可能產生不同回答，因此驗收應檢查允許的行為範圍，而非要求逐字重現上一次回覆。
每個案例都應留下預期副作用、實際工具參數與後端結果。光聽到模型說「已取消」無法證明資料庫沒有寫入；語氣自然也無法代替授權檢查。執行回執與人工成本的討論可延伸成這裡的驗收紀錄：對話、工具呼叫與業務狀態必須對得上。
延遲紀錄要保留使用者聽到聲音的時刻
建議同時記錄使用者停止說話、收到第一段音訊、開始播放，以及業務操作完成的時間。第一段聲音可能只是「我幫你查一下」，回答內容要等後端回傳才完整；兩者分開，才能知道等待發生在模型、電話串接還是工具服務。若只留下整通電話總長，會很難判斷是哪個環節變慢。
測試時也應保留失敗分母。只計算成功回覆的延遲，容易漏掉逾時與中斷的通話；只看平均值，又可能掩蓋少數等待很久的使用者。測試量太少時，應直接標示樣本不足，避免把一次順暢的展示寫成正式服務保證。人工抽查可以優先聽那些工具成功、使用者卻重問或要求轉接的案例，補上機器紀錄看不到的困惑。
把停止條件寫進升級單
先用無真實寫入的測試環境驗證，再安排受控流量。下列 YAML 是本文建議的審查模板，不是供應商 API 設定，也沒有執行效果：
candidate_model: grok-voice-3.0
baseline: 待填舊版測試紀錄與日期
configuration: 待填語音、prompt 與工具 schema 版本
release_checks:
unauthorized_write: 出現即停止擴大流量
duplicate_side_effect: 出現即停止擴大流量
end_to_end_p95: 待填產品已接受的上限
task_success: 待填案例集與通過門檻
fallback: 待填已驗證的轉人工或受限查詢流程
owner: 待填當班負責人未授權寫入或重複副作用出現，就停止擴大流量。 這是本文提出的規則，並非公告所載的產品保證。品質與速度門檻則要按場景訂定：查營業時間與修改配送地址，不能共用同一種失敗容忍度。
放量期間若收到異常，升級單應能回到具體對話案例，而不是只有「新版比較慢」的抱怨。記錄案例識別碼、當時設定與業務結果即可；原始錄音另按公司的同意、保存期限與存取規則處理，不要為了除錯把完整客服資料散落在告警通知裡。
降級流程也要實際演練。若沒有可用舊模型，停用高風險寫入工具、保留查詢或轉人工，通常比臨時改回一個已棄用的名稱更可控。已完成的退款或出貨無法靠切回模型撤銷，必要的補償仍由業務系統處理。
每分鐘同價，仍要核對每件成功任務的帳
官方價格頁將 3.0 與已棄用的 2.0 都列為每分鐘 0.08 美元，另列每次文字輸入 0.004 美元。這是服務定價，不能直接換算成你的完整電話客服成本。
建議在同一批案例記錄通話時間、文字輸入、外部服務費與人工接手量。模型若多問兩輪才確認地址，即使分鐘單價沒變，完成任務的成本仍可能改變；反過來，能減少人工接手，也可能值得稍長的等待。這些都應由自己的紀錄回答。
這次可以先做一件小事：找出正式環境所有 grok-voice-latest，把實際指定值、最後驗收日期、測試紀錄與降級負責人放在同一張升級單。下次別名再切換時，團隊就知道哪些流程需要補驗，以及誰有權停止放量。