OpenCode+DigitalOcean 讓你切換模型

OpenCode + DigitalOcean 讓你在終端裡自由切換編碼模型。

我一直挺喜歡 Claude Code 這種東西。終端裡敲一句話，它就能自己讀文件、改代碼、跑測試、再回來告訴你結果。第一次用的時候，我甚至有點上頭，像是終於有人把「聊天式建議」那套煩人的複製貼上流程砍掉了。

但我用久了，問題就很明顯了。它好用，真的好用，可它也太綁人了：模型綁在 Anthropic 上，價格綁在訂閱上，代碼還得經過對方的基礎設施。對我這種經常在不同項目裡切換、偶爾還要看合規要求的人來說，這種感覺不太對勁。不是不能用，是用著總覺得自己把太多主動權交出去了。

所以我看到這篇知乎教程時，第一反應不是「哇，替代品來了」，而是「終於有人把這事講明白了」。原文來自知乎專欄 Claude Code 的開源替代方案：用 OpenCode + DigitalOcean 實現模型自由，作者是 DigitalOcean 云服務。它不是在吹一個新玩具，而是在講一套能落地的替換方案：OpenCode 負責終端裡的智能體體驗，DigitalOcean 負責把模型和基礎設施這件事從 Claude 那邊拎回來。

我最在意的點也很簡單：我能不能繼續保留 Claude Code 那種工作流，但把模型換成我自己的選擇？能不能在項目中途直接切到別的模型，而不是被一個訂閱和一個供應商鎖死？這篇文章的答案是能，而且它給出的路徑還挺直接。下面我把它拆開，不講虛的，只講我會怎麼用。

你真正想要的，不是「另一個工具」，是控制權

OpenCode 複刻了 Claude Code 的體驗，包括終端用戶界面、文件編輯、Shell 命令、LSP 感知和多會話支持，但消除了供應商鎖定。

這句其實已經把核心說透了。OpenCode 不是想重新發明一套編碼智能體，它是在盡量保留 Claude Code 的手感，同時把「誰提供模型、誰託管推理、誰看見你的請求」這些問題拆開。

我把它翻譯成人話就是：你要的不是「又一個 AI IDE」，你要的是一個能讀項目、能改文件、能跑命令的終端代理，而且這個代理別總替你做平台選擇。你該選模型的時候選模型，該換供應商的時候換供應商，不用重建工作流。

這點我特別認同。因為開發者真正在意的，從來不是「模型名字聽起來多高級」，而是它在我的代碼庫裡到底幹不幹活。一個模型在重構上強，另一個在測試生成上穩，第三個在長上下文裡不容易跑偏。你如果被綁死在單一模型上，就只能忍著。

我自己也遇到過這種情況。某個項目裡我需要它老老實實按現有架構補測試，另一個項目裡我又需要它更激進地幫我拆模塊。一個模型不可能永遠最合適，但如果工具允許我切換，我就能把「模型差異」變成日常操作，而不是遷就。

OpenCode 的價值就在這裡。它不是把 AI 編碼體驗做得更花俏，而是把選擇權還給你。這個方向我看得很順眼。

怎麼用到自己身上？先別急著比較誰更聰明。先問三個問題：我是否需要在同一個項目裡試不同模型？我是否介意代碼經過某家公司的推理基礎設施？我是否想把工具和模型解耦？如果答案裡有兩個「是」，那你就已經有理由試 OpenCode 了。

• 你不必因為喜歡某個工具，就接受它綁定的模型。
• 你也不必因為模型強，就接受它附帶的託管路徑。
• 把工具層和模型層拆開，後面才有討論空間。

「模型自由」不是口號，是你能立刻切換的命令

模型由你選擇。Kimi K2.6、DeepSeek V4 Pro、Llama 4、Qwen 3 Coder，甚至是 Claude、OpenAI，哪個對你的工作負載表現最好就用哪個。你甚至可以在項目中途用一條 /models 命令切換模型。

這段是整篇文章最值錢的地方。因為它不是在說「未來可能支持更多模型」，而是在說你現在就能切。這個差別很大。前者是願景，後者是工作流。

我一直覺得，模型選擇這件事被很多人講得太玄了。其實開發場景很樸素：有些模型寫腳手架快，有些模型補文檔強，有些模型在複雜倉庫裡更不容易亂改。你不需要一開始就押寶，你需要的是快速試錯。

