OpenCode使用系列课程连载（4）——Skills技能扩展篇：从会用到会驾驭
Excerpt
前面三篇，我们把 OpenCode 的基础使用、进阶技巧、性能优化和故障排查基本串起来了。如果你已经跟着折腾过一遍，大概率会有个感觉：这工具能干活，但还没到“越用越顺手”的状态。这点差距，很多时候不在模型，也不在 prompt，而在你有没有真正进入 OpenCode 的 Skills 这一层。没有 Skills，很多任务都得现聊现编；有了它，事情才开始按更稳定、更像老手的方式推进。这一篇就聊 Sk
前面三篇，我们把 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 不是命令，而是工作流能力包
很多人第一次看到 Skill，会下意识把它理解成“一个更高级的命令”或者“一个封装好的提示词模板”。
这么理解不算错，但会低估它。
更准确一点的说法是：
Skill 不是一条命令，而是一整套针对某类任务提前写好的方法论、步骤约束和工具使用规则。
普通命令更像“让工具做一件事”。比如打开文件、执行命令、切换模型，这种动作都很明确。
但 Skill 处理的，往往不是单点动作，而是一类经常反复出现、又很容易做歪的任务。
比如：
-
排查 bug，到底是先改还是先查根因？
-
写复杂功能，是不是应该先拆计划再开干？
-
任务做完了，是不是必须先验证，再声称“已经好了”？
-
涉及 PDF、Word、Excel 这种文档时，是不是该进入一套更专门的处理流程？
这些问题的共同点是：它们不是“会不会答”的问题，而是“该按什么套路做”的问题。
它相当于把一套比较成熟的做法提前塞进系统里。等你碰到对应任务时，OpenCode 就不是临时现想，而是沿着这套路径推进。
简单对比一下：
| 对比项 | 普通 Prompt | Skill |
|---|---|---|
| 作用方式 | 一次性指令 | 一套任务工作流 |
| 稳定性 | 更依赖临场发挥 | 更依赖预设方法 |
| 适用范围 | 单次任务 | 一类重复问题 |
| 典型场景 | 临时提问、补充说明 | 调试、规划、文档处理、验证等 |
说白了，Prompt 决定“你这次想干嘛”，而 Skill 更像在决定“这类事情应该怎么干”。
三、Skill 是怎么被加载的：知道一点原理，但别陷进去
这部分知道一点就够了，目的是理解：为什么有些 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，基本就是三件事：
-
把 Skill 放到 OpenCode 能识别的位置
-
让当前环境能读取到它
-
找个明确场景验证它确实生效了
更值得记住的是验证思路：
-
能不能看到它
-
能不能理解它适用于什么任务
-
在对应场景下，会不会真的按那套流程工作
如果你装的是 pdf 这种文档处理类 Skill，那验证方式就不该只是“列表里有没有它”，而应该是拿一个真实 PDF 任务试一下；如果你装的是 investigate，那就看它遇到异常时会不会先调查根因，而不是直接开改。
4.4 配置的核心，不是越多越好，而是越贴场景越好
很多人一开始接触 Skills，会有一种很程序员的冲动：既然能装，那我先装一堆再说。
但真到日常使用里，你会发现 Skill 不是浏览器插件，不是装得越多越有安全感。
更现实的思路是：
-
先补通用高频能力
-
再补你最常见的任务类型
-
最后再考虑项目级、团队级、私有化的特种 Skill
五、必装 Skills 装机指南：新手先装什么，办公装什么，开发装什么
如果你刚接触 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
docx
xlsx
investigate
writing-plans
verification-before-completion
这套组合的好处是比较均衡：
-
有技能发现入口
-
有办公与内容处理能力
-
有调试能力
-
有复杂任务规划能力
-
有收尾验证能力
六、全局 Skill、项目 Skill，到底怎么分工
很多人折腾一圈后，真正卡住的不是“怎么装”，而是“装在哪”。
记这一句就够了：
能跨项目复用的，优先放全局；只服务当前仓库和团队的，优先放项目级。
比如这些更适合放全局：
-
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 才算真正开始发挥威力。
