OpenCode Skills 必装合集详解：让 AI 从实习生变熟练工

写这篇东西之前，我一直在琢磨一个问题：同样用 opencode，为什么有的人身边的 AI 像熟练工，交代一句就能把代码审查、提交信息、接口文档全收拾利索，而有的人的 AI 像个只会接话的实习生，问一句挤一句？差别不在大模型本身，而在你给它配了什么“技能”——在 opencode 里那叫 skill，一个封装好的指令包。

我自己的 opencode 配置文件里，前前后后装过几十个 community skill，淘汰来淘汰去，最后留下的就这么十几个。它们不是那种花里胡哨的提示词模板，而是真正能在日常开发里帮你省时间的工具。今天就把我筛选出的必装合集拿出来逐个拆解，讲清楚每个 skill 解决什么问题、内部的逻辑是什么、实际用的时候该注意什么。照着装一套，你会在下一周的工作里明显感觉到，AI 的响应水平完全不一样了。

1. 关于 OH My OpenCode skills，先说说它们到底是什么

有些朋友一上来就问我“skill 是不是就是 system prompt？”不完全是。opencode 里的 skill 更接近一套“行为协议”：它包含触发条件、完整的工作流程、输出格式要求，甚至还能挂载额外的脚本或配置文件。普通 prompt 是你每次都要把话说全，而 skill 是让 AI 在看到特定场景时，自动按你最满意的方式去干活。

我举一个最直观的例子。你让 AI “帮我检查这段代码”，甩一句 prompt 过去，它大概率只能帮你看看语法错误和明显 bug。但一个设计良好的 code review skill，会先读取你的 git diff，再对比项目里的代码风格约定，检查单测覆盖，最后按优先级输出一份包含问题代码位置、严重级别、修改建议的报告。这不是靠大模型“聪明”，而是 skill 里把检查清单写清楚了。

为什么单独的 prompt 做不到？原因在于上下文窗口和注意力分配。如果你不规定工作流程，AI 只会选择它觉得最顺手的做法，而不会主动去跑测试、翻历史记录。Skill 本质上就是给你的人工智能助手装了一套“标准作业程序”，让每次交互都有稳定的质量下限。这也是我为什么建议新手别急着自创 skill，先把社区里验证过的必装合集用熟，再去动刀改。

说到“OH My OpenCode”，可以理解为社区里很流行的一套 skill 增强方案。它把散落在各处的 skill 做了分类整理，推荐给 opencode 用户直接安装。当然，不必非要装某个特定的整合包，重点是理解每个 skill 的价值，然后按需挑选。

2. 我最先装的 5 个通用 skills

2.1 Code Review：把 AI 从语法检查器变成团队导师

先聊聊 code review。这是我最先安装、也是碰过最多坑的 skill。好的 review skill 会告诉 AI：你要站在一个经验丰富的老工程师角度，而不是往代码里挑刺。我用的这个 skill 内部定义了一套五级问题分级——阻断级、严重、建议、风格、疑问。它要求 AI 对每个问题都给出仓库里的具体文件路径、行号，以及为什么你觉得这是个问题。

实际用下来，最惊喜的是它要求 AI 在审查前先自行生成一份“本地最小复现步骤”。比如发现某个函数可能越界，skill 会指示 AI 写一小段测试代码去验证，而不是光靠肉眼猜。这一步极其关键，能过滤掉大量假阳性问题。我一度觉得 AI 审查不靠谱，就是因为之前用的普通 prompt 会让 AI 把“可疑”当“确定”，改了一堆其实没毛病的东西。

安装之后你还需要做一个小调整：把 review 的触发命令从手输斜杠改成 git 提交前自动执行。配合 opencode 的命令别名机制，我只需要在提交前输入/review，它会自动拉取最近一次提交的 diff，按 skill 里的格式输出审查结果。整个过程不需要把代码复制粘贴到对话框，非常顺手。

2.2 Commit 信息规范化：一个被严重低估的效率神器