OpenCode + DigitalOcean 這裡給你的，就是試錯能力。文章裡提到的模型目錄很長，像 MiniMax M2.5、Claude Sonnet 4.5、GPT-5、DeepSeek、Llama 3.3、Kimi K2.5、Qwen3 這些都在可用範圍裡。重點不是名單多，而是你不需要為每個模型單獨搭一套接入方式。

我會怎麼理解這個能力？就是把模型當成依賴項，而不是宗教信仰。今天這個倉庫適合更穩的模型，明天那個倉庫適合更會發散的模型。你甚至可以在同一個任務裡先讓一個模型做 plan，再換另一個模型做 build。原文提到按 Tab 就能在 plan 和 build 智能體之間切換，這種設計就很實用。

我以前在別的工具裡試過「模型切換」，結果不是配置散落一地，就是切換成本高到我懶得試。最後模型選擇變成了「默認用那個最順手的」，而不是「針對任務選最合適的」。這就是工具設計失敗的地方。

如果你要把這套方案用起來，我建議別一上來就糾結排行榜。先拿你真實項目裡的三個任務做對比：補一個 API 端點、重構一個舊模塊、寫一組測試。每個任務都試兩個模型，記錄它們的修改質量、是否亂動無關文件、是否能按你的約束執行。這樣你會很快知道「模型自由」到底值不值。

• 先用真實任務測試，不要拿玩具示例自嗨。
• 比較輸出質量時，重點看無關修改和返工次數。
• 把模型切換做成日常動作，而不是一次性決策。

開源這件事，真正的好處是你能審計它

OpenCode 採用 MIT 許可。你可以閱讀代碼、複刻它，並確切知道它對文件和提示做了什麼操作。

我對「開源」這兩個字一直挺挑剔。很多項目嘴上說開源，實際只是把一部分代碼扔出來，真正關鍵的流程還是黑箱。OpenCode 至少在這個點上態度清楚：你能看它怎麼工作，也能自己複刻它。

這不是情懷問題，是工程問題。一個會讀文件、會改文件、會執行命令的 AI 工具，天然就比聊天機器人更敏感。它碰到的是你的源碼、你的測試、你的 shell 歷史，甚至是你還沒提交的臨時代碼。這種工具如果不能審計，我會本能地不放心。

MIT 許可也很現實。它意味著你可以把它放進自己的流程裡，不用擔心一堆奇怪的限制。對於團隊來說，這種寬鬆許可通常更容易過內部審查。哪怕你最後不改源碼，至少你知道它沒有在背後搞什麼花活。

我跑過不少「AI 編碼助手」，最煩的就是它們一邊說自己幫你提效，一邊又把關鍵行為藏起來。比如它到底是不是把整個文件發出去了，它到底是按什麼粒度做上下文收集，它到底有沒有保留會話數據。你問這些問題，很多產品頁面只會給你一句模糊的隱私說明。

OpenCode 的思路更像工具，而不是平台。工具就該可見、可控、可替換。你可以不喜歡它的默認行為，但至少你知道自己在改什麼。

怎麼落地？如果你打算在團隊裡推這類工具，我建議先做兩件事：第一，看看倉庫裡有沒有明確的提示和文件訪問邏輯；第二，給團隊寫一頁很短的使用說明，告訴大家哪些內容可以交給它，哪些內容不該交給它。開源不等於自動安全，但開源至少讓你有機會把安全邊界畫出來。

隱私不是標語，得看數據到底去哪了

OpenCode 不會存儲你的代碼或對話數據。DigitalOcean 推理不會保留或訓練提示或回應數據，僅保留為提供服務所必需的部分。

這段話我會認真看，但不會盲信。原因很簡單：隱私聲明不是魔法，它只是個起點。不過，至少這篇文章把問題擺出來了，而且把 OpenCode 本地行為和 DigitalOcean 推理側的處理方式分開講了。

對我來說，最重要的不是「有沒有 AI」，而是「數據流向能不能講清楚」。如果代碼在 Droplet 上，提示發到推理服務，回應回來後不做額外留存，那這個鏈路比把本地編輯器和一堆雲端服務混在一起更容易理解。理解得越清楚，越容易做合規判斷。

文章還提到，如果你想更保守一點，可以把 Droplet 限制在 VPC 內，並限制模型訪問密鑰的作用範圍。這個建議我挺贊同。很多人談隱私只談「有沒有保存」，其實更應該談「誰能訪問、從哪訪問、能訪問多久」。

