opencode实战指南：从安装到Skills扩展，打造终端AI编程助手

我最近这段时间一直在和各种 AI 编程助手较劲从 Claude Code 到 Codex再到一些小众的终端 Agent最后停在了一个叫 opencode 的工具上。说实话刚看到它的时候我有点不耐烦——又一个命令行助手但实际用了两周之后我发现自己已经不怎么打开 Claude Code 了组里几个同事也在我的安利下陆续切了过去。这篇内容我就把这阵子折腾 opencode 的经验整理出来包括安装、模型接入、Skills 扩展、编辑器联动以及一些网上搜得到的报错和根本没人写的坑。无论你是刚听说 opencode 想试试看的新人还是已经装了但觉得也就那样的观望派这篇应该都能给你一些新东西。1. opencode 是什么为什么我在用腻了 Claude Code 之后转向它先说清楚 opencode 是什么。它是一个开源的、跑在终端里的 AI 编程代理agent定位和 Claude Code 很像你能在终端里跟它对话它能读你的代码库、改文件、执行 shell 命令、跑测试甚至自己起一个浏览器去帮你复现前端的 bug。但它和 Claude Code 有一个本质区别——它不绑定某一家模型。Claude、GPT、Gemini或者任何兼容 OpenAI 接口的模型都能接进来同一个会话里还能随时切换模型。这个特性听起来不起眼但对日常开发来说太重要了。我最早是 Claude Code 的重度用户因为它写代码的质量确实高尤其是 Claude 系列模型对复杂工程上下文的理解比我在 IDE 里手动划代码再问 AI 要强太多。但用久了有几个问题一是模型被锁死在 Anthropic 的生态里虽然可以通过环境变量强行换模型总归不是官方支持路径二是 Claude Code 本身是闭源的遇到我想微调行为或扩展能力的时候只能在它的配置项里打转。Codex 那边则是另一种偏科OpenAI 模型的推理很强但它的一些云任务绑定让我这个习惯本地跑的开发者觉得不够顺手。opencode 恰好补上了这些缺口。它是开源项目模型无关终端交互界面做得挺细会话树、文件 diff、工具调用过程都能看清楚。它支持一个叫 Skills 的扩展机制你可以把团队里常见的操作流程写成一个个技能包让 Agent 自己判断什么时候该调用这个后面我会详细讲。它还接了 LSP、MCP 和 Playwright意味着它不只是会改代码的文字生成器而是真的能感知代码诊断信息、能访问数据库/浏览器这些外部工具。所以这篇文章适合谁看如果你已经在用 Claude Code 或 Codex想知道 opencode 值不值得切换可以重点看第一、四、六章如果你是第一次接触终端 AI Agent第二章和第三章先帮你在本机装好、跑通第一轮对话如果你关心的是怎么把它嵌进日常 IDE 工作流第五章是给你的。整体基调是实操为主我尽量把每一步都写透。1.1 它和 Claude Code / Codex 的本质差异很多人第一眼看到 opencode 的界面会问这不就是 Claude Code 的山寨吗从交互形态上讲确实很像但它们的设计哲学差别很大。第一是模型中立。Claude Code 是 Anthropic 官方的 CLI主推 Claude 系列Codex 是 OpenAI 生态的虽然也可以配第三方模型但那属于越狱玩法。opencode 从第一天就把多 provider 作为核心能力设计配置里可以同时定义 Anthropic、OpenAI、Gemini 等多家服务商然后在会话中随时用/models切换。这意味着同一个 opencode 会话里我可以用 Claude 写核心逻辑遇到长上下文分析时切到上下文窗口更大的模型再做代码审查时切回另一个灵活性不是一个 CLI 聊天工具能比的。第二是开源和可扩展。opencode 的仓库在 GitHub 上完全开源的社区可以提交插件、Skills、面板增强。它有一个/skills体系本质上是把角色设定 操作流程 参考脚本打包成 Markdown 文件放进项目或全局目录模型会根据用户的请求自动挑选合适的技能来执行。这比你每次把 Prompt 复制粘贴一遍靠谱得多因为技能分发的单位是文件而不是聊天记录。Claude Code 后来也推出了类似的能力但 opencode 在这块起步早生态也更开放。第三是工具链的完整度。opencode 内置了文件编辑、Shell 执行、Git 操作、HTTP 请求、LSP 诊断、MCP 接入、Playwright 浏览器控制而且这些工具的使用痕迹在 TUI 界面里是可见的——模型跑过什么命令、改过哪一行都会展开给你看。我自己更信任能看见执行过程的 Agent至少它把代码改坏了的时候我能快速定位是哪一步搞砸的。Claude Code 也有工具调用展示但 opencode 的界面把每个 tool 调用的输入输出拆得更细排查起来更舒服。1.2 一个终端工具为什么值得专门写一篇有人可能觉得AI 编程助手用 IDE 插件不就行了为什么还要在终端里多装一个工具这个疑问我一开始也有。后来我发现终端 Agent 和 IDE 插件解决的问题层次不同。IDE 里的 Copilot 类工具本质是高级补全 局部对话它的上下文边界是当前文件或者你手动选中的代码片段而 opencode 这类终端 Agent 的上下文边界是整个项目它能自己遍历目录、读多个文件、跑命令、根据测试结果反复修改。换句话说前者是副驾后者更像是一个能独立开工的实习生你只要在旁边盯着它别闯祸就行。所以一个终端工具值得写一篇长文不是因为它玄而是因为它的使用方式和传统插件完全不一样。你需要学会给它布置任务的语言需要理解它什么时候会自作主张、什么时候会卡住需要配置好模型和权限甚至需要为它维护一份项目说明文档。这些东西 IDE 插件不会教你官方文档往往也只写命令不写思路所以我这篇尽量把怎么用得好和为什么这样用一起讲透。2. 从零装好 opencode三种安装方式与 Windows 那个经典报错安装 opencode 本身并不复杂但因为它的安装入口比较多很多人在第一步就卡住了。尤其 Windows 用户报错信息里的opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名简直是人人都要遭遇一次的经典。我把几种安装方式放在一起对比然后单独讲这个报错。2.1 安装方式对比opencode 官方推荐三种方式curl 安装脚本、npm 全局安装、直接下载二进制包。我个人的建议是看你本机已经有什么环境。安装方式适合场景命令备注curl 脚本macOS / Linux 用户想要一键安装curl -fsSL https://opencode.ai/install | bash安装到~/.opencode/bin需要把该目录加入 PATHnpm 全局包已有 Node.js 环境的开发者npm install -g opencode-ai依赖 Node 运行时更新方便GitHub Releases 二进制想要固定版本、离线安装到 releases 页面下载对应平台的压缩包Windows 用户推荐这种方式解压即用我自己的机器是 macOS最初就是 curl 一把梭。之后在给一台 Windows 笔记本配置时发现 npm 方式对多数前端/全栈开发者更顺因为他们的机器上基本都有 Node。如果你公司电脑有严格的管理员权限限制用二进制包解压到用户目录是最省事的。这里还要说一句opencode 的 npm 包名和命令名不完全一致。命令是opencode但 npm 包名是opencode-ai这一点很容易让人装错。我见过有人执行npm install -g opencode装了个不知道什么东西然后一脸懵。记住包名是opencode-ai。2.2 解决“无法将 opencode 项识别为 cmdlet”等 PATH 问题这个报错绝大多数情况不是 opencode 没装上而是装完之后 Windows PowerShell 找不到可执行文件的位置。先判断装没装上。如果你用的是 npm 方式在 PowerShell 里执行npm config get prefix这会输出类似C:\Users\你的用户名\AppData\Roaming\npm的路径。opencode 装好后可执行文件会出现在这个目录下。如果npm list -g --depth0能看到opencode-ai那说明包已经装上了剩下的问题就是路径。接着检查PATH环境变量里有没有包含上面那个 npm 全局目录。PowerShell 中输入$env:PATH -split ; | Where-Object { $_ -like *npm* }如果输出为空说明 npm 全局目录不在PATH里。修复方法有两种临时修复当前终端立即生效$env:PATH ;$env:APPDATA\npm opencode --version永久修复在系统设置里搜索编辑账户的环境变量把C:\Users\你的用户名\AppData\Roaming\npm添加到用户变量Path中然后重新打开终端。另外提示一点Windows 下还有个隐蔽情况PowerShell 执行策略。某些机器默认禁止运行 .ps1 脚本导致 npm 安装包时生成的全局命令无法被识别。如果上述 PATH 修复后依然报错试一下Set-ExecutionPolicy -Scope CurrentUser RemoteSigned这个命令会把当前用户的脚本执行策略放开到本地脚本可运行、远程脚本需要签名足够 npm 生成的命令使用也不会对系统造成多大风险。2.3 验证是否装好装好之后别急着开聊先做三件事opencode --version这一步确认基础可执行文件没问题。然后opencode直接进入 TUI 交互界面。如果看到图形化的终端界面说明主程序正常。最后按CtrlC退出或者用内置的退出命令。我遇到过一些人装完执行opencode没反应其实是输入法把命令吃掉了或者终端窗口宽度太小导致 TUI 渲染失败。把终端拉大一点尽量到 120 列以上再试试。如果你用的是 curl 脚本安装它默认会往 shell 配置文件里写一行export PATH$HOME/.opencode/bin:$PATH但有些系统 shell 不是默认读取那个配置文件比如你用 zsh 但脚本只改了 bash 的.bashrc。出现这种情况手动把上面这行加到对应的~/.zshrc里再source ~/.zshrc就行。3. 第一次对话前的模型接入别急着跑先把 provider 搞清楚opencode 装好只是第一步真正决定它是神器还是人工智障的是你给它接的模型。很多新手第一次运行 opencode 时会惊讶地发现它居然不要求立刻填 API Key那是因为它默认带了一些模型提供方的快捷配置但这不代表你可以不搞懂 provider 直接裸奔。我把模型接入的逻辑拆开讲。3.1 为什么不提供 API Key 也能启动opencode 内置了多个模型的默认配置。项目地址和官方文档里维护了一份支持的模型列表其中有部分模型是开箱即用的也就是你可以直接在模型选择器里选中它们开始对话不需要手动配置密钥。这个设计是为了降低上手门槛——先让你把工具跑起来感受到 Agent 工作流之后再决定要不要接更强大的付费模型。但有一个重点是模型的能聊和能用是两码事。一个能回答问题的模型未必能老实执行工具调用。opencode 这类 Agent 的工作方式是模型生成指令 → 工具执行 → 把结果返回给模型 → 模型继续决策如果模型不具备稳定的 tool calling 能力它就会开始胡编文件路径、瞎猜命令输出表现出来就是越改越乱。所以我的建议是开箱即用的模型用来体验流程可以真正接手项目还是接一个工具调用能力强的商业模型。3.2 免费模型如何选模型 ID、上下文长度、工具的三角取舍如果你是学生或者想先低成本评估 opencode可以选择免费或低价的模型。但选择时不要只看免费两个字要看三个指标第一工具调用能力。这个最关键。如果模型不支持 structured tool callsopencode 就无法可靠地让它执行 shell 命令或修改文件。大多数主流模型在 API 层面都支持 function calling但实际稳定性差异很大。我的经验是选那种文档里明确标注支持 Agent / tool use的模型。第二上下文长度。Agent 在工作过程中会不断把文件内容、命令输出、错误日志塞进上下文如果你选一个上下文窗口只有 8k 的模型它可能刚读两个文件就失忆了。做日常开发至少 32k 起步复杂项目最好 128k 以上。第三速度和限流。免费模型的响应速度通常比付费模型慢而且单位时间请求数限制更紧。opencode 在跑自动化任务时会高频调用模型限流严重的话一个简单的改 bug 任务会被卡得断断续续。我个人的策略是本地随手实验、跑演示、写小脚本时用免费模型正式项目、重构、写测试这些需要稳定质量和持续推理的任务切到付费模型。opencode 的会话里可以/models随时切所以这个策略没什么成本。模型类型工具调用稳定性上下文大小适合任务免费/轻量模型中低小~中体验流程、简单问答、代码片段生成通用商业模型高中~大日常开发、读写文件、执行命令超大上下文模型高极大大型项目全局分析、重构调研3.3 配置文件的字段与常见问题一旦你决定接入某个模型就需要了解 opencode 的配置文件。它的主配置文件叫opencode.json在 macOS / Linux 上的默认路径是~/.config/opencode/opencode.jsonWindows 上是%USERPROFILE%\.config\opencode\opencode.json。项目目录下也可以放一个opencode.json会覆盖全局配置适合团队统一规范。一个常见的配置结构长这样{ $schema: https://opencode.ai/config.json, provider: { openai: { options: { apiKey: {env:OPENAI_API_KEY}, baseURL: https://api.openai.com/v1 }, models: { gpt-4o: {} } }, anthropic: { options: { apiKey: {env:ANTHROPIC_API_KEY} }, models: { claude-sonnet-4-20250514: {} } } } }这里的{env:OPENAI_API_KEY}是一种变量引用语法意思是从环境变量里读密钥而不是把密钥明文写进 JSON。强烈建议你不要把真实密钥写进配置文件尤其是项目根目录下的配置一不小心就提交到 Git 仓库里了。把 key 放到 shell 环境里例如export ANTHROPIC_API_KEYsk-ant-... export OPENAI_API_KEYsk-...如果你使用的是某个兼容 OpenAI 接口的服务在baseURL那里填它的地址即可。opencode 对 OpenAI 兼容协议支持得比较完善很多第三方模型服务都能用这种方式接入。这里有几个配置上的常见问题我直接列出来改完配置文件不生效opencode 通常启动时读取配置已打开的会话不会热加载。改完配置重新启动opencode。模型 ID 写错模型 ID 必须和模型服务方提供的 ID 完全一致多个空格都会报错。不确定就去 API 文档里复制。报错this model is not available in your country这个提示在模型服务侧出现意思通常是当前 API 请求的地区和模型可用地区不匹配或者是模型名称拼错了被服务端返回了这个错误文案。合规的处理方式是核对模型 ID、检查 API 端点是否填成了别的区域然后换成官方明确支持当前区域的模型。不要去找什么绕过方案既不稳定也不安全。4. Skills 机制让 opencode 从“问答工具”变成“执行工具”很多人把 opencode 当作一个终端里的 ChatGPT这是对它的最大误解。opencode 真正厉害的地方是 Skills 机制——它让 AI 不再只是回答你这个 bug 应该怎么改而是能按照你预定义的流程去执行整个任务。这一章我重点讲 Skills 是什么、怎么写、以及超级技能包怎么装。4.1 Skills 是什么和 Prompt 模板有什么区别你可以把 Skill 理解成一个带触发条件和使用说明的专业操作手册。它是一段 Markdown 文件开头有一段 YAML 格式的 frontmatter写清楚这个技能的名字和描述正文里则是具体的执行步骤、约束条件和参考信息。当用户提出请求时opencode 会把项目里所有可用的 Skill 的 name 和 description 告诉模型模型判断当前请求匹配哪个技能就会自动加载该技能的完整内容并按步骤执行。和单纯把一份 Prompt 模板复制到对话框里的区别在于Skill 是结构化、可被发现、可按需加载的。你不用手动告诉模型请你扮演一个前端调试专家先看 package.json再跑 dev server……——只要你预先写好一个 Skill 文件模型看到用户的求助后自己就会判断应该激活它。而且 Skills 可以附带脚本、参考文件执行时可调用外部程序能力天花板高很多。另外Skills 是文件化的可以放进 Git 仓库。这就意味着团队可以把我们团队上线前要做哪些检查我们新项目怎么初始化目录遇到数据库迁移该按什么步骤回滚这些约定沉淀成几个 Skill所有成员一键共享。这是复制 Prompt 无法做到的工程化优势。4.2 如何安装和编写自己的 skillopencode 会在两个位置寻找 Skills项目级目录.opencode/skills以及全局目录~/.config/opencode/skillsWindows 对应%USERPROFILE%\.config\opencode\skills。安装别人写的 Skill 很简单把对应的.md文件放进上述任意一个目录即可如果对方的 Skill 带脚本和资源通常是一个文件夹整个克隆或复制进去就行。例如git clone https://github.com/someone/awesome-skill ~/.config/opencode/skills/awesome-skill自己动手写一个 Skill 也非常好上手。下面是我给团队写的一个前端 Bug 复现技能用来让 opencode 遇到样式或交互类 bug 时不要直接瞎改代码而是先用 Playwright 复现--- name: frontend-debug description: 用户在开发前端时遇到组件渲染、样式错乱、交互点击无效等问题时使用。通过 Playwright 自动化浏览器复现问题收集 console 报错。 --- # 前端 Bug 复现流程 1. 在项目根目录找到 package.json确认 dev 脚本。 2. 启动本地开发服务器记录端口号。 3. 使用 Playwright 打开相关页面 URL。 4. 在页面中执行用户描述的操作路径复现 bug。 5. 收集 console 中的 error 和 warning。 6. 将复现步骤、页面截图、console 报错汇总给开发者。 7. 如果 bug 定位明确可以直接给出修复建议或修改代码。第 7 步我特意留给 Agent 自己判断因为有些前端问题是环境问题根本不在代码里。Skills 编写时要注意 description 写清楚什么场景用这个技能因为模型是靠 description 来判断触发的。description 太模糊它可能会在不该用时用了description 太具体它可能漏掉该用的场景。我的经验是描述里把触发条件 能解决的问题 大概步骤在 2-3 句话内说清楚至于细步骤放正文里。写好之后存为.opencode/skills/frontend-debug.md重启 opencode 就能用。想测试有没有被识别在 TUI 里输入/skills查看当前可用的技能列表。4.3 Superpowers / Memory 这类扩展怎么接opencode 社区里比较热门的扩展包是 superpowers 和 memory。superpowers 是社区开发者维护的一套增强技能集合里面包含了很多实用的 Agent 工作流比如代码审查、重构计划、TDD 循环等。接入方式和上面一样把 superpowers 仓库克隆到全局 Skills 目录下即可。装好后在/skills里能看到一大串技能模型会根据场景自动选用。memory 这个需求点在于模型默认不记得你上一次给它交代的项目约定。比如你上周告诉它这个项目不允许直接改公共组件本周再对话它可能就忘了。memory 扩展让 opencode 可以在指定的 markdown 文件中持续记录这些约定每次会话启动时自动读取相当于给 Agent 配了一个长期记忆。用法通常是在项目根目录维护一个AGENTS.md或类似文件把约定写进去模型会自动纳入上下文。不过这里有个反面教训我一开始追求大而全把社区里凡是跟技能沾边的包统统塞进了 Skills 目录结果模型每次决策前都要过一遍几十个技能描述既费 token 又容易选错。后来我清理到只剩 5 个左右真正高频使用的技能效果立竿见影。所以接入第三方扩展之前先想清楚自己的团队到底在重复做哪些事只给 Agent 装它真正需要的装备。5. 编辑器集成VS Code 插件与 JetBrains 插件的正确打开方式opencode 本身是一个终端工具但绝大多数开发者的日常主战场是 IDE。opencode 团队显然也意识到这一点所以提供了 VS Code 和 JetBrains 系的插件。这一章讲编辑器集成和几个高频工具搭配。5.1 终端里好用但编辑器集成才是日常先说 VS Code。直接在扩展市场搜索 opencode找到官方插件安装。装完侧边栏会出现 opencode 面板面板里能创建会话、选择模型、查看 Agent 执行过程。最大的好处是你在编辑器里选中的代码可以一键发送给 Agent它修改的文件会以 diff 形式展示在编辑器里所见即所得。JetBrains 系插件IDEA、PyCharm 等同理。热搜词里提到的 opencode jetbrains idea 插件 指的就是这个。安装后在 IDE 的 Tool Window 里打开 opencode会弹出一个内置终端和会话面板。我平时写 Java/Kotlin 项目时习惯在 IDEA 里用 opencode 直接分析 maven 项目结构——它自己能读pom.xml识别依赖关系比纯靠对话问这个项目怎么跑靠谱得多。但要注意一个问题终端里的 opencode 和 IDE 插件里的 opencode 是两个独立进程配置、会话、技能目录在多数情况下是共享的都读同样的~/.config/opencode但正在进行的会话不会自动同步。我的建议是长期任务用终端跑短平快的改代码请求用 IDE 面板各司其职。5.2 MCP、LSP 与 Playwright真实开发里的三个高频用法光靠读文件 改文件的工具Agent 能解决的问题有限。opencode 接入了三种让我觉得它不是普通聊天机器人的能力。第一个是 LSPLanguage Server Protocol。opencode 能够启动语言服务器获取代码库的诊断信息比如 TypeScript 类型错误、Python 的 import 错误、未定义变量等等。这样 Agent 在动手改代码之前就能看到编译器级别的错误而不是靠猜。使用方式是在 TUI 里运行/lsp然后选择需要启用的语言服务。配置后模型会在需要时自动去查诊断信息。这个能力对大型 TypeScript 项目尤其有用能明显降低改完这处又破坏另一处的连锁翻车概率。第二个是 MCPModel Context Protocol。简单理解MCP 就是给 AI 接外部工具的标准化接口。opencode 作为 MCP client可以连接文件系统、数据库、浏览器等 MCP server。比如你可以在配置文件里加一个 filesystem MCP server让 Agent 能以外挂方式访问指定目录也可以接数据库 MCP让它直接查表结构。配置方式是在opencode.json里增加mcp字段{ mcp: { my-fileserver: { type: local, command: [npx, -y, modelcontextprotocol/server-filesystem, ./data] } } }第三个是 Playwright。这个解决的是前端 bug 排查的痛点。以往让 AI 改前端 bug它只能看代码猜现在你给它一个 Playwright 技能它能自己启动浏览器、打开页面、模拟点击、收集报错信息。我在第四章写的frontend-debugSkill 就是基于这个思路。实际操作中Agent 会生成一个临时测试脚本执行npx playwright test然后把失败截图和 console 日志作为决策依据最后反推代码问题。这一套流程跑通之后前端 bug 的修复效率提升是肉眼可见的因为整个链路从观察现象到修复代码都由同一个 Agent 闭环完成中间没有信息损耗。6. 接手老项目与日常排错的实战心得最后一个部分我想聊聊 opencode 在真实开发场景中的表现包括用它快速接手陌生项目、日常排错的排查链路以及它跟其他 Agent 工具的横向对比。这一章内容更偏个人经验不一定每个场景都适合你但应该有些参考价值。6.1 用 opencode 快速摸清一个陌生项目的结构接手一个没看过的项目最耗时间的是找到入口、理清模块、搞懂约定。opencode 很擅长做这件事。我的做法是在项目根目录启动 opencode先输入一句模糊的话请帮我梳理这个项目的整体结构包括技术栈、目录划分、启动方式、主要模块并输出一份简要架构说明。Agent 会自动读取README、package.json/go.mod/pom.xml等元信息文件然后按模块浏览源码最后给出一份结构化总结。指令里的关键点是要求它输出一份简要架构说明否则有些模型会只给一段泛泛而谈的话不落地。如果项目里有AGENTS.md或CLAUDE.mdopencode 也会自动读取并作为项目上下文。我的习惯是在新项目起步时就让它生成一份AGENTS.md里面写清楚构建命令、测试命令、代码风格、目录约定之后每次对话模型都会自动遵守。这相当于把团队规范写进了 Agent 的长期记忆里比每次重新交代高效得多。还有一个小技巧接手老项目时我最常给的第二条指令是帮我把这个项目从跑起来到跑通核心流程的步骤整理成 checklist。这个任务会让 Agent 主动去读配置、看启动日志甚至自己尝试通过命令验证。它能发现很多文档里没写但实际需要的东西比如某个环境变量必须设置、某个本地服务必须先启动。6.2 遇到意外错误时的排查链路用 opencode 没有不出错的时候它是 Agent不是神。遇到问题不要慌我整理了一套排查链路能解决 80% 的异常。第一步开日志。opencode 带 debug 日志可以用下面这种方式启动opencode --debug日志会打印每个模型请求、工具调用、报错堆栈。TUI 里看不到的底层信息这里都能看到。日志文件一般存在用户数据目录下的log文件夹具体路径可以用opencode --log-dir查看。第二步判断是模型问题还是工具问题。如果现象是模型不执行指令、答非所问那多半是模型没配好或上下文太乱先/compact压缩上下文或/models换一个工具调用能力更强的模型。如果现象是工具执行失败比如文件写不进、命令找不到那多半是权限或环境变量问题。opencode 对工具权限有开关配置检查一下permission相关设置确认没有拦掉 Agent 需要的命令。第三步看是不是配置文件的坑。配置文件写错、模型 ID 不匹配、API key 没生效都会在日志里留下明确错误。最常见的几个错误我在第三章已经列过。还有一种是你在项目里放了opencode.json它覆盖了全局配置里的某些 provider 设置导致 key 失效排查时把项目级配置和全局配置都看一遍。第四步如果 Agent 陷入循环——反复执行命令、反复报错、反复改同一份文件——不要跟它硬耗。先CtrlC打断然后用一句话告诉它目前的问题是什么、已经试过哪些方案、失败原因是什么请停下来重新分析不要重复执行刚才的命令。 这一步非常有效。循环本质上是因为上下文里积累了太多失败信息模型找不到出口你帮它把问题重新聚焦它就能跳出来。6.3 对比 codex / claude code / pi 之后我的选择最后聊聊工具选型。这段时间我身边的开发者经常争论 Codex、Claude Code、pi 和 opencode 到底哪个 Agent 好用。我的结论可能有点反主流工具之间的差距并没有想象中那么大真正拉开体验差距的是模型 工具链 团队规范三者的匹配度。维度Claude CodeCodexpiopencode开源否部分是是模型绑定主推 ClaudeOpenAl 系为主可配但偏轻量完全中立Skills/插件生态有较封闭弱一般活跃编辑器集成有有一般VS Code / JetBrains 都有上手成本低低很低中要配模型和技能我是这样用的日常主力是 opencode Claude 模型因为 Claude 的代码能力确实强而 opencode 又给了我随时切换模型的自由团队协作时我强制要求大家用 opencode并把opencode.json和AGENTS.md提交到仓库保证每个人聊出来的效果一致至于 pi 这类更轻量的工具我在需要快速回答一个简单问题、不想启动完整 Agent 流程的时候会用一下。Claude Code 我也没删除偶尔它的某些交互细节确实更顺手但跨模型场景下我还是把 opencode 当第一选择。拿opencode 接手开发项目来说我的体会是它比另外几个工具更听话。因为它的打开配置和技能体系是文件化的接手新项目时只要项目里有一套成型的 Skills 和 AGENTS.mdAgent 几乎能立刻进入角色。这套工作流一旦在团队里跑顺价值是很明显的。最后再分享一个小技巧opencode 的模型选择不是一成不变的我建议对同一个任务故意用两个不同模型跑一遍对比结果。尤其是在写测试用例和梳理复杂逻辑时不同模型的切入角度经常不一样互相印证能发现不少隐藏问题。大概率你在用久了之后也会形成一套属于自己的 opencode 使用姿势那比任何人的推荐都重要。