企业官网建设流程全解析

如果你也经历过在 Windows 的 PowerShell 里敲下opencode却得到一串红色报错“无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”，别急着卸载。这个提示几乎每个刚接触 opencode 的 Windows 用户都会撞上，它拦住的只是新手村门口的第一道坎，真正的问题往往不在 opencode 本身，而在环境变量和安装路径上。

这篇文章我不会跟你客气，直接从 opencode 到底是什么讲起，把安装、模型接入、配置、接项目、IDE 插件、高频报错一条龙捋清楚。内容主要覆盖我在真实项目里用 opencode 干活时积累下来的经验，包括 go 订阅模型的选择、配合 ccswitch 切换配置、LSP 语义理解、Playwright 测前端 bug 这些实操细节。写给想用 opencode 但还没完全跑通的人，也写给团队想引入这个工具但担心它是不是又一个“套壳 CLI”的人。

1. opencode 是什么：不是又一个套壳 CLI，而是能“接手项目”的终端 AI 工程师

先说结论：opencode 是一个在终端里运行的 AI 编程助手，定位和 Claude Code、Codex 类似，但它走的是开源路线，并且从底层设计上就更强调“多模型”“多环境”“可扩展”。如果你把它当成一个只能聊代码的聊天机器人，那就太小看它了。它更接近一个能理解你项目上下文、能调用工具、能按你团队规范干活的“终端 AI 同事”。

1.1 名字里的信息：open + code

opencode 这个名字起得很直白，“开放”和“代码”是它的两个核心词。open 体现在哪里？第一，它支持接入多种模型，不绑定某一家厂商，你可以根据手里的 API key 或订阅服务自由切换；第二，它的配置是明文 JSON 文件，你能看到它到底在用什么模型、什么参数在工作；第三，Skills 技能机制允许你给它定义行为规范，让它适应团队自己的代码风格，而不是反过来被它带着走。

我用了一段时间之后的感觉是，opencode 并不是想取代 Claude Code 或者 Codex，它更像是想做一个统一入口。今天你可能用 A 模型的 API，明天团队可能买了 B 模型的订阅，后天的免费模型跑得不错你又想切过去试试。opencode 恰恰把这些都收拢到了同一个命令行界面里，这是它和那些深度绑定官方生态的工具之间最大的差异。

1.2 底层实现与核心功能

opencode 的发布形态让我一开始就很有好感：单二进制，Go 语言编写，下载下来就能跑，不依赖 Node 运行时，也不需要装一堆 Python 包。这一点在接手开发项目的时候尤其重要，新环境拉下来一个二进制文件就能用，省掉了所有环境摩擦。

核心能力大致可以拆成这么几块：

• 终端原生交互：在项目目录里直接启动，AI 能看到当前仓库的 git 状态、文件结构、最近改动，和你进行上下文相关的对话；
• 多模型接入：支持 OpenAI、Anthropic 以及多种兼容 OpenAI 协议的模型端点，配合订阅、免费模型源、企业网关都可以用；
• Skills 技能系统：允许你把团队规范、项目专属操作步骤封装成可复用的技能，让 AI 在特定场景下按你的规则执行；
• LSP 集成：通过语言服务器协议获得代码的语义级理解，不再是靠字符串拼凑上下文；
• Playwright 支持：可以直接让它驱动浏览器复现前端 bug，把“这个按钮点不动”变成可验证的测试过程；
• IDE 插件：VS Code 和 JetBrains IDEA 都有配套插件，终端里的对话和编辑器里的代码操作能联动起来；
• Desktop 客户端：如果你不习惯纯终端操作，也有图形化界面可以用。

至于 2.0 版本，体验上的变化主要集中在配置结构、LSP 稳定性和多会话管理上，老版本升级上来之后最直观的感受是提示更丰富、上下文管理更聪明了。

2. 安装与启动：PowerShell 报错“cmdlet 无法识别”的完整排查链路

我敢说，搜索“opencode”这个词的人里，一多半都是被这个问题拦住的：在 PowerShell 里敲opencode直接报“无法将 opencode 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这不是 opencode 坏了，是 Windows 环境变量没配对。下面按排查顺序讲，你照着走一遍，大概率就能解决。

2.1 先确认 opencode 到底装没装好

这个错误的本质是：PowerShell 在你当前命令解释器的 PATH 环境变量里，没有找到名为opencode.exe的可执行文件。换句话说，系统根本不知道这个命令去哪里找你。

