Windows下Opencode自定义模型配置指南：完整流程、避坑与参数组合

老早就想聊聊这个话题了。之前一直在命令行里折腾各种 AI 编码代理工具，后来换到 Windows 环境，总感觉配置这条路比预想中坎坷，尤其是想把 Opencode 接到自定义模型上，官方文档写得倒是简洁，但实际操作里暗坑不少。这篇文章就把我在 Windows 下从零配置 Opencode 自定义模型的完整过程、踩过的坑、以及最终跑通的参数组合整理出来，给同样在这条路上折腾的朋友做个参考。

先说清楚一个概念：Opencode 是什么。简单讲，它是一个运行在终端里的 AI 编码代理，你可以在终端里直接跟某个大模型对话，让它帮你写代码、改 bug、做代码审查，甚至自动执行终端命令来完成一个相对完整的开发任务。它本身不自带模型能力，而是通过配置对接各种模型服务——OpenAI 系的、Anthropic 系的、本地 Ollama 部署的，以及其他兼容 OpenAI 协议的服务。所以“自定义模型”这件事，在 Opencode 里本质上就是配置 provider 和 model 两个层次的问题。

我为什么非要折腾自定义模型，而不是直接用某个商业模型的官方 CLI？原因很简单：数据隐私和成本。在某些公司环境里，代码片段不能随便外发到第三方平台，这时候本地模型就成了仅有的选择；另外，团队内部往往有一套已经接入好的模型网关或私有化部署服务，统一走自定义模型配置能复用现有的 key 和计费体系。从实际经验看，Opencode 的自定义模型配置能力相当灵活，只要你理解了它的配置模型，几乎任何兼容 OpenAI 或 Anthropic 协议的端点都能接上。

1. Opencode 的架构与自定义模型的核心逻辑

1.1 先搞清楚 Provider、Model、Profile 三者的关系

Opencode 的配置思路跟很多 AI 应用不太一样。它不是简单填一个 API Key 就行，而是把“谁能提供模型服务”和“具体用哪个模型”分开管理。前者叫 Provider（模型提供方），后者叫 Model（模型实例）。

举个例子，你配置了一个 Provider 叫 mycompany，地址指向你们公司内部的模型网关，然后你在这个 Provider 下面注册两个 Model，一个叫 gpt-4-family（映射到公司网关的某个模型别名），一个叫 code-model-small（映射到另一个轻量模型）。实际使用的时候，你可以通过启动参数 --model mycompany/code-model-small 直接选中某个模型，也可以在交互式会话里用 /model 命令临时切换。如果不指定，Opencode 会使用顶部配置里的默认模型。

这就带来一个好处：你能在不同模型之间切换，还不用修改 Provider 配置。对于我这种经常要在“大而全”和“快而省”的模型之间切换的开发者，这种设计非常顺手。还有个容易忽略的概念是 Profile（配置档）。Opencode 允许多个 Profile，每个 Profile 是一整套独立的配置，包括自己的 Provider、Model、系统提示词、权限设置。比如你日常开发用一个 Profile，写文档用另一个 Profile，各自的模型和提示词互不干扰。这个机制在后面配置自定义模型时非常有用。

1.2 Windows 环境与 Linux/macOS 的差异点

很多人以为 Opencode 在 Windows 下的配置就是装完直接 opencode 回车，但实际遇到的第一个坑就是运行环境。Opencode 官方推荐在 Linux 和 macOS 上运行，Windows 属于“能用但没那么顺”的状态。它在 Windows 下需要依赖一些类 Unix 工具，所以你先得装一套 Git for Windows（提供 bash.exe、sh.exe）和 Windows Terminal，否则很多工具链根本跑不起来。

另一个差异是路径分隔符。Windows 下你写配置里的模型路径时，经常要处理反斜杠转义问题。配置文件里 JSON 的路径如果写 C:\Users\xxx，不转义的话 JSON 解析直接报错。我后来统一用正向斜杠 C:/Users/xxx 或者双反斜杠，问题就消失了。

还有一个很隐蔽的坑：Windows 的控制台编码。如果模型返回的中文内容在终端里显示乱码，十有八九是代码页问题。在 PowerShell 里执行 chcp 65001 切到 UTF-8 可以解决大部分情况，或者在 Windows Terminal 的设置里把默认编码改成 UTF-8。这些前置问题不解决，你后面无论怎么配置模型都会觉得哪哪都不对劲。

