最近我把主力编码 agent 从 Claude Code 换成了 opencode前前后后用了两周第一感受是这东西完全不是 IDE 自动补全那种“AI 助手”它是真的能在终端里自己读代码、改文件、跑命令的智能体。也正因为它的使用方式和传统插件很不一样大量人才会在 opencode 安装、opencode 配置、opencode 免费模型这些环节上卡住。这篇文章我打算把从零到日常使用的完整链路写清楚包括 Windows 上最经典的 cmdlet 报错、接入免费模型的配置方法、Skills 和 Memory 的玩法、VS Code/IDEA 插件到底该怎么配合以及怎么让它用 Playwright 自己测前端 bug。适合所有想把 opencode 当主力编码 agent 的人尤其是刚下载完却在终端里跑不起来的“新手”。1. 先把 opencode 是什么这件事掰扯清楚1.1 它不是 IDE 里的自动补全而是能自己动手的 agent很多人第一次听到 opencode 时会把它和 GitHub Copilot、通义灵码这类补全工具放在一起比这其实是方向错了。opencode 是一个跑在终端里的开源编码 agent它的核心工作流程是你给它一个自然语言任务它自己拆解任务、读取项目文件、定位相关代码、修改文件、执行命令然后告诉你结果。你可以让它从一个报错日志开始排查也可以让它从一个需求描述开始直接实现功能。这和 Copilot 那种“光标停在哪就补全到哪”的交互完全不同。opencode 更像一个坐你旁边的实习生你交代清楚事情它会自己打开各种文件去查最后给出改动方案。这个“自己查、自己试、自己改”的能力才是它被很多人当作 Claude Code 替代品的原因。1.2 为什么 Go 编写这件事会直接影响你的安装命令opencode 本体是用 Go 写的所以最常见的安装方式是go install。你去搜“opencode go”其实搜到的多半是安装命令而不是某个叫“opencode go”的独立产品。Go 带来的好处是单二进制分发装完之后就是一个可执行文件不像 Python 项目要处理一堆依赖。但副作用是如果你本机 Go 工具链不熟很容易装完找不到命令。尤其是 Windows 用户GOPATH/bin没进 PATH终端里就会直接报“无法将 opencode 识别为 cmdlet”。这个报错我在后面会专门展开说。理解了“opencode 是个 Go 写的 agent”后面安装、配置、排查都会顺很多。它的很多报错不是 opencode 自身的问题而是环境变量、配置文件、模型服务哪里没对齐。2. 安装 opencode 时最常见的三处卡壳2.1 Windows 上“无法将 opencode 识别为 cmdlet”的根因和处理这条报错大概是最近搜 opencode 的人里最高频的问题之一完整错误长这样opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写如果包括路径请确保路径正确然后再试一次。第一次看到这个错很多人以为是安装失败了其实大多数情况是 opencode 已经装好但 PowerShell 不知道去哪找它。我先说排查链路。第一步先确认本机有没有 Go 工具链go version如果提示找不到 go那就得先装 Go再去执行官方 README 里的安装命令。主流仓库opencode-ai/opencode一般支持这样装go install github.com/opencode-ai/opencodelatest如果go version正常且安装命令执行完了接下来看 Go 的 bin 目录go env GOPATH通常在C:\Users\你的用户名\go这个路径下而 opencode 的可执行文件会出现在C:\Users\你的用户名\go\bin\opencode.exe。你需要在系统环境变量 PATH 里加上C:\Users\你的用户名\go\bin。我不推荐临时用$env:Path ...; opencode这种写法因为关掉终端就失效。正确做法是系统设置里搜“编辑账户的环境变量”然后双击用户变量里的 Path新建一项把go\bin路径填进去。保存后一定要重开一个 PowerShell 窗口再跑opencode --version只要版本号能打出来这个问题就彻底解决了。2.2 macOS/Linux 下装好了却打不开的 PATH 问题macOS 和 Linux 用户遇到的情况类似但表现不太一样。通常是执行安装脚本或go install之后再执行opencode提示 command not found。原因也很简单Go 把二进制放到了$(go env GOPATH)/bin但这个目录不在你的PATH里。临时处理可以这样做export PATH$(go env GOPATH)/bin:$PATH想一劳永逸就把它写进 shell 配置文件。用 zsh 的写进~/.zshrc用 bash 的写进~/.bashrcecho export PATH$(go env GOPATH)/bin:$PATH ~/.zshrc source ~/.zshrc还有一类情况是安装脚本给到的路径不是 Go bin 目录而是~/.opencode/bin或/usr/local/bin。这种时候不要先怀疑 opencode先看安装脚本输出最后写到了哪个目录再手动把那个目录加进 PATH。2.3 第一次启动报 unexpected server error八成不是安装问题安装通过之后第一次启动 opencode 可能还会遇到一个让人慌的报错error: unexpected server error. check server logs这个报错的迷惑性很强猛一看像是程序崩了。实际上它通常是 opencode 启动内部的 agent server 时出了问题最常见的诱因是模型配置为空、API Key 没设置、配置的模型服务不可用或者本地模型端口没开。遇到这个问题我的排查顺序固定是这样先跑opencode logs看日志或者用opencode --log-level debug启动看它到底卡在哪一步。如果日志里明说认证失败那问题就在 API Key如果日志里是连接被拒那就去看本地模型服务是否在运行。这个报错基本和安装无关别再去重装一遍。3. 模型接入与配置免费模型、API Key、多服务商切换3.1 配置文件到底放在哪里opencode 的配置分两层全局配置和项目级配置。全局配置一般放在用户配置目录下我这边实测是~/.config/opencode/opencode.json项目级配置则放在项目根目录下的.opencode目录里。不同版本、不同安装方式的路径可能会有一点差异最好的办法是看opencode --help里的提示或者直接在当前用户配置目录里搜opencode.json。配置文件的核心作用就是告诉 opencode你要用哪个模型、去哪认证、有没有额外的 provider 设置。它本质上是一份 JSON里面包含 model、provider、apiKey、baseURL 这类信息。不同版本的 schema 有变化我不建议从网上抄一份不回头的配置而是先跑一次官方默认配置再逐项改成你需要的。3.2 免费模型和本地模型怎么接很多人搜“opencode 免费模型”其实核心诉求是想不额外花钱就把东西跑起来。这里有两类路线。第一类是 OpenRouter 这类聚合平台上的“免费模型”通常在模型名后面带有:free标记。你只需要在配置里填 OpenRouter 的 API Key然后把模型指定成某个 free 模型即可。免费模型确实能跑但限流比较厉害适合体验 agent 的工作流不适合日常主力开发。第二类是本地模型也就是通过 Ollama 这类工具跑在你自己电脑上的模型。这条路前期配置多一点但跑起来之后没有按次计费的问题。前提是你机器显存和内存足够不然一个 7B 模型就能把整机拖垮。用 Ollama 接 opencode 时先把 Ollama 服务和模型拉起来ollama serve ollama pull qwen2.5-coder:7b然后在 opencode 的配置里把 provider 指向 Ollama。至于具体的模型标识符不同版本写法略有差异但思路是统一的provider 叫ollama模型名对照ollama list里显示的名字。选本地模型时不要贪大先跑一个小参数模型验证链路再根据真实响应速度决定要不要换更大的。3.3 cc-switch 这类工具在 opencode 配置里的正确用法opencode 本身并不强制要求搭配 cc-switch但如果你手里有两三套不同服务商的 Key每次手动改配置确实很烦。cc-switch 本质上是一个配置切换小工具它把 model、apiKey、baseURL 打包成预设切换时直接写到 opencode 的配置文件里。我见过很多人把 cc-switch 当成 opencode 的官方组件其实不是。它只是在你和配置文件之间加了一层“快捷开关”。用的时候要留意切换后最好重启 opencode或者重新加载配置否则某个会话可能还沿用旧的模型设置。另外这类工具生成的配置模板不一定适配你当前 opencode 版本的 schema切换完如果报错第一时间打开配置文件检查字段名是不是被覆盖成了旧格式。4. opencode 的标准使用姿势从新建对话到真正改代码4.1 先让 agent 出计划再让它碰文件我一开始用 opencode 时犯过一个错上来就让它“把登录页面的 bug 修了”结果它咔咔改了一堆文件最后测试还是挂的。问题不在于 opencode 笨而在于我给的指令缺少约束。现在我的标准工作流是分阶段推进的。第一轮对话只做计划我会说先不要改代码。读一下 src 目录和 tests 目录告诉我 1. 登录页相关的组件和状态管理分别在哪 2. 现有测试覆盖了什么 3. 按照你的判断bug 最可能在哪一层。等它列出计划后我再把具体任务交给它并限定改动范围。这一步很多人会跳过但正是这一点拉开了“能把 agent 用好的人”和“让 agent 乱改代码的人”之间的差距。opencode 的规划能力不差前提是你给它规划的空间。4.2 Skills 和 superpowers 这类扩展该不该装如果你搜 opencode 的时候会看到oh-my-claudecode、superpowers、skills这些词它们其实说的是同一件事给 agent 加“技能包”。Skills 可以理解为一套任务执行模板。比如你经常写前端页面就给它配一个前端调试 skill里面写明遇到运行时错误时应该先启动开发服务器、再截图、再分析控制台而不是凭空猜。opencode 会在合适的场景下自动调用这些 skill。我试过把 oh-my-claudecode 里的一些技能目录塞进 opencode 的 skills 目录能用一部分但不建议全部照搬因为 opencode 的 tool 命名和 Claude Code 不是完全一致。superpowers 更像一套项目管理方法论会强制 agent 在动手前输出测试计划和风险清单这个思路放在 opencode 这种高自由度 agent 上很合适。往项目里加 skill 时我习惯建一个类似这样的目录结构.opencode/ skills/ frontend-debug/ SKILL.mdSKILL.md 里写清楚这个技能什么时候用、具体步骤是什么。不要搞一堆花哨指令先写三到五条真正能指引 agent 行动的内容就行。4.3 用 opencode 接手老项目的三条经验“opencode 接手开发项目”也是很多人搜的高频场景。我实际用它接过一个半年没人维护的 Java 服务和一个结构很乱的 React 项目整体可行但有一些经验值得分享。第一条先让它摸清项目骨架再让它回答问题。一上来就问“这个项目怎么启动”其实不够好更好的方式是读 README、pom.xml 和代码目录说明这个项目的模块划分、入口、构建命令和测试命令。第二条把“项目约定”写进 Memory。opencode 2.0 之后Memory 能力变得比较实用。当它执行过一次正确的改动方式后我会明确告诉它“记住这个项目所有新增接口都放在 controller 外层包下”后续它再改代码就会优先遵守这个约定。第三条每次只让它做一个小而完整的改动。接手老项目时agent 一旦尝试同时处理多个问题很容易把现有逻辑改坏。限定单次任务范围跑完测试再继续效率反而更高。5. VS Code、IDEA、桌面版opencode 插件的真实体验5.1 终端版和 VS Code 插件的分工很多人会在搜索里看到 “opencode vscode 插件” “vscode opencode 插件”然后以为 opencode 主要靠 IDE 插件使用。我的实际感受是opencode 的老家是终端VS Code 插件是锦上添花。终端版的好处是它拥有完整的终端能力可以执行任何命令也可以在 SSH 远程开发时直接跑在服务器上。VS Code 插件更适合轻量场景你在编辑器里选中一段代码让 opencode 解释、改错、写测试这些操作比切到终端再粘贴代码舒服得多。需要注意一点终端版和插件如果同时连接同一个项目最好只让其中一个发起实际的文件修改操作。两个 opencode 实例同时改同一个文件最后结果基本就是互相覆盖。5.2 JetBrains IDEA 里 Maven 项目配置的一个隐藏坑用 IDEA 插件的朋友很多会搜 “opencode mvn 配置”一开始我还以为是 opencode 本身有 mvn 参数后来才反应过来这是同一个问题IDEA 插件该怎么拿到 Maven 项目上下文。opencode 的模型配置和 Maven 配置是两码事。模型配置决定 agent 用什么大脑Maven 配置决定 agent 懂不懂你这个项目的编译依赖。IDEA 里如果 Maven 项目还没完成 import插件里的 opencode 经常答不准依赖关系甚至写出编译不过的代码。我的处理方式是不要一上来就依赖 IDEA 的自动 import而是让 opencode 自己在项目终端里跑一次构建mvn -q -DskipTests compile让它直接面对编译输出比让它在 IDE 的索引里猜更靠谱。如果它改动了pom.xml也一定要让它重新跑一次构建确认依赖能被解析。5.3 桌面版到底值不值得长期用搜索词里有 “opencode 桌面版” 和 “opencode desktop”。如果你已经装了终端版桌面版最吸引人的地方是能看到更直观的 diff 和对话记录。但它目前更像一个带界面的终端壳而不是完全独立的编辑器。我个人的判断是桌面版适合在电脑前做 code review 场景不适合你在远程服务器上干活。SSH 到云服务器时你唯一能用的是终端版桌面版完全帮不上忙。另外桌面版和终端版同时打开同一份项目时文件锁和并发写入都可能出问题。日常开发我还是更推荐终端版为主插件作为辅助。6. 前端 bug 排查如何让 opencode 配合 Playwright 干活6.1 为什么 agent 只靠读静态代码很难定位前端问题前端 bug 有个非常讨厌的特征很多问题只有在真实浏览器环境里才会暴露。某个按钮点击后没反应可能是事件绑定问题也可能是某个异步数据没回来导致的渲染中断还可能是 CSS 遮住了元素导致点击根本没触发。如果只让 opencode 读源码它就只能凭经验猜。猜对算运气好猜错就会陷入“改一下跑一下”的低效循环。所以我一直建议凡是涉及前端运行时的 bug一定要让 opencode 有办法打开真实浏览器。6.2 跑通 Playwright 的最小方案opencode 能不能用 Playwright其实不取决于 opencode 有没有专门插件而取决于它能不能在项目里执行命令。只要项目里有 Node.js 和 Playwright你就能在对话里指挥 opencode 写脚本、跑脚本、看结果。先在项目根目录装好依赖npm init -y npm i -D playwright/test npx playwright install chromium然后在package.json里加一个脚本{ scripts: { test:e2e: playwright test } }接下来就可以在 opencode 里这样下指令用 Playwright 写一个最小复现脚本 1. 打开 http://localhost:3000/login 2. 点击登录按钮 3. 记录控制台报错和网络请求状态 4. 保存截图到 ./artifacts 然后根据结果判断是前端逻辑问题还是接口问题。opencode 会自己写测试脚本、执行它、再读输出。这个过程中它能看到真实浏览器的行为定位 bug 的准确率会明显提高。前端开发里我现在的习惯是任何“现象类” bug 都先走这个流程而不是让它只读代码。7. opencode 2.0 之后和 Codex CLI、Claude Code 怎么选7.1 2.0 的变化和我为什么不追新版本搜索词里频繁出现 “opencode 2.0”说明新版本已经成了很多人关注的焦点。从我实际使用的感受来说2.0 最大的变化不是界面变好看而是把 Skills、Memory 这类长期记忆能力变成了比较正式的功能。但我有个习惯生产环境用的 opencode 版本一旦确认没问题就不会频繁升级。原因很简单agent 类工具迭代太快今天升级完可能某个 provider 的配置格式就变了。我会先在测试仓库里升到新版本跑一遍典型任务确认行为符合预期再把正式环境切过去。7.2 三个 agent 的选型对照如果你在 “opencode codex claude code” 和 “opencode codex pi 哪个 agent 好用” 之间纠结我的建议看下面这张对照表对比项opencodeClaude CodeCodex CLI模型锁定不锁OpenAI/Anthropic/本地模型都能接主要面向 Claude 模型以 Codex/OpenAI 力量为主配置门槛略高需要自己管模型配置中等官方封装较好较低开箱即用Skills/扩展支持生态正在长生态成熟技能包多相对有限适合场景手里有多套模型 Key想灵活切换Anthropic 深度用户OpenAI 系快速上手至于 Pi它更偏对话和方案生成而 opencode 偏任务执行。如果你要的是真去改代码我倾向 opencode。如果你只是需要一个聊天式的架构辅助Pi 或许更轻松。不要指望一个 agent 在所有场景都最好。7.3 最后一点使用建议我现在的做法是把 opencode 当成团队里一个“需要 review 的兼职开发”而不是放权不管的全自动工人。它适合接手老项目、跑测试、找 bug、实现明确的小功能但不适合在没有任何测试保护的情况下直接往主分支推代码。每次让它改完代码我都会要求它列出改动文件再看一眼 diff 再决定要不要提交。如果你刚开始用我建议装完先锁定一个已知行为正常的版本拿一个不重要的仓库跑熟再逐步放开权限。opencode 是个很强大的工具但工具越强越需要你给它画清楚边界。
opencode实战：解决安装配置难题，免费模型+Playwright调试全攻略
最近我把主力编码 agent 从 Claude Code 换成了 opencode前前后后用了两周第一感受是这东西完全不是 IDE 自动补全那种“AI 助手”它是真的能在终端里自己读代码、改文件、跑命令的智能体。也正因为它的使用方式和传统插件很不一样大量人才会在 opencode 安装、opencode 配置、opencode 免费模型这些环节上卡住。这篇文章我打算把从零到日常使用的完整链路写清楚包括 Windows 上最经典的 cmdlet 报错、接入免费模型的配置方法、Skills 和 Memory 的玩法、VS Code/IDEA 插件到底该怎么配合以及怎么让它用 Playwright 自己测前端 bug。适合所有想把 opencode 当主力编码 agent 的人尤其是刚下载完却在终端里跑不起来的“新手”。1. 先把 opencode 是什么这件事掰扯清楚1.1 它不是 IDE 里的自动补全而是能自己动手的 agent很多人第一次听到 opencode 时会把它和 GitHub Copilot、通义灵码这类补全工具放在一起比这其实是方向错了。opencode 是一个跑在终端里的开源编码 agent它的核心工作流程是你给它一个自然语言任务它自己拆解任务、读取项目文件、定位相关代码、修改文件、执行命令然后告诉你结果。你可以让它从一个报错日志开始排查也可以让它从一个需求描述开始直接实现功能。这和 Copilot 那种“光标停在哪就补全到哪”的交互完全不同。opencode 更像一个坐你旁边的实习生你交代清楚事情它会自己打开各种文件去查最后给出改动方案。这个“自己查、自己试、自己改”的能力才是它被很多人当作 Claude Code 替代品的原因。1.2 为什么 Go 编写这件事会直接影响你的安装命令opencode 本体是用 Go 写的所以最常见的安装方式是go install。你去搜“opencode go”其实搜到的多半是安装命令而不是某个叫“opencode go”的独立产品。Go 带来的好处是单二进制分发装完之后就是一个可执行文件不像 Python 项目要处理一堆依赖。但副作用是如果你本机 Go 工具链不熟很容易装完找不到命令。尤其是 Windows 用户GOPATH/bin没进 PATH终端里就会直接报“无法将 opencode 识别为 cmdlet”。这个报错我在后面会专门展开说。理解了“opencode 是个 Go 写的 agent”后面安装、配置、排查都会顺很多。它的很多报错不是 opencode 自身的问题而是环境变量、配置文件、模型服务哪里没对齐。2. 安装 opencode 时最常见的三处卡壳2.1 Windows 上“无法将 opencode 识别为 cmdlet”的根因和处理这条报错大概是最近搜 opencode 的人里最高频的问题之一完整错误长这样opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。请检查名称的拼写如果包括路径请确保路径正确然后再试一次。第一次看到这个错很多人以为是安装失败了其实大多数情况是 opencode 已经装好但 PowerShell 不知道去哪找它。我先说排查链路。第一步先确认本机有没有 Go 工具链go version如果提示找不到 go那就得先装 Go再去执行官方 README 里的安装命令。主流仓库opencode-ai/opencode一般支持这样装go install github.com/opencode-ai/opencodelatest如果go version正常且安装命令执行完了接下来看 Go 的 bin 目录go env GOPATH通常在C:\Users\你的用户名\go这个路径下而 opencode 的可执行文件会出现在C:\Users\你的用户名\go\bin\opencode.exe。你需要在系统环境变量 PATH 里加上C:\Users\你的用户名\go\bin。我不推荐临时用$env:Path ...; opencode这种写法因为关掉终端就失效。正确做法是系统设置里搜“编辑账户的环境变量”然后双击用户变量里的 Path新建一项把go\bin路径填进去。保存后一定要重开一个 PowerShell 窗口再跑opencode --version只要版本号能打出来这个问题就彻底解决了。2.2 macOS/Linux 下装好了却打不开的 PATH 问题macOS 和 Linux 用户遇到的情况类似但表现不太一样。通常是执行安装脚本或go install之后再执行opencode提示 command not found。原因也很简单Go 把二进制放到了$(go env GOPATH)/bin但这个目录不在你的PATH里。临时处理可以这样做export PATH$(go env GOPATH)/bin:$PATH想一劳永逸就把它写进 shell 配置文件。用 zsh 的写进~/.zshrc用 bash 的写进~/.bashrcecho export PATH$(go env GOPATH)/bin:$PATH ~/.zshrc source ~/.zshrc还有一类情况是安装脚本给到的路径不是 Go bin 目录而是~/.opencode/bin或/usr/local/bin。这种时候不要先怀疑 opencode先看安装脚本输出最后写到了哪个目录再手动把那个目录加进 PATH。2.3 第一次启动报 unexpected server error八成不是安装问题安装通过之后第一次启动 opencode 可能还会遇到一个让人慌的报错error: unexpected server error. check server logs这个报错的迷惑性很强猛一看像是程序崩了。实际上它通常是 opencode 启动内部的 agent server 时出了问题最常见的诱因是模型配置为空、API Key 没设置、配置的模型服务不可用或者本地模型端口没开。遇到这个问题我的排查顺序固定是这样先跑opencode logs看日志或者用opencode --log-level debug启动看它到底卡在哪一步。如果日志里明说认证失败那问题就在 API Key如果日志里是连接被拒那就去看本地模型服务是否在运行。这个报错基本和安装无关别再去重装一遍。3. 模型接入与配置免费模型、API Key、多服务商切换3.1 配置文件到底放在哪里opencode 的配置分两层全局配置和项目级配置。全局配置一般放在用户配置目录下我这边实测是~/.config/opencode/opencode.json项目级配置则放在项目根目录下的.opencode目录里。不同版本、不同安装方式的路径可能会有一点差异最好的办法是看opencode --help里的提示或者直接在当前用户配置目录里搜opencode.json。配置文件的核心作用就是告诉 opencode你要用哪个模型、去哪认证、有没有额外的 provider 设置。它本质上是一份 JSON里面包含 model、provider、apiKey、baseURL 这类信息。不同版本的 schema 有变化我不建议从网上抄一份不回头的配置而是先跑一次官方默认配置再逐项改成你需要的。3.2 免费模型和本地模型怎么接很多人搜“opencode 免费模型”其实核心诉求是想不额外花钱就把东西跑起来。这里有两类路线。第一类是 OpenRouter 这类聚合平台上的“免费模型”通常在模型名后面带有:free标记。你只需要在配置里填 OpenRouter 的 API Key然后把模型指定成某个 free 模型即可。免费模型确实能跑但限流比较厉害适合体验 agent 的工作流不适合日常主力开发。第二类是本地模型也就是通过 Ollama 这类工具跑在你自己电脑上的模型。这条路前期配置多一点但跑起来之后没有按次计费的问题。前提是你机器显存和内存足够不然一个 7B 模型就能把整机拖垮。用 Ollama 接 opencode 时先把 Ollama 服务和模型拉起来ollama serve ollama pull qwen2.5-coder:7b然后在 opencode 的配置里把 provider 指向 Ollama。至于具体的模型标识符不同版本写法略有差异但思路是统一的provider 叫ollama模型名对照ollama list里显示的名字。选本地模型时不要贪大先跑一个小参数模型验证链路再根据真实响应速度决定要不要换更大的。3.3 cc-switch 这类工具在 opencode 配置里的正确用法opencode 本身并不强制要求搭配 cc-switch但如果你手里有两三套不同服务商的 Key每次手动改配置确实很烦。cc-switch 本质上是一个配置切换小工具它把 model、apiKey、baseURL 打包成预设切换时直接写到 opencode 的配置文件里。我见过很多人把 cc-switch 当成 opencode 的官方组件其实不是。它只是在你和配置文件之间加了一层“快捷开关”。用的时候要留意切换后最好重启 opencode或者重新加载配置否则某个会话可能还沿用旧的模型设置。另外这类工具生成的配置模板不一定适配你当前 opencode 版本的 schema切换完如果报错第一时间打开配置文件检查字段名是不是被覆盖成了旧格式。4. opencode 的标准使用姿势从新建对话到真正改代码4.1 先让 agent 出计划再让它碰文件我一开始用 opencode 时犯过一个错上来就让它“把登录页面的 bug 修了”结果它咔咔改了一堆文件最后测试还是挂的。问题不在于 opencode 笨而在于我给的指令缺少约束。现在我的标准工作流是分阶段推进的。第一轮对话只做计划我会说先不要改代码。读一下 src 目录和 tests 目录告诉我 1. 登录页相关的组件和状态管理分别在哪 2. 现有测试覆盖了什么 3. 按照你的判断bug 最可能在哪一层。等它列出计划后我再把具体任务交给它并限定改动范围。这一步很多人会跳过但正是这一点拉开了“能把 agent 用好的人”和“让 agent 乱改代码的人”之间的差距。opencode 的规划能力不差前提是你给它规划的空间。4.2 Skills 和 superpowers 这类扩展该不该装如果你搜 opencode 的时候会看到oh-my-claudecode、superpowers、skills这些词它们其实说的是同一件事给 agent 加“技能包”。Skills 可以理解为一套任务执行模板。比如你经常写前端页面就给它配一个前端调试 skill里面写明遇到运行时错误时应该先启动开发服务器、再截图、再分析控制台而不是凭空猜。opencode 会在合适的场景下自动调用这些 skill。我试过把 oh-my-claudecode 里的一些技能目录塞进 opencode 的 skills 目录能用一部分但不建议全部照搬因为 opencode 的 tool 命名和 Claude Code 不是完全一致。superpowers 更像一套项目管理方法论会强制 agent 在动手前输出测试计划和风险清单这个思路放在 opencode 这种高自由度 agent 上很合适。往项目里加 skill 时我习惯建一个类似这样的目录结构.opencode/ skills/ frontend-debug/ SKILL.mdSKILL.md 里写清楚这个技能什么时候用、具体步骤是什么。不要搞一堆花哨指令先写三到五条真正能指引 agent 行动的内容就行。4.3 用 opencode 接手老项目的三条经验“opencode 接手开发项目”也是很多人搜的高频场景。我实际用它接过一个半年没人维护的 Java 服务和一个结构很乱的 React 项目整体可行但有一些经验值得分享。第一条先让它摸清项目骨架再让它回答问题。一上来就问“这个项目怎么启动”其实不够好更好的方式是读 README、pom.xml 和代码目录说明这个项目的模块划分、入口、构建命令和测试命令。第二条把“项目约定”写进 Memory。opencode 2.0 之后Memory 能力变得比较实用。当它执行过一次正确的改动方式后我会明确告诉它“记住这个项目所有新增接口都放在 controller 外层包下”后续它再改代码就会优先遵守这个约定。第三条每次只让它做一个小而完整的改动。接手老项目时agent 一旦尝试同时处理多个问题很容易把现有逻辑改坏。限定单次任务范围跑完测试再继续效率反而更高。5. VS Code、IDEA、桌面版opencode 插件的真实体验5.1 终端版和 VS Code 插件的分工很多人会在搜索里看到 “opencode vscode 插件” “vscode opencode 插件”然后以为 opencode 主要靠 IDE 插件使用。我的实际感受是opencode 的老家是终端VS Code 插件是锦上添花。终端版的好处是它拥有完整的终端能力可以执行任何命令也可以在 SSH 远程开发时直接跑在服务器上。VS Code 插件更适合轻量场景你在编辑器里选中一段代码让 opencode 解释、改错、写测试这些操作比切到终端再粘贴代码舒服得多。需要注意一点终端版和插件如果同时连接同一个项目最好只让其中一个发起实际的文件修改操作。两个 opencode 实例同时改同一个文件最后结果基本就是互相覆盖。5.2 JetBrains IDEA 里 Maven 项目配置的一个隐藏坑用 IDEA 插件的朋友很多会搜 “opencode mvn 配置”一开始我还以为是 opencode 本身有 mvn 参数后来才反应过来这是同一个问题IDEA 插件该怎么拿到 Maven 项目上下文。opencode 的模型配置和 Maven 配置是两码事。模型配置决定 agent 用什么大脑Maven 配置决定 agent 懂不懂你这个项目的编译依赖。IDEA 里如果 Maven 项目还没完成 import插件里的 opencode 经常答不准依赖关系甚至写出编译不过的代码。我的处理方式是不要一上来就依赖 IDEA 的自动 import而是让 opencode 自己在项目终端里跑一次构建mvn -q -DskipTests compile让它直接面对编译输出比让它在 IDE 的索引里猜更靠谱。如果它改动了pom.xml也一定要让它重新跑一次构建确认依赖能被解析。5.3 桌面版到底值不值得长期用搜索词里有 “opencode 桌面版” 和 “opencode desktop”。如果你已经装了终端版桌面版最吸引人的地方是能看到更直观的 diff 和对话记录。但它目前更像一个带界面的终端壳而不是完全独立的编辑器。我个人的判断是桌面版适合在电脑前做 code review 场景不适合你在远程服务器上干活。SSH 到云服务器时你唯一能用的是终端版桌面版完全帮不上忙。另外桌面版和终端版同时打开同一份项目时文件锁和并发写入都可能出问题。日常开发我还是更推荐终端版为主插件作为辅助。6. 前端 bug 排查如何让 opencode 配合 Playwright 干活6.1 为什么 agent 只靠读静态代码很难定位前端问题前端 bug 有个非常讨厌的特征很多问题只有在真实浏览器环境里才会暴露。某个按钮点击后没反应可能是事件绑定问题也可能是某个异步数据没回来导致的渲染中断还可能是 CSS 遮住了元素导致点击根本没触发。如果只让 opencode 读源码它就只能凭经验猜。猜对算运气好猜错就会陷入“改一下跑一下”的低效循环。所以我一直建议凡是涉及前端运行时的 bug一定要让 opencode 有办法打开真实浏览器。6.2 跑通 Playwright 的最小方案opencode 能不能用 Playwright其实不取决于 opencode 有没有专门插件而取决于它能不能在项目里执行命令。只要项目里有 Node.js 和 Playwright你就能在对话里指挥 opencode 写脚本、跑脚本、看结果。先在项目根目录装好依赖npm init -y npm i -D playwright/test npx playwright install chromium然后在package.json里加一个脚本{ scripts: { test:e2e: playwright test } }接下来就可以在 opencode 里这样下指令用 Playwright 写一个最小复现脚本 1. 打开 http://localhost:3000/login 2. 点击登录按钮 3. 记录控制台报错和网络请求状态 4. 保存截图到 ./artifacts 然后根据结果判断是前端逻辑问题还是接口问题。opencode 会自己写测试脚本、执行它、再读输出。这个过程中它能看到真实浏览器的行为定位 bug 的准确率会明显提高。前端开发里我现在的习惯是任何“现象类” bug 都先走这个流程而不是让它只读代码。7. opencode 2.0 之后和 Codex CLI、Claude Code 怎么选7.1 2.0 的变化和我为什么不追新版本搜索词里频繁出现 “opencode 2.0”说明新版本已经成了很多人关注的焦点。从我实际使用的感受来说2.0 最大的变化不是界面变好看而是把 Skills、Memory 这类长期记忆能力变成了比较正式的功能。但我有个习惯生产环境用的 opencode 版本一旦确认没问题就不会频繁升级。原因很简单agent 类工具迭代太快今天升级完可能某个 provider 的配置格式就变了。我会先在测试仓库里升到新版本跑一遍典型任务确认行为符合预期再把正式环境切过去。7.2 三个 agent 的选型对照如果你在 “opencode codex claude code” 和 “opencode codex pi 哪个 agent 好用” 之间纠结我的建议看下面这张对照表对比项opencodeClaude CodeCodex CLI模型锁定不锁OpenAI/Anthropic/本地模型都能接主要面向 Claude 模型以 Codex/OpenAI 力量为主配置门槛略高需要自己管模型配置中等官方封装较好较低开箱即用Skills/扩展支持生态正在长生态成熟技能包多相对有限适合场景手里有多套模型 Key想灵活切换Anthropic 深度用户OpenAI 系快速上手至于 Pi它更偏对话和方案生成而 opencode 偏任务执行。如果你要的是真去改代码我倾向 opencode。如果你只是需要一个聊天式的架构辅助Pi 或许更轻松。不要指望一个 agent 在所有场景都最好。7.3 最后一点使用建议我现在的做法是把 opencode 当成团队里一个“需要 review 的兼职开发”而不是放权不管的全自动工人。它适合接手老项目、跑测试、找 bug、实现明确的小功能但不适合在没有任何测试保护的情况下直接往主分支推代码。每次让它改完代码我都会要求它列出改动文件再看一眼 diff 再决定要不要提交。如果你刚开始用我建议装完先锁定一个已知行为正常的版本拿一个不重要的仓库跑熟再逐步放开权限。opencode 是个很强大的工具但工具越强越需要你给它画清楚边界。
