opencode：开源终端AI编程助手从安装到进阶的完全指南

1. opencode 到底是什么一个终端 AI 编程助手为什么能火起来过去这一年终端里的 AI 编程助手赛道挤满了玩家。Anthropic 的 Claude Code 是闭源标杆OpenAI 的 Codex 背靠 ChatGPT 生态Google 也有自己的方案但社区里讨论度最高、GitHub 星标涨得最猛的开源选择却是 opencode 这个从 Serverless 圈子跨界杀出来的项目。它被很多人称为 Claude Code 的开源替代品但实际用下来它的定位比替代品这三个字要大得多。opencode 是一家叫 SST 的公司之前做 Serverless Stack 框架那个团队发起的开源项目MIT 协议核心代码以 TypeScript 和 Go 为主。它在终端里跑一个全交互式的 TUI 界面可以读取你的项目文件、搜索代码、执行命令、调用模型完成多步任务而且所有数据和配置都存在本地。相比 Claude Code 闭源、依赖特定账号体系的玩法opencode 对模型供应商没有绑定你可以把 Anthropic、OpenAI、DeepSeek、Ollama 本地模型、OpenRouter 上的各种免费模型全接到同一个界面里来。它适合谁我总结下来是三类人一是受够了在 IDE、浏览器、终端三个窗口之间来回切换想要一个统一的编码交互入口的开发者二是对 Claude Code 这类闭源工具的数据流向不放心想保留所有上下文都在本地的人三是喜欢折腾——愿意自己定义 skills、写自定义命令、把 AI 塞进自己全流程里的人。如果你只是偶尔让 AI 解释一段代码那它对你可能有点重但如果你想让 AI 真正参与写代码、改 bug、跑测试那 opencode 值得认真看看。1.1 它和 Claude Code 的渊源不只是一片替代品很多人第一次听说 opencode是因为这不是开源的 Claude Code 吗这句话。这种说法有一定道理但不全对。Claude Code 火起来之后Anthropic 并没有开放核心实现大家只能隔着 API 用它。于是开源社区开始出现各种兼容 Claude Code 工作流的项目opencode 是其中完成度最高的一个。它借鉴了 Claude Code 的那套交互范式你在终端里描述任务agent 自己拆步骤、读文件、改代码、执行命令、给结果。但它不是仿一个壳而是在架构上做了自己的取舍——模型层是可插拔的配置是本地纯文本的平台绑定完全去掉。这意味着什么意味着你可以在 opencode 里用 Anthropic 的模型也可以切到别家。甚至可以本地跑一个量化模型网线拔了照样干活。这种自由度是 Claude Code 给不了的也是它能在社区里这么快扩散的最根本原因。1.2 opencode 最值钱的设计数据在本地、行为可定制用了一段时间之后我越来越觉得 opencode 最有价值的不是 TUI 界面多好看而是两点数据在本地行为可定制。所谓数据在本地指的是它的会话记录、配置、缓存都放在~/.local/share/opencode和~/.config/opencode这类本地目录里。项目里也有像AGENTS.md这样的纯文本说明文件来给模型提供上下文。整个系统没有账号体系没有云端强迫同步你在命令行里干了什么只有你的机器知道。行为可定制这一点更关键。它有一套 skills 机制你可以给模型预置各种专项指令让它面对某类任务时自动带上一整套工作流。这有点像把prompt 工程做成了文件系统里可管理的资产。再加上社区里已经有 oh-my-claudecode、superpowers 这类现成的技能包可以一键安装opencode 的实际能力边界早就超出了命令行问答工具的范畴。2. 从零装好 opencode安装方式与两条高频报错的根因聊完定位直接进实操环节。这一章我只讲两件事怎么把一个能用的 opencode 跑起来以及安装过程中最高频遇到的两类报错到底是什么原因、怎么处理。这几条可以说是社区提问区里重复率最高的内容值得单独拎出来说透。2.1 安装链路npm 包名和 PATH 是最大的坑官方推荐的安装方式有几种我按实际体验排序给你。# 方式一npm 全局安装最常见 npm install -g opencode-ai # 方式二HomebrewmacOS / Linux brew install sst/tap/opencode # 方式三curl 脚本安装 curl -fsSL https://opencode.ai/install | bash这里的第一个坑是包名。npm install -g opencode是装不到的因为opencode这个包名早就被一个远古时代的无关项目占了真正要装的是opencode-ai。很多刚上手的人在这里就直接卡住了明明跑了命令却说找不到包。第二个坑是原生安装方式走 GitHub Releases 下载二进制如果你所在网络访问 GitHub 不稳定curl 安装脚本大概率会卡在下载那一步不动也不报错就是等。所以我在国内网络环境下的建议是能用 npm 就用 npmnpm 有镜像源加速成功率最高。如果公司没有开 npm 镜像那就先把 registry 指到公共镜像再装npm config set registry https://registry.npmmirror.com npm install -g opencode-ai装完之后验证版本opencode --version如果这一步能正常输出版本号恭喜你最难的环节已经过去了。2.2 Windows 下无法识别 cmdlet的完整排查这条报错几乎是 Windows 用户必经的一关原文是opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。 请检查名称的拼写如果包括路径请确保路径正确然后再试一次。看到这行字绝大多数人的第一反应是是不是没装上。但绝大多数情况下opencode 已经装好了是 PowerShell 找不到它。背后的原理很简单npm 全局安装的带命令行的包本质是往一个全局 bin 目录里丢一个可执行文件或软链系统在执行命令时只会去 PATH 环境变量里列出的目录中找。当这个全局 bin 目录不在 PATH 里系统就完全不认识这个名字。解决方法是先查到 npm 的全局 bin 路径再把它加进用户级 PATH一句话概括就是告诉系统去哪找。npm config get prefix拿到结果后把结果下的某个子目录加进 PATH。npm 在 Windows 上的全局可执行文件通常放在%APPDATA%\npm也就是C:\Users\你的用户名\AppData\Roaming\npm这个目录同时是 npm 全局 bin 目录和缓存的所在位置。# 在 PowerShell 里以当前用户身份添加 PATH [Environment]::SetEnvironmentVariable( Path, [Environment]::GetEnvironmentVariable(Path, User) ;%APPDATA%\npm, User )执行完这个命令后重新打开 PowerShell再跑opencode --version就能识别了。注意如果你电脑上同时装了 nvm-windows并且用 nvm 切换过多个 Node 版本PATH 里可能已经有一条指向某个 Node 版本目录的 npm 全局路径。此时npm config get prefix返回的目录可能会随当前 Node 版本变化。建议把用户级 PATH 里的 npm 全局路径统一指向同一个固定位置避免切换 Node 版本后 opencode 又消失。这是我在换版本时亲身踩过的坑。2.3 unexpected server error升级后最常见的翻车现场装好了、能启动了下一个高频报错长这样opencode error: unexpected server error. check server logs这句报错翻译过来是服务端发生意外错误请查看服务日志但它根本没有告诉你日志在哪。很多人第一次遇到就直接懵了。根据我对这个项目长期的跟踪和社区反馈的观察这个报错在 2.0 之后出现频率最高。因为 opencode 2.0 把架构从单进程模型改成了 client-server 模型你在终端里敲命令起的是一个客户端它背后连着一个本地 server 进程server 负责跟模型 API、文件系统、工具调用打交道。升级版本时本地旧版本的缓存数据和状态文件可能与新版本二进制不兼容server 进程一启动就崩客户端就报 unexpected server error。处理的完整链路是这样的先退出 opencode按几次q或直接 CtrlC确认 TUI 进程已结束。清理本地缓存文件夹先备份再删别手一抖全没了# Linux / macOS cp -r ~/.local/share/opencode ~/.local/share/opencode.bak rm -rf ~/.local/share/opencode # Windows Copy-Item -Recurse $env:USERPROFILE\.local\share\opencode $env:USERPROFILE\.local\share\opencode.bak Remove-Item -Recurse $env:USERPROFILE\.local\share\opencode确认没有残留 server 进程# 查看是否还有 opencode 相关进程在跑 ps aux | grep opencode如果有直接 kill 掉。Windows 下可以用任务管理器或者 PowerShell 里执行Get-Process | Where-Object { $_.Name -like *opencode* }找到后 Stop-Process。重新运行opencode这次会以全新状态启动 server配置和模型信息会重新初始化。这个操作我至少做过五六次了每次都是升级之后遇到问题清完就好。另外一个心得是opencode 的自动升级是异步的它会在后台拉新版然后提示你重启。如果你刚好在旧版本还开着、新版本已经拉到一半的时候重启了终端也容易出现异常。所以看到升级提示后最好是干净退出全部 opencode 相关进程再重新打开不要带着 session 原地刷新。3. 模型接入免费模型、CC Switch 和环境变量是怎么配合的opencode 装上只是第一步真正发挥价值的是把模型接好。这一章是全网提问率最高的模块尤其是opencode 能用什么模型怎么配免费模型这类问题社区里快问烂了。3.1 理解 opencode 的 provider 配置模型opencode 的模型接入逻辑并不复杂它本质上是一个支持多 provider 的客户端你只需要在配置文件里写清楚每个 provider 的 API 地址、模型名、Key然后在 TUI 里用/models切换。配置文件在~/.config/opencode/opencode.jsonLinux/macOS或%USERPROFILE%\.config\opencode\opencode.jsonWindows。下面是一个同时配置了 Anthropic 正式 API、OpenAI 兼容接口和本地 Ollama 的最小示例{ $schema: https://opencode.ai/config.json, provider: { anthropic: { npm: ai-sdk/anthropic, name: Anthropic, options: { apiKey: sk-ant-xxxx }, models: { claude-sonnet-4-20250514: { name: Claude Sonnet 4 } } }, my-plugin: { npm: ai-sdk/openai-compatible, name: 自定义 OpenAI 兼容服务, options: { baseURL: https://你的服务地址/v1, apiKey: 你的key }, models: { deepseek-chat: { name: DeepSeek Chat } } }, ollama: { npm: ai-sdk/ollama, name: Ollama, options: { baseURL: http://localhost:11434/api }, models: { qwen2.5-coder:7b: { name: Qwen 2.5 Coder 7B } } } } }看到这里你应该明白了所谓能不能用某某模型取决于你手头有没有能跑到通的 API 地址和 Key。只要有 OpenAI 兼容协议的地址理论上什么模型都能塞进来——包括 DeepSeek、智谱 GLM、Moonshot 这些国内模型服务也包括各种经过网关转换的模型服务。3.2 CC Switch 联动为什么大家都在用第三方的配置切换工具搜索热词里有一组很有意思的搭配opencode go 需要配合 cc switch 等工具。CC Switch 是一个社区做的配置 Profile 切换工具最初是给 Claude Code 用户切换不同 API 供应商用的。为什么 opencode 玩家也用得上它原因很简单opencode 对 Claude Code 的很多环境变量是兼容的。它读ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN/ANTHROPIC_API_KEY这一套环境变量。CC Switch 的本质就是把这些环境变量按 Profile 管理起来一键切换。你平时可能给 opencode 配好了一组走 Anthropic 官方地址、一组走某个中转地址、一组走公司内部模型网关。直接改命令行环境变量既容易串又不直观所以大家借 CC Switch 来做这件事。用法也很直白在 CC Switch 里创建一个新 Profile填上你的 BASE URL 和 Key然后把 Switch 的写入位置配置为同时写入.env或 shell profile终端里新打开的 opencode 就会自动读到新环境变量。唯一的注意点是CC Switch 切换的是环境变量而 opencode 如果在运行时读取了环境变量切换后重启 opencode 才生效。别切换完了直接在原 session 里敲命令那还是旧配置。3.3 免费模型的实测hy3-free 这类免费模型能撑起日常开发吗opencode hy3-free 下线了吗这个话题最近在社区里讨论度不低。hy3-free 是社区里一个服务商提供的免费模型入口很多人拿它配合 opencode 用不花一分钱就能体验完整的 agent 工作流。我自己也试过一段时间说几句大实话。免费中转模型的可用性确实是薛定谔状态。高峰期经常速度掉到没法看偶尔还直接报错返回 5xx或者改了请求格式不兼容导致 opencode 以为模型崩了。所以如果你把它当主力开发工具那体验是堪忧的——刚开始干活就转圈等两分钟出一个半截答案那滋味非常酸爽。但它做两件事非常合适一是入门体验没开 API 账号之前先用它跑通 opencode 的整个链路知道 TUI、skills、文件读写这些功能用起来是什么感觉二是批量跑一些不敏感的小任务比如让它给 README 补章节、批量生成单元测试注释、整理 TODO 清单这种任务慢就慢点不影响心情。我的建议是把免费模型当试用装主力工作还是接稳定的付费 API 或者跑本地模型。如果本地显卡能跑得动 Qwen 2.5 Coder 7B 或者 14B 这种尺寸接 Ollama 做日常编码辅助也完全够用。免费服务的稳定性天然就没有保障这跟工具本身无关别把模型不稳定误当成opencode 不好用。4. 把 opencode 搬进 IDEVSCode 与 JetBrains 插件实测终端 TUI 虽然帅气但在绝大多数人的日常开发流程里IDE 还是绕不开的主战场。这也是 opencode 插件、桌面版这类话题热度一直居高不下的原因。我自己在 VSCode 和 JetBrains 里都深度用过 opencode 的官方插件把真实体验摊开来讲。4.1 VSCode 插件轻量但够用VSCode 的 opencode 插件本质上是把 opencode 的 server 能力嵌进了编辑器侧边栏。你不需要在终端和 IDE 之间来回切换直接在 VSCode 里打开一个面板选中一段代码问它这段逻辑有什么问题它会把答案输出在编辑器右侧还能直接预览 diff、一键替换代码块。用下来我觉得它的优势场景是看代码 改代码的联动。终端 TUI 里你把代码改完之后还得自己回到编辑器和测试之间来回切VSCode 插件里agent 改完代码diff 直接出现在编辑器里哪个文件动了什么一目了然。尤其适合前端项目里那种一个 bug 牵连好几个组件的场景改动链路人眼可查。缺点也有面板里的交互深度明显不如 TUI多步任务跑久了会发现插件端对长流程的控制力弱一些。我的用法是简单交互靠 IDE 插件复杂多步任务回终端开 TUI。4.2 JetBrains IDEA 插件解决终端 TUI 和 IDE 之间的割裂感JetBrains 系IDEA、PyCharm、GoLand 等的 opencode 插件解决的问题和 VSCode 插件类似但体验上更贴合 JetBrains 的习惯。以 IDEA 为例安装插件后在右侧工具窗口能找到 opencode 面板。它跟终端里的 opencode 共享同一套 server 和配置——也就是说你在终端里积累的 skills、custom commands、模型配置在 IDEA 插件里直接复用。这对同时用多个 JetBrains IDE 的人来说特别友好模型配置只需要维护一份。实际体验上JetBrains 插件在生成代码插入到编辑器时比我预想中要顺滑代码风格也能贴合项目的既有习惯。唯一让我不太满意的是长对话场景下插件面板的内存占用会逐渐升高。如果你一个 opencode 对话窗口开了两三个小时期间反复让 agent 分析大文件最好时不时把服务重启一下或者直接新建一个会话窗口别硬撑。4.3 配合 Playwright 测前端 Bug 的思路热搜词里有一条opencode playwright 怎么测试前端bug这其实是个非常实用的场景值得展开说说。常规开发流程里前端 bug 的复现和验证是最费时间的一步。你让 opencode 修一个 bug它改完代码你还要手动打开浏览器、点几下、看 Console、截图、确认问题没了。一来一回bot 的效率优势就被这个手动环节稀释了。Playwright 正好补上了这个环节它可以在代码层面驱动浏览器自动打开页面、触发交互、收集报错、截图。实际操作上你不需要手动写 Playwright 脚本——直接在 opencode 里告诉它用 Playwright 复现这个问题然后验证修复是否生效。大部分情况下 opencode 会自己决定写脚本、跑测试、把结果贴回来。你需要做的事是确保项目里已经装好了 Playwrightnpm install -D playwright/test npx playwright install chromium然后在 opencode 里给它自由调用npx playwright test的权限。如果你不希望它每次执行命令都弹确认可以调整授权配置设置对npx playwright这一条命令自动放行。实测中有一个经验越是点击几下会出现偶发 bug的问题越要让 opencode 把复现步骤写成 Playwright 测试脚本多跑几遍。它不会嫌烦也不会手速失控那些小概率触发的 bug 在重复执行下反而更容易暴露。这种AI 改代码 E2E 自动验证的组合算是 opencode 最有生产力的玩法之一。5. Skills 机制为什么 opencode 能被社区玩出花如果你只用 opencode 做问答和改代码那大概只发挥了三成功力。真正让这个工具拉开档次的是 Skills 机制。很多热词都指向它opencode skills、opencode oh-my-claudecode、opencode 安装 superpowers。这一章我系统地讲清楚 Skill 到底是什么、现成的技能包怎么装、以及自己写一个 Skill 的完整步骤。5.1 Skill 到底是什么从 oh-my-claudecode 说起先给一个最通俗的类比Skill 就是给 AI 的岗位说明书。你平时让 AI 干活需要把任务描述清楚但很多时候不是任务不清楚而是 AI 缺少做这类任务的标准流程。比如你让它写一个单元测试一个没经验的开发者可能直接生成十个测试用例就交差了但如果它是一个懂行的工程师会先读被测文件的依赖、找出边界条件、再按项目现有测试框架的风格来写。Skill 干的就是这件事把懂行的工程师的思维方式预置给模型。oh-my-claudecode这个名字一听就是在致敬oh-my-zsh。它是一个社区整理的 Claude Code 技能和提示词集合把日常开发里高频出现的任务类型都做成了可复用的 skill——解释代码、生成 commit message、写文档、做代码审查、拆解技术方案。opencode 的 skill 格式与 Claude Code 的 agent/command 体系高度兼容所以 oh-my-claudecode 这套东西可以直接被 opencode 用这也是它出现在 opencode 热词里的原因。5.2 安装 superpowers给 opencode 装上外挂superpowers 是另一个社区技能包创始人是一位前 Google 工程师这套技能包在设计上比 oh-my-claudecode 更强调结构化问题解决。它的思路不是给你一堆花哨指令而是把软件工程的经典工作流比如先写测试再写实现、先画系统边界再落代码沉淀成 skill让模型在动手之前先过一遍完整思考链。在 opencode 里安装这套技能包很简单。opencode 的 skill 目录在这里全局技能目录~/.config/opencode/agentLinux/macOS或%USERPROFILE%\.config\opencode\agentWindows项目级技能目录项目根目录下的.opencode/agent或.agent把 superpowers 仓库里的 skill 文件夹复制到全局技能目录里重启 opencode然后在对话里输入/就能看到新的命令列表。如果你用的是 opencode 2.0 以上的版本还支持直接把仓库 fork 一份到本地然后通过ln -s做成软链方便后续拉更新。装完之后最大的变化是模型回答问题前会主动走理解需求 - 拆分步骤 - 明确验证方式这一套流程。同样一个问题在默认 prompt 和装了 superpowers 之后输出的质量差别肉眼可见。注意skill 不是越多越好。每装一个新的 skill模型在每次请求时都会把对应的指令文本塞进上下文占用 token。装了一堆用不上的技能会白白增加请求时长和费用。我建议先不装跑通基础知识后再按需添加两三个高频场景就够。5.3 自己写一个 Skill 的完整步骤自己动手写 skill 其实比很多人想象中简单。所谓 skill本质上是一个带SKILL.md的目录。opencode 在应对某个 skill 触发时会读取这个文件里的内容。下面用一个我实际场景中的code review skill 举例。第一步建目录mkdir -p ~/.config/opencode/agent/code-review第二步在目录里写SKILL.md--- name: code-review description: 对指定代码变更进行代码审查输出问题清单和修改建议 --- # Code Review 流程 当用户要求进行代码审查时按以下步骤执行 1. 收集上下文读取相关文件和最近 git diff 2. 检查重点 - 安全性是否存在注入、越权、敏感信息泄露风险 - 性能是否存在明显 O(n^2) 算法、重复请求、内存泄漏风险 - 可维护性命名是否清晰、函数是否过长、是否缺少边界处理 3. 输出结构 - 问题严重级别P0 阻断 / P1 严重 / P2 建议 - 每个问题给出文件路径、行号范围、问题描述、修改建议 4. 语言使用中文输出第三步重启 opencode在对话里输入/code-review模型就会加载这个 skill 并按定义好的流程去执行。你可能会问这不就是写了个 prompt 吗没错本质上它就是在管理 prompt。但它的价值在于你可以把每次临时起意、反复试出来的高质量指令沉淀成文件让团队里每个人都能复用同一套标准。这种自己的方法论逐步资产化的过程才是 opencode 玩到后期最有意思的地方。6. 进阶配置Memory、项目级上下文与团队协作opencode 用得越久越会意识到上下文管理比模型选择更影响体验。同样是接同一个模型有人用起来感觉是懂项目的老手有人用起来感觉是个刚入职的实习生差异就在上下文怎么管理。6.1 AGENTS.md给 opencode 写项目说明书opencode 读取项目上下文的机制和 Claude Code 类似核心就是AGENTS.md。这个文件放在项目根目录作用是给 AI 一份项目说明书让它每一次进入项目时自动读取理解项目背景、代码结构、常用命令和约定。一个比较完整的 AGENTS.md 长这样# 项目说明书 ## 项目简介 这是一个面向企业客户的 B2B 订单管理系统前端 React TypeScript后端 Node.js PostgreSQL。 ## 常用命令 - pnpm dev 启动开发环境 - pnpm test 运行单元测试 - pnpm build 构建生产包 ## 代码结构 - src/pages 页面组件 - src/api 接口调用层 - src/components 公共组件 ## 约定 - 所有接口返回统一使用 { code, message, data } 格式 - 组件统一用函数式写法 hooks - 数据库查询必须走 Prisma禁止裸 SQL ## 注意事项 - 改动数据库 schema 后必须跑 pnpm prisma generate - 部署环境不支持 Node 18 以下版本写完这个文件后你每次让 opencode 干活它都能自动带着项目上下文去看问题命中率提升非常明显。很多人说AI 不懂我的项目其实不是模型不行是你连项目说明书都没给它。6.2 全局 Memory 和跨会话记忆的取舍除项目级的AGENTS.md之外opencode 还支持全局级别的记忆配置。热词里的opencode memory指的就是这个机制。它允许你把一些不管在哪个项目里都适用的偏好写进全局配置文件这样每次会话都会带上。全局记忆适合放什么适合放你的个人代码风格和工具偏好比如注释用中文还是英文、缩进用 2 空格还是 4 空格、默认的 commit message 格式是什么、对第三方依赖的态度是宁缺毋滥还是能用就行。这些偏好跟具体项目无关放在全局最合理。但这里有一个性能上的取舍全局记忆和项目级说明都会被塞进每次请求的上下文里拖得越长每次请求处理的 token 就越多模型响应越慢、越费钱。实际使用中我强烈建议全局记忆文件控制在 50 行以内项目级AGENTS.md控制在 100 行左右只放会反复用到的关键信息。那些一次性任务说明直接在对话里描述就行别都沉淀成永久记忆否则上下文会越堆越臃肿。6.3 接手老项目时用 opencode 理清代码的路径很多人在热词里搜opencode 接手开发项目这其实是一个被低估的使用场景。我最近接手过一个维护了四五年、文档几乎为零的旧服务opencode 帮我省了大量读代码的时间。我的路径是这样的第一步先让 opencode 读一遍项目根目录让它输出整体结构、入口文件、路由和核心模块的关系图第二步把入口文件丢给它让它用通俗语言讲清请求从进入服务到返回响应的完整链路第三步挑一个具体功能比如某个订单状态流转问它对应的代码路径再让它按调用层级整理出来。做完这三步一个陌生项目的骨架基本就搭起来了。再往后我会把整理出来的结论回写到AGENTS.md里让后续所有会话都能复用。这样跟 opencode 配合的第五天看不懂老项目这个焦虑就明显减轻了。它未必能完全替代你逐行读代码但绝对能帮你把从零到上手的时间压缩一大截。7. 和其他终端 Agent 横向对比opencode、Codex、Claude Code、pi 怎么选最后来聊一个避不开的话题市面上这么多个终端 AI agent——opencode、Codex、Claude Code、pi——到底选哪个这组对比不仅是热词里反复出现的也是我几乎每周都会被线下朋友问到的问题。7.1 四个工具的一次平行评测对比维度opencodeClaude CodeCodexpi开源情况开源MIT闭源闭源开源模型绑定可自由接入多模型主要走 Anthropic主要走 OpenAI可配置多模型本地数据完全本地本地为主云端为主本地为主技能扩展支持社区生态丰富支持官方和社区都有有限有限IDE 集成VSCode / JetBrains / 桌面版官方插件OpenAI 相关生态较弱上手难度中等需要配置低装了能用低账号即用低适合人群爱折腾、要自由度的开发者想省心、重度 Claude 用户重度 ChatGPT/OpenAI 用户想快速体验的人从表里能看出来opencode 的核心竞争力在于自由和生态。它的模型无关、数据本地、配置开放配合社区 skills 能做很多定制化的工作流。Claude Code 的优势是体验和效果毕竟 Claude 模型的代码能力在多数场景下确实是第一梯队而且你不用花时间配置装上就能用。Codex 的优势是深度绑定 OpenAI 生态如果你日常重度使用 ChatGPT 订阅、对 Codex 云端任务的流程度要求高自然选它。pi 则更像一个轻量级选手适合简单场景快速尝鲜。7.2 我的最终选择与原因我个人的最终选择是主力场景用 opencode重度对话和模型效果对比时会打开 Claude Code 作为辅助。原因有几个。一是 opencode 让我能把自己手上的多个模型通道统一在一个界面下管理不用为了用不同模型去装不同客户端二是 opencode 的整体机制足够开放我可以把团队约定、代码规范、测试标准全部沉淀成 skills 和 AGENTS.md形成一套可复制的工程资产这一点在团队协作里价值极大三是本地数据这一点和 IDE 插件的联动方式更贴合我们团队的工作习惯。当然每个工具的手感是有明显差异的。如果你预算充足、不在乎绑定生态、只希望装完就能获得最好的代码体验那 Claude Code 确实值得买。如果你跟我一样希望把主动权握在自己手里愿意花一点时间配置出一个顺手的工作流那 opencode 就是值得你长期投入的方向。最后再说一个我自己的真实体会选工具这件事没有绝对的最好的只有最适合当前工作流的。opencode 对我来说最舒服的一点是它的能力边界是开放可扩展的——今天你觉得某个流程不顺明天就能通过加一个 skill 或改一份配置把它拧过来。这种工具跟着人走的感觉正是它在这么短时间里吸引一批忠实用户的核心原因。如果你刚接触 opencode不要急着跟风装一堆插件先把它跑通、配置一个稳定模型、用一阵子再说。等你的项目、习惯和它磨合得差不多了你会发现自己写代码的节奏已经悄悄变了。