1.3 配置文件的加载顺序与优先级

Opencode 配置文件的加载顺序属于那种“不看文档就很容易怀疑人生”的部分。整个配置体系从全局到局部有明确的优先级，层级越往下，优先级越高。我先梳理一下：

• 全局配置：位于 %USERPROFILE%\.config\opencode\ 或通过 OPENCODE_CONFIG 环境变量指定的目录
• 项目级配置：位于当前项目根目录的 .opencode/ 目录下
• 命令行运行目录下的 .config/opencode 目录

当存在多个配置文件时，更深层级的配置会覆盖更全局的配置。这也就解释了为什么你在全局配好的 provider，到了某个特定项目里突然不生效了——极有可能是那个项目里有自己的 .opencode 配置，把全局配置覆盖了。

我在某公司做顾问时，经常发现 A 同事在全局配好的模型，拿给 B 同事用，B 在自己项目里却一直启动不了。排查到最后，就是项目里一个陈旧的 .opencode/config.json 在作祟。如果你想强制忽略项目级配置，可以用 --no-project-config 启动参数，这个参数在排查问题的时候非常管用。

2. Windows 环境准备：基础依赖与可选的本地模型运行时

2.1 Node.js 版本与安装方式

Opencode 本质上是 Node.js 编写的 CLI 工具，所以 Node.js 是硬依赖。这里要特别注意版本问题：如果你 Node.js 版本偏低，装是能装上，但运行后各种 API 报错，光看报错信息根本想不到是运行时版本太老。我建议 Node.js 20 或以上，这是亲测最稳的。

安装方式推荐用官方安装包或者在 PowerShell 里用 winget install OpenJS.NodeJS.LTS，二选一都行。装完以后一定要重开终端，让 PATH 环境变量刷新。验证安装只需要两条命令：

bash复制node --version
npm --version

如果你希望各个项目的 Node 版本隔离管理，可以额外装一个 fnm 或 nvm-windows。Opencode 这种工具建议装在全局环境里，免得不同项目切换 Node 版本时，全局 CLI 的依赖被搞乱。

2.2 本地模型运行时：Ollama 的安装与基础配置

如果你需要完全离线的本地模型方案，那 Ollama 是绕不开的。它是一个本地模型运行工具，可以帮你把开源模型跑起来，并对外提供兼容 OpenAI 风格的 API。对于 Opencode 来说，Ollama 就是一个典型可用的 Provider。

Ollama 的 Windows 版安装包做得比较省心，下载安装包后一路下一步就行。装完它默认监听在 127.0.0.1:11434。验证是否正常运行，直接在浏览器访问：

text复制http://127.0.0.1:11434

如果能看到 Ollama is running 的字样，说明服务已起来。接下来拉取一个模型：

bash复制ollama pull qwen2.5-coder:7b

这步会根据网络情况耗时不等。模型文件比较大，建议确认磁盘空间充足。拉取完成后你可以直接用 ollama run qwen2.5-coder:7b 先跟它对话试试，如果这一步通了，后面的 Opencode 对接就会非常顺利。

还有一个细节要注意：Ollama 默认只允许本地访问。如果你想在多台机器或容器里通过 IP 访问 Ollama，需要修改环境变量 OLLAMA_HOST=0.0.0.0。但如果是 Windows 本机调试，直接用默认的 127.0.0.1 就好，没必要开放远程访问。开放远程会带来不必要的安全风险，你本机的其他应用也能顺手调用你的本地模型端口。

2.3 Git 与终端环境的坑

Git 在 Windows 下不光是版本控制工具，更是 Opencode 运行时的依赖——它需要 Git 自带的那些 Unix 工具（比如 bash、sh）来执行某些 shell 操作。安装 Git for Windows 时，建议在安装向导里选择“Use Git from Windows Command Prompt”，这样 git、bash 这类命令会自动加进 PATH，后面省心很多。

终端方面，强烈建议装 Windows Terminal 并用它来运行 Opencode，而不是用老的复古 conhost。Opencode 会输出丰富的颜色和交互式 UI，Windows Terminal 对 ANSI 转义序列的支持好得多，显示效果完全是两个世界。另一个容易忽略的问题：如果你用的是 PowerShell 5.1，执行策略默认是 Restricted，可能连 opencode 都启动不了。先执行下面这条命令查看当前策略：

