AI编程圈子里的热度几乎全被skills这个词承包了。无论是Claude Code、Codex还是OpenCode大家都在讨论怎么给自己的AI助手装上一套可复用的“专业技能包”。我最早接触skills是在折腾Claude Code自动写前端页面的时候——同一套组件规范、同样的视觉风格每次都要在提示词里重新交代一遍累得不行。后来发现skills机制可以把这些固定流程打包成一个个独立文件夹AI在合适的时候自动调用效果比想象中稳定得多。这篇文章不聊抽象概念我会从安装、编写、推荐到清理把我实操中验证过的方法完整过一遍适合所有想把AI助手用得更有深度的人。1. Skills 到底是什么先把它当成AI的“专业外挂”1.1 一个skills包长什么样先说个最直观的结论skills本质上就是“给AI看的说明书配套脚本的文件夹”。它不是一个宏大的框架更不是什么需要重新训练的模型。你完全可以把它理解成一个标准的项目目录只要按约定放好文件AI就能在需要时读取并按照里面的指示来完成特定任务。以我目前主力使用的Claude Code为例一个最普通的skills包长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── generate_report.py └── assets/ └── template.md核心是那个SKILL.md。它用Markdown写成开头有一段YAML格式的元信息包括技能名称、功能描述、允许使用的工具等后面则是具体的操作指引。AI在对话时读到这个文件就会根据描述决定“现在该不该调用这个技能”。这里的关键在于skills不是让AI背规则而是给AI提供一份“操作手册”。就像你给实习生一份带步骤的SOP他照着做就能完成一项完整工作而不是每次都要从头解释。1.2 为什么superpower skills能爆火很多人第一次听说skills都是因为superpower skills这个开源项目。其实它的原理并不复杂真正打动人的是“打包思维”。以前我们让AI干活靠的是每次在对话里写一大段提示词现在把这些提示词整理成结构化的文件放进一个标准目录AI就能在不同项目里反复调用。我个人的体会是superpower skills真正牛的地方是把那些“人人都能用、但需要花时间总结”的通用工作流沉淀了下来。比如代码审查、文档撰写、复杂问题拆解、任务规划这些技能在多个项目里都能复用节省下来的时间非常可观。而且这个项目带火了一个概念skill也可以是“组合拳”。一个技能里面可以串联多个步骤比如读取代码、分析边界条件、生成测试用例、执行测试、输出报告整个过程被串成一条流水线。AI不再只是“回答一句话”而是“完成一个项目环节”。1.3 适用场景与使用边界那是不是所有场景都适合用skills呢并不是。我自己用下来的经验是最适合skills的场景有三类重复性高、流程稳定的任务比如前端项目的组件规范检查、数学建模比赛中的数据处理模板。需要专业领域知识的内容比如AI漫剧的分镜设计、角色一致性描述这些知识很难靠临时对话说清楚。跨项目复用的通用能力比如代码评审、README生成、Git提交信息规范。但如果是那种“一次性的、个性化极强”的任务比如“帮我把这个文案改得更幽默”特意写一个skill反而画蛇添足。判断标准很简单这个任务我会不会重复做三次以上如果会才值得做成skills。2. 手动安装GitHub上的Skills完整实操记录2.1 先搞清安装路径项目级与用户级从GitHub安装一个现成的skills听起来挺简单但第一步就经常有人搞错到底放到哪个目录不同的AI工具约定不同但大方向是一致的。以Claude Code为例官方支持两种层级用户级全局目录~/.claude/skills/所有项目都能用适合放通用类技能。项目级本地目录.claude/skills/只在当前项目生效适合放与这个项目强绑定的技能。我的建议是个人开发阶段先用项目级目录因为改动方便、不会污染全局环境一段技能彻底稳定之后再移到全局目录。比如我在做一个React项目时会专门写一个“组件规范检查”的skill放在项目里项目做完发现其他项目也用得上再复制到全局去。2.2 clone、拷贝、软链三种安装方式的取舍从GitHub手动安装一个skills具体有几种方法我按实用程度排序。方法一git clone到临时目录再拷贝git clone https://github.com/yourname/awesome-skill.git mkdir -p ~/.claude/skills cp -r awesome-skill/skill-name ~/.claude/skills/ rm -rf awesome-skill这种方式的优点是干净不会在本地留下多余的git仓库。缺点是如果原作者更新你需要重新拉取再拷贝升级比较麻烦。方法二直接把仓库克隆到位git clone https://github.com/yourname/awesome-skill.git ~/.claude/skills/awesome-skill这样后续更新直接用git pull就行。缺点是这个目录会保留.git信息如果你用某些AI工具扫描技能目录时把它当成普通文件偶尔会多出一些噪音。方法三软链接我个人最推荐git clone https://github.com/yourname/awesome-skill.git ~/dev/skills/awesome-skill ln -s ~/dev/skills/awesome-skill ~/.claude/skills/awesome-skill这样你开发skills时可以直接在原始仓库里改改完立即生效不需要反复拷贝。对频繁调试skill的人来说这几乎是最高效的方式。我写自己的skills集时全程都是用软链改完文件不用重启AI环境新对话里就能用上。如果你用Codex或者OpenCode安装路径可能会有一点差异但思路完全一致先找到对应工具的全局或项目级技能目录然后把skill文件夹放进去。这一步是最核心的路径找对了后续就顺了。2.3 装完怎么验证让AI真正用上这个技能很多人以为把文件夹放进去就算装好了其实还没完。我见过不少新手装完后发现AI完全没有反应于是怀疑skills没用。其实安装完成后要做的第一件事是“确认AI能看到它”。以Claude Code为例你可以直接问AI“当前项目里有哪些可用的skills”让它列出目录内容。再用一个能触发该技能的任务去测试比如装了一个前端代码审查的skill就随便打开一个前端文件问“帮我按团队规范审查一下”。如果AI开始引用skill里的步骤说明安装成功。另外要注意的是很多AI工具不会在每次对话里自动加载所有skill而是根据任务描述去匹配。如果你装完发现AI“没反应”先别急着怀疑安装问题很可能是当前的query不够“触发”这个技能。后面我专门写一节排查技巧。2.4 踩坑目录名、权限、版本不同步手动安装这件事踩过的坑比想象中多。这里集中列一下目录名不能乱改有些skill内部会有相对路径引用和自身目录相关的资源比如assets/里的文件。你如果为了让名字好看改掉了文件夹名很可能导致资源加载失败。所以手动安装时尽量保留原始目录名。不要漏掉隐藏文件很多skill会包含.gitignore或者.env.example拷贝时如果用了cp -r但没开通配符隐藏文件可能丢。最简单的办法是直接进入目录后再拷贝。检查执行权限如果skill里带了scripts/*.sh可能要执行chmod x才能被调度。我遇到过一次shell脚本无法执行查了半天才发现是权限位不对。这些坑在官方文档里很少写但一旦踩到会浪费不少时间。3. 自己写Skills的正确姿势从模板到落地3.1 SKILL.md 的 frontmatter 怎么写如果你想真正用上这项能力光会装是不够的一定要学会自己写。自己写最大的好处是完全贴合自己的工作流不用去迁就别人的思路。我从一个小小的前端规范检查skill开始到现在已经积攒了二十多个自己的skill每次写完都有一种“给AI派了份固定工作”的踏实感。先看最基础的部分frontmatter。它决定了AI何时使用这个技能。--- name: frontend-a11y-check description: 检查项目中的前端可访问性问题包括图片缺少alt、按钮无aria-label、表单缺少label等。当你需要评估web页面或组件时使用。 allowed-tools: grep, read, list ---name不需要花哨机器可读即可。真正重要的是description因为AI是靠它来判断“当前任务是否匹配这个技能”。你不能光写“可访问性检查”要写清楚“在什么场景下用、具体覆盖哪些问题”。我建议在description里加入触发条件词比如“当你需要评估web页面或组件时”这样匹配概率会大幅提升。allowed-tools是告诉AI执行这个技能时需要哪些工具这能避免它在检查过程中随意使用危险操作。不过也不要限制太死至少保留读取和搜索类工具。3.2 正文body的书写原则让AI能“看懂并执行”frontmatter下面是正文。正文的写法直接决定技能质量。我总结出几个原则用步骤不要用概念。不要写“检查代码的可维护性”而要写“1. 打开目标文件。2. 定位所有函数声明。3. 检查是否存在超过50行的函数若有则记录。4. 检查重复代码块若有则标记具体行号。”给出判断标准。比如“当图片标签没有alt属性时视为错误”这比“注意图片可访问性”有效得多。提供输出模板。让AI按固定格式输出比如用表格列出问题等级、文件位置、修改建议。这样你一看结果就知道下一步该做什么。还有一个容易被忽略的点允许AI在遇到边界情况时跳出skill。写一句“如果发现某种情况不在上述流程中请根据常识处理并备注”可以避免AI生硬地按脚本执行显得很蠢。3.3 结合scripts把模块化脚本包进去纯文本的skill只能指导AI做事但如果想让AI真正执行某些重复性高的动作还得靠配套脚本。比如我自己写过一个“生成项目目录树”的skill里面就放了一个Python脚本用来递归扫描目录并输出指定格式的树状图。#!/usr/bin/env python3 import os, sys def print_tree(root, prefix, ignore[.git, node_modules, __pycache__]): entries sorted([e for e in os.listdir(root) if e not in ignore]) for i, entry in enumerate(entries): connector └── if i len(entries)-1 else ├── path os.path.join(root, entry) print(prefix connector entry) if os.path.isdir(path): print_tree(path, prefix ( if i len(entries)-1 else │ ), ignore) if __name__ __main__: print_tree(sys.argv[1] if len(sys.argv) 1 else .)然后把脚本的调用方式写在SKILL.md里AI就可以在需要时自己运行。这里有个关键点脚本路径要写相对路径最好基于SKILL.md所在目录来解析。因为很多AI工具执行脚本时工作目录可能是项目根目录而不是skill目录如果你用绝对路径换个环境就废了。3.4 测试与发布先本地验证再上传GitHub写完skill后我强烈建议按照下面这个流程走一遍单文件测试先用一个最小项目把skill放在项目级目录里手动触发一次看输出是否符合预期。边界测试故意给AI一个“不太像该用这个skill”的任务看它会不会错误调用。如果错误调用频繁就说明description写得太宽。换场景测试把skill移到全局目录换一个完全不同的项目再试一次确保没有依赖隐藏路径。发布确认稳定后上传到GitHub。README里要写清安装方式最好附带示例输出。发布这件事很多人不重视觉得“我自己用就行了”。但我的经验是发布到GitHub不仅能让别人受益还能倒逼你把描述和目录结构整理得更清晰。事实上我大部分skill的第一次重构都是发生在准备发布的时候——写README时发现自己有些说明根本讲不清楚。4. 常用Skills资源推荐前端、数学建模、内容创作怎么选4.1 前端开发skills代码生成、评审、重构前端是skills应用最热门的领域之一因为前端项目的模式化程度很高重复任务多。我在前端开发里最常用的几个skills方向是组件规范生成根据团队约定生成React/Vue组件文件自动带上样式、类型定义、基础测试。代码评审从性能、可访问性、语义化、依赖大小等维度进行评审并给出修改建议。样式系统治理用于扫描CSS中的魔法数字、重复色值并建议提取为设计变量。选前端skills时我建议优先选“描述清晰、自带脚本”的。有些skill只给一段泛泛的提示词这样的技能包价值不高。真正好用的前端skill会告诉你它具体检查哪些规则而不是说“请提升代码质量”。4.2 数学建模skills华为杯/国赛向其实不只是华为杯各类数学建模比赛这两年都开始流行给Codex或Claude Code配数学建模skills。因为这些比赛时间紧、任务重如果能用AI快速完成数据清洗、特征工程、结果可视化甚至按论文模板生成LaTeX就能节省大量时间。我印象比较深的有几个方向数据预处理模板自动识别缺失值、异常值做分布分析并生成数据探索报告。建模思路库根据不同题目的特征推荐适合的模型。比如预测类问题给时间序列/回归方案优化类问题给规划/启发式算法方案。论文排版助手导入比赛论文模板按结构生成标题、摘要、章节并插入图表引用。这类skills在使用时要注意比赛环境离线很多不能依赖AI实时联网。所以我在给比赛准备skill时会刻意把资料、模板全部放在skill目录里让AI在本地就能完成大部分工作。4.3 内容创作/AI漫剧skills分镜、角色一致性、画面提示词AI漫剧是最近很火的应用方向很多人在做漫画改编、动态漫、短视频漫剧。这个领域的skills核心是解决“角色一致”和“分镜稳定”两大痛点。常见的AI漫剧skills包括角色设定管理保存每个角色的外貌、服装、性格标签在生成画面时复用避免同一角色出现两张不同面孔。分镜脚本生成输入剧情文本输出分镜编号、景别、运镜、画面说明和对应提示词。画风统一把指定画风的描述词内置比如“厚涂、赛璐璐、水墨、3D渲染”生成任何画面时都附加统一风格约束。我自己试用过几个内容创作类skill感觉最有用的是“角色一致性”这种。因为它不是靠一次生成完成的而是需要在多轮对话中持续绑定角色描述如果没有skill你很难在一部长篇漫剧里保持所有画面里的角色形象一致。4.4 社区资源站点与检索技巧想找更多现成的skills无非就是几个渠道我习惯这么搜GitHub搜索直接搜claude skills、codex skills、awesome skills注意看stars和最近更新日期。Awesome 列表有一些专门的仓库收录了优秀skills比如awesome-claude-skills之类里面通常有分类和简介。个人博客/推文很多作者会写“我常用的skills推荐”这种内容往往包含真实的适用范围和踩坑描述比仓库README更有参考价值。检索时有个小技巧不要只看stars要看issues。如果一个skill仓库的issues里有很多人反馈各种路径问题说明它适用范围有限但同时也说明它确实有人用使用场景明确。最怕的是那种几百个stars但一年不更新的仓库装上去大概率要踩坑。5. Skills的日常管理与清理像维护工具箱一样维护技能库5.1 查看已装skills与目录体量skills装多了之后最直接的问题是“乱”。有时候你都不知道自己装过什么更别提AI还要在这么多候选里找到最合适的。我最早一度装了几十个skill结果AI经常调用错误的那个气得我全部删掉重新来。建议你先做个“技能盘点”。在终端里跑一下这些命令ls -la ~/.claude/skills/ du -sh ~/.claude/skills/* | sort -h第一行看有哪些技能第二行看每个技能占用多大空间。往往能发现一些体积异常大的“技能”——比如有人不小心把模型权重文件放进了assets目录一个skill占几个GB完全不合理。5.2 更新、回滚与去重技能更新是个常被忽略的问题。用GitHub仓库直接克隆的skill更新还算简单git pull就行。但你会遇到一个问题原作者改了目录结构而你本地已经基于旧版本做了一些自定义修改一pull就冲突。我现在的习惯是尽量不直接改第三方skill如果要改就把修改记录写在skill目录里的 CHANGELOG.md 中。这样即使pull发生冲突也能根据记录快速决定是保留本地版本还是用上游版本。还有一个容易被忽视的点去重。很多skills功能是重叠的。比如三个代码审查skill一个查安全一个查性能一个查风格但它们都会在“帮我看看代码”时被触发AI可能选错。我的解决办法是统一维护一个“技能清单表”记录每个技能的适用场景、冲突项、最后使用时间。当我发现某个skill连续一个月没被调用就会考虑清理。5.3 自制清单脚本统计哪些skills最常用为了判断哪些skill该清理我写了一个简单的Python脚本统计AI工具日志中各个skill被调用的次数。大致思路是读取工具日志文件按skill名称做计数然后输出排序。import re from collections import Counter from pathlib import Path logs Path(~/.claude/).glob(*.log) name_counter Counter() for log in logs: text log.read_text(errorsignore) for skill_name in re.findall(rskill:([a-zA-Z0-9\-_]), text): name_counter[skill_name] 1 for name, count in name_counter.most_common(): print(f{name}\t{count})这个脚本并不复杂关键思想是不要凭感觉管理skills要让数据说话。看完统计结果我往往能发现几个“我以为很常用、其实一次没调过”的技能可以直接删掉。5.4 给新手的建议少而精别囤货关于skills管理我最想给新手的建议就四个字少而精。你不需要跟风装一堆似乎很酷的skills更不应该看到“superpower skills”就整个仓库克隆下来。因为你很难理解每个子技能在什么场景下起作用只会增加AI的匹配负担。我见过太多人装了100个skill结果AI平均响应变慢还老是调错。正确的做法是从一个你当前最痛、最频繁的任务开始先手动写一个skill。把它用到顺手逐步往里面补充细节。确定稳定后再考虑从社区找2-3个同类型的佼佼者来对比参考。每装一个新skill就删掉一个不再用的旧skill。我自己现在保持的活跃技能数量大约在8-12个这个体量既能覆盖大部分场景又不会让AI“选择困难”。有时候与其追求技能数量和功能覆盖面不如专注把少数几个做深。6. 常见问题与排查技巧实录6.1 agent总是忽略我的skill怎么办这是我在各种社区里看到最多的问题。装好了skills但AI就是不用。最常见的三个原因description写得太模糊AI在匹配时无法确定这个skill是否适用。解决方法是把触发场景写具体比如“当你需要生成一个React组件时”而不是“可以用来生成前端代码”。技能目录层级不对。有些工具要求每个skill直接是skills目录下的一个子目录不能再嵌套一层。你放成~/.claude/skills/xxx/my-skill/AI可能只扫到了外层xxx而外层没有SKILL.md文件自然无法识别。全局/项目级冲突。如果项目级目录里有一个同名skill它可能会覆盖全局同名skill。遇到“明明更新了全局skill却还是旧行为”的情况先检查项目里有没有同名文件。6.2 description描述不清导致匹配失败我调试过一个自己的“生成周报”skill一开始description写的是生成周报。结果AI在用户问“帮我总结一下这周的事情”时完全没有调动它。后来我改成生成项目周报。当用户要求总结本周工作进展、列出完成事项、规划下周安排时使用。输入是本周的工作记录列表。改动之后AI的匹配率立刻上来了。这说明description的核心不是“它是什么”而是“在什么情况下使用它”。6.3 相对路径、工具权限、模型版本问题安装和编写之外还有几个容易忽略的“技术坑”相对路径失效SKILL.md里写的脚本路径如果用的是./scripts/xxx.py实际执行时可能因为当前工作目录是项目根目录而找不到文件。建议在skill里统一约定所有相对路径都相对于SKILL.md所在目录并在正文中显式写“先定位到当前技能目录”。allowed-tools 限制过严如果你只在frontmatter里允许了read但技能步骤里需要执行python脚本AI会因为权限不足而拒绝执行。我通常会至少写上read, list, run, edit, grep。模型版本低有些老模型可能没有接受过skills相关训练或者不支持复杂的技能调用。如果你发现某个skill在上一版本模型里好用、升级后变迟钝可以先去工具的官方changelog里看看是不是有配置开关需要重新开启。6.4 快速自查清单最后我把踩过坑之后总结出来的“安装-运行-调试”检查清单放在这里每次遇到问题照着走一遍基本能解决九成的问题[ ] 技能目录是否直接位于skills根目录下且包含SKILL.md[ ] frontmatter中name是否与目录名一致[ ] description是否包含足够的触发条件词[ ] 技能引用的脚本、资源是否存在且路径写法是基于SKILL.md的相对路径[ ] 是否有同名skill存在于项目级目录造成覆盖[ ] 工具是否给AI授予了执行脚本的权限[ ] 用最简单的场景测试AI是否输出了预期结果我自己在实际操作中还有个习惯每次调试skill时都会在旁边打开技能目录实时看AI的思维链和它读取了哪些文件。一旦发现它没读SKILL.md马上就能定位到匹配问题。这类问题大部分不是功能缺陷而是“人没写清楚、AI不知道该用”。技能技能关键就在于你怎么把经验结构化地表达给AI。你写得越清楚AI就越像你的资深同事。