企业官网建设流程全解析

1. 为什么我最终把 AI 编程助手装进了本地环境

先交代一下背景。我在某团队做后端开发，平时大量时间花在写胶水代码、补单元测试、改老项目接口上。今年年初开始接触 OpenCode，一开始只是当成一个“能对话的代码补全工具”来用，后来发现它远不止于此——它本质是一个可编程、可离线、可多人共用的 AI 编程助手框架。你可以把它理解成一个自带 REPL 会话引擎的终端工具：你在终端里输入自然语言指令，它调用后端大模型，再把生成的代码、解释、重构建议直接回写到项目文件里。

老实说，第一次用 OpenCode 的时候我并没觉得惊艳，因为很多在线编程助手也能做到相似的效果。真正打动我的是三点：第一，它的会话上下文可以跨终端保持，意味着我关掉窗口、第二天重启，依然能接着昨天的任务继续聊；第二，它不绑定某一家模型服务，你可以把模型地址换成任意兼容 OpenAI 接口的服务，包括一些完全内网部署的模型；第三，它的配置文件是纯文本，能放进 Git 仓库里随项目走，团队里每个人拉下来就能用一致的规则。

我之所以用“本地”来形容它，不是说它必须离线运行，而是它给了你完全掌控权。团队里一位同事的项目涉及敏感业务数据，不能把代码片段发到外部服务，他就用 OpenCode 接到了某高校实验室提供的一个内网模型网关上，整个使用过程不经过公网。另一个朋友专注前端，他把 OpenCode 接到某国产大模型 API 上，专门用来生成 Vue 组件和样式代码，说比通用助手更懂他的项目结构。这也是我写这篇入门指南的初衷：如果你只是想要一个“开箱即用”的在线助手，很多产品都够用；但如果你希望这个助手能按照你的方式工作、能适配你的网络环境、能在你不满意的任何环节动手改造，OpenCode 是当前开源方案里综合素质很高的选择。

这篇指南会覆盖从零开始部署 OpenCode 的完整流程，包括硬件评估、模型选型、配置编写、核心功能实操、多人协作落地，以及我在真实项目中使用时踩过的一些坑。适合两类读者：一类是从未接触过自建编程助手的开发者，照着操作就能跑通；另一类是已经在用类似工具、但想迁移到 OpenCode 或者想深入了解其运行机制的进阶用户。

2. OpenCode 的核心架构与工作边界：先搞清楚它能干什么

2.1 从“对话式补全”到“文件级操作”的跃迁

传统编程助手的交互逻辑是“你写代码，它补全下一条”；OpenCode 的逻辑更像是“你用自然语言写任务单，它帮你改文件”。它的核心交互单元是会话（Session），每次会话里你可以连续发出多条指令，比如“帮我重构 src/utils/format.ts 里的日期格式化函数，保持对外接口不变”，它会在后台读取文件、生成新代码、直接写入文件，然后告诉你改动了哪些地方。

这种设计带来一个明显的边界问题：**它成不成功，取决于你对任务描述得清不清楚，以及模型的代码理解能力有多强。**实际使用中我发现，如果把任务拆成一两条非常具体的指令，效果最稳定；如果一句指令里塞了五个需求，OpenCode 往往只处理了前两个。所以我会在后面的章节里专门讲“如何给 OpenCode 下达高质量指令”，这是从“能用”到“好用”最关键的一步。

2.2 三个核心模块：会话引擎、模型网关、工具链

拆开看，OpenCode 运行起来依赖三个部分。

会话引擎负责维护对话上下文、管理会话历史、解析你的指令。它会把你的每次输入（包括代码文件内容片段）打包成结构化的请求，发送给模型网关。这里注意一点：OpenCode 把代码文件内容作为上下文发送给模型，所以大文件会消耗大量 token，这也是后面要讲“上下文裁剪”的原因。

模型网关是一个适配层，它把 OpenCode 和具体的大模型 API 隔离开来。你只要在配置文件里指定 baseURL 和模型名称，它就能对接不同厂商的模型服务。我自己就用过三种：某开源代码模型（部署在某云服务器上的自托管实例）、某通用大模型 API、还有一个主打低价的对话模型。它们生成的代码质量差别不小，但 OpenCode 本身的运行机制完全一致。

工具链是 OpenCode 的扩展能力，比如 Git 集成、文件搜索、LSP（语言服务器协议）集成等。通过 LSP，OpenCode 能感知项目里的语法错误和类型信息，这让它的补全建议比纯文本预测更准。不过 LSP 配置稍有门槛，我后面会给出具体做法。