bash复制Get-ExecutionPolicy

如果是 Restricted，改成 RemoteSigned 即可：

bash复制Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

这些前置问题弄完，Opencode 的安装和运行才能算真正顺了。

3. 安装 Opencode 的完整过程

3.1 用 npm 全局安装

安装命令很简单：

bash复制npm install -g opencode-ai

这里有个认知误区要澄清：Opencode 的包名不是开箱即用的 opencode，而是 opencode-ai。如果你直接 npm install -g opencode 去搜，会命中一堆完全不相关的包。这是文档里一句话带过、但坑了无数人的地方。装完之后验证一下：

bash复制opencode --version

如果提示命令找不到，多半是 npm 全局配置的 bin 目录没加进 PATH。你可以用 npm prefix -g 查看全局安装路径，然后把对应的 bin 目录手动加到系统环境变量里。Windows 上常见的全局路径是 C:\Users\xxx\AppData\Roaming\npm，确认这个目录在 PATH 中即可。

3.2 验证安装与启动引导面板

第一次在终端里执行 opencode，它会进入一个初始化的引导面板，要求你选择要连接的模型服务商。这里可以直接退出引导，因为我们接下来要配置自定义 provider，通过引导选出来的服务商大概率不是你真正要用的。

退出引导后，Opencode 可能会因为找不到任何可用的 provider 而提示错误，这属于正常现象，不用慌。你接下来只需要把自定义配置写好，一切就会恢复正常。

如果哪天你想重装或升级到最新版本：

bash复制npm install -g opencode-ai@latest
npm uninstall -g opencode-ai

升级后建议对比一下文档中提到的 breaking change，大版本更新时 Opencode 的配置结构偶尔会变化。

3.3 一个可选但推荐的做法：通过项目级配置隔离模型环境

前面提到 Opencode 支持项目级配置，这在自定义模型场景下特别实用。你可以在某个具体项目里放一个 .opencode/config.json，把该项目专属的模型和提示词全部放进这个文件。这样一来，换一个项目不会影响全局配置，同一个老板让你维护多个项目时也不会出现模型错乱。

我在实际使用中会把一个通用的 provider 配置放在全局，而把具体模型和提示词放在项目级配置中。这样即使不同项目用同一个模型网关，各自的参数、上下文限制、提示词也完全隔离，调起来互相不干扰。

4. 自定义模型配置的完整拆解

4.1 配置文件的目录与文件格式

Opencode 的配置文件是一个 JSON 文件，常见的位置是全局配置目录。在 Windows 下，全局目录位于：

text复制C:\Users\你的用户名\.config\opencode\opencode.json

如果你的系统设置了 XDG_CONFIG_HOME 环境变量，那位置会变成 %XDG_CONFIG_HOME%\opencode\opencode.json。项目级的位置是 .opencode\opencode.json。

因为 Windows 的 explorer 默认隐藏带点开头的文件夹，所以在资源管理器里可能看不到 .config 目录。建议直接在终端里用命令处理：

bash复制mkdir -p $HOME\.config\opencode
notepad $HOME\.config\opencode\opencode.json

文件创建好之后，我建议直接编辑它，而不是通过 UI 操作。

4.2 Provider 配置详解：从本地 Ollama 到远程网关

先看一个基础的 Provider 配置，以本地 Ollama 为例：

json复制{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (本地模型)",
      "options": {
        "baseURL": "http://127.0.0.1:11434/v1"
      },
      "models": {
        "qwen2.5-coder:7b": {
          "name": "通义千问 Coder 7B"
        }
      }
    }
  },
  "model": "ollama/qwen2.5-coder:7b"
}

逐项拆解一下：

• provider 下定义了一个 key 叫 ollama，这个 key 是 provider 的标识符，后续引用模型时要用它作为前缀。
• npm 字段指定了该 provider 要使用哪个 SDK 包。@ai-sdk/openai-compatible 是通用兼容包，可以对接一切兼容 OpenAI 协议的端点，包括 Ollama、各类网关、各种开源模型推理服务。
• options.baseURL 是接口地址。Ollama 的 OpenAI 兼容端点是 /v1，这一点很容易写错。如果你写成了 http://127.0.0.1:11434，请求会 404，而且报错信息很误导人。
• models 下面列出该 provider 可用的模型。qwen2.5-coder:7b 是 Ollama 里的模型名，需要跟 ollama list 看到的 tag 完全一致，否则请求时找不到模型。
• 最外层的 model 是“默认模型”，格式是 providerId/modelId。这里写 ollama/qwen2.5-coder:7b，Opencode 启动后就会默认使用这个。