很多人觉得 commit message 随手写写就行，不值得为一个 skill 装包。但你试试在团队协作里面对几十条“fix bug”“update”的时候，就会明白那个痛苦。我装的这个 commit skill，优势在于它不只是生成格式化的信息，它会先跑git diff --stat和git diff，分析改动的文件类型、变更范围，再按照 Conventional Commits 规范去生成。

这里的门道在于，它还会参考你最近五条历史 commit 的风格。如果你团队习惯用中文写提交说明，它就不会自作聪明地输出英文；如果历史里喜欢加 issue 编号，它也会自动补上。这一点是用纯 prompt 很难实现的，因为你需要让 AI 先理解仓库的 commit 历史，然后再决定表达风格。

我在不同语言的项目里都试过。一个 Python 后端项目和一个前端工程，同样的改动内容，skill 给出的 commit message 侧重点完全不同。比如 Python 项目它会更强调模块功能和依赖变化，前端项目则会把性能影响、UI 表现写进 description。这不是大模型的泛化能力，完全是 skill 配置里的检查项起了作用。

2.3 API 接口文档生成：从代码反推出文档，省下写接口文档的半天时间

写接口文档是我最抗拒的杂活之一，也是我认为 AI 最该干的活。市面上不少工具能生成 OpenAPI 文档，但 opencode 的这个 skill 走的是另一条路线：它不直接生成 YAML 文件，而是先读取路由定义、序列化器、控制器层的代码，提炼出一个带业务语义的接口描述，再输出成 Markdown 格式的文档，方便直接放 wiki。

关键点在它内部定义了一个三维分析流程：第一维看 HTTP 路由参数与校验规则，第二维看业务逻辑中的状态码分支，第三维看数据库模型的字段约束。三个维度合并之后，生成的文档会包含每个接口的权限要求、异常场景、字段格式要求。这些信息散落在代码各处长，人工整理容易漏，由 skill 驱动 AI 去全文检索再汇总，反而更可靠。

我在一个模拟项目 X 上实测过，一个三十多个接口的后端服务，它生成的文档初稿基本能用，错的只是几个枚举值的描述不够准确。改一版就能交付。我的心得是：使用这个 skill 之前最好先让 AI 读一遍项目的 README 和路由入口，否则它对某些业务术语会理解偏。

2.4 技术方案与架构图：从需求到落地设计，AI 帮你理清边界

技术方案设计这事，很多时候不是想不到思路，而是找不到合适的分析框架。我用的这个架构设计 skill 模板里规定了一套五段式写法：背景与目标、方案对比、技术选型理由、数据流设计、风险与回退。要求 AI 先整理约束条件，再输出方案，而不是一上来就丢出一个“推荐做法”。

它在实际工作中的用法很灵活。比如我要设计一个数据同步模块，可以直接把需求背景丢给 AI，它会按 skill 的流程先列出三个候选方案，每个方案用表格做对比，最后给出推荐。最值钱的是，它会主动指出“方案B在数据一致性上有风险”这类问题，还会建议补充哪些监控指标。

架构图画不了，这是个遗憾，但 skill 能输出 Mermaid 源码和一些结构化的文本描述。因为内容安全等考虑，我这里就不贴图表格式了。实际用的时候，你可以让它在描述数据流时，把所有步骤写成一个有序列表，这样你再画图就快多了。

2.5 重构安全网：让 AI 帮你把“动代码”变成“可验证的小步走”

直接让 AI 做重构，它经常会给你整出一份大改动的 diff，看得人心惊胆战。后来我装的这个重构 skill，内置了“小步重构”策略：每次最多重构一个函数或一个模块，并且要求 AI 在改动前后都必须跑一遍相关测试，测试通过才继续下一步。

它的提示词里有一个很具体的执行顺序——先定位所有引用点，再列出改动影响面，接着才写新代码。也就是说，AI 先帮你做影响分析，再动手。这样生成的改动就谨慎很多，不会再出现“为了优化这个函数，结果把其他调用的地方全都改了一遍”的尴尬局面。

