先说结论如果你经常跟终端打交道希望一个 AI 能在你的代码库里直接干活而不是只生成一段代码让你自己复制粘贴那 opencode 值得你花一个周末好好折腾一遍。我大概半年前开始用 opencode起初也是抱着试试看的心态毕竟当时已经习惯了 Claude Code 的交互方式。但真正让我彻底转向它的原因很朴素它的配置是纯文件化的所有模型、工具、技能都能用一份 JSON 管起来团队协作时直接提交到 Git 仓库就能复用。这篇文章我会从安装、配置、IDE 插件、Skills、LSP、常见报错到工具横评完整记录我实际踩过坑和验证过的用法。1. opencode 到底是什么先搞清楚它解决什么问题1.1 它本质上是一个 CLI Agent不是代码补全工具很多人第一次听到 opencode会下意识拿它跟 GitHub Copilot 或 Continue 这类插件类比。其实完全不是一个赛道。Copilot 干的是“你在写代码时猜你下一个字符”opencode 干的是“你把一个任务丢给它它在你的终端里读代码、改文件、执行命令、看报错然后提交一个完整的改动”。它的常见形态是一个全屏 TUI终端界面应用。你敲下opencode回车会进入一个对话界面左边是系统信息、会话状态中间是对话窗口底部是输入框。你可以用自然语言说“帮我修复登录接口的并发问题”它会先扫描项目结构读取相关文件分析问题然后给出修改方案确认后直接改代码。整个过程不需要你手动告诉它文件在哪。这种工作模式带来的最大变化是AI 从“辅助写代码”变成了“执行任务”。它更像一个随时待命的实习生你说清楚目标它会自己去翻代码、跑测试、改 bug。这也是为什么 opencode 这类工具被叫做 Agent 而不是编辑器插件。1.2 它和传统 AI 编程插件的核心区别我可以给你一个非常直观的对比。传统插件的工作流是你选中一段代码你写一个 prompt插件生成代码你手动找到插入位置你自己跑测试验证opencode 的工作流是你描述任务Agent 自己找相关文件Agent 修改代码必要时执行命令Agent 查看测试结果如果失败继续修你 review 最终改动所以如果你只是需要一个“帮你写函数的工具”opencode 也许略重。但如果你的需求是“帮我改完这个模块并保证测试通过”那它就是效率神器。我个人的经验是重构、修 bug、迁移接口这类任务用它省掉的时间和焦虑是最多的。另外opencode 是真正意义上的开源社区项目不是某个大厂的封闭产品。它的迭代节奏非常快社区里每天都有新技能Skills、新插件、新配置方案冒出来。这一点对喜欢掌控感的人来说非常重要——你可以完全决定它用哪个模型、走哪条 API 通道、在哪个目录下能干什么而不是被一个黑盒产品牵着走。2. 安装 opencode 与环境准备从零跑起来2.1 官方安装方式总览opencode 的官方安装方式已经覆盖了主流平台常见有三条路径平台推荐方式备注macOS官方安装脚本或 Homebrewbrew install opencode可用的话会最省事Linux官方安装脚本安装后需要确认 PATH 环境变量Windows官方安装脚本或 npm 安装npm 全局安装需要把 npm 全局目录加到 PATH官方给过一个安装脚本大概长这样curl -fsSL https://opencode.ai/install | bash这个脚本会把可执行文件下载到你的用户目录下的某个 bin 目录里然后提示你把它加到 PATH。如果你不想用脚本npm 也是一个常见选择npm install -g opencode-ai这里我想特别强调一句无论你从哪条路安装装完第一件事不是直接用而是确认命令是否在当前终端生效。因为 opencode 是一个纯 CLI 工具IDE 插件、后台脚本、自动化任务最终都会调用这个可执行文件。如果 PATH 没配好后面所有环节都会在同一个错误上反复卡壳。2.2 安装完成后必须做的几个验证步骤我建议你安装完按下面顺序检查一遍重新打开一个终端窗口不是刷新是重新打开执行opencode --version看是否显示版本号如果提示找不到命令执行which opencode或where.exe opencode定位安装位置确认安装目录是否在 PATH 中不要小看第二步。很多人装完直接在同一个终端窗口里运行发现报错“无法识别”。这不是安装失败而是当前终端的 PATH 没有重新加载。解决方式就是开新窗口或者执行source ~/.bashrc、source ~/.zshrc这类命令刷新环境。首次运行opencode时它会进入交互式配置流程询问你希望使用哪个模型提供方以及是否设置默认模型。如果你暂时不想配置也可以直接选跳过后面用配置文件补齐。我个人的建议是跳过也没关系因为模型配置这件事更适合放在opencode.json里统一管理而不是靠初始化向导一步步点。2.3 Windows 下“无法识别 opencode”的解决细节在 Windows 上最典型的报错是这样opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名这个问题的本质是你的 PowerShell 在当前PATH环境变量里找不到opencode.exe。安装脚本确实把文件放进去了但目录没被系统索引到所以终端不认。你按顺序做这三件事执行npm config get prefix拿到 npm 全局安装目录记下路径通常是C:\Users\你的用户名\AppData\Roaming\npm打开系统设置搜索“编辑账户的环境变量”在“用户变量”的Path里新增上面这个路径确认后重开终端再跑opencode --version如果还是不行可能是安装脚本把可执行文件放到了其他目录。你可以去C:\Users\你的用户名\.opencode\bin这类位置找找也可以全盘搜索opencode.exe然后把所在目录加入 PATH。这个问题一旦解决后面就一马平川了。Windows 上还有一件事值得注意如果你用 Git Bash 或 WSL终端环境和 PowerShell 的 PATH 是分开的需要分别确认。3. 模型接入与 API 配置把模型真正接进来3.1 支持的模型提供方与接入方式opencode 最让我喜欢的一点是没有绑定某个固定模型。它可以把多种服务商接进来常见有三类接入方式典型场景关键配置Anthropic API 直连使用 Claude 系列模型ANTHROPIC_API_KEYOpenAI 兼容接口使用 OpenAI 或其他兼容服务OPENAI_API_KEY以及可选的 baseURL聚合平台 / 网关通过一个密钥访问多个模型平台提供的 baseURL 和 API Key配置入口有两个全局配置和项目配置。全局配置放在~/.config/opencode/opencode.jsonLinux/macOS或%USERPROFILE%\.config\opencode\opencode.jsonWindows项目配置放在项目根目录.opencode/opencode.json。项目配置会覆盖全局配置这非常适合团队场景每个项目固定的模型、技能、工具约束都写在仓库里新同事 clone 下来就直接能用。3.2 通过 opencode.json 自定义 provider如果你想接入一个自定义模型配置文件大概是这样的结构{ $schema: https://opencode.ai/config.json, provider: { my_company_llm: { npm: ai-sdk/openai-compatible, name: My Company LLM, options: { baseURL: https://api.example.com/v1, apiKey: env:MY_COMPANY_API_KEY }, models: { llm-3.5-turbo: { name: My Fast Model } } } } }这段配置我解释一下provider下面定义一个你自己命名的服务商npm字段指定调用方式如果你要接的服务是 OpenAI 兼容协议就用ai-sdk/openai-compatibleoptions.baseURL是服务地址的根路径apiKey建议写成env:变量名的形式而不是直接写密钥models下面列出可用的模型名。配置完这个文件后在 opencode 里通过/models命令就可以看到自定义模型切换过去就能用。这里有一个我踩过几次的坑很多 OpenAI 兼容服务在baseURL结尾要不要带/v1上很随意有的带、有的不带配错了会报 404 或 401。我建议第一次配完先用curl测试一下接口地址是否真的可用再交给 opencode能省很多排查时间。3.3 API Key 管理与环境变量在配置文件里写明文 API Key 是最糟糕的做法因为项目配置可能会被提交到 Git 仓库。正确姿势是配合环境变量export MY_COMPANY_API_KEYsk-xxxx然后在opencode.json里引用env:MY_COMPANY_API_KEY。这样你的配置文件可以公开密钥只在运行环境中存在。Windows 用户可以在系统环境变量里加也可以用 PowerShell 临时设置$env:MY_COMPANY_API_KEY sk-xxxxmacOS/Linux 用户建议写到~/.bashrc、~/.zshrc或.env文件里。注意opencode 读取环境变量是在启动时读的如果你改完环境变量需要重启 opencode 进程否则还是旧的 Key。还有一个小技巧如果你同时在用多个模型提供方可以在配置里给不同 Key 起不同的环境变量名然后在不同项目里引用不同的变量。这样项目 A 用公司模型项目 B 用个人模型互不干扰。3.4 聚合平台与订阅模型选择建议不少用户会问“opencode 用什么订阅模型好”我个人不推荐把精力花在追求某个免费模型上。免费模型往往意味着限流、排队、上下文窗口缩水偶尔用一下可以但如果你打算把 opencode 用到日常开发里稳定性和上下文长度比价格重要得多。如果是通过聚合平台或网关接入订阅模型选模型时盯三件事上下文窗口低于 32K 的模型跑复杂项目会频繁截断任务做到一半失忆很难受限流策略有些订阅套餐名义上便宜但每分钟请求次数极低一跑测试就持续报 429计费模式按 token 计费时一个大型重构任务可能烧掉几百万 token别只盯着单价还要提醒一句任何“订阅模型”是否可用取决于上游服务商而不是 opencode。所以如果某一天某个模型提示不可用第一反应应该是去服务商后台检查状态而不是去怀疑 opencode 坏了。opencode 的角色只是一个标准化的客户端它把所有模型拉到了同一条交互流程里。4. 在编辑器里使用 opencodeVS Code 与 IDEA 实战4.1 VS Code 插件安装与连接 CLI虽然 opencode 的核心是终端应用但它提供官方 VS Code 插件很适合需要同时看代码上下文和对话记录的场景。在 VS Code 扩展面板里搜索opencode安装后通常会在左侧侧边栏或者编辑器面板里出现一个对话框。这个插件本质上是个壳它在后台调用你已经安装好的 opencode CLI。所以插件装完不代表万事大吉你的终端必须能执行opencode命令。如果你的 VS Code 内嵌终端能正常使用 opencode但插件连接到一半报错最常见的原因是 VS Code 进程的环境变量和终端的环境变量不一致。特别是 macOS 上通过 Finder 启动的 VS Code 往往不加载 shell 配置文件导致插件找不到 CLI。解决方式是先关闭 VS Code用终端启动 VS Codecode .看看插件是否恢复正常如果还不行可以在插件设置里手动指定 opencode 可执行文件的路径。Windows 用户可以把上一节提到的 npm 全局路径直接填进去。4.2 IDEA 插件Java/Maven 项目的提示用 JetBrains IDEA 或者 IntelliJ 系 IDE 的人可以在插件市场里搜索 opencode 相关插件。这类插件的使用逻辑和 VS Code 版本类似也是连接本机 CLI。不过我现在要专门说一个场景就是你在 IDEA 里做 Java 或 Maven 多模块项目时opencode 的配置要比常规项目多一步。opencode 默认会根据目录结构猜测项目类型但 Maven 项目里很多 source 路径是约定大于配置的如果 Agent 找不到pom.xml或模块之间的依赖关系它改代码时很容易改错模块。我的经验是在项目根目录的.opencode/opencode.json里把 Maven 相关的命令写清楚或者直接通过 Skills 告诉它先读哪些文件、用什么命令构建。具体做法我放到下一节讲 Skills 时展开。至少有一点请你记住第一次在新项目里用 opencode 之前花两分钟把项目结构跟它说清楚比让它自己瞎猜省一小时。4.3 桌面版不想碰命令行的变通方案如果你实在抵抗命令行opencode 也有桌面应用形态。社区里常说的“opencode desktop”就是一个把 CLI 包装成独立桌面程序的方案适合那些需要 TUI 但又不喜欢终端样式的人。不过我对这种用法持保留态度。opencode 本身的 TUI 已经做得很克制桌面版更多是视觉上的容器底层还是要依赖命令行和本地配置。如果你完全不想碰命令行其实不适合用这类 Agent 工具——你至少需要能看懂环境变量和配置文件。桌面版可以作为团队的“演示模式”或者给非技术决策者展示用真正干活我建议你还是回到终端或 IDE 插件。5. 进阶玩法Skills、LSP、Playwright 与 Memory5.1 Skills把技能变成复制即用的流程定义Skills 是 opencode 里价值密度最高的功能也是我一直推荐团队一定要投入时间做的部分。它的概念很简单你给某个任务定义一个标准化流程保存为一个技能之后随时调用。比如你们团队有固定的代码规范、固定的发布流程、固定的排错套路都可以写成 Skill。有一次我在处理一个老项目的 Maven 报错时直接在对话里输入/skills选中自己定义的 Maven 排错技能它就会按照流程先读pom.xml、再跑编译、再收集报错信息、最后给出修复建议。整个过程不需要我一遍遍重复“请先看一下 pom 配置”。技能文件通常是一个目录里面放SKILL.md文件大概长这样--- name: maven-debug description: 当 Maven 构建失败时用该技能分析日志并修复 --- 1. 读取项目根目录的 pom.xml确认依赖与插件配置 2. 执行 mvn clean compile 收集完整报错信息 3. 根据错误定位到具体 module 或依赖 4. 给出修复建议并同步更新相关文件你可以在全局技能目录放通用技能也可以在项目.opencode/skills/目录放项目专属技能。团队协作时把技能文件放进 Git 仓库所有组员就能共享。社区里也有不少人分享了现成的技能集比如一些叫 superpowers 的技能集合里面打包了一堆实用的 Prompt 工程技巧可以 clone 下来参考。我的建议是先用社区的开胃菜然后开始沉淀自己的菜单。5.2 LSP让 Agent 真正“理解”你的代码LSPLanguage Server Protocol原本是给编辑器提供代码跳转、补全、诊断用的协议。opencode 这类 Agent 工具接入 LSP 之后就能获得代码库的语义信息比如某个函数的定义在哪、哪些地方调用了它、当前文件有什么语法错误。如果没有 LSPAgent 基本只能靠纯文本搜索来找代码遇到重构场景会非常痛苦。它可能看见一个方法名匹配就以为找到了正确位置实际上可能有同名重载、不同包路径等问题。接入 LSP 后Agent 可以像 IDE 一样精确地知道符号之间的关系。实际配置时你通常不需要手动写太多东西opencode 会根据项目语言自动尝试启动对应的 LSP。如果你发现 Agent 的行为明显“两眼一抹黑”建议先确认语言服务器是否已安装比如 TypeScript 项目需要typescriptJava 项目需要 JDK 自带的 language server 支持项目是否有完整的依赖比如 Maven 项目先跑一次mvn dependency:resolve是否在.opencode配置里显式指定了 LSP 的命令参数这一块是 opencode 和普通聊天式 AI 工具拉开差距的关键能力。同样的模型有 LSP 和没有 LSP在大型项目里的表现完全两个级别。5.3 Playwright让 Agent 自己打开浏览器查 Bug如果你是前端开发者热词里那个“opencode playwright 怎么测试前端 bug”我太熟悉了。opencode 可以集成 Playwright让 Agent 在浏览器里主动复现问题而不是靠肉眼盯代码猜 bug。典型场景是这样的你发现登录页在某种情况下会白屏。传统方式是你自己打开 DevTools、复现、打断点、看网络请求。用 opencode 时你可以要求它“用 Playwright 打开本地登录页输入测试账号点击登录然后把控制台报错抓给我”。Agent 会启动一个浏览器实例一步一步执行操作并把实际观察到的页面状态和报错信息拉回到对话里。配置时你只需要在项目里安装好 Playwright并且在给 opencode 的任务描述里明确告诉它“用 Playwright 验证”。它通常会自动生成临时的脚本去跑。这里有个技巧让 Agent 写 Playwright 脚本时明确指定要等待的标签、需要断言的元素避免脚本因为页面加载慢而误判。真实项目里元素加载问题是最常见的坑加上等待逻辑能大幅减少噪音。5.4 Memory让 Agent 记住项目偏好Memory 功能解决的是“失忆”问题。你在开发一个项目时可能会反复强调“不要改公共组件”“测试用例放在 resources 目录下”“提交信息用 conventional commit 格式”这些偏好。如果每个新会话都要重新交代一遍效率会很低。opencode 的 Memory 就是把这类偏好存下来后续会话自动加载。你可以在 TUI 里通过/memory命令添加记录也可以直接编辑对应的 markdown 文件。我一般会在每个项目的初始化阶段就用 Memory 把技术栈、目录结构、常用命令、编码规范写进去。之后不管谁在这个项目里开新会话Agent 都能第一时间知道项目背景。这里建议区分使用全局 Memory 放你自己的通用习惯项目 Memory 放这个仓库的专属规则。不要把全局 Memory 塞太满否则 Agent 在无关项目里也会受到干扰。Memory 这种功能是典型“设置时麻烦十分钟使用后舒服一整年”。6. 真实项目实战用 opencode 接手 Maven 多模块项目6.1 首轮对话怎么问信息密度最高接手一个陌生项目特别是老旧的 Java 多模块项目很多人上来就直接说“帮我看下这个项目”然后抱怨 opencode 的回复不够准确。其实问题往往出在提问方式上。我自己的首发 Bao 文先让 opencode 做一次项目扫描。请先不要修改任何文件。通读整个项目告诉我 1. 顶层模块划分和依赖关系 2. 每个模块的核心职责 3. 项目使用的 Java 版本、构建命令、测试命令 4. 潜在的构建配置问题这个指令的核心是“先只读不改写”。等 Agent 给出项目全景你再提具体需求。这样它的后续操作会精准很多。不要一开始就让它改代码在一个它还不了解的项目里贸然动代码大概率会车毁人亡。6.2 无头模式用 opencode run 做自动化opencode 不只是交互式 TUI它还支持无头模式也就是直接在命令行里运行一条 prompt 然后退出适合写进 CI 脚本或者本地自动化任务。命令形态大概是opencode run 修复 src/main/java 下所有未使用的 import 并运行 mvn test无头模式的场景非常广。我经常用它来处理“批量替换”“统一重构”“自动生成单元测试”这类任务。它可以直接在 shell 脚本里被调用输入任务输出结果不需要你一直守在终端前。但要注意无头模式不会像交互模式那样等你确认每步操作。所以任务描述里要尽可能明确边界比如“只修改 src/main/java不碰测试代码”“修改完运行测试并给出结果摘要”。这样能减少误伤。6.3 用 Skill 固化 Maven 排错流程回到前面提过的 Maven 排错。我经历过的真实情况是项目构建失败的时候报错信息往往铺天盖地真正造成失败的原因可能隐藏在三分之一的地方。人工排查时大家习惯先看第一行异常但 Maven 的很多错误是传递性的真正的根因得继续往下翻。我因此写了一个maven-debugSkill流程是这样的读取项目pom.xml确认 parent、dependency、plugin 配置执行mvn clean verify -DskipTests compile获取完整日志提取日志里的 ERROR 和 BUILD FAILURE 段落而不是只看第一行根据异常类型分类处理依赖冲突跑mvn dependency:tree分析并给出排除建议编译错误定位到源码文件和具体行插件缺失或版本问题检查本地仓库与镜像源配置修改后再次执行构建直到成功把这个流程固化成 Skill 后open code 处理 Maven 问题的能力明显上了一个台阶。它不再是泛泛地“读报错猜原因”而是有一套完整的诊断路径一步一步收敛问题。这也是我认为 Skills 最重要的价值把专业人士的排错思路复制给 AI。6.4 配置文件切换ccswitch 这类工具帮了什么忙当你的项目比较多还各自用了不同的模型提供方时切换 API Key 和 baseURL 会变成一个麻烦事。社区里有人写了 ccswitch 这类配置切换小工具本质上是快速改写 opencode 配置文件让不同项目或不同任务能快速使用不同服务商配置。如果你是这种情况我建议先手工把配置结构理清楚确保你的opencode.json本身是模块化、可维护的再考虑用这类工具。执行顺序是先确认手动能切通再用工具简化重复操作。否则工具反而会成为黑盒出了问题你更难排查。另外如果你把 opencode 接在某个聚合网关后面需要明白一件事这类网关通常暴露的是 OpenAI 兼容接口你真正关心的不是它叫什么名字而是它的 baseURL、apiKey、模型名是否填对。很多人在这一步翻车不是 opencode 的问题而是服务商给的请求地址没看清楚。7. 常见报错排查这些问题 90% 的人都会遇到7.1 opencode 无法识别这是安装环节出现频率最高的问题对应错误信息是opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名我看到不少用户是在c:\windows\system32这个默认目录下直接执行 opencode 的。即便 PATH 配好了有些终端在管理权限下也可能出现环境变量没有继承完整的情况。解决路径前面已经说过了这里只需要再补一条装完任何 CLI 工具如果不想折腾 PATH最省事的方法是直接重启一次电脑再打开终端。不是玄学是环境变量刷新的最彻底方式。报错场景常见原因解决方式提示不是内部或外部命令PATH 里没有 opencode 所在目录找到可执行文件路径加入 PATHCMD 能跑但 PowerShell 不认两个终端的环境变量不同步在系统环境变量里配置不要只在单个终端里临时设置VS Code 插件连不上 CLIVS Code 进程没有加载最新 PATH从终端启动 VS Code或者在插件设置里指定 CLI 路径7.2 unexpected server error 排查opencode error: unexpected server error. check server logs这类报错通常不是 opencode 本身的问题而是它请求模型服务时服务端返回了异常。排查思路按顺序来先确认 API Key 还有效额度没有耗尽确认 baseURL 填的是否正确特别是结尾路径确认你选的模型是否存在模型名是否写错用 curl 直接模拟同样的请求看看服务端返回什么如果直接请求正常但 opencode 里一直报错再看配置文件的 JSON 格式是否正确。尤其注意多了一个逗号、引号不匹配这类低级错误。opencode 的日志目录一般在系统用户目录下macOS 可以在~/Library/Application Support/opencode/log找Linux 在~/.local/share/opencode/log。查日志时重点看请求发出的地址和响应状态码比瞎猜快得多。7.3 model is not available in your country这个错误是模型提供方根据地区限制返回的不是 opencode 能决定的。它通常意味着你请求的模型服务在你当前所在地区没有被授权。遇到这个提示我的建议顺序是换一个模型试试判断是不是所有模型都不可用去服务商后台查看该模型的支持地区联系服务商客服确认企业授权或区域放行策略不要试图用任何非常规手段绕过这种限制也不要轻信“免费模型到处能上”的说法。这类区域限制主要是模型服务商做合规和分发控制用户层面能做的主要是选择合适的模型和合规渠道。我的立场一直很明确工具是拿来提效的不要在合规风险上给自己找麻烦。7.4 其他容易忽略的小问题第一是版本问题。opencode 更新速度非常快API 有时会变。如果你发现某个功能在文档里有但本地怎么都出不来先检查版本是不是太旧。第二是代理冲突。这里我说的是系统层面的网络访问策略——如果你的开发环境配了 HTTP 代理而 opencode 请求的 API 域名走了代理会导致握手失败或证书错误。遇到网络类报错先临时关闭系统代理或者确认该域名是否被代理规则正确放行。第三是并发冲突。不要同时在一个项目里开多个 opencode 会话让它们改代码它们之间没有锁机制很容易互相覆盖。我的习惯是一个项目同时只开一个会话需要并行任务时用无头模式并确保任务范围不重叠。8. 与 Claude Code、Codex、Pi 怎么选一张表讲清楚8.1 工具横向对比open code 不是唯一一个 CLI Agent 工具现在社区里还常见 Claude Code、Codex 以及一些更轻量的 Pi 类工具。选型这个问题没有标准答案我把它整理成表格方便你对照自己的场景维度opencodeClaude CodeCodexPi 类轻量工具交互形态TUI、IDE 插件、桌面版终端 TUIOpenAI 官方 CLI终端 TUI模型绑定灵活支持多种 provider主要围绕 Claude 模型主要围绕 OpenAI 模型取决于具体实现通常也比较灵活配置方式opencode.json 文件化配置配置项较多生态深CLI 参数配置相对简单通常极简可扩展性Skills、自定义 provider、LSP 插件Agents 与 Skills 能力成熟偏代码生成与语义理解偏轻量任务扩展性一般上手成本中等需要配置模型低官方支持好低开箱即用低适合试水适合谁喜欢完全掌控、团队需要共享配置的人Claude 生态深度用户OpenAI 生态用户、快速验证想法的人想体验 Agent 但不想折腾的人我对 Pi 类工具了解不算特别深因为它们迭代也很快但核心体验是“轻”。如果你只是想跑一个快速实验不希望为了配置文件折腾 20 分钟那它可以当做一个快速入口。但如果要真正承接项目级别的重构任务我认为 opencode 和 Claude Code 这样的成熟工具更靠谱。8.2 我的选型建议说句掏心窝的话不要一上来就问“哪个最好”要问“哪个最适合我现在的约束条件”。如果你的公司已经在用 OpenAI 全家桶那 Codex 可能天然顺手如果你重度依赖 Anthropic 模型的编程能力Claude Code 是正路如果你像我一样需要在多个模型、多个项目之间来回切换也希望配置能提交进 Git 仓库让团队复用那 opencode 的开放性就是最大优势。我现在的日常是opencode 作为主入口通过配置文件在不同项目里走不同模型。比如内部项目走公司自建的 OpenAI 兼容服务开源小项目走 Anthropic 模型前端调试时用 Playwright Skill 让它在浏览器里自己验证效果。这套方式用下来最大的感受是“不容易被某个模型绑架”。即便哪天某个模型服务变贵了或下线了只需要改配置换一个模型整套工作流不用动。最后再分享一个我个人的使用习惯不管是哪个 Agent 工具我都坚持“确认过再写入”的原则。让 AI 先给方案我再 review而不是直接让它放手改。这不是对 AI 不信任而是对自己的代码库负责。OpenCode 这类工具的能力边界每天在扩展但你自己的判断力永远是最后一道防线。
先说结论如果你经常跟终端打交道希望一个 AI 能在你的代码库里直接干活而不是只生成一段代码让你自己复制粘贴那 opencode 值得你花一个周末好好折腾一遍。我大概半年前开始用 opencode起初也是抱着试试看的心态毕竟当时已经习惯了 Claude Code 的交互方式。但真正让我彻底转向它的原因很朴素它的配置是纯文件化的所有模型、工具、技能都能用一份 JSON 管起来团队协作时直接提交到 Git 仓库就能复用。这篇文章我会从安装、配置、IDE 插件、Skills、LSP、常见报错到工具横评完整记录我实际踩过坑和验证过的用法。1. opencode 到底是什么先搞清楚它解决什么问题1.1 它本质上是一个 CLI Agent不是代码补全工具很多人第一次听到 opencode会下意识拿它跟 GitHub Copilot 或 Continue 这类插件类比。其实完全不是一个赛道。Copilot 干的是“你在写代码时猜你下一个字符”opencode 干的是“你把一个任务丢给它它在你的终端里读代码、改文件、执行命令、看报错然后提交一个完整的改动”。它的常见形态是一个全屏 TUI终端界面应用。你敲下opencode回车会进入一个对话界面左边是系统信息、会话状态中间是对话窗口底部是输入框。你可以用自然语言说“帮我修复登录接口的并发问题”它会先扫描项目结构读取相关文件分析问题然后给出修改方案确认后直接改代码。整个过程不需要你手动告诉它文件在哪。这种工作模式带来的最大变化是AI 从“辅助写代码”变成了“执行任务”。它更像一个随时待命的实习生你说清楚目标它会自己去翻代码、跑测试、改 bug。这也是为什么 opencode 这类工具被叫做 Agent 而不是编辑器插件。1.2 它和传统 AI 编程插件的核心区别我可以给你一个非常直观的对比。传统插件的工作流是你选中一段代码你写一个 prompt插件生成代码你手动找到插入位置你自己跑测试验证opencode 的工作流是你描述任务Agent 自己找相关文件Agent 修改代码必要时执行命令Agent 查看测试结果如果失败继续修你 review 最终改动所以如果你只是需要一个“帮你写函数的工具”opencode 也许略重。但如果你的需求是“帮我改完这个模块并保证测试通过”那它就是效率神器。我个人的经验是重构、修 bug、迁移接口这类任务用它省掉的时间和焦虑是最多的。另外opencode 是真正意义上的开源社区项目不是某个大厂的封闭产品。它的迭代节奏非常快社区里每天都有新技能Skills、新插件、新配置方案冒出来。这一点对喜欢掌控感的人来说非常重要——你可以完全决定它用哪个模型、走哪条 API 通道、在哪个目录下能干什么而不是被一个黑盒产品牵着走。2. 安装 opencode 与环境准备从零跑起来2.1 官方安装方式总览opencode 的官方安装方式已经覆盖了主流平台常见有三条路径平台推荐方式备注macOS官方安装脚本或 Homebrewbrew install opencode可用的话会最省事Linux官方安装脚本安装后需要确认 PATH 环境变量Windows官方安装脚本或 npm 安装npm 全局安装需要把 npm 全局目录加到 PATH官方给过一个安装脚本大概长这样curl -fsSL https://opencode.ai/install | bash这个脚本会把可执行文件下载到你的用户目录下的某个 bin 目录里然后提示你把它加到 PATH。如果你不想用脚本npm 也是一个常见选择npm install -g opencode-ai这里我想特别强调一句无论你从哪条路安装装完第一件事不是直接用而是确认命令是否在当前终端生效。因为 opencode 是一个纯 CLI 工具IDE 插件、后台脚本、自动化任务最终都会调用这个可执行文件。如果 PATH 没配好后面所有环节都会在同一个错误上反复卡壳。2.2 安装完成后必须做的几个验证步骤我建议你安装完按下面顺序检查一遍重新打开一个终端窗口不是刷新是重新打开执行opencode --version看是否显示版本号如果提示找不到命令执行which opencode或where.exe opencode定位安装位置确认安装目录是否在 PATH 中不要小看第二步。很多人装完直接在同一个终端窗口里运行发现报错“无法识别”。这不是安装失败而是当前终端的 PATH 没有重新加载。解决方式就是开新窗口或者执行source ~/.bashrc、source ~/.zshrc这类命令刷新环境。首次运行opencode时它会进入交互式配置流程询问你希望使用哪个模型提供方以及是否设置默认模型。如果你暂时不想配置也可以直接选跳过后面用配置文件补齐。我个人的建议是跳过也没关系因为模型配置这件事更适合放在opencode.json里统一管理而不是靠初始化向导一步步点。2.3 Windows 下“无法识别 opencode”的解决细节在 Windows 上最典型的报错是这样opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名这个问题的本质是你的 PowerShell 在当前PATH环境变量里找不到opencode.exe。安装脚本确实把文件放进去了但目录没被系统索引到所以终端不认。你按顺序做这三件事执行npm config get prefix拿到 npm 全局安装目录记下路径通常是C:\Users\你的用户名\AppData\Roaming\npm打开系统设置搜索“编辑账户的环境变量”在“用户变量”的Path里新增上面这个路径确认后重开终端再跑opencode --version如果还是不行可能是安装脚本把可执行文件放到了其他目录。你可以去C:\Users\你的用户名\.opencode\bin这类位置找找也可以全盘搜索opencode.exe然后把所在目录加入 PATH。这个问题一旦解决后面就一马平川了。Windows 上还有一件事值得注意如果你用 Git Bash 或 WSL终端环境和 PowerShell 的 PATH 是分开的需要分别确认。3. 模型接入与 API 配置把模型真正接进来3.1 支持的模型提供方与接入方式opencode 最让我喜欢的一点是没有绑定某个固定模型。它可以把多种服务商接进来常见有三类接入方式典型场景关键配置Anthropic API 直连使用 Claude 系列模型ANTHROPIC_API_KEYOpenAI 兼容接口使用 OpenAI 或其他兼容服务OPENAI_API_KEY以及可选的 baseURL聚合平台 / 网关通过一个密钥访问多个模型平台提供的 baseURL 和 API Key配置入口有两个全局配置和项目配置。全局配置放在~/.config/opencode/opencode.jsonLinux/macOS或%USERPROFILE%\.config\opencode\opencode.jsonWindows项目配置放在项目根目录.opencode/opencode.json。项目配置会覆盖全局配置这非常适合团队场景每个项目固定的模型、技能、工具约束都写在仓库里新同事 clone 下来就直接能用。3.2 通过 opencode.json 自定义 provider如果你想接入一个自定义模型配置文件大概是这样的结构{ $schema: https://opencode.ai/config.json, provider: { my_company_llm: { npm: ai-sdk/openai-compatible, name: My Company LLM, options: { baseURL: https://api.example.com/v1, apiKey: env:MY_COMPANY_API_KEY }, models: { llm-3.5-turbo: { name: My Fast Model } } } } }这段配置我解释一下provider下面定义一个你自己命名的服务商npm字段指定调用方式如果你要接的服务是 OpenAI 兼容协议就用ai-sdk/openai-compatibleoptions.baseURL是服务地址的根路径apiKey建议写成env:变量名的形式而不是直接写密钥models下面列出可用的模型名。配置完这个文件后在 opencode 里通过/models命令就可以看到自定义模型切换过去就能用。这里有一个我踩过几次的坑很多 OpenAI 兼容服务在baseURL结尾要不要带/v1上很随意有的带、有的不带配错了会报 404 或 401。我建议第一次配完先用curl测试一下接口地址是否真的可用再交给 opencode能省很多排查时间。3.3 API Key 管理与环境变量在配置文件里写明文 API Key 是最糟糕的做法因为项目配置可能会被提交到 Git 仓库。正确姿势是配合环境变量export MY_COMPANY_API_KEYsk-xxxx然后在opencode.json里引用env:MY_COMPANY_API_KEY。这样你的配置文件可以公开密钥只在运行环境中存在。Windows 用户可以在系统环境变量里加也可以用 PowerShell 临时设置$env:MY_COMPANY_API_KEY sk-xxxxmacOS/Linux 用户建议写到~/.bashrc、~/.zshrc或.env文件里。注意opencode 读取环境变量是在启动时读的如果你改完环境变量需要重启 opencode 进程否则还是旧的 Key。还有一个小技巧如果你同时在用多个模型提供方可以在配置里给不同 Key 起不同的环境变量名然后在不同项目里引用不同的变量。这样项目 A 用公司模型项目 B 用个人模型互不干扰。3.4 聚合平台与订阅模型选择建议不少用户会问“opencode 用什么订阅模型好”我个人不推荐把精力花在追求某个免费模型上。免费模型往往意味着限流、排队、上下文窗口缩水偶尔用一下可以但如果你打算把 opencode 用到日常开发里稳定性和上下文长度比价格重要得多。如果是通过聚合平台或网关接入订阅模型选模型时盯三件事上下文窗口低于 32K 的模型跑复杂项目会频繁截断任务做到一半失忆很难受限流策略有些订阅套餐名义上便宜但每分钟请求次数极低一跑测试就持续报 429计费模式按 token 计费时一个大型重构任务可能烧掉几百万 token别只盯着单价还要提醒一句任何“订阅模型”是否可用取决于上游服务商而不是 opencode。所以如果某一天某个模型提示不可用第一反应应该是去服务商后台检查状态而不是去怀疑 opencode 坏了。opencode 的角色只是一个标准化的客户端它把所有模型拉到了同一条交互流程里。4. 在编辑器里使用 opencodeVS Code 与 IDEA 实战4.1 VS Code 插件安装与连接 CLI虽然 opencode 的核心是终端应用但它提供官方 VS Code 插件很适合需要同时看代码上下文和对话记录的场景。在 VS Code 扩展面板里搜索opencode安装后通常会在左侧侧边栏或者编辑器面板里出现一个对话框。这个插件本质上是个壳它在后台调用你已经安装好的 opencode CLI。所以插件装完不代表万事大吉你的终端必须能执行opencode命令。如果你的 VS Code 内嵌终端能正常使用 opencode但插件连接到一半报错最常见的原因是 VS Code 进程的环境变量和终端的环境变量不一致。特别是 macOS 上通过 Finder 启动的 VS Code 往往不加载 shell 配置文件导致插件找不到 CLI。解决方式是先关闭 VS Code用终端启动 VS Codecode .看看插件是否恢复正常如果还不行可以在插件设置里手动指定 opencode 可执行文件的路径。Windows 用户可以把上一节提到的 npm 全局路径直接填进去。4.2 IDEA 插件Java/Maven 项目的提示用 JetBrains IDEA 或者 IntelliJ 系 IDE 的人可以在插件市场里搜索 opencode 相关插件。这类插件的使用逻辑和 VS Code 版本类似也是连接本机 CLI。不过我现在要专门说一个场景就是你在 IDEA 里做 Java 或 Maven 多模块项目时opencode 的配置要比常规项目多一步。opencode 默认会根据目录结构猜测项目类型但 Maven 项目里很多 source 路径是约定大于配置的如果 Agent 找不到pom.xml或模块之间的依赖关系它改代码时很容易改错模块。我的经验是在项目根目录的.opencode/opencode.json里把 Maven 相关的命令写清楚或者直接通过 Skills 告诉它先读哪些文件、用什么命令构建。具体做法我放到下一节讲 Skills 时展开。至少有一点请你记住第一次在新项目里用 opencode 之前花两分钟把项目结构跟它说清楚比让它自己瞎猜省一小时。4.3 桌面版不想碰命令行的变通方案如果你实在抵抗命令行opencode 也有桌面应用形态。社区里常说的“opencode desktop”就是一个把 CLI 包装成独立桌面程序的方案适合那些需要 TUI 但又不喜欢终端样式的人。不过我对这种用法持保留态度。opencode 本身的 TUI 已经做得很克制桌面版更多是视觉上的容器底层还是要依赖命令行和本地配置。如果你完全不想碰命令行其实不适合用这类 Agent 工具——你至少需要能看懂环境变量和配置文件。桌面版可以作为团队的“演示模式”或者给非技术决策者展示用真正干活我建议你还是回到终端或 IDE 插件。5. 进阶玩法Skills、LSP、Playwright 与 Memory5.1 Skills把技能变成复制即用的流程定义Skills 是 opencode 里价值密度最高的功能也是我一直推荐团队一定要投入时间做的部分。它的概念很简单你给某个任务定义一个标准化流程保存为一个技能之后随时调用。比如你们团队有固定的代码规范、固定的发布流程、固定的排错套路都可以写成 Skill。有一次我在处理一个老项目的 Maven 报错时直接在对话里输入/skills选中自己定义的 Maven 排错技能它就会按照流程先读pom.xml、再跑编译、再收集报错信息、最后给出修复建议。整个过程不需要我一遍遍重复“请先看一下 pom 配置”。技能文件通常是一个目录里面放SKILL.md文件大概长这样--- name: maven-debug description: 当 Maven 构建失败时用该技能分析日志并修复 --- 1. 读取项目根目录的 pom.xml确认依赖与插件配置 2. 执行 mvn clean compile 收集完整报错信息 3. 根据错误定位到具体 module 或依赖 4. 给出修复建议并同步更新相关文件你可以在全局技能目录放通用技能也可以在项目.opencode/skills/目录放项目专属技能。团队协作时把技能文件放进 Git 仓库所有组员就能共享。社区里也有不少人分享了现成的技能集比如一些叫 superpowers 的技能集合里面打包了一堆实用的 Prompt 工程技巧可以 clone 下来参考。我的建议是先用社区的开胃菜然后开始沉淀自己的菜单。5.2 LSP让 Agent 真正“理解”你的代码LSPLanguage Server Protocol原本是给编辑器提供代码跳转、补全、诊断用的协议。opencode 这类 Agent 工具接入 LSP 之后就能获得代码库的语义信息比如某个函数的定义在哪、哪些地方调用了它、当前文件有什么语法错误。如果没有 LSPAgent 基本只能靠纯文本搜索来找代码遇到重构场景会非常痛苦。它可能看见一个方法名匹配就以为找到了正确位置实际上可能有同名重载、不同包路径等问题。接入 LSP 后Agent 可以像 IDE 一样精确地知道符号之间的关系。实际配置时你通常不需要手动写太多东西opencode 会根据项目语言自动尝试启动对应的 LSP。如果你发现 Agent 的行为明显“两眼一抹黑”建议先确认语言服务器是否已安装比如 TypeScript 项目需要typescriptJava 项目需要 JDK 自带的 language server 支持项目是否有完整的依赖比如 Maven 项目先跑一次mvn dependency:resolve是否在.opencode配置里显式指定了 LSP 的命令参数这一块是 opencode 和普通聊天式 AI 工具拉开差距的关键能力。同样的模型有 LSP 和没有 LSP在大型项目里的表现完全两个级别。5.3 Playwright让 Agent 自己打开浏览器查 Bug如果你是前端开发者热词里那个“opencode playwright 怎么测试前端 bug”我太熟悉了。opencode 可以集成 Playwright让 Agent 在浏览器里主动复现问题而不是靠肉眼盯代码猜 bug。典型场景是这样的你发现登录页在某种情况下会白屏。传统方式是你自己打开 DevTools、复现、打断点、看网络请求。用 opencode 时你可以要求它“用 Playwright 打开本地登录页输入测试账号点击登录然后把控制台报错抓给我”。Agent 会启动一个浏览器实例一步一步执行操作并把实际观察到的页面状态和报错信息拉回到对话里。配置时你只需要在项目里安装好 Playwright并且在给 opencode 的任务描述里明确告诉它“用 Playwright 验证”。它通常会自动生成临时的脚本去跑。这里有个技巧让 Agent 写 Playwright 脚本时明确指定要等待的标签、需要断言的元素避免脚本因为页面加载慢而误判。真实项目里元素加载问题是最常见的坑加上等待逻辑能大幅减少噪音。5.4 Memory让 Agent 记住项目偏好Memory 功能解决的是“失忆”问题。你在开发一个项目时可能会反复强调“不要改公共组件”“测试用例放在 resources 目录下”“提交信息用 conventional commit 格式”这些偏好。如果每个新会话都要重新交代一遍效率会很低。opencode 的 Memory 就是把这类偏好存下来后续会话自动加载。你可以在 TUI 里通过/memory命令添加记录也可以直接编辑对应的 markdown 文件。我一般会在每个项目的初始化阶段就用 Memory 把技术栈、目录结构、常用命令、编码规范写进去。之后不管谁在这个项目里开新会话Agent 都能第一时间知道项目背景。这里建议区分使用全局 Memory 放你自己的通用习惯项目 Memory 放这个仓库的专属规则。不要把全局 Memory 塞太满否则 Agent 在无关项目里也会受到干扰。Memory 这种功能是典型“设置时麻烦十分钟使用后舒服一整年”。6. 真实项目实战用 opencode 接手 Maven 多模块项目6.1 首轮对话怎么问信息密度最高接手一个陌生项目特别是老旧的 Java 多模块项目很多人上来就直接说“帮我看下这个项目”然后抱怨 opencode 的回复不够准确。其实问题往往出在提问方式上。我自己的首发 Bao 文先让 opencode 做一次项目扫描。请先不要修改任何文件。通读整个项目告诉我 1. 顶层模块划分和依赖关系 2. 每个模块的核心职责 3. 项目使用的 Java 版本、构建命令、测试命令 4. 潜在的构建配置问题这个指令的核心是“先只读不改写”。等 Agent 给出项目全景你再提具体需求。这样它的后续操作会精准很多。不要一开始就让它改代码在一个它还不了解的项目里贸然动代码大概率会车毁人亡。6.2 无头模式用 opencode run 做自动化opencode 不只是交互式 TUI它还支持无头模式也就是直接在命令行里运行一条 prompt 然后退出适合写进 CI 脚本或者本地自动化任务。命令形态大概是opencode run 修复 src/main/java 下所有未使用的 import 并运行 mvn test无头模式的场景非常广。我经常用它来处理“批量替换”“统一重构”“自动生成单元测试”这类任务。它可以直接在 shell 脚本里被调用输入任务输出结果不需要你一直守在终端前。但要注意无头模式不会像交互模式那样等你确认每步操作。所以任务描述里要尽可能明确边界比如“只修改 src/main/java不碰测试代码”“修改完运行测试并给出结果摘要”。这样能减少误伤。6.3 用 Skill 固化 Maven 排错流程回到前面提过的 Maven 排错。我经历过的真实情况是项目构建失败的时候报错信息往往铺天盖地真正造成失败的原因可能隐藏在三分之一的地方。人工排查时大家习惯先看第一行异常但 Maven 的很多错误是传递性的真正的根因得继续往下翻。我因此写了一个maven-debugSkill流程是这样的读取项目pom.xml确认 parent、dependency、plugin 配置执行mvn clean verify -DskipTests compile获取完整日志提取日志里的 ERROR 和 BUILD FAILURE 段落而不是只看第一行根据异常类型分类处理依赖冲突跑mvn dependency:tree分析并给出排除建议编译错误定位到源码文件和具体行插件缺失或版本问题检查本地仓库与镜像源配置修改后再次执行构建直到成功把这个流程固化成 Skill 后open code 处理 Maven 问题的能力明显上了一个台阶。它不再是泛泛地“读报错猜原因”而是有一套完整的诊断路径一步一步收敛问题。这也是我认为 Skills 最重要的价值把专业人士的排错思路复制给 AI。6.4 配置文件切换ccswitch 这类工具帮了什么忙当你的项目比较多还各自用了不同的模型提供方时切换 API Key 和 baseURL 会变成一个麻烦事。社区里有人写了 ccswitch 这类配置切换小工具本质上是快速改写 opencode 配置文件让不同项目或不同任务能快速使用不同服务商配置。如果你是这种情况我建议先手工把配置结构理清楚确保你的opencode.json本身是模块化、可维护的再考虑用这类工具。执行顺序是先确认手动能切通再用工具简化重复操作。否则工具反而会成为黑盒出了问题你更难排查。另外如果你把 opencode 接在某个聚合网关后面需要明白一件事这类网关通常暴露的是 OpenAI 兼容接口你真正关心的不是它叫什么名字而是它的 baseURL、apiKey、模型名是否填对。很多人在这一步翻车不是 opencode 的问题而是服务商给的请求地址没看清楚。7. 常见报错排查这些问题 90% 的人都会遇到7.1 opencode 无法识别这是安装环节出现频率最高的问题对应错误信息是opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名我看到不少用户是在c:\windows\system32这个默认目录下直接执行 opencode 的。即便 PATH 配好了有些终端在管理权限下也可能出现环境变量没有继承完整的情况。解决路径前面已经说过了这里只需要再补一条装完任何 CLI 工具如果不想折腾 PATH最省事的方法是直接重启一次电脑再打开终端。不是玄学是环境变量刷新的最彻底方式。报错场景常见原因解决方式提示不是内部或外部命令PATH 里没有 opencode 所在目录找到可执行文件路径加入 PATHCMD 能跑但 PowerShell 不认两个终端的环境变量不同步在系统环境变量里配置不要只在单个终端里临时设置VS Code 插件连不上 CLIVS Code 进程没有加载最新 PATH从终端启动 VS Code或者在插件设置里指定 CLI 路径7.2 unexpected server error 排查opencode error: unexpected server error. check server logs这类报错通常不是 opencode 本身的问题而是它请求模型服务时服务端返回了异常。排查思路按顺序来先确认 API Key 还有效额度没有耗尽确认 baseURL 填的是否正确特别是结尾路径确认你选的模型是否存在模型名是否写错用 curl 直接模拟同样的请求看看服务端返回什么如果直接请求正常但 opencode 里一直报错再看配置文件的 JSON 格式是否正确。尤其注意多了一个逗号、引号不匹配这类低级错误。opencode 的日志目录一般在系统用户目录下macOS 可以在~/Library/Application Support/opencode/log找Linux 在~/.local/share/opencode/log。查日志时重点看请求发出的地址和响应状态码比瞎猜快得多。7.3 model is not available in your country这个错误是模型提供方根据地区限制返回的不是 opencode 能决定的。它通常意味着你请求的模型服务在你当前所在地区没有被授权。遇到这个提示我的建议顺序是换一个模型试试判断是不是所有模型都不可用去服务商后台查看该模型的支持地区联系服务商客服确认企业授权或区域放行策略不要试图用任何非常规手段绕过这种限制也不要轻信“免费模型到处能上”的说法。这类区域限制主要是模型服务商做合规和分发控制用户层面能做的主要是选择合适的模型和合规渠道。我的立场一直很明确工具是拿来提效的不要在合规风险上给自己找麻烦。7.4 其他容易忽略的小问题第一是版本问题。opencode 更新速度非常快API 有时会变。如果你发现某个功能在文档里有但本地怎么都出不来先检查版本是不是太旧。第二是代理冲突。这里我说的是系统层面的网络访问策略——如果你的开发环境配了 HTTP 代理而 opencode 请求的 API 域名走了代理会导致握手失败或证书错误。遇到网络类报错先临时关闭系统代理或者确认该域名是否被代理规则正确放行。第三是并发冲突。不要同时在一个项目里开多个 opencode 会话让它们改代码它们之间没有锁机制很容易互相覆盖。我的习惯是一个项目同时只开一个会话需要并行任务时用无头模式并确保任务范围不重叠。8. 与 Claude Code、Codex、Pi 怎么选一张表讲清楚8.1 工具横向对比open code 不是唯一一个 CLI Agent 工具现在社区里还常见 Claude Code、Codex 以及一些更轻量的 Pi 类工具。选型这个问题没有标准答案我把它整理成表格方便你对照自己的场景维度opencodeClaude CodeCodexPi 类轻量工具交互形态TUI、IDE 插件、桌面版终端 TUIOpenAI 官方 CLI终端 TUI模型绑定灵活支持多种 provider主要围绕 Claude 模型主要围绕 OpenAI 模型取决于具体实现通常也比较灵活配置方式opencode.json 文件化配置配置项较多生态深CLI 参数配置相对简单通常极简可扩展性Skills、自定义 provider、LSP 插件Agents 与 Skills 能力成熟偏代码生成与语义理解偏轻量任务扩展性一般上手成本中等需要配置模型低官方支持好低开箱即用低适合试水适合谁喜欢完全掌控、团队需要共享配置的人Claude 生态深度用户OpenAI 生态用户、快速验证想法的人想体验 Agent 但不想折腾的人我对 Pi 类工具了解不算特别深因为它们迭代也很快但核心体验是“轻”。如果你只是想跑一个快速实验不希望为了配置文件折腾 20 分钟那它可以当做一个快速入口。但如果要真正承接项目级别的重构任务我认为 opencode 和 Claude Code 这样的成熟工具更靠谱。8.2 我的选型建议说句掏心窝的话不要一上来就问“哪个最好”要问“哪个最适合我现在的约束条件”。如果你的公司已经在用 OpenAI 全家桶那 Codex 可能天然顺手如果你重度依赖 Anthropic 模型的编程能力Claude Code 是正路如果你像我一样需要在多个模型、多个项目之间来回切换也希望配置能提交进 Git 仓库让团队复用那 opencode 的开放性就是最大优势。我现在的日常是opencode 作为主入口通过配置文件在不同项目里走不同模型。比如内部项目走公司自建的 OpenAI 兼容服务开源小项目走 Anthropic 模型前端调试时用 Playwright Skill 让它在浏览器里自己验证效果。这套方式用下来最大的感受是“不容易被某个模型绑架”。即便哪天某个模型服务变贵了或下线了只需要改配置换一个模型整套工作流不用动。最后再分享一个我个人的使用习惯不管是哪个 Agent 工具我都坚持“确认过再写入”的原则。让 AI 先给方案我再 review而不是直接让它放手改。这不是对 AI 不信任而是对自己的代码库负责。OpenCode 这类工具的能力边界每天在扩展但你自己的判断力永远是最后一道防线。
