开源AI编码代理opencode实战：从终端安装到Skills与Playwright集成

最近终端圈子里最热闹的一件事，就是那个用 Go 写的开源 AI 编码代理 opencode 突然爆火。如果你一直在用 Claude Code、Codex 或者 Aider 这类工具，那你大概率已经在各种仓库、X 时间线或者 V2EX 讨论帖里看到过它的名字。我花了一周时间把它从安装、配置、IDE 集成到真实项目实操完整跑了一遍，最大的感受是：这玩意儿不是一个简单的“ChatGPT 终端壳子”，而是一整套可以嵌进你日常开发流程的 AI 编码基础设施。

这篇东西不是什么官方文档翻译，是我自己从零上手 opencode 的完整记录和避坑总结。不管你是刚听到这个名字、已经在用但没玩明白 Skills 和 Memory，还是想在 VS Code、JetBrains IDEA 里把它接进现有工作流，应该都能从里面找到点有用的东西。我尽量把每一步操作背后的原因也讲清楚，方便你遇到问题时不至于只会照着抄。

1. 项目概述与定位：opencode 到底是个什么项目

1.1 它不是某家公司的闭源产品，而是 Charm 团队的开源项目

先说大家都关心的问题，热搜里那句“opencode是哪家公司的”几乎是每个刚接触的人都会问的。opencode 不是某一个商业公司的商业产品，而是由 Charm 这个团队发起并维护的开源项目。Charm 这家公司在终端圈子里名气不小，做过非常火的终端 UI 组件库 Bubble Tea、Lip Gloss，还有一个名为 Glow 的终端 Markdown 阅读器。他们的技术路线一直围绕“把终端体验做到现代、美观、可用”展开，opencode 也正是这个路线在 AI 编码领域的一次延伸。

底层实现层面，opencode 使用 Go 编写核心逻辑和 TUI 界面，CLI 同时借用 TypeScript 生态来对接各家 AI 模型 SDK。Go 给它带来了单文件分发、内存占用低、启动速度快、部署简单的优势，这也是为什么它能一个二进制文件直接跑在 macOS、Linux、Windows 上，只需要一条命令就能完成安装。整个项目以 Apache 2.0 协议开源，意味着你可以审阅代码、自己构建、甚至基于它做二次开发。

从定位上看，opencode 属于“终端 AI 编码代理”（terminal AI coding agent）这个细分赛道。它不是一个单纯的对话补全工具，而是能在你的项目目录里自己读文件、自己执行命令、自己修改代码的 Agent。它能理解整个项目上下文，而不仅仅是当前打开的那个文件，这是它和普通 IDE 内 AI 补全插件最本质的区别。

1.2 和 Claude Code、Codex 这些 Agent 工具比，它的差异化在哪

用过 Claude Code 的人应该都有体会，那玩意儿确实强，但它更像是一个“绑定在 Anthropic 模型上的客户端”。opencode 的思路不一样：它把“Agent 的壳”和“模型的大脑”彻底解耦，你想接 Claude 就接 Claude，想接 GPT 就接 GPT，想接 DeepSeek、Kimi、通义、Ollama 本地模型也可以，全看你自己怎么配置。

我整理了一个对比表，方便你理解它和同类工具的核心差异：

我自己用了几天后，最大的感受是 opencode 的“可组合性”非常强。它不是替你做决策，而是把选择权全部交给你。你可以同时配置多个 Provider，在同一个项目里随时切换，甚至在同一会话里让它调用多家模型对比回答。对于那些不想被单一厂商锁定的团队和个人来说，这种自由度属于刚需。

2. 安装与第一步实战：从命令行到第一个 AI 对话

2.1 全平台安装方式与 Windows 特别提示

opencode 的安装方式足够简单，官网和仓库 README 提供了好几种路径，我实测下来按推荐顺序排列如下：

1. 官方安装脚本。macOS 和 Linux 终端执行：

curl -fsSL https://opencode.ai/install | bash

Windows 的 PowerShell 用户执行：

irm https://opencode.ai/install.ps1 | iex

这个脚本会把可执行文件放到用户目录下的~/.opencode/bin（macOS/Linux）或%USERPROFILE%\.opencode\bin（Windows），然后自动写入 PATH。实测在 macOS 上装完立刻就能用。

2. Homebrew 方式。macOS 用户如果不想用脚本，我比较推荐这个：

brew install charmbracelet/tap/opencode

