企业官网建设流程全解析

1. 自定义 provider 接入后，推理程度为什么总是不受控

很多人第一次在 open code 里接自定义 provider，注意力都放在“能不能连上”这件事上：Base URL 填对、Key 填对、模型名填对，发一条请求能出字，就觉得大功告成。真正用起来才发现另一个问题——模型要么话太多，要么想太浅。写个正则表达式它给你输出三段推理过程，问个简单概念它又一句话带过，完全不受你控制。

这个现象在本地/自建模型服务场景里尤其明显。因为官方托管的模型往往在服务端就帮你把推理预算调好了，而自定义 provider 把这份控制权交回给了你。open code 作为客户端，本身不会替你做“这个任务该想多深”的判断，它只负责把请求发出去。于是推理程度（也就是大家常说的思考程度、reasoning effort）到底给多少，取决于你在opencode.json里怎么声明。

我试过在同一个自建服务上跑两类任务：一类是补全一个 TypeScript 类型定义，另一类是让它分析一段有并发 bug 的代码。如果都用默认配置，前者会浪费大量 token 在无意义的推理上，后者又可能因为推理预算不足而漏掉关键路径。解决办法不是换模型，而是在 open code 里给同一个模型挂上不同档位的 variant，用快捷键或斜杠命令切换。

这篇内容就围绕opencode.json展开，讲清楚三件事：自定义 provider 的模型怎么声明推理档位、配置改完怎么验证生效、以及不同任务怎么匹配不同思考深度。全程给可复制的配置片段和验证动作，你跟着改完重启就能对比输出长度和耗时的变化。

需要先说明一个前提：推理程度这个参数能不能真正生效，取决于你的自定义 provider 背后的服务是否支持对应的字段。open code 负责把reasoningEffort这类参数透传出去，服务端认不认是另一回事。所以下面的验证步骤里，我会让你同时观察输出长度和耗时，用这两个指标反推参数有没有被消费。

2. TaoToken 前置：把自定义 provider 的 Base URL 和 Key 准备好

在动opencode.json之前，得先有一个能用的 provider 端点。如果你用的是自建服务，Base URL 通常是你本机的地址加端口，比如http://127.0.0.1:8000/v1这种形式。如果你希望走一个统一的网关来管理多个模型、统一计费和鉴权，可以用 TaoToken 的 API 端点作为 provider 的 Base URL。

TaoToken 的 API 地址是https://taotoken.net/api，注意这个地址后面不加任何查询参数。在 open code 的 provider 配置里，你需要填的是这个 Base URL 加上你的 API Key。Key 的获取入口在控制台的 API Keys 页面，登录后新建一个即可。模型对话的入口可以用来先手动验证某个模型能不能正常出字，确认链路通了再写进配置文件。

这里要强调一个容易踩的坑：open code 的 provider 配置里，Base URL 的写法和你直接 curl 时不完全一样。有些 provider 需要你在 URL 末尾带上/v1，有些则不需要，取决于它内部的路径拼接逻辑。TaoToken 的 API 端点https://taotoken.net/api是标准写法，open code 会在此基础上拼接具体的模型路径。如果你填成https://taotoken.net/api/v1，可能会出现路径重复导致 404。

另外，自定义 provider 的模型 ID 必须和你服务端注册的模型名完全一致，大小写敏感。比如服务端注册的是my-local-qwen，你在配置里写成My-Local-Qwen就会报模型不存在。这个错误在 open code 里通常表现为请求发出后返回一个明确的错误信息，而不是静默失败，所以排查起来不算难。

准备好这两样东西——Base URL 和 API Key——就可以进入下一步写配置了。如果你还没有 Key，先去控制台建一个；如果你已经有自建服务的地址，直接用它也行。下面的配置示例里我会用占位符，你替换成自己的实际值即可。

3. 可复制的 opencode.json 配置：给模型挂上 reasoningEffort 档位

