最近我看到后台咨询里“opencode”相关的问题一下子多了起来从“opencode安装教程”“opencode使用教程”到“opencode配置”“opencode免费模型”再到什么“opencode playwright”、opencode skills、“opencode memory”热度涨得很快。我自己的感受是过去半年AI编程工具圈的注意力几乎全被Claude Code和Codex瓜分而opencode能在这时候冲出来说明它确实踩中了不少人的真实需求——一个开源的、跑在终端里的、不绑定单一模型的AI编程代理而且安装配置足够简单还能配合VS Code、IDEA、桌面端一起用。这篇文章我不打算给你复述官方README而是把我从零开始接触opencode、装坏过好几次环境、换过好几轮模型、最终把它纳入日常开发流程的完整过程写下来。包括它到底是什么、为什么值得关注、怎么安装不踩坑、配置文件里的关键项怎么理解、Skills和Memory这些“听起来很玄”的功能到底怎么用以及我在实际项目里遇到的那些报错和排查思路。内容会偏实操尽量把每一步的“为什么”也交代清楚这样你遇到变种问题时不至于只会照抄命令。1. 先搞清楚opencode是什么以及它凭什么火起来1.1 opencode的定位和能解决的实际问题简单说opencode是一个运行在终端里的开源AI编程代理AI coding agent。它的使用方式和Claude Code很像你在项目目录下启动它它会读取你项目里的代码结构通过对话理解你的需求然后帮你完成读代码、改代码、跑命令、查报错、提交PR这一整条链路的工作。但和Claude Code最大的区别在于opencode不绑定任何一家模型厂商。你可以把它接到Anthropic的Claude、OpenAI的GPT系列、Google的Gemini也可以接本地跑的Ollama模型或者接各种兼容OpenAI协议的网关服务。这一点对我来说是决定性的优势——因为我的实际项目分散在不同技术栈里有些重前端、有些重后端不同模型在不同任务上的表现差异很大。用opencode之后我可以在同一个工具里按项目切换模型而不是每个模型配套一个专用agent工具。它还解决了另一个很实际的问题团队协作。opencode支持配置文件入库可以把模型偏好、项目约定、常用指令都写到项目仓库里新成员clone下来就能用同一套配置不需要每个人在自己的IDE里反复设置。我接手过不少旧项目第一步就是用opencode读一遍项目结构、生成一份AGENTS.md文档把构建命令、测试命令、目录约定都固化下来后面再让AI改代码时准确率明显不一样。1.2 opencode和Claude Code、Codex、Pi等工具的对比网上经常有人问“opencode codex claude code哪个agent好用”其实这种问法本身就有问题。这几个工具虽然都叫AI agent但定位不完全一样适合的团队和使用场景也不同。我把自己用过的感受整理成一张表工具是否开源模型绑定交互形态核心优势主要的坑Claude Code否绑定Anthropic终端CLI代码理解能力强长上下文稳定需要Anthropic API Key费用偏高OpenAI Codex否绑定OpenAI终端CLI / 云端和OpenAI生态结合深模型单一部分任务表现波动opencode是不绑定多模型可切终端TUI / 桌面 / IDE插件开源、灵活、配置透明多模型切换需要自己维护配置Pi是不绑定终端CLI轻量、上手快功能相对少适合简单任务这里要注意一点opencode团队本身也在做自己的订阅服务社区里常说的opencode go、opencode套餐走的是网关接入多家模型的路线。但我个人的建议是如果你已经有了可用的模型API Key完全不需要买额外套餐直接配置原生API就行。订阅模式适合那些不想维护多家API账号、希望一个Token走天下的人。1.3 opencode到底是谁家出的以及开源社区的氛围“opencode是哪家公司的”这个问题我看网上说法挺乱的甚至有人把它归到某个大厂名下这不太准确。opencode目前是由SST团队主导开发并开源维护的核心作者是Dax Raad——如果你用过SST这个Serverless框架应该对它有印象。简单说这不是某个大厂的内部工具拿出来秀而是做开发者工具出身的团队在认真打磨一个社区驱动的产品。这也解释了opencode的一个鲜明特点迭代非常快社区反馈直接驱动功能开发。比如我最早用的时候还没有桌面版后来慢慢有了VS Code插件、IDEA插件、桌面客户端这些都是社区呼声很高后才补上的。代价是文档更新有时候跟不上版本很多新功能要靠看GitHub Release、翻Issues才能搞明白。所以我一直有个建议装opencode之前先看一眼官方仓库的Release页面知道自己装的版本有哪些已知问题能省很多排查时间。2. opencode安装的几种方式以及新手最容易踩的坑2.1 官方推荐的安装路径npm全局安装如果你电脑上有Node.js环境最省事的安装方式是npm全局安装npm install -g opencode-ai装完之后在终端输入opencode能正常进入交互界面就算装好了。这里有个细节容易翻车opencode在npm上的包名不是opencode而是opencode-ai。为什么因为npm上opencode这个包名很早就被别的项目占用了。如果你看到某些教程让你npm install -g opencode装出来的可能是另一个完全不相关的东西运行命令的时候会报各种莫名其妙的问题。我早期就踩过这个坑后来养成习惯包名一律以官方文档为准。除了npm如果装了HomebrewmacOS或ScoopWindows也可以用brew install opencode scoop install opencode这两种方式的好处是后续升级方便坏处是版本可能不是最新的。如果某个新功能你等了很久还没在brew或scoop里看到那就直接去GitHub Releases页面下载对应平台的二进制包手动替换到PATH目录里。2.2 Windows上“不是内部或外部命令”这类报错的真正原因热搜词里有一条很典型opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。Windows用户看到这行报错第一反应通常是“是不是安装失败了”但我实测下来绝大多数情况是以下三个原因之一第一npm全局安装目录没有加入PATH环境变量。Node.js安装时会把npm的全局目录配好但如果你是用nvm-windows或者自己下载Node二进制包解压的全局bin目录可能不在PATH里。解决办法是先查看全局目录位置npm config get prefix比如输出是C:\Users\你的用户名\AppData\Roaming\npm那就把这个路径手动加到系统环境变量的PATH里然后重新打开终端。第二安装过程中被Windows Defender或杀毒软件拦了。这种情况不常见但我确实遇到过——npm安装时报Success但实际bin目录里没有opencode.exe。排查方式很简单直接去npm全局目录下看有没有opencode相关文件如果没有就是被安全软件静默删了加白名单后重新安装。第三你当前用的终端是PowerShell但执行策略限制了脚本运行。opencode安装后默认生成的启动器可能是.cmd或.ps1PowerShell在执行策略受限时不让跑。解决办法是管理员权限打开PowerShell执行Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser之后重新打开终端。如果还是不行就直接用opencode.cmd试试能跑起来说明就是执行策略的问题。2.3 用go install安装的注意事项“opencode go安装”也是搜索热词里出现比较多的我理解大家想说的是能不能用go install装这个工具。理论上opencode是Go语言写的确实支持go install github.com/sst/opencodelatest但这里要提醒一句用go install装出来的版本依赖Go模块代理的同步速度通常比npm或Release包慢一到两个版本。官方往往先在npm上发版GitHub Release通常同步Go模块索引再往后排。如果你是为了体验新功能不建议用go install如果是固定版本长期使用go install倒是没问题。另外go install装出来的二进制默认放在$GOPATH/bin目录下如果这个目录不在PATH里运行opencode同样会提示找不到命令。这一点和前面Windows的问题本质上是一样的不是工具没装上而是系统找不到它。2.4 验证安装成功的几个快速检查方法装完之后我建议按顺序跑三条命令确认环境是好的opencode --version opencode --help opencode auth list第一条看版本第二条看帮助信息第三条看认证状态。如果你执行opencode auth list时提示没有登录任何模型提供商说明核心程序没问题只是还没配置模型。后面我会单独讲模型接入。注意运行opencode需要一个终端模拟器Windows自带的旧版cmd在渲染TUI界面时可能会出现显示错乱、闪烁、中文乱码等问题。建议优先用Windows Terminal。我实测下来Windows Terminal PowerShell 7的组合最稳编辑体验接近macOS上的iTerm2。3. 模型接入与配置免费模型、订阅服务、CC Switch怎么配合3.1 第一次启动先搞清楚opencode auth login干嘛用装好opencode之后第一次运行界面会提示你登录模型提供商。这一步其实是opencode的一个设计亮点它不直接让你在配置文件里填API Key而是通过opencode auth login命令走浏览器OAuth流程把Key安全地存在系统钥匙串里。我举个实际例子你想用Anthropic的Claude模型在终端执行opencode auth login它会列出支持的提供商清单选Anthropic浏览器弹出授权页面登录后Key就自动保存了。之后再执行opencode auth list能看到当前已登录的provider列表。为什么要这么做因为如果直接让你编辑配置文件很容易出现Key不小心提交到Git仓库的事故。OAuth方式至少保证了Key不落在项目文件里。我这里想强调的是如果你在配置里写死了API Key记得在.gitignore里排除opencode的配置文件尤其当你的项目是公开仓库时。3.2 opencode.json配置文件provider、model、权限设置的详解opencode的配置文件支持三种级别全局配置、项目配置、本地私有配置。按优先级从低到高是全局~/.config/opencode/opencode.json 项目项目根目录opencode.json 本地私有opencode.local.json。全局配置适合放默认provider和模型项目配置适合放这个项目特有的约定本地私有配置适合放个人偏好并且建议加进.gitignore。一个最小的配置文件长这样{ $schema: https://opencode.ai/config.json, provider: { default: anthropic, anthropic: { model: claude-sonnet-4-20250514 } }, permission: { default: allow } }逐个拆解一下provider.default默认使用哪个提供商取值对应opencode models列出的provider id。provider.anthropic.model指定该提供商下默认的模型ID。模型ID怎么写直接执行opencode models就能看到。permission.default工具的自动授权策略。allow表示agent执行命令、改文件时不再弹确认框效率高ask表示每个操作都要你确认安全但烦deny表示不允许agent自动执行任何操作基本等于只读模式。我的建议是在个人电脑上做探索性项目时用allow在团队项目或生产环境涉及写操作时用ask。权限这块是opencode里最容易被忽略但影响很大的配置因为它直接决定了agent执行改动的自由度。你要是上来就allow有心理准备不至于吓一跳因为agent跑起来可能连续改好几个文件、执行好几条命令。3.3 免费模型怎么接Ollama本地模型和Google Gemini免费额度热搜词里“opencode免费模型”热度很高。我先把结论放在前面严格意义上大模型API几乎没有“免费”的但确实存在两种接近免费的路子一种是本地模型一种是有免费额度的云模型服务。先看本地模型。opencode支持Ollama作为provider只要你本机装好Ollama并拉取了对应模型配置非常简单{ provider: { ollama: { model: qwen2.5-coder:7b } } }然后在opencode里切换模型为ollama/qwen2.5-coder:7b即可。本地模型的优点是不用联网、数据安全、免费缺点也很直接——对机器性能要求高小参数模型代码理解能力有限做点简单的重构、写点小工具、解释代码逻辑还可以应付复杂业务逻辑会力不从心。再看有免费额度的云服务。Google Gemini系列经常开放免费额度如果你能拿到API Key就可以在opencode里配置{ provider: { google: { model: gemini-2.5-flash, apiKey: 你的Key } } }免费额度的限制通常是每分钟请求数、每天token总量有限适合轻量使用。我的建议是免费额度用来跑通流程、做demo、处理次要任务没问题真正赶项目还是用稳定付费的模型不然做到一半撞上速率限制心情会非常差。3.4 opencode go订阅到底值不值以及和CC Switch的配合“opencode go套餐”“opencode go订阅模型选择”是社区讨论很热烈的话题。opencode团队确实推出了订阅服务主要通过网关聚合多模型一个订阅账号能切换多家模型对不想分别维护多个API Key的人比较友好。但我要泼一盆冷水订阅服务的好处是方便代价是灵活性降低。你可能会遇到网关侧模型更新不及时、高峰期限流、某些模型在你的账号下不可用等问题。社区里很多人为了在多个CLI工具之间共用一套订阅配置会配合使用CC Switch之类的第三方工具来切换provider配置。CC Switch的作用其实就是帮你管理不同工具的API配置把它们集中在一个面板里切换。如果你决定走“订阅 CC Switch”这条路我建议按这个顺序操作先装好CC Switch在面板里把opencode的配置文件路径指到opencode的配置目录然后在CC Switch里选择不同的provider组合再回到opencode用/models命令看当前生效的模型列表。这样至少能保证你切换配置后opencode里能用的模型是跟着变的。不过我个人的习惯是主力项目用自己的API Key探索项目用免费额度订阅服务只作为备选。因为工具链里依赖层数越少故障排查就越快。你想一下如果一次报错要同时排查opencode、订阅网关、CC Switch三层配置定位问题的时间会翻好几倍。3.5 “This model is not available in your country”这类报错怎么处理搜索词里有一条很典型this model is not available in your country. opencode怎么用muse spark 1.3 fr。遇到这类报错很多人第一反应是换节点、改网络环境但我必须明确说模型可用区域是由模型服务商根据网络出口IP、账号地区、服务条款综合决定的客户端层面没有任何合法手段能绕过这个限制。从技术排查的角度你能做的主要是以下几件事第一确认报错来自哪一层。如果你用的是官方API报错通常来自模型提供商的接口响应如果你用的是订阅网关报错可能来自网关侧。两种情况下排查对象不同。第二确认你配置的模型ID是否正确。有些模型在服务商那边有区域版本比如某个模型的欧洲版本、亚太版本模型ID写法不一样。执行opencode models查看当前provider支持的最新模型ID对照服务商官方的模型列表看看是不是用错了ID。第三如果这个模型在你的地区确实不可用最稳妥的方案就是换一个提供同级别能力的替代模型或者改用本地模型。现在的开源模型进步很快在特定任务上并不比商业模型差太多完全值得一试。4. opencode核心功能拆解Skills、Memory、LSP、Playwright到底是什么4.1 Skills让agent学会你的“独家招式”Skills是opencode社区比较新的概念很多人在热搜里搜“opencode skills”。用大白话理解Skills就是一套预定义的指令模板让agent学会特定的执行流程或领域知识。这个设计思路有点像给agent装备了“技能卡”需要时调用不需要时不干扰普通对话。举个例子你经常让opencode按你们的团队规范创建React组件每家公司的规范多少有点不一样有人用function组件有人用箭头函数有人样式文件单独放有人用CSS-in-JS。你可以把这些偏好写成一个Skill内容类似Skill Name: react-component 执行步骤 1. 根据组件名生成函数式组件 2. 样式文件使用同目录下同名.module.css 3. 添加默认导出 4. 补充组件的Props类型定义配置好之后下次你只需要说“用react-component创建一个Button组件”agent就会自动按这个流程执行产出的代码格式直接符合团队规范。这一点比在对话里一遍遍纠正agent要省心太多。Skill文件一般放在项目目录下的.opencode/skills/或者由opencode管理具体路径以当前版本文档为准。它的本质是prompt模板 可编程步骤所以你可以把它理解成“给agent写的SOP”。4.2 Memory让agent记住项目的前因后果“opencode memory”也是高频搜索词。Memory讨论的是agent如何跨会话记住有效信息。默认情况下LLM是无状态的每次对话结束它对你的项目就没有记忆了。这导致你每次开新会话都要重新解释项目背景很浪费。opencode的做法是通过AGENTS.md文件来承载项目级记忆。你可以在项目根目录建一个AGENTS.md把项目用到的技术栈、目录结构、构建命令、测试命令、编码约定、已知坑点写进去。启动opencode后agent会自动读取这个文件相当于一进场就快速了解了项目“前情提要”。我实际项目里就是这么用的接手一个旧项目第一件事让opencode读一遍代码然后我手动补充AGENTS.md把容易踩的坑写进去。之后再开新会话让agent改代码你会发现它不再犯那些查过一遍才能知道的低级错误。这个文件建议提交到Git仓库团队里每个人都受益。4.3 LSP接入代码补全和跳转是怎么做到的“opencode 如何使用lsp”这个搜索词说明不少人对opencode的代码理解能力有期待。LSPLanguage Server Protocol在IDE里很常见它提供代码补全、跳转定义、查找引用、错误提示这些能力。opencode支持接入LSP让agent在分析代码时能调用这些能力而不是只靠阅读理解全文。配置方式上opencode会在你有需要时自动启动对应语言的LSP Server你也可以手动指定。比如前端项目里TypeScript的tsserver会自动生效。实际效果是agent在处理重构、重命名、跨文件引用时正确率会明显提升。这里要提醒一点LSP启动后会占据一定内存项目代码量大时资源占用会比较明显。如果你只是让opencode写一个新函数不涉及跨文件分析可以在配置里关掉LSP速度反而更快。按需开启不要无脑全开。4.4 Playwright接入自动化测前端Bug的正确姿势“opencode playwright 怎么测试前端bug”这个问题问的人很多。Playwright是一个浏览器自动化测试框架opencode可以把它作为工具接入然后agent就能启动浏览器、打开页面、点击、输入、截图、读取控制台报错把前端Bug的“看现场”环节自动化。我遇到过一次实际场景页面上的弹窗在特定分辨率下被遮挡传统做法是我自己打开DevTools慢慢看。用opencode接入Playwright之后我只需要说“打开首页切换到手机分辨率点击登录按钮把弹出的对话框截图给我再把控制台报错列出来”。agent会自己启动浏览器执行这一串操作把截图和报错信息带回对话里。整个排查过程从“半小时手动操作”变成了“几分钟对话”。配置Playwright需要注意opencode需要能启动浏览器所以本机要装好对应浏览器内核。常见的问题是环境变量里没有配好浏览器路径导致agent报“unable to launch browser”。可以先手动执行npx playwright install chromium把内核装上再试。5. 实操过程用opencode从零接手一个开发项目的完整记录5.1 准备阶段初始化配置和AGENTS.md下面我把自己接手一个实际前端项目的完整过程记录下来给你提供一套可以直接“抄作业”的流程。场景是我需要接手一个同事留下的大型React项目代码量大概十几万行。我打开终端进入项目目录先执行opencode第一次打开后我先执行命令/init这个命令会让opencode扫描项目结构并生成一份AGENTS.md草稿里面包括项目技术栈、关键目录说明、构建命令等。生成完之后我检查一遍把同事在交接文档里提到的“部署时注意先执行xx脚本”这种坑补充进去。然后我在对话里提一个整体认知请求“请通读项目README和package.json梳理出项目的核心业务流程和主要模块划分用结构化方式列出来。”这一步让agent在正式开始改代码前先对项目有个全局认识。这个过程我觉得非常关键相当于人对项目的“入职培训”不带这一步直接让人干活差错率会高很多。5.2 典型任务执行从需求到代码落地有了AGENTS.md和整体认知之后我接到一个实际需求修改用户信息编辑页增加“头像裁剪上传”功能。我在opencode里把需求尽可能描述清楚“在用户信息编辑页增加头像裁剪上传功能要求支持正方形裁剪上传前预览使用现有的upload API仿照项目中已有上传组件的写法权限控制保持和其他编辑操作一致。”注意我这里提到了“仿照项目中已有上传组件的写法”——这就是在利用Memory让agent参考项目里已有代码风格而不是凭空发挥。opencode会先分析现有组件结构找到和上传相关的已有代码然后给出实现方案。如果它不确定某些细节会主动提问。我在实际体验里的感受是让agent先给方案再动手比让它直接改代码要稳得多。你可以使用斜杠命令如/plan来让它先做计划。在它动手改代码时我观察它的操作日志确保它没有改到不该动的文件。改完之后我让它执行项目自带的lint和测试命令确认不引入新的报错。这一步相当于“人工验收”无论如何不能省。5.3 测试前端Bug的实战片段在另一个场景里我需要验证一个分页组件在数据为空时是否显示正确。我采用Playwright方案对opencode说“用playwright打开本地开发环境进入列表页把接口返回改成空数组截图看空状态样式是否正常。”它会启动浏览器打开页面可能还会让我手动帮助登录然后尝试修改网络响应。整个过程如果顺利几十秒内能回来一张截图和操作记录。这种能力放在以前要么我手动调半天要么写个临时测试脚本而现在类似的交互被压缩进了自然语言指令里。有一点要提醒涉及登录态的页面Playwright的操作经常卡在登录环节。解决思路是给agent提供一套测试账号或者提前用浏览器会话保持登录状态。最省事的做法是先手动在浏览器里登录一次让session cookie持久化再让opencode接管后续操作。5.4 项目收尾把经验沉淀回配置文件项目做完之后我会做一个很多教程不会提的操作把这次开发中agent做得不好的地方、容易误判的约定补进AGENTS.md或Skills里。长此以往配置会越来越贴合你和你的团队agent的表现会一次比一次好。这听起来像“调教AI”本质上是沉淀团队知识资产让AI替团队记住那些靠口口相传的规范。6. 常见问题与排查技巧实录6.1 运行时报“unexpected server error”怎么办搜索词里有一条c:\windows\system32opencode error: unexpected server error. check server logs。这类报错我在用opencode早期也遇到过通常是opencode的本地服务或网关服务返回了异常不一定是你的代码问题。排查步骤我建议按顺序来第一步确认opencode版本是不是太旧。因为opencode迭代很快老版本连新网关接口可能不兼容。执行opencode upgrade升级到最新版很多奇奇怪怪的报错会直接消失。第二步查看本地日志。opencode的日志默认在系统临时目录或用户配置目录下具体路径执行opencode --log-path查看。日志里会有具体的错误堆栈能看到是网络层问题、鉴权问题还是模型响应格式问题。第三步检查网络代理。如果你的机器开了系统代理一些请求可能走了代理导致连接异常。关闭代理后再试能排除一个常见干扰项。6.2 配置了模型但对话一直报鉴权失败这个问题常见原因有三种API Key配置错误、Key权限不足、模型ID输入错误。API Key错误是最容易自查的去服务商控制台重新生成一个Key替换后再试。权限不足比较隐蔽有些Key默认只有只读权限或者只允许特定模型需要在服务商后台配置完整权限。模型ID输入错误也很常见因为每个服务商的模型命名规则不一样最稳妥的方式是执行opencode models看它列出的模型ID或者去服务商文档复制正确的模型名。6.3 模型响应速度慢或者频繁中断如果你发现opencode对话时响应很慢、经常转圈先检查用的是不是免费额度或低优先级套餐——这类服务的排队机制会导致响应变慢。另外大上下文对话也会拖慢速度因为每次请求都要把历史消息一并发给模型。解决方法有两个方向一是适时用/clear清空上下文只保留当前任务的关键上下文二是在配置里降低model的上下文长度限制或者在模型侧设置maxTokens避免agent一次想太多东西。6.4 各种报错的速查对照我把这段时间你可能会遇到的报错信息、可能原因、解决办法整理成一张速查表方便收藏使用报错/现象常见原因解决办法无法将“opencode”项识别为 cmdletnpm全局目录没加入PATH检查npm prefix把全局bin目录加入PATHunexpected server error版本过旧/网关异常升级opencode查看日志定位具体错误This model is not available in your country模型区域限制更换可用模型或使用本地模型鉴权失败/401API Key错误或权限不足重新生成Key检查账号权限Playwright无法启动浏览器浏览器内核未安装执行npx playwright install chromium响应速度慢免费额度排队/上下文过长清理历史消息升级模型服务中文乱码终端编码问题使用Windows Terminal设置UTF-8编码配置了不生效配置文件优先级混乱检查是否存在项目级配置覆盖了全局配置6.5 几个“过来人”的避坑清单最后分享几个我反复踩过的坑不是官方文档里能直接看出来的。第一个坑不要把permission.default在一开始就设为allow。我理解大家想让agent放手干活但在项目状态不明确时这个设置可能让agent一口气改十几个文件你想回退都费劲。建议先用ask跑通一个简单任务确认它的行为模式符合预期再按需放开权限。第二个坑同时配置多个provider时一定要明确默认模型。opencode并不是自动选择“最聪明的模型”它有自己的一套优先级逻辑。如果你不手动指定可能在你以为用的是Claude时实际用的却是另一个模型。每次开工前用/models确认当前生效的模型。第三个坑及时更新你本地VS Code插件或桌面版。opencode的CLI和IDE插件不是同一个人开发的版本匹配问题会导致插件连不上CLI的本地服务。如果你装了VS Code插件后连不上先去插件设置里把opencode可执行文件路径指向你实际安装的版本。第四个坑AGENTS.md不要写得太长。我在一个项目里把AGENTS.md写得很详细结果每次对话都要消耗大量token去读这份文档反而拖慢了速度。现在我的习惯是AGENTS.md只保留高频、关键的信息详细内容放到按需调用的Skills里。写在最后的个人体会从第一次跑通opencode到现在我把不少日常开发流程都迁移到了这个工具里而且逐渐形成了一套自己的使用习惯小项目直接用默认配置跑团队项目一定会先写AGENTS.md涉及文件改动多的任务就让agent先出计划前端视觉类问题才动用Playwright。这套流程不是opencode官方教的而是我一次次调试、踩坑、调整配置之后慢慢沉淀下来的。最后再分享一个小技巧遇到opencode本身表现不稳定的时候不要第一时间怀疑工具坏了先执行opencode upgrade和opencode doctor看看环境状态。opencode的检查命令能帮你自动诊断配置、权限、版本这些问题很多时候一条命令就能解决。工具类产品的惯性思维是“我配置错了才报错”但在opencode这种高速迭代的项目里“版本太旧”才是最常见的问题来源。