跳到主要内容

OpenCode使用系列课程连载（4）——Skills技能扩展篇：从会用到会驾驭

Excerpt​

前面三篇，我们把 OpenCode 的基础使用、进阶技巧、性能优化和故障排查基本串起来了。如果你已经跟着折腾过一遍，大概率会有个感觉：这工具能干活，但还没到“越用越顺手”的状态。这点差距，很多时候不在模型，也不在 prompt，而在你有没有真正进入 OpenCode 的 Skills 这一层。没有 Skills，很多任务都得现聊现编；有了它，事情才开始按更稳定、更像老手的方式推进。这一篇就聊 Sk

640.6

前面三篇，我们把 OpenCode 的基础使用、进阶技巧、性能优化和故障排查基本串起来了。

如果你已经跟着折腾过一遍，大概率会有个感觉：这工具能干活，但还没到“越用越顺手”的状态。

这点差距，很多时候不在模型，也不在 prompt，而在你有没有真正进入 OpenCode 的 Skills 这一层。

没有 Skills，很多任务都得现聊现编；有了它，事情才开始按更稳定、更像老手的方式推进。

这一篇就聊 Skills：它是什么，怎么配，怎么装，哪些值得先装，去哪里找，以及怎么慢慢搭出一套适合自己的 Skill 体系。

如果只用一句话概括这一篇的重点，那就是：Skills 不是给 OpenCode 多加几个名字，而是把很多事从“临场发挥”变成“按流程做对”。

一、为什么说 Skills 才是 OpenCode 的灵魂​

前面三篇解决的，其实是三个问题：

  • 第一篇：先把 OpenCode 装起来、跑起来、用起来。

  • 第二篇：让 AI 更懂你的项目和你的表达方式。

  • 第三篇：把性能、配置、排障这些现实问题解决掉。

但如果你问我，OpenCode 真正和“普通 AI 聊天窗口”拉开差距的地方在哪，我会把票投给 Skills。

很多 AI 工具的工作方式，本质上还是“你提一个要求，它回你一段结果”。结果稳不稳、靠不靠谱，很多时候主要看模型临场发挥。

OpenCode 不是不吃 prompt，但它更强的地方在于：它允许你把某一类任务的做法，提前打包成一套可复用的工作方式。

比如调试问题时，不是上来就开始改；复杂需求进来时，不是直接一把梭；准备收尾时，也不是 AI 说一句“应该已经好了”就算数。这些更靠谱的做法，都可以交给 Skills 来兜底。

不会 Skills 的时候，你用到的更多还是一个“通用型 AI 助手”；会用之后，OpenCode 才更像真实工程流程里的工具。

所以前三篇讲完后，第四篇最该进的就不是新命令，而是 Skills 这一层。

二、先搞懂：Skill 不是命令，而是工作流能力包​

640.7

很多人第一次看到 Skill，会下意识把它理解成“一个更高级的命令”或者“一个封装好的提示词模板”。

这么理解不算错，但会低估它。

更准确一点的说法是：

Skill 不是一条命令，而是一整套针对某类任务提前写好的方法论、步骤约束和工具使用规则。

普通命令更像“让工具做一件事”。比如打开文件、执行命令、切换模型，这种动作都很明确。

但 Skill 处理的，往往不是单点动作，而是一类经常反复出现、又很容易做歪的任务。

比如：

  • 排查 bug，到底是先改还是先查根因？

  • 写复杂功能，是不是应该先拆计划再开干？

  • 任务做完了，是不是必须先验证，再声称“已经好了”？

  • 涉及 PDF、Word、Excel 这种文档时，是不是该进入一套更专门的处理流程？

这些问题的共同点是：它们不是“会不会答”的问题，而是“该按什么套路做”的问题。

它相当于把一套比较成熟的做法提前塞进系统里。等你碰到对应任务时，OpenCode 就不是临时现想，而是沿着这套路径推进。

简单对比一下：

对比项普通 PromptSkill
作用方式一次性指令一套任务工作流
稳定性更依赖临场发挥更依赖预设方法
适用范围单次任务一类重复问题
典型场景临时提问、补充说明调试、规划、文档处理、验证等