配合代码评审 skill 一起用，效果翻倍。我就遇到过 AI 提出一个重构方案，从代码看完全没问题，但影响分析里漏了一个定时任务的调用点。重构 skill 的清单这次起了作用，它在执行前要把所有影响的调用点列出来，最后检查阶段揪出了那个漏网之鱼。这种细节是从实际坑里学到的，说明书里不会告诉你。

3. 面向日常开发的增强型 skills

通用型的五个装完之后，日常编码会顺手很多，但要说质变，还得看下面这几个针对具体场景的增强型 skill。

3.1 数据库操作助手：读库、查数据、看索引，一步到位

开发过程中我们经常要连数据库查东西，反正我是懒得记那些命令参数和连接串。这个数据库 skill 出现得特别及时。它做的事情是：识别项目里的数据库配置，自动拼好连接命令，然后根据你的自然语言问题生成并执行 SQL。

先说原理。它内部预设了若干种数据库方言的处理分支——MySQL、PostgreSQL、SQLite 都支持，我这个插件会通过解析连接字符串里的协议头来区分方言，再调用对应的命令行客户端。它还会判断当前是不是安全环境，如果检测到不是只读连接，涉及到写操作的请求会被拦下来，必须二次确认。这个安全兜底设计非常关键，我见过不少 AI 工具在数据库上栽跟头，就是因为缺少这一层防护。

我用得最多的是查看慢查询和索引状态。只要说一句“帮我查一下 user 表里有没有冗余索引”，它会自己跑一遍SHOW INDEX，然后对比查询计划，列出可删的索引。这些事情以前要开一个数据库管理工具，一个个点，现在一句话就能出结果。

3.2 Docker 容器排查：从日志到资源占用，一条龙问到底

微服务一多，排查容器问题就成了日常。我装的这个 skill 帮我省掉了很多从乱糟糟的日志里找线索的时间。它的核心思路是分步诊断——先看容器的健康状态，再看资源占用，然后看日志的异常片段，最后给出可能的原因列表。

操作方式也不用记 Docker 命令。你直接跟它说“看看订单服务为什么老是重启”，它会自动docker logs检查退出码，再查个docker stats看内存占用，最后把排查结论以“时间线 + 可疑点”的形式整理出来。实测下来，它对“日志里出现 out of memory”这类问题的判断比我快，因为它会先把内存相关日志筛出来，再关联进程的 OOM 记录。

这个 skill 的工艺细节在“日志采样策略”。完整日志往往几千行，它不会一股脑塞进上下文，而是先尾随最后两百行看尾部异常，再结合错误关键字往回翻。这样既不会烧掉上下文窗口，又能快速定位问题点。这个设计思路也提醒了我，好的 skill 本身就应该懂得节制，不是数据越多越好。

3.3 测试用例生成与执行：从“写用例”到“跑用例”闭环

让 AI 写测试用例是一件很讨喜的事，但你要是直接说“给这个函数写单测”，它写出来的东西往往只覆盖正常路径，边界一碰就断。我用的这个测试 skill，解决的就是覆盖率问题。

它会在生成测试之前先读取函数的签名、核心逻辑和依赖项，然后要求自己列出至少五个测试角度：正常输入、边界值、异常输入、依赖失败、超时场景。最让我惊喜的是，它会主动判断某个用例是不是“假阳性”——也就是测试虽然挂了但代码其实没错，这种问题在涉及时间或随机数的函数里特别常见。

执行环节也是闭环的。生成完测试文件它会直接跑起来，跑完把失败结果反馈给用户，还会基于失败信息自己修改断言。我常常就看着它写测试、跑测试、改测试，循环两三轮，一个模块的测试就整洁不少。如果你项目里测试覆盖率要求高，这个 skill 建议排在前排装。

3.4 Git 历史分析与分支策略辅助：提交记录里的“数据挖掘”