但首先要排除一种情况：安装过程本身是否完整。opencode 这类 Go 编写的工具，官方安装方式通常是下载对应平台的二进制包、解压到某个目录，然后把它加入 PATH。部分环境也可以走包管理器（比如 Homebrew、Scoop）安装。如果你是用安装脚本自动装的，它会替你配置环境变量，但 Windows 下脚本经常因为没有管理员权限而写不到系统 PATH，只会写到当前用户的环境变量，甚至根本没写进去。

这时候你先找到 opencode 的安装目录。常见位置包括：

• 官方安装脚本默认的%USERPROFILE%\.local\bin或%LOCALAPPDATA%\Programs\opencode
• 你自己手动解压到的任意目录
• 包管理器安装后的标准路径

打开这个目录，确认存在opencode.exe。如果文件都不在，卸载重装，或者直接下载官方二进制包手动解压。如果文件在，继续下一步。

2.2 修改 PATH 环境变量，并理解为什么重开终端很重要

确认二进制存在后，最直接的操作是把这个目录加进 PATH。图形化操作步骤是：开始菜单搜“编辑账户的环境变量”，打开“环境变量”，在“用户变量”里找到Path，编辑，新建一行，粘贴 opencode 所在目录，一路确定。

操作完之后，必须把当前终端窗口全部关掉再重开。很多新手在这里卡住，是因为修改环境变量只对“新启动的进程”生效，你当前开着的 PowerShell 窗口里 PATH 还是旧值，怎么敲都报错。这是 cmdlet 无法识别问题里最普遍、最容易被忽略的一个原因。

如果你不想走图形界面，也可以在 PowerShell 里手动把目录追加到当前用户的 PATH：

# 将 opencode 目录加入用户级 PATH（把路径换成你的实际安装目录） [Environment]::SetEnvironmentVariable( "Path", [Environment]::GetEnvironmentVariable("Path", "User") + ";C:\Users\你的用户名\.local\bin", "User" )

然后再重开终端，运行：

opencode --version

能看到版本号，就说明装好了。

2.3 Linux 和 macOS 下的隐含坑

如果你在 macOS 或 Linux 上遇到“command not found”，排查思路类似，但有个隐含坑：如果是用官方脚本安装到~/.local/bin，而这个目录没有被你的 shell 加载进 PATH，同样会报错。在~/.bashrc或~/.zshrc里加一行：

export PATH="$HOME/.local/bin:$PATH"

然后source ~/.bashrc或重开终端即可。还有一点，如果在服务器上用sudo安装，装到了/usr/local/bin但普通用户没有执行权限，也会出现“找不到命令”或“权限不足”，记得检查文件权限。

2.4 另外两个被低估的 Windows 问题：执行策略和杀软隔离

在 Windows 上还有一个很隐蔽的问题：如果你是通过官方安装脚本（通常是 PowerShell 脚本）安装的，Windows 默认的执行策略可能会拦住脚本，导致安装根本没跑完，但你误以为装完了。

解决办法是在管理员 PowerShell 里临时放开执行策略，装完再恢复：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

这条只对当前进程生效，不会永久改动系统策略。另外，某些杀毒软件会对终端类工具误报并直接隔离opencode.exe，安装后如果仍然提示找不到命令，去查一下隔离区。

3. 模型接入与配置：go 订阅、免费模型、ccswitch 和 JSON 配置文件的门道

opencode 装好之后，下一个绕不开的坎就是模型配置。这也是搜索词里“opencode go 订阅模型选择”“opencode go 套餐”“ccswitch 配置 opencode”“opencode 免费模型”“opencode 怎么用”密集出现的原因。模型接入这块不搞清楚，工具就是空壳。

3.1 模型来源的三种方式

我在实际使用中，把 opencode 的模型来源分成三类：

• 自己手头的 API key：如果你有 OpenAI、Anthropic 或其他兼容服务的 key，直接在配置里填 base URL、模型名、key 就能用。这种方式最灵活，适合有公司网关或者内部模型平台的人。
• opencode go 订阅：这是 opencode 推出的订阅套餐，本质上提供了一批托管模型端点，你不需要一个一个去各家的控制台申请 key，一个订阅就能用多种模型。选择套餐时建议先看自己项目的语言栈和需求，侧重前端调试就选包含多模态模型的档次，侧重长上下文代码理解就选上下文窗口更大的那一档，不要盲目买最贵的。
• 免费模型源：网上流传的一些 free 模型 list 确实可以临时接入，但稳定性很差。经常有人问“hy3-free 是不是下线了”，这种免费源变动非常频繁，今天能用明天就 401，适合尝鲜，不适合正经干活。

