大概是从去年年底开始我发现自己写代码进入了一个奇怪的状态工具链越来越成熟用Claude Code、Codex这些AI编程助手干活也越来越顺手但每次换个项目、换个任务总要把同样的规范、同样的流程、同样的检查清单反复粘贴到对话框里。项目一多这些重复劳动比我实际写代码的耗时还长。直到有次我在GitHub上翻到一些开源项目看到别人把这类对话工作流做成了一个个独立的模块还给它们起了个名字——skills。从那一刻起我的AI编程方式彻底变了。今天这篇不聊虚的就围绕skills这套东西好好展开。它是什么、为什么现在每个人都在谈、怎么把GitHub上现成的skills装进Claude Code或Codex、有哪些值得收藏的skills库、数学建模和AI漫剧这些场景怎么写自己的skills、以及如果装太多之后该怎么清理。我踩过的坑、试错后的经验都会写出来你直接照着抄就行。1. skills到底是什么为什么AI编程突然都在聊它1.1 从会聊天的AI到会干活的AI先明确一个概念skills在AI编程工具里指的是一组可复用的指令、规范、脚本和资源的集合。它不是独立的软件更像是一份岗位说明书——告诉AI助手当你接到某类任务时应该按什么流程做、用什么工具、检查什么指标、输出什么格式。说得更直白一点。以前你用AI写代码像是请了个聪明的实习生你每件事都要叮嘱一句先跑一下测试、记得处理边界情况、按ESLint规范来。有了skills你相当于给这个实习生配了一整本操作手册他接到任务就知道该翻到哪一页、按哪条标准执行、最后交付什么。我见过一个很典型的案例。有哥们做前端开发他把团队的代码规范、组件写法、PR检查标准全写进了一个skill然后让Claude Code处理页面重构。原来要来回磨好几轮、改完还要人肉review一遍的活现在AI一次性生成的结果基本就能达到提测要求。我后来也照做效果确实夸张。这不是AI变聪明了而是它知道该怎么干活了。1.2 skills和提示词、MCP、Agent到底什么关系很多刚接触的朋友容易把几个概念搞混提示词Prompt、Agent、MCPModel Context Protocol和skills。提示词是一次性的、临时写给AI的指令用完就没了。skills是工程化的、可复用的提示词工作流是有组织、有结构的手册可以被AI按需加载。Agent是AI的自主行动能力skills可以理解为给Agent配的经验库让它行动时有所依据。MCP是一种协议负责让AI连接外部数据源和工具比如读数据库、调用API。skills可以引用MCP工具但skills本身更偏重流程和规范。用一句话概括MCP解决AI能碰什么skills解决AI怎么干。明白了这层关系你就知道为什么skills突然火起来。现在各家AI编程工具的能力底子已经足够强差距恰恰体现在你怎么引导它干活上。谁沉淀的skills多、质量高谁用AI干活的上限就高。这就像同一个厨师、同一口锅菜谱的质量决定了成菜的水平。2. 快速上手怎么把别人的skills装进自己的工具2.1 Claude Code手动安装GitHub上的skillsClaude Code的skills机制是目前生态里最成熟的。安装分三种方式官方插件市场装、命令行装、手动装。这里重点说手动装因为很多优质skills并不在市场里只托管在GitHub仓库上。直接复制到目录第一步确认你的Claude Code版本支持skills建议用最新版。在终端执行claude --version查看如果版本太老先升级。第二步找到Claude Code的配置目录。macOS和Linux在~/.claude/Windows在%USERPROFILE%\.claude\。skills对应的是该目录下的skills/文件夹如果没有就手动创建。第三步去GitHub上找到你要装的skills仓库把整个skill文件夹比如一个叫frontend-review的目录里面含SKILL.md和其他资源文件下载下来放进~/.claude/skills/目录下。装好之后目录结构是这样的~/.claude/skills/ ├── frontend-review/ │ ├── SKILL.md │ └── reference/ ├──>/plugin install repo-owner/repo-name这条命令会把整个仓库作为插件装进Claude Code里面的skills会一并注册。这种方式适合安装包含多个skills的聚合包比手动一个个丢目录省事很多。如果你用的是Codex或者OpenCode它们各有自己的skills目录通常也在用户目录下比如~/.codex/skills/安装逻辑是类似的找到目录、放进去、重启生效。提示装完skills之后建议花两分钟检查一下SKILL.md里声明的name和description这两个字段会在AI决策是否加载该skill时起关键作用。描述写得含糊AI可能该用的时候不用、不该用的时候乱用。2.2 superpower skills这类聚合包怎么装说到装skills绕不开一个名字superpowers。这是社区里知名度极高的skills聚合库作者是Jesse Vincent也就是obraGitHub地址是obra/superpowers。它不是单个skill而是一整套方法论——包含项目规划、任务拆解、代码审查、测试驱动开发、调试等一揽子工作流。安装超级简单官方推荐直接通过Claude Code的插件机制装/plugin install obra/superpowers装完之后你会看到一堆skills出现在目录里。注意聚合包的意义不是让你全用上而是让AI根据任务自己选。比如你丢给Claude Code一个复杂的重构任务它会自动调用superpowers里的规划skill先拆任务再动手。我的建议是新手不要一上来就装超级聚合包先把单点skills用熟知道每个skill的触发方式和输出逻辑再装superpowers这类重量级选手。否则你根本分不清是哪个skill在生效出了问题也不知道该排查谁。2.3 Codex、OpenCode等工具的skills安装差异不少朋友是在Codex上用的尤其华为杯、美赛这类数学建模竞赛Codex的skills生态最近也很活跃。Codex安装skills的原理和Claude Code相同但有几个细节要注意第一Codex的skills目录不一定在~/.codex/skills/具体看版本。你可以先跑一条命令确认codex --version然后查看用户目录下有没有.codex文件夹确认skills子目录的位置。第二Codex对skills的加载策略更挑食。它要求SKILL.md里的描述和目标任务匹配度足够高才触发模糊描述很容易被跳过。所以装完别人的skills如果发现不生效先检查是目录没放对还是描述写太泛。第三OpenCode这类开源工具对skills的支持还在快速迭代中不同版本的文件组织方式可能都不一样。最稳妥的办法是去看它的官方文档里skills或agents那节按对应版本操作。对我来说跨工具使用skills最大的心得是skills文件本身是通用的瓶颈在于你用的工具认不认这个目录结构。所以无论在哪装先确认路径再确认重启最后用一句话测试触发三步走完基本不会有大问题。3. 值得收藏的skills源与场景推荐3.1 常用skills源网站和GitHub仓库社区里已经有不少人专门维护skills的应用商店只是没有统一的官方商店而已。我常用的几个渠道GitHub搜索直接搜claude skills、codex skills、awesome skills这类关键词。GitHub的awesome系列列表质量很高比如awesome-claude-skills里面按前端、后端、写作、数据分析等场景做了分类。anthropics/skills官方实验仓库里面有不少官方维护的示例skills内容质量有保障直接看代码能学到不少写作技巧。obra/superpowers刚才提到的聚合包方法论向值得研究它怎么组织一个skill的目录结构和上下文引用。typesafe的AI skills仓库TypeSafe团队开源了一套面向类型安全和工程规范的skills对做严肃工程项目的朋友帮助很大里面关于代码生成、类型推导校验、重构安全的思路值得参考。cola skills社区里近期讨论度较高的一个集合主打创意类和内容生成类任务很多做AI漫剧、短视频脚本的朋友在推里面关于分镜和角色一致性的skill写法很有启发。找skills源有个技巧不要只盯star数要看最近更新时间和SKILL.md里描述的具体程度。很多仓库star很高但skill写得很水描述全是空话有的冷门仓库反而是作者从真实业务里提炼出来的读一遍就懂为什么那么写。3.2 前端开发场景到底需要哪些skills前端是skills应用最成熟的领域之一因为前端开发流程标准化程度高、可检查的指标明确。我自己整理并实测下来最常用的几个代码规范审查skill。这个skill让AI按你团队的ESLint规则、组件命名规范、TypeScript类型约定来检查生成的代码。装之前AI写的组件props命名全看心情装之后它会老老实实按你定好的风格走。一条skill解决的问题比你给AI单次强调十遍请遵守规范都有效。响应式与可访问性检查skill。它会要求AI在生成页面后主动检查断点布局、对比度、focus态、ARIA标签这些细节。我以前做完页面总要自己跑一遍Lighthouse现在让AI先自查一轮明显省事。性能优化skill。触发它会自动分析Bundle体积、图片尺寸、懒加载时机并给出优化方案。对做中后台系统的团队特别有用。组件库二次封装skill。如果你用Ant Design或Element Plus这类组件库这个skill能把组件统一风格的要求固化下来AI生成页面时自动引用封装过的组件而不是直接用原始组件导致样式漂移。我见过不少前端团队把这类skills直接放进~/.claude/skills/目录后要求组员统一使用代码review的批注量肉眼可见减少。说到底skills解决的不仅是效率问题更是团队协作的一致性难题。3.3 数学建模场景的skills推荐数学模型比赛是skills使用场景里挺特别的一个存在。因为它需要的技能栈非常杂数据清洗、模型选型、代码实现、可视化、论文排版每一个环节AI都能帮上忙但每个环节的正确工作方式完全不一样。华为杯、美赛、国赛这几年越来越多人用AI辅助直接把skills队伍带起来了。数据清洗和探索性分析skill。建模的第一步永远是处理数据。一个好的data-cleaning skill会严格规定缺失值处理策略、异常值检测流程、归一化方式并自动生成探索性图表。这个skill能避免AI拿到数据就瞎跑模型。模型选型skill。做评价类问题该用层次分析法、熵权法还是TOPSIS做预测类问题该用回归、时间序列还是神经网络。模型选型skill会把decision tree写进指令里要求AI先分析问题类型再论证模型选择然后才动手写代码。LaTeX论文排版skill。建模比赛时间紧论文排版经常是最后一道坎。写一个论文skill把三线表、公式规范、算法伪代码模板、参考文献格式全固化进去AI直接按你的目标期刊/比赛要求生成论文段落效率翻倍。可视化skill也值得装。它会让AI生成图表时统一配色、字体、标注格式保证论文里的图和代码里跑出来的图风格一致。数学建模场景我个人的体会是不要把skills理解成做题神器它更像你的规范化助教。它不能替你想出创新模型但它能确保你在有限时间内把每个环节都做到位不留扣分死角。4. 自己动手写一个skills从需求到落地4.1 SKILL.md的标准结构和写作规范聊完用必须聊写。只有自己能写skills才能真正把AI变成你的AI。一个标准skill在磁盘上的结构是这样的my-skill/ ├── SKILL.md ├── scripts/ # 可选的脚本 ├── reference/ # 可选的参考资料 └── assets/ # 可选的模板文件其中SKILL.md是核心它决定了这一个skill能不能被正确触发、能不能按预期工作。我第一次写skills时犯的错就是把SKILL.md写成了长篇大论。后来看了不少优秀开源项目才悟到SKILL.md的正确写法是有固定框架的。第一部分是YAML frontmatter--- name:>--- name: anime-storyboard description: 根据剧情文本生成AI漫剧分镜表包含景别、运镜、时长、台词、画面描述及对应文生视频prompt。适用于需要批量生成分镜脚本的场景。 ---正文里的工作流部分## 工作流 1. 解析输入剧本提取场景、角色、动作、对白。 2. 按场景-镜头编号生成分镜表列为编号、景别、运镜、时长、画面描述、台词、备注。 3. 角色一致性如出现已登记角色必须在画面描述中使用该角色的固定外观描述不得自行改写。 4. 为每个分镜生成文生视频Prompt包含主体、环境、镜头运动、画风、质量修饰词。第四步测试优化。装好后用一段实际剧本文本触发它第一次跑出来分镜表结构没问题但Prompt里的画风修饰词太统一、缺少变化。我又在skill里加了一条指令画风修饰词需根据场景情绪动态选择如紧张用暗调、温馨用暖色重跑之后效果明显好多了。从这个案例里能总结出一个通用心法写skill本质上是把你的隐形经验显性化。规则越具体、边界越清晰skill效果越好。别指望AI能理解你脑子里的默认值你一定要把所有影响输出的条件都写清楚。4.3 AI skills开发和调试的实操经验写完skills只是开始打磨才是重头。我建议你写完任何skill后按下面这套方法测试先做单元测试用几个典型的输入分别触发skill检查输出是否符合预期。注意不要只测一个输入就下结论要测边界。比如分镜skill你给它一行文本它该怎么处理给它一万字剧本又该怎么处理两种情况差别很大。再做干扰测试故意给一个和skill场景完全无关的任务比如数据分析skill你让它写首诗看它会不会错误加载。如果它错误触发了说明description写得有歧义需要改得更精确。最后做回归测试把几个老任务重新跑一遍确保新skill没影响之前的输出逻辑。这一步很多人忽略直到某天发现AI行为突然变了才回头查很浪费时间。我自己的经验是skill写好后最好让它能接受对话中的中途调整。比如分镜skill用户可能在某个分镜上手动改了一版promptAI应该学会从那个点继续而不是每次重新生成整套。5. 日常维护清理、迭代与常见问题排查5.1 为什么skills一定要定期清理skills装多了技能冗余问题就来了。我有一段时间前后装了二十多个skills以为越多越好结果AI反而变钝了——有时候它会在简单任务上错误地套用复杂skill有时候因为多个skill的description互相重叠AI不知道该选哪个处理速度肉眼可见地变慢。后来我参考了社区里tibo的清理思路做了一次彻底梳理。tibo总结的方法很直接以使用频率和触发准确度为标准把skills分成三个等级——高频常用、偶尔用、基本闲置。常用保留偶尔用的合并同类项基本闲置的直接删。具体操作也分享给大家第一步列出所有已安装的skillsls ~/.claude/skills/第二步逐个看SKILL.md的description问自己两个问题我上一个用这个skill是什么时候这个描述有歧义吗如果两个问题都答不上来就删。第三步用目录隔离低频skill。比如把不常用但可能用到的skills挪到~/.claude/skills/archive/里让主目录保持轻量。这样AI扫描时不会被干扰真需要用时再移回来。第四步定期合并同类项。比如我之前有前端Code Review和组件审查两个skill内容高度重叠直接合并成一个前端工程化检查触发逻辑更清晰、输出也更稳定。我之前写过一句话清理完skills之后再说一次skills的核心价值是把AI的注意力聚焦到你真正需要的流程上。装了二十个skill却互相打架效果还不如只留五个精心打磨过的。5.2 skills不生效、误触发、输出异常怎么办用skills的过程中我自己踩过不少坑把这些整理成一个问题速查表遇到问题直接按表排查问题可能原因排查与解决办法装了skills但AI完全不理会目录放错 / 版本太旧 / description太泛检查目录位置确认工具版本支持skills重写description明确什么输入-什么输出skill被错误触发description包含的触发词太宽泛给场景描述加限定词去掉无关词在SKILL.md里加不适用场景说明输出质量忽高忽低正文工作流步骤不够细、约束条件缺失细化步骤明确每步的输出物增加禁止项列表生成结果风格和自己预期不一致SKILL.md缺少示例在reference目录放一个标准输出的示例文件让AI对齐风格更新skill后行为异常缓存未刷新重启工具清空临时缓存确认没有旧版本文件残留聚合包和单个skill重复功能重叠合并同类skill只保留覆盖面最广的那一个这份排查表是我真金白银换来的经验。特别是description写太宽泛导致触发错乱这个问题可以说十个skill翻车里有八个都是栽在这里。写描述时有个技巧先写场景再写输入最后写输出三要素缺一不可。比如当你需要把CSV数据转换成中文报告时使用比数据处理好一百倍。5.3 如何建立自己的skills迭代节奏最后聊聊长期维护。skills不是一次写完就完事的它应该跟着你的工作方式一起演进。我的建议是每两周专门留一个小时来做skills维护翻一遍现有skills、看看哪些可以优化、哪些可以删除、有没有新场景值得沉淀。另外一个容易被忽略的地方是好的skills往往是一线项目复盘出来的不是凭空设计的。我在给朋友写AI漫剧分镜skill之前她根本说不出自己有什么固定偏好是我观察她做了十几个分镜之后才总结出那些隐含规则。所以当你觉得某个任务反复手工调整时先别急着忍把它写成一个skill一次投资长期受益。我还想说一点skills的写法本身也在进化。现在的生态里很多人开始把skills和MCP工具链打通比如skill里直接引用外部工具节点让AI既能按流程办事又能调用数据服务。未来一段时间的趋势一定是工具能力越来越标准化个人差距越来越体现在你沉淀的skills方法论上。我个人在实际操作中的体会是skills这套东西上手门槛比想象中低但真正把它用好需要的是你对自己工作流有清晰的认知。花点时间把重复劳动固化成skill短期看是慢了长期看是稳赚不赔的事。希望这篇能把你在AI编程skills这条路上省下不少试错的弯路。