好处是后续升级方便，一条brew upgrade opencode就搞定，安装位置也统一，不会在系统里散落一堆文件。

3. Go 用户直接安装。如果你机器上本来就有 Go 环境：

go install github.com/charmbracelet/opencode@latest

注意go install装完后二进制会落在$(go env GOPATH)/bin下，这个路径不一定在 PATH 里，装完先跑一下opencode --version，提示找不到就直接把 GOPATH/bin 加到 PATH。

Windows 用户容易踩的第一个坑，就是热搜里那句“无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个报错就两个原因：一是 PATH 里没有 opencode 所在目录，二是没有重新打开终端，PATH 没刷新。如果安装脚本执行成功但命令还是不认，先检查环境变量：

$env:Path = [System.Environment]::GetEnvironmentVariable("Path","User") echo $env:Path

能看到C:\Users\你的用户名\.opencode\bin就说明 PATH 没问题，重启 PowerShell 或 VS Code 再试。

2.2 初始化配置与模型接入：先跑起来再说

安装完成后，运行opencode会直接进入交互式 TUI 界面。但第一次打开它不会自动给你配好模型，需要先告诉它你要用哪一家的接口。

最简单的方式是用登录命令。比如你要用 Anthropic 的 Claude：

opencode auth login

它会弹出交互式选择，让你从支持的服务商列表里选一个，然后跳转到浏览器或让你粘贴 API Key。这个命令会为你生成配置文件，默认存放在~/.config/opencode/opencode.json。

但如果你用的是 DeepSeek、Kimi 这类通过 OpenAI 兼容接口提供的服务，我建议更稳妥的路线是直接手写配置。先创建一个空配置文件，然后往里加 Provider。这里有一个我在实际配置中验证过可用的 DeepSeek 片段，字段含义我做了注释：

{ "$schema": "https://opencode.ai/config.json", "provider": { "deepseek": { "name": "DeepSeek", "options": { "baseURL": "https://api.deepseek.com/v1", "apiKey": "{env:DEEPSEEK_API_KEY}" }, "models": { "deepseek-chat": { "name": "DeepSeek V3" }, "deepseek-reasoner": { "name": "DeepSeek R1" } } } } }

看到{env:DEEPSEEK_API_KEY}这种写法了吧？这是 opencode 推荐的做法，API Key 不要直接硬编码在 JSON 里，而是通过环境变量引用。先在系统里设置好环境变量，然后 opencode 读取配置时会自动替换成真实值。这样你把配置文件提交到 Git 仓库也没问题，密钥不会泄露。

配置完成后，运行opencode models就能看到所有可用的模型列表。opencode再次启动 TUI 后，可以按快捷键切换当前模型。

2.3 第一次实战：让 Agent 处理一个小任务

进入 opencode 的 TUI 后，你会看到左栏是当前项目的文件树，右栏是对话区，底部是输入框。初次使用我建议先让它做一个简单任务，别一上来就丢一个大型重构需求。比如我拿一个小的待办项目测试，输入：

看看这个项目用了哪些技术栈，然后帮我梳理一下目录结构，最后指出代码里可能存在哪些明显问题。

opencode 会先读取项目元数据文件，然后自己浏览目录、查看关键文件，最后给出结构说明和问题清单。你会看到它像真人工程师一样按顺序执行“读文件 → 分析 → 整理结论”的步骤，而且每个动作在界面里都有日志展示。这个过程直观展示了它和普通对话工具的本质区别：它真的在项目上下文里工作，而不是对着空气聊天。

第一次跑通之后，你就算正式入门了。接下来要做的，就是好好理解配置文件——因为后面所有高级玩法，都建立在你能自由修改配置的基础上。

3. 核心配置与进阶玩法：Skills、Memory 和模型管理

3.1 配置文件结构：一个 JSON 管理所有模型与工具

opencode 最吸引我的一点，是把所有配置集中到了~/.config/opencode/opencode.json一个文件里。相比 Claude Code 那种主要靠环境变量和命令行参数来配置的方式，一个结构化的 JSON 文件明显更直观、更好维护。

我自己的配置文件结构大致是这样的：