如果你要连的是一个远程 OpenAI 兼容网关，Provider 结构几乎一样，只是 options.baseURL 换成网关地址，同时要增加 apiKey 字段。要注意的是 apiKey 最好通过环境变量注入，而不是硬编码在配置文件里。Opencode 支持在配置里使用变量占位符，例如：

json复制{
  "provider": {
    "mygw": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "公司模型网关",
      "options": {
        "baseURL": "https://gateway.example.com/v1",
        "apiKey": "{env:MY_GATEWAY_API_KEY}"
      },
      "models": {
        "gpt-4-family": { "name": "大模型" },
        "code-fast": { "name": "轻量模型" }
      }
    }
  },
  "model": "mygw/gpt-4-family"
}

这里 {env:MY_GATEWAY_API_KEY} 的写法是 Opencode 支持的环境变量引用。好处很明显：配置文件可以提交到仓库，但密钥始终留在本机环境变量里。在 Windows 下设置用户环境变量的命令是：

bash复制setx MY_GATEWAY_API_KEY "sk-xxxx"

注意 setx 设置完成后，需要重开终端窗口才能生效。否则你配置半天，一直提示鉴权失败，可能只是环境变量没刷新。

4.3 模型级别的参数细化

模型并不是只能填一个名字，它还可以配置很多行为参数。常用的几个字段我列一下：

• temperature：控制随机性。代码生成任务我一般设 0.2 或 0.3，太高会让模型发挥不稳定。
• maxTokens：单次生成的最大 token 数。设得太小会导致长代码习惯性截断。
• contextLength：上下文窗口长度。这个参数特别重要，取决于你用的模型和推理服务的限制。
• reasoning：是否开启推理模式。Stream 系列或部分模型支持这种参数。
• cost：用来做 token 计费的标记。

一个典型的完整模型配置示例：

json复制{
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (本地)",
      "options": {
        "baseURL": "http://127.0.0.1:11434/v1"
      },
      "models": {
        "qwen2.5-coder:7b": {
          "name": "Qwen Coder 7B",
          "temperature": 0.2,
          "maxTokens": 8192,
          "contextLength": 32768
        }
      }
    }
  },
  "model": "ollama/qwen2.5-coder:7b"
}

4.4 系统提示词与工具能力的自定义

除了模型本身，Opencode 的自定义程度很高的一块是系统提示词。你可以在配置里用 instructions 字段写一段额外的提示词，追加到 Opencode 内置系统提示词后面。这个字段对于自定义模型场景非常关键。为什么？因为很多自部署模型，尤其是参数量较小的模型，指令遵循能力不如大厂商业模型，你需要在系统提示词里把行为约束写得更直白、更细粒度。

举个例子，我自己在配小模型时，会在 instructions 里明确加上：直接输出代码，不要解释；按照项目现有风格编码；不确定时先说不知道；禁止编造 API。这些指令对于参数量小的模型来说比什么都管用。

另外，permission 模块是 Opencode 的权限控制核心。你要不要允许模型自动执行终端命令、自动修改文件？默认情况下它有一套安全策略，但在本地可信环境中可以把限制放宽。不过你在公司环境里用公共网关的时候，我建议不要把自动执行打开，否则模型一旦被诱导执行了危险命令，后果很难收拾。

4.5 多 Provider 切换的实用配置

最后再说一个实用技巧：在同一个配置文件里配置多个 Provider，然后通过默认 model 选一个，运行中用 /model 命令切换。比如我一个配置文件里同时配了 Ollama 本地模型和公司网关模型，平时默认走公司网关，跑一些敏感代码审查时切换到本地模型，整个过程不需要改任何配置，非常丝滑。

这个切换能力也是我坚持用 Opencode 而不是某些商业 CLI 的重要原因。商业 CLI 通常把模型选择锁死在自家生态里，而 Opencode 这种配置文件驱动的设计自由度大太多。