说白了，Prompt 决定“你这次想干嘛”，而 Skill 更像在决定“这类事情应该怎么干”。

三、Skill 是怎么被加载的：知道一点原理，但别陷进去​

640.8

这部分知道一点就够了，目的是理解：为什么有些 Skill 会自动触发，为什么有些要手动调用，为什么换个项目之后表现又不太一样。

可以这样理解：

模型本身像发动机，Skill 像当前任务启用的一套驾驶模式。

当某个 Skill 被加载时，系统会把与它相关的说明、步骤、约束、注意事项一起带进当前上下文。模型看到这些以后，做事方式就会发生变化。

变化的不是“它能不能回答你”，而是“它会按什么方式回答你、推进任务、调用工具、约束自己”。

比如：

  • 没有 Skill 时，模型可能直接开始动手。

  • 有 brainstorming 时，它会先澄清，再设计，再确认。

  • 有 investigate 时，它会更强调先找根因，再谈修复。

  • 有 verification-before-completion 时，它会要求先验证结果，再声称完成。

再记一件事：

Skill 不是永远常驻的，它通常是按任务类型按需加载，或者由你明确触发。

同理，全局 Skill 和项目 Skill 的差异，本质上也可以理解成“作用域不同”。

  • 全局 Skill 更像你自己机器上的通用驾驶模式。

  • 项目 Skill 更像这个仓库、这个团队、这套工程约定里的专属玩法。

你记住一句话就够了：

Skill 的价值，不是给模型多塞一点知识，而是给它多塞一套更靠谱的做事方式。

四、Skills 怎么看、怎么配、怎么装​

这一节主要解决四个问题：

  • 当前环境里到底有哪些 Skill

  • 这些 Skill 从哪来

  • 怎么判断一个 Skill 能不能用

  • 如果想加新的 Skill，该往哪放、怎么验证

4.1 先看：当前到底有哪些 Skills​

很多人折腾 OpenCode 一段时间后，对模型、命令、配置文件都挺熟，但一问“你现在环境里到底有哪些 skill”，往往就开始凭印象回答。

更稳的做法是：

  • 先查看当前环境能识别到哪些 Skill

  • 再看每个 Skill 解决什么问题

  • 最后决定哪些值得常用，哪些只是偶尔备用

别把这一步当成“查库存”，它更像是在看你这把瑞士军刀到底装了哪些刀片。

4.2 再看：这些 Skill 是从哪来的​

通常来说，你在 OpenCode 里看到的 Skill，来源大致有几类：

  • 系统或环境预置的内置 Skill

  • 全局范围安装或配置的 Skill

  • 当前项目目录中定义的项目级 Skill

  • 某些团队自己沉淀出来的私有 Skill

Skill 不是“账号级魔法”，它是有实际来源和实际作用域的。谁提供它，它就从哪来；它放在哪，它就在哪个范围里起作用。

4.3 然后才是：怎么配、怎么装​

安装 Skill，基本就是三件事：

  1. 把 Skill 放到 OpenCode 能识别的位置

  2. 让当前环境能读取到它

  3. 找个明确场景验证它确实生效了

更值得记住的是验证思路：

  • 能不能看到它

  • 能不能理解它适用于什么任务

  • 在对应场景下，会不会真的按那套流程工作

如果你装的是 pdf 这种文档处理类 Skill，那验证方式就不该只是“列表里有没有它”，而应该是拿一个真实 PDF 任务试一下；如果你装的是 investigate，那就看它遇到异常时会不会先调查根因，而不是直接开改。

4.4 配置的核心，不是越多越好，而是越贴场景越好​

很多人一开始接触 Skills，会有一种很程序员的冲动：既然能装，那我先装一堆再说。

但真到日常使用里，你会发现 Skill 不是浏览器插件，不是装得越多越有安全感。

更现实的思路是：

  • 先补通用高频能力

  • 再补你最常见的任务类型

  • 最后再考虑项目级、团队级、私有化的特种 Skill