2.3 与常见在线编程助手的关键差异

很多人第一次接触 OpenCode 时会问：它和那些装在 IDE 里的助手有什么本质区别？我列了一张对比表：

这张表不是我凭空总结的，而是来自我和几个同事实际对比后的体感。OpenCode 在批量操作和可定制性上优势明显，但在单行补全的即时性和 IDE 深度集成上不如成熟的在线插件——如果你主要场景是“边敲边补全”，那它未必是最优选；如果你经常需要“按文档修改多个文件”“按指令生成单元测试”“按规范批量调整代码风格”，OpenCode 的体验会好很多。

3. 搭建前的评估与模型选型策略：不先想清楚这件事，装好也会吃灰

3.1 硬件与运行环境的最低门槛

OpenCode 本身用 TypeScript 编写，运行在 Node.js 环境上，所以第一步是准备 Node.js。官方建议不低于某个长期维护版本，实际我建议直接装最新的 LTS，省得碰到一些语法兼容问题。安装本体很小，几十兆级别，但真正占用资源的是后端模型服务。

这里要分两种情况。如果你使用云端的模型 API，本地只需要一台能跑 Node.js 的机器即可，2 核 4G 内存的开发机完全够用，OpenCode 自身占用可以忽略，主要内存消耗来自编辑器、浏览器等日常开发工具。如果你打算把模型也部署到本地，那就要认真评估硬件了——以我常用的某开源代码模型为例，量化后大约需要 12GB 显存才能流畅跑起来，这意味着至少需要一张中高端显卡；如果模型参数更大，显存需求翻倍也不稀奇。

一个常被忽视的点是磁盘空间。模型文件动辄 10GB 起，加上依赖库和日志，建议预留 100GB 空闲磁盘。我第一次部署时没在意，结果模型下载到一半磁盘满了，整个安装过程卡住，排查了半天才反应过来。另外，如果使用内存不足的机器跑本地模型，会出现生成速度极慢、甚至直接报错的现象，所以评估时要把“运行内存”和“显存”分开看。

3.2 模型选型的三条路线与对比

面对五花八门的模型，我建议按三条路线来选择：

第一是“免费额度优先”路线。适合学生、个人开发者、学习试用人群。很多模型服务商提供免费或低价额度，日常小项目完全够用。优点是零成本启动，缺点是并发限制严格、上下文窗口较小，项目稍大就容易触顶。

第二是“性能优先”路线。适合对代码质量要求较高的团队。选择编码专项优化模型，或者旗舰级通用模型，它们对复杂重构、跨文件分析的表现明显更好，但 token 费用会高不少。如果你每天生成的代码量很大，一个月的模型费用可能够买一台不错的机器。

第三是“内网合规”路线。适合数据敏感场景。把某开源代码模型部署到公司内网或私有云上，OpenCode 通过内网网关调用。这样代码完全不出域，但需要团队里有懂模型部署的人，而且要接受相对较低的生成速度。

我建议刚上手的人先走免费额度路线，把 OpenCode 的交互模式和配置方式摸熟，之后再根据实际效果决定要不要升级模型或者自建内网。不要一上来就上顶配，因为模型的能力差异在你的使用深度不足时体现不出来，反而容易因为成本问题半途而废。

3.3 一次失败的选型经历

这里分享一个反面案例。最初我给自己配了一个超长上下文的通用大模型，以为“上下文越长越好”，结果用起来非常痛苦。首先费用高得吓人，因为我习惯把整个文件都丢进上下文，每次请求都按大批量 token 计费；其次模型在长上下文下生成的代码容易“啰嗦”，经常把已经废弃的旧接口也写进新建议里。后来我换成一个代码专用模型，上下文窗口虽然短一些，但因为针对代码任务做了优化，生成的代码风格干净很多，费用也降下来了。

这个经历让我明白一个道理：上下文窗口长不代表模型聪明，它只代表它能“看”的东西多。如果你的任务本身不需要全局信息，一个专注代码任务的短窗口模型可能更合适。选模型时要结合你的任务类型、上下文消耗习惯、成本预算三个维度综合判断，而不是无脑选参数最大的那个。

4. 安装配置全流程：从零到能跑通第一次对话

4.1 安装 Node.js 与包管理器

