OpenCode：编程助手可以换模型，项目规矩不用跟着重写

换一个模型，往往不只是在菜单里换名字。项目怎么启动、测试在哪跑、哪些目录不能动，又得重新解释一遍。对于每天在不同仓库切换的开发者，这些重复交代比一次问答更消耗注意力。

OpenCode 提供了另一种组织方式：编码代理在终端里工作，模型来源可以配置，项目约定则留在仓库。你可以调整负责思考的模型，同时继续沿用这份代码的结构和规则。它更像一个可配置的开发入口，而不是某一家模型的专用聊天壳。

先认识项目，再让它改

OpenCode 1 的官方入门展示了一个很具体的起点：在项目目录启动 OpenCode，通过初始化让它分析仓库并生成 AGENTS.md。这个文件用于记录项目结构和编码模式。它值得人工检查、随代码维护，而不应把自动生成的内容当成永远准确的项目说明。

例如，一个中文内容网站把前台、管理端和接口放在同一仓库。与其每次都说“改前台请去哪个目录”，不如把运行方法、验证方式和目录职责保留下来。以后换模型或换会话时，仍能以同一套材料开始。这是工作流上的便利，并不代表模型一定会遵守所有规则；重要改动仍要检查文件和结果。

OpenCode 的仓库说明还区分了 plan 与 build：前者偏分析和代码探索，默认限制文件修改；后者用于实际开发。这种分工的用处，是把“打算怎么改”先变成可以讨论的方案。对于支付、权限或数据结构变化，先看方案比一开始就堆补丁更容易发现理解偏差。

模型能换，能力不会自动对齐

官方文档允许配置不同模型提供方。已有服务凭据的人可以沿用自己的来源，不必为了使用这个终端界面默认接受某一种套餐。

但统一入口不会抹平模型差异。同一任务换模型后，对代码的理解、工具调用和上下文承载可能不同。更合理的试法，是保留同一份项目说明、同一个小任务和同样的测试，观察改动能否落在正确文件，而不是只比较回复是否流畅。这里说的是选择方法，不是本文完成过的模型对测。

项目采用 MIT 许可；模型调用、托管服务以及对应账户的条款仍各自成立。代码能下载，不代表所有模型也随之免费，更不代表使用云模型时源码留在本机。

入门时先看清是哪一代

目前官方资料同时保留 OpenCode 1 与 OpenCode 2 的入口。文档明确提醒，两代默认都使用 opencode 命令，不能按默认方式并排安装；主仓库安装说明与旧版入门中的包名也不同。第一次尝试，先从当前官方仓库选择对应版本，再沿该版本文档走；选择新版本时直接进入 OpenCode 2 文档，别把两份教程拼在一起。

你不需要立刻把所有开发任务迁过来。找一份能正常启动、测试已知的项目，让它解释一个接口，再处理一个有明确结果的小改动，就足以判断这套入口是否顺手。

如果你真正想要的是“我可以自己决定模型，但不想反复重建项目习惯”，OpenCode 的吸引力就在这里。本文核对的是官方工作方式与版本提示，没有执行项目修改，也不承诺它能替代代码审查。