这个 skill 是我为了解决一个具体痛点才装的：理解一段陌生代码的来龙去脉。以前拿到一段看不懂的逻辑，我只会git blame，看每一行是谁改的、什么时候改的。但是 blame 只能告诉你个名字和日期，上下文还不够。

有了这个 skill，可以深入好多：它会列出指定文件的所有历史提交，按主题聚类，分析代码演化的阶段。比如一个支付模块，它会告诉你“第一阶段加了支付入口，第二阶段修复了并发问题，第三阶段重构了结算逻辑”。这对接手老项目的人来说，真的是救命级别的功能。

它还能辅助做分支清理。输入git branch --merged的结果，它会判断哪些分支已经被合并过、可以安全删除，哪些含有独特提交需要保留。用一次之后我就再也回不去手动看了，效率提高很多。不过要留意它必须读完整 git 历史才能做判断，仓库特别大的时候，首次运行会明显变慢。

3.5 接口联调与 Mock：前后端分离场景下的隐形助手

这个 skill 其实是我后来才发现的好东西。它主要解决一个场景：后端接口还没写好，前端页面已经需要接口字段来联调了。AI 会基于已定义的接口文档生成一个本地 Mock 服务，字段结构和真实接口保持一致，返回值规则可配置。

实操中我只需要把 OpenAPI 文档或者以往的接口代码丢给它，它会自己用 Node 起一个临时服务，路由和真实约定一致。切换真实接口的时候，只改配置里的 baseURL 就行。这个能力自己写脚本也能做，但 skill 做得很顺滑的一点是，它会把 Mock 数据的样本一起生成出来，各种边界值、错误码都会模拟到。

现在很多项目都在前后端并行开发，这个 skill 的价值会越来越被看到，建议配合接口文档生成那个 skill 一起装，天生一套。

4. 安装配置与最佳实践

4.1 安装方式与目录规范

opencode 的 skill 安装方式在社区版和稳定版之间略有差异，但基本原理一致：把 skill 作为一个目录放在约定的配置目录下，然后在配置文件里声明启用。以我目前在用的版本为例，skill 目录结构大概是这样的：

~/.config/opencode/ ├── command/ ├── skills/ │ ├── code-review/ │ │ ├── SKILL.md │ │ └── scripts/ │ ├── commit-message/ │ └── api-doc/ └── opencode.json

每个 skill 的核心就是一个SKILL.md文件，里面用 Markdown 写了触发条件、执行步骤和输出格式。有些复杂的 skill 还会带scripts/目录，放辅助脚本。安装的时候不需要动源码，只要把这个目录丢进来，再确保 assets 或 config 里声明的路径正确即可。

我建议：不要直接 clone 整个合集仓库到你的配置目录。因为很多技能包之间有依赖冲突，比如两个不同的 review skill 会争抢同一个斜杠命令。正确做法是先每个技能单独下载，逐个放进skills/目录，然后在配置里手动启用。虽然第一次麻烦点，但后面排查问题会省很多事。

4.2 如何判断一个 skill 是否值得安装

我在前面推荐了不少 skill，但我强烈不建议你照着全装。安装过多 skill 反而会让 AI 触发混淆，经常拔错头。判断一个 skill 值不值得装，就看三点：

第一，它是否解决了一个你至少每周都会遇到的高频痛点。如果一个月才用一次，不值得常驻。比如“数据库操作助手”对我这种天天碰 MySQL 的人那是必装，但如果你只是偶尔跑一下 SQL，可能就完全没必要。

第二，它的执行流程是否明确，是否可验证。一个合格的 skill 会包含检查步骤、输出规则和成功标准。如果 SKILL.md 里全是“帮助开发者提高效率”这种空话，那它就是一个伪装成 skill 的普通 prompt，价值不大。

第三，它与已有技能是否冲突。装之前先看一眼它定义的触发命令，别跟现有的重复。我的建议是给每个 skill 定义唯一的斜杠命令，比如/review、/commit、/sql，这样你调用时总能精准加载，不会含糊。