我見過不少團隊不是不在乎隱私，而是根本沒法回答審計問題。比如「代碼有沒有離開內網」「日誌裡有沒有敏感信息」「模型請求能不能追蹤到具體項目」。如果你用的是一套說不清的閉源工具，回答這些問題會很痛苦。

這裡的好處是，你至少能把架構說清楚：項目代碼在 Droplet，模型請求走 DigitalOcean 推理，密鑰通過模型訪問密鑰統一管理。這個鏈路比「裝個插件就開始寫代碼」更適合需要解釋給別人聽的場景。

我會怎麼建議你驗證這部分？先別看宣傳頁，直接看三件事：會話數據有沒有本地或雲端持久化、密鑰是不是集中管理、Droplet 和推理服務之間的數據邊界能不能說清。能說清，才算能用。

五分鐘部署聽起來像廣告，但這次真的不算誇張

整個設置可在五分鐘內完成：部署 Droplet、SSH 登錄、在設置嚮導中粘貼模型訪問密鑰，然後開始編碼。

我一般對「五分鐘搞定」這種說法很警惕，因為大多數時候它只是把麻煩轉移到別的地方。但這篇文章給的流程，確實是那種很標準的「少廢話、少手工」的部署路徑。

它的步驟很直白：先在 DigitalOcean 控制台創建 Gradient 模型訪問密鑰，再從 Marketplace 部署 OpenCode 一鍵式應用，接著 SSH 登錄 Droplet，粘貼密鑰，最後啟動 OpenCode。沒有本地裝一堆依賴，沒有手寫 YAML，沒有到處找環境變量名。

這類部署方式我很吃。因為它把「試用成本」壓得很低。很多工具之所以沒人堅持用，不是因為不好，而是第一次上手太煩。你要先裝客戶端、配模型、配權限、配網絡，最後還沒開始寫代碼，心態已經崩了。

文章裡還給了資源規格建議，最低是 1 GB RAM / 1 vCPU / 25 GB 存儲，推薦 2 GB RAM / 2 vCPU 或更高。這個信息很實用，因為它告訴你這不是必須上重機器才能跑的東西。對個人開發者來說，能先從小規格開始試，心理負擔會小很多。

我也注意到文中給了 API 部署示例，這一點對習慣自動化的人很友好。你可以先手動試一遍流程，再把它寫進腳本或基礎設施模板裡。先驗證，再自動化，順序別反。

如果你真想快速試，我建議按這個順序來：

• 先創建模型訪問密鑰，別跳過這一步。
• 先用 Marketplace 一鍵部署，不要一開始就自己拼裝環境。
• 先 SSH 登錄看嚮導是否正常，再考慮自定義配置。
• 先跑一個小任務驗證模型切換，再上真實倉庫。

別只看默認模型，先把 /models 和 RULES.md 用起來

要永久設置默認模型，在 Droplet 上編輯配置。你還可以在項目目錄中添加一個 RULES.md 文件，為智能體提供跨會話保留的常駐指令。

這是我最想單獨拎出來說的部分，因為它決定了這套工具到底是「能用」，還是「真的能融進你的工作流」。默認模型只是起點，規則文件才是讓智能體穩定下來的關鍵。

OpenCode 裡可以直接用 /models 切換模型，這個已經很方便了。但如果你每次都靠手動選擇，長期還是會亂。文章建議你在 /root/.config/opencode/opencode.json 裡固定默認模型，這樣至少起步一致。然後再在項目裡放一個 RULES.md，把項目約束寫清楚。

我非常贊成這種做法。因為智能體最容易出問題的地方，不是它不會寫，而是它會忘。你今天告訴它「別改遷移文件」，明天它又在別的會話裡忘了。把規則寫進項目，讓它每次都能讀到，這比口頭提醒靠譜得多。

我自己在用類似工具時，最常寫的規則就三類：代碼風格、測試要求、不可修改區域。比如「函數簽名必須帶型別提示」「不要改已有遷移，只能新建」「任何任務完成前先跑測試」。這種規則看起來囉嗦，但它能顯著減少返工。

原文還提到，Droplet 預裝了一些輔助腳本，比如檢查版本、更新、重新運行設置嚮導。這個細節我很喜歡，因為它說明這不是一次性演示，而是考慮了後續維護。很多教程只管你第一次跑通，不管你兩週後怎麼更新。

