说实话2月7日那天开始折腾 OpenCode我一开始的情绪是拒绝的——桌面上已经躺着 Claude CodeVS Code 里还挂着 Codex再来一个命令行 Agent感觉就是多一个吃 token 的玩具罢了。但真正把 OpenCode 的基础命令跑通、再往 Skills 的方向深挖了一下之后我的看法变了。这个工具最大的价值不是又多了一个能写代码的 AI而是它把模型调度、项目上下文、技能复用这三件事拆得很干净尤其是 Skills 机制直接决定你能把 Agent 用到什么深度。这篇笔记就是当天从安装配置、基础使用、进阶订阅到 Skills 理解的完整记录尽量写细适合两类人刚接触 OpenCode 想少走弯路的以及已经在用但一直没搞懂 Skills 到底怎么玩、怎么跟 MCP 工具打配合的。1. 先盘一盘OpenCode 和 Claude Code 这类工具有什么不一样1.1 它解决的其实是一个模型锁死的问题如果你用过 Claude Code应该有过这种感觉工具是好工具但你只能在 Anthropic 的模型池子里选。今天想试试某个国产模型的编码能力不行工具不支持明天发现某个开源模型性价比很高还是不行切不过去。OpenCode 最核心的差异就是模型无关。它是一个开源的 AI 编码 Agent跑在终端里通过命令行直接读写你项目里的文件、执行命令、调用各类模型 API。你可以在同一个工具里切着用 Claude、GPT、国产模型或者各种兼容 OpenAI 协议的端点。对经常在不同客户环境、不同技术栈里切换的人来说这个不被绑定的价值比想象中大得多。我实测下来日常问答、写文档、改配置这类轻活用便宜模型甚至免费模型写业务代码、重构核心逻辑再切到中高端编码模型一个月下来的 token 开销能省将近一半。这在 Claude Code 那种模型锁定的架构里是做不到的。1.2 为什么 Skills 会成为 OpenCode 生态里的关键词Skills 这词最近在 GitHub 上热度很高从 claude code skills、codex skills 到 opencode skills几乎每个主流 Agent 工具都在收编这套体系。它到底是什么通俗讲Skills 就是给 Agent 准备的标准作业程序SOP一份结构化的技能定义文件加上若干辅助脚本告诉 Agent 遇到某类任务时先干什么、再干什么、调哪些工具、按什么流程产出结果。没有 Skills 的 Agent像是一个刚毕业的新人什么都会一点但遇到具体任务全靠临场发挥挂了 Skills 的 Agent像是老员工手把手写了操作手册接到任务直接按成熟流程执行稳定性和产出质量完全是两回事。你现在去 GitHub 搜 opencode skills、superpower skills、baoyu skills 这类仓库能找到大量现成的技能包覆盖 ppt 生成、数学建模、前端开发、安全检测等场景。配合 opencode 这类支持 Skills 机制的 Agent下载下来就能用这才是它真正拉开差距的地方。1.3 看完这篇你大概能带走什么后面内容我按当天的实操顺序来写先讲安装和环境准备把 Windows 上最常见的 cmdlet 报错排查清楚再讲基础操作尤其是如何导入一段程序代码并进行修改完善这个很多人都在搜的场景然后是进阶内容包括 opencode go 订阅、套餐和模型选择、桌面版和 IDE 插件协同最后是重头戏Skills 的原理、安装方式、推荐仓库和实战案例以及几个我在踩坑过程中觉得特别值得记录的排查链路。2. 安装与环境准备四条路径、一个必踩的坑2.1 三种主流安装方式OpenCode 的安装方式不少我当天分别试了命令行安装和桌面版简单整理一下安装方式适用场景注意事项npm 全局安装最常用适合开发者和重度用户Windows 下容易踩 PATH 的坑curl 一键脚本Linux/macOS 服务器或容器环境需要确认脚本来源可信桌面版不想碰命令行的轻度用户本质上是带 GUI 的封装功能略少于 CLI那两天我主要用的是 npm 方式。装完后顺手在三个地方跑起来Windows Terminal 里的纯终端环境、VS Code 的集成终端、还有 JetBrains IDEA 的插件面板。这里先不展开 IDE 集成后面单独讲。2.2 无法将 opencode 项识别为 cmdlet的完整排查链路这个报错太经典了几乎每个在 Windows 上通过 npm 装完 opencode 的人都会遇到一次opencode : 无法将“opencode”项识别为 cmdlet、函数、脚本文件或可运行程序的名称第一反应是安装失败其实不是。这个报错的本质是npm 全局安装的命令目录没有加入系统 PATHPowerShell 找不到可执行文件。排查链路我捋一下第一步确认包确实装上了。在终端里执行npm root -g拿到全局 node_modules 的路径。正常情况下 opencode 的可执行文件在这个目录的 .bin 子目录里Windows 上通常长这样C:\Users\你的用户名\AppData\Roaming\npm。第二步检查这个目录在不在 PATH 里。PowerShell 里执行echo $env:Path如果用 npm 安装的目录没出现在这段字符串里那问题就定位到了。第三步把目录加进用户 PATH[Environment]::SetEnvironmentVariable(Path, [Environment]::GetEnvironmentVariable(Path, User) ;C:\Users\你的用户名\AppData\Roaming\npm, User)改完重新打开一个终端窗口再执行opencode --version能正常输出版本号就说明解决了。这里有个小细节很多人改了 PATH 之后在当前窗口里继续跑命令发现还是报错就以为没生效。其实 PowerShell 的 PATH 变量是在窗口启动时读取的不会实时刷新必须新开一个终端。我当时也差点在这个地方绕晕。2.3 VS Code 和 JetBrains IDEA 插件接入OpenCode 的可玩性在 IDE 里会再上一个台阶。VS Code 的插件装完后你可以在编辑器里直接选中一段代码右键交给 OpenCode 处理不用切到终端去描述上下文JetBrains IDEA 插件同理。我个人的使用习惯是轻量改动直接在 IDEA 插件面板里完成涉及跨文件重构或者要 Agent 全局搜索定位问题时才切到终端里做深度对话。IDE 插件的优势是上下文就在眼前省去了 Agent 反复读取文件的步骤但终端模式的对话上下文管理更透明适合复杂任务。这两者不是替代关系更像是快捷入口和工作台的关系。2.4 模型接入API Key 和免费模型怎么配装好工具之后下一步就是接模型。OpenCode 支持通过opencode auth login交互式登录也支持在配置文件里手动填 API Key。这里专门说一下免费模型。我当天试了热搜里提到的 Muse Spark 1.3在 opencode 的模型列表里可以找到。对轻量级问答、生成注释、写简单的脚本片段免费模型完全够用。真要改复杂业务代码还是建议切到中高端模型成本可控的前提下质量和稳定性完全不同。如果你用的模型服务商同时提供多个模型建议在配置文件里把默认模型设成免费的日常高频的轻量任务都走它遇到重活再手动切换到付费强模型。这个策略我后面在模型选择那节还会细讲。3. 基础操作实测从能对话到能干事3.1 启动会话和基本命令终端里输入opencode就能进入交互式对话界面。界面里可以直接输入自然语言也可以使用/开头的斜杠命令。我当天用的最多的几个/models切换当前会话使用的模型/share生成分享链接方便把会话记录发出去/help查看所有可用命令实际用过几次之后你会发现 OpenCode 的 Agent 能力和代码库协作的能力才是重点。它不只是聊天机器人而是能真正读写项目文件、执行命令、在代码库中搜索定位的自动化助手。3.2 导入程序代码并修改完善的完整过程热搜里有一条是opencode 如何导入一段程序代码并进行修改完善这个场景太典型了——新手拿到一段不完整的代码不知道怎么让 Agent 参与进来。我用一个实际例子说明。假设你有一段处理 CSV 文件的 Python 脚本功能是读取数据并计算均值但你想让它同时支持异常值过滤和结果导出。第一步直接在对话里粘贴这段代码跟一句指令请分析下面这段代码找出其中可能导致计算结果不稳定的问题并帮我改进这一步的目的不是让 Agent 改写而是先让它读取和理解代码。Agent 会返回对代码逻辑的分析包括它发现的边界条件问题比如数据为空时报错、异常值未处理等。第二步给出明确的修改需求请修改这段代码增加异常值过滤功能使用四分位距IQR方法把统计结果保存到 result.txt代码保持单一文件结构添加必要的注释。这里的关键是要求要具体什么方法、什么输出、什么格式。描述越模糊Agent 越容易自由发挥结果往往不是你想要的。第三步Agent 给出修改后的完整代码同时说明改动了哪些地方。你可以直接复制回项目里跑一下验证通过后收工。整个过程中 OpenCode 做了三件事读取并理解代码、按需求设计修改方案、输出可用代码。这比单纯用网页版 ChatGPT 复制粘贴效率高的地方在于当代码量大了之后它可以通过命令行工具直接读取整个目录的代码而不是依赖你在对话框里手动粘贴。3.3 与整个代码库协作除了单段代码OpenCode 更擅长的其实是和整个代码库协作。我当天做的一个测试是在一个已有的 Django 项目里直接让它定位所有没有加索引的数据库查询。我只需要在终端里输入请扫描这个项目中的所有 models.py找出查询量较大但没有建索引的字段并给出添加索引的具体 migration 方案。OpenCode 会自己去读项目文件、逐个文件扫描、生成修改建议。整个过程不需要我手动打开任何代码文件它在项目的目录结构之上工作比 IDE 里的行级补全工具高了一个维度。这种项目级 Agent的能力才是把 AI 编码工具从补全工具变为协作者的分水岭。3.4 一个小而完整的实战案例再补一个完整的例子。我当天在做一个内部工具时给 Flask 接口写接口文档OpenCode 帮我做了以下事情读取了项目里所有路由文件提取出 GET/POST 接口清单对每个接口识别的入参和返回结构自动生成了 Markdown 格式的接口文档额外扫描出了三个接口缺少参数校验的问题这几件事要是手动做至少得小半天。OpenCode 全程用了不到十分钟而且它生成的文档质量已经有我八成功力了。这背后靠的就是 Agent 可以同时调起文件读写、命令行执行、代码解析等多种能力你想让它干活而不是聊天。4. 进阶玩法Go订阅、模型路由与多端协同4.1 opencode go 订阅和套餐怎么选在你已经能熟练操作基础和项目级功能之后接下来要解决的就是模型成本和多端配置管理的问题。opencode 官方提供 go 订阅服务本质上是一个托管订阅帮你把各家模型的 API Key 和用量管理统一了适合不想自己折腾多把 Key、不想研究各家计费规则的用户。Go 订阅的套餐设计逻辑大概分两类一类是按月固定费用包含一定额度的模型用量适合高强度日常开发另一类是偏按量付费的模式适合偶尔用一下的轻中度用户。选哪个取决于你的使用频率如果每天都要跟 Agent 对话超过一两个小时建议直接上固定套餐用超了再按量续整体成本比单独买多个 API Key 便宜如果只是偶尔用 Agent 写点脚本那用免费模型加上按量付费就足够。我这里给一个比较通用的选择框架估算你每周的 Agent 调用次数和 token 消耗量小于一个数量级的直接用按量稳定的日常重度使用固定套餐更划算。4.2 模型选择的思路免费模型打底、中高端模型攻坚热搜词里同时出现了opencode 免费模型和opencode go 订阅模型选择很多人其实纠结的是同一个问题到底该用哪个模型我当天的策略是双轨制日常轻量任务比如生成注释、写简单的函数、改配置文件、回答工具用法问题用 Muse Spark 1.3 这类免费或极低价的模型。这些任务对推理深度要求不高用强模型是一种浪费。复杂任务比如重构核心模块、设计数据模型、排查疑难 bug、跨文件架构调整切换到中高端编码模型。这类任务需要强推理能力便宜模型经常会在关键步骤上想歪。实际操作上我会在启动 OpenCode 后用/models先锁定一个主模型然后按任务复杂度临时切换。如果主模型是免费模型做复杂任务时切到中高端模型如果主模型已经是中高端模型日常轻活没必要往下切因为切换本身也有一点心智成本只要别让它闲着处理太琐碎的活就行。4.3 桌面版和 ccswitch 配置管理OpenCode 桌面版其实就是给不喜欢终端操作的人提供的一个图形入口下载安装后按界面提示登录模型即可。但如果你是重度开发用户我反而建议老老实实待在终端里因为 CLI 模式下你可以在任何目录自由切换工作区桌面版反而多了环境切换的开销。同时装了好几个 AI 编码工具之后OpenCode、Claude Code、Codex配置文件管理就成了大问题。每个工具都有自己的配置路径、模型 API Key、参数模板。我当天用到的 ccswitch 就是干这个的工具它把多套配置按项目或按场景分组切换时不用手动改配置文件。举个例子参与项目 A 时默认使用的是 OpenAI 系模型配 OpenCode参与项目 B 时公司内部要求走企业网关。用 ccswitch 建立两个 profile一条命令切到对应配置再也不用记配置文件路径和格式了。4.4 oh-my-claudecode 这类增强工具能帮你省多少事oh-my-claudecode 这个名字看起来是给 Claude Code 用的但它对 OpenCode 的使用体验也有实打实的提升。我理解的这类增强工具本质上是一套经过大量实战验证的配置集和命令别名内置了很多优化的提示词模板、常用工具调用指令和模型参数预设。我当天的体感是装完之后同样是让 Agent 分析一个项目输出质量明显更结构化。这是因为默认提示词已经帮我把项目结构扫描、代码规范检查、风险点分析这些步骤定成了固定流程Agent 不会再自由发挥跑偏。如果你是配置党这套东西值得折腾一下。如果只想快点上手用建议先跳过等基础跑通再回来否则容易在一堆配置项里迷路。5. Skills机制拆解Agent的职业技能到底怎么定义5.1 Skills 和普通 Prompt 的本质区别现在进入整篇的重头戏Skills 理解。前面我提到过一个比喻Skills 像是老员工写给新人的操作手册。这里必须把边界讲清楚它和普通 Prompt 有什么本质区别普通 Prompt 是一次性指令帮我写一个 Python 脚本读取 CSV 并计算均值。你说完Agent 做一次完事。下次遇到同样的需求你必须重新描述一遍而且因为措辞不同Agent 的理解可能也会有偏差。Skills 则不同它是一个封装好的能力单元带有一个结构化的技能说明文件定义了什么时候用、怎么用、按什么步骤执行、输出什么格式同时还可以带配套脚本。你把 Skill 装进 Agent 之后只要任务描述和这个 Skill 的场景匹配Agent 就会自动加载这个能力包按固定流程执行。更关键的是Skills 是可以跨工具共享的。你在 GitHub 上找到一个 claude code skills 仓库里面的技能包在 OpenCode 里也能用一个为 Codex 写的技能拿到 OpenCode 里同样能识别。生态互通这是 Skills 能火起来的重要推手。5.2 一个 Skill 的内部结构长什么样为了搞懂机制我当天手动拆了一个 Skill 包结构非常简单skill-name/ ├── SKILL.md └── scripts/ └── run.pySKILL.md 是这个技能的核心它通常包含两部分文件头部是一段 YAML frontmatter定义了技能的 name 和 description正文部分则是具体的执行步骤包括什么时候使用、关键操作步骤、输出要求、质量检查清单等。Agent 的运行逻辑是这样的接到用户任务后先看任务描述和各技能的 description 匹配度找到最匹配的 Skill然后读 SKILL.md按照正文里定义的步骤一步步执行如果需要更复杂的逻辑就去 scripts/ 目录下调用配套脚本完成。这套设计的好处是把人的方法论沉淀成了机器可执行的流程。你之前费神总结出来的项目复盘方法、代码审查清单、接口设计规范都可以写成 Skill以后每次遇到对应场景Agent 都会自动按你的规范做事。5.3 Skills 如何调用 MCP 工具热搜词里有一条skills 如何调用 mcp 工具这也是理解 Skills 机制最容易卡住的地方。先解释一下 MCP它是模型上下文协议Model Context Protocol可以简单理解成一个万能插座标准。各种外部工具数据库、文件系统、浏览器、第三方服务实现了 MCP 服务器之后Agent 只要实现了 MCP 客户端就能统一调用这些工具。Skills 和 MCP 的关系是Skill 负责流程编排MCP 负责具体能力的执行。一个 Skill 的 SKILL.md 里会写明这个流程的每个步骤需要调用哪些 MCP 工具遇到需要实际操作数据库、读取网页、调用外部 API 的场景Agent 就通过 MCP server 去执行。举个例子一个视频生成 Skills 包步骤拆解是分析用户需求 → 选择模板 → 调用视频生成 API → 导出结果文件。其中调用视频生成 API这一步就是通过对应的 MCP 工具完成的。你在 SKILL.md 里看到的可能是使用 vidmuse_generate_video 工具但实际上 Agent 是通过 MCP server 去调用它的。所以别把 Skills 和 MCP 搞混了MCP 是手Skills 是大脑里装的一套工作流程。没有 MCPSkill 只能做一些纯文本分析和代码生成类的活配上 MCPSkill 才能操作真实世界的外部工具。5.4 技能包的自动匹配与加载逻辑最后聊一下技能包的加载匹配逻辑。你装了很多 Skill 之后Agent 怎么知道当前任务该用哪个关键在 SKILL.md 里的 description 字段。这一句描述写得越准确、越有区分度Agent 匹配的准确率就越高。比如你要做一个数学建模类技能description 写清楚适用于数学建模竞赛中的问题分析、模型选型和论文结构生成效果就是比笼统写用于数学建模好得多。这也解释了一个我那天反复遇到的问题为什么某些 Skill 装了却不生效。大概率不是文件放错位置而是 description 写得太泛Agent 根本判断不出该在什么时候加载它。后面踩坑章节我会详细展开。6. Skills实战下载、安装、场景化推荐与自建6.1 npx skills add 命令和源码安装两条路装 Skills 最快的方式是命令行。当天我看到的最典型命令是npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这里拆解一下参数sandai-org/vidmuse-skillsGitHub 仓库地址--agent claude-code指定安装到哪个 Agent 的技能目录。当然你可以换成opencode-g全局安装对所有项目生效如果不加默认装到当前项目目录-y跳过交互式确认如果你想用 OpenCode对应的命令就是把--agent参数换成 opencode。这个命令的本质是自动克隆 GitHub 仓库把里面的 Skills 包放到对应的全局配置目录下。另一种方式是源码安装手动去 GitHub 上把仓库 clone 下来然后将里面每个 skill 子目录复制到 OpenCode 的 skills 目录。关于目录位置我当时实验下来OpenCode 会读取两个地方的 skills一是用户全局配置目录下的 skills 文件夹二是项目根目录下的.opencode/skills目录。全局装适合通用的技能项目里装适合跟当前项目强相关的专用技能。直接源码安装的方式就是git clone https://github.com/xxx/some-skills.git 复制对应技能目录到 ~/.config/opencode/skills/ 下 重启 opencode这种方式的好处是可定制性强方便自己改里面的脚本缺点是没有版本管理和依赖解析升级全靠手动。如果是常用技能我还是推荐用npx skills add这种自动安装方式。6.2 值得收藏的 Skills 仓库当天我逛 GitHub 逛到眼花这里列几个我觉得值得重点关注的方向不是单纯求多而是这些仓库刚好覆盖了 Skills 生态的典型玩法和场景。仓库/项目核心方向适合人群superpower skills大量通用工作流技能包想直接体验 Skills 能力的入门者mattpococks skills前端开发、类型安全的技能集合前端/全栈开发者baoyu skills中文用户友好的技能集国内开发者、内容创作者claude code skills 聚合仓库各种零散的实用技能汇总喜欢自己淘技能的人codex skills 相关仓库OpenAI Codex 生态的技能包同时用 Codex 的开发者以 superpower skills 为例它里面包含了代码审查、项目分析、需求拆解、文档生成等大量通用技能。装上之后你对 Agent 说一句帮我做一次项目健康度检查它就会自动按打包好的流程去扫描、分析、输出报告。这种体验是普通 Prompt 给不了的。6.3 典型场景拆解数学建模、PPT生成、前端开发场景一数学建模。这类技能包通常会把竞赛中的标准流程固化成步骤读题 → 问题分析 → 模型选型 → 数据预处理 → 建模计算 → 结果分析 → 论文结构生成。你只要把比赛题目输入给 Agent它就能按这个流程走比每次从零开始描述需求稳定得多。场景二PPT 生成。当 Skills 结合 MCP 工具时你甚至可以让 Agent 直接生成一份结构完整的 PPT 文件。它先分析你的主题生成大纲再把大纲按模块拆解最后调用 MCP 工具写入 PPT 文件。这个链路里Skills 管的是逻辑流程MCP 管的是文件生成这个动作。场景三前端开发。有些技能包专门针对页面实现包含组件拆解规则、样式规范、响应式适配清单。前端开发类的 skills 在 GitHub 上有不少搜索 coding skills github 就能找到一堆。这类技能的典型用法是根据这个设计稿实现页面Agent 会按技能包里的规范和流程产出更统一的前端代码。这里必须提一句安全合规网上能看到一些渗透测试方向的 skills这类技能包仅能用于你自己拥有合法授权的系统、或者搭建的靶机环境做授权范围内的安全测试绝不能在未授权的真实系统上使用。工具本身是中性能力边界和底线要自己守好。6.4 动手写一个最小 Skill看完别人的技能包强烈建议你动手写一个最小可用的 Skill把机制彻底跑通。这里给一个极简例子my-emoji-remover/ ├── SKILL.mdSKILL.md 内容如下--- name: emoji-remover description: 当用户需要清理文本中的 emoji 符号时使用。适用于内容清理、社交媒体文案预处理等场景。 --- 1. 读取用户提供的文本内容 2. 使用 scripts/remove.py 移除所有 emoji 3. 返回处理后的纯文本这个 Skill 本身逻辑不复杂但跑通之后你就理解了整个机制Agent 识别到清理 emoji的需求 → 匹配到这个 Skill 的名称和描述 → 读取 SKILL.md 里的步骤 → 按步骤执行。之后你再把它扩展成更复杂的技能本质上只是增加更多的步骤和脚本。我在实际使用中发现自己写 Skill 才是最有价值的玩法。因为只有你最清楚自己团队的项目规范、代码风格、交付质量标准把这些沉淀成 Skill等于把你的方法论复制给了 Agent以后每次自动执行它就是你的数字替身。7. 踩坑实录几个值得记录的问题与排查链路7.1 this model is not available in your country的排查思路这个报错不少人都遇到过当你在 opencode 里切换到某个模型时弹出一句this model is not available in your country。我当时的排查过程是这样第一步排除账号问题。登录模型服务商的控制台确认账号区域设置是否和自己的实际情况一致。有些服务商是按账号注册区域来决定可用模型的和实际连接位置无关。第二步确认是不是模型本身有区域限制。某些模型只在特定区域提供服务你当前所在区域不在允许列表里就会出现这个报错。这种情况的合规解法是放弃使用该模型换成同平台其他可用模型或者切换到别的模型服务商。第三步检查是不是配置里写错了模型名称。有时候你配置的模型 ID 拼写有误服务商返回的报错也可能比较笼统。换一个确定可用的模型再测试能帮助快速缩小问题范围。我的最终方案很简单不跟它较劲换用同一个供应商下其他可用的模型。AI 编码工具最重要的是任务能不能完成不是必须非某个具体模型不用。如果你确有业务需求必须使用某类受限模型建议走合规的采购和开通流程不要尝试任何绕过的操作。7.2 Skills 装了却不生效问题出在哪这是一条最容易让新手卡住的链路。我当天装好一个技能包之后发现调用时 Agent 完全没有识别到它。排查顺序如下第一步确认安装位置正确。全局技能要放在 OpenCode 的全局 skills 目录项目级技能要放在当前项目的 skills 目录。装错位置是最高频的原因。第二步重启会话。OpenCode 是在会话启动时加载技能列表的如果是运行中安装的技能当前会话不会自动识别重启一下通常就好了。第三步检查 SKILL.md 的格式。YAML frontmatter 里必须有完整的 name 和 description并且 description 要具体。如果描述太笼统Agent 在匹配时判断不出来等于没装。第四步用指令强制确认。你可以在对话里直接问 Agent你有哪些可用的技能或者技能 emoji-remover 是否已加载让它自己列出已识别的技能。这一步能快速判断到底有没有加载成功。我那天的问题最终定位在第二步——会话没重启白查了半天目录结构。7.3 多模型混用时行为不一致的问题前面我建议免费模型打底、中高端模型攻坚但这里有个坑如果你在一个会话里频繁切换模型会发现不同模型对同一个 Skill 的执行质量差异很大。免费模型经常只执行 SKILL.md 里的部分步骤或者跳过某些脚本中高端模型则执行得更完整。排查之后原因也清楚Skills 里的步骤本质上还是自然语言指令模型的指令遵循能力直接决定执行完整度。轻量模型在长流程任务上理解能力有限容易偷工减料。我的建议是在关键任务上固定使用同一个中高端主模型不要频繁切换。把免费模型留给那些不需要加载 Skill 的简单问答。如果你想用免费模型跑通全流程最好把 SKILL.md 的步骤写得再细一些每个步骤单独成段降低模型的执行难度。7.4 Windows 环境下的路径和权限问题最后补一个 Windows 特有的坑。全局 skills 目录如果放在系统盘某些受保护的位置可能会出现写入失败或者 Agent 读取不到的情况。我当时把全局目录放在用户目录下绕开了权限问题。如果遇到技能加载失败同时又是 Windows 系统先确认技能的目录和文件是否设置了只读属性然后检查路径是否包含中文或特殊字符。路径越简单越好全英文、无空格是兼容性最高的方案。8. 最后分享一点我的使用体会折腾完这一圈我最真实的感受是OpenCode 不是一个又一个 AI 编程工具它更像一个把模型选择权和技能复用权都还给用户的 Agent 平台。两天时间从安装配置、基础操作到进阶订阅再深入理解了 Skills 机制整个过程最大的收获不是学会了几个命令而是理解了技能化对 Agent 工作流的改变——你不再依赖临场发挥式的 Prompt而是可以把成熟的方法论沉淀成可复用的能力包。如果让我给刚入手的你一个建议我会说先把一个 Skill 完整跑通再上量。不管是从 GitHub 下载一个现成的还是自己手写一个最简单的把它在真实项目里跑出一次可用的结果你对 Skills 的理解会一下子通透很多。最后再分享一个小技巧日常用 OpenCode 时最好养成先让 Agent 复述任务、再执行的习惯。让它在动手前用自己的话描述一遍它将要做的修改看起来多了一步对话实际上能避免大量因理解偏差导致的返工。复杂任务尤其如此。这个小习惯帮我省下了不少 token也少踩了很多坑。