我第一次在终端里敲下opencode时迎头就是一行红色报错无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这行报错几乎成了每个新手入坑的第一道坎也侧面说明 opencode 的安装路径和普通桌面软件完全不同。作为一款终端优先的 AI 编程代理opencode 正在成为 Claude Code、Codex 之外最值得关注的选手它开箱即支持多模型、可写配置、可接 Skills还能通过 LSP 让 agent 真正“看懂”代码语义。这篇内容我想系统梳理一下 opencode 的完整用法从安装排错、模型接入、go 订阅这类社区黑话到 Skills、Memory、LSP、Playwright 这些让它“变聪明”的进阶能力再到 VSCode、IDEA、桌面版等编辑器集成方式。无论你是刚听说 opencode 的新人还是已经在用 Claude Code、Codex 想迁移过来的老手这篇应该能覆盖大部分实操疑问。1. opencode 到底是个什么项目AI 编程助手的下一个形态1.1 从自动补全到编程代理的演进过去两年AI 编程工具明显分成了两个时代。第一个时代是“补全时代”代表工具是 GitHub Copilot、通义灵码这类 IDE 插件它们擅长在你敲代码时给出下一行、下一个函数的建议本质是一个“超级自动补全”。它们的上限在于只能理解当前文件、当前光标附近的局部上下文你让它跨文件改一个接口影响的所有调用点它基本做不来。第二个时代就是“代理时代”代表工具包括 Claude Code、OpenAI Codex以及今天要聊的 opencode。这类工具不再满足于“补全”而是真正接管一个任务闭环读项目结构、搜索相关代码、跨文件修改、运行测试、根据失败信息自我修正直到任务完成。你可以把它理解成“一个 24 小时在线的初级工程师”你给它派活它自己干活干完汇报。opencode 就是这个阵营里非常特殊的一员。它没有绑定某个厂商的模型也没有锁定某个编辑器而是以命令行工具的形式存在让你在任意目录、任意工作流里随时喊它出来干活。1.2 终端优先、多模型、可编程的定位opencode 的核心定位可以拆成三点。第一终端优先。它的主界面是一个漂亮的 TUI终端图形界面和 Claude Code 的交互方式同源但比 Claude Code 更“标准”——有清晰的分屏、操作提示、可配置的快捷键。这也意味着它天生适合 SSH 远程服务器、Docker 容器这类没有图形界面的环境。第二多模型支持。你可以在 opencode 里同时配置 Anthropic、OpenAI、Google Gemini、本地 Ollama 模型然后在会话里随时切换。这个设计非常实用因为不同模型在不同任务上的表现差异很大架构设计我倾斜 Claude代码重构用 GPT简单脚本生成我会切到一个便宜的快速模型。第三可编程、可配置。opencode 不是靠命令行参数硬堆功能而是通过opencode.json配置文件、.opencode目录下的 Skills、Memory 等机制把你自己团队的编码规范、常用命令、项目背景都喂给 agent。这个能力让它从“通用编程助手”变成“懂你们项目规矩的编程助手”。1.3 opencode 与 Claude Code、Codex 的选型对比很多人在选型时会纠结这三个工具我直接给出一份基于实际体验的对比对比维度opencodeClaude CodeOpenAI Codex模型绑定多模型自由切换以 Claude 为主以 GPT 系列为主使用界面TUI 为主配合 IDE 插件TUI网页/Terminal配置灵活度高支持 opencode.json中主要通过 CLI 参数低选项较少扩展机制Skills、Memory、LSP、PlaywrightSkills、插件社区有限上手成本终端用户很快纯 IDE 用户稍高终端用户为主较低适合人群想保留模型选择自由的团队Claude 深度用户OpenAI 生态用户我的判断是如果你团队里已经重度使用 Claude Code且项目模型绑定不敏感继续用没问题但如果你想要一个“不锁模型、配置可控、能逐渐沉淀团队规范”的工具opencode 的长期空间更大。特别是它把配置和技能目录做成了项目内文件这意味着你换电脑、新人入职直接拉仓库就能拥有一模一样的 AI 助手环境。2. 安装与启动绕不开的 cmdlet 报错和 PATH 那点事2.1 四种安装方式挑一个顺手的opencode 的安装和其他终端工具一样首选官方脚本。以下是目前主流的安装方式# 方式一官方安装脚本推荐会自动安装到 ~/.opencode/bin curl -fsSL https://opencode.ai/install | bash # 方式二npm 全局安装 npm install -g opencode-ai # 方式三HomebrewmacOS / Linux brew install sst/tap/opencode # 方式四直接下载二进制 # 去 GitHub Releases 页面下载对应平台压缩包解压后放到 PATH 里方式一最省心脚本会自动识别你的操作系统和 CPU 架构下载对应二进制并写入 shell 配置文件。方式二适合本来就装着 Node 环境的开发者升级也更方便npm update -g opencode-ai。方式三适合 macOS 用户顺手还能获得 brew 的自动更新管理。安装完成后核心二进制会落在~/.opencode/bin/opencode具体路径以安装输出为准。我在 Linux 服务器和 macOS 上都装过这个路径是统一的后面排查 PATH 问题全靠这个规律。2.2 Windows 下“cmdlet 不识别”的根因与解决这是所有热搜里出现频率最高的问题值得单独拆开讲。报错长这样opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。这句话的翻译是PowerShell 在当前的$PATH环境变量里找不到一个叫opencode的可执行文件。注意你看到这个报错不代表安装失败绝大多数情况是安装成功但路径没进 PATH。opencode 的安装脚本会把二进制放到~\AppData\Local\opencode\bin或~\.opencode\binWindows 平台具体看脚本版本但不会像 Windows 桌面软件那样自动帮你改系统环境变量。解决步骤如下先确认二进制是否真的存在。在 PowerShell 里执行ls $HOME\.opencode\bin\opencode.exe如果提示找不到路径再去%LOCALAPPDATA%\opencode\bin下面找。找到之后再继续。把该目录追加到当前会话的 PATH先验证能不能跑$env:Path $HOME\.opencode\bin opencode --version能跑之后把它写进用户级环境变量免得每次开终端都要重设setx PATH $env:PATH;$HOME\.opencode\bin然后重开一个终端窗口。setx只影响之后启动的进程当前窗口还得手动补一次 PATH。这里有个容易踩的坑网上很多教程会让你直接改系统环境变量里那个超长的 PATH 字符串我不建议这么干。setx PATH $env:PATH;某路径会把当前会话里所有临时路径也写进去久而久之 PATH 会变得很臃肿。更干净的做法是在系统设置里搜“编辑账户的环境变量”然后在用户变量中单独新建一条OPENCODE_BIN指向二进制目录再把%OPENCODE_BIN%加到用户 PATH 的开头。这个维护起来清晰得多。2.3 首次启动选模型、填 Key、开始干活安装好之后在项目目录里直接执行opencode第一次启动会让你选择模型供应商常见选项有 Anthropic、OpenAI、Google、本地模型等。选好后填入对应的 API Key。如果你用的是 CLI 环境、不想交互式输入也可以先把环境变量配好再启动export ANTHROPIC_API_KEYsk-ant-xxx # 或者 export OPENAI_API_KEYsk-xxx进入 TUI 之后你会看到对话输入框、当前模型标识、以及可用命令提示。我用得最多的场景是让它“接手查问题”。举个例子在一个前端项目里我直接输入帮我看看当前的 git 状态解释一下最近三个提交各自改了什么东西然后指出有没有明显的代码坏味道。opencode 会先调终端命令git status、git log再读取相关文件内容最后给你一份结构化的分析。这种“自己跑命令、自己看结果”的模式和传统 AI 代码补全是完全不同的体验。2.4 日常最常用的几个 CLI 命令除了直接敲opencode进入交互模式还有几个子命令我平时经常用opencode run 任务描述非交互模式直接在命令里给任务适合脚本化调用和 CI 集成。opencode serve启动一个本地服务供 VSCode 插件、JetBrains 插件等图形界面连接。这是 IDE 集成的关键命令。opencode init在当前项目里生成一份模板opencode.json相当于初始化配置。opencode --version确认版本号排查问题时第一步先跑这个。日常开发我不推荐频繁用run因为交互模式能让你在 agent 做错方向时及时打断省下大量 token。run更适合“定时任务”“批处理”这类无人值守场景。3. 模型接入与“go 订阅”热搜背后那些事3.1 opencode 到底支持哪些模型供应商opencode 的模型接入层做得比较干净它把所有模型统一抽象成 provider model 两层。官方支持的主要供应商包括AnthropicClaude 3.5/3.7 Sonnet、Opus 等OpenAIGPT-4o、o3 等Google GeminiGemini 1.5/2.0 Pro 等Ollama本地模型比如 qwen、llama 系OpenAI 兼容接口vLLM、LM Studio、各类第三方网关在opencode.json里配置模型的方式大致是{ provider: { anthropic: { models: { sonnet: { name: claude-sonnet-4-20250514 } } }, ollama: { models: { qwen3: { name: qwen3:14b } } } } }这种设计的好处是模型名称和实际调用的model id可以解耦。比如你可以把配置里的sonnet这个“逻辑名”指向 Anthropic 的某个具体模型哪天官方升级了模型别名你只改这一处配置项目里所有已经写好的 prompt 不用动。3.2 “opencode go”到底是 Go 语言还是订阅套餐搜“opencode go”会看到两类完全不同的结果很多人在这里被绕晕。第一类是指 opencode 这门技术本身的开发语言。opencode 的核心引擎是 Go 写的所以性能非常好——启动速度、内存占用都比 Node 系的同类工具强尤其在大仓库里调用文件搜索和 git 操作时体感差异非常明显。这也是我把它长期放在主力位置的原因之一终端工具一旦启动变慢使用频率会直线下降。第二类才是热搜的“重头戏”社区里流传的“go 订阅”“go 套餐”。这个东西本质上是第三方模型 API 聚合服务把各大模型厂商的调用额度打包成订阅套餐然后提供一个统一的 OpenAI 兼容接口给你。opencode 里要接这类服务一般是在opencode.json里配置自定义 provider把baseURL指向这个服务的地址再配上它给你的 key。我不是反对用这些服务但有几个风险你必须清楚数据安全你的代码会经过第三方服务器敏感项目严格不建议这么干。账号风险有些套餐属于“共享号”容易因并发过高触发限流也可能被供应商风控封禁届时你的历史会话和代码片段都在别人手里。稳定性第三方网关一旦故障你正在跑的任务会直接中断且排查链路不透明。如果你决定要尝鲜我的建议是给这类服务单独建一个 provider 别名比如叫proxy不要和官方 provider 混在一起日常小任务用它提速没问题核心架构设计和带敏感业务代码的任务切回官方 API。3.3 CC Switch、Superpower 这些工具到底在干嘛热搜里出现了很多“配套工具”很多人不知道它们和 opencode 的关系。逐个说破CC Switch本来是一个管理 Claude Code 多套 API 配置的图形化小工具。因为 opencode 也支持类似的多 provider 配置社区里不少人直接用 CC Switch 来快速切换 opencode 的不同配置组。你可以把它理解成一个“配置路由器”在官方 API、第三方网关、本地模型之间一键切换。Superpowers这是一套增强插件/技能集给 Claude Code 装上之后它会把任务拆解成“头脑风暴 → 方案设计 → 执行计划 → 编码实现”的标准工作流。opencode 社区也有人在做类似移植。它在 opencode 里的落地形态其实就是把一组写好的 Skills 文件和系统 prompt 放进.opencode目录。oh-my-claudecode名字虽然带 Claude Code但它是社区里比较出名的 Claude/opencode 配置管理仓库类似“oh-my-zsh”之于 zsh。它会聚合社区里常用的 Skills、别名、辅助脚本让你一键装进自己的配置目录。这些工具本质上解决的是同一个问题AI 编程助手的配置和学习成本不低需要沉淀和分享。与其每次新项目重新调教 agent不如把规范、技能、常用套路做成可复用的配置文件。3.4 两个高频报错的排查思路热搜里有两条报错出现频率特别高我分别说下我的处理方式。第一条是this model is not available in your country.。很多人看到这个报错第一反应是网络问题其实绝大多数情况是当前配置的 provider 在某个具体模型上的投放范围有限或者你用的第三方聚合渠道根本没有这个模型的路由。处理办法是先在 opencode 里用/models看看当前 provider 到底暴露了哪些模型如果目标模型不可用就切换到其它 provider或者在配置里给同一个逻辑名映射两个模型做 fallback。这属于模型路由问题不需要用任何非常规手段解决。第二条是error: unexpected server error. check server logs。这个报错信息很笼统真正的问题往往在入口之前。我的排查顺序是先确认 key 还能不能用去对应平台看一眼额度是不是撞了消费上限。再确认baseURL配得对不对。很多第三方网关要求路径必须以/v1结尾少了这个就会报这类“服务器异常”。最后打开 opencode 的 debug 日志。一般是在配置文件里设logLevel: debug重新跑一次opencode run 11这种最小请求看日志里最终打出去的 HTTP 请求 URL、请求头和响应体是什么。十次里有八次问题出在 key 或 baseURL 上而不是 opencode 本身。4. 让它更像“老同事”Skills、Memory、LSP 与前端 Bug 排查4.1 Skills给 agent 灌一份“岗位手册”如果你只是把 opencode 当成一个会写代码的对话框那它发挥出来的能力不到三成。真正拉开体验差距的是它的 Skills 机制。Skills 是什么可以理解成给 agent 准备的“岗位手册”或者“工作说明书”。你把你希望它遵守的规则、常用的命令流程、项目特有的约定写成一堆 Markdown 文件放进.opencode/skills/目录。opencode 在开始执行任务时会根据任务内容动态检索并加载相关的 skill。我举一个实际例子。我们团队的后端仓库要求所有新增接口必须写单元测试并且测试文件必须和源码放同一个目录。我就在.opencode/skills/backend-workflow.md里写了# Backend Workflow ## 适用场景 当任务涉及新增或修改 REST API 时必须执行以下步骤。 ## 步骤 1. 先阅读项目根目录的 CONTRIBUTING.md确认编码规范。 2. 接口实现完成后在相同目录下创建 名称.test.ts 文件。 3. 运行 npm run test -- 目标测试文件确认通过后才能收尾。 4. 如果测试失败优先修复测试而不是跳过测试。之后每次让 opencode 改接口它都会自己把这些步骤走完。这就是“老同事”和“会用 IDE 的实习生”之间的区别——它不是每次都在等你提醒而是形成了一套肌肉记忆。Skills 的编写有个重要原则写“为什么”和“什么时候”少写“是什么”。不要长篇大论解释什么是 REST API而是告诉 agent 在什么场景下必须触发什么动作。因为模型本身已经知道 REST API 是什么它缺的是你们团队的上下文约定。4.2 Memory让 agent 跨会话记住项目背景Skil les 解决的是“这件事怎么做”Memory 解决的是“这个项目是什么”。在你和 opencode 的一次次会话中它会积累当前 session 的上下文但会话一关下次重新打开它对你项目的了解又会回到原点。Memory 机制就是为了让重要信息跨会话留存。我习惯在.opencode/memory.md里维护这样几类内容项目的架构总览这个 repo 分成几个模块模块之间怎么依赖。关键路径说明比如“用户认证逻辑在src/auth所有请求经过middleware/auth.ts”。决策记录为什么当初选了 A 方案而不是 B 方案避免 agent 下次“好心”把架构改回去。已知坑位比如“src/utils/date.ts里的时间格式化函数只支持 UTC别给它传本地时间”。有了这份 Memory新会话里直接问“我们这个项目怎么加一个新接口”opencode 可以给出完全贴合项目结构的回答而不是泛泛而谈的教科书方案。我建议把.opencode目录提交到 Git 仓库里这样全组共享同一份“项目认知”新人接手时看一遍 memory 文件和 skills就能快速理解这个 AI 助手为什么会被配置成现在这个样子。4.3 LSP 集成让 agent 从“看文本”升级到“看代码”纯靠读文件内容agent 很容易被字符串匹配误导。比如你要它重构一个函数它可能在全局搜索所有同名函数名时分不清哪个是定义、哪个是调用。LSPLanguage Server Protocol机制就是解决这个问题的。opencode 支持通过 LSP 与语言服务器对接从而获得真实的代码语义跳转定义、查找引用、符号重命名、获取诊断信息。简单来说原来它是拿着一个纯文本文件“读代码”接了 LSP 之后它是通过 IDE 同款的语言服务“分析代码”。以 TypeScript 项目为例配置文件里加一块{ lsp: { typescript: { command: [typescript-language-server, --stdio] } } }之后让 opencode 做“查找这个接口的所有引用并逐个评估改动影响”这类任务时它的准确率会明显提升因为它看到的不是“哪个文件里出现过这个词”而是“这个符号在代码语义上被谁依赖”。这个配置比较容易被忽略但当我第一次看到 opencode 自己调用 LSP 去定位一个跨文件符号的所有引用时我就明白这类 agent 工具和早期“暴力搜索贴代码”的 AI 助理已经不是一代产品了。4.4 用 Playwright 复现并定位前端 Bug 的真实流程opencode 另一个让我觉得“值回票价”的能力是它可以动态操作浏览器来复现前端问题。热搜里出现“opencode playwright 怎么测试前端 bug”说明大家已经猜到这条路是可行的。我实际遇到过一个场景产品反馈“搜索框输入关键词后按回车没有反应但点击搜索按钮可以搜”。这种问题你让 agent 纯看代码它只能猜未必能定位到事件绑定差异。我的处理方式是让 opencode 这样跑先在项目里启动开发服务器确认端口。用 opencode 内置的 Playwright 工具打开页面。定位到搜索框元素用键盘输入关键词然后模拟按下回车。操作完之后把页面截图、console 报错、network 请求列表一起拉回来。根据截图和报错信息再去看对应的 React/Vue 组件代码。我的实际体验是这样的闭环能力远比“直接让 AI 猜 bug”靠谱得多。它相当于给了 agent 一双眼睛和一只手眼睛看页面渲染结果手去操作真实交互。排查结果出来之后它不仅能告诉你问题在哪个文件哪一行还能顺手把修复方案写出来、跑一遍测试验证。对前端团队来说这个能力可以大幅降低“环境复现”的成本。以前你需要在 issue 里写一堆复现步骤现在直接让 opencode 按你描述的步骤跑一遍浏览器附上截图和报错整个 Bug 信息就立体了。5. 编辑器集成与多端使用VSCode、IDEA、Desktop5.1 VSCode 插件终端与编辑器之间的桥梁虽然 opencode 主战场在终端但长时间在终端和编辑器之间来回切换体验还是会撕裂。VSCode 插件解决的正是这个问题。安装方式很简单在 VSCode 扩展市场搜索 opencode安装后左侧边栏会出现一个 opencode 面板。前提是你在本机已经装好并配置好了 opencode CLI——插件本质上是调用了opencode serve启动的本地服务。插件面板里你仍然可以像终端里一样对话但额外获得两个很实用的能力选区上下文你可以在编辑器里选中一段代码右键选择“发送给 opencode”它会自动带上选区内容作为上下文。文件跳转当 opencode 在回复中指出某个文件某一行时你可以直接在编辑器里点过去看不用自己在项目里翻。我的使用习惯是简单的写代码、改 bug 就在编辑器里顺手用插件涉及多文件重构、需要看 git 历史和跑测试的任务切回终端 TUI 更高效。两者的会话数据是可以共享的因为背后是同一个 CLI 服务。5.2 JetBrains IDEA 插件Java/Kotlin 项目的选择如果你主力 IDE 是 IntelliJ IDEA也有对应的开放方案。opencode 官方推出了 JetBrains 插件安装位置在 Settings → Plugins → Marketplace 搜索 opencode。JetBrains 插件和 VSCode 插件思路相近但有一个对 JVM 系项目特别友好的点它能利用 IDEA 自身的索引信息把项目符号、类的继承体系、Maven/Gradle 依赖关系这些上下文直接传给 agent。这比纯 LSP 拿到的信息还要完整。还有一个细节值得注意IDEA 插件默认信任的项目范围可以单独配置。如果你同时开着多个仓库可以在插件设置里限定 opencode 能访问的目录防止 agent 在排查问题时“跑偏”到别的项目里读文件。5.3 Desktop 桌面版给不习惯终端的人一个入口opencode 还提供了桌面客户端本质上是一个 GUI 外壳内嵌了 opencode 的完整能力。Desktop 版的好处是不用记命令、不用理解 PATH 概念打开就能选模型、开对话、看文件 diff。但我要提醒一句桌面版目前不适合作为重型工作流的主入口。原因是它在项目目录切换、终端命令执行、场景化配置上的灵活性依然不如命令行完整。它更像是一个“展示型入口”让团队里不熟悉终端的人先感受一下 opencode 能干什么真正重度使用还是建议回到 CLI。5.4 接手开发项目openocde 的正确打开方式热搜里有一个特别扎眼的关键词——“opencode 接手开发项目”。这其实是很多新人或跨团队接手存量代码库时的刚需。我刚接手一个六个月没人维护的前端项目时第一件事就是进到项目目录里跑opencode然后输入这样一个 prompt这是一个我从未看过的项目。请帮我做以下事情 1. 阅读 README 和 package.json告诉我这是什么类型的项目、技术栈是什么。 2. 梳理出主要目录结构说明每个目录的职责。 3. 找出项目里配置了哪些脚本命令dev/build/test以及有没有 CI 配置。 4. 搜索 TODO/FIXME/HACK 注释汇总这些遗留问题主要集中在哪里。 5. 最后给出你建议的探索路线如果我想快速定位用户登录流程应该从哪些文件开始看。opencode 会花一两分钟顺着这个路径把项目“踩”一遍然后给你一份类似“新人入职引导文档”的总结。这个过程中它可能会跑几个只读命令、读一堆配置文件全程不需要你手动打开几十个文件。我的体感是它不能替代你真正读懂代码但它能把“从零开始摸清一个项目”的时间压缩到一杯咖啡的量级。剩下的时间你可以带着它的总结去重点看关键模块而不是像无头苍蝇一样在仓库里乱转。6. 配置实战我的 opencode 标准指南与避坑清单6.1 opencode.json 核心字段与一份参考配置聊了这么多最终都要落到配置上。opencode 的项目配置文件是根目录下的opencode.json也支持.opencode目录。我给出一个适合中小型前端/全栈项目的最小可用配置{ $schema: https://opencode.ai/config.json, provider: { anthropic: { models: { sonnet: { name: claude-sonnet-4-20250514 }, opus: { name: claude-opus-4-20250514 } } }, openai: { models: { gpt4o: { name: gpt-4o } } }, local: { models: { qwen: { name: qwen3:14b, baseURL: http://localhost:11434/v1 } } } }, model: sonnet, theme: dark, logLevel: info, skills: { enabled: true, directory: .opencode/skills }, lsp: { typescript: { command: [typescript-language-server, --stdio] } } }说明几个字段model是默认模型对应上面 provider 里定义的逻辑名我默认用 sonnet复杂任务时用/model手动切到 opus。logLevel平时设info够用排查问题改成debug。skills.directory指定技能目录建议固定在项目.opencode/skills随仓库走。lsp按需配置不一定每个项目都要配如果不开opencode 也能工作只是对代码语义的理解弱一些。要提醒的是opencode 版本迭代很快字段可能在不同版本间有调整最好的方式是先用opencode init生成一份模板再基于模板改。6.2 配置即代码把.opencode纳入版本管理如果你团队里有多个人共同使用 opencode我强烈建议把.opencode目录纳入 Git 仓库。具体做法是在项目根目录创建.opencode/skills/、.opencode/memory.md。把团队规范、命令流程、项目背景写进这些文件。把.opencode提交到仓库并要求后续成员拉代码后直接使用。这样做的直接效果是任何新成员 clone 完代码获得的不只是代码还包括团队沉淀下来的 AI 协作规范。这和 oh-my-claudecode 这类工具的思路完全一致——配置不应该是每个人电脑里私有的东西而是项目资产的一部分。当然如果配置文件里有个人 API key记得用环境变量或者独立的auth.json来存放不要把这个文件提交进仓库。6.3 常见错误与解决办法速查报错/问题主要原因处理方式cmdlet 不识别 opencode安装目录不在 PATH手动把~/.opencode/bin加入用户 PATH重开终端this model is not available in your country模型路由/供应商区域限制切 provider 或模型别名配置 fallback 模型unexpected server errorkey 过期、baseURL 拼接错误、配额耗尽查看 debug 日志确认 key 和 baseURL启动很慢LSP 语言服务器初始化、大仓库索引按需配置 LSP避免一次性加载过多索引会话上下文混乱项目 memory 未维护及时更新.opencode/memory.mdIDE 插件连不上本地 serve 服务没启动/端口占用检查opencode serve状态重启插件这张表是我半年多使用下来遇到概率最高的几类问题。大部分都不是 opencode 本身的 bug而是环境配置和上下文管理不当造成的。6.4 我的使用习惯与性能调优建议最后分享几个我自己的实操经验不一定适合所有人但可以当个参考。第一模型要分流。小任务、一次性脚本生成用快速便宜的小模型重大重构、架构设计、安全相关代码审查切到最强模型。不要所有任务都让顶级模型跑既慢又贵反而会因为“太聪明”在小任务上过度设计。第二控制一次任务的粒度。opencode 虽然能一口气完成“查问题 → 改代码 → 跑测试 → 提交”但任务跨度越大中途走偏的概率越高。我通常会让它先出计划我确认方向后再让它动手。这能省下大量返工 token。第三定期清理会话历史。opencode 的会话历史都留在本地用久了会占用磁盘空间而且历史列表越长越难找到有用的旧会话。我一般一两周会清理一次只保留真正有参考价值的会话。第四敏感项目切本地模型。我处理过一些未公开的业务代码不会把它们发到任何云端 API。opencode 对 Ollama 的支持让这件事变得很现实同一个配置里日常任务用云端模型涉及敏感文件时直接切到本地模型而 Skills、Memory 这些能力不受影响。这也是我最终选定 opencode 作为主力的原因之一——它把模型选择权完全留给了使用者。敲了大半年 opencode我最大的体会是这类工具的价值并不在于“能写多少代码”而在于它能不能逐渐理解你和你团队的工作方式。Skills、Memory、LSP、Playwright 这一整套东西本质上都是在把“项目语境”交给 agent。你投入在.opencode目录里的每一份文档都会在未来一次又一次的会话里持续产生回报。如果你现在还在把它当普通聊天框用我建议从写一份memory.md开始那种“换了个懂行搭档”的感受试过就知道了。
