1. opencode 到底是什么终端里的开源编码代理最近一段时间我几乎每天都会打开终端跑 opencode身边也有不少做后端和前端的朋友开始从别的 AI 工具迁过来。如果你还没听说过它我用一句话先概括opencode 是一个跑在终端里的开源 AI 编码代理你可以在命令行里直接让它读代码、改代码、跑测试、修 Bug甚至让它自己去浏览器里验证前端效果。它和 Claude Code、OpenAI Codex 属于同一类东西但最大的区别是 opencode 本身不绑定任何一家模型厂商你可以自由选择后端模型。我一开始对这类终端工具是有点抵触的。原因很简单人已经够依赖 IDE 插件了再来一个黑乎乎的终端窗口学习成本是不是太高了但实际用下来我发现它解决了几个 IDE 插件很难处理的问题。第一是批量重构它能直接操作多个文件而不是像补全插件那样只在你当前光标附近给建议。第二是可脚本化你可以把 opencode 接进 CI 或者自己的自动化流程里让它按你给的指令处理一段代码任务。第三是上下文完整它能看到整个仓库结构比 IDE 里只看到当前打开文件要聪明得多。我自己最常用的场景大概有三个接手老项目时让它先梳理项目结构和关键逻辑写前端页面时让它自己打开浏览器验证交互以及处理一些重复性很高的代码迁移工作。这篇文章没有废话我会从安装配置一直讲到常见报错排查尽量用我实际踩过的坑来帮你绕路。1.1 和 Claude Code、Codex 那些工具比它有哪些不一样先说 Claude Code。Claude Code 很强但它背后绑定的是 Anthropic 的模型虽然体验流畅可如果你公司有内部模型或者你习惯用别的模型 API那就很尴尬。Codex 是 OpenAI 出的同样是绑死自家模型。opencode 的做法不一样它把自己定义成一个模型无关的 agent 框架你可以在配置里指定用 OpenAI、Anthropic、Google、本地 Ollama 或任何兼容 OpenAI API 格式的服务。这个模型无关意味着什么意味着你换模型不用换工具。今天用 Claude 模型写文档明天换一个便宜的开源模型跑日常重构后天在本地起一个量化模型做离线问答这一切都可以在同一个终端工具里完成。对我来说这是 opencode 最核心的差异化价值。另外一点是权限控制。opencode 允许你非常细粒度地设置 agent 能访问哪些文件目录、能执行哪些命令。这个对生产环境特别重要。Claude Code 也有类似能力但 opencode 的配置更透明都写在本地配置文件里项目里每个人都能看到出了问题也好定位。最后是社区生态。opencode 支持 Skills、插件、VSCode 插件、IDEA 插件、桌面版这些都是社区驱动的方向。后面我会详细讲这些怎么配。1.2 它解决了我什么样的实际问题我个人的一个真实经历上个月接了一个老项目代码堆了四五年模块特别多文档几乎没有。按照以前的习惯我至少得花大半天在 IDE 里翻目录、搜引用、看历史提交才能理出个大概。这次我直接在项目根目录跑起 opencode让它用中文帮我梳理整个仓库的功能模块、依赖关系和数据流向它很快给出了一份结构文档还标出了几个明显可能是死代码的目录。我对照代码抽查了一部分准确率相当高。还有一次前端页面出了个交互 Bug问题只在特定操作步骤下出现手动复现特别烦。我用 opencode 配合 Playwright 写了一个自动复现脚本让它自己去页面里点击、填表、截图、看 console 报错最后它把定位到的异常信息和可能的修复方案一起丢给我。这个后面专门有章节讲。所以如果你平时也在做全栈开发、独立开发或者经常要接手别人的代码opencode 这类工具带来的效率提升是很直观的。它不是替代你写代码而是把你从一堆低信息密度的琐事里解放出来。1.3 核心特性速览在进入操作细节之前我先列一下 opencode 的核心能力也算给大家一个整体框架多模型后端支持 OpenAI 格式、Anthropic、Google、本地模型、以及大多数兼容接口的第三方服务。Agent 与交互模式可以一次性执行任务也可以进入交互模式多轮对话。Skills可扩展的指令集合让 opencode 学会处理特定类型任务比如分析日志、生成测试、代码审查。Memory跨会话记住项目偏好和用户习惯减少重复说明。Playwright 集成让 AI 自己启动浏览器、操作页面、捕获前端 Bug。LSP 支持利用语言服务器的能力更准确地理解代码符号、跳转和引用关系。编辑器与桌面配套VSCode、JetBrains 插件、桌面客户端都有社区方案。开源可审计配置和日志都在本地命令执行透明行为可追踪。这些特性并不全是 opencode 首创但它们被集成到一个工具里并且以开源方式提供这才是它引起关注的原因。2. 安装与配置从报错到跑通的完整路径opencode 的安装方式有好几种但很多教程只写一句npm install 一下就行结果新手在 Windows 上装完直接报错。这里我把官方推荐方式和我实际测试过的方式都过一遍。2.1 选择安装方式curl、npm、还是源码构建最常用的安装方式是执行官方安装脚本。在 Linux 和 macOS 上终端里跑一行curl -fsSL https://opencode.ai/install | bash这个脚本会检测你的系统架构下载对应二进制文件并放到本地 bin 目录。安装完成后最好新开一个终端窗口再执行opencode --version如果输出版本号说明安装成功。Windows 上如果你有 Node.js 环境可以直接用 npm 安装npm install -g opencode-ai这个包名需要特别注意不要拼错。安装完成后检查版本。如果 PowerShell 提示无法将 opencode 项识别为 cmdlet、函数、脚本文件或可运行程序的名称这通常是 npm 全局 bin 目录没有加入系统 PATH后面的常见报错章节会专门讲。opencode 官方也提供直接下载压缩包的方式Windows 用户可以去 releases 页面下载对应的 exe 文件解压到任意目录后将这个目录加入 PATH 即可。还有一种方式是源码构建。opencode 本身是用 Go 写的所以如果你本地有 Go 环境也可以直接拉源码编译git clone https://github.com/sst/opencode.git cd opencode go install这种方式适合想改源码或者要尝鲜最新主分支的开发者。日常使用没必要这么折腾官方安装脚本最快。我个人的建议是macOS 和 Linux 用户用 install 脚本Windows 用户优先用 npm 或直接下载 release 包。2.2 首次初始化与全局配置安装完之后第一次运行前建议先初始化配置目录。opencode 会默认在用户目录下创建一个配置文件夹例如 Linux 和 macOS 下的~/.config/opencode/Windows 下通常是%USERPROFILE%\.config\opencode\或AppData下对应的目录。不同版本路径会有一点点差异但核心文件是opencode.json。你可以手动创建这个配置文件也可以在交互界面里输入/config命令让它帮你管理。一个最基础的配置长这样{ $schema: https://opencode.ai/config.json, model: anthropic/claude-sonnet-4-20250514, provider: { openai: { api_key: env:OPENAI_API_KEY } } }这里model字段填的是默认模型provider里配置不同服务商的 key。注意env:前缀表示从环境变量读取 API Key这样不会把密钥写死在配置文件里。强烈建议所有人都这样配置尤其是项目里会共享配置文件时。如果你用的是本地模型比如 Ollamaprovider 配置会变成这样{ provider: { ollama: { options: { base_url: http://localhost:11434/v1 } } } }然后模型字段可以填类似ollama/qwen2.5-coder:7b这种形式。opencode 对 OpenAI 兼容接口的支持比较广很多第三方服务都可以用类似方式接进来。2.3 配置模型供应商与免费模型很多人关心 opencode 能不能用免费模型。答案是能但要看你说的免费是哪种。一种是真的免费开放接口的模型比如某些社区提供的限流接口或者本地跑的完全开源的模型。配合 Ollama 之类的工具你可以完全不花钱在 opencode 里跑代码任务。缺点是本地模型对显存要求高小参数量模型在处理复杂项目时效果会明显弱于大模型。另一种是订阅服务里包含的模型。比如某些云平台或工具提供的额度通常你可以拿到一个兼容 OpenAI 格式的 base URL 和 API Key直接在 provider 里配好就行。我建议第一次上手的人不要纠结免费模型先配一个你手头已有的、能力足够强的模型跑通全流程。这里有个很现实的体验问题模型能力越弱越容易在 agent 工具调用、多文件修改这类场景里翻车最后你会分不清是 opencode 的问题还是模型的问题。所以我的推荐路线是先用自己的主力模型配上跑通等熟悉了 opencode 的交互方式之后再去尝试本地模型或便宜的替代模型。2.4 检查安装配置是否生效配置完之后在项目目录里运行opencode会进入交互界面。这个界面和 Claude Code 类似底部是输入框上面是对话和工具调用记录。你可以先输入一个问题试试请读取项目的 README 和主要配置文件告诉我这个项目是做什么的使用什么技术栈。如果它能正确回复说明安装配置都通了。如果报错优先看终端里的提示很多时候是模型服务商那边的问题不是 opencode 本身的问题。另外可以用opencode models命令列出当前可用的模型列表。这个命令会读取配置文件里 provider 的信息并向对应服务商获取模型列表。如果这个命令报错说明 provider 配置有问题。3. 高频使用场景Skills、Memory、Playwright 与 LSP工具装上只是开始真正有价值的是怎么把它用进日常开发流程。这一章我会按实际使用频率把几个关键场景逐个拆开讲。3.1 用 Skills 扩展 opencode 的“动手能力”Skills 是 opencode 里一个非常重要的扩展机制。它本质上是一组预设的指令和配置文件放在特定目录下让 opencode 在对话中能自动调用合适的能力。举个例子我写前端比较多就常用一个名为frontend-review的 Skill作用是让 opencode 对当前项目的页面做一轮代码审查重点检查响应式布局、可访问性和性能隐患。传统做法是我把这段审查要求复制粘贴到每次对话里有了 Skill 之后只需要在对话里输入/frontend-reviewopencode 就会自动加载这套指令按我预设的流程执行。Skills 的目录结构一般是这样的~/.config/opencode/skills/ ├── frontend-review/ │ ├── SKILL.md │ └── scripts/其中SKILL.md是用 Markdown 写的指令文件里面描述了该 Skill 的触发条件、执行步骤和注意事项。opencode 会读取每个 Skill 的元信息在对话中判断是否需要加载。社区里已经有现成的 Skills 集合比如有人做过superpowers这个项目里面打包了几十个套路化的开发技能包括写测试、做安全加固、性能优化、代码重构等。我装上之后很多平时要手动组织语言的重复请求都变成了一个命令的事。需要注意的是Skills 不是越多越好。加载过多 Skill 会让每次请求的上下文变长既浪费 token也可能让模型误判。我建议只放自己真正高频使用的 5 到 10 个并且定期清理。3.2 Memory让 AI 记住项目上下文用过 Claude Code 的人都知道最痛苦的事情是你每次开一个新会话它都不记得你之前说过的偏好。opencode 的 Memory 机制就是为了解决这个问题。它的原理很简单opencode 会把一些关键信息写入一个 memory 文件下次启动时自动加载。比如你可以在配置里加入{ memory: { instructions: [ 代码注释必须使用中文, 测试文件放在 __tests__ 目录下, 不要修改 generated 目录下的文件 ] } }这样无论开多少次会话opencode 都会遵守这些规则。还可以在对话里直接说记住这个项目的部署命令是 make deploy它会把这条信息存储下来。实际使用中Memory 最适合放两类内容一类是项目级约定比如代码风格、目录规范、提交信息格式另一类是环境信息比如本地开发服务器的启动方式、常用端口、依赖安装命令。这些信息如果每次都要重新解释不仅浪费时间还极容易因为漏说导致 AI 作出错误判断。我自己踩过的一个坑是一开始把 memory 文件放在项目目录里结果不小心提交到了 Git 仓库导致同事那边拉下来后 opencode 行为变得很奇怪。后来我把项目相关的 memory 放进了.gitignore只保留真正需要团队共享的公约在版本管理里。3.3 用 Playwright 让 AI 自己测前端 Bugopencode 对 Playwright 的支持是它区别于其他终端 agent 的重要功能之一。你可以让 opencode 启动一个浏览器会话自动操作页面看页面渲染结果甚至读取控制台报错。我实际遇到过一个场景本地开发环境里某个页面在点击按钮后弹窗没有按预期出现。我让 opencode 使用 Playwright 打开页面模拟点击然后截图并检查页面里的 DOM 状态。它很快定位到是某个异步接口返回的数据格式变了导致前端解析失败。这里的关键是opencode 并不仅仅把 Playwright 当作截图工具它会从浏览器上下文里拿到 console 日志、网络请求、DOM 快照等结构化信息然后基于这些信息去推断问题原因。使用方式也不复杂。你只需要在对话里描述清楚要复现的操作步骤opencode 会自己决定是否需要启动浏览器。你也可以在 prompts 里明确告诉它用 Playwright 打开 http://localhost:5173点击登录按钮等待弹窗出现然后把 console 里的报错信息整理给我。对我这种平时用 Vite 做前端开发的人来说这个功能几乎省掉了一半的手动测试时间。不过要说清楚的是Playwright 集成不是万能的。对于需要登录态、权限复杂或者依赖特定本地数据的场景你可能需要先启动好自己的测试环境并提前准备好 mock 数据否则 AI 会卡在环境问题上。3.4 借助 LSP 提升代码理解精度LSP 是 Language Server Protocol 的缩写简单说就是让编辑器拥有高级代码分析能力的协议。opencode 支持 LSP意味着它不仅能读文本还能像 IDE 一样理解符号定义、引用关系、类型信息。举个例子如果项目里定义了一个UserService类普通的 AI 工具遇到帮我重构 UserService 的所有调用点这种任务时很可能靠正则式和模糊匹配来找容易漏改。而 opencode 接入 LSP 后可以通过语言服务精确获取所有引用位置然后逐一处理。在配置里LSP 通常是自动检测的。opencode 会检测项目里是否使用了 TypeScript、Python、Java 等语言并尝试启动对应的语言服务器。你也可以手动指定 LSP 配置比如在项目配置里加上{ lsp: { typescript: { command: typescript-language-server, args: [--stdio] } } }需要提前安装对应的语言服务器。对于 TypeScript 项目一般执行npm install -g typescript-language-server typescript即可。对于 Python 项目常见的是pyright-langserver或pylsp。Java 项目则可能需要配置 Java 环境路径。LSP 的作用平时不太容易感知但在做复杂重构、跨文件搜索调用链、分析类型报错时效果差异很大。我建议所有使用 opencode 的人不要跳过这个配置尤其是维护大型项目的时候。3.5 在 Java/Maven 项目里折腾 opencode 的配置热词里有不少关于opencode mvn 配置的问题说明很多人是在 Java 项目里使用 opencode。Java 项目跟 Node 项目不太一样构建工具路径、JDK 版本、Maven 仓库路径都可能影响 AI 执行命令。在 Java/Maven 项目里我建议在项目的 opencode 配置里额外加上这些约定{ instructions: [ 构建项目前先执行 mvn -q compile, 运行测试时使用 mvn -q test -DtestTargetTest, 不要修改 pom.xml 中的版本号 ] }为什么要这么写因为 opencode 默认的理解可能只是基于命令行通用知识它未必知道你项目的 Maven 版本和依赖下载策略。提前把常用命令写进 instructions能显著减少它瞎猜的风险。另外如果你的项目依赖本地的 Maven 私服或者特殊的镜像仓库建议在环境变量里把MAVEN_OPTS、JAVA_HOME等配置好再启动 opencode。否则它执行mvn test时可能因为私服认证问题失败而且报错信息对 AI 来说很容易误导到另外一个方向。对于 Java 开发者我其实也更推荐使用 JetBrains IDEA 的 opencode 插件因为 IDE 本身的编译状态、错误高亮、Gradle/Maven 工具窗口能给它提供额外的上下文。这个插件配置方式见下一章。4. 编辑器与桌面配套从终端到 IDEopencode 虽然是终端工具但开发者的日常阵地还是 IDE。官方和社区做了不少插件让 opencode 能嵌入编辑器里使用。4.1 VSCode 插件在编辑器里使用 opencodeVSCode 插件是使用体验最接近官方终端版的方式。安装后在编辑器侧边栏会多出一个 opencode 面板你可以在这里发起对话、查看文件变更、提交确认。VSCode 插件会自动读取你终端版opencode.json的配置所以模型、provider、skills 这些都是共通的不用重复配置。使用场景上我一般会在写代码同时让 opencode 帮我审查当前文件或选区。比如我在一个函数上右键选中问 opencode它就会把上下文带到对话里能直接给出优化建议。这个插件还有一个好处是 diff 审查界面。opencode 在修改文件前会列出变更你可以像 review 同事代码一样逐行确认是否接受。这样比在终端里直接接受所有修改安全得多。4.2 JetBrains IDEA 插件Java 开发者的选项JetBrains 系的插件起步比 VSCode 晚一点但现在也基本可用了。如果你在用 IDEA 写 Java装了这个插件之后右侧也能打开 opencode 面板。IDEA 插件的优势是它和 IDE 本身深度绑定比如说它可以直接引用当前选中的类名、方法名上下文里包含 IDE 的符号信息。对 Java 开发来说这比纯终端里用 LSP 拿到的信息还要干净。配置上JetBrains 插件同样读取全局 opencode 配置文件。唯一需要注意的是版本匹配老版本插件可能不支持新版 opencode 的 Skills 或 Memory 语法。遇到插件不生效时先看插件日志通常是因为 JSON 配置里多了新版本才有的字段。4.3 桌面版和终端版怎么配合使用opencode 的桌面版是一个基于 GUI 的客户端本质上还是调用同一个 agent 引擎。很多人问桌面版和终端版要不要选一个我的建议是可以同时装。桌面版适合做一些可视化操作比如看对话历史、管理多个项目、查看 token 消耗量。终端版适合在远程服务器、SSH 环境或者写脚本时使用。两者共享配置目录因此模型和 Skills 是一致的不需要分开维护。我在远程开发机上只装终端版在本机开发环境同时用桌面版和 VSCode 插件。桌面版更多是用来快速回看之前跑过的任务记录而不是发起新任务。因为对我来说终端里一条命令就能启动对话根本不需要打开一个 GUI 窗口。4.4 社区美化工具与技能包oh-my-claudecode、superpowersopencode 社区里有一个和它经常同时出现的项目叫 oh-my-claudecode最初是为了美化 Claude Code 的终端界面而做的后来也兼容 opencode。它提供了一套主题和快捷键配置让终端对话看着更舒服。如果你对终端纯文本界面不满意可以试试。另一个值得提的社区项目是 superpowers它在热词里也出现了。这个项目实际上是一个 Skills 合集里面包含了很多结构化的 agent 技能比如从零生成项目骨架、代码评审清单、数据库迁移方案等。安装 superpowers 很简单一般是把它的 skills 目录克隆到你本地的 opencode skills 目录下然后重启 opencode 即可。但要注意社区的 skills 更新节奏很快偶尔会有指令格式和当前 opencode 版本不兼容的情况。遇到某个 skill 不生效不要慌优先看它有没有在文档里标明支持的 opencode 版本。5. 常见报错与排查实录这一章是全文里我最想让你认真看的部分因为很多人在安装配置阶段就卡住了问题都不是大问题但就是网上查不到准确答案。5.1 “opencode 无法识别为 cmdlet、函数、脚本文件或可运行程序的名”这个报错在 Windows 上出现最多英文版是opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。原因基本只有一个opencode 的可执行文件地址没有加入系统的 PATH 环境变量。通过 npm 安装时npm 会默认把全局包的可执行文件放在某个目录下例如%APPDATA%\npm。如果这个目录不在 PATH 里PowerShell 就找不到 opencode 命令。排查和解决办法分三步执行npm prefix -g查看 npm 全局目录。确认这个目录下有没有 opencode 相关可执行文件。没有的话说明安装本身有问题。打开系统环境变量设置把 npm 全局目录添加到 PATH 中重新打开终端。如果你是用 release 压缩包方式安装的那就把解压后的目录加进 PATH。如果急着用也可以临时用npx opencode-ai代替opencode命令启动但这只适合临时救急因为每次启动都会受到 npm 缓存的影响。5.2 unexpected server errorcheck server logs运行 opencode 时有时会直接报error: unexpected server error. check server logs。这个报错的信息量很小网上很多人抱怨不知道查什么日志其实关键是找对日志位置。opencode 的日志文件通常放在用户数据目录下比如 Linux 和 macOS 上的~/.local/share/opencode/log/Windows 上一般在%LOCALAPPDATA%\opencode\log或类似目录。你可以在报错后打开最新的日志文件搜索error、panic、failed关键词。根据我的经验这个报错最常见的触发原因是模型服务商接口返回了异常状态码。比如 API Key 过期、额度用完、请求内容触发了服务商的安全限制、或者 base URL 配置不正确。日志里一般会带上 HTTP 状态码照着状态码去排查效率高很多。另外如果你本地开了多个 opencode 进程偶尔会因为端口占用导致 server 启动失败。这时候把已有的 opencode 进程全部关掉再重试通常能解决。5.3 This model is not available in your country这个报错的字面意思是在你的国家/地区当前不可用。经常有人来问怎么解决其实这往往不是 opencode 本身的限制而是你配置的模型服务商对请求来源区域做了限制。遇到这个报错能做的事情很有限。第一检查你使用的模型服务商是否有官方支持的区域覆盖说明换一个服务商或换一个在该区域可用的模型。第二项目环境如果不是长期固定的可以确认当前的网络出口是否符合服务商要求。第三如果有其他同类的 API 服务直接在配置里把 provider 换掉。我要特别提醒大家一点不要为了让一个模型在非支持区域可用去折腾那些不稳定、来路不明的第三方转发服务。这类服务既可能泄露你的代码也经常因为负载过高导致连接中断。在我的原则里开发工具安全性和稳定性永远排第一不要让一个 agent 工具变成数据泄漏的口子。5.4 模型上下文长度导致的中途报错在实际项目里用 opencode 时最扫兴的事情是任务跑到一半突然报 context length exceeded 或者类似错误。这不是 opencode 的 bug而是模型上下文窗口有限对话和工具调用历史越来越长最终超出了模型接受的 token 上限。遇到这种情况有几个处理办法把大任务拆小不要让一个会话里既做需求分析、又写代码、又跑测试、又做 review。拆成多个会话每个会话只做一件事。使用 memory 和 skills 减轻上下文负担把固定约定放进 memory把重复指令封装成 skills减少每轮对话携带的信息量。使用compact或clear命令如果对话已经很长可以压缩历史或者清空上下文重新开始但要记得把关键结论记录下来。我自己现在养成的习惯是项目前期探索阶段会用单独一个会话实施阶段重新开一个新会话并告诉它我已经完成了探索接下来只负责修改以下文件。这种方式把 token 浪费降到了最低任务成功率也明显更高。5.5 常见报错速查表报错信息最常见原因解决方向无法将 opencode 项识别为 cmdlet...PATH 未配置好检查 npm 全局目录并加入 PATHunexpected server error服务商接口异常、Key 失效查看 opencode 日志检查 API 状态This model is not available in your country模型服务商区域限制换服务商或模型区域设置context length exceeded对话历史太长压缩历史或拆分任务provider xxxxx not found配置里的 provider 名称写错检查 opencode.json 字段名authentication failedAPI Key 错误检查环境变量或配置文件中的 keyskills directory not foundSkills 目录路径配置错误确认 skills 目录存在并权限正确6. 选型对比与个人实践建议最后聊聊我自己的选型标准和使用心得这部分会有一些主观判断但都是基于真实项目里的对比得出的。6.1 opencode vs Claude Code vs Codex vs Pi这几类工具的对比其实不用拼出个你死我活而是看场景。Claude Code 的优势是模型链路调教得最顺滑尤其 Anthropic 自家模型在长上下文、复杂代码理解上有明显优势。缺点也很清楚模型绑定、不开源、配置自由度低。如果你不介意这些Claude Code 是很好的选择。Codex 是 OpenAI 自家的 CLI agent有了模型能力底子在代码生成上有一定优势。但绑定模型同样意味着你没法换到更便宜或更隐私的模型。opencode 的优势在于开源和模型自由。你可以把它同时接入 OpenAI、Anthropic、本地模型甚至公司内部微调模型。缺点是自由带来的代价你需要自己去配置很多东西报错排查也更多要靠自己。Pi 在热词里出现频率不低有些人把它和 opencode 放在一起比较。Pi 是另一个 AI 编码 agent 方向的工具侧重点更像是会话式结对编程。我没有长期使用它但体验下来感觉交互上它更偏向即时反馈而 opencode 更适合做自动化任务和批量重构。我的结论是如果你只想要一个开箱即用的工具选 Claude Code 或 Codex如果你愿意花一点时间配置换取模型自由和开源透明度opencode 是更划算的选择。6.2 什么项目适合用 opencode从影响范围和适用场景来看opencode 在下面几类项目里最有用多模块老项目AI 能快速梳理模块关系减少接手成本。前端项目配合 Playwright直接能自动回归页面 Bug。数据管道和脚本类项目这类项目命令调用多、逻辑重复性高很适合 agent 自动化。需要模型私有化部署的团队opencode 支持本地模型代码不出内网。反过来如果项目本身非常小只有几个文件那安装配置 opencode 的成本可能比收益还高直接让普通的 AI 编程助手处理就够了。另外如果你的项目对代码安全要求极高任何代码都不允许发送到外部模型服务那就要么用本地模型要么别用这类工具。6.3 几条我踩过坑之后的习惯最后分享几个我实际踩坑后沉淀下来的习惯希望对你有帮助。第一所有 API Key 一律用环境变量注入不要直接写进opencode.json。配置文件很容易被同步到网盘或 Git 仓库一旦泄露损失很大。第二重大项目进场前先让 opencode 输出一份当前目录和文件清单并人工确认哪些目录它绝不能动。我习惯在配置里把generated、dist、node_modules、target这类目录排除掉{ ignore: [ generated/**, dist/**, node_modules/**, target/** ] }这样能避免 AI 在某些极端情况下改错文件。第三任务完成后要求 opencode 给出变更摘要包括改了哪些文件、为什么改、影响面提示。这不仅能倒逼它认真处理也能让你在 review 时快速进入状态。第四善用compact而不是硬撑长对话。一个会话如果超过 30 轮效率会明显下降与其等到上下文撑爆不如主动压缩。我不太喜欢给工具做最强之类的结论性评价因为每个团队的约束条件不一样。但 opencode 开箱见底、可配置、可审计、可扩展的风格确实比较符合我这类开发者对工具安全边界和可控性的偏好。如果你最近也在找一款能深度整合进自己工作流的终端 AI 编码代理不妨照着这篇文章的路径从安装开始试上一天你会很快知道它到底适不适合自己。
