claude code 平替: opencode + deepseek/qwen

我最近试了下 opencode，配上私有部署的 Qwen（也能换成 DeepSeek 之类的模型），最大的感受很朴素：

• 不再为 token 不够用焦虑（至少不会像订阅版那样心里打鼓）
• 不再为订阅费心疼（尤其是“用得不算少，但又没到重度依赖”的阶段）
• 效果确实差一点，可应付日常工作，基本够用

这篇文章就写一件事：把它配到能稳定用，尤其是 TLS/证书这道坎。

What

这里说的 opencode，指的是 OpenCode（GitHub） 这个开源 AI coding agent，官方介绍在 opencode.ai。

OpenCode 是什么（我按“能干啥”来理解它）

一句话：把“像 Claude Code 那样的 coding agent”搬进终端里。

它的定位不是“再做一个 Chat”，而是偏工程化的“工作台”：

• 终端/TUI 优先：你在 shell 里就能开工（当然也有桌面端、IDE 扩展）
• Provider-agnostic：不绑定某一家模型/平台，你能接 Claude、GPT、Gemini，也能接公司私有部署（只要你们提供 OpenAI-compatible 入口）
• LSP 支持：它会尽量加载合适的语言服务，做补全/跳转/诊断这类“工程味”更重的活
• 多会话：同一个项目你可以开多个 session 并行做事（比如一个写代码，一个查资料/改文档）
• 内置 agent：它有不同权限/风格的 agent 可切（比如默认的全权限 build，以及更克制的只读 plan）
• 隐私取向：官方宣称不存储你的代码/上下文（这点对“公司环境”尤其关键）

这篇文章里，我们来看看怎么用它

更具体点，这篇文章就是把 OpenCode 当“壳”，把模型换成公司内网的 Qwen/DeepSeek：

• 用 opencode 当“终端里的 AI coding 工具”
• 通过 @ai-sdk/openai-compatible 接一个 OpenAI-compatible 的内部网关（例如 https://my-llm.fanyamin.com/api）
• 选择内部提供的模型（例如 Qwen3-235B-A22B-Thinking-2507 / Qwen3-235B-A22B-Instruct-2507）

Why

1) 订阅费不是问题，心理负担才是

你在写代码时不想算账：这段 prompt 值不值 0.2 美元，那段 diff 会不会把额度烧穿。能“放心用”，比“更聪明一点”对日常效率更重要。

2) 私有部署模型的收益：可控、便宜、能集成

固然模型能力会略弱，但胜在：

• 内网可达，延迟更稳
• 权限可控（公司做过审计/准入）
• 成本可控（你不用自己掏腰包）

How

下面以 my-llm.fanyamin.com 这种 OpenAI-compatible 网关为例。

0) 安装 opencode

你可以用官方安装脚本（最省事）：

curl -fsSL https://opencode.ai/install | bash

或者用 npm 全局安装：

npm install -g opencode-ai

我个人的小习惯是：涉及 curl | bash 的脚本，能先看一眼脚本内容再跑就先看一眼，心里更踏实。

1) 配置 opencode 的 provider（推荐做法）

把配置放在 ~/.config/opencode/opencode.json。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "happycoding": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "happycoding",
      "options": {
        "baseURL": "https://my-llm.fanyamin.com/api"
      },
      "models": {
        "Qwen3-235B-A22B-Thinking-2507": {
          "name": "Qwen3-235B-A22B-Thinking-2507"
        },
        "Qwen3-235B-A22B-Instruct-2507": {
          "name": "Qwen3-235B-A22B-Instruct-2507"
        }
      }
    }
  }
}

几点小提醒：

• JSON 一定要用英文双引号。你贴的示例里出现了中文引号（“ ”），那种会直接解析失败。
• 你原文里 Instruct 的 name 写成了 Thinking，我这里顺手纠正了。

2) 登录与连上 provider

我这边的流程是：

• /connect：按提示完成登录/授权
• /models：确认能看到内部的模型列表（例如 Qwen3-235B-A22B-A22B-Thinking-2507 这种）

注意：~/.local/share/opencode/auth.json 这类文件里通常会有 token/凭据，别提交到仓库，也别贴到博客里。

3) 处理 TLS 自签证书（推荐：加 CA，不要关校验）

最常见的坑是：内部网关用了自签名证书/私有 CA，Node 侧会报 TLS 错。

正确姿势是把 CA 加进来。你可以用 openssl s_client 把证书链导出来：

openssl s_client -connect my-llm.fanyamin.com:443 -showcerts </dev/null \
  | openssl x509 -outform PEM > happycoding-ca.pem

然后让 Node 进程信任它：

export NODE_EXTRA_CA_CERTS=~/certs/happycoding-ca.pem
opencode

4) 不推荐但你可能见过的做法：关闭 TLS 校验

你可能见过：

NODE_TLS_REJECT_UNAUTHORIZED=0 opencode

这招的确“能跑”，但代价是把 HTTPS 的安全底线一起关掉了——等于告诉程序：谁给我证书我都信。

如果只是本地临时排障（确认问题确实在证书链），可以短时间用一下；长期使用不建议，更不建议写进脚本或文档当“标准方案”。

Example

一个我自己常用的“确认链路是否通了”的小步骤：

1. opencode 里跑 /models 能列出 Qwen3-235B-A22B-*
2. 随便发个小请求让它回一句（例如让它总结 git diff 的意图）
3. 如果卡住/报错，优先看 TLS、代理、baseURL 路径（/api 有没有漏）

Summary

opencode + 私有 Qwen/DeepSeek 这条路，核心不是“模型有多强”，而是“工程上能不能稳稳当当地用起来”。

无他：先把证书、网络、配置这三板斧练熟，你就能少掉一半的心火。

Checklist

• [ ] ~/.config/opencode/opencode.json 是合法 JSON（英文双引号、无多余逗号）
• [ ] baseURL 能在本机访问（内网/VPN/代理）
• [ ] /models 能列出你要用的模型
• [ ] 自签证书问题用 NODE_EXTRA_CA_CERTS 解决，而不是长期 NODE_TLS_REJECT_UNAUTHORIZED=0
• [ ] auth.json/token 文件不外传、不进 git

References

• opencode 配置 schema：https://opencode.ai/config.json
• Node 环境变量：NODE_EXTRA_CA_CERTS

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。