{ "$schema": "https://opencode.ai/config.json", "provider": { "anthropic": { "options": { "apiKey": "{env:ANTHROPIC_API_KEY}" }, "models": { "claude-sonnet-4-20250514": { "name": "Claude Sonnet 4" } } }, "openai": { "options": { "apiKey": "{env:OPENAI_API_KEY}" } }, "ollama": { "options": { "baseURL": "http://localhost:11434/v1" }, "models": { "qwen2.5-coder:14b": { "name": "Qwen2.5 Coder 14B" } } } }, "mcp": { "playwright": { "type": "local", "command": ["npx", "-y", "@playwright/mcp@latest"] } } }

这里有两处我特别想强调的用法。

第一，ollama这个 Provider 非常值得本地模型爱好者配置。它让 opencode 可以直接调用你本机 Ollama 里跑着的模型，比如qwen2.5-coder:14b。你不需要任何 API Key，不需要联网，全部推理在本地完成，而且 opencode 会把所有的 Agent 操作能力原样提供给本地模型。这等于你有了一套完全免费、数据不出本机的 AI 编程环境，对于隐私敏感的项目或者想省 API 费用的场景非常实用。不过本地模型的推理速度和质量肯定不如云端大模型，我通常拿它处理注释补全、简单脚本这类低难度任务。

第二，mcp字段用来配置 MCP 服务器。我在这里把 Playwright 的 MCP 服务器注册进去了，后面实战环节会详细说用它修前端 Bug 的事情。opencode 会自动启动和管理这些 MCP 进程，你只需要在配置里声明好，TUI 里就能看到对应的工具。

3.2 接入 DeepSeek、Kimi、通义等国内模型

很多人在国内环境下不想或者不方便用国外模型，opencode 对国产模型的支持其实非常友好。只要这家模型厂商提供了 OpenAI 兼容接口，你就可以通过配置baseURL和对应的模型名给它接入。我测试过 DeepSeek 和智谱，整体跑通没有遇到什么障碍。

以 Kimi 为例，配置片段大致是这样：

{ "provider": { "moonshot": { "name": "Moonshot Kimi", "options": { "baseURL": "https://api.moonshot.cn/v1", "apiKey": "{env:MOONSHOT_API_KEY}" }, "models": { "kimi-k2-0711-preview": { "name": "Kimi K2" } } } } }

不同厂商的模型名和对上下文长度支持不一样，配置时有两个容易踩的坑。一个是baseURL末尾是否带/v1要严格按厂商文档来，填错最常见的报错就是 404 或 ”model not found“。另一个是模型名必须和厂商 API 里的名字完全一致，比如 DeepSeek 的下划线deepseek-chat，你写成连字符deepseek-chat反而对，但别写成deepseek-chat-v3这种自己发明的名字。

配置完成后记得重启 opencode 或者运行opencode models验证模型是否可见。我见过不少人改完配置直接在当前会话里继续用，发现模型没变，就直接下结论说配置没用——其实 TUI 通常需要重新启动进程才能加载新的 Provider 配置。

另外还有一类工具值得提一句，就是 ccswitch 这类配置切换工具。如果你有多套 API Key、多个服务商，不想频繁手动修改配置文件，社区里有人做了可视化切换工具，本质上是在帮你管理这个 JSON 文件。我用下来觉得它适合配置非常多的用户，普通情况下一份 JSON 多配几个 Provider，启动后用快捷键切换就完全够用了。

3.3 Skills 和 Memory：把高频工作套路沉淀成能力

Skills 是我认为 opencode 区别于普通 AI 编码器最有价值的功能，也是热搜词里那个 “opencode skills” 的核心。

简单说，Skill 是一段预定义的提示词模板，配合可执行的脚本或指南，让 Agent 知道在面对某类任务时应该用什么流程、输出什么格式、遵循什么规范。它解决的问题是：每次遇到同一类任务，你不需要重新把所有规则、约束、代码风格讲一遍。

创建 Skill 的方式是在~/.config/opencode/skills/目录下创建一个子目录，里面放一个SKILL.md文件，再加一个可选的脚本。目录名就是 Skill 的名字。比如我想让 Agent 在写 Go 单元测试时遵循我的习惯，就建一个go-test-writer目录，里面写一个SKILL.md：

--- name: go-test-writer description: 编写 Go 单元测试的规范与常用模板 --- 当我负责编写 Go 单元测试时，按以下步骤执行： 1. 先分析被测函数的输入输出和边界条件 2. 采用 table-driven 测试风格 3. 每个测试用例都要包含失败时的错误信息描述 4. 为依赖的接口创建 mock，不依赖真实网络 5. 测试文件名以 _test.go 结尾，与源码同包

