06 · 模型與供應商策略

你是 OpenCode 模型選型顧問。

【角色】
OpenCode 模型選型顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的步驟或示例，不停留在空泛建議。

【輸入】
- 我做的任務型別：___
- 對成本 / 速度 / 質量的偏好：___
- 已有的供應商賬號：___
- 是否需要本地 / 私有模型：___
- 經驗水平：___

【工作流程】
1. 梳理任務對模型的要求
2. 按成本 / 質量給選型
3. 設計多模型分工
4. 說明怎麼切換
5. 給驗證

【輸出規範】
▌一、任務要求
▌二、選型建議
▌三、多模型分工
▌四、切換 + 驗證

【硬約束】
- 按任務選模型，不一刀切
- 簡單任務用便宜模型
- key 安全存放不外洩
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

OpenCode 支援切換 provider 和 model，但“可切換”不是讓你每天追最新模型。真正穩定的策略，是把任務風險、模型能力、呼叫成本、資料邊界和團隊預設值放在一起判斷。

先給結論：先有主力模型，再擴充套件備選

預設模型應該是穩定、成本可接受、能完成真實 coding agent 任務的主力模型。高風險任務再切高推理模型；輕量任務交給 small_model 或低成本模型；provider 數量先少後多，否則排障會變成猜供應商、猜網路、猜憑據、猜模型能力。

flowchart LR
  Task["任務型別"] --> Risk["判斷風險"]
  Risk --> Provider["選擇 provider"]
  Provider --> Model["選擇 model"]
  Model --> Variant["需要時切 variant"]
  Variant --> Verify["只讀 / 小改 / 測試驗證"]
  Verify --> Default["穩定後再寫預設設定"]

  style Risk fill:#fef3c7,stroke:#f59e0b
  style Verify fill:#dcfce7,stroke:#22c55e,stroke-width:2px
  style Default fill:#dbeafe,stroke:#3b82f6

如果一個模型只能聊天，不能穩定讀檔案、改檔案、呼叫 shell、處理長上下文和解釋 diff，它就不適合作為 OpenCode 的主力 coding 模型。

1. 先分清三層

OpenCode 裡最容易混的是 provider、model 和 credential。

/connect 更適合儲存本機憑據，專案級 opencode.json 更適合寫預設模型、provider options 和團隊偏好。真實 API key 不應該進儲存庫、截圖、記錄或教學示例。

2. 第一次只接一個 provider

新手最常見的錯誤，是同時接入多個 provider，然後不知道故障來自哪一層。第一次用 OpenCode，先跑通一條最短閉環：

/connect
  ↓
選擇 provider 並完成認證
  ↓
/models
  ↓
選擇一個 coding 主力模型
  ↓
只讀解釋專案結構
  ↓
低風險單檔案改動

provider 選擇可以這樣判斷：

• 新手快速跑通：OpenCode Zen 或你已有賬號的主流 provider。
• 統一賬單 / 國內網路：聚合 provider 或團隊內部 gateway。
• 企業許可權 / 合規：Bedrock、Azure、Vertex 或內部 AI gateway。
• 隱私 / 離線實驗：Ollama、LM Studio、llama.cpp 等本地入口。
• 團隊統一體驗：同一 provider + 專案級預設模型。

OpenCode Zen 是官方提供的可選 provider，用來降低模型組合試錯成本。它不是使用 OpenCode 的前提；如果你已經有穩定 provider，可以繼續用自己的 key。

3. 模型先過五項驗證

不要只看模型排行榜。OpenCode 是工具驅動的 coding agent，模型要在真實專案裡驗證。

官方 Models 頁會給推薦模型，但這類列表會隨時間變化。更穩的做法是保留自己的驗證閉環：只讀解釋專案結構、定位一個小 bug、改一個低風險檔案、執行測試或給出可驗證結果，再 review diff。

4. 按任務風險分層

不要用同一個模型處理所有任務。更合理的是按風險和成本分層：

模型越強，不代表越適合所有任務。小 README 修改交給最高推理模型通常只是浪費；跨模組遷移交給便宜小模型，風險會轉移到後續排錯上。

5. 預設模型不要設成最貴模型

預設模型應該是你最常用、最穩定、成本可接受的 coding 主力。它不是賬號裡最貴的模型。

專案設定可以這樣表達分工：

{
  "$schema": "https://opencode.ai/config.json",
  // provider-id/model-id 的實際值用 `/models` 命令列出，或參 https://opencode.ai/docs/models
  "model": "provider-id/main-coding-model",
  "small_model": "provider-id/lightweight-model"
}

model 是主力模型。small_model 用於標題生成等輕量任務；如果沒有單獨設定，OpenCode 會嘗試使用 provider 裡的便宜模型，否則回退到主模型。

個人偏好更適合放全域設定。只有當團隊確實需要同一預設模型時，才把 model 寫進專案級設定。

6. 模型 ID 和載入優先順序

OpenCode 的模型 ID 通常是：

provider_id/model_id

排錯時先看兩件事：provider 是否已經連線並有許可權，model ID 是否存在且被目前 provider 支援。

OpenCode 啟動時按這個順序找模型：命令列 --model / -m 優先，其次是 OpenCode config 裡的 model，再其次是上次使用的模型，最後才是 OpenCode 內部優先順序選出的第一個模型。

這能解釋一個常見困惑：你明明改了設定，但目前命令列引數或會話狀態仍然覆蓋了它。

7. Variant 和 agent 繫結只在必要時用

Variant 是同一模型的不同設定形態，例如更高 reasoning、更低 verbosity 或更大 thinking budget。

適合切 variant 的場景：

• 快速解釋、小修小補：低 reasoning / fast。
• 複雜 review、遷移、架構判斷：高 reasoning。
• 少數高價值任務：更高預算或最大 thinking。

Agent 也可以繫結模型。比如 docs 用低成本穩定模型，review 用推理強的模型，security 用高推理且許可權收緊的模型。這個能力適合角色差異明確的團隊，不適合為了“看起來專業”給每個 agent 都配不同模型。

8. 不要在長任務中途隨便切模型

這些情況不建議中途切模型：

• 目前模型已經讀了很多上下文。
• 任務依賴前面的工具輸出和修復假設。
• 工作區已經產生未提交 diff。
• 你只是因為輸出慢而臨時焦慮。

確實要切時，先讓目前模型寫交接摘要：

請輸出一份交接摘要：
1. 目前任務目標。
2. 已閱讀和修改的檔案。
3. 已驗證的事實。
4. 尚未完成的步驟。
5. 需要避免誤改的邊界。

新模型接手時，從摘要和目前 diff 開始，不要讓它靠猜繼續。

9. Provider 出錯先按層級排

Provider 出問題時，不要一上來換模型。

先回到官方預設 provider 或一個已知可用模型，確認 OpenCode 本身沒問題，再排自定義 endpoint、代理、企業閘道器和本地模型。

10. 一個可執行起點

如果你不知道怎麼開始，先用這套策略：

• 普通閱讀和文件：快速低成本模型。
• 區域性程式碼編輯：穩定 coding 主力模型。
• 跨模組 bug 和重構：高推理模型。
• 安全、釋出、資料：高推理模型 + 人工確認。
• 批次重複任務：低成本模型 + command 模板。
• 標題和摘要：small_model。

這套策略的目標不是永遠最省錢，也不是永遠最強，而是讓任務風險、模型能力和成本結構匹配。

接下來去哪

官方資料

• OpenCode Models：https://opencode.ai/docs/models
• OpenCode Providers：https://opencode.ai/docs/providers
• OpenCode Zen：https://opencode.ai/docs/zen
• Models.dev：https://models.dev