写这篇东西之前我一直在琢磨一个问题同样用 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 个通用 skills2.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 头部缺少 frontmatterYAML 格式的元信息区opencode 就没把它识别成一个 skill。注意很多下载的 skill 在传输或复制过程中会丢失这个头部。遇到这个问题打开文件补齐 frontmatter 就好。坑三多 skill 协作时上下文爆炸现象同时启用了四个 skill一次对话里 AI 把每个 skill 的完整指令都当成上下文读进去了结果还没开始干活窗口就满了。解决思路是在配置里对每个 skill 设置较低的基础权重让 AI 只在触发相关命令时才加载它而不是常驻记忆。坑四版本兼容性opencode 更新比较频繁skill 的 API 结构有可能变化。我建议每两周 git pull 一次技能仓库并关注更新日志。如果某个 skill 突然失效通常不是配置问题而是接口变了。经验用 git 管理你的 skill 目录我自己是把整个skills/目录纳入版本管理的。这样一来每次调整都留了记录回滚也方便。更重要的是我可以把个人觉得好用的配置同步到多台电脑上不用重新折腾。表格整理一下最常见的问题速查现象可能原因处理方式技能未触发frontmatter 缺失或格式错误检查 SKILL.md 头部 YAML 信息多个技能抢占命令触发条件重叠给每个技能分配唯一斜杠命令AI 上下文提前耗尽技能常驻加载调整技能基础权重并改为按需触发技能执行效果变差opencode 版本升级更新技能仓库并核对兼容性数据库中写操作被拦安全策略开启在配置中放开只读限制谨慎操作在我个人的实际体验里最推荐大家优先安装的其实是 code review、commit message 和 API 文档生成这三个。它们都属于“高频、重复、规则明确”的任务类型正是 skill 最擅长发挥的地方装完的性价比拉满。再分享一个让技能效果起飞的小技巧在 opencode 的全局配置里把每个技能都绑定一段你项目专属的背景说明。比如我在做金融类项目的时候给数据库操作 skill 单独加了一段“所有金额字段以分为单位金额查询结果保留两位小数”的提示生成的 SQL 直接就能用。这种“通用 skill 项目上下文”的混搭法是我目前见过最灵活也最出效果的用法。技能合集不是越多越好装了一堆却不理解它们什么时候触发的组合拳反而会拖累模型的表现。希望这篇实战拆解能帮你少走点弯路把 opencode 这把刀磨利。多位开发者表示只要第一周稍微忍耐一下熟练之后真的回不去了。