五、必装 Skills 装机指南：新手先装什么，办公装什么，开发装什么​

640.9

如果你刚接触 Skill 生态，很容易走两个极端：要么完全不装，要么一口气装二十个。

更靠谱的方式不是“装得多”，而是按场景补能力。

我建议直接分三档来装：

  • 新手通用档：先解决“我不知道该装什么”

  • 办公生产力档：先把 PDF、Office 这些高频文档能力补起来

  • 开发进阶档：把排障、规划、验证这几个高价值环节补齐

5.1 新手先装什么：先把“技能发现能力”装上​

如果只能先装一个，我优先推荐：find-skills

很多人不是不会用 OpenCode，而是根本不知道“这件事原来已经有现成 Skill 可以接管”。

这时候，find-skills 的作用就出来了。它像一个技能搜索入口，帮你从“靠猜”进入“按需发现”。

5.2 办公和内容生产先装什么：文档处理四件套​

这一组可以直接打包记：

  • pdf

  • docx

  • pptx

  • xlsx

它能直接把 OpenCode 的适用范围，从“写代码工具”扩到“日常生产力工具”。

你一旦把文档类 skill 补上，它处理的就不只是源码文件了，还包括：

  • PDF 提取、合并、拆分、OCR

  • Word 文档整理、改写、结构化输出

  • PPT 内容读取、改稿、重组

  • Excel / CSV / TSV 的清洗、整理、转换和分析

其中最值得单独点名的是 pdf。这东西谁都离不开，谁都嫌它难处理，真碰上抽文本、并文件、做 OCR 的活时，专门的 skill 会特别值钱。

5.3 开发进阶先装什么：补齐最容易翻车的三个环节​

这一组优先补这三个：

  • investigate

  • writing-plans

  • verification-before-completion

一句话概括：它们刚好卡在三个最容易把任务做歪的地方。

investigate 负责把调试拉回根因分析；writing-plans 负责把复杂任务先拆清楚再动手；verification-before-completion 则专治“事还没验，就先说好了”。

5.4 一份够用的“最小必装清单”​

如果你不想一开始装太多，可以先从下面这份最小清单起步：

find-skills
pdf
docx
xlsx
investigate
writing-plans
verification-before-completion

这套组合的好处是比较均衡：

  • 有技能发现入口

  • 有办公与内容处理能力

  • 有调试能力

  • 有复杂任务规划能力

  • 有收尾验证能力

六、全局 Skill、项目 Skill，到底怎么分工​

640.10

很多人折腾一圈后，真正卡住的不是“怎么装”，而是“装在哪”。

记这一句就够了：

能跨项目复用的，优先放全局；只服务当前仓库和团队的，优先放项目级。

比如这些更适合放全局：

  • pdf

  • docx

  • pptx

  • xlsx

  • find-skills

  • verification-before-completion

但如果是下面这些，就更适合项目级：

  • 某个仓库专用的发布流程

  • 某个团队约定好的测试方式

  • 和项目目录结构、技术栈、部署规则强绑定的工作流

  • 公司内部特有的私有脚本、规范或平台接入说明

这一点官方文档说得很清楚，OpenCode 会从项目和全局的多个兼容路径里发现 SKILL.md，常见位置包括：

一、为什么说 Skills 才是 OpenCode 的灵魂​

  • 项目级：.opencode/skills/<skill-name>/SKILL.md

  • 全局级：~/.config/opencode/skills/<skill-name>/SKILL.md

  • 兼容 Claude 风格：.claude/skills/...、~/.claude/skills/...

  • 兼容 agent 风格：.agents/skills/...、~/.agents/skills/...

说得直白点：

全局要轻，项目要准。

七、4 个高价值 Skill 的实战示例​

如果没有实际场景，前面的内容还是容易显得像在介绍工具目录。

所以这一节我挑 4 个比较有代表性的 Skill，看一下它们分别适合什么场景。

7.1 find-skills：不知道装什么时，先别猜​

当你明确知道自己有个需求，但不知道有没有现成 skill 可用时，最稳一点的方式，就是先用 find-skills 缩小范围。它的价值不是替你做决定，而是把“靠运气碰”变成“按需求找”。