open code 的配置文件位置在 Windows 上是C:\Users\你的用户名\.config\opencode\opencode.json，在 macOS 和 Linux 上通常是~/.config/opencode/opencode.json。如果这个文件不存在，手动创建一个即可。配置的核心结构是provider下面挂各个 provider，每个 provider 下面挂models，每个模型可以带一个variants字段。

下面是一个完整的可复制片段，你可以直接改掉 Base URL、Key 和模型名后使用：

{ "provider": { "taotoken": { "npm": "@ai-sdk/openai-compatible", "options": { "baseURL": "https://taotoken.net/api", "apiKey": "sk-你的实际Key" }, "models": { "my-reasoning-model": { "name": "my-reasoning-model", "variants": { "low": { "reasoningEffort": "low" }, "medium": { "reasoningEffort": "medium" }, "high": { "reasoningEffort": "high" }, "max": { "reasoningEffort": "max" } } } } } } }

这段配置做了几件事。npm字段声明用 OpenAI 兼容协议来对接，这对大多数自建服务和网关都适用。options里的baseURL和apiKey是连接信息。models下面定义了一个模型my-reasoning-model，它的variants里有四个档位，每个档位对应一个reasoningEffort值。

这里的关键点是：variants是挂在模型级别的，不是 provider 级别。也就是说，同一个 provider 下的不同模型可以有完全不同的档位定义。比如你有一个快速补全模型和一个深度推理模型，前者可能只需要low和medium，后者才需要high和max。

配置写完后，保存文件，然后重启 open code。重启这一步不能省，因为 open code 在启动时读取配置，运行中修改文件不会热加载。重启后，你可以用快捷键Ctrl + T来切换当前模型的 variant，或者输入/variants命令来查看和选择。如果这两个操作都没反应，说明配置没有生效，需要回到文件检查 JSON 语法是否正确。

一个常见的 JSON 语法错误是尾随逗号。比如"max": { "reasoningEffort": "max" },后面如果还有内容，这个逗号是合法的；但如果它是最后一个字段，逗号就会导致解析失败。open code 在配置解析失败时通常不会给出很详细的提示，所以建议改完后用编辑器的 JSON 校验功能先过一遍。

另外，reasoningEffort的取值不是所有服务端都支持max这个档位。有些服务只认low、medium、high三档，你写max它可能会忽略或者报错。这种情况下，你可以把max映射成high，或者干脆去掉这一档。验证方法在下一节。

4. 验证请求：改配置、重启、发测试请求对比输出

配置改完重启后，怎么确认reasoningEffort真的生效了？最直接的办法是发一条测试请求，对比不同档位下的输出长度和耗时。这里给一个可复现的验证流程。

先准备一条测试 prompt，要求它做一件需要一定推理但又不至于太复杂的事，比如：“用 TypeScript 写一个函数，判断一个字符串是否是合法的 IPv4 地址，要求处理边界情况。”这条 prompt 的好处是，推理程度低的时候模型可能直接给一个简单正则，推理程度高的时候它会考虑前导零、段数、数值范围等边界。

然后按以下步骤操作：

第一步，用Ctrl + T或/variants把当前 variant 切到low，发送这条 prompt，记录输出字符数和从发送到完成的时间。你可以用秒表粗略计时，或者看 open code 界面上的耗时显示。

第二步，切到high，发送同样的 prompt，再次记录输出字符数和耗时。

第三步，切到max（如果你的服务端支持），重复一次。

如果配置生效，你应该能观察到：low档位的输出明显更短、更快，可能只给了一个基础正则；high和max档位的输出更长，会包含边界处理的说明，耗时也相应增加。如果三个档位的输出完全一样，长度和耗时都没有变化，那说明reasoningEffort没有被服务端消费。

这种情况下，先检查你的服务端是否支持这个参数。有些自建推理服务用的是自己的参数名，比如thinking_budget或reasoning_tokens，而不是reasoningEffort。open code 透传的是reasoningEffort，如果服务端不认，它可能会忽略这个字段，导致所有档位行为一致。

另一个验证角度是看请求日志。如果你能访问 provider 服务端的日志，可以直接搜索请求体里有没有reasoningEffort字段，以及它的值是什么。这是最确定的验证方式，比看输出长度更可靠。