OpenCode 通过 npm 包分发，所以先确保 Node.js 就位。我在 Ubuntu 服务器上用的是 NodeSource 源安装，在本地 Windows 上直接下载官方安装包，在 mac 上用 Homebrew。安装完执行node -v和npm -v确认版本号正常。

提示：如果机器上同时有多个 Node 版本，推荐用版本管理器管理，避免 OpenCode 依赖的包因 Node 版本不一致出现诡异问题。

然后安装 OpenCode 本体，我用的命令是：

npm install -g @opencode-ai/opencode

全局安装的好处是终端任意位置都能直接执行opencode命令。如果你不想全局安装，也可以在项目目录下局部安装，配合npx调用，但每次都要多敲几个字符，个人体验不如全局安装顺滑。

4.2 配置文件的字段逐个拆解

安装完成后，在用户主目录下执行opencode init会生成一个默认配置文件。打开它你会发现结构非常简洁，但别小看这几个字段，它们决定了 OpenCode 的“性格”。

{ "model": { "provider": "custom", "name": "your-model-name", "baseURL": "https://your-endpoint.example.com/v1", "apiKey": "your-api-key" }, "context": { "maxTokens": 8000, "autoCompress": true }, "tools": { "git": true, "fileSearch": true, "lsp": true }, "session": { "saveDir": "~/.opencode/sessions", "resume": true } }

逐项解释一下：baseURL是模型服务的地址，注意要写到/v1这一层，因为 OpenCode 会按照 OpenAI 兼容接口的路径拼接请求；apiKey填服务商分配的密钥，如果是自建模型网关，这里可以填一个自定义的令牌值；maxTokens限制每次请求的最大 tokens 输出，调低可以降低费用但可能截断长代码；autoCompress开启后，当上下文接近长度上限时，OpenCode 会自动对历史会话做摘要压缩，这个功能强烈建议开启；saveDir是会话存储位置，确认有写权限即可；lsp开启后支持语言服务器协议。

第一次配置时最容易出错的点是baseURL写错。有一些模型服务商的接口路径不是标准的/v1，比如有些必须写成/v1/chat/completions，或者多一个版本前缀。遇到这种情况，建议先用同一套 API 密钥在 curl 里手动发请求，确认接口路径正确之后再填进配置文件，能省掉大量排查时间。

4.3 跑通第一次对话：验证配置是否正确

配置完成后，在项目目录下执行opencode，会进入交互式终端界面。输入一句话：

请读取当前目录下的 package.json，然后告诉我这个项目用了哪些主要依赖。

如果配置正确，你会看到 OpenCode 先调用文件读取工具，拿到 package.json 内容，再调用模型接口，生成一段分析结果。这一小步跑通，说明从会话引擎到模型网关全链路正常。

如果这一步没成功，常见的错误有两类。一类是网络问题，报错信息里通常有ECONNREFUSED或ETIMEDOUT，这时候检查你的网络能不能访问到baseURL对应的地址，在内网环境里尤其要确认网关的防火墙规则；另一类是鉴权问题，报错信息往往是401或403，这时候重点检查apiKey是否有效、服务商是否限制了 IP 白名单。

我见过不少人在这一步卡了很久，最后发现是配置文件中多了一个空格或者一个多余的斜杠。所以，如果配置不生效，第一件事是把配置文件里的字符串全部删掉重新手打一遍，不要直接复制粘贴——这样虽然费一点时间，但能过滤掉很多隐藏字符问题。

5. 核心功能实操：从单文件补全到跨文件重构

5.1 代码补全与 Tab 接受机制

OpenCode 在交互式终端里支持类似 IDE 的代码补全体验。当你在编辑一个文件并调用 OpenCode 时，它会根据当前文件内容和你的指令生成候选代码，按 Tab 键接受，按 Esc 拒绝。这个机制和在线插件的补全非常接近，但底层逻辑有一个差异：OpenCode 的补全不是逐字符推断，而是在理解当前代码块的语义后生成一段完整的实现。

举个例子，我写一个函数parseConfig，在注释里写明“读取 config.yaml，解析并返回配置对象”，OpenCode 会把整个函数体生成出来，包括文件读取、错误处理、返回值类型定义。如果是在线的逐字符补全工具，需要我先写一半函数它才能猜另一半；而 OpenCode 从语义层面就能理解意图。当然，这也意味着你的注释和函数签名写得越清楚，补全质量越高。

