最近两个月Skills这个词在我常用的几个AI编程工具社区里突然就刷屏了。打开GitHub Trending一半仓库叫awesome-skills另一半叫xxx-skills。Claude Code、Codex、OpenCode甚至一些本地跑的Agent框架全都在讲技能、装技能、写技能。我自己一开始是有点抵触的——不就是给Agent配几个Prompt吗搞出这么大声势。直到我把一个开源Skill真正装进去、让Agent自己跑通一条从前需要我手写50行脚本的流程之后我才意识到这玩意儿的价值不是多一个配置文件而是一种全新的协作方式。如果你也和我一样被skillsuperpower skillclaude code skills这些词轰炸过又不太清楚它们和插件、MCP、提示词有什么区别那这篇就按我的理解给你捋一捋。我不打算讲华丽的理论就讲我真正装过、写过、用过的经验从安装到开发再到踩坑清理一条线走完。想学Skills怎么用、怎么写或者只是想找一些靠谱的skills源站这篇都能给你一些可落地的参考。1. Skills不是插件也不是提示词——它到底是个什么东西1.1 从会聊天到会干活Skills补上了LLM缺的那只手先把结论放在前面一个Skill的本质是一份结构化的人类专业经验文档加上辅助脚本让大模型在遇到特定任务时能按照这套经验去执行而不是靠随机应变。说得更直白一点你平时在对话框里贴的那段请扮演资深前端工程师帮我做代码审查注意性能边界——那是提示词。而Skill就是把这段提示词固化成文件再配上几个能处理具体文件的脚本让Agent可以动手去完成整个流程。我最早用Claude Code的时候经常要在会话里反复交代你是资深Python开发者你写的代码要带类型注解遇到API报错优先查日志。这些话每次都讲一遍Agent还是会在关键决策点自由发挥。后来我装了第一个来自GitHub的Skill效果立刻不一样——它不只是记住了规则而是直接在本地创建一个临时工作目录把待处理代码拖进去跑完静态分析再把结果分类输出。那种感觉就像你原来雇了个聪明的实习生现在给他一本岗位手册和一套工具箱他终于能独立干活了。这种转变的本质是把大模型从一个什么都懂一点但需要反复叮嘱的顾问变成一个手里有清单、脚下有工具的执行者。Skills解决的核心问题不是模型能力不够而是模型的输出太不稳定——同一个问题隔半天再问它的过程可能完全不同。有了Skill过程被固化成流程模型只需要按流程执行结果自然就稳定了。1.2 Skills、MCP、Prompt、插件几个概念的边界很多朋友一上来就懵是因为这几个词长得太像。我做个简单的对照概念本质类比Prompt / 提示词对话中的指令文本口头交代任务System Prompt / 人设指令模型的系统级行为约束入职第一天发的公司章程Skill结构化SOP 辅助脚本岗位手册加工具箱MCP Server外部工具接入协议公司内部的审批系统接口Plugin / 插件带UI或程序入口的扩展独立的外挂设备最核心的区别在于Skill不是在对话里告诉模型怎么做而是把怎么做变成一套可复用的工作流。MCP解决的是Agent够不到外部数据的问题Skill解决的是Agent不知道怎么做得专业的问题。两者能配合但不能互相替代。比如一个数学建模Skill可能用MCP去读Excel数据用自身脚本做数据清洗再按论文模板生成报告这是典型的分工。1.3 为什么这一轮Skills突然火了Claude Code和Codex们的共性我观察了一下这轮Skills热不是某个厂商造出来的概念而是几个主流编程Agent几乎同时开始支持类似的规范。Claude Code在2.x版本里引入了对.claude/skills目录的原生支持Codex这边也有自己的skills机制OpenCode社区更是直接搞了个skills市场。各家底层虽然不完全互通但文件结构的思路高度一致一个目录丢进去里面放个SKILL.md再加几个可执行脚本就形成一个技能。这种目录即技能的设计把过去靠人肉复制粘贴的黑话配置变成了可以被版本管理、被分享、被组合的标准单元。所以你会看到GitHub上有人专门整理前端开发skills数学建模skills还有人把整个skill库做成git仓库方便一键克隆。这是它快速传播的最根本原因——可复制、可审计、可迭代。再说说如何学习skills这件事。我的建议是不要先看概念直接找个开源skill装上用一次。你只有真实体会到原来Agent还能这么干活才会理解结构上那些设计为什么存在。等用顺了再拆解你会发现skill根本没多难。2. 安装一个Skill的完整实操从GitHub到跑起来2.1 手动安装的两种路径CLI命令和文件目录放入先解释一下什么叫手动装。现在很多工具都支持从市场直接装但GitHub上大量Skill并没有进市场或者说你想用的版本比市场新这时候就得手动装。以Claude Code为例最朴素的安装方式是把仓库里那个skill文件夹放到项目的.claude/skills/下。比如你找到一个叫superpower-skills的仓库里面有几十个子文件夹每个都是一个skill那你可以用git clone把仓库拉下来然后挑出你要的那几个复制到指定位置。# 以Claude Code为例 git clone https://github.com/example/superpower-skills.git ~/skills-src mkdir -p ~/.claude/skills cp -r ~/skills-src/skills/code-review ~/.claude/skills/如果你用的工具是OpenCode或者类Visual Studio Code的Agent客户端路径可能不一样常见的有~/.config/opencode/skills、~/.opencode/skills、或者是项目根目录下的.opencode/skills。装之前最好先看下README人家写清楚支持哪个路径你就放哪放错位置不生效这个我在第六部分会专门讲。2.2 官方/第三方市场skills网页版入口和一键装的真相很多人在搜skills网页版入口skills下载是想找到一个网页点两下就能装技能。实际情况是目前没有统一的官方Skills商店各家有各家的入口。Claude Code的skills市场还比较早期OpenCode倒是搞了个比较像样的registry还有社区做的awesome-skills导航页。我试过几个一键安装命令本质上还是抓取GitHub仓库、解析SKILL.md、往对应目录写文件和你手动操作没区别。所以我的建议是别迷信一键装看命令干了什么再执行。开源社区的命令一般会把安装源和落位路径打印出来值得养成习惯每次装完都把安装日志过一遍。技能这种东西不像普通npm包装错了不会报错只会在你需要的时候静默不生效比较难受。2.3 安装后必做的三件事验证、权限、日志装完Skill不是就完事了一定要做三件事。第一验证。找一个临时目录故意构造一个该Skill适用的任务看Agent是否按SKILL.md里的步骤走。我装数学建模skills的时候就拿一份CSV让它做数据探索它一口气跑出了缺失值统计、分布图和建模建议说明这家伙确实被激活了。如果没有任何变化先怀疑路径放错。第二权限。很多skill会申请执行shell命令、读写文件。Claude Code会弹权限请求你在装完第一次使用时务必看清楚它要跑的到底是什么命令。我遇到过某个skill的脚本里有rm -rf开头的清理逻辑虽然它在指定目录下工作我还是改成只打印日志不直接删除。权限审查永远不能省。第三日志。把Agent在某个任务中的完整思考/调用记录存下来跑完翻一翻既能确认Skill是否被加载也能提前发现脚本层面可能有的路径硬编码。2.4 SuperPower Skills的安装经验谈SuperPower Skills在热词里出现频率很高它其实是社区里一套很全的skills集覆盖写作、编程、数据分析等上百个方向。安装它最让我头疼的是目录特别深、文件特别多复制时容易手滑漏掉引用文件。我后来学乖了直接用git sparse-checkout只拉自己需要的那几个skill省时省力。# 只拉取需要的一个子目录 git clone --filterblob:none --sparse https://github.com/example/superpower-skills.git cd superpower-skills git sparse-checkout set skills/writing-assistant这个操作是想告诉那些手动装大仓库的朋友不用整个仓库都搬过来用sparse checkout选子集干净又快速。SuperPower这类skill集的强项是开箱即用质量也比较稳定适合新手建立对skill的体感。3. 解剖一个Skill的内部结构SKILL.md与scripts是怎么协同工作的3.1 一个典型Skill的目录清单先给你看一个我从GitHub上clone下来后实际跑过的skill目录名字就叫code-reviewcode-review/ ├── SKILL.md ├── scripts/ │ ├── analyze.py │ └── report.py ├── templates/ │ └── report_template.md ├── prompts/ │ └── intro.md └── metdata.json注意不是每个skill都长这样但最核心的两个东西一定有SKILL.md或者叫skill.md和一个可执行脚本。剩下的templates、prompts、metdata.json都是锦上添花。理解了这一点你对skill的很多误会就会消失——它真的不是一个神秘的黑盒就是一套有固定约定的目录。3.2 最关键的SKILL.md前置条件、步骤分解和输出约束SKILL.md是这个技能的大脑。我见过的优秀写法一般会包含这么几个部分名称与简介、适用场景、前置条件、执行步骤、输出格式、注意事项。写法上特别强调给Agent看的指令要明确到状态机级别每一步最好有判断条件如果A成立则走B否则走C。下面是我从某个开源skill里抽象出来的结构--- name: code-review description: 对指定目录的Python代码做一轮静态审查输出问题清单和修复建议。 --- ## 适用场景 - 代码量在1000行以内的仓库或目录 - 需要快速定位潜在的逻辑错误和风格问题 ## 前置条件 - 已安装Python3.12 - 目标目录内不能有大型二进制文件 ## 执行步骤 1. 复制目标目录到临时工作区避免污染源文件 2. 运行 scripts/analyze.py --dir temp_dir收集AST级别问题 3. 运行 scripts/report.py --input analyze_result --output out_dir 4. 将生成的report.md内容作为最终回复 ## 输出格式 - 按错误级别分组问题critical / warning / info - 每条问题包含文件路径、行号、原因说明 ## 注意事项 - 不要修改源文件 - 如果源码大量使用动态特性跳过critical级别未遂的误报你会发现这份文档不是在解释代码审查是什么而是在告诉Agent你现在是个代码审查执行者按这个流程走。这正是Skill和普通Prompt的本质差异它把判断和执行拆开了Agent只负责推理和调用流程和标准都写在文件里。3.3 脚本和资源文件shell之外还能装什么SKILL.md负责说scripts负责做。脚本不一定是PythonNode.js、shell、Ruby都行只要Agent能调用且你的机器上有对应解释器。我在实际项目里用过三种类型纯数据处理脚本比如把CSV转JSON、做简单的清洗这种写Python最顺手。调用外部API的脚本比如Skill要和知识库通信脚本会封装请求头、限流逻辑。生成报告模板的脚本用模板文件填充变量输出结构化Markdown。还有一类资源文件值得注意templates和prompts。templates是输出模板prompts是给Agent的补充对话上下文。有些Skill在运行到特定阶段时会把prompts/里的额外指令也拼接进对话历史相当于流程中的提示词分镜脚本。这个设计很聪明因为它让Skill不再依赖一次性把话说全而是按阶段喂给Agent。3.4 为什么说Skill就是给Agent的一份SOP我用了很多次岗位手册这个类比其实更准确的是SOP——标准作业程序。把一家公司里某个岗位的专家经验拆解成什么时候做什么、做到什么程度、出什么成果的步骤就是一份可以被复制的Skill。这就是为什么skills开发并不是什么高深的事你完全可以把一个老员工教会新员工的过程这一段话一段话地固化下来再配几个自动化脚本一个Skill诞生了。理解了这一点你就知道网上那些AI skills怎么写的教程本质上教你的是专业流程建模——先把业务拆流程再把流程写清楚最后用脚本把重复劳动接上。写代码反而是最简单的部分。4. 从零写一个自己的Skill需求拆解到发布的关键环节4.1 选场景一个Skill应该小到什么程度初学者常犯的错误是野心太大想一个Skill包揽数据分析图表美化论文写作。我建议从一次会话能结束的任务起步比如把Markdown文档里的中文和英文之间自动加空格或者扫描一个目录的图片按尺寸分类并输出清单。为什么因为Skill的测试闭环很短你写一个SKILL.md放两个脚本构造一次任务5分钟就能验证效果。真正值得沉淀成Skill的场景一般有三个特征流程稳定、判断点清晰、重复频率高。如果一项任务你每两周就要让Agent干一次而且每次你都要重新解释一遍要求那它就应该被写成一个Skill。4.2 设计Prompt把专家知识压缩进SKILL.md写SKILL.md很容易写成一篇介绍如何做某事的文章而不是一份让Agent执行的作业指导书。我的经验是每一句话都要能转换成Action。不要写分析数据质量而要写对每列计算缺失值比例若超过30%在该列的summary中标记WARN。前一种句子Agent看了等于没看后一种它才知道起身干活。我还会刻意在SKILL.md里加入反面示例。比如在当前项目里我写过一个代码变更说明生成的Skill专门在注意事项里写明不要使用优化代码结构这类无信息量的变更描述必须说明改动的函数、文件和验证结论。激励模型用具体词汇往往比泛泛而谈更有用。4.3 编写脚本让Agent动手而非只是建议脚本不一定要复杂但一定要可执行、可验证。我写过一个图片统一重命名的Skill脚本极其简单20行Python读取目录下所有JPG/PNG按拍摄时间排序重命名为IMG_20250101_001.jpg。真正让这个Skill值钱的是SKILL.md里写的处理规则重复名字冲突时要加后缀而不是覆盖、重命名之前先写一个dry-run清单让用户确认。逻辑全在规则里脚本只是执行器这个思维方式很关键。代码建议写得verbose一点给Agent留下足够信息。因为Agent不是你它不知道哪个中间结果重要。脚本最好每个关键步骤都print一行状态SKILL.md里也写明如果运行失败把最后五行日志发给用户寻求决策。这样当脚本出错时Agent能基于日志继续推理而不是干瞪眼。4.4 本地测试与迭代我常用的验证方法本地测试我一般走三步。第一步冷启动测试。不告诉Agent任何额外信息直接扔给它一个符合Skill适用场景的任务看它是否自己发现并激活这个Skill。很多框架的Skill不是默认加载的而是靠语义匹配触发如果Agent完全没有提到Skill说明命名或description写得不够清楚。第二步边界测试。故意给一个不太符合的场景比如Skill是代码审查你扔一个空目录看它会不会礼貌地拒绝而不是瞎编报告。这一步能看出SKILL.md里的前置条件写得够不够细。第三步回归测试。把上个月用这个Skill处理的旧任务重新跑一遍对比输出看迭代没有破坏原有能力。如果你在改SKILL.md这一步尤其重要因为提示词微调很玄学可能改了措辞整体效果就变了。4.5 发布与分享打包标准和语义化命名写完Skill把它push到GitHub是最自然的分享方式。但有几个细节需要养成习惯仓库根目录直接放skill目录README里写清楚支持的工具和安装路径。包一个许可证我习惯用MIT但有些商业项目会用Apache License。命名遵循purpose-language-tool模式比如emoji-clean-up-claude方便别人搜索。在metdata.json里注明Agent工具的兼容版本别含糊。另外如果有人想把自己的Skill发布到OpenCode市场流程一般是Fork它们的registry仓库在索引文件里登记你的仓库地址和描述。这个动作不算难但对那些想走正规渠道传播的朋友是必须的。5. 场景化Skills组合推荐前端、数学建模、漫剧与日常5.1 前端开发CSS重构、组件生成、性能分析类Skills前端开发Skills是我安装得最多的一个门类因为任务类型特别适合固定流程脚本扫描。我最满意的一个Skill叫css-analyzer它会用puppeteer脚本加载页面收集未使用的样式规则结合lighthouse数据给出优化建议。原来我做这类分析要开DevTools、手动记录网络请求现在一句话Agent自己开无头浏览器跑一遍输出带证据链的报告。组件生成类的Skill也有意思比如你可以把自己的UI规范间距、色彩、圆角写进SKILL.md让Agent生成新组件时自动遵守。这个本质上是把design system翻译成Agent能看的条例。如果团队里有人专门维护设计规范把这个迁移成Skill并不难收益却很直接。我的建议是前端Skills不必贪多挑频繁用、判断标准明确的装比如代码审查、样式清理、可访问性检测其余按需再装。5.2 数学建模从建模比赛到论文撰写的Skills搭配含华为杯、Codex华为杯、数学建模这几个词在Skills热词里热度很高我特意去研究了一下。数学建模赛题通常有一套固定的工程化流程数据清洗、模型选择、调参、结果可视化、论文撰写。这套流程如果全部靠人肉完成非常耗时间而Skills正好天生适配。我看到社区里有人做了一个建模论文自动生成的Skill它把国赛/华为杯的评分要点拆进了SKILL.md比如摘要要包含核心结论和灵敏度分析模型要给出假设依据和适用条件然后脚本负责把实验结果渲染成表格和图表。配上Codex的skills机制整个工作流能省掉大概三分之一的人工整理时间。我对参加比赛的学生的建议是不要把所有期望都押在一个一次全自动的Skill上而是拆成几个子技能eda-explorer做探索性分析、modeling-notebook做模型拟合、report-drafter做论文骨架。这几步之间留人工确认的节点反而稳。5.3 AI漫剧与内容创作脚本、分镜、配音对齐的Skills流AI漫剧是最近在短视频平台火起来的内容形态主要是用AI生成漫画分镜、配音、脚本。它的制作流程也很标准化先有剧本再拆场景再生成角色一致的分镜图最后配音和字幕对齐。这个流程里Skills能帮大忙。我见过一个做漫剧的博主分享过自己的skills流一个Skill负责把小说章节细化为分场脚本包含场景描述、台词、镜头运动另一个Skill负责基于角色设定文件生成提示词确保主角样貌稳定第三个Skill做字幕对轴输入音频和时间戳输出标准SRT。这中间每个Skill都只是解决一个很小的问题但组合起来就是一条完整的量产流水线。写这种内容类Skill最需要注意的就是风格一致性。你可以把角色设定写进SKILL.md甚至把主角眼睛是琥珀色生气时会露出虎牙这种细节都写进去然后让Agent在每次画面描述中都引用该设定文件。效果比你每次手工Copy Prompt稳定得多。5.4 通用常青树代码审查、文档生成、数据清洗如果你不确定从哪些Skill开始装我建议先从这几个通用常青树入手代码审查无论什么语言一个能扫AST并分类问题的Skill都值得装。文档生成扫描项目目录自动生成README、CHANGELOG、API索引。数据清洗对CSV/JSON做缺失值、异常值检查并生成数据质量报告。日志分析输入一段日志按级别聚合、提取报错堆栈输出调查报告。这些Skill通用性高几乎每天都会用到帮你快速建立原来还能这样的体感。等你熟悉了它们的结构再针对自己的业务写专用Skill就会顺手很多。6. 踩坑与清理我交过的学费和Tibo的清理思路6.1 安装后不生效常见原因和排查链路Skill不生效是最常见的坑我把它排在第一位。我遇到过的情况有四种目录放错位置。Claude Code不认~/.claude-skills它就认~/.claude/skillsOpenCode的路径又有自己的一套。解决方式很简单看工具的官方文档用ls看清楚你实际落在哪。名称冲突。如果你装了个superpower-writing而系统里有个同名内置skill很可能内置的优先。SKILL.md格式错误。YAML frontmatter写错比如description太长或者有非法字符Agent加载时会跳过。作用域不对。有些skill只在全局生效有些只在项目目录生效。你在项目A装的全局skill突然不生效了大概率是因为全局路径被项目里的本地目录覆盖了。排查链路我一般这样走先看工具日志/verbose输出确认skill有没有被加载再用一个明确匹配的任务触发它最后逐步检查路径、命名、YAML格式。不要一上来就改代码急大概率会误判。6.2 Skill之间的冲突命名污染和上下文风暴Skill装多了以后第二个坑出现冲突。最典型的是多个Skill都抢同一个语义场景。比如我同时装了A代码审查、BPython代码优化当我让它审查一段Python代码时两个Skill都可能被触发Agent一会儿用A的模板一会儿用B的规则输出格式完全混乱。更隐蔽的问题是上下文风暴。每个Skill在触发时都会把SKILL.md的内容灌进上下文。如果你一次装了几十个skill即使当前任务只用到两个Agent也可能因为描述相似而尝试加载其他一堆。上下文一撑爆模型注意力就会下降回答质量肉眼可见地滑坡。我的建议保持少而精。一个工具里同时启用五六个高频skill就够其他放进去但不启用按需手动激活。很多框架支持在SKILL.md里声明仅当用户明确提到关键词时才加载这种开关能有效减少误触发。6.3 清理Skills的实操参考Tibo的清理思路社区里Tibo分享过一套清理skills的思路我实践下来的感受是很实用。他的核心观点是Skills不是越多越好而是应该像包一样做定期整理。具体可以分四步第一步盘点。列出所有已安装的skill按最近30天是否使用过做一次筛选长期没用过的直接进回收站。第二步区分依赖型和独立型。有些skill会依赖另一个skill的脚本如果你删了依赖引用它的skill也会坏。清理前先用grep搜索一下引用关系。第三步检查体积。一个超大的skill集可能有几十MB拖慢启动速度。用du -sh看每个skill目录的实际大小把大户挑出来看是否保留。第四步建立版本锚点。删之前把你正在用的SKILL.md复制到备份目录或者直接用git提交一次万一删后悔了能快速恢复。Tibo还特别强调了一件事——清理不是目的知道自己为什么留才是。每一个留下来的skill都应该能回答它在上个季度解决了我的哪个问题这个问题。用这个标准筛一遍你会惊讶地发现有一大半是可以扔的。6.4 版本管理GitOps式的Skills运维Skills本质上是一堆文本加脚本天然适合放进Git仓库。我现在把自己的~/.claude/skills直接做成一个Git仓库每次新装或改动都提交一次。这样做的好处是我能回到任意时间点看自己的skill演化轨迹出问题直接git checkout回上一个commit。这个习惯救了我不止一次。另外如果你给团队搭建共享skill库建议遵循GitOps思路把skill放在一个单独的仓库里用PR流程做变更评审。因为SKILL.md里的每一句话都可能影响Agent行为Review的价值很高。我见过一个团队因为有人改错一个unless为if导致自动修复脚本在特定条件下跑出反向结果。这种问题光靠肉眼测试很难发现但代码评审可以兜底。7. Skills生态一览值得收藏的源站和仓库7.1 第一梯队官方风格仓库和高质量合集先推荐几个我反复访问的源站。第一梯队是typesafe/ai-samples这个仓库它是TypeSafe团队维护的一组AI示例里面有比较规范的skills结构很适合当作怎么写skill的参考。它的优势在于代码质量和配套文档都很在线不像有些仓库只放了一堆SKILL.md没有脚本。紧跟着是awesome-skills系列社区有一堆人维护awesome-claude-skillsawesome-codex-skills把分散在GitHub上的skill仓库按类别整理出来省去全网搜索的时间。我装新skill前会先在这类聚合页里看一下有没有同类、别人怎么评价。7.2 社区聚合入口OpenCode市场、导航站和Github TopicOpenCode有自己的registry可以当作一个类似npm的自动化安装源。它最大的好处是命令是标准化的你只需要写版本号不用手动处理目录。缺点是覆盖的skill远不如GitHub全。此外用GitHub Topic检索也是好办法直接搜topic:claude-skills、topic:codex-skills出来的仓库通常比较垂直能发现冷门但好用的东西。我之前看到cola skills、codex nature skills这类小众合集就是通过这种方式找到的它们大多服务于某个特定社区或行业但思路经常能带来启发。7.3 如何判断一个Skill是否值得装质量评估清单最后分享我的一个装前五问可以帮你过滤掉大量劣质skill仓库最后更新时间是什么时候超过一年没更新的大概率不兼容新版本工具。SKILL.md里的步骤是否具体如果充满了分析数据生成报告这种大词执行效果大概率不可控。有没有配套脚本纯markdown的skill本质上就是一个提示词可以作为灵感但稳定性会差很多。依赖的运行时是否常见如果要求装一堆冷门工具我会犹豫很久。许可证是否清晰没有License的仓库即使再好也不建议直接在你商业项目里使用。按这套标准筛下来能留下的skill其实不多但每一个都能真正提升你的Agent使用体验。说到底Skills这种东西的威力不在数量而在你把多少专家经验精准地压缩进了一个目录。装多了、写杂了反而会淹没你真正需要的声音。我到现在还保持着定期翻GitHub、看新skill的习惯。每次看到有人把一个以前只能靠人肉完成的工作流拆解成一份漂亮的SKILL.md加几个简洁脚本都会觉得这个生态还在非常早期的高速增长期。如果你还没亲手装过任何一个skill我建议现在就动手——找一个最大的坑踩一遍你会有比我这篇更深刻的体感。