7.2 pdf：给 PDF 这位老朋友一点现代化待遇​

如果你经常处理技术资料、扫描件、合同、方案、培训材料，那 pdf 基本属于装上就不太想卸的类型。它能把提取内容、合并、拆分、OCR 这些零散又麻烦的动作收拢起来，不用每次重新拼工具链。

7.3 investigate：真正排障，不是直接开改​

很多调试失败，不是因为不会修，而是因为根因判断错了。investigate 的好处，就是它会把任务拉回正确节奏：先调查、先收集线索、先验证假设，再决定改哪里。

7.4 writing-plans：复杂任务别热血上头​

这个 Skill 适合那种你一看就知道不是两分钟能搞完的事。它的价值，就是先把事情拆开，先把顺序排好，先把影响面想清楚。工程里最浪费时间的，往往不是写计划，而是没计划。

八、去哪里找更多好 Skill​

Skill 生态现在已经不小了，但越到这时候，越不能见到一个就往自己环境里装。

更靠谱的做法是：

  • 先找可信来源

  • 再看适不适合自己的场景

  • 最后才决定要不要装进常用环境

下面这几个站点都值得收藏。

8.1 skills.sh​

这是现在比较有代表性的公开目录之一。它的好处是直观：能搜、能看热门技能、能看到不少公开技能集合，适合作为第一站。

8.2 SkillsMP​

这个站更像一个 Skill Marketplace，也就是技能市场。它的特点是覆盖量大、搜索维度多、社区感更强，适合做更大范围的查找和筛选。

8.3 SKILLS.pub​

它可以作为值得关注的公开资源入口之一，帮助你更快发现不同作者、不同方向、不同风格的 Skill 资源。

8.4 官方文档与教程型站点也别跳过​

除了技能站本身，也建议把官方文档和教程型资源一起收藏。资源站适合找灵感，官方文档适合防止你把事做歪。

九、怎么搭建属于你自己的 Skill 体系​

看到这里你大概也能感觉到：Skill 这东西最怕的不是没有，而是装得没章法。

最后给一个比较务实的三步法。

9.1 第一步：先补通用能力​

先把那些在多数项目里都能复用的能力补上。

比如：

  • find-skills

  • pdf

  • docx

  • xlsx

  • verification-before-completion

9.2 第二步：围绕高频场景继续加​

想清楚你最常做的事是什么。

如果你经常排障，就优先补调试类 Skill；如果你经常做复杂需求，就优先补规划类 Skill；如果你经常写文档、做材料、处理 PDF 和表格，那就优先补文档类 Skill。

别追着流行走，先追着高频场景走。真正能留下来的 Skill，往往不是“网上都在装的那个”，而是你每周都能用到的那个。

9.3 第三步：再沉淀项目专属 Skill​

等你在某个项目里反复碰到同一类流程时，再考虑把它沉淀成项目级 Skill。

比如：

  • 某套固定发布流程

  • 某个仓库特有的测试顺序

  • 某类内部脚本调用方式

  • 某个团队长期坚持的开发约束

当这些东西开始稳定重复时，把它们收进项目级 Skill，价值就会很高。到这时候，Skill 就不再只是“拿来用的资源”，而开始变成你团队工作方式的一部分。

结语​

如果把前三篇看成是在教你怎么把 OpenCode 用起来，那这一篇我们聊的是：怎么把它用顺、用稳、用成自己的节奏。

Skills 最有意思的地方，不是界面里多几个名字，而是很多原本靠经验、靠习惯、靠临场发挥的事情，开始变成更稳定的工作流。

OpenCode 的上限，不只由模型决定，也不只由 prompt 决定，很大程度上取决于你有没有把合适的能力用 Skills 组织起来。

所以别急着一口气装一堆。先装最常用的，先补最刚需的，先把自己的节奏跑顺。等你慢慢形成一套属于自己的 Skill 组合之后，Skills 才算真正开始发挥威力。

Bottom GIF
Top GIF