有一条经验供参考：对于不熟悉的第三方库，OpenCode 生成的调用代码经常会有 API 版本不对的隐患，因为它训练数据里混着不同版本的用法。我的习惯是让 OpenCode 生成代码后，用 LSP 或编译器的报错信息做一次校验，不要盲目相信生成结果。

5.2 斜杠命令与自定义快捷指令

OpenCode 内置了一批斜杠命令，最常用的是/new开启新会话、/resume恢复历史会话、/help查看帮助、/tokens查看当前上下文消耗。这些命令看似简单，但组合起来能形成高效工作流。

比如我每天上班第一件事是执行/resume，找到昨天的会话继续开发，不需要重新描述一遍项目背景。实现一个较复杂功能时，我会先/new开一个干净的会话，把需求背景完整描述一次，然后逐条下达子任务，这样上下文里全是当前功能相关的信息，不会因为混入旧任务而干扰模型判断。

更高级的用法是自定义快捷指令。配置文件里可以定义斜杠命令的展开模板，比如我定义了一个/review命令，它会自动把当前 Git 暂存区的改动全部读取出来，然后生成一份代码审查意见。实现起来就是在配置文件中加一段：

{ "commands": { "review": "请查看当前 git 暂存区的所有改动，按文件逐个审查，重点关注潜在 bug、边界条件、性能问题和安全漏洞，给出具体的修改建议。" } }

这样每次执行/review都会按同样的标准做代码审查，不会因为当天的措辞不同而改变审查维度。

5.3 结合 LSP 的实时诊断与错误修复

开启 LSP 集成后，OpenCode 能读取当前文件的语言服务器诊断信息。什么意思呢？当你打开一个 TypeScript 文件，如果里面有类型错误，OpenCode 能感知到这些错误的具体位置和原因，然后在你下达修复指令时，生成针对这些错误的高质量修复代码。

这个功能的实用价值非常大。之前我手动改一晚上都调不对的类型报错，用 OpenCode 配合 LSP 几分钟就搞定了。它甚至会告诉你“第 25 行的类型不匹配，因为函数的第三个参数被定义成了可选，但实际传参时没有走可选分支”，这种级别的诊断能力已经超越了普通代码补全工具。

不过 LSP 集成有个前提：你的项目本身要能正常跑起来语言服务器。如果 TypeScript 版本太老、或者 tsconfig.json 配置有问题，LSP 加载失败，OpenCode 自然也就诊断不出问题了。所以遇到“明明有错误但 OpenCode 看不到”的情况，先检查语言服务进程是否正常，这往往不是 OpenCode 的问题。

6. 多人协作与团队场景落地：配置文件进仓库的正确姿势

6.1 团队共享配置：从“个人工具”到“团队规范”

OpenCode 支持在项目根目录放置.opencode.json配置文件，这个文件会被 Git 跟踪。团队里每个人 clone 代码后，只要安装了 OpenCode，拉到这份配置就能继承团队设定的模型参数、指令模板、上下文策略。这对于保持团队代码风格一致性很有帮助。

我所在的团队就约定了一份共享配置，里面做了一件事：禁止生成包含调试输出代码。我们在配置文件中加入了一条规则，要求 OpenCode 生成的代码不能包含console.log，除非显式要求。结果一段时间后，团队代码里的临时调试语句明显变少了，代码合并时的噪音也少了很多。这种“通过配置文件约束 AI 行为”的能力，是用在线编程助手时很难做到的。

当然，配置文件进仓库也带来了一个需要注意的问题：不要把个人 API 密钥提交进去。正确做法是在配置里引用环境变量，比如"apiKey": "{OPENCODE_API_KEY}"，每个人在自己的 shell 环境里设置对应的环境变量。我在刚开始没注意这个细节，结果把密钥直接写进了配置并推到了仓库上，虽然立刻撤销了，但想起来还是有点后怕。

6.2 内网模型的接入：受限环境的落地经验

在数据敏感的团队项目里，公网模型服务不可用，这时候 OpenCode 的内网模型接入能力就派上用场了。我们当时的做法是搭建一个内网模型网关，然后在配置里把baseURL指向网关地址。OpenCode 本身不需要特殊改动，只要网络能连通网关就行。

