切換 AI 模型使用者會知道嗎？假的能力歸因是什麼

使用者選了 Claude，跟它說「幫我畫一張圖」。平台背後偷偷呼叫了別的模型來畫。使用者看到結果覺得很棒，到處說「Claude 也能畫圖耶」。但這根本不是 Claude 畫的——評價記在了錯的帳上。

Provider 抽象

統一的 Provider 介面，讓所有 AI 服務用同一個規格溝通：

interface Provider {
  id: string
  getModels(): Promise<ModelInfo[]>
  findModel(query: string): Promise<ModelInfo | undefined>
  isConfigured(): boolean
}

就像餐廳的點餐系統——不管食材來自哪個供應商，通通用同一張訂單格式。好處是成本優化（模型價差可達 60 倍）、供應商風險分散、模型過時時能快速切換。

假的能力歸因（False Capability Attribution）

層級	錯誤歸因
第一層	把能力歸給了錯的模型（以為 Claude 會畫圖）
第二層	把信任歸給了錯的平台（以為這個平台的 AI 比較強）

業界三種透明度：

做法	代表	透明度
完全透明	Perplexity、OpenRouter	明確顯示正在用哪個模型
半透明	ChatGPT	用 DALL-E 畫圖時小字標註
完全不透明	某些平台	偷偷降級到更便宜的模型

我的追問與發現

「我用 CLI Claude Code 不就是單一模型嗎？我是不是畫地自限？」

要區分兩個角色。作為使用者，你選最順手的工具，這是品味不是限制。作為建造者，你做產品讓別人用，這時候 Provider 抽象才是必要的——因為掛掉的不是你的工作效率，是客戶的體驗。使用者選工具靠品味，建造者設計架構靠韌性。

「偷偷切換模型不就產生了謬誤評價？」

正在現實中發生。ChatGPT 用 DALL-E 畫圖，使用者覺得「我在跟 ChatGPT 對話，它畫了這張圖」——能力被歸給了對話窗口的品牌，而不是實際執行的模型。Provider 抽象給你的是切換的「能力」，但不給你偷偷切換的「權利」。長期下來，整個生態系的評價機制都會失真。

你可以怎麼用

使用者角色：選你最順手的 AI 工具，不必焦慮「只用一家會不會太局限」
建造者角色：產品一開始就用 Provider 抽象設計，保留切換彈性
透明原則：如果你的產品背後切換了模型，告訴使用者。信任比省成本重要
評價時多想一步：看到「某某 AI 好厲害」的評價，先想想——這個能力真的是那個模型自己做到的嗎？

延伸連結

介面設計怎樣才算誠實？

一句話帶走

Provider 抽象給你切換的「能力」，但不給你偷偷切換的「權利」。

📚 完整學習對話紀錄（想看完整脈絡可展開）

原文（蒸餾精華第 5 段）

統一的 Provider 介面，讓所有 AI 服務用同一個規格溝通：

interface Provider {
  id: string
  getModels(): Promise<ModelInfo[]>
  findModel(query: string): Promise<ModelInfo | undefined>
  isConfigured(): boolean
}

支援 NCHC、OpenRouter、OpenAI、Gemini、Mistral、LMStudio 等 9+ 服務。

Claude 的白話解釋

一個統一介面，服務所有 AI 供應商。就像餐廳的點餐系統 — 不管食材來自哪個供應商，通通用同一張訂單格式。opencode.json 作為唯一的設定真相來源（single source of truth）。

什麼時候需要這種設計？四個情境：

情境	說明
成本優化	GPT-4o 每百萬 token $15 vs Haiku 每百萬 token $0.25，差 60 倍
供應商風險	如果 Claude 掛了 8 小時怎麼辦？
模型過時	最強的模型每隔幾個月就換人
內容管線	連「內容型網站」也需要，用 AI 跑內容產出流程

我的提問：我用 CLI Claude Code 不就是單一模型嗎？我是不是畫地自限？

讀到這段的時候我的第一反應是：我每天用 Claude Code，就是綁定一個模型在做事，這不就是蒸餾裡說的反面教材嗎？我是不是畫地自限了？

Claude 的回答：作為使用者不是，作為建造者才需要

這裡要區分兩個完全不同的脈絡：

你的角色	說明	模型切換的影響	斷線時怎樣
使用者	你用 Claude Code 來寫程式	你自己選了最順手的工具	你等一下就好
建造者	你做一個產品，背後呼叫 AI API	你的用戶會受到影響	你的用戶打不開服務

你用 Claude Code 寫程式，那你是使用者。選擇你覺得最好用的工具，這是品味，不是限制。

但如果有一天你做了一個產品，背後要呼叫 AI 來處理事情，你就變成了建造者。這時候 Provider 抽象就是必要的 — 因為掛掉的不是你的工作效率，是你客戶的體驗。

我又追問：偷偷切換模型不就產生了謬誤評價？

想到一個問題：切換模型會有提示工程的差異和品質差異。如果平台沒有讓使用者知道正在用哪個模型，不就會產生謬誤的迷因評價？

舉個例子：使用者選了 Claude Opus 4.6，跟它說「幫我畫一張圖」。平台背後偷偷呼叫了 banana2 來畫圖，使用者看到結果覺得很棒，就到處說「哇，Claude 也能畫圖耶，還畫得比 ChatGPT 好！」

這根本就不是 Claude 畫的，但評價記在了 Claude 頭上。這就是一個假的歸因迷因。

Claude 的回答：這叫「假的能力歸因」，而且正在現實中發生

這個現象有個名字：假的能力歸因（False Capability Attribution）。

而且它不是理論，正在現實中發生：

ChatGPT 用 DALL-E 畫圖，Claude 用外部工具處理特定任務，但使用者覺得「我在跟 ChatGPT 對話，它畫了這張圖」
使用者把能力歸給了對話窗口的品牌，而不是實際執行的模型

這裡面有兩層問題：

層級	錯誤歸因
第一層	把能力歸給了錯的模型（以為 Claude 會畫圖）
第二層	把信任歸給了錯的平台（以為這個平台的 AI 比較強）

業界目前有三種做法：

做法	代表	透明度
完全透明	Perplexity、OpenRouter	明確顯示正在用哪個模型
半透明	ChatGPT	用 DALL-E 畫圖時，小字標註用了 DALL-E
完全不透明	某些平台	偷偷降級到更便宜的模型，使用者完全不知情

最關鍵的一句話：

Provider 抽象給你的是切換的「能力」，但不給你偷偷切換的「權利」。

技術上你可以無縫切換任何模型，但如果不告訴使用者，你就是在製造假的能力歸因。

我學到的

「假的能力歸因」 — 技術執行層的切換如果不誠實揭露，會在使用者認知層製造錯誤的品牌評價。

這跟之前學到的「誠實介面」是同一個精神：能力到哪裡就說到哪裡，不多也不少。Provider 抽象是一個很強的架構設計，它讓你有能力在不同 AI 服務之間切換。但「有能力做」和「該不該做」是兩件事。偷偷切換模型，使用者的讚美和批評都會記在錯的帳上，長期下來整個生態系的評價機制都會失真。

技術決策從來不只是技術問題，它會直接影響使用者的認知和信任。