对我来说，最舒服的组合是：公司内部有 gate 环境，配置成第一个模型端点；本地开发用 go 订阅作为兜底；免费模型几乎不碰，因为它浪费在排错上的时间远大于省下的订阅费。

3.2 配置文件的结构与修改姿势

opencode 的主要配置是一个 JSON 文件，通常在你用户目录下的配置文件夹里。以 Linux 为例，路径一般是~/.config/opencode/opencode.json；Windows 下则在%APPDATA%\opencode或用户配置目录里。第一次运行 opencode 时它会自动创建一个默认配置，往后你可以手动改。

一份典型的配置大概长这样：

{ "model": "your-default-model", "api_base": "https://your-api-endpoint.example.com/v1", "api_key_env_var": "OPENCODE_API_KEY", "temperature": 0.2, "lsp": { "enabled": true, "servers": { "typescript": "typescript-language-server --stdio", "python": "pyright-langserver --stdio" } } }

上面这段是一个示例性的结构，字段不一定在所有版本里都叫这个名字，但它表达了几个关键信息：默认模型是谁、API 地址指向哪里、密钥从哪里读、AI 生成参数默认是什么、LSP 服务怎么启用。model和api_base决定请求发往哪里，这通常是你改得最多的两个字段。api_key_env_var这个设计我特别喜欢，它让 key 不用明文写在 JSON 里，而是从环境变量读取，避免配置文件被误提交进 git 导致密钥泄露。

改完 JSON 之后，要重启 opencode 才会重新加载配置。这个问题在搜索词里也有体现，很多人改了模型配置发现不生效，其实就是没重启会话。有些版本支持配置热重载，但我不建议依赖它，你没法确定当前会话到底有没有拿到新配置。

3.3 ccswitch 的作用与配合方式

当你有多个模型配置要来回切换时，每次手动编辑 JSON 就很痛苦。ccswitch 这个工具就是解决这个痛点的：它本质上是一个配置切换器，可以管理多套模型服务商配置，需要哪套就切换到哪套，省去手动备份和改 JSON 的过程。

我常用的流程是：

1. 安装 ccswitch；
2. 在 ccswitch 里配置几套 profile：公司网关一套、个人 go 订阅一套、某个临时测试端点一套；
3. 让 opencode 的配置读取由 ccswitch 生成的配置，启动前先ccswitch use 公司网关；
4. 切换完之后再启动 opencode，它就能用到对应的模型端点和 key。

这种工作流特别适合同时接多个客户项目的场景：每个客户的代码仓库可能要求不同的模型策略，手动改 JSON 容易出错，用 ccswitch 切换之后，至少我不用再担心把 A 项目的 key 带到 B 项目的日志里。

3.4 “this model is not available in your country”怎么处理

这个报错我在排查模型配置时遇到过几次，直译是“该模型在你的国家或地区不可用”。很多人第一反应是找规避工具，但我的建议是别在这个方向上浪费时间。

这类限制通常来自模型服务商的分区授权策略，和你的 opencode 配置本身没有直接关系。一个模型端点在不支持的区域内被调用，服务端就会返回这个错误。正确的处理思路是：

• 先确认你所处区域是否被模型服务商支持，如果不支持，换一个对该区域开放的模型端点或服务商；
• 公司有合规的海外服务或网关时，走公司统一入口；
• 改配置用该区域可用的模型，比如有些模型在部分地区就是不可用，换成本地可部署的开源模型也能解决问题；
• 企业用户可以直接联系服务商或渠道伙伴，确认合规的接入方式。

我理解大家着急用模型的心情，但在企业项目里，绕过区域限制可能带来合规风险，用违规工具接公司项目更是大忌。最稳妥的做法永远是：选择一个明确支持你所在区域的模型源。

4. 实战：用 opencode 接手开发项目的完整打法

工具最终的检验场永远是真实项目。我接手的遗留项目数量不算少，Java、Python、TypeScript 都有。这里面最花时间的从来不是写新代码，而是“读懂旧的代码”。

4.1 第一步：让 opencode 先“进现场”

接手新项目时，我不会上来就让它改代码，而是先打开项目目录，启动 opencode，明确告诉它当前项目的基本信息。你可以用自然语言给它指令，让它先读 README、看依赖清单、梳理目录结构。opencc 的优势在于它在项目目录里运行的时候，能感知到 git 状态、最近提交、未提交的改动，所以它的上下文里天然包含“这个项目正在发生什么”。

