AI 助理一本正經瞎猜，然後被官方文件打臉——
一次 OpenCode v1.14.40 + Ollama 的 Windows 排錯完整故事

這篇文章有三個主角：一個固執的排錯工程師、一個聽起來很有把握的 AI、以及一份他們都沒去讀的官方文件。

結局是：工程師手動挖對了一半，AI 說中了一半又說錯了一半，官方文件早就把答案寫好了——只是沒人第一步就去查。

一、故事的起點：Qwen 在哪裡？

環境是 Windows 11，Ollama 本地跑著 qwen3.5:9b-q8_0，OpenCode v1.14.40 剛裝好。按理說一切應該順暢——但 OpenCode 每次啟動，都自作主張地選回了一個叫做 minimax-m2.7:cloud 的雲端模型。

排錯的直覺是：設定檔的問題。但 哪個 設定檔？

XDG 規範遷移的陷阱

OpenCode 在某個版本之後，悄悄從 Windows 慣例路徑遷移到了符合 XDG 規範的新路徑。舊版使用者習慣去改的地方，新版根本不理。

# 舊版慣例（不再生效）
%APPDATA%\opencode\opencode.json

# 新版 XDG 規範路徑（這才是有效的）
%USERPROFILE%\.config\opencode\opencode.json

在這個路徑下，把 model 欄位手動修正為 ollama/qwen3.5:9b-q8_0，重啟，終於有效。Qwen 3.5 開始正常接管工作，而且 tool calling 能力也確認正常——它主動調用 read 工具讀取了本地的 CONSTITUTION.md，完全符合 agentic 工作流的期待。

二、Google Search AI 進場：半真的答案

排錯告一段落後，拿去問了 Google Search AI 模式，想看看是否有更快的方法。它給出了這樣的回覆：

第一反應是：這個指令看起來不像真的。Ollama 的 CLI 哪有 launch 子指令？立刻斷言這是幻覺，語氣還相當篤定。

Google Search AI 的說法	當下的判斷
ollama launch opencode 是真實指令	❌ 幻覺（錯誤）
Qwen 3.5 強化了 Agentic AI / Tool Use	✔ 屬實
Opencode 1.14.40 可正確識別 Qwen 3.5	✔ 屬實（我們剛驗證的）
--model 參數存在	❌ 幻覺（再次誤判）

三、官方文件打臉：幻覺指令是真的

直到有人說「你要不要看一下官網？」

打開 https://docs.ollama.com/integrations/opencode，第一段就是：

# Quick setup
ollama launch opencode

# 不啟動，只寫設定
ollama launch opencode --config

更關鍵的是，實際執行 ollama launch opencode --model qwen3.5:9b-q8_0 之後，終端機出現了這樣的提示：

This will modify your OpenCode configuration:
  C:\Users\User\.local\state\opencode\model.json
Backups will be saved to C:\Users\User\AppData\Local\Temp\ollama-backups/
Proceed?
   Yes    No

等等——這個路徑是什麼？.local\state\opencode\model.json？這是一個我們從來沒改過的檔案。

四、第六個檔案的現身

查看 model.json 的內容：

{
  "recent": [
    { "providerID": "ollama",    "modelID": "qwen3.5:9b-q8_0" },
    { "providerID": "opencode",  "modelID": "minimax-m2.5-free" },
    { "providerID": "ollama",    "modelID": "minimax-m2.7:cloud" }
  ],
  "favorite": [],
  "variant": { ... }
}

這份檔案就是整個排錯故事的幕後黑手。recent 陣列紀錄使用過的模型，minimax-m2.7:cloud 就躺在裡面，每次 OpenCode 啟動時從這裡讀取最近使用的模型——而不只是從 opencode.json 讀。

我們修對了 opencode.json（Global Config），但 model.json（State）這一層沒動到。所以 minimax 陰魂不散，是因為它根本住在另一個地方。

五、原廠設計邏輯：五層 Config 優先權

查閱 OpenCode 官方文件後，完整的設計邏輯是這樣的——

最高 優先	Managed Config（企業強制層） Windows: %ProgramData%\opencode\opencode.json　·　需管理員權限，使用者無法覆蓋
↑ 高	Project Config（專案層） .opencode/opencode.json（專案根目錄）　·　覆蓋 Global，不影響其他專案
↑ 中	Custom Config（自訂路徑層） $OPENCODE_CONFIG_DIR　·　介於 Global 與 Project 之間
↑ 低	Global Config（使用者全域層） ~/.config/opencode/opencode.json　·　這是我們手動修改的那層
最低	Remote Config（組織預設層） .well-known/opencode　·　登入 provider 時自動拉取，作為基底
獨立 State	model.json（模型狀態層） ~/.local/state/opencode/model.json　·　由 ollama launch 管理，非 Config 系統

重要設計原則：設定檔採用合併（merge）而非取代（replace）。後載入的層只覆蓋衝突的 key，不衝突的設定全部保留。你可以在 Global Config 設全域偏好，在 Project Config 只寫專案差異，兩者共存不互傷。

手動修對了一層（Global Config），ollama launch 補上了另一層（model.json State），兩層對齊，Qwen 才真正坐穩位子。
— 完整的故事結論

六、決策樹：我到底該改哪個檔案？

把五層 Config + model.json 的複雜關係，轉化成一個可操作的決策工具。點選你的情境，直接拿到對應的路徑與指令。

七、故事教訓的完整清單

---

如果你也在 Windows 環境用 OpenCode + Ollama，踩過類似的雷，希望這份地圖能替你省幾個小時。

而如果你也曾經用篤定的語氣否定了一個其實存在的東西——歡迎加入這個俱樂部。門很大，我們都進來過。