配置好之后，你在 opencode 会话里直接说”用 go-test-writer 给这个函数写测试“，Agent 就会读取这个 Skill 并按照里面的规则执行。你可以把团队代码规范、常见的重构流程、项目启动步骤都沉淀成 Skills，本质上是在给你的 AI 助手“做岗前培训”。

Memory 则是让 Agent 记住项目的长期上下文。它会把关键的项目决策、架构约束、用户偏好等持久化到~/.config/opencode/memory/目录。比如我告诉它“这个项目使用 pnpm 而不是 npm，不要随意引入新的依赖”，下次会话它还能记得。Memory 和 Skills 的区别在于，Skills 是“怎么做某类任务的说明书”，Memory 是“关于这个项目/用户的事实记录”，两者配合使用时非常强大。

我强烈建议新用户先不要追求复杂的 Workflow 编排，而是从写一两个自己最常用的 Skill 开始。比如你经常写 Python 脚本，就写一个“Python 脚本规范”的 Skill；经常处理前端样式，就写一个“CSS 类名规范”。用真实项目跑几次，你会立刻感受到这两样东西带来的效率提升。

4. 把 opencode 接到 IDE 和桌面端：VS Code、IDEA 与桌面版

4.1 VS Code 插件：终端和编辑器无缝切换

如果你主要活动场景在 VS Code，那 opencode 的官方扩展还是很值得装的。它在扩展市场直接搜 “opencode” 就能找到，安装后左侧活动栏会多一个 opencode 图标。

插件解决的问题是：终端里的 TUI 和编辑器里的代码浏览经常要反复切换，Alt+Tab 切来切去很烦人。装上扩展后，你可以在编辑器侧边栏直接打开一个对话面板，选中代码片段就能发送给 opencode 的当前会话。当 Agent 修改文件时，侧边栏会列出变更，你可以直接点击查看 diff，一键接受或拒绝。

我在实际项目里用下来的感受是，VS Code 插件更适合那些“需要频繁阅读代码、上下文跨度大”的场景。比如分析一个函数被谁调用了、修改某个接口的影响面有多大，这类任务在侧边栏里带着完整项目上下文去问，比单纯在终端里效果好得多。插件本身不重装终端里的 opencode 进程，它只是利用你本地已有的命令和配置，所以不用担心“两个地方模型配置不一样”的问题。

4.2 JetBrains IDEA 插件：Java/Kotlin 项目玩家的福音

JetBrains 系用户也有官方插件。在 IDEA 或 IntelliJ 的插件市场搜索 “opencode” 就能找到。处理 Java、Kotlin 这类重工程项目时，IDEA 插件比 VS Code 插件更有价值，因为 JetBrains 本身对大型代码库的索引和导航能力是 VS Code 比不了的。

集成之后，你可以在 IDEA 里直接呼出 opencode 对话框，让 Agent 帮你分析当前类的继承结构、生成单元测试、解释某个 Spring Boot 注解的作用。最爽的是它在生成代码时可以直接插入到当前编辑器光标位置，不像终端里那样还得手动复制粘贴。

不过我遇到的体验痛点也很真实：JetBrains 系列的插件比较吃内存，同时打开大型项目和 opencode Agent 时，叠加 Agent 自己的工具调用开销，16GB 内存的机器会明显感觉到风扇狂转。如果你是低配机器，建议在 IDEA 里只开一个对话会话，不要同时挂多个 agent。

4.3 桌面版：适合不想碰终端的开发者和产品经理

opencode 官方还推出了桌面版客户端，外观比 TUI 更图形化，有传统的输入框、按钮、文件浏览面板，整体体验和 ChatGPT 桌面应用有几分相似，但底层连接的是 opencode 的完整 Agent 能力。

桌面版的意义在于扩大了使用人群。它让不习惯终端操作的团队成员——比如技术文案、QA、产品经理——也能用上项目级 AI 编码助手。你给它一个项目目录，它同样能读代码、提建议、跑脚本。我个人会把桌面版当作“只读助手”用途，让团队里非开发人员用它理解代码库、生成接口文档、梳理业务流程，而真正改代码还是回到终端或者 IDE 里操作，避免低质量修改污染代码。

5. 实战记录：用 opencode 接手一个陌生项目并修掉前端 Bug

5.1 让 Agent 读懂陌生代码库：接手项目的第一台发动机