这里有三个需要提前规划的点。第一是网关的并发能力，模型推理是资源密集型的，多个开发同事同时使用时会互相挤占资源，导致响应变慢。建议根据团队规模合理设置网关的队列长度和最大并发数。第二是模型的选择，内网部署模型通常比云端模型能力弱一些，所以任务拆分要更细，指令也要写得更明确。第三是模型更新流程，内网模型的版本升级不像云端 API 那样透明，建议在升级前先在一台测试机上跑一遍典型任务，确认效果没有退化再全量切换。

实际运行过程中我们发现，OpenCode 的会话恢复功能在内网场景价值巨大。因为在受限网络下，模型响应偶尔会超时甚至直接中断，如果是传统 IDE 插件，中断往往意味着重头再来。而 OpenCode 的会话保存机制让整个对话过程都有持久化，重连后执行/resume就能恢复到断开前的进度。

6.3 私有知识库与领域指令注入

如果你的团队有内部编码规范、常用工具链说明、历史项目经验文档，可以通过配置 OpenCode 的“指令注入”机制，让模型生成代码时自动参考这些规范。具体做法是维护一个规则文档目录，然后在配置文件中引用这些文档路径，OpenCode 每次发起请求时会把文档内容作为系统提示的一部分打包发送给模型。

效果最明显的是让 OpenCode 遵守团队自己定义的 API 封装规范。我们团队有一套统一的服务调用封装，要求所有后端请求都必须走这个封装函数，禁止直接使用底层 HTTP 客户端。在注入这个规范后，OpenCode 生成的新代码基本都能走对通道，代码审查时这类问题几乎绝迹了。

需要注意的是：规则文档不要写得过长，否则每次请求的 tokens 消耗会明显增加。我建议把规则按“必须遵守”和“建议参考”分级，只把必须遵守的部分注入到系统提示里，其余内容留在文档中供模型按需检索。

7. 真实项目中的完整工作流：一次数据导出功能的前后

7.1 从需求描述到代码落地的全过程

光讲功能太抽象，我拿最近做的一个实际功能来演示 OpenCode 的完整工作流。需求是：给某内部业务系统增加一个数据导出功能，用户在前端选择日期范围，后端生成 CSV 文件并提供下载。任务量不大不小，正好能展示 OpenCode 的各个能力。

第一步，我新建了一个会话，把需求描述清楚：需要新增一个后端接口、一个前端按钮、一个导出记录表。OpenCode 读完项目现有的目录结构和代码风格后，先给了我一版整体方案，包括接口路径、文件位置、涉及的表结构。这一步帮我省去了大量翻代码找位置的功夫。

第二步，我让它生成后端接口代码。指令是“新增一个 POST /export 接口，接收 startDate 和 endDate 参数，查询对应时间段的订单数据，写入临时文件，返回下载链接，并插入一条导出记录”。OpenCode 自动找到项目里已有的数据库访问类、工具函数库，生成的代码风格与周边代码几乎一致——这一点让我挺惊讶的，因为它用了 LSP 和文件搜索能力去感知上下文，不是凭空硬编。

第三步，我让它生成前端调用代码。因为前端是另一个团队的同事维护的，我不太熟，OpenCode 通过项目里的前端文件推断出请求封装方式，生成了一段合理的调用代码，我把它转交过去的时候同事说“这风格跟我们这边挺像”。

第四步，我执行/review让 OpenCode 审查新代码。它发现了一个边界情况：当所选日期范围内没有订单数据时，生成的 CSV 文件只有表头，没有数据，而前端打开空文件会显示乱码，因为 Excel 无法识别默认编码。我用它提供的修改建议调整了文件编码并添加空数据提示，这个小问题如果真的漏到线上，大概率会收到用户反馈。

7.2 任务拆解粒度与指令质量的关系

如果这次开发我上来直接说“帮我做个数据导出功能”，OpenCode 也能跑，但结果可能完全不同。它可能用了一种项目里根本没引入过的文件上传库，或者生成一个不符合现有路由风格的新路由。问题不在于模型笨，而在于它缺少足够的信息约束。

所以我总结了一个经验公式：指令的信息密度越高，生成代码的可用度越高。一条好的 OpenCode 指令应该包含四要素：任务目标、涉及的现有文件或模块、输入与输出的结构、约束条件（比如必须使用某个已有的封装函数）。缺了哪一样，生成结果的随机性都会变大。

实际操作时，我给每条指令都预留了后续修复的余量，也就是说我不会把生成结果直接当作最终代码，而是把它当作“初稿”，然后结合 LSP 报错和代码审查意见做一轮或多轮迭代修改。有人觉得这样太麻烦，但我的体感是，OpenCode 生成代码的上限取决于模型能力，而下限取决于使用者的判断力，两者缺一不可。