5. 实操演示：从零跑通一个本地自定义模型

5.1 端到端完整配置流程

我拿 Ollama + Qwen Coder 7B 作为例子，带你完整走一遍。这个组合在 Windows 上最能体现配置流程的每个关键环节。

第一步，确认 Ollama 服务正常并已经拉取模型：

bash复制ollama list

输出里应该能看到 qwen2.5-coder:7b。如果没有，执行：

bash复制ollama pull qwen2.5-coder:7b

第二步，创建配置文件。用编辑器打开全局配置：

bash复制notepad $HOME\.config\opencode\opencode.json

写入：

json复制{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (本地模型)",
      "options": {
        "baseURL": "http://127.0.0.1:11434/v1"
      },
      "models": {
        "qwen2.5-coder:7b": {
          "name": "Qwen Coder 7B"
        }
      }
    }
  },
  "model": "ollama/qwen2.5-coder:7b",
  "instructions": "你是一个资深程序员。直接输出代码，不要解释。回答请使用简体中文。"
}

第三步，在终端里启动：

bash复制opencode

正常情况下，你会看到 Opencode 的交互式界面，并且默认模型已经变成了 ollama/qwen2.5-coder:7b。如果不确定当前在用哪个模型，输入：

text复制/model

会列出当前 Profile 下所有可用模型，并标出当前选中的那个。

第四步，试一个简单的任务。比如：

text复制请写一个 Python 函数，实现把一个目录下所有 .log 文件按时间排序后合并输出到一个新文件。

观察响应速度和质量。如果模型很快输出代码，并且文件操作正常，说明链路已经通了。如果响应很慢，多半是模型推理能力不足或者 contextLength 配置过大，可以调整。

5.2 更复杂的接入验证：OpenAI 兼容网关

接远程网关时，最关键的是先验证网关本身是否可用。我一般先拿 curl 测一下：

bash复制curl https://gateway.example.com/v1/models -H "Authorization: Bearer $env:MY_GATEWAY_API_KEY"

如果网关支持 /v1/models 端点，会返回一个模型列表 JSON。这一步能帮你确认三件事：网关地址是否正确、鉴权是否有效、模型 ID 到底长什么样。很多自定义配置失败，就是因为模型 ID 写错了。网关返回的模型 ID 跟你以为的模型名可能是两回事。

确认之后，把 Provider 配置改成网关参数，再启动 Opencode 测试即可。

5.3 配置文件校验：养成好习惯

写完配置文件，建议先做个 JSON 语法校验。最快速的方法是把文件内容粘贴到任意 JSON 校验工具里，或者用 Node.js 校验：

bash复制node -e "JSON.parse(require('fs').readFileSync(process.env.HOME + '/.config/opencode/opencode.json', 'utf8')); console.log('ok')"

当然，在 Windows 下 $HOME 环境变量同样可用。如果校验通过，再启动 Opencode，你会少很多无谓的排查时间。

6. 常见问题与排查技巧实录

6.1 配置不生效或找不到配置文件

这是一个高频问题。症状是明明改好了配置，但 Opencode 启动后还是报错找不到模型或 provider。首先确认你改的是不是 Opencode 真正读取的那个文件。用下面这行命令打印出实际加载的配置路径：

bash复制opencode debug

它会输出 Opencode 当前加载的配置、环境变量和各类路径。如果你的配置文件路径跟这个输出不一致，那说明你改错文件了。另外一个排查思路是启用 --no-project-config 启动参数，排除项目级配置的干扰。如果加了这个参数就正常了，那问题基本就在项目目录里的 .opencode 配置上。

6.2 请求报错 404 或模型不存在

如果你配置的是 Ollama，报 404 大多是因为 baseURL 写错了。Ollama 的 OpenAI 兼容端点是 http://127.0.0.1:11434/v1，不是 http://127.0.0.1:11434。网关类服务同理，要确认你的端点是否带 /v1 前缀，要看服务方文档。

如果 URL 没问题但还是 404，那就检查模型 ID。Ollama 里要用 ollama list 显示的完整 tag 名，比如 qwen2.5-coder:7b。少写一个冒号后缀都找不到模型。远程网关的模型 ID 要以网关实际返回的为准，前面演示的 curl 命令就是为了拿到这个准确的 ID 列表。

