开头
这两年终端里的AI编程工具简直卷疯了，从最早的 Copilot 插件，到 Claude Code 和 Codex 这种纯命令行 Agent，再到今天要聊的 opencode，变化快得让人眼花缭乱。我第一次在 GitHub 上刷到 opencode 项目时，第一反应是"又一个终端 AI 工具？"，但真正装上用了两周之后，我把它写进了自己主力开发环境的常驻工具列表里，跟 Git、tmux 享受同等待遇。
opencode 是什么？简单说，它是一个开源的 AI 编程助手，跑在终端里，可以帮你读代码、改代码、跑测试、提 PR，甚至给你解释一个陌生项目的架构。它跟 Claude Code 和 Codex 这类工具定位相似，但它有几个明显不一样的地方：对多模型的支持更开放，不绑定某一家厂商；提供终端和桌面两种交互形态；插件生态做得相当舒服，尤其适合从零开始接进现有工作流。如果你现在是 Claude Code 或 Codex 的用户，想找一个更自由、更可控的替代品，或者你是第一次接触终端 AI Agent，想找个入门门槛低的工具，opencode 都值得看看。这篇文章我会从安装、配置、模型接入、核心功能到 IDE 联动，把实际踩过的坑和验证过好用的方案一次性讲清楚。
1. 工具定位与核心设计思路
1.1 不站队的 Agent 底座
先说清楚一个容易被忽略的关键点：opencode 本身不提供模型，它是一个"Agent 运行时"。什么意思？你可以把它理解成一台没有发动机的车，底盘、悬挂、方向盘都给你装好了，而发动机（模型）可以自己选，可以换，甚至可以同时装好几个轮着用。这种设计与 Claude Code"全家桶"路线形成鲜明对比——Claude Code 出厂就绑定了 Anthropic 的模型，虽然用起来省心，但如果你想接别的模型，就得折腾各种代理工具，那群热心网友做的 ccswitch、claude-code-router 就是这么火起来的。
opencode 的思路是把模型接入做成"一等公民"功能。它内置了非常多的 provider 支持，OpenAI、Anthropic、Google、本地模型（Ollama、LM Studio）都能直接配置，甚至还能接到各种兼容 OpenAI 接口的第三方服务。这意味着你可以用同一个终端工作流，今天用 GPT 的模型，明天换 Claude 的模型，后天试试国产的开源模型，而操作习惯和工具链完全不用变。
我自己实际用下来的感受是，这种"不站队"的定位在团队协作里尤其有价值。团队里有人习惯 Claude 的代码风格，有人觉得 GPT 更顺手，有人公司有内部模型网关，在 opencode 里这些都是配置项的问题，而不是"你迁就我、我迁就你"的站队问题。
1.2 为什么在众多 CLI Agent 里选它
市面上终端 AI Agent 已经不少了，除了前面提到的 Claude Code 和 Codex，还有开源社区的 screenpipe、crush、pi 等等。每个都有自己的侧重，opencode 的差异点在哪？我梳理了几个它真正打动我的地方。
第一是安装足够简单，一条命令就能跑起来，对新手非常友好。第二是对话体验和上下文管理做得好，它会把项目文件自动索引起来，回答问题时能主动引用相关代码，这一点做得比很多需要手动"喂文件"的工具贴心。第三是它的 session 机制，你可以把一次任务的上下文保存下来，下次继续接着聊，这在处理大型重构任务时简直是必需品——不然每次开新会话都要重新解释一遍项目背景。
当然还有一点很现实：它是开源的，而且社区活跃度不错。开源意味着你不用担心它某天突然停止维护导致整个工作流失效，也意味着遇到问题可以直接去看源码，或者提 issue 等社区回复。我见过不少朋友因为某个闭源工具突然改版导致自动化脚本全崩，那感觉真的太难受了。
1.3 它适合谁用
如果你属于下面这几类人，opencode 大概率值得上手一试。
第一类是多模型流浪者，喜欢在不同模型之间切换着用，不想被单一厂商绑定。第二类是团队技术负责人或架构师，需要统一开发工具链，但又希望成员能按需选择模型。第三类是开源项目维护者，经常要接手陌生代码仓库、快速理解架构，或者在多个项目之间切换，opencode 的自动索引和多 session 能力非常能打。第四类是为了尝鲜 AI 编程的纯新手，因为安装和配置流程足够平滑，不会在第一关就把人劝退。
至于说它适不适合完全替代现有的 IDE、完全用终端写代码，我的看法是现阶段没必要那么激进。更好的姿势是让 opencode 负责 Agent 类任务——改 bug、写测试、解释代码、跨文件重构，而编辑器仍然保留给你自己手动写码。人机协作，而不是人机对抗。
2. 安装与基础使用全流程
2.1 跨平台安装方式
opencode 的安装方式很灵活，官方推荐的方法是使用 npm 全局安装，如果你本机已经有 Node.js 环境，一条命令就能搞定：
npm install -g opencode-ai装完之后验证一下：
opencode --version如果你不想用 npm，也可以直接从 GitHub Releases 页面下载对应平台（macOS、Linux、Windows）的预编译二进制文件，解压后把它放进 PATH 里就能用。这个方法适合没有 Node.js 环境的机器，或者你想固定某一个版本做团队统一部署的场景。团队场景我强烈建议锁版本，别让大家各自装最新的，万一模型配置格式变了，排查起来太费劲。
Windows 用户需要注意一个常见问题：如果你在 PowerShell 里输入opencode报"无法将 opencode 项识别为 cmdlet、函数、脚本文件或可运行程序的名称"，说明 opencode 的可执行文件路径没有加入 PATH。解决办法有两个，一是重新以管理员身份打开 PowerShell，执行下面命令后重启终端：
npm config get prefix拿到 npm 全局安装路径后，手动把它加到系统环境变量 PATH 里。第二个更省事的办法是直接用 npx 运行：
npx opencode-ai2.2 初始化与首次对话
安装完成之后，在任意项目目录下执行opencode，它会进入交互式对话界面。首次运行时会引导你做基本配置，比如选默认模型 provider、填入 API key 等。如果跳过了引导也没关系，所有配置都存在用户目录下的~/.config/opencode/里，随时可以手动改。
第一次对话我建议先别急着让它干活，先问几个简单问题测试连通性，比如：
你能看到当前目录下有哪些文件吗？请简要概括这个项目的结构。如果它能准确列出文件树并给出合理判断，说明环境正常。如果报错Error: unexpected server error. check server logs for more details，多半是模型 API 没配好或者网络不通，这个在后面的模型配置章节会详细讲排查方法。
一个我踩过的坑：不要在一个超级大的 monorepo 根目录直接启动 opencode，它默认会扫描整个目录建立索引，如果这个仓库有几万个文件，索引过程会非常慢，甚至卡死。更好的做法是在子项目目录里启动，或者通过配置把无关目录排除掉。
2.3 对话界面的基本操作
opencode 的交互式界面跟 Claude Code 很像，熟悉终端 AI 工具的朋友几乎零成本上手。你直接输入自然语言指令，它会以流式方式实时显示思考过程和代码输出。界面上有几个常用快捷键值得记一下：
Ctrl+C：中断当前生成过程，适合模型跑偏思路或者回答太长时及时打断。/加关键词：唤起内置命令，比如/model可以切换当前会话使用的模型，/new开启新会话，/compact可以压缩当前会话的上下文。Shift+Tab：在一些版本中用来切换输入方式，比如从普通命令模式切换到 agent 模式。
这些快捷键在不同版本里可能有差异，记不住也没关系，输入/之后界面上会有提示列表，跟着提示走就行。我个人的使用习惯是把常见操作写成/命令的肌肉记忆，因为鼠标切来切去真的很打断心流。
3. 模型接入与配置详解
3.1 核心配置文件的构成
opencode 的模型配置是它最强大也最需要花时间理解的部分。配置文件的默认位置是~/.config/opencode/opencode.json，结构大概是这样的：
{ "provider": { "openai": { "apiKey": "sk-xxxx", "model": "gpt-4o" }, "anthropic": { "apiKey": "sk-ant-xxxx", "model": "claude-sonnet-4-5" }, "ollama": { "baseURL": "http://localhost:11434/v1", "model": "qwen2.5-coder:14b" } }, "default": "anthropic", "exclude": ["node_modules", "dist", ".git"] }这个 JSON 里最核心的概念是provider块，每个 provider 代表一个模型来源，你可以在一个配置文件里同时配好多个 provider，然后通过/model命令随时切换。default字段指定了默认使用哪个 provider。exclude是给索引器用的排除列表，强烈建议把node_modules、dist、build这类目录都排掉，一方面减少索引时间，另一方面避免无关文件污染上下文。
3.2 接入主流云模型
接入 OpenAI 和 Anthropic 的模型是最基础的操作。打开对应平台的 API 控制台，创建一个 API Key，然后填到配置文件里就行。
以 OpenAI 为例：
{ "provider": { "openai": { "apiKey": "你的key", "model": "gpt-4o" } } }如果你用的不是官方 API，而是某个兼容 OpenAI 接口的第三方服务，那就需要多配一个baseURL字段，指向服务商的地址：
{ "provider": { "myproxy": { "apiKey": "你的key", "baseURL": "https://api.example.com/v1", "model": "some-model-name" } } }注意，opencode 对 provider 的命名没有硬性限制，你可以随便起名字，只要字段结构正确就行。这一点对多模型切换特别方便，比如你可以把同一个服务商下不同模型分别配置成不同名字。
3.3 接入本地免费模型
如果你不想用付费云 API，或者有数据隐私方面的考虑，本地模型是个不错的方向。opencode 原生支持 Ollama，配置非常简单。
先在本地安装并启动 Ollama，拉一个适合编程的模型，比如阿里的 Qwen2.5-Coder 系列：
ollama pull qwen2.5-coder:14b然后在 opencode 配置里加一个 provider：
{ "provider": { "ollama": { "baseURL": "http://localhost:11434/v1", "model": "qwen2.5-coder:14b" } } }然后就可以在 opencode 里愉快地使用本地模型了。不过说实话，本地模型在代码理解和生成的准确率上，跟顶尖云端模型还有明显差距。我的实践结论是：本地模型适合做简单任务，比如批量改格式、写注释、做代码翻译，涉及复杂业务逻辑重构时，还是切回云端模型更靠谱。但在断网环境或者处理敏感代码时，有本地模型兜底真的很安心。
还有一种完全免费的思路：用一些提供免费额度的模型服务商。目前国内外有不少平台给开发者提供有限的免费 API 额度，只要在 opencode 里把对应的 provider 配好就能用。免费的额度虽然不多，但用来体验 opencode 的工作流、跑通概念验证已经完全够用了。这里提醒一句，任何第三方服务都建议先看服务协议和隐私政策，涉及公司项目代码时更要谨慎。
3.4 报错排查：server error 的常见原因
搜索热词里有一个特别典型的报错：opencode: error: unexpected server error. check server logs for more details。我刚开始用的时候也碰到过，当时第一反应是 opencode 坏了，后来排查了一圈才发现，十有八九是模型 API 那边出了问题。
这类"server error"最常见的触发场景有以下几种。
第一，API Key 无效或过期。检查配置里的 key 是否复制完整，有没有多余空格，去对应平台的控制台确认 key 还在有效期内。
第二，baseURL地址配错。如果你用的是第三方兼容接口，地址少了一个/v1后缀，或者填成了网页地址而不是 API 地址，都会报这种模糊的错误。最好的判断方法是把baseURL加上/models路径，直接在浏览器里打开，看能不能返回一个 JSON 列表。能返回就说明地址没问题，不能返回就是地址错了。
第三，网络代理干扰。如果你的系统配置了代理，而代理规则把 opencode 的请求踢到了错误的路由，就可能在调用时偶发 server error。排查方法：临时关掉代理，再试一次；或者在 opencode 的环境变量里显式指定不走代理。
第四，模型名称填错。模型名是 provider 侧定义好的，填一个不存在的名字，服务端会直接返回错误，但 opencode 这边的错误信息包装成了比较笼统的 server error。去服务商文档里确认一下准确的模型 ID，这是很多人容易忽略的坑。
如果以上都排查完还没解决，可以执行opencode doctor，它会检查环境变量、配置文件、本地模型服务是否正常，并给出诊断报告。这个命令在官方文档里位置很隐蔽，我是一步步翻源码才发现的，直接安利给所有被奇怪报错折磨过的人。
4. 核心功能实操与经验技巧
4.1 用 Skills 扩展 Agent 能力
Skills 是 opencode 非常值得关注的一个功能，它基本上就是给 Agent 预先定义好的"技能包"，让 opencode 在特定场景下自动套用工作流。这个概念跟 Claude Code 的 Skills 类似，但 opencode 的实现更开放，你可以自己创建技能包，也可以从社区安装别人分享的。
一个技能包是一个包含SKILL.md文件的目录，里面用 Markdown 描述这个技能是什么、在什么条件下触发、执行步骤是什么。举个实际的例子，我能经常用到的"代码审查技能包"，内容大概长这样：
# Code Review Skill ## Description 当用户要求进行代码审查时触发此技能。 ## Steps 1. 读取 git diff，了解本次变更。 2. 检查变更涉及的文件，理解上下文。 3. 关注潜在问题：性能、安全隐患、边界条件、代码风格。 4. 输出审查结论，包含问题严重程度和建议修复方案。把这个文件放到~/.config/opencode/skills/code-review/SKILL.md，然后让 opencode 审查代码时，它就会自动按这个流程执行。社区里已经有不少现成的技能包，覆盖了前端调试、数据库迁移、依赖升级等场景，可以直接拿来用，再根据自己的实际需求改一改。
我个人的体会是，Skills 的价值不在于它有多智能，而在于它把"个人和团队的最佳实践"沉淀成了可复用的流程。一个新人加入团队，不用再口口相传"我们项目测试要先跑 A 再跑 B 最后看 C"，直接把技能包扔给他就行。
4.2 memory：让 Agent 记住项目约定
搜索词里有opencode memory，这个功能确实值得单独讲。用过各种 AI 编程工具的人都有这种体验：明明上午已经告诉过它"这个项目用 pnpm 不用 npm""数据库迁移要用 XX 工具"，下午新开一个会话，它又忘得一干二净，得重新教一遍。
opencode 的 memory 功能就是为了解决这个问题。它把一些跨会话的关键信息持久化保存下来，下次对话时 Agent 会自动加载相关记忆。这个能力在两种场景下特别有用：一是项目细节约定多且复杂，二是你在多个项目之间频繁切换，每个项目的组织结构、技术栈、常见坑都不一样。
Memory 的使用不需要你主动操作，Agent 会在合适的时机自动写入信息。比如你告诉它"这个项目不要在 service 层写业务逻辑，业务逻辑放 domain 层"，它会把这条信息记下来，后续会话里都会遵守。当然，你也可以手动查看和管理记忆内容，配置文件里可以控制 memory 的开关和容量。
不过我也要提醒一点，memory 不是万能的。它不能替代项目文档，该写的 README、架构文档还是要写。它更适合承担"隐性知识"的持久化，比如团队的口头约定、代码风格偏好这类写在文档里显得啰嗦、但确实影响协作质量的信息。
4.3 Agent 模式：让它自己动手解决问题
opencode 有一个 Agent 模式，开启之后它不再只是"回答你的问题"，而是可以自主执行一系列操作。比如你给它一个任务"修复登录页面的报错"，它可能会自己规划步骤：先读取相关文件，分析错误原因，修改代码，然后运行测试验证修复是否生效。整个过程中它可以调用各种内置工具，比如读取文件、编辑文件、执行终端命令、运行测试等。
这个模式真的很有"同事"的感觉，而不是一个被动的问答机器。我在实际使用中最常用的一个场景是让它修前端 bug：先描述复现步骤，它会自己打开浏览器、用 Playwright 复现问题、定位到出错的代码、给出修复建议，甚至直接改完代码跑一遍测试确认。
搜索词里有个opencode playwright 怎么测试前端bug，我当时看到就觉得用过的人都知道这功能有多香。有了 Playwright 集成，opencode 可以直接操作浏览器做端到端测试，对前端开发者来说，这相当于把"复现 bug—定位 bug—修复 bug—验证修复"整条链路都自动化了。最惊喜的是它的复现过程是真实的浏览器操作，不是模拟或者猜，所以定位到的问题一般都很准确。
4.4 oh-my-claudecode 与 superpowers 插件
热词里有opencode oh-my-claudecode和opencode 安装 superpowers，这两个都是社区里热度很高的插件/扩展包。如果你是 Claude Code 的老用户，可能对 oh-my-claudecode 这个项目有印象，它是一个给 Claude Code 加各种实用功能增强的社区项目。现在 opencode 社区也有人在移植和适配这套增强能力，让 opencode 的用户也能用到那些非常顺手的增强指令和工具，比如更好的 diff 查看、更智能的上下文整理、更多的快捷指令等。
superpowers 则是另一套更野心勃勃的扩展思路，它试图给 Agent 引入"协作方法论"，不是简单地执行命令，而是把复杂任务拆成多个阶段，让 Agent 像一个资深工程师一样分步骤推进，每个阶段都有明确的输入、产出和反馈循环。装上之后你能明显感觉到 Agent 在复杂任务中更有条理了，出错率也低不少。
安装这些扩展通常只需要在配置里加一行引用，具体可以参考各项目的 README。说实话，opencode 的插件机制让我挺惊讶的，它不是简单地提供 API 让开发者二次开发，而是真正做到"用户自己定义 Agent 的行为"，这在封闭的商业工具里几乎不可想象。
4.5 上下文管理和大型项目重构实战
最后说一个使用体验上影响巨大的点：上下文管理。终端 AI Agent 的上下文窗口是有限的，对话越长，它能记住的有效信息越少，回答质量就越差。opencode 提供了一些工具来缓解这个问题。
第一个是condense（或/compact）操作，可以把当前会话里的历史对话压缩成一段摘要，释放上下文空间。我一般在连续聊了十几轮、感觉 Agent 开始"健忘"的时候就会来一次压缩。第二个是会话保存和恢复，一个复杂的重构任务往往不是一次对话能完成的，你可以把当前会话保存下来，明天继续用同一个会话聊，所有上下文都还在。
在大型项目重构中，我的实践套路是这样的：先在 opencode 里打开会话，让它生成一份项目结构总览；然后通过对话确认重构目标和约束条件；接着分段执行重构，每完成一段就运行测试；一个阶段完成后，让 opencode 写一份这个阶段的总结，再开始下一阶段。整个过程像有一个非常耐心的同事陪着你做大型重构，你只需要把握大方向，具体实现细节交给它去抠。
5. IDE 插件、桌面版与工作流整合
5.1 VSCode 和 JetBrains 插件
搜索热词里 VSCode opencode 插件、JetBrains IDEA opencode 插件的关注度都很高。说实话，纯终端的 Agent 工具对很多开发者来说还是有点门槛的，把 opencode 的能力嵌入到自己熟悉的 IDE 里，学习成本和切换成本都低得多。
VSCode 装好 opencode 插件之后，你可以在编辑器侧边栏直接和 Agent 对话，选中代码片段发送给它，它会在右侧面板显示分析结果，产生的代码 diff 可以直接预览和接受。这个体验比切到终端舒服很多，尤其是处理小型改动的时候，不用来回切换窗口。
JetBrains 系（IDEA、PyCharm 等）的插件也类似，直接在 IDE 内部完成对话、代码生成和重构。而且 JetBrains 插件的 diff 体验更成熟，逐行接受或拒绝修改的操作非常流畅。我个人在写 Java 后端的项目时，基本就是 IDEA 加 opencode 插件组合，改代码、写测试的效率提升非常明显。
插件的安装很简单，直接在 IDE 的插件市场搜 opencode 就能找到。注意要选对官方维护的插件，因为社区里可能出现同名但来路不明的插件，安全问题不是小事。
5.2 桌面版：不想碰终端的人怎么办
搜索词里opencode桌面版的热度不算低，确实，不是每个人都喜欢终端界面。如果你用不惯终端，或者你身边的同事、领导想体验一下 AI 编程助手，但一看到命令行就头大，opencode 桌面版就是为这种情况准备的。
桌面版本质上是在图形界面里封装了 Agent 的能力，有完整的对话界面、文件管理面板、代码预览窗口，操作方式更像 ChatGPT 这类聊天工具，但背后干活的还是那个熟悉的 opencode。我第一次给团队里一个不常用终端的同事推荐桌面版时，他十分钟就上手了，直呼"这才是给人用的工具"。
桌面版适合哪些人？我的判断是：日常偏业务的开发者、刚接触 AI 编程工具的新手，以及需要可视化查看 Agent 操作过程的管理者或技术评审。而如果你本身就是重度终端用户，还是直接用命令行版效率更高，没必要多套一层界面。
5.3 与 ccswitch 等配置工具的配合
热词里有ccswitch配置opencode和opencode go 需要配合 cc switch 等工具，这里也顺带说清楚。ccswitch 本身是 Claude Code 生态里的模型切换工具，社区里有人也用它来管理 opencode 的配置，特别是当你同时使用多个 AI 终端工具时，用一套配置中心统一管理 API Key 和模型参数，确实省很多事。
如果你已经在用 ccswitch，也想把它跟 opencode 结合起来，基本原理就是让 opencode 读取 ccswitch 生成的配置环境变量，而不是自己单独维护一套。具体操作依赖于 ccswitch 的版本和配置导出方式，没有统一答案。但我的建议是：如果你只用一个 Agent 工具，就没必要引入 ccswitch；只有在多工具、多配置需要统一管理的时候，才考虑引入这层工具链。工具是为了省事，不是给自己增加维护负担。
5.4 用 opencode 接手陌生项目的完整流程
最后分享一个我特别想安利的实际用法：用 opencode 接手一个从未接触过的项目。这个场景我几乎每周都会遇到，不管是公司里同事交接的项目，还是 GitHub 上想二开的开源项目，以前纯粹靠人看代码，效率太低，现在有了 opencode，整个流程变得非常清晰。
我的标准流程分四步。第一步，在项目目录里启动 opencode，先让它生成项目的整体结构说明，包括技术栈、目录职责、核心模块间的关系。第二步，针对项目里最核心的几个文件或模块，逐一询问它的职责、关键逻辑和设计原因。第三步，让 opencode 结合项目的构建脚本和测试代码，梳理一套完整的"本地开发指南"：怎么跑起来、怎么跑测试、有没有什么环境依赖的坑。第四步，如果是一次实际开发任务，就让 opencode 先定位涉及修改的代码区域，讲清楚改动思路后再动手。
这套流程走下来，一个十万行级别的项目，基本两到三个小时就能建立起可用的全貌认知，比之前光靠读代码至少快一倍以上。当然，我始终主张 Agent 给出的结论只能作为参考，关键逻辑一定要自己顺着代码验证一遍——它不是一个可以完全信赖的架构师，但绝对是一个极好的"带路人"。
6. 常见问题与避坑速查
6.1 高频问题与解决方案对照
我把这段时间收集到的高频问题整理成一个速查表，不是全量文档，但覆盖了 90% 的新手问题。
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| opencode 命令不存在 | 安装路径不在 PATH 中 | 用完整路径运行或手动添加 PATH |
| 首次启动非常卡 | 目录索引范围过大 | 在配置的 exclude 中排除 node_modules 等大目录 |
| 对话到一半报 server error | 模型 API 网络异常 | 检查网络、临时关代理、确认 API Key 有效 |
| 问答质量明显下降 | 上下文过长 | 执行 condense/compact 压缩会话 |
| 切换模型后功能异常 | 新模型不支持某些工具调用 | 确认模型支持 function calling，或换回原模型 |
| 生成代码风格不符合项目规范 | 缺少上下文约束 | 在对话中明确告知规范，或利用 memory 沉淀约定 |
| 本地模型回答太慢 | 硬件性能不足 | 换更小的模型尺寸，或减少上下文长度 |
| IDE 插件连不上服务 | opencode 服务未启动 | 先在终端启动一次 opencode，再重启插件 |
6.2 环境与依赖常见坑
Node.js 版本过低是安装 opencode 时很常见的坑。如果你本机 Node 还是 14 或 16 这种老版本，npm 安装可能会失败或运行时报错。建议先把 Node 升级到 18 以上，最好用 LTS 版本，能省掉很多莫名其妙的兼容性问题。
另一个坑跟中文路径有关。如果你的项目路径里包含中文或特殊字符，部分版本的 opencode 在建立索引时可能出问题。这不是 opencode 的 bug，是 Node.js 生态的历史遗留问题。解决方案很粗暴但有效：把项目放在纯英文路径的目录下。
还有一个容易被忽略的：终端代理环境变量。很多开发者的 shell 里配置了HTTP_PROXY和HTTPS_PROXY，这些环境变量会被 opencode 继承。如果你的代理偶尔失效或规则不当，openode 调用模型 API 时就会出现间歇性失败。排查这类问题时，先看报错信息里有没有代理相关的关键字，有的话可以先清掉代理变量再测试。
6.3 安全与合规使用建议
最后聊点严肃的。AI 编程工具能大幅提升效率，但使用过程中一定要有安全和合规意识。
第一，不要把生产环境的密钥、数据库密码、内部系统地址直接粘贴给 Agent。即使你用的是本地模型，这些敏感信息也可能被写入日志或记忆文件。我的习惯是：给 Agent 的代码和描述一律脱敏，涉及敏感配置的部分用占位符代替。
第二，使用任何第三方模型服务时，务必确认服务商的隐私政策。云端 API 会把你的对话内容发送到服务商的服务器上进行处理，如果你在处理公司内部项目代码，最好先获得公司的合规许可，或者选择本地模型方案。
第三，opencode 的 memory 和会话日志会保存在本地，如果你在多台设备之间同步配置文件，留意这些文件是否也被同步了。敏感项目建议关闭同步，或者只同步配置文件，不同步 session 数据。
这些听起来像是老生常谈，但我确实见过不止一次因为 AI 工具使用不当导致的泄密事故。工具本身无辜，但使用者的安全意识不能缺席。
写在最后
从第一次在 GitHub 上刷到 opencode，到把它变成我日常开发的常驻工具，前后不过几周时间，但体验上的变化是实实在在的。它不像某些商业产品那样用华丽的宣传片吸引你，更像一个热爱命令行、把开发者体验放在第一位的工程师，默默给你递来一把好用的瑞士军刀。它接模型的选择自由度、对 Skills 和 memory 的支持、在 IDE 和桌面端的覆盖，让我觉得它不是一个跟风之作，而是一个真正理解终端开发者在想什么的工具。
我个人在实际使用中最深的体会是：用好 opencode 的关键，不在于背多少命令，而在于把它当成一个需要磨合的队友。它会遗忘、会误解、会在复杂任务里跑偏，但只要你愿意给它清晰的指令、保存好项目约定、适时压缩上下文，它回报你的效率提升远远超出你的投入。最后再分享一个小技巧：日常开发中，我会在项目根目录放一个.opencode.md文件，把项目独有的技术栈、运行命令、代码规范写进去，每次新开会话时 opencode 会自动读取它。这个小文件，比任何口头交代和群公告都管用。
 Lev)