8. 实测中遇到的坑与排除方法：这些细节最容易劝退新手

8.1 上下文爆炸：一个粗暴操作引发的连环问题

OpenCode 的上下文管理其实做得不错，但前提是你懂得配合。有一次我让它分析整个项目的问题，它后台把所有核心源码都读了一遍，生成了一个上万字的分析报告，那次操作直接把我的 token 额度烧掉了一半，而且后续会话明显变慢。原因就是我把“项目上下文窗口”设得太大，加上没有控制单次读取文件的数量。

后来我调整了策略：涉及大项目分析时，先让 OpenCode 按目录层级浏览项目结构，然后再有针对性地读取具体文件；每次会话只聚焦一个小范围，彻底想清楚了再进入下一个议题，决不贪多。这个改变让同样的任务量下 token 消耗减少了一半以上。

8.2 模型幻觉：生成看似合理的错误代码

模型幻觉在复杂项目里很难完全避免，表现是生成一段结构完整、逻辑自洽但实际无法编译的代码。最常见的是 API 名称写错、依赖导入路径不对、或者使用了已经废弃的配置字段。这类问题的特点在于“看起来没问题”，新手很容易直接采用，然后在编译阶段报错。

我的对策是永远启用 LSP 诊断作为第一道校验，因为 OpenCode 的 LSP 集成能自动发现绝大多数语法和类型错误；第二道校验是执行一次构建或测试；真正的业务逻辑校验没法自动化，只能靠 code review 时人工把关。说得直白一点，把生成代码当作“付费初稿”而不是“成品交付”，这个心态能帮你避免很多损失。

8.3 OpenCode 进程占用与性能问题

长时间开着 OpenCode 会话后，偶尔会遇到响应变慢的情况。排查后发现，是因为会话历史中积累了太多文件内容，每次请求都要重新处理这段长历史。我试过把maxTokens调高来缓解，但效果一般；最管用的方法是定期/new开启新会话，把旧的任务结果沉淀成代码后就果断丢弃历史上下文。

另外一个性能相关的点是 OpenCode 在大型仓库中的首次文件搜索会较慢。它需要对整个项目目录建立索引，如果项目里包含海量依赖文件，索引时间可能长达几分钟。这时候不要以为是卡死了，耐心等待或查看一下进程日志即可。如果实在受不了，可以在配置里排除某些目录，禁止 OpenCode 对其做文件搜索，比如node_modules、vendor、dist这些目录本来就没必要让 AI 去分析。

8.4 本地模型服务的并发排队问题

接入内网模型后，多人首次同时使用会让响应时间显著上升。因为单机 GPU 的推理能力是有限的，多个请求同时到达时会排队处理。我们第一次团队联调时就碰到了：三个人同时让 OpenCode 生成代码，结果每个人都在等待队列里排了近一分钟。

解决方案有两步。第一步是错峰使用，早晨和下午这类低峰期体验明显更好；第二步是引入一个轻量级的请求转发层，把 OpenCode 发来的请求按优先级排队，并把耗时的模型推理放到后台异步处理，避免前端长时间无响应。不过这属于基础设施优化，对于个人使用者来说，最简单的建议是：如果本地模型太慢，别硬扛，直接换成速度更快的云端 API，效率优先。

9. 在成本和性能之间找到你的平衡点

最后聊聊一个很多人忽略的话题：OpenCode 用得好不好，很大程度上取决于成本和性能的平衡。我见过有人用最贵的模型处理最简单的任务，每月账单吓死人；也见过有人为了省钱，用一个小模型做复杂的重构任务，反复生成、反复失败，浪费的时间远超省下的费用。

我的经验是给任务分三级：零碎补全和简单问答用便宜快速的小模型，普通模块开发用性价比适中的中等模型，复杂架构设计和跨文件重构才动用能力最强的模型。OpenCode 支持在不同会话间切换模型配置，所以我会建几个不同命名的配置文件，实际操作时根据任务难度选择不同的启动参数。

这个思路实施之后，我的月度模型支出下降了大概四成，而整体开发效率几乎没有下降。如果你也想长期稳定使用 OpenCode，我的建议是：建立一个适合自己的任务分级体系，定期检查 token 消耗，并且不要害怕更换模型。工具始终是为人服务的，你用得顺手、成本可控，比盲目追求“最强模型”有意义得多。