过去几个月里我终端里一直同时躺着三个AI编程AgentClaude Code、Codex以及今天重点聊的opencode。很多人问为什么不用IDE里的AI插件我的回答是真正高频的AI辅助开发尤其是那些要跨多个文件改代码、需要不断看编译反馈和测试结果的任务终端里的TUI反而比IDE对话框更顺手。opencode就是这类工具里风格很特别的一个它开箱即用、配置灵活而且不绑死某一家模型所以最近在开发者圈子里讨论度一直很高。这篇东西不是官方文档的中文翻译而是我实际用了几个月之后的经验总结。我会从安装、模型接入、日常操作、Skills、LSP、Playwright测试这些维度把能直接落地的用法和踩过的坑都写清楚。不管你是已经用惯了Claude Code想换个手感的老手还是刚接触终端AI编程、想低成本入门的新人应该都能从这里找到有用的东西。1. opencode到底是个什么工具定位、特性与适用人群1.1 它到底解决了什么问题opencode是一个跑在终端里的AI编程代理用TUI文本用户界面操作核心卖点是把“对话式AI写代码”这件事做成一个命令行下完整的工作流。你可以在里面问问题、让它读项目代码、创建和修改文件、执行shell命令、跑测试甚至让它操作浏览器验证前端效果。这些能力和Claude Code、Codex其实是同一类但opencode有几个很实在的差异。第一模型无关。它不像某些工具被绑定在特定模型上而是可以通过配置对接OpenAI、Anthropic、Google Gemini、DeepSeek、本地模型等多种来源。这意味着你不需要因为换了一个模型就整套工具搬家。第二权限控制做得细。它对文件读写、命令执行、Agent模式切换等操作都有独立的授权策略跑自动化任务的时候可以放开权限平时手动操作时可以保持每次询问安全上更稳。第三TUI交互设计值得称赞。左侧是对话和文件列表右侧是diff预览改动一眼就能看清。这种布局让“AI改完代码—我审查diff—按快捷键接受或拒绝”成为一个非常顺滑的循环。1.2 和Claude Code、Codex放在一起比我用这三个工具处理同一类任务快两个月简单总结一下差异。对比维度opencodeClaude CodeCodex界面形态TUI交互带diff预览终端对话为主交互偏极简终端对话为主模型绑定多模型可配主力为Claude系列偏OpenAI系列权限控制细粒度授权有授权体系有授权体系开源情况开源社区活跃不开源不开源前端验证内建Playwright工具需额外配置较弱上手成本中等低低Claude Code的优势是生态成熟、有大量现成Skills和配置方案可以参考opencode的社区虽然起步稍晚但迭代很快而且因为开源很多玩法可以自己改源码。Codex在OpenAI自家模型上表现强但灵活性不如opencode。我个人现在的分工是重大项目用opencode主导因为它能把模型源、权限、自动化脚本串成一个整体Claude Code保留给需要大量Claude模型特性的场景Codex则在试新模型能力时偶尔用。1.3 适合谁用不适合谁用如果你日常工作流里有大量跨文件修改、频繁需要AI执行命令和查看结果同时你又习惯键盘操作那opencode会非常对味。它也适合喜欢折腾配置的开发者因为opencode.json里能调的东西不少。反过来如果你只是想在编辑器里有个人帮你补全代码、写写单元测试那VS Code的插件和JetBrains插件反而更轻量没必要专门学一套终端工具。另外如果你完全不想接触命令行和配置文件那opencode暂时也不适合你它本质上还是给终端用户准备的。2. 安装与环境准备那些报错基本都是PATH问题2.1 npm安装与版本检查opencode的官方安装方式是用npm全局安装。在macOS或Linux终端以及Windows的PowerShell里都可以这么装npm install -g opencode-ai装完确认版本opencode --version如果npm在你机器上已经配置好了这一步通常很顺利。装好之后直接在项目目录下运行opencode就会进入TUI界面。首次启动会引导你配置模型提供商选一个你手头有API Key的模型源就能开聊。这里有两个小提示。如果安装过程中因为网络问题卡得很久可以检查一下npm的registry源是不是接近满速的镜像。另外装不上通常不是包本身的问题而是Node.js版本太旧opencode对Node的版本有要求遇到安装失败先去升级Node。2.2 cmdlet报错的根因与修复Windows上非常常见的一个报错是这个样子的opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。很多人看到这行就以为是安装失败了实际不是。这条报错的意思是opencode已经装到了某个目录但那个目录不在PowerShell的环境变量PATH里所以shell找不到这个命令。根因是npm的全局bin目录没有被加入到PATH。你可以先查一下npm全局安装路径npm prefix -g比如输出是C:\Users\你的用户名\AppData\Roaming\npm那就在PowerShell里把这个目录临时加入PATH$env:Path ;C:\Users\你的用户名\AppData\Roaming\npm这样在当前的PowerShell窗口里就能用了。永久生效的话要在系统环境变量里把那个目录加到Path里或者用setx命令setx PATH $env:PATH;C:\Users\你的用户名\AppData\Roaming\npm注意改了环境变量之后要新开一个终端窗口才会生效。如果你用Windows Terminal记得完全关闭再重新打开。2.3 日常升级与回滚opencode迭代很快基本两三天就发一版。我建议保持更新因为很多bug修得很及时。升级命令就是重新执行全局安装npm install -g opencode-ailatest如果某个版本用着不对劲想回退比如想回到1.8.0npm install -g opencode-ai1.8.0这里有个经验opencode的配置文件和版本兼容性整体做得不错但个别情况下新版本调整了权限默认行为升级前最好看一眼Changelog。我自己就被一个版本更改了命令执行授权默认值升级后跑自动化任务多了一串确认排查了一会儿才反应过来是版本行为变了。3. 模型接入与opencode go订阅选型与配置的取舍3.1 模型配置的两种入口交互式与JSONopencode支持在启动后通过/models命令切换模型也可以在配置文件里预设多个模型源后面随时切换。明显的优点是你不用被某一家的模型生态绑死。在项目根目录下有一个opencode.json如果没有首次配置会自动生成模型相关配置大致长这样{ $schema: https://opencode.ai/config.json, provider: { openai: { apiKey: sk-xxxx }, anthropic: { apiKey: sk-ant-xxxx } }, model: anthropic/claude-sonnet-4 }provider字段配置的是模型服务商model字段指定默认使用哪个模型。具体键名可能随版本更新略有变动但整体思路是先配服务商的API访问凭据再指定用哪一款模型。3.2 opencode go订阅值不值得上很多人在搜索里问“opencode go订阅模型选择”和“opencode go套餐”这里统一说下我的理解。opencode go指的是它提供的聚合订阅式模型访问入口通过一个订阅去使用多个主流模型省去分别注册、分别充值、分别管理多个API Key的麻烦。如果你重度使用AI编程并且一天内会在Claude、GPT和其他模型之间来回切换这种聚合订阅的价值很大。它的模型选择逻辑也很简单在TUI里打开模型列表当前套餐里可用和不可用的模型会区分展示不可用的模型会标明原因。我自己是从“所有模型都单独开API”切换成订阅制的最大的感受是账单清晰了不用再同时盯好几个后台看消耗。它的免费档额度对轻度用户也够用可以作为入门体验。如果是尝鲜先用免费档跑通流程再去订付费套餐。选择具体模型时不要只看跑分要看它在你日常任务里的实际表现代码生成质量、指令遵循度、上下文长度、是否频繁卡壳。同一个模型在A项目里表现得很好在B项目里可能因为上下文结构不同而表现波动这很正常。3.3 免费模型与区域限制的真实情况很多人关心免费模型。opencode里是能挂一些免费模型的但免费模型有几个共同问题请求速率受限、可能有每日次数上限、高峰期排队严重。还有一个非常典型的报错会出现在部分模型源上this model is not available in your country.这句报错的意思是模型服务商在API层面就做了区域限制你当前账号的所属区域不在可用名单里。这是模型厂商基于区域合规要求做的限制表现就是无论重试多少次都一样。遇到这种情况正确且稳妥的路径是在模型列表里重新选择换成当前账号区域可用的模型或者检查你接入的API网关账号区域是否和模型开放区域一致使用官方支持的入口。不要试图去改什么环境变量或者绕区域限制那种路子既不稳定也不合规而且上游服务商会随时收紧策略。另外有些免费模型例如hy3-free用着用着突然提示失效了大概率是上游把免费策略调整了或直接下线了换一个同类免费模型就行。我的配置建议是主力模型挂一个你真正信任、区域也稳定的付费模型免费模型只用来做简单问答或者跑不太紧急的批量任务避免被限流打断工作流。3.4 用ccswitch这类工具管理多套密钥当你同时使用opencode、Claude Code、Codex或者其他AI工具时每个工具都要配置API Key时间一长就容易乱。ccswitch这类配置同步/切换工具解决的就是这个痛点把多套模型配置集中管理切换时把对应配置写到目标工具里。我在opencode里使用ccswitch的经验是先为每个模型源整理好一套key、baseUrl、模型名然后在ccswitch里建好配置组需要切到哪个模型源就一键应用。这样opencode.json不用每次手动改尤其是要临时切换供应商时特别省事。注意任何“切换配置”这类操作本身没有问题但前提是每个来源都是你合法获得的、官方允许的访问凭据。不合规的渠道不仅随时可能失效还会让API Key面临安全风险。4. TUI里的日常从提问到跨文件改代码的完整链路4.1 TUI基本操作与模式切换opencode进入项目后你会看到几个区域对话区、文件列表区、diff预览区。常用快捷键先记住这几个CtrlX在agent、build、plan三种模式之间切换CtrlE打开内置编辑器/打开命令面板里面有模型切换、Skills管理、权限设置等入口CtrlC中断当前AI执行plan模式会让AI先给你完整方案不在你确认前改任何文件所以我接到新需求时都会先切到plan模式问一轮。等方案确认了再切回build模式让它实际动手或者切到agent模式让它自主跑完整个流程。4.2 一次跨文件改动的工作流记录我拿一次真实的改动来说给项目加一个新的登录接口涉及后端路由、参数校验、前端页面和服务层处理。我在对话里描述需求后opencode会先扫描项目结构定位相关文件然后给出它的实施计划。我确认后切换到build模式让它逐个文件改动。每个文件改完右侧diff区都会显示这段改动前后对比我通过快捷键接受或拒绝。最后它自动执行测试命令把通过或失败的消息贴回对话。整个过程里最有价值的其实不是它写代码而是它把“改文件—查diff—跑测试—修复”这个循环拉得很短。我每天大量时间是消耗在“改完代码等编译结果”上的opencode配合权限放开后几乎能做到改完自动跑测试省下的时间非常可观。4.3 权限控制与自动执行策略opencode的权限模型建议认真设置。配置文件里可以对文件读写、命令执行分别设置allow/deny/ask规则。我的建议是分环境个人项目或者新项目可以放开文件读写权限让它放手改改完你看diff公司项目或者重要仓库保持ask模式改之前确认执行危险命令前确认运行自动化流水线时可以用只读权限扫描和输出方案避免误操作有一个我踩过的坑一开始我把命令执行权限全部设成allow有一次AI在跑测试时顺手执行了一个清理命令虽然没出事但吓出一身汗。现在非必要时段我都保持ask只有在明确要跑自动化批量任务时才临时放开。5. 让agent更懂代码skills、LSP与Playwright的实际用法5.1 skills给agent定义可复用技能包Skills是opencode里一个很有价值的机制。它允许你用Markdown文件定义一项技能包括适用的任务说明、步骤要求和注意事项。当AI遇到匹配任务时会主动加载对应的技能说明从而按你预设的规范执行。我举个例子。我的项目里有自己的代码规范比如新增接口必须同时更新OpenAPI文档错误码必须统一。以前每次都要在对话里重复说明现在我把规范写成一个skill文件放在项目的skills目录下--- name: api-rule description: 当需要新增或修改API时使用 --- 新增或修改API时必须同步做三件事更新接口文档、补充错误码定义、添加对应测试用例。缺少其中任何一项都视为任务尚未完成。效果很明显AI在改接口相关代码时会自动把这个技能加载进来改完之后顺带把文档和测试也补上。这极大的解决了每次都从零解释的问题。5.2 LSP接入让agent看得见编译诊断很多AI编程工具的痛点在于AI改完代码后自己不知道代码编不编得过。opencode可以通过LSPLanguage Server Protocol接入语言服务让AI感知到编辑器的诊断信息。这意味着AI在修改代码后能通过LSP拿到编译错误、类型错误、lint警告并主动修复。配置LSP需要对不同语言安装对应的language server比如说TypeScript项目要装typescript-language-server。没用LSP之前AI改完代码往往要靠我手动跑一遍编译才知道挂没挂。接入之后它改完就能根据诊断信息自我修正。每次编译反馈都像是一个“哨兵”帮助AI尽早发现错误而不是一口气改完五六个文件才发现方向错了。5.3 Playwright前端验证肉眼确认真改好了opencode支持调用Playwright后它的能力一下就扩到前端测试了。AI不仅能改代码还能打开浏览器实际操作页面确认改动是不是真的有效。典型场景是排查前端bug。你可以直接在对话里让它“复现这个bug”它启动Playwright后打开页面按你描述的操作执行同时观察页面的控制台报错、网络请求和布局变化。整个过程里所有信息都会回传它会基于真实浏览器状态给出判断。我在一个Dashboard项目里用它排查过点击按钮无反应的问题AI通过Playwright打开浏览器执行点击然后从控制台捕获到一个JavaScript报错并定位到具体组件前后花了不到十分钟。这种活以前我至少要开DevTools手动复现一遍再逐个断点排查效率差太多了。需要说明的是Playwright模式下页面交互的耗时会比纯代码扫描长适合用在需要“眼见为实”的验证场景。日常简单改动不必每次都启动浏览器按需求来就行。6. 我用opencode踩过的坑配置、兼容与多Agent并存的心得6.1 配置JSON里的常见误区和修改技巧opencode.json是个很灵活的配置文件但过分灵活也意味着容易配错。我遇到过的坑排序如下模型名写错。同一个服务商下模型名必须用官方API文档里的完整模型标识缩写或口语化写法都会导致启动时找不到模型。provider认证字段不匹配。不同服务商要求的key字段名不同最稳妥的办法是先从官方文档复制示例再替换key值。改了配置没有重启。opencode的配置在启动时读取大部分内容运行时想完全热加载并不总是稳定所以改完配置后重开一下TUI最稳。我建议给opencode.json写个简单注释习惯把每个服务商的用途标注清楚。虽然它是JSON不直接支持注释但很多编辑器插件支持JSONC格式可以当注释用。6.2 接手老项目时怎么让它快速进入状态接手一个没见过的项目最怕AI一顿乱改。我的做法是先切到plan模式让opencode读一遍项目README、目录结构和关键模块入口然后输出一份项目理解报告。这份报告包括项目技术栈、运行方式、关键目录职责、可能的坑点。我会先审核这份报告看它有没有理解偏差。如果项目里有明显的历史包袱比如老代码里有很多废弃接口或者兼容逻辑我会直接在对话里说明或者加到skill里让AI在改动时尽量绕开。这些上下文对AI非常有帮助它不会自动知道你的历史债务在哪里但一旦你告诉它它就会非常稳定地避开雷区。6.3 opencode、codex、claude code、pi怎么共存怎么选现在市面上终端AI Agent不少它们各有各的脾气。我给一个比较简单的选型依据你的核心诉求推荐选择理由需要最大程度的模型自由opencodeprovider可配置不绑特定模型重度使用Claude模型Claude Code对Claude模型支持最完整主要在OpenAI生态里玩耍Codex和OpenAI模型契合度最高追求极致轻量、单任务快速问答pi更轻适合快速交互我的实际做法是让它们共存使用opencode作为主工作台Claude Code处理特定Claude任务pi用来做临时问答。不用非此即彼工具是服务工作的。有一个减少混乱的小技巧不同工具可以用不同配置文件指定不同的默认模型避免互相干扰。比如opencode默认用Claude SonnetCodex用专用模型Claude Code保留默认这样在同一个项目里切换工具时行为差异是可控的、可预期的。回看这几个月的使用opencode最大的吸引力不是某一次惊艳的代码生成而是它把AI编程变成了一套可定制、可控制、可验证的工作流。它的Skills、LSP、Playwright这些能力单独拿出来都不算独一份但组合在一起就形成了一个非常顺手的日常驾驶舱。配置上踩过的坑换个角度想也是它灵活性的体现——如果说我有什么建议那就是刚开始用的时候别贪多先把权限模型和模型选择吃透再往里加Skills和自动化验证等这套跑顺了再回看终端里那些曾经手动完成的事你会觉得过去浪费了不少时间。
过去几个月里我终端里一直同时躺着三个AI编程AgentClaude Code、Codex以及今天重点聊的opencode。很多人问为什么不用IDE里的AI插件我的回答是真正高频的AI辅助开发尤其是那些要跨多个文件改代码、需要不断看编译反馈和测试结果的任务终端里的TUI反而比IDE对话框更顺手。opencode就是这类工具里风格很特别的一个它开箱即用、配置灵活而且不绑死某一家模型所以最近在开发者圈子里讨论度一直很高。这篇东西不是官方文档的中文翻译而是我实际用了几个月之后的经验总结。我会从安装、模型接入、日常操作、Skills、LSP、Playwright测试这些维度把能直接落地的用法和踩过的坑都写清楚。不管你是已经用惯了Claude Code想换个手感的老手还是刚接触终端AI编程、想低成本入门的新人应该都能从这里找到有用的东西。1. opencode到底是个什么工具定位、特性与适用人群1.1 它到底解决了什么问题opencode是一个跑在终端里的AI编程代理用TUI文本用户界面操作核心卖点是把“对话式AI写代码”这件事做成一个命令行下完整的工作流。你可以在里面问问题、让它读项目代码、创建和修改文件、执行shell命令、跑测试甚至让它操作浏览器验证前端效果。这些能力和Claude Code、Codex其实是同一类但opencode有几个很实在的差异。第一模型无关。它不像某些工具被绑定在特定模型上而是可以通过配置对接OpenAI、Anthropic、Google Gemini、DeepSeek、本地模型等多种来源。这意味着你不需要因为换了一个模型就整套工具搬家。第二权限控制做得细。它对文件读写、命令执行、Agent模式切换等操作都有独立的授权策略跑自动化任务的时候可以放开权限平时手动操作时可以保持每次询问安全上更稳。第三TUI交互设计值得称赞。左侧是对话和文件列表右侧是diff预览改动一眼就能看清。这种布局让“AI改完代码—我审查diff—按快捷键接受或拒绝”成为一个非常顺滑的循环。1.2 和Claude Code、Codex放在一起比我用这三个工具处理同一类任务快两个月简单总结一下差异。对比维度opencodeClaude CodeCodex界面形态TUI交互带diff预览终端对话为主交互偏极简终端对话为主模型绑定多模型可配主力为Claude系列偏OpenAI系列权限控制细粒度授权有授权体系有授权体系开源情况开源社区活跃不开源不开源前端验证内建Playwright工具需额外配置较弱上手成本中等低低Claude Code的优势是生态成熟、有大量现成Skills和配置方案可以参考opencode的社区虽然起步稍晚但迭代很快而且因为开源很多玩法可以自己改源码。Codex在OpenAI自家模型上表现强但灵活性不如opencode。我个人现在的分工是重大项目用opencode主导因为它能把模型源、权限、自动化脚本串成一个整体Claude Code保留给需要大量Claude模型特性的场景Codex则在试新模型能力时偶尔用。1.3 适合谁用不适合谁用如果你日常工作流里有大量跨文件修改、频繁需要AI执行命令和查看结果同时你又习惯键盘操作那opencode会非常对味。它也适合喜欢折腾配置的开发者因为opencode.json里能调的东西不少。反过来如果你只是想在编辑器里有个人帮你补全代码、写写单元测试那VS Code的插件和JetBrains插件反而更轻量没必要专门学一套终端工具。另外如果你完全不想接触命令行和配置文件那opencode暂时也不适合你它本质上还是给终端用户准备的。2. 安装与环境准备那些报错基本都是PATH问题2.1 npm安装与版本检查opencode的官方安装方式是用npm全局安装。在macOS或Linux终端以及Windows的PowerShell里都可以这么装npm install -g opencode-ai装完确认版本opencode --version如果npm在你机器上已经配置好了这一步通常很顺利。装好之后直接在项目目录下运行opencode就会进入TUI界面。首次启动会引导你配置模型提供商选一个你手头有API Key的模型源就能开聊。这里有两个小提示。如果安装过程中因为网络问题卡得很久可以检查一下npm的registry源是不是接近满速的镜像。另外装不上通常不是包本身的问题而是Node.js版本太旧opencode对Node的版本有要求遇到安装失败先去升级Node。2.2 cmdlet报错的根因与修复Windows上非常常见的一个报错是这个样子的opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。很多人看到这行就以为是安装失败了实际不是。这条报错的意思是opencode已经装到了某个目录但那个目录不在PowerShell的环境变量PATH里所以shell找不到这个命令。根因是npm的全局bin目录没有被加入到PATH。你可以先查一下npm全局安装路径npm prefix -g比如输出是C:\Users\你的用户名\AppData\Roaming\npm那就在PowerShell里把这个目录临时加入PATH$env:Path ;C:\Users\你的用户名\AppData\Roaming\npm这样在当前的PowerShell窗口里就能用了。永久生效的话要在系统环境变量里把那个目录加到Path里或者用setx命令setx PATH $env:PATH;C:\Users\你的用户名\AppData\Roaming\npm注意改了环境变量之后要新开一个终端窗口才会生效。如果你用Windows Terminal记得完全关闭再重新打开。2.3 日常升级与回滚opencode迭代很快基本两三天就发一版。我建议保持更新因为很多bug修得很及时。升级命令就是重新执行全局安装npm install -g opencode-ailatest如果某个版本用着不对劲想回退比如想回到1.8.0npm install -g opencode-ai1.8.0这里有个经验opencode的配置文件和版本兼容性整体做得不错但个别情况下新版本调整了权限默认行为升级前最好看一眼Changelog。我自己就被一个版本更改了命令执行授权默认值升级后跑自动化任务多了一串确认排查了一会儿才反应过来是版本行为变了。3. 模型接入与opencode go订阅选型与配置的取舍3.1 模型配置的两种入口交互式与JSONopencode支持在启动后通过/models命令切换模型也可以在配置文件里预设多个模型源后面随时切换。明显的优点是你不用被某一家的模型生态绑死。在项目根目录下有一个opencode.json如果没有首次配置会自动生成模型相关配置大致长这样{ $schema: https://opencode.ai/config.json, provider: { openai: { apiKey: sk-xxxx }, anthropic: { apiKey: sk-ant-xxxx } }, model: anthropic/claude-sonnet-4 }provider字段配置的是模型服务商model字段指定默认使用哪个模型。具体键名可能随版本更新略有变动但整体思路是先配服务商的API访问凭据再指定用哪一款模型。3.2 opencode go订阅值不值得上很多人在搜索里问“opencode go订阅模型选择”和“opencode go套餐”这里统一说下我的理解。opencode go指的是它提供的聚合订阅式模型访问入口通过一个订阅去使用多个主流模型省去分别注册、分别充值、分别管理多个API Key的麻烦。如果你重度使用AI编程并且一天内会在Claude、GPT和其他模型之间来回切换这种聚合订阅的价值很大。它的模型选择逻辑也很简单在TUI里打开模型列表当前套餐里可用和不可用的模型会区分展示不可用的模型会标明原因。我自己是从“所有模型都单独开API”切换成订阅制的最大的感受是账单清晰了不用再同时盯好几个后台看消耗。它的免费档额度对轻度用户也够用可以作为入门体验。如果是尝鲜先用免费档跑通流程再去订付费套餐。选择具体模型时不要只看跑分要看它在你日常任务里的实际表现代码生成质量、指令遵循度、上下文长度、是否频繁卡壳。同一个模型在A项目里表现得很好在B项目里可能因为上下文结构不同而表现波动这很正常。3.3 免费模型与区域限制的真实情况很多人关心免费模型。opencode里是能挂一些免费模型的但免费模型有几个共同问题请求速率受限、可能有每日次数上限、高峰期排队严重。还有一个非常典型的报错会出现在部分模型源上this model is not available in your country.这句报错的意思是模型服务商在API层面就做了区域限制你当前账号的所属区域不在可用名单里。这是模型厂商基于区域合规要求做的限制表现就是无论重试多少次都一样。遇到这种情况正确且稳妥的路径是在模型列表里重新选择换成当前账号区域可用的模型或者检查你接入的API网关账号区域是否和模型开放区域一致使用官方支持的入口。不要试图去改什么环境变量或者绕区域限制那种路子既不稳定也不合规而且上游服务商会随时收紧策略。另外有些免费模型例如hy3-free用着用着突然提示失效了大概率是上游把免费策略调整了或直接下线了换一个同类免费模型就行。我的配置建议是主力模型挂一个你真正信任、区域也稳定的付费模型免费模型只用来做简单问答或者跑不太紧急的批量任务避免被限流打断工作流。3.4 用ccswitch这类工具管理多套密钥当你同时使用opencode、Claude Code、Codex或者其他AI工具时每个工具都要配置API Key时间一长就容易乱。ccswitch这类配置同步/切换工具解决的就是这个痛点把多套模型配置集中管理切换时把对应配置写到目标工具里。我在opencode里使用ccswitch的经验是先为每个模型源整理好一套key、baseUrl、模型名然后在ccswitch里建好配置组需要切到哪个模型源就一键应用。这样opencode.json不用每次手动改尤其是要临时切换供应商时特别省事。注意任何“切换配置”这类操作本身没有问题但前提是每个来源都是你合法获得的、官方允许的访问凭据。不合规的渠道不仅随时可能失效还会让API Key面临安全风险。4. TUI里的日常从提问到跨文件改代码的完整链路4.1 TUI基本操作与模式切换opencode进入项目后你会看到几个区域对话区、文件列表区、diff预览区。常用快捷键先记住这几个CtrlX在agent、build、plan三种模式之间切换CtrlE打开内置编辑器/打开命令面板里面有模型切换、Skills管理、权限设置等入口CtrlC中断当前AI执行plan模式会让AI先给你完整方案不在你确认前改任何文件所以我接到新需求时都会先切到plan模式问一轮。等方案确认了再切回build模式让它实际动手或者切到agent模式让它自主跑完整个流程。4.2 一次跨文件改动的工作流记录我拿一次真实的改动来说给项目加一个新的登录接口涉及后端路由、参数校验、前端页面和服务层处理。我在对话里描述需求后opencode会先扫描项目结构定位相关文件然后给出它的实施计划。我确认后切换到build模式让它逐个文件改动。每个文件改完右侧diff区都会显示这段改动前后对比我通过快捷键接受或拒绝。最后它自动执行测试命令把通过或失败的消息贴回对话。整个过程里最有价值的其实不是它写代码而是它把“改文件—查diff—跑测试—修复”这个循环拉得很短。我每天大量时间是消耗在“改完代码等编译结果”上的opencode配合权限放开后几乎能做到改完自动跑测试省下的时间非常可观。4.3 权限控制与自动执行策略opencode的权限模型建议认真设置。配置文件里可以对文件读写、命令执行分别设置allow/deny/ask规则。我的建议是分环境个人项目或者新项目可以放开文件读写权限让它放手改改完你看diff公司项目或者重要仓库保持ask模式改之前确认执行危险命令前确认运行自动化流水线时可以用只读权限扫描和输出方案避免误操作有一个我踩过的坑一开始我把命令执行权限全部设成allow有一次AI在跑测试时顺手执行了一个清理命令虽然没出事但吓出一身汗。现在非必要时段我都保持ask只有在明确要跑自动化批量任务时才临时放开。5. 让agent更懂代码skills、LSP与Playwright的实际用法5.1 skills给agent定义可复用技能包Skills是opencode里一个很有价值的机制。它允许你用Markdown文件定义一项技能包括适用的任务说明、步骤要求和注意事项。当AI遇到匹配任务时会主动加载对应的技能说明从而按你预设的规范执行。我举个例子。我的项目里有自己的代码规范比如新增接口必须同时更新OpenAPI文档错误码必须统一。以前每次都要在对话里重复说明现在我把规范写成一个skill文件放在项目的skills目录下--- name: api-rule description: 当需要新增或修改API时使用 --- 新增或修改API时必须同步做三件事更新接口文档、补充错误码定义、添加对应测试用例。缺少其中任何一项都视为任务尚未完成。效果很明显AI在改接口相关代码时会自动把这个技能加载进来改完之后顺带把文档和测试也补上。这极大的解决了每次都从零解释的问题。5.2 LSP接入让agent看得见编译诊断很多AI编程工具的痛点在于AI改完代码后自己不知道代码编不编得过。opencode可以通过LSPLanguage Server Protocol接入语言服务让AI感知到编辑器的诊断信息。这意味着AI在修改代码后能通过LSP拿到编译错误、类型错误、lint警告并主动修复。配置LSP需要对不同语言安装对应的language server比如说TypeScript项目要装typescript-language-server。没用LSP之前AI改完代码往往要靠我手动跑一遍编译才知道挂没挂。接入之后它改完就能根据诊断信息自我修正。每次编译反馈都像是一个“哨兵”帮助AI尽早发现错误而不是一口气改完五六个文件才发现方向错了。5.3 Playwright前端验证肉眼确认真改好了opencode支持调用Playwright后它的能力一下就扩到前端测试了。AI不仅能改代码还能打开浏览器实际操作页面确认改动是不是真的有效。典型场景是排查前端bug。你可以直接在对话里让它“复现这个bug”它启动Playwright后打开页面按你描述的操作执行同时观察页面的控制台报错、网络请求和布局变化。整个过程里所有信息都会回传它会基于真实浏览器状态给出判断。我在一个Dashboard项目里用它排查过点击按钮无反应的问题AI通过Playwright打开浏览器执行点击然后从控制台捕获到一个JavaScript报错并定位到具体组件前后花了不到十分钟。这种活以前我至少要开DevTools手动复现一遍再逐个断点排查效率差太多了。需要说明的是Playwright模式下页面交互的耗时会比纯代码扫描长适合用在需要“眼见为实”的验证场景。日常简单改动不必每次都启动浏览器按需求来就行。6. 我用opencode踩过的坑配置、兼容与多Agent并存的心得6.1 配置JSON里的常见误区和修改技巧opencode.json是个很灵活的配置文件但过分灵活也意味着容易配错。我遇到过的坑排序如下模型名写错。同一个服务商下模型名必须用官方API文档里的完整模型标识缩写或口语化写法都会导致启动时找不到模型。provider认证字段不匹配。不同服务商要求的key字段名不同最稳妥的办法是先从官方文档复制示例再替换key值。改了配置没有重启。opencode的配置在启动时读取大部分内容运行时想完全热加载并不总是稳定所以改完配置后重开一下TUI最稳。我建议给opencode.json写个简单注释习惯把每个服务商的用途标注清楚。虽然它是JSON不直接支持注释但很多编辑器插件支持JSONC格式可以当注释用。6.2 接手老项目时怎么让它快速进入状态接手一个没见过的项目最怕AI一顿乱改。我的做法是先切到plan模式让opencode读一遍项目README、目录结构和关键模块入口然后输出一份项目理解报告。这份报告包括项目技术栈、运行方式、关键目录职责、可能的坑点。我会先审核这份报告看它有没有理解偏差。如果项目里有明显的历史包袱比如老代码里有很多废弃接口或者兼容逻辑我会直接在对话里说明或者加到skill里让AI在改动时尽量绕开。这些上下文对AI非常有帮助它不会自动知道你的历史债务在哪里但一旦你告诉它它就会非常稳定地避开雷区。6.3 opencode、codex、claude code、pi怎么共存怎么选现在市面上终端AI Agent不少它们各有各的脾气。我给一个比较简单的选型依据你的核心诉求推荐选择理由需要最大程度的模型自由opencodeprovider可配置不绑特定模型重度使用Claude模型Claude Code对Claude模型支持最完整主要在OpenAI生态里玩耍Codex和OpenAI模型契合度最高追求极致轻量、单任务快速问答pi更轻适合快速交互我的实际做法是让它们共存使用opencode作为主工作台Claude Code处理特定Claude任务pi用来做临时问答。不用非此即彼工具是服务工作的。有一个减少混乱的小技巧不同工具可以用不同配置文件指定不同的默认模型避免互相干扰。比如opencode默认用Claude SonnetCodex用专用模型Claude Code保留默认这样在同一个项目里切换工具时行为差异是可控的、可预期的。回看这几个月的使用opencode最大的吸引力不是某一次惊艳的代码生成而是它把AI编程变成了一套可定制、可控制、可验证的工作流。它的Skills、LSP、Playwright这些能力单独拿出来都不算独一份但组合在一起就形成了一个非常顺手的日常驾驶舱。配置上踩过的坑换个角度想也是它灵活性的体现——如果说我有什么建议那就是刚开始用的时候别贪多先把权限模型和模型选择吃透再往里加Skills和自动化验证等这套跑顺了再回看终端里那些曾经手动完成的事你会觉得过去浪费了不少时间。