接手别人留下的项目，特别是那种没有文档、没有注释、目录结构混乱的老项目，是很多程序员最头疼的事。过去我得花半天时间人肉梳理项目结构、调用链、关键模块。现在我会把这个过程直接丢给 opencode。

上手是这么操作的。启动 opencode 后，先给一个宏观问题：

这是一个什么类型的项目？入口文件在哪里？核心业务流程是什么？把项目的关键模块和它们之间的关系整理成文档。

opencode 会自己遍历目录，读package.json、README、源码文件，然后生成一份有结构的技术分析文档。这一步通常只能算热身。真正有价值的是接下来我让它做的深度追踪，比如：

帮我找出用户登录完整流程相关的所有代码，从路由、中间件到数据库操作，画出数据流向，并指出每一层的文件路径。

这时候 Agent 会跨文件追踪调用关系，输出一份“代码地图”。我在实际接一个 RAG 项目时，opencode 只花了大约三分钟就把整个核心链路理清楚了，还指出了两个我之后验证确实存在的设计隐患。如果不借助 Agent，这个工作我自己做可能要两三个小时。

这里有个很有用的技巧：不要只问一次就完事。你可以根据 Agent 的回答继续追问，让它在之前的分析基础上深入。opencode 的对话是有上下文的，它会记住之前读过的内容，所以它就相当于一个“越聊越懂项目”的接手同事。我一般会把这个过程整理出的架构要点直接让它写入项目的ARCHITECTURE.md，下次任何人接手都能少走弯路。

5.2 用 Playwright 让 Agent 自动复现前端 Bug

热搜里有句“opencode playwright 怎么测试前端bug”，这个确实值得说，因为它是 opencode 一个很亮眼的落地场景。传统流程是：你发现前端 Bug，手动复现，截图，再回代码里找原因。现在 opencode 可以通过配置好的 Playwright MCP 服务器，自己在真实浏览器里打开页面、操作、截图、读取控制台报错，然后把报错和项目代码关联起来分析。

我处理的一个真实需求是：某个基于 React 的管理后台，表格筛选功能在切换条件后数据不刷新。过去的做法是我自己打开页面，操作几步，看 Network 请求，再翻代码找 setState 有没有生效。这次我直接让 opencode 自己来：

用 Playwright 打开本地开发服务器，进入用户管理页，选择状态筛选为“已禁用”，然后检查表格数据是否正确刷新。如果没刷新，把控制台报错和网络请求信息抓下来，分析原因。

opencode 调用 Playwright MCP 工具，启动了一个自动化浏览器，一步步执行了我的指令。它自己点击下拉框、选择筛选条件、点击查询按钮，然后主动查看表格内容和 Network 面板。最终它定位到问题出在筛选条件改变后没有重置分页页码，请求发到第 0 页去了。它甚至直接给出了修复代码。

这个案例里最让我惊喜的不是它能用 Playwright，而是它能自己“读”浏览器返回的结果并据此调试。你会直观看到一个 Agent 在浏览器和代码之间来回穿梭：打开页面 → 看效果 → 翻代码 → 改文件 → 再刷新页面验证。这种“接近人类工程师”的工作流，在一年前还是科幻片，现在已经是 opencode 的日常能力了。

当然，要让这条链路跑通，前提是本地已经启动了开发服务器，并且配置好 MCP。配置方法就是 3.1 节里那个mcp字段，用npx -y @playwright/mcp@latest启动一个本地 MCP 进程。首次使用会自动下载 Playwright 的浏览器内核，需要一些耐心。

6. 常见问题与排查技巧实录：报错、卡顿、模型不响应

6.1 “命令不被识别”问题的三种解法与 PATH 排查

这条基本是 Windows 新手铁定遇到的坎，对应热搜里那句关于 cmdlet 识别不了 opencode 的报错。我帮你按出现频率排个序：

第一种情况：安装完压根没重启终端。脚本改的是用户级 PATH，当前终端进程的环境变量不会自动刷新。关掉终端重开，或者直接在 VS Code 里重载窗口。第二种情况：PATH 里根本没有 opencode 所在目录。用 2.1 节那段 PowerShell 命令手动确认。如果没有，自己去“系统属性 → 环境变量”里把%USERPROFILE%\.opencode\bin加进用户 PATH。第三种情况：安装脚本因为系统的执行策略（Execution Policy）被拦截了。用管理员 PowerShell 执行一次Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser，然后再执行安装命令。