我通常会这样开场：

看一下这个项目的 README 和 package.json，先告诉我这是一个什么项目、 技术栈是什么、我该从哪里入手了解现有代码。

它给出的回答会包含项目结构、核心模块、入口文件等，这个初诊比我自己翻目录快得多。但注意，任何 AI 工具的初次分析都可能有盲区，你要自己对项目结构有个基本判断，不能 AI 说什么就信什么。

4.2 第二步：用 LSP 让它真正“看懂”代码，而不是搜字符串

很多 AI 编码助手早期之所以在大型项目里表现不好，是因为它分析代码主要靠“按文件名搜 + 按字符串匹配”，遇到同名函数、动态调用、重载方法就容易懵。opencode 对 LSP 的支持，解决的就是这个问题。

LSP 全称 Language Server Protocol，语言服务器协议。它做的事情是：语言服务器常驻后台，对项目进行真正的语义分析，当你需要查看某个符号的定义、查找它的引用、获取它的类型信息时，LSP 能给出精确结果，而不是粗糙的文本匹配。

在 opencode 里启用 LSP 后，AI 提问“这个函数在哪里被调用”时，背后走的是语义级查询。比如你接手一个 TypeScript 项目，问它某个接口的所有实现类，它能给出真正继承了那个接口的类，而不是简单搜到相同字符串的文件。这个能力对接手大型项目尤其值钱。

配置 LSP 的重点是确保对应语言的 language server 已经安装到 PATH。TypeScript 通常用typescript-language-server，Python 用pyright-langserver，Java 项目则依赖 JDTLS。不同语言服务器的安装方式不同，opencode 的配置项里指定启动命令即可。LSP 首次启动时会对整个项目建索引，大项目要等一会儿，但一旦建立好索引，后面对话的准确率会有质的提升。

4.3 第三步：用 Skills 把团队规范固化下来

Skills 是我个人认为 opencode 最被低估的功能。简单说，Skills 是一种可复用的技能模块，每个技能包含一份说明文件（比如SKILL.md）和配套脚本，你告诉 opencode “这个项目里用某个 Skill”，它就会按照这个 Skill 里定义的工作流来处理问题。

举个例子：我接手的项目中有一套自己约定的错误码格式，新人接手时经常写错。我把它做成一个 Skill，里面写清楚错误码的编号规则、文档位置、更新流程。之后让 opencode 帮忙新增接口时，它就会自动按照这个规范去处理，不会再随手编一个错误码。

Skills 本质上干的是一件很朴素的事：把团队中“有经验的人才知道的规则”显式地交给 AI。这比你在每次对话里长篇大论地描述规范要可靠得多，因为对话有上下文窗口，但 Skill 可以在需要时随时加载。

4.4 第四步：Playwright 让前端 bug 不再靠肉眼复现

搜索词里“opencode playwright 怎么测试前端 bug”正好戳中接手老前端项目的痛处。老项目最经典的场景是：用户说某个按钮点了没反应，但你本地打开页面、手动点了一下，看起来又好好的。于是你花大量时间复现、看 console、猜原因。

opencode 结合 Playwright 之后，你可以直接把这个问题交给它。比如对它说：

用 Playwright 打开本地开发服务器，点击登录页面的“登录”按钮， 把控制台报错和网络请求结果记录下来，帮我分析为什么按钮没有跳转。

opencode 会调用 Playwright 相关脚本去驱动浏览器，真实加载页面、模拟点击、捕获 console 信息和网络请求，再把结果回传给你。这个能力的好处是，AI 是在“真实运行环境”里测试，而不是靠读代码猜问题。很多只有运行时才暴露的错误，比如某个资源加载失败、某个事件绑定在动态渲染节点上、某个跨域问题，都能被更快定位。

我的一次实际排查经历是：一个 Vue 项目里，按钮点击后要调一个接口做表单提交，但在生产环境总是不跳转。我让 opencode 用 Playwright 复现，它在 console 里捕获到一条 404 报错，原因是接口地址是相对路径，而生产环境部署在子目录下，路径拼接错误。这种问题静态看代码很难一眼发现，但浏览器实际跑一遍就藏不住了。

4.5 接手项目时 AI 能做什么、不能做什么

我可以负责任地说，opencode 能帮你在接手项目时省掉至少三分之一的理解成本。它擅长的是：