6.3 认证失败或 401 错误

401 基本可以断定是 apiKey 配置问题。优先检查环境变量是否真的存在。Windows 下可以在 PowerShell 里执行：

bash复制echo $env:MY_GATEWAY_API_KEY

如果没有输出，就是环境变量没设置成功。注意 setx 设置完必须重开终端。还有一点：配置文件里的占位符写法 {env:MY_GATEWAY_API_KEY} 一定不要漏掉 env: 前缀，否则 Opencode 会把它当成字符串字面量发送出去。

另外，某些网关要求请求头里带的是 Authorization: Bearer <key>，OpenAI 兼容 SDK 已经默认这么做，你不用额外配置。但如果你自定义的不是 OpenAI 兼容协议，而是某个私有协议，那就要考虑自定义 npm SDK 包的问题了，这个话题比自定义模型还要深一层，本文先按下不表。

6.4 输出乱码与终端显示问题

这是 Windows 玩家特有的痛苦。Opencode 界面里的中文如果变成乱码，通常不是模型问题，而是控制台代码页问题。在 PowerShell 里先执行：

bash复制chcp 65001

然后重开 Opencode。如果你用 Windows Terminal，可以在配置文件的 profiles 里把 "intenseTextStyle": "bright" 之类的显示设置调整一下，但最核心的还是把默认终端字体改成支持 Unicode 的，比如 Cascadia Mono 或 Consolas。我自己用过 Cascadia Mono，显示效果在 Windows Terminal 里几乎没有乱码问题。

6.5 响应很慢或模型没有输出

Opencode 启动后模型半天不回复，排查顺序应该是：CPU/GPU 是否在推理（本地模型看任务管理器，远程模型看网关日志）、上下文是否被塞爆、maxTokens 是否太小被截断。本地模型慢，大概率不是 Opencode 的问题，而是模型参数太大、量化等级不够，或者 CPU 推理没有走 GPU。你可以用 ollama ps 查看当前模型的运行时状态。要是模型已经加载，但显存不够，它会退化成 CPU 推理，速度会慢到怀疑人生。

6.6 常见问题排查速查表

7. 几个值得深入的自定义方向

如果你按上面的步骤已经跑通，那恭喜你，自定义模型的基本链路已经掌握。接下来还有一些更有意思的玩法，我在实践中摸索过，值得分享。

第一个是把 Opencode 跟团队内部的知识库网关对接。做法很简单：还是在 Provider 层加一个网关地址，然后把模型 ID 指到网关提供的带知识库增强的模型别名。这样在 Opencode 里提问时，模型可以自动检索团队知识库，而不是凭空回答。关键点是你要理清网关的模型别名和普通模型的区别，别把两个模型 ID 搞混。

第二个是自定义工具权限。Opencode 可以控制哪些工具自动执行、哪些工具需要人工确认。比如你可以让模型自动读写项目文件，但执行删除或安装依赖时必须弹窗确认。这个功能在公司环境里的价值太大了，既保留了 AI 的效率，又守住了安全底线。我一般把 write 列为自动，bash 列为手动确认，效果比较均衡。

第三个是接入多模态模型。Opencode 不只是处理代码文本，如果模型支持视觉，你可以粘贴截图，让模型解读 UI 报错或设计稿。配置方式完全一样，只要 Provider 背后跑的是一个多模态模型就行。遇到前端布局宽度不对，直接截图发给 Opencode 让它分析 CSS 问题，比凭空描述高效得多。

这几个方向目前我都在用。我的体会是：Opencode 这个工具真正的爽点，在于它把“模型能力”和“开发工作流”解耦了。模型可以随时换，工作流始终保持一致。今天你用本地小模型跑私有代码，明天切到公司高精度网关做复杂重构，全程只需要一个 /model 命令。

最后再分享一个我在实际使用中总结出来的小技巧：初始排查阶段不要用复杂的 Profile 配置，先写一个最简单的 provider + model 配置，跑通链路之后，再逐步叠加 instructions、permission、多个 Provider 这些高级功能。很多人一上来就照着网上的复杂配置抄，结果出了问题根本无从下手。我踩过这个坑，希望你不用再踩。按这个节奏来，你在 Windows 下把 Opencode 配成顺手的样子，基本一个下午就够了。