macOS 和 Linux 上如果安装脚本跑完但找不到命令，绝大多数原因是 shell 的配置缓存问题。比如 zsh 用户先执行hash -r刷新命令缓存，还不行就检查~/.zshrc里是否配置了.local/bin这个目录。

6.2 运行时报 “unexpected server error” 怎么办

热搜里那句 “opencode: error: unexpected server error. check server logs” 是很多人都会遇到的。这个报错的本质是 opencode 内部逻辑服务在处理请求时抛出了异常，通常不是 opencode 自身崩溃，而是它请求上游模型服务时收到的响应不合法。

我的排查顺序是这样的：

1. 看日志。opencode 会把运行日志写到数据目录，macOS/Linux 在~/.local/share/opencode/log/，Windows 在%LOCALAPPDATA%\opencode\log\。打开最新的日志文件，搜索error或unexpected关键字，通常能看到具体是哪一层出了问题。

2. 确认 API Key 是否有效、是否过期。这个报错最常见的诱因就是 Key 无效，模型服务返回了 401，但某些兼容接口的响应体不符合规范，导致 opencode 解析失败，抛出了 generic error。

3. 确认 baseURL 是否正确。如果你配置的第三方 API 点已经变更地址或需要额外的请求头，opencode 默认不会带这些头信息，自然就收到非预期响应。遇到这种情况，去查厂商最新的兼容接口文档，然后同步改配置。

4. 尝试重启。Terminal TUI 用久了之后，它的内部状态可能会和 MCP 子进程之间出现不一致，完全退出 opencode 重新进入往往能解决一半以上的怪问题。

6.3 模型切换不生效、响应慢和质量不稳的排查心得

很多人改完配置发现当前会话里模型没变，这个问题我前面提到过：配置加载通常发生在进程启动时，改完 JSON 必须重启 opencode。如果重启后还是不行，跑一下opencode models，看看你的新模型在不在列表里。不在列表就说明配置格式有问题，或者模型名拼错了。模型在列表里但对话没切换，就在 TUI 里用切换模型的快捷键，一般默认是 Shift+Tab 循环切换聊天和编辑模式，实际以界面的快捷键提示为准。

响应慢的问题要分场景。如果是本地 Ollama 模型，慢是正常现象，特别是 14B 以上参数量的模型，建议把上下文长度调小，或者换一个量化的 GGUF 版本。如果是云端模型，先检查是不是自己的构建任务太重，比如你让它一次性读取了整个项目的所有文件，Token 消耗大，首字返回时间自然很长。这时候应该把任务拆小，先让它看目录结构再决定读哪些文件。

质量不稳定的问题，我有三条经验：第一，尽量用小而专的模型名单，不要同时开几十个模型，选择越多，Agent 切换时越容易在一个不适合任务的模型上输出低质量结果。第二，善用 Skills 约束输出格式，当 Agent 输出不稳定时，写一个明确的 Skill 把要求说清楚，效果往往比你反复对话纠正好几轮都好。第三，把重大项目拆成多个小任务分多次会话完成，而不是一个会话里堆积几十个功能需求。opencode 的上下文窗口再大也有极限，保持上下文精简是稳定性的第一保证。

写在最后：我给新人的几条建议

用 opencode 这几天，我对它的定位从“一个新鲜的终端工具”逐渐变成了“终端的现代 AI 工作台”。它不像某些产品那样试图把你圈在自家生态里，而是把模型、技能、MCP 工具、IDE 和桌面端都开放出来，让你自由组合。这种克制的设计，恰恰是它最难得的地方。

如果你想上手，我个人的建议是：先别急着配一堆 Provider 和装各种插件。用默认安装和一个用得最顺手的模型，跑通一个真实小任务，感受一下 Agent 在项目上下文里工作的模式。然后存下第一个 Memory、写上第一个 Skill，再逐步接入 IDE 插件、Playwright 和桌面端。这种渐进式的方式最不容易被各种配置问题劝退。

我在实际使用中还有一个习惯：会用 Claude Code 和 opencode 各跑同一个任务，然后对比它们给出的方案。opencode 胜在开放和可配置，Claude Code 在复杂推理上依然有优势。两个工具互补着用，比只押注一个工具稳得多。等你的 Skills 库越来越厚，你会发现 opencode 已经不是一个命令，而是一个真正懂你项目、懂你习惯的 AI 同事了。