• 梳理项目结构，定位入口和关键模块；
• 理解已有代码的语义和调用关系；
• 按照项目既有风格生成新代码；
• 跑真实测试去复现和验证问题。

但它不能替代你去做架构决策，也不能保证它找出的“问题根因”一定是真相。你依然需要具备基本的代码阅读能力，并且对 AI 的每一个结论保持质疑。接手遗留项目的核心不只是“看懂代码”，还要判断哪些代码是可以动的、哪些是不能碰的雷区，这种分寸感，AI 目前给不了你。

5. 与 IDE 的配合：VS Code 和 JetBrains IDEA 插件实战

终端里的 opencode 确实够强，但它也有一个天然短板：不直接面对编辑器里的光标位置和选中代码。需要 AI 针对某个函数做修改、并且把改动直接应用回编辑器时，终端对话就有点绕。所以 opencode 提供了 VS Code 和 JetBrains IDEA 插件，用来打通“聊”和“写”之间的最后一环。

5.1 VS Code 插件：把选中的代码变成对话上下文

VS Code 插件我通常这样用：在编辑器里选中一段代码，右键选择“Send to opencode”，AI 就自动把选中内容作为上下文接收，我直接在侧边栏或者终端里跟它讨论。它给出的 diff 建议，我确认后可以直接应用到文件。

安装方式是最普通的：在 VS Code 扩展市场搜索 opencode，安装即可。插件本身需要识别本机的 opencode CLI，所以前面的命令行安装和 PATH 配置一定要先搞定，如果插件提示无法识别 opencode，回到第二节的 PATH 排查步骤去。

使用流水线其实很简单：

1. 在项目目录里先启动好 opencode 会话；
2. 回到 VS Code，选中一个函数或一个文件片段；
3. 把选中内容发给会话，询问“这段逻辑有没有问题”或“帮我重构这个函数”；
4. 拿到建议，按Tab之类的方式接受 diff，或者复制粘贴。

这个模式比纯终端对话高效，因为 AI 看到的就是你正在纠结的那段代码，不用再通过描述去猜测位置。

5.2 JetBrains IDEA 插件：Java 项目里的亲测体验

IDEA 里的 opencode 插件逻辑类似，但它在 Java/Kotlin 生态里表现得更好一些。一方面 JetBrains 本身带很强的语义分析能力，插件和它深度集成后，opencode 拿到的上下文质量更高；另一方面，Java 项目的重构往往涉及多文件、多符号联动，AI 的 diff 建议在 IDEA 里预览和分批应用比较方便。

我的习惯是 IDEA 插件用于代码分析和小的修改，大型重构还是会自己控制。比如让 opencode 找出某个 service 接口的全部实现，把选中的某段代码解释成文档，这种任务特别适合在 IDEA 插件里做；但如果是跨模块的依赖升级，我宁可自己动手，不让 AI 一把梭。

5.3 终端和 IDE 如何协作使用

有人可能觉得，既然有 IDE 插件，终端 CLI 是不是多余？我自己的经验是两个场景互补：

• 需要全局视野的时候用终端：比如“总结这个项目的架构”“这个错误日志可能的原因”“对比这两个文件的差异”，这些不依赖光标位置的任务，终端对话更自然，因为你可以直接给出项目相关的宏观指令；
• 需要精确修改的时候用 IDE 插件：比如“这个函数有 bug，帮我改”，这种任务必须绑定具体代码片段，在 IDE 里操作最顺手。

还有一点，当你同时在多台机器或远程服务器上操作时，终端版的价值是 IDE 插件无法替代的。SSH 到服务器上排查线上问题时，你不可能打开一个完整的 IDE，这时候 opencode 的单二进制优势就体现出来了。

6. 高频报错排查：从 server error 到模型不可用的真实排错链路

用 opencode 的过程中，报错在所难免。搜索词里“c:\windows\system32>opencode error: unexpected server error. check server logs”和“opencode this model is not available in your country”这两条非常典型。我把这些高频问题串成一条完整的排查链路写在这里，以后遇到可以按顺序查。

6.1 unexpected server error 的排查思路

这个报错直译是“意外的服务器错误，请检查服务器日志”。它有几种可能，我遇到的概率从高到低排序如下：

