如果你逛过OpenCode的社区应该见过ohmyopencode这类项目——它做的事情很简单把OpenCode的配置、Agent指令、Skill技能包整理成一套可以快速拉起的合集。标题里的skill必装合集我理解指的是从这个大合集里筛出真正值得装的技能而不是照单全收。Skill这个机制用好了OpenCode才从一个能写代码的AI变成一个遵守你团队规矩的AI程序员用不好就是装了一堆花架子指令该乱改代码还是乱改。这篇文章我不打算给你搬运一份完整清单而是按我实际落地时的思路来拆先讲清楚Skill是干什么的、为什么不能乱装再给出我用频率和收益两个维度筛出来的必装分层然后逐个说明每个Skill的配置细节、容易翻车的地方最后说一说我在真实项目里踩过的坑。无论你是刚接触OpenCode的新手还是已经装了二三十个Skill但感觉装跟没装一样的老手这篇都值得看完——尤其建议跳过那种多就是好的错觉先搞清楚什么值得装。1. 先搞清楚Skill到底解决什么问题1.1 Skill不是插件是行为约束能力封装我第一次接触Skill时也把它想简单了以为它就是一段更长的提示词。用了一段时间后我意识到它真正的价值是给AI立规矩。就好比你带一个能力很强的新人他写代码没问题但他不知道你们仓库提交信息要带需求编号、不知道改动公共模块之前必须先在本地跑一遍相关测试、不知道这个模块有历史包袱动不得。这时候你需要的不是给他换一台更强的电脑而是给他一本部门工作手册。Skill就是这本手册。机制层面一个Skill本质上由一个核心说明文件SKILL.md和若干可选的支持文件组成支持文件可以是脚本、模板或者参考文档。AI在接到任务时会先读取这套说明然后按照上面写的流程、约束、输出格式去执行。重点在于先读流程再干活这一步——它把一次性的口头交代变成了每次都会自动遵守的规矩。这一点和普通提示词的区别是本质性的提示词用完即丢Skill可以沉淀、可复用、可跨项目迁移。也正因为这个机制Skill不适合贪多。装得太多AI每次启动都要把这些说明读一遍不仅拖慢响应还可能让模型在不同技能之间左右横跳。所以真正专业的用法是分层管理、按需触发这比收集癖式地狂装一堆Skill要重要得多。1.2 为什么需要一份必装合集OpenCode默认的行为是通用的适合处理各种泛化任务但它不会替你考虑团队规范。比如在前后端分离的项目里我希望AI改前端组件时不要顺手改动接口契约在维护老项目时我希望它做大改动之前先做影响面分析。这些约束默认模型完全不知道只能靠Skill补上。但Skill市场里鱼龙混杂有维护得很好的也有写了三句话就丢上去的。乱装的代价很直观第一加载成本活跃的技能越多占用的上下文越长后面处理大任务时AI容易失忆第二冲突成本两个Skill对同一场景给出相反方向的要求模型很难判断听谁的第三维护成本技能多了没人更新里面的指令迟早过期。所以一份经过筛选的合集比全量安装实用得多。我的筛选标准很朴素触发频率够不够高、装上后收益能不能实实在在看到、会不会和默认行为打架。按这个标准筛完剩下的数量其实不多但个个都顶用。2. 必装清单总览按使用频率分层2.1 第一梯队写代码时高频触发的Skill第一梯队是几乎每天都要用的我直接放在默认技能目录里确保能够随时生效。以下是我目前留下的核心四项Skill名称核心用途触发时机优先级测试驱动开发TDD强制AI按先写测试、再写实现、最后重构的顺序推进新功能开发、Bug修复P0代码重构含同义改写变量更名、函数提取、消除重复代码先从影响面分析开始任何代码修改之前P0代码审查从安全、性能、可维护性三维度审查改动合并代码前、大功能落地后P0Git提交信息与Changelog按仓库历史风格生成规范提交信息发版前整理变更记录提交代码、发布版本时P0这四类的共同点是动作高频、AI默认容易翻车、做好了收益立竿见影。TDD治AI不写测试的懒病重构管住AI乱动代码的手审查给AI一次自我纠错的机会提交信息则让历史变得可读。四个技能配合起来基本覆盖了从改代码到合入的完整链路。如果你只想装四个那就先装这四个其他的可以后面按需补。2.2 第二梯队提升工程规范的节点型Skill第二梯队不是每天用但到了节点性工作能省出大把时间。我通常把它们放在另一个技能目录里需要时手动触发接口文档生成从路由定义、数据模型、注释中整理出接口说明适合对外联调前突击使用。AI还能顺带标出请求参数缺了哪些校验这个附加价值很香。Changelog生成扫描两个版本之间的提交记录按功能、修复、重构等类型归类。它节省的不是写文字的时间而是翻Git历史的时间。依赖与安全检查分析依赖树标记过期版本和已披露的安全风险升级依赖前先跑一遍能少踩很多坑。单元测试补全针对已有代码补边界测试和异常路径测试适合版本提测前用来铺覆盖率。这类Skill的特点是适合场景触发不适合常驻。因为它们本身指令长、逻辑重如果一直处于活跃状态会在无关对话里分散模型的注意力。我的用法是把它们安装好但只在需要时点名调用。2.3 第三梯队按技术栈选择的进阶Skill第三梯队更垂直适合有明确技术栈的团队按需选用。比如你在维护老系统架构评审Skill就很有用——它能把模块之间的依赖关系梳理出来标记循环依赖和过度耦合在设计期就拦住潜在的维护灾难。又比如项目用到数据库数据库迁移Skill会在表结构变更后主动分析对现有查询的影响并生成回滚SQL尤其适合没有专职DBA的小团队。第三梯队的管理方式要更克制。我建议单独建目录甚至不要预先启用——真到对应场景再手动把技能加载进来。原因是这类Skill的说明往往非常长动辄几千字常驻的话会挤占对话上下文让AI面对日常任务时明显变笨。到这时你就明白Skill管理不是做加法而是做减法。3. 逐个拆解装了以后最值的四个Skill3.1 TDD Skill强制先测试后实现TDD Skill的核心是把Red-Green-Refactor节奏写进指令。我在SKILL.md里写下的关键约束是面对新功能时第一步先分析需求、列出测试用例清单第二步写第一个失败测试第三步写刚好能通过该测试的最小实现最后才考虑重构。每一步只满足当前测试禁止预测后续需求提前写出完整方案。这个禁止预测未来的约束是我踩坑后补上的。最早版本没有这条AI会直接写完整实现然后反手生成一个凑数测试。它的表现和人偷懒的路径一模一样——先干完活再敷衍填个记录。加了这条之后AI的行为会明显更接近真正做TDD的节奏一上来先给测试再讨论实现。实践效果也直观。以前AI提测后经常被测试打回现在它会同步产出一套本地可跑的测试至少把主路径和异常路径都覆盖了。这里得提醒一句Skill只负责把流程卡住测试断言写得好不好AI的智能程度决定上限你的人工复核决定底线。所以TDD Skill不能完全撒手Review测试本身仍然靠你。3.2 重构与同义改写Skill管住AI乱改代码的手大多数AI改代码翻车症结其实不是能力不足而是上下文视野有限。它在一个大文件里只看得到局部就敢对全局下判断。典型例子把一个方法从A文件搬到B文件它只改了搬走的部分忘了改原调用点把一个变量名从temp改成orderTotal漏掉了字符串模板里或注释里的引用。这类错误极其隐蔽往往等CI跑挂了才发现。重构Skill的应对方式是把流程切成阶段先全量扫描把所有受影响的调用点列成清单然后产出改动计划最后才动手改。在Skill里我写了条硬性要求跨文件改动必须先输出影响面清单等用户确认后再执行。这一条约束看着简单但直接砍掉了AI一半以上的误改。我用的技能包里还包含同义改写这个能力标签。它不只管代码更名还管注释和文案的一致性。AI改完代码后必须同步维护注释里已失效的描述。很多项目代码烂根源就是注释与实现脱节这个习惯一旦通过Skill固化下来几个月后整个代码库的可读性提升会很明显。尤其老项目维护场景这一条比什么都值钱。3.3 代码审查Skill把AI当第一个Reviewer代码审查Skill不是让AI替代人工Review而是让它先做一轮机械但全面的初筛。我把审查维度固定为三类安全性包括注入、越权、敏感信息泄露性能包括循环内查询、未分页、重复计算可维护性包括魔法数字、过深嵌套、命名混乱。AI不会因为读起来不顺眼就发牢骚它只会按维度逐项查。输出格式也必须结构化。我要求它给出问题清单每条带文件路径、行号、严重级别和具体修复建议。这样人工Review时不再需要从对话记录里翻上下文直接对着清单逐条确认。整个改动从提交到合入的时间大概能缩短两成。省下的时间主要不是来自AI发现高级bug而是这个流程逼着改动方先把代码理了一遍等于多了一道自查门。不过Review Skill不建议全自动跑全仓在大型仓库里这么做会烧掉大量token产出一堆噪音。更合理的用法是每次执行对当前改动范围合并前跑一次。把检查和修复做成对话闭环收益远大于一次性全仓扫描。3.4 提交信息与Changelog Skill历史可读、发版省心AI生成的提交信息默认风格基本是fix bugupdate code这种正确但没营养的模板。提交信息Skill的解决思路是让AI先读一下仓库最近十条提交的写法再按同一种风格生成新message。我在配置里给定了几条硬规则主题用动词开头、控制在50个字符以内正文按为什么改、怎么改、影响范围三块写有需求编号的必须带上。Changelog Skill负责发版前的收尾工作。它扫描两个标签之间的提交记录按功能、修复、重构、文档等归类再结合语义化版本规则给出版本号建议。这一层自动化非常省心尤其在版本迭代快的项目里每次发版前手动整理变更记录真的很烦。需要提醒的是Changelog的质量上限取决于提交信息的质量。你提交记录本来就是一团浆糊AI也提炼不出有价值的变更说明。所以提交信息Skill是地基Changelog Skill是在地基上盖楼——两个配套装效果才稳。4. 想让Skill真正好用这三块配置不能省4.1 用Agent指令编排Skill触发顺序Skill装好只是第一步真正的落地靠Agent指令。默认情况下Skill需要用户主动点名触发实际使用中这个动作经常被忘。我更推荐建一个自定义Agent指令把核心Skill挂到工作流上让AI按编排顺序自动执行。我的一段指令配置长这样# 自定义Agent指令示例 你是一个负责任何代码修改任务的智能体。在执行修改之前必须按顺序执行以下动作 1. 调用代码重构技能对改动目标做影响面分析输出受影响文件清单 2. 根据分析结果调用测试驱动开发技能同步补充或更新测试 3. 完成修改后调用代码审查技能对改动范围执行自查 4. 最后提醒我运行相关测试并确认影响面是否有遗漏。指令与技能的区别值得强调指令管编排管何时触发什么技能管执行管这个动作具体怎么做。很多人的Skill之所以一直沉睡就是只装了技能没有配指令AI始终不知道什么时候该用。所以当你说某Skill装跟没装一样先去检查有没有对应的指令文件在驱动它。4.2 控制Skill数量别让上下文被挤爆上下文窗口是AI编程工具最硬的资源。一个中大型Skill的SKILL.md大概2KB到4KB如果默认启用5个以上的技能启动时就会吃掉20KB左右的上下文这还没算技能引用的支持脚本输出。上下文被技能挤压最直接的后果是AI处理大文件时频繁失忆前面刚说清楚的约束后面就忘了。我自己实测下来默认路径保留三到五个高频技能是比较平衡的区间剩下的挂到备用目录里需要时再手动加载。如果你的模型本身上下文足够长可以适当多装一点但原则始终是精确触发优于常驻干扰。宁可让AI在需要的时候临时去读一段长技能也不要让它每个对话都背着大批用不上的说明干活。4.3 把团队规范沉淀成私有Skill真正体验过Skill红利之后你会发现它最妙的应用场景其实是团队私有规范的沉淀。团队要求接口必须带版本号、错误码必须统一风格、数据库变更必须带回滚SQL——这些东西写进文档没人看但做成Skill AI每次都会执行。我团队里现在就维护着一套自定义Skill结构清晰skills/ └── api-standard/ ├── SKILL.md └── templates/ └── api-response.mdSKILL.md开头写适用场景和核心规则模板文件给出标准响应格式的示例。模型对具体示例的遵循度远高于抽象描述——比如确保错误码风格统一就不如所有错误码必须使用ERR_模块_编号格式例如ERR_AUTH_001有约束力。所以写Skill说明时多用肯定句式、少用抽象词、尽量给出例子。一个值得注意的细节是私有Skill不要和公共Skill混放在同一个目录维护和更新节奏不一样。分开管理公共的可以放心随上游更新私有的是团队资产得单独保护起来。5. 常见问题与排查实录5.1 装了但没生效先按这个顺序排查Skill没生效是出现频率最高的问题我自己也被坑过几回。归纳下来有一套排查顺序先确认技能目录位置对不对很多用户把SKILL.md放到了全局配置目录但项目启动时压根没加载项目级技能目录再检查SKILL.md的文件名和格式是否规范命名不对会导致识别失败然后启动后查询技能列表确认它真的出现在列表里如果列表里有但对话中不调用大概率是Agent指令把它屏蔽了或者命名与内置能力重名AI优先走了内置逻辑。我处理过一个很典型的案例技能列表能看到但无论怎么问AI都不调用最后发现名字和内置能力撞了。改成唯一性更强的名字后一下子就正常了。这类问题排查起来不复杂但要按顺序来不然很容易在一个错误方向上浪费半天。5.2 Skill之间打架用优先级和触发条件拆分Skill装到一定数量后指令冲突是躲不掉的。我遇到过最典型的一组冲突重构Skill要求修改前先做影响面分析而补全测试Skill要求直接生成测试用例两个同时触发时AI会来回横跳最后产出既不完整也没分析的东西。处理办法有两个方向。第一是给Skill加优先级标识比如在指令文件里明确当多个技能同时适用时以重构技能的分析结果作为后续动作的输入这样AI就知道谁说了算。第二是用触发条件缩小适用范围比如通过文件后缀、目录路径、任务关键词把Skill限定到特定场景从源头减少同时触发的概率。我在指令里会把两个方向都写上双保险。5.3 模型忘了Skill怎么提高遵循度最后一个高频问题是模型对长指令的遵循不稳定。根源不完全是Skill写得不好而是不同模型对指令的遵守能力差异很大。有的模型会在生成代码过程中逐渐跑偏把最开始的约束抛在脑后写出来的东西又回到默认风格。我的应对思路是长短结合。在Skill说明的开头放一句强制声明比如在任何响应之前先完整阅读本说明并检查是否已遵循全部规则在关键步骤之间插入重申型提醒每隔几步就回到约束本身。另外最重要的规则放在文档开头和末尾——模型对首尾的关注度高于中间所以权重最高的硬性要求不要去中间埋着。这个方法实测有效不过本质上是给模型能力打补丁选一个指令遵循度更稳的模型才是治本之策。5.4 问题排查速查表现象可能原因排查手段技能不出现目录位置错误检查技能文件是否在项目级目录下技能出现但不用命名冲突或未配置触发改名或将技能挂到Agent指令多个Skill互相打架指令边界未定义加优先级或限定触发场景对话中技能突然失效模型遵循度不够调整指令措辞或更换模型参考文档乱码编码格式不对统一使用UTF-8保存6. 我的使用心得与跳过的几个坑最后聊几个实际体会如果你准备在团队里推Skill这套玩法这些或许能帮你少走弯路。第一个坑是别被数量洗脑。我一开始也热衷于收集Skill觉得装得越多越专业结果AI在对话里变得又慢又容易精分。后来删到第一梯队四个一切立刻清爽了。Skill的价值不在于你能装多少而在于每次触发时能不能稳定产出符合预期的结果。一个被频繁用好的技能顶过十个躺在列表里睡大觉的。第二个经验是Skill要有人统一维护。我们团队早期每个人都能随手加技能结果技能库迅速膨胀、互相冲突最后又全部推倒重来。现在固定由一个人负责合并需求和更新其他人只提反馈情况立刻稳了。这和代码库的维护逻辑完全一样没人统一review的技能库迟早变成技术债。第三个体会是Skill、命令、模型三者是配套关系。单独堆Skill而不管指令编排、不关注模型遵循度效果很难出来。所以如果你打算好好用Skill建议先花十分钟把Agent指令文件写好再决定装哪几个技能我一开始是反着来的先装技能再补指令来回折腾了不少时间。从小处入手先选一个你最痛的点配好对应的一个技能跑两周看效果再逐步扩展。Skill这东西只有放进真实工作流里跑起来才见真章看一堆清单远不如一个跑顺的小闭环。