OpenCode 模型怎么选？7 个标准对比托管、本地与免费模型

没有一个模型永远适合所有任务。复杂推理优先选择稳定的托管模型，日常改代码使用均衡的编程模型，隐私或离线要求则考虑本地模型；免费或套餐内模型适合验证工作流，但不应被默认视为永久的质量保证。本文把“哪个模型最好”拆成可以重复执行的判断步骤。

擅长长篇架构规划的模型，不一定适合每一次小改动。可以先把工作分成四类：推理与规划、代码实现、解释与文档、快速转换。规划需要跨多个步骤保持一致；实现需要准确修改代码并正确使用上下文；文档更重视清晰和速度；简单转换则没有必要占用昂贵模型。

选择 OpenCode 模型时，先写下预期输出、答错的代价、需要提供多少仓库上下文，以及模型是否必须调用工具。只读解释可以先用快速模型；会改动多个文件的迁移则应选择更强模型，并在执行前要求计划、假设和回滚方式。这样即使模型目录变化，判断标准仍然有效。

不要用“最佳模型”替代具体需求。如果工作接近补全式编辑，延迟可能比最高推理能力更重要；如果是生产事故排查，稳定性和可追溯性通常比小额价格差更重要。下一节的选择流程能把这些取舍显式写出来。

托管模型通常适合做第一轮基准，因为运行环境由服务商维护，模型通过端点提供。需要更强推理、较大上下文或较稳定工具行为时，它是常见起点；代价是网络依赖、服务商政策和调用成本。涉及私有代码前，应先确认数据会发往哪里以及服务条款如何处理。

本地模型不是简单的“便宜版托管模型”，它受到显存或内存、计算能力、量化方式、运行时和工具调用能力影响。本地推理适合隐私、离线或实验，但往往需要更小的提示词和更明确的任务边界。连接与运行细节可继续查看站内 Ollama 指南，本文只负责判断本地路径是否适合当前任务。

套餐或订阅内模型可以统一账单并快速开始，但仍要检查能力边界：额度可能变化，模型可能调整，上下文或工具限制也可能影响大仓库工作。不要把价格套餐直接当作能力保证，套餐比较和模型选择应分别判断。

上下文长度只有在模型能准确使用相关信息时才有价值。把整个仓库都送进去可能增加噪声和成本，却不一定改善答案。先提供能证明任务所需的最小文件集合，只有证据不足时再扩大范围；在 OpenCode 中还要检查 agent 能读什么、启用了哪些工具，以及提示词是否要求具体输出。

交互式终端很在意延迟。一次高风险规划可以接受慢模型，但重复的小改动更适合快速模型。稳定性不仅是服务是否在线，也包括格式一致、工具选择正确、面对不确定信息时会承认限制，以及失败时是否可预测。隐私是项目约束，不是宣传用语；选择服务商前先确定哪些代码允许离开本机。

对候选模型使用同一个任务、提示词和上下文做小型对照测试，记录首个有用结果的时间、总耗时、错误数、改动文件数、事实错误和是否需要大量返工。把结果连同模型标识和日期保存下来，推荐才会可复核，而不是依赖记忆。

OpenCode 的模型配置采用 provider/model 形式。具体服务商标识和模型 ID 应以服务商当前文档为准，确认前先使用占位符。根据使用范围把选择放在用户配置或项目配置中：仓库默认值要让团队成员一眼看懂，密钥则应留在服务商凭据流程或环境变量中。

最小可审查的配置比复制一大串模型目录更稳妥。先设置一个默认模型，用只读或低风险任务验证，再记录它为什么适合这个仓库。如果同事需要换模型，写清原因和取舍，不要悄悄改变共享默认值。模型、服务商和配置结构应以官方文档为准。

{
  "$schema": "https://opencode.ai/config.json",
  "model": "provider/model-id"
}

不要用炫技 Demo 评价模型。选择接近真实工作的基准：解释一个陌生模块、提出计划但不修改、实现一个边界清晰的变更、审查生成的 diff。每个候选使用相同仓库上下文、提示词和验收标准。听起来很聪明但漏掉约束的模型，不应直接成为默认模型。

用正确性、完整性、交互成本和风险四个维度记录结果。正确性看代码或解释是否准确；完整性看是否覆盖全部要求；交互成本包括等待和追问；风险包括泄露密钥、执行破坏性命令、未审查写入和没有依据的断言。这个记录比一个单一分数更能指导选择。

只有当失败模式重复出现时才切换模型。如果只有长上下文失败，先缩小上下文或换更合适的上下文能力；如果工具调用失败，先检查权限和服务商支持；如果本地运行慢，先尝试更小的模型或更窄的提示词，再决定是否放弃隐私要求。

1. 固定任务使用同一个真实任务、仓库快照、提示词和验收清单。
2. 先做只读测试先要求假设和计划，再允许可写工具。
3. 记录结果记录有用结果时间、错误、追问次数和改动文件。
4. 检查 diff发现无依据的改动、漏测或多余文件就先拒绝。
5. 设置默认值选择达到门槛且实际成本和风险最低的模型。

第一个误区是只看模型排行榜，不看自己的仓库。公开基准可能使用不同提示词、上下文、工具和日期；模型即使排名高，也可能因为服务商不可用、预算超限或补丁不稳定而不适合作为默认值。把排行榜当成假设，再用小型本地基准验证。

第二个误区是把免费模型和付费或套餐模型当成同一种体验。免费模型适合学习命令流程和验证提示词，但额度、排队、上下文和可用性都可能不同。在它通过与生产候选相同的基准前，把它限制在低风险任务。

第三个误区是还没检查配置和权限就先换模型。缺少 provider 密钥、模型 ID 错误、工具被阻止或上下文过大，都可能看起来像模型质量差。先确认服务商、模型标识、认证和实际生效的配置来源，再用 JSONC 与 MCP 指南隔离真正失败的层。

模型目录和服务商政策变化快，但仓库的基本工作流通常更稳定。把任务类型、上下文边界、验收检查和回滚方式保存在基准中；服务商更新时只替换模型标识和测量记录。这样既能保持页面和项目配置诚实，也不会声称某个模型永久最佳。

后续按边界查看相关指南：Ollama 指南讲本地模型连接，Go 与 Zen 对比讲订阅选择，JSONC 指南讲配置结构，MCP 指南讲工具上下文和权限。它们各自承接独立意图；本文负责帮助你决定先测试哪条路径。