4.3 自己裁剪一个 skill 的模板

用熟之后，你会发现很多 skill 大可以自己改。我分享一下我的裁剪思路。拿到一个新 skill，先别急着用，打开 SKILL.md 看看它的核心逻辑。通常一个合格的 skill 应该包含四个部分：角色设定、工作流程、输出格式、约束条件。

一个简单的自定义模板我通常这样写：

# 技能名称：代码注释规范化 ## 触发条件 当用户提到"注释"、"comment"、"文档字符串"时触发。 ## 执行流程 1. 列出当前文件的公开函数和类。 2. 识别缺失注释的代码块。 3. 参考文件头部的注释风格，生成统一格式的注释。 4. 对于公共 API，补充参数说明和返回值说明。 ## 输出格式 在每个修改点给出 file:line 前缀。 最后输出一个修改统计摘要。 ## 约束 只修改注释，不允许更改任何业务逻辑。

这样的模板认证后放进去就能用。真正的价值在于，你自己裁剪过的 skill 才最贴合你的工作习惯。

5. 实战排坑记录与实用建议

最后是我这段时间踩坑的经验整理。装 skill 和用 skill，看起来简单，实际操作中总有一些细节坑人不浅，在这里统一说清楚。

坑一：skill 之间的触发词冲突

现象：装了某个英文命名的 skill 之后，发现另一个 skill 的调用总是跑到它那里。原因一般是它们的触发词重合了，AI 无法精确区分。解决办法是我把所有常用 skill 都指定了独立且罕见的斜杠命令，并在配置里关闭“所有提示词都当作技能触发”的模糊匹配选项。

坑二：SKILL.md 的格式错误

现象：skill 装进去完全没效果，AI 表现和没装一样。原因是 SKILL.md 头部缺少 frontmatter（YAML 格式的元信息区），opencode 就没把它识别成一个 skill。注意很多下载的 skill 在传输或复制过程中会丢失这个头部。遇到这个问题，打开文件补齐 frontmatter 就好。

坑三：多 skill 协作时上下文爆炸

现象：同时启用了四个 skill，一次对话里 AI 把每个 skill 的完整指令都当成上下文读进去了，结果还没开始干活，窗口就满了。解决思路是在配置里对每个 skill 设置较低的基础权重，让 AI 只在触发相关命令时才加载它，而不是常驻记忆。

坑四：版本兼容性

opencode 更新比较频繁，skill 的 API 结构有可能变化。我建议每两周 git pull 一次技能仓库，并关注更新日志。如果某个 skill 突然失效，通常不是配置问题，而是接口变了。

经验：用 git 管理你的 skill 目录

我自己是把整个skills/目录纳入版本管理的。这样一来，每次调整都留了记录，回滚也方便。更重要的是，我可以把个人觉得好用的配置同步到多台电脑上，不用重新折腾。

表格整理一下最常见的问题速查：

在我个人的实际体验里，最推荐大家优先安装的其实是 code review、commit message 和 API 文档生成这三个。它们都属于“高频、重复、规则明确”的任务类型，正是 skill 最擅长发挥的地方，装完的性价比拉满。

再分享一个让技能效果起飞的小技巧：在 opencode 的全局配置里，把每个技能都绑定一段你项目专属的背景说明。比如我在做金融类项目的时候，给数据库操作 skill 单独加了一段“所有金额字段以分为单位，金额查询结果保留两位小数”的提示，生成的 SQL 直接就能用。这种“通用 skill + 项目上下文”的混搭法，是我目前见过最灵活也最出效果的用法。

技能合集不是越多越好，装了一堆却不理解它们什么时候触发的组合拳，反而会拖累模型的表现。希望这篇实战拆解能帮你少走点弯路，把 opencode 这把刀磨利。多位开发者表示，只要第一周稍微忍耐一下，熟练之后真的回不去了。