• 本地服务状态异常：opencode 的一些功能依赖本地后台服务，如果服务没起来或端口被占用，就会出现这个错误。先确认本地服务进程还在不在，必要时重启一下；
• API 端点不可达：你配置的api_base在当前网络环境中无法访问，可能是网络问题，也可能是服务商临时故障。可以在终端里用curl测试一下配置的端点地址是否正常返回；
• 模型服务商端故障或限流：高峰期 API 网关可能返回 5xx，opencode 没有把原始状态码透传出来，统一包装成了这个错误。这种情况换一个模型或者过一会儿再试；
• API key 失效或余额不足：有些服务商在 key 失效时不会返回清晰的 401，而是返回一个通用错误。

排查的时候，第一步永远是看日志。opencode 的日志目录一般也在用户配置目录下，Windows 在%APPDATA%\opencode\log，Linux 在~/.local/share/opencode/log或类似路径。打开最新的日志文件，搜索error或panic关键字，通常能看到比终端更具体的错误信息。

如果日志里出现的是网络超时，就先检查网络连通性；如果出现的是 401/403，就检查 key；如果出现的是某个请求的响应体直接携带模型服务商错误，就把响应体内容拿出来看，那里往往藏着真正的答案。

6.2 模型区域不可用：合规处理而不是找偏门

前文已经说过，这个报错本质是模型服务商的区域策略。我再补充一个真实场景：如果你同时配置了多个模型端点，A 点不可用但 B 点可用，opencode 并不会自动切换，它只会严格按照你当前配置里的model字段来请求。所以遇到这个错误时，第一件该做的事不是搜“绕过”方法，而是打开配置文件，看看当前默认模型是哪个，换成一个你确认可用的模型再试。

如果你确实需要某个特定模型，正确的路径是和企业服务商确认合规接入方式，或者在团队网关层面统一处理。反正我的原则是：项目需求再急，也不在这种安全边界问题上冒险。

6.3 配置改了不生效、版本升级异常、免费源失效

这三类问题相对琐碎，但出现频率很高。

配置改了不生效：先确认你改的是不是 opencode 实际读取的那个文件。你可以通过opencode启动时的日志，或者命令版参数查看配置加载路径。确认路径无误之后，彻底退出所有 opencode 相关进程，包括 IDE 插件的会话，然后重新启动。我的经验是，不要在一个长会话里测试配置变更，改完配置直接开新会话最省事。

版本升级异常：opencode 2.0 的配置和旧版可能有差异，如果你从 1.x 升上来，遇到报错先查一下官方更新日志，看看有没有破坏性的配置变更。我升级的时候就会把旧配置备份一份，然后以默认配置为基准重新填关键字段，而不是直接覆盖。

免费模型源失效：像我前面说的，免费源不稳定是常态。如果你看到 401、403 或者“model not found”这类的错误，大概率不是 opencode 的问题，而是那个免费端点已经下线或改了模型名。搜索词里“opencode hy3-free 下线了吗”就是典型例子。别在这种事上花时间，换回正式端点或者订阅即可。

6.4 一套通用的排错顺序

总结成一张表，方便你照着查：

这套顺序看起来简单，但能解决绝大多数 opencode 的使用问题。关键心态是：先确认自己这边没问题，再怀疑外部服务，不要一上来就想着绕路径。

7. 一些真正想说的经验

opencode 是我目前用下来在“接老项目”这个场景里最顺手的 AI 编码助手，但这不代表它是万能的。我真正想分享的经验就三条。

第一，别让 AI 替你做大方向的判断。它擅长的是在你明确的框架内执行任务，接手项目时架构层面的取舍、哪些技术债可以暂时不还、哪些模块牵一发动全身，这些判断一定要自己做。AI 的产出只是一个输入，不是最终答案。

第二，从小任务开始建立信任。刚接触 opencode 时，别一上来就让它重构核心模块，先让它读读某个文件、写写测试用例、解释一段你不熟悉的逻辑。几次验证下来，你自然知道它在哪些任务上可靠、哪些任务上还需要你盯着。我现在已经把好多重复性劳动交给它了，但每个改动我都还会过一遍 diff。

第三，把配置当作工程资产来管理。模型端点、key、Skills、LSP 配置这些东西，不值得每次换机器时重新折腾一遍。用 ccswitch 管好模型配置，把团队 Skill 收进版本仓库，LSP 的安装命令写进 README，这样团队里其他人接手时能少踩很多坑。

最后再分享一个小技巧：如果你主用 VS Code 或 IDEA，不妨把 opencode 的对话面板固定在一个位置，遇到需要修改的代码选中即可发送，不需要来回切换窗口。这个习惯一旦养成，你的编码节奏会被带得更顺，这也是我用了这么久之后最想推荐给新人的一个操作细节。