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 实现模型自由。我这篇是基于它做的拆解和重写，模板部分是我整理后的可直接复制版本，不是原文全文。