如果你要把這套東西真正用進日常，我建議你把規則分成兩層：一層放在全局配置裡，約束默認模型和基礎行為；另一層放在項目目錄裡，約束這個倉庫的具體習慣。這樣你既能統一大方向，又不會讓每個項目都像沒規矩的野地。

這套方案適合誰，不適合誰，我的判斷很簡單

如果你正在為 Claude Code、Cursor 或類似工具支付月費，並希望成本更低或更可預測，這個方案值得考慮。

我不想把這東西說成人人都該換。沒必要。工具選擇本來就是看場景，不是看站隊。OpenCode + DigitalOcean 適合的是那些已經習慣終端工作流、又想把模型和基礎設施控制權拿回來的人。

如果你本來就很少在終端裡做複雜編碼任務，那它的價值就沒那麼大。你如果只想偶爾問問代碼建議，直接聊天式工具可能更順手。但如果你經常做重構、調試、補測試、批量改文件，那這種智能體式工作流會更有存在感。

我會特別推薦給這幾類人：一是已經在為 Claude Code、Cursor 之類付費，但想把成本和模型選擇變得更可控的人；二是對代碼出境比較敏感的人；三是本來就愛折騰開源工具、想知道底層到底怎麼跑的人。

不太適合的人也很明顯：不想碰 SSH 和 Droplet 的人、完全不關心模型切換的人、以及只想「開箱即用、別問我怎麼回事」的人。這個方案雖然部署不算難，但它畢竟還是偏開發者工具，不是消費級應用。

我自己的判斷是，如果你已經在 Claude Code 上形成了穩定習慣，但又對綁定關係不爽，那這篇教程基本就是為你準備的。它不是讓你放棄那種體驗，而是讓你保留體驗，同時換掉底層約束。

這才是我覺得最有價值的地方：不是「換一個更強的 AI」，而是「讓你能決定 AI 用誰、跑在哪、怎麼留痕」。對開發者來說，這種控制感比宣傳頁上的任何形容詞都實在。

你可以直接複製的模板

# OpenCode + DigitalOcean 使用模板

## 1. 先準備模型訪問密鑰
- 登錄 DigitalOcean 控制台
- 打開 Inference → Manage
- 創建一個 Model Access Key
- 把密鑰保存到密碼管理器裡

## 2. 部署 OpenCode Droplet
- 從 DigitalOcean Marketplace 部署 OpenCode
- 選擇 2 GB RAM / 2 vCPU 或更高
- 添加 SSH key
- 等待 Droplet 創建完成

## 3. SSH 登錄並完成初始化
ssh root@YOUR_DROPLET_IP

# 按提示粘貼模型訪問密鑰
# 完成嚮導後，進入你的項目目錄
cd /path/to/your/project
opencode

## 4. 固定默認模型
# 編輯全局配置
nano /root/.config/opencode/opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "model": "digitalocean/minimax-m2.5"
}

## 5. 在項目裡加 RULES.md
# RULES.md
- 這是一個使用 FastAPI 和 PostgreSQL 的 Python 3.12 項目。
- 函數簽名始終添加型別提示。
- 永遠不要修改已有的遷移文件。創建新的。
- 在認為任何任務完成之前，先運行 `pytest`。

## 6. 日常使用習慣
- 用 `/models` 切換模型
- 用 Tab 在 plan 和 build 之間切換
- 先讓模型做計劃，再讓它修改文件
- 每次大改後都跑測試

## 7. 我會用來驗證它的任務
- 補一個健康檢查接口
- 給舊模塊做一次重構
- 生成一組單元測試
- 讓模型只改必要文件，不要亂動別的東西

這個模板不是原文逐字複製，我把它整理成了更適合直接落地的版本。你可以先照著跑一遍，再根據自己的倉庫把 RULES.md 改成你的項目約束。

我建議你第一次試的時候，別上來就拿最核心的生產倉庫開刀。先找一個小項目，或者從一個局部任務開始，比如補一個 API、寫測試、改文檔。等你確認模型切換、規則約束、文件編輯這些環節都正常，再把它推進到更重要的代碼庫裡。

如果你只記住一句話，我希望是這個：OpenCode + DigitalOcean 的意義，不是「又多了一個 AI 工具」，而是你終於能把編碼智能體從單一模型和單一平台裡解耦出來。

原文來源是知乎專欄文章 Claude Code 的開源替代方案：用 OpenCode + DigitalOcean 實現模型自由。我這篇是基於它做的拆解和重寫，模板部分是我整理後的可直接複製版本，不是原文全文。