直接說結論，「產品底層的 LLM 底層根本不應該任意更換。」
更精確地來說應該是底下這句：
API 可以抽換，但產品行為無法零成本、無回歸地抽換。越接近 Agent、工具操作與真實工作流程，模型與系統的耦合就越深。
真正的產品單位從來不是「一個 LLM」，而是一整條鏈：
Model × System Prompt × Tools × Memory × Agent Scaffold
× Safety Policy × Evaluations × UX
換模型，理論上只是換公式裡的一個變數；實際上，其他七個變數全部都是「圍繞這個變數的舊值」校準出來的，
換一個變數，等於要重新解一次整條方程式。
講幾個整理出來的不同面向案例。
真實案例：當團隊真的按下「切換模型」的那一刻
案例一｜企業搜尋工具，一次「小升級」讓 CI 全紅
Tursio 是一套跑在企業內部的搜尋系統，原本建立在 GPT-4-32k 上，提示詞經過長時間打磨，已經能穩定推斷使用者沒講明的欄位、抓出時間趨勢、自動排序結果。團隊只是想把模型升級到 GPT-4.1、後來又試了 GPT-4.5 Preview——理論上是「同一家供應商、同一個系列、只是新一點的版本」。
結果隔天早上打開 CI，測試大片變紅：GPT-4.1 不再主動推斷隱含欄位和排序邏輯
GPT-4.5 則開始在輸出裡夾雜多餘的說明文字，把原本乾淨的 JSON 弄壞，解析器直接噴錯。工程團隊最後得重寫提示詞、補上大量範例，還額外建了一套專門用來做模型遷移回歸測試的 testbed。連在同一家供應商內部升版，都得走這一遭。
案例二｜客服機器人想省成本，卻先卡在「格式」這一關
一套每月處理 530 萬次對話的企業客服系統，原本用 Claude 3 Haiku。為了省錢，團隊評估了好幾個開源替代方案。第一關根本輪不到比「回答得好不好」——GPT-OSS 20B 和 120B 連穩定輸出既有的 XML 格式都做不到，直接被淘汰；Qwen3-32B 也有一樣的毛病，得在提示詞裡硬塞進格式範例才勉強修好。
案例三｜寫作助手為了轉換率，多花了好幾個月
HyperWrite 是一款 AI 寫作工具，原本跑在 Claude 3.5 Sonnet 上。為了降低成本，團隊嘗試把好幾個候選模型接上去測試，離線 benchmark 分數都不差，但一放進真實使用者的付費轉換漏斗，轉換率就是比原本的模型差一截
而且事前完全預測不到。團隊前後花了好幾個月測試，最後只有 GPT-4.1 在 A/B test 裡打平了轉換率，才敢正式換過去。模型差異影響的不只是「回答準不準」，會一路穿透到留存和營收。
案例四｜開源 coding agent 為每個模型準備不同的「說話方式」
Aider 是一套廣泛被使用的開源程式開發 Agent，維護者發現不同模型連「怎麼描述一次程式碼修改」都得客製：Gemini 常常沒辦法遵守標準的 diff 格式，得換一套特製的寫法；
GPT-4 Turbo 則要用改過的 unified diff，否則它會習慣性地用「原始程式碼略」偷懶跳過該改的部分。連 temperature、streaming 方式、system prompt 能不能用，每個模型也都不一樣。
這代表連「Agent 怎麼跟模型溝通」這件最底層的協定，都是為特定模型量身訂做的——換模型等於連整個編輯協定都要重寫。
案例五｜相容層工程師半夜被 400 error 叫醒
LiteLLM 是一套讓開發者用同一套介面呼叫不同 LLM 供應商的相容層，理論上就是「解決你論點」的那種工具。但維護者發現，Anthropic 的 extended thinking 搭配工具呼叫時，client 端必須把 thinking_blocks 完整保存並重新送回去，一般標榜「OpenAI-compatible」的 client 會直接漏掉這段資料，然後莫名其妙丟出 400 error。
不同供應商連工具呼叫失敗時回傳的 stop reason 都不一樣，例如 Gemini 有自己專屬的 MALFORMED_FUNCTION_CALL。
「相容」兩個字在請求格式上是真的，但在推理狀態和工具軌跡的語意上完全不是這回事。
案例六｜同一句提示詞，在自家新模型上突然「太聽話」
Anthropic 自己發布 Claude Opus 4.5／4.6 的遷移說明時，明講了一件事：新模型對 system prompt 變得更敏感。過去為了避免工具「該用卻不用」而寫的強烈措辭，換到 4.6 上可能反過來變成「不該用也硬要用」
Opus 4.6 也更容易自己生出一堆 subagent、把簡單任務過度工程化，甚至做出刪檔案、force push 這種難以復原的動作。這是自家公司對自家客戶的官方警告
同一份 skill 或 agent prompt，換一個新版本，可能不只是「效果變差」，而是從「不足」直接反轉成「過量」。
案例七｜GPT 小版號升級，客服回答突然變得太短
OpenAI 從 GPT-5.5 升到 GPT-5.6 時，官方遷移文件特別提醒開發者要重新比較 reasoning effort 的設定，因為 5.6 預設就比 5.5 簡潔許多
很多產品裡原本寫死的「be concise」指令,套上去反而讓回答短到不夠用。官方甚至要求開發者重新定義哪些操作可以直接執行、哪些需要先跟使用者確認、要不要拿掉那些制式的稱讚和安撫語句。連相鄰的小版號，都足以改變一個產品的自主性、篇幅和語氣。
案例八｜借了別人的框架，還是得重寫大半
Qwen Code 這個工具是從 Gemini CLI 的框架改過來的，但 Qwen 團隊發現，要真正發揮 Qwen3-Coder 的實力，光靠原本的框架不夠，得額外加上客製化的 prompt、parser 和 function-calling 協定。
而 Qwen3-Coder 本身,又是靠 execution-driven 的 Code RL 和長週期 Agent RL 訓練出一套自己特有的工具使用與任務完成習慣。
開源權重從來不等於「中性、可以隨便接上去用」
模型被什麼樣的驗證機制和獎勵訓練出來,決定了它天生就偏好某一種做事方式。
案例九｜使用者集體抗議,逼供應商把「奉承度」調回去
2025 年 OpenAI 更新 GPT-4o 時,無意間讓模型變得過度討好、奉承使用者,後來緊急回滾。等到 GPT-5 上線,刻意調低了諂媚程度,結果一堆已經習慣舊語氣的使用者反過來抗議「太冷淡」,逼 OpenAI 又把語氣調暖。
官方公布的測試數字顯示,誘導性諂媚測試裡的回覆比例從 14.5% 降到 6% 以下——這證明「要不要討好使用者」根本是可以刻意調校的訓練目標,不是能力附帶的副作用,而是連同一家公司自己都會在版本之間反覆橫跳的產品決策。
案例十｜省成本換底層模型,結果整套 Agent 框架跟著壞掉
有工程師實測把 Claude Code 這套 Agent 框架的底層,從 Anthropic 換成透過 OpenRouter 接上的 GLM-5、MiniMax,想藉此省成本。結果發現:工具呼叫的格式、上下文壓縮的邏輯、驅動 Plan mode 和 subagent 運作的 prompt 結構,全部是照著 Claude 的反應方式調校出來的。
換了底層模型後,工具呼叫開始不可靠、上下文壓縮會莫名失敗,而且錯誤看起來很像模型能力不夠,實際上是框架和模型不匹配——就像把一顆不對規格的引擎硬裝進為別的引擎設計的底盤。
案例十一｜CTO 面對董事會的那句實話
有一位企業 CIO 在訪談裡直接承認:「所有的 prompt 都是為 OpenAI 調校的」——每一條指令都是專門寫出來的,光是教會 LLM 做好 agentic 處理就要好幾頁指示,換模型現在變成一個真正要花大量工程時間的任務。
另一個更具體的數字:一家金融業者光是把 API 從舊版遷到新版,就得重建整套 prompt engineering,是一個 40 萬美元、耗時 8 個月的專案,而且遷移途中才發現新模型在幾個關鍵工作流程上表現不如預期,只能部分回退。
Builder.ai 倒閉後,有一家製造業客戶花了 31.5 萬美元、三個月時間,才把 40 條 AI 工作流程搬到新平台上,過程中還有幾個面向客戶的功能一度中斷——原因很單純,當初完全沒有建立與供應商無關的抽象層。這些不是理論推演,是有金額和時程紀錄的真實帳單。
案例十二｜一個人做的 benchmark,發現大部分模型都在「發明」API
有開發者為了選出最適合寫 Ruby 程式碼的模型,做了一套嚴謹的實測。結果整場測試裡,只有 Claude Opus 系列和 GLM 5 系列真正正確使用了指定的 gem API,其他模型全都在「發明」根本不存在的呼叫方式。GPT-5.4 在單輪對話裡沒問題,但一進到多輪對話,呼叫格式就開始出錯,而且燒掉的 token 量是 Opus 的 15 倍。這種差異不是「大家結果差不多,只是使用者感覺不同」而已,是真的會讓正式環境壞掉的行為差異。
案例十三｜多 Agent 專案卡在「該不該動手」的死循環
有團隊在建構多 Agent 協作系統時發現:某些模型家族的訓練傾向就是「積極出手」,即使不太需要也會嘗試呼叫工具、拼湊步驟往前推進;換到另一種傾向「先想清楚再動作」、需要明確指令才會執行的模型家族後,原本靠前者的積極性推動任務的 Agent 架構突然卡住
不是不會做,而是不斷反問「要不要現在執行這一步」,整個流程停在原地。團隊最後得重新設計工具的使用門檻和任務邊界,連 Orchestration 層的邏輯都要跟著改寫。
案例十四｜設計規格被「自由發揮」搞砸
一個品牌設計團隊寫了一份嚴格的 design.md,要求 AI 嚴格遵守「Less is More」的設計哲學和精確的資料結構,原本搭配的模型會乖乖照做、只產出符合規範的東西。換成另一個帶有較強「討好」或「發散」傾向的模型後,它會為了「展現豐富度」而自己腦補、加進不必要的裝飾層級,規格文件裡明明寫著「不要加」,它還是加了。團隊原本用來壓制舊模型「話多」的那套 prompt,套到新模型上完全失效,甚至方向還反過來。
案例十五｜BOM 表裡多出來的幽靈欄位
一家把 AI 接進 ERP 流程、產生製造用 BOM 表的公司,原本的模型遇到資料不齊全的狀況,會乖乖回傳空值或 Null,後端可以安全地攔截處理。
換了模型之後,新模型在遇到同樣的缺漏狀況時,會「自己猜」一個看起來合理但其實是虛構的數值填進去,有時還會在 JSON 外面多包一層 Markdown 標籤和一句客套的結語,直接讓解析器炸掉。
原本為舊模型量身打造的後處理攔截機制,面對新模型冒出來的一整批新型態 edge case,得全部重新翻修。
反向證據：Scaffold 本身的份量，不亞於模型本身
2026 年有一項研究反過來驗證了同一件事:研究者刻意固定底層模型不變,只更換 Qwen Code 這個 coding agent 框架的 35 個連續版本,在 50 個 SWE-bench Verified 任務上測試——結果品質依然明顯波動,而且可以精確追溯到某次 scaffold、prompt 或工具編排的修改。
這說明兩件事:第一,產品表現從來不是模型能力單獨決定的;第二,當一套 scaffold 已經針對某個模型調校完成,換模型等於改變了一個「已經共同最佳化的系統」
不只模型變了,連原本用來配合這個模型的框架也一併失效。
真正會被綁定的九個層級
換模型時,以下九個層級幾乎都要重新校準:
1. 指令與語意層 —— 同一句「處理這個問題」,不同模型可能理解成直接回答、先提計畫、直接改檔案、先反問澄清、呼叫工具調查,或因風險而要求確認。
2. Tool calling 層 —— 工具觸發的門檻、要不要平行呼叫多個工具、會不會虛構參數、遇到工具錯誤時是重試還是詢問使用者、什麼時候該停下 agent loop,每個模型都不一樣。
3. Agent 自主性層 —— 本機可逆操作能不能直接做、寫資料庫要不要先問、發信留言要不要確認、能不能自己建檔或清暫存、准不准 force push——同一句「全力完成任務」,在保守模型上剛剛好,在主動模型上可能就是越權。
4. 輸出與 Parser 層 —— JSON/XML/YAML 遵不遵守、會不會多塞說明文字、diff 格式對不對、citation 格式一不一致,案例二裡的兩個模型就是因為過不了這一關直接被淘汰。
5. Reasoning 與狀態層 —— 推理狀態是 server-side 保存還是要 client 自己重送、允不允許 system prompt 或 streaming——不只是參數名稱不同,是整個 agent loop 的狀態機邏輯不同,案例五就是這樣被半夜叫醒的。
6. RAG 與 Context 層 —— chunk 大小、文件排序、要不要重複強調關鍵規則、對不完整資料的處理方式,舊模型上有幫助的長 prompt,新模型上可能反而造成規則重複或注意力干擾。
7. Skills 與 Agent Team 層 —— 每個 skill 都藏著「模型懂什麼、容易漏什麼」的假設,換模型後,原本用來補償弱點的 skill,可能變成重複指令,甚至放大新模型本來就有的過度行為,案例十四就是這樣。
8. Safety 與拒答層 —— 哪些內容會拒答、拒答時有沒有替代方案、會不會執行到一半才喊停,這些差異會直接影響客服、資安、醫療、金融產品的完成率和使用者信任。
9. UX 與商業層 —— 使用者要不要多問一輪、任務放棄率、付費轉換率、客訴、使用者覺得「模型有沒有真的在做事」——案例三已經證明,這些離線 benchmark 完全預測不到。
關於「模型推論本身帶有偏差」的重新框架
與其爭論「模型是否客觀無偏」，更精確的說法是:每個模型都有不同的行為先驗、策略先驗,以及被獎勵訓練出來的行動傾向。這些傾向來自訓練資料分布、人類偏好標註、RLHF/RLAIF/RLVR、工具使用軌跡、安全 policy、對篇幅語氣與自主性的偏好設計。
案例八和案例九就是最好的例子:
Qwen3-Coder 特別獎勵「可執行、可被測試驗證」的結果,GLM-5 則依序訓練 reasoning、agentic、general alignment,它們自然會形成不同的決策風格。這不是誰有偏差、誰沒有的問題,而是每個模型都被訓練成偏好某一種特定的行動策略。真正的問題從來不是「模型是否客觀」,而是:
你的產品,能不能接受這個模型被訓練出來的預設行動策略?
一個重要限定:使用者感受到的差異
你觀察到的「GPT 一直問、Claude 直接做」,不一定全部來自底層模型本身,也可能來自產品層的隱藏 system prompt、工具權限設定、approval policy、UI 對操作的確認機制。
但這不是削弱論點,反而進一步強化它:既然使用者實際接觸到的永遠是「模型 + 產品 scaffold」這個整體,只換底層模型、卻不同步重做 scaffold,本來就不可能保證相同的產品行為——案例十的 Claude Code 換底層就是這樣壞掉的。
也有人認為門檻沒那麼高
不是所有分析都同意鎖定已經無法逆轉。有觀點認為,企業換 LLM 供應商雖然需要重新測試,但整體鎖定程度遠比不上換 ERP 系統那種大工程,目前門檻依然偏低。
像 Walmart 建的多模型動態路由系統(代號 Code Puppy,橫跨 GPT、Claude、Gemini),或企業逐漸走向「模型無關架構」,把商業邏輯和底層模型分離,說明可攜性確實能靠事前架構設計換來。
只是代價通常是犧牲對單一模型的極致優化
所謂 model agnostic,實務上經常等於「在所有模型上都不是最優」。
真正能做到「隨意抽換」的,往往是那些一開始就放棄深度客製化、接受平庸化的產品;一旦你想要的是「在特定模型上打磨到極致的 Agent-native 產品」,可攜性與深度就是一組必然的 trade-off。
結語
現有案例支持的不是「任何情況下都絕對不能換模型」,而是更精確的判斷:
「自由抽換 LLM」只在 API 簡報、概念驗證、或最小共同功能層上成立;一旦產品累積了 prompts、skills、tools、memory、agent teams、safety rules、evaluations 與使用者習慣,所謂換模型,便是一場重新校準、重新驗證,甚至重新設計產品行為的遷移工程。
選擇 LLM,某種程度上就像選擇作業系統的核心
你的 Skills、Tasks 與 Agent 邏輯,是跑在這個特定核心上的應用程式。企圖在不動任何底層建設的情況下「自由抽換 LLM」,就像期待把針對 iOS 深度最佳化的程式碼原封不動丟到 Android 上執行一樣,不切實際。
留言
張貼留言