开头这两年终端里的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 工具的朋友几乎零成本上手。你直接输入自然语言指令它会以流式方式实时显示思考过程和代码输出。界面上有几个常用快捷键值得记一下CtrlC中断当前生成过程适合模型跑偏思路或者回答太长时及时打断。/加关键词唤起内置命令比如/model可以切换当前会话使用的模型/new开启新会话/compact可以压缩当前会话的上下文。ShiftTab在一些版本中用来切换输入方式比如从普通命令模式切换到 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 会自动读取它。这个小文件比任何口头交代和群公告都管用。
