这几年在AI编程圈子里混你会发现一个特别明显的风向变化以前大家比拼的是谁的提示词写得长、写得好后来是拼谁的上下文塞得准、塞得全现在呢最新的话题已经变成了“skills”——也就是把一套完整的、可复用的技能包教给AI智能体让它像老员工一样按照你的工作方式干活。这个变化不是小打小闹它直接改变了我们和AI协作的模式。我这段时间把GitHub上热门的skills仓库翻了个遍也在Claude Code、Codex、Cursor这些主流工具里实测了十几套不同场景的skills包括前端开发、学术研究、数学建模甚至还有测试用例生成。这篇文章想把我的理解和踩坑经验完整写出来。不管你是刚听说“skills”这个概念的新手还是已经在用但经常遇到“AI不按套路走”的开发者这篇文章应该都能提供一点实在的参考。1. Skills到底是什么为什么一夜之间大家都在谈我记得第一次看到.claude/skills这个目录的时候第一反应是“这不就是个强化版的prompt文件夹吗”。但实际用了一段时间之后发现这个理解太浅了。Skills的本质是把“如何完成一类任务”的完整方法论打包成一个结构化的技能包里面既有指令、有步骤、有参考资料甚至有可执行的脚本或工具配置。它不是让你的AI“听懂一句话”而是让你的AI“上手就能干活”。1.1 从上下文工程到技能包一个自然演进的产物我们先把时间线拉出来看看。最早的时候大家玩的是“提示词工程”核心思路是写一个无敌详细的prompt把所有要求都塞进去。但这种做法有个致命问题上下文窗口是有限的你不可能永远堆内容而且每次开新会话之前写的一大堆规范就清零了重新粘贴又累又容易漏。后来有了“上下文工程”的概念比如Claude Code的CLAUDE.md、Codex的AGENTS.md你可以把项目的全局规范、技术栈偏好、常见约定写进去让AI每次启动时自动加载。这比复制粘贴进步了一大截但它偏向“静态背景知识”相当于给新同事发了一本员工手册。而Skills在这个基础上又往前走了一步。它不仅仅是“知识”更是“能力包”。一个设计良好的Skill会包含完整的工作流定义什么情况下触发、先做什么、后做什么、用哪些工具、遵循什么输出格式、有哪些禁忌。这已经不是“员工手册”了这是“老带新的传帮带”把一个熟练工处理某类任务的完整套路都沉淀了下来。我打个比方你就明白了。CLAUDE.md像是公司墙上贴的规章制度你什么时候想看都能看到但它不会主动帮你干活。而Skills更像是给AI装了“行业模板库”比如你给它一个“前端设计稿还原”的skill它拿到一张设计图就知道该先去提取颜色变量、再拆组件层级、然后匹配现有UI库的命名规范最后输出可运行的Tailwind代码。这一整套流程不需要你反复交代一次加载以后每次都能稳定执行。1.2 和普通提示词、MCP到底有什么区别这是新手最容易混淆的地方。我经常在社区里看到有人问“Skills跟MCPModel Context Protocol有什么区别跟普通的提示词又有什么不一样”这里我直接给一个对照关系你一看就明白了。维度普通提示词MCP工具Skills本质一次性指令外部工具/API的标准化接入层可复用的任务处理流程与方法论解决的问题让AI这一轮听懂让AI能连上外部数据和操作让AI按固定套路把一类活干好生命周期会话结束后消失常驻按需求调用按触发条件自动加载或手动指定依赖关系无Skills可以调用MCP工具可与MCP配合也可独立工作MCP解决的是“连接”问题它把浏览器、数据库、文件系统、设计工具等等外部能力暴露给AI让AI能“动手”。Skills解决的是“方法”问题它告诉AI“你拿到这些工具之后应该按什么顺序、用什么方式去完成任务”。两者完全不冲突而且经常组合使用。举个例子你做一个“网页查资料并整理摘要”的skill里面可以定义先通过MCP的搜索工具检索信息再根据skill内置的摘要模板输出结构化结果最后把来源链接按固定格式附上。这里MCP负责“搜得到”Skills负责“整理得专业”。没有MCP的话AI就是个光说不练的秀才没有Skills的话MCP工具给AI了它也是一通乱用效率上不去。1.3 为什么正好是现在这个节点爆发任何技术概念的走红背后一定有工具生态和社区内容共同助推。Skills能在这几个月突然成为高频热词我认为有三个关键推手。第一个是Anthropic率先在Claude Code里推出了官方原生的Skills机制。它允许你把SKILL.md文件放到指定目录然后AI会扫描并自动学习这些技能的定义和能力边界。这个官方背书起到了很大的示范效应让大量开发者开始尝试。第二个是吴恩达Andrew Ng专门出了一期关于Agent Skills的教程他在课程里把一个复杂的Agent任务拆解成多个可复用的“技能单元”强调通过结构化技能的组合来构建稳定可靠的AI应用。这个教程影响面非常大让很多原本只做传统机器学习的人也开始关注Skills。第三个是社区的快速跟进。GitHub上像baoyu skills这类的中文Skills集合仓库、mattpococks skills这类英文精品合集以及各种数学建模、渗透测试、前端开发的垂直领域Skills仓库如雨后春笋般冒出来。工具方搭好了台子社区负责唱戏内容一多这个生态自然就热起来了。2. 主流工具对Skills的支持现状与选型建议既然是实操向的文章光聊概念肯定不行。我直接把市面上大家问得最多的几款工具——Claude Code、Codex、Cursor、OpenCode——对Skills的支持情况挨个拉一遍重点说清楚它们的目录格式和配置方式有什么差异。2.1 各家实现方式速览目录结构、格式与加载逻辑先说Claude Code。它原生支持Skills官方推荐的做法是在项目的.claude/skills/目录下创建以技能名命名的子文件夹每个文件夹里放一个SKILL.md文件还可以附上scripts/、references/等辅助资源。Claude Code启动时会递归扫描这些目录读取技能的描述和触发条件。SKILL.md的开头部分一般用YAML frontmatter写元数据比如name、description正文部分写详细的工作流程。下面是一个标准的Claude Code Skill目录结构.claude/ └── skills/ └── frontend-design-restore/ ├── SKILL.md ├── scripts/ │ └── extract-colors.py └── references/ ├── tailwind-guide.md └── ui-patterns.md然后是Codex也就是OpenAI家的编程智能体。Codex对Skills的接入方式与Claude Code略有不同它更依赖AGENTS.md这个全局说明文件同时也能识别skills目录。在Codex里你可以在项目根目录建一个skills/文件夹然后在AGENTS.md里显式声明这些技能的存在和用途。这样做的好处是AI在任务开始阶段就会感知到“项目里有全套可用的技能”并且会主动评估是否需要调用。再来看Cursor。Cursor本质上是一个AI代码编辑器它对Skills的支持主要体现在.cursor/rules/目录这个目录里的.mdc文件扮演了类似SKILL.md的角色。虽然名字不一样但核心思想相通给AI预设一份高优先级的指导文件让它处理代码时遵循里面的规范。需要注意的是Cursor的规则文件更多是“约束性”的写法上比较像一套强制执行的编码规范不像Claude Code的Skills那样强调完整的流程编排和资源文件配套。最后是OpenCode。这是一个终端版的AI编程工具它同样支持Skills而且实现得比较简洁。OpenCode会在启动时读取~/.config/opencode/skills/或者项目内的.opencode/skills/目录加载里面的技能定义。它的优势是跨平台、轻量适合喜欢纯终端操作的人。如果你平时用Neovim这类编辑器比较多OpenCode的Skills体验会比Claude Code更顺手一点。我把它们的核心差异整理成了一张表格方便你按需选择工具技能目录位置核心配置文件加载方式优势Claude Code.claude/skills/SKILL.md启动扫描自动读取生态成熟、社区案例多、原生内置Codexskills/AGENTS.md skills目录通过AGENTS.md显式声明与OpenAI工具链结合紧适合深度AI逻辑Cursor.cursor/rules/.mdc规则文件编辑器自动加载与IDE集成好编码时即时生效OpenCode.opencode/skills/自定义配置终端启动加载轻量、跨平台、适合终端流2.2 一个前端开发者的真实选型建议我自己平时主力工作流是前端开发加AI辅助所以对“到底该选哪个工具玩Skills”这个问题有点发言权。我的建议分几种情况。如果你主要用Claude Code作为AI结对编程工具那就直接用它的原生Skills机制完全不需要额外折腾。目前GitHub上质量最高的Skills集合基本都是围绕Claude Code格式写的你用其他工具还需要转换格式而Claude Code是开箱即用。如果你同时使用多个AI编程工具比如既用Claude Code又用Codex我建议你以AGENTS.md作为“索引层”在文件里统一声明你有哪些技能然后不同工具通过自己的规则文件去加载对应实现。这个思路和代码架构里的“面向接口编程”一个道理——上层统一暴露能力清单下层各自实现。如果你只是想快速体验不太想折腾命令行工具那Cursor是最低门槛的方案。它毕竟是图形界面配置规则之后可视化反馈很清楚适合从传统IDE迁移过来的开发者。2.3 社区里已经有哪些现成的Skills值得收藏这个我实测过一些给大家报几个靠谱的“菜名”。前端开发方向最火的就是“图片还原设计稿”。这类Skill一般会告诉AI拿到设计稿图片后先分析整体布局和色板再根据项目已有的组件库拆解页面结构最后输出Tailwind或CSS Modules代码。我用过之后最大的感受是AI生成的还原度比裸奔状态下高非常多至少省掉了我30%的调整时间。学术研究方向academic research skills这类仓库做得比较系统。它通常包含文献检索、论文结构分析、引用格式整理等多个子技能而且每个子技能都带参考文件和步骤模板。对于研究生或者科研狗来说这东西比自己去写长篇大论的提示词实用多了因为学术写作的规范太多太细交给设计好的Skill去执行出错的概率低很多。数学建模方向也有不少好东西。热词里多次出现“数学建模skills推荐”不是偶然因为数学建模涉及问题分析、模型假设、公式推导、代码实现、论文撰写等多个环节每个环节的套路都很固定非常适合做成Skills。有的仓库甚至把美赛、国赛的获奖论文结构都总结进了Skill让AI辅助生成初稿时自动往“评委喜欢看的样子”靠拢。测试用例设计方向的Skills也值得关注。好的测试Skill会把需求拆解成功能点列表再按等价类、边界值、场景法等不同方法生成测试用例表最后还能自动输出可执行的测试脚本框架。这类Skill对做质量保障的团队特别友好能显著提升用例覆盖率减少漏测。还有安全测试方向确实有人在整理渗透测试相关的Skills主要是信息收集、资产梳理、报告模板这些授权范围内的测试辅助内容。我一直强调一个原则安全测试工具和技能只能在获得授权的环境中使用任何未经许可的测试行为都是不合规的。这里提一下就够了具体内容不展开。3. 动手开发自己的第一个Skills从需求拆解到可用交付看了这么多现成的Skills估计你也手痒了。这一章我拿一个我踩过不少坑的真实案例来演示怎么从零到一开发一个能用的Skills。这个案例就是“前端设计稿还原”因为它足够典型——有输入、有输出、有中间步骤、有工具依赖而且几乎每个前端开发者都经历过这个场景。3.1 先拆需求别一上来就写SKILL.md我第一次写Skill的时候犯过一个特别典型的错误打开编辑器就开始准备写SKILL.md的正文结果憋了半天写出一堆正确的废话。后来我发现正确的姿势是先做需求拆解。设计一个Skill之前你必须回答四个问题。第一这个Skill在什么时候被触发触发条件越明确AI的加载准确率就越高。比如“设计稿还原”这个Skill触发条件应该定义为用户上传了一张图片或设计稿文件同时期望生成对应的前端页面代码。第二这个Skill包含哪些工作流步骤这里要把一个大任务拆成顺序清晰的小步骤。拿设计稿还原来说我会拆成五步分析设计稿风格和布局、提取主题色与字体变量、对照项目技术栈确定组件方案、逐区块生成代码、自查和修正样式。第三这个Skill需要哪些参考资料或背景知识比如你的项目用的是Tailwind还是Ant Design组件的命名习惯是什么是否有统一的工具函数库。这些都应该作为参考资料放在Skill目录里而不是写在正文里让AI去猜。第四Skill的最终输出应该长什么样是完整的代码文件还是带说明文档的代码片段是直接可以运行的还是需要人工再润色一步这个界定了质量标准AI才知道自己在什么时候算“干完了”。这四个问题想清楚之后你脑海里的Skill其实已经成型了一大半写SKILL.md就变成了一件很顺手的记录工作。3.2 SKILL.md怎么写才不废话SKILL.md是这个技能包的“说明书”它的作用是让AI在最短时间内理解你的意图所以最忌讳的就是长篇大论、废话连篇。你要把它当成给一个聪明但没经验的实习生写的操作手册而不是学术论文。按照Claude Code的规范SKILL.md开头是一个YAML格式的frontmatter里面主要是name和description两个字段。需要注意description字段非常重要AI就是靠它来判断该不该加载你这个Skill的。你必须在description里写清楚你的Skill“在什么场景下、解决什么问题”不要泛泛地说“帮助用户写好代码”那跟没说一样。你要写类似“当用户需要将设计图转换为高保真前端代码时使用此技能支持从图片中提取色板、布局、字体并生成响应式页面”这样就具体得多。正文部分我习惯用自己的模板结构固定实测下来效果很好--- name: frontend-design-restore description: 将设计稿图片还原为高保真前端页面的技能。适用于用户提供截图、Figma导出图或设计稿单页时的页面开发场景。支持分析布局、提取主题变量、生成响应式代码。 --- # 将设计稿还原为前端页面 ## 适用场景 - 用户提供设计稿图期望得到可直接运行的页面代码 - 用户希望新页面与现有项目的组件规范和主题风格保持一致 ## 工作流程 1. **分析设计稿**识别页面整体布局、区块层次、间距体系与视觉风格。 2. **提取主题变量**从设计稿中提取主色、辅助色、字体、圆角、阴影形成Tailwind或CSS变量配置。 3. **确定技术方案**根据项目的现有技术栈React/Vue/Tailwind等选择组件实现方式。 4. **逐区块生成代码**从上到下依次实现导航、主体内容、侧边栏、页脚等模块。 5. **响应式与细节修正**检查断点适配、交互态样式和无障碍处理。 ## 输出要求 - 返回可直接打开运行的完整页面代码 - 代码中注释标明关键设计决策 - 标明哪些变量是从原设计稿自动提取的 ## 参考文件 - 读取 references/theme-tokens.md 获取本项目主题变量命名规范 - 读取 references/component-patterns.md 获取常用组件的实现模式 ## 工作流原则 - 不做过度设计忠实还原设计稿不擅自添加装饰元素 - 用上下留白和间距控制层级避免用大量绝对定位 - 遇到设计稿未覆盖的交互状态时使用项目中已有模式并显式说明这个模板的核心理念是“给了AI明确的出口与边界”适用场景防止误用工作流程防止遗漏步骤输出要求保证交付质量参考文件让它去读配套资料而不是瞎猜。3.3 资源文件与参考资料的合理组织一个Skill如果只靠一个SKILL.md撑场面那它功能再强也有限。真正好用的Skill往往都配套了丰富的资源文件。我自己常用的组织方式有两种references/放文档类参考资料scripts/放可执行的辅助脚本。references/目录适合放什么我前端项目的主题变量规范、常用UI组件的代码模式、项目的历史页面实现示例这些能显著提高AI生成代码的命中率。比如我会把一个已经上线页面的组件写法作为“优质范例”放进references然后在SKILL.md里写明“生成新页面时参考该范例的代码风格”。这样AI输出的代码就不是凭空想出来的而是贴着项目真实标准来写的一致性会好很多。scripts/目录则可以用来放一些自动化工具。比如你可以写一个Python脚本自动读取设计稿图片里的颜色信息并生成颜色变量文件。技能加载时AI可以先执行脚本处理输入再基于处理结果生成代码。这种“工具流程”的组合才真正把Skills用出了“多智能体系统”的味道。需要注意一个细节资源文件不要塞太大。我之前见过有人把一个几MB的设计规范PDF塞进references里结果AI每次加载技能都吃几十万的token对话没几轮就撞上上下文上限了。正确做法是提取精简要点写进Markdown或者用脚本按需读取原始大文件而不是让AI把所有参考资料一次性载入。3.4 实测用一个能跑的Skills案例走一遍光说不练假把式。这里我放一个真实的“前端设计稿还原”Skill落地后的调用过程你可以直观感受一下一个设计良好的Skill是怎么被AI执行的。# 先创建一个技能目录 mkdir -p .claude/skills/frontend-design-restore/references mkdir -p .claude/skills/frontend-design-restore/scripts # 把主题变量规范放进去 cat .claude/skills/frontend-design-restore/references/theme-tokens.md EOF # 项目主题变量规范 - 主色#2563EB业务蓝 - 辅助色#F59E0B警示黄 - 字体Inter, system-ui, sans-serif - 圆角8px 基础圆角16px 卡片圆角 - 阴影0 1px 2px rgba(0,0,0,0.05) EOF # 把组件模式示例放进去 cat .claude/skills/frontend-design-restore/references/component-patterns.md EOF # 按钮组件实现模式 采用 React Tailwind 方式核心类名组合为 inline-flex items-center justify-center rounded-md bg-blue-600 px-4 py-2 text-sm font-medium text-white hover:bg-blue-500 EOF然后你在实际干活时直接把设计稿截图拖进对话或者粘贴图片路径接着告诉Claude Code一条极简的指令“用frontend-design-restore这个技能把这张图还原成页面”。我实测下来AI会经历以下过程先扫描SKILL.md得知整个流程然后读取references里的主题变量与组件规范接着调用文件系统工具读取设计稿图片逐区块生成代码。如果生成的代码里某些间距和设计稿不一致它会自己走到“响应式与细节修正”这一步去修订。整个过程基本不用我再塞背景知识最多就是最后我手调一下细节这套流程跑得非常顺。4. Skills与MCP的联动以及常见问题排查实录Skills真正威力爆发是在它跟MCP工具串联起来的时候。而且越用深入你越会发现Skill调试其实是一门“手工活”很多问题只要你知道原因十分钟就能解决。4.1 Skills如何调用MCP工具配置与实战先说场景。你希望“网页查资料”这个Skill能通过MCP检索实时数据而不是每次都让AI叹气说知识截止日期。这就要在Skill里显式声明对MCP工具的依赖。在Claude Code环境里MCP server通常保存在.mcp.json或项目配置中。你的Skill要做的事就是告诉AI“这个任务需要调用哪些工具”并把调用方式写明白。我习惯在SKILL.md里加一段“工具依赖”区域例如--- name: web-research-summary description: 基于实时网页搜索和内容抓取输出结构化研究报告的技能。适用于需要最新资料或数据支撑的场景。 --- ## 工具依赖 - 使用 web_search 进行关键词搜索获取候选页面列表 - 使用 web_fetch 抓取目标页面的正文内容 - 使用 content_extract 提取页面的核心观点与关键数据核心思路是Skill负责定目标MCP负责干执行。你不需要在Skill里写“具体怎么搜索”这种琐碎指令因为MCP工具已经实现了搜索逻辑。你只需要告诉AI“什么情况下用哪个工具、用完之后怎么处理结果”。Codex那边的玩法也类似但由于Codex对AGENTS.md的依赖更强我一般会在AGENTS.md里先声明“该项目启用了web-research-summary技能涉及最新资料查询时请调用此技能”然后在skills目录里放相应实现。Cursor中对MCP的配置更直观你在设置页面加好MCP server然后规则文件里引用工具名即可。需要提醒的是不要让Skill每次执行时都强行调用MCP工具。有些操作明显不需要实时数据比如“生成一个静态HTML邮件模板”你如果还在Skill里绑定一个搜索工具反而会拖慢响应、引入噪音。所以设计Skills和MCP联动时一个很重要的原则是按需接入而不是能接尽接。4.2 开发调试Skills的日常踩过的坑与习惯养成Skills开发过程中的坑我基本都踩过一遍这里挑几个最典型的说说。第一个坑是description写得过于抽象导致AI压根不触发这个Skill。我一开始写过“协助用户高效完成前端页面开发”这种描述结果AI在99%的情况下根本想不起还有这个技能存在整个Skill形同虚设。后来我改成“当用户提供设计稿截图时使用输出符合项目Tailwind主题规范的高保真页面代码”之后触发率一下子涨上来了。核心原因就是AI在判断“该不该用技能”时靠的是description与当前任务的语义匹配度匹配度不够自然就失灵。第二个坑是参考文件路径写错。Skill里如果你写了“请参考references/xxx.md”这个路径的基准目录是有讲究的。有些AI理解的是相对项目根目录有些理解的是相对SKILL.md所在目录。如果你写的路径和AI的理解不一致它就会跟你要一个不存在的文件或者自己编一套规范出来。我的习惯是在SKILL.md开头就用绝对路径或从项目根目录开始的相对路径写清楚避免歧义这样调试起来省很多功夫。第三个坑是上下文塞太多导致模型“东施效颦”。同一个Skill里如果放了太多互相冲突的参考资料AI反而会不知道该听谁的。比如你在references里既放了一套“简洁风格”的页面范例又放了一套“信息密度高”的页面范例那AI生成出来的东西大概率会四不像。现在我维护资源文件的原则是宁缺毋滥每个参考文件必须有明确的使用场景并且在主文档里说清楚什么时候该参考哪一份。4.3 社区高频问题速查表最后做个收尾把Skill开发和使用中最常见的问题整理成一个速查表方便你遇到问题时直接对号入座。常见问题可能原因解决办法AI完全不使用Skilldescription描述太模糊与任务关联度低在description中写清楚触发场景、目标和典型输入Skill时灵时不灵触发条件与用户指令大相径庭调整SKILL.md中的适用场景让示例覆盖更多表达方式输出代码风格不统一references参考资料冲突或缺失精简资源文件只保留高质量、风格一致的范例每次执行顺序都乱工作流列表写得不明确用有序编号把步骤拆细并从“最重要的第一步”写起Skill调用MCP失败工具未在配置中启用或名称不符检查MCP server状态确认工具名称和Skill里的引用一致上下文占用过高参考文件太大、加载内容过多精简Markdown参考必要时用脚本按需读取大文件AI生硬套用Skill模板输出要求不具体在输出要求中明确交付物的结构和质量验收标准我在实际使用中的体会是Skills到了一定规模之后真正的门槛不在“怎么写单条技能”而在“怎么让整个技能库互相配合不打架”。你可以建立一套“索引Skill”它不负责具体任务只负责把其他Skill按场景分类并说明各自的边界这样AI在每次开局时就能快速定位到合适的技能。这就像给团队立项目录每个新需求进来先查目录再找人而不是把所有人都问一遍。如果你也在折腾Skills欢迎沿着我上面的思路去迭代。先挑一个你自己日常重复度高的场景按“拆需求—写模板—配资源—接MCP—调试触发率”这个节奏走一遍大概率能做出第一个有实际生产力的Skill。等跑通了第一个后面做就会快很多。