如果服务端确实不支持reasoningEffort，但你用的网关支持参数映射，可以在网关层做一层转换，把reasoningEffort映射成服务端认识的参数。TaoToken 的接入文档里有关于参数透传和映射的说明，可以参考。这种情况下，open code 侧的配置不用改，改的是网关侧的规则。

5. 本篇常见错排查：401、local proxy failed、reading choices、OAuth

配置自定义 provider 时，报错信息往往比较隐晦。下面列几个高频错误和对应的排查方向。

401 Unauthorized：这个最直接，Key 不对或者没带上。检查opencode.json里apiKey字段的值，确认没有多余空格，确认 Key 没有过期或被撤销。如果你用的是 TaoToken，去控制台的 API Keys 页面确认这个 Key 的状态是启用。另外注意，有些 provider 要求 Key 以Bearer前缀传递，open code 的 OpenAI 兼容模式通常会自动加，但如果你用的是自定义 npm 包，可能需要手动在options里加headers。

local proxy failed：这个错误通常出现在你配置了本地代理或者网关地址，但 open code 连不上那个地址。检查baseURL是否可达，用curl或浏览器访问一下。如果是本机服务，确认端口没有被防火墙拦截，确认服务进程在运行。如果是远程网关，确认网络连通性。这个错误和推理程度无关，是连接层的问题。

reading choices 相关报错：这类错误通常意味着服务端返回的响应结构不符合 OpenAI 兼容格式。open code 期望响应里有choices数组，如果服务端返回的是自定义结构，就会解析失败。解决办法是在 provider 配置里指定正确的响应解析方式，或者用网关做一层格式转换。如果你用的是自建服务，检查它的 API 是否真的兼容 OpenAI 的/v1/chat/completions格式。

OAuth 相关报错：如果你配置的 provider 需要 OAuth 而不是 API Key，open code 的apiKey字段就不适用了。这种情况下需要走 OAuth 流程，通常涉及在浏览器里授权然后回调。open code 对 OAuth 的支持取决于你用的 npm 包和 provider 类型。如果你只是想用 API Key 方式接入，确认你的 provider 支持这种鉴权方式。

排查时的一个通用技巧：把 open code 的日志级别调高，或者在启动时加--verbose之类的参数（取决于版本），这样能看到完整的请求和响应。很多错误在详细日志里一目了然。

另外，如果你在配置里同时写了variants和模型级别的其他参数，注意 JSON 的层级不要写错。variants是models下面某个模型的字段，不是provider的字段，也不是options的字段。写错层级会导致配置被忽略但不报错，表现为切换 variant 没反应。

6. 按任务匹配思考深度：把 variant 用成日常习惯

配置生效之后，真正的价值在于把不同 variant 用在不同任务上。我的习惯是：代码补全、格式化、简单重命名这类任务用low，让它快速出结果，不要浪费推理预算；代码审查、bug 分析、架构讨论用high或max，让它把边界情况想清楚。

切换方式就是Ctrl + T循环切换，或者/variants选择。你可以在 open code 里为不同项目设置不同的默认 variant，这样打开项目时就自动匹配。具体做法是在项目根目录放一个.opencode配置或者在工作区设置里指定，取决于你的 open code 版本。

如果你希望把多个模型统一管理，并且在不同项目间共享 provider 配置，用 TaoToken 的 API 端点作为 Base URL 会比较省事。Key 在控制台统一管理，模型对话入口可以快速验证某个模型在当前档位下的表现。长期做编码和 Agent 任务的话，Coding Plan 提供了更稳定的调用额度，适合把 variant 切换变成日常操作。

最后给一个实用技巧：在切换 variant 后，不要只看输出长度，还要看输出质量。有时候low档位虽然短，但恰好给出了你需要的答案；high档位虽然长，但可能绕了弯路。推理程度高不等于结果一定好，关键是匹配任务。你可以为常用任务建一个简单的对照表，记录哪个 variant 在哪个任务上表现最好，用几次就有感觉了。