1. Skills 到底是什么为什么突然就火了最近 AI 编程圈子里skills这个概念几乎刷屏了。从 GitHub 上的 Trending 仓库到 X 上技术博主们的讨论再到吴恩达专门出了一套 Agent Skills 的教程 PDF到处都是它的影子。我刚开始看到这个词的时候也有点懵因为skills直译过来就是技能听起来平平无奇但真正用起来才发现这玩意儿确实是把 AI 工具从聊天机器人变成专业助手的关键一步。先说结论Skills 是一套标准化的指令封装机制它把某个领域的最佳实践、工作流程、约束条件和验收标准打包成一个结构化的文件通常是 Markdown让 AI 工具在执行相关任务时自动加载并遵循。简单来说你不需要每次跟 AI 对话时都把一长串需求背景、技术约束、输出格式重新啰嗦一遍Skills 把这套上下文固化下来一个命令就能让 AI 进入专业模式。它解决了什么问题呢举个很实际的例子。我经常用 Claude Code 写前端页面以前每次对话都要花时间描述请按照 Vue 3 TypeScript Tailwind 的技术栈注意组件拆分样式用 CSS Modules输出要包含测试用例这些要求。有了 Skills 之后我把这些要求写成一个前端开发 Skill 文件AI 会自动感知当前任务是否匹配匹配了就自动加载完全不用我重复操作。这个能力听起来不复杂但对日常效率的提升是质变级别的。而且它不只是给 Claude Code 用的目前主流的 AI 编程工具——Codex、Cursor、OpenCode、GitHub Copilot 都有了自己的 Skills 支持社区里甚至出现了专门做 Skills 分享的仓库比如 baoyu skills、mattpococks skills还有各种数学建模 skills“渗透测试 skills”“测试用例 skills”等垂直领域的合集。这篇文章我会从几个层面来拆解 Skills它是怎么设计的、在不同工具里怎么用、如何从零开发一个自己的 Skill、以及实操中常见的坑。不管你是前端、后端、测试还是搞数据分析的只要你在用 AI 辅助写代码这玩意儿都值得花半小时了解一下。2. Skills 的设计思路与核心原理2.1 从 Prompt 到 Skills 的进化逻辑要理解 Skills 的价值得先回到 Prompt 这个老话题。过去我们使用 AI 编程工具本质上是在做一次性指令——你写一段 PromptAI 根据上下文生成回答。这个模式最大的问题在于上下文是临时的、脆弱的。一旦开启新会话所有约定都得重新建立一旦任务变得复杂Prompt 越长AI 越容易忘掉中间的关键要求。Skills 的进化逻辑就是把临时的 Prompt变成持久化的职业技能。它借鉴的是人类社会的分工模式一个前端工程师不需要每次写代码前都背诵一遍 HTML 标签和 CSS 属性的含义这些是内化的技能同样一个 Skill 文件就是 AI 的内化技能告诉它在什么场景下应该遵循什么规则。从技术实现角度看Skills 的核心由三部分组成触发器Trigger描述这个 Skill 适用于什么场景AI 根据用户输入自动判断是否激活。指令体Instructions详细描述执行流程、技术约束、编码规范、输出要求。参考资源References示例代码、常见问题、目录结构规范等辅助材料。这三者组合在一起形成一套完整的工作流说明书。AI 工具会在每次对话开始时读取所有可用的 Skill 描述如果当前用户消息匹配某个 Skill 的触发器就把整个 Skill 文件加载进上下文相当于给你这个会话附了身。2.2 Skills 与 MCP 的关系很多人的理解是错的聊到 Skills 就绕不开 MCPModel Context Protocol模型上下文协议但很多人都把两者的关系搞混了。我见过不少新手问skills 如何调用 mcp 工具这个问题的表述其实就暴露了一个认知误区。MCP 解决的是AI 如何连接外部工具和数据源的问题它是一套通信协议——AI 可以调用 MCP 服务器上注册的工具请求外部数据、触发外部操作。而 Skills 解决的是AI 应该怎么干活的问题它是一套规则约束——定义了 AI 在特定场景下的行为方式和执行标准。两者的关系更像是规则和工具的关系。举个例子我开发了一个网页信息抓取的 Skill在这个 Skill 的指令文件里明确写了当需要获取实时网页内容时调用 fetch_webpage 工具这是一个 MCP 工具当需要搜索时调用 web_search 工具。也就是说Skills 本身不直接连接外部世界但它会告诉 AI你应该用哪些 MCP 工具、按什么顺序用、拿到结果后怎么处理。在实际使用中Skill 文件可以通过tools字段声明它依赖的 MCP 工具AI 在执行任务时会自动调用。Claude Code 里甚至可以直接在 SKILL.md 的 frontmatter 中绑定特定工具的调用权限。理解了这层关系再去搜skills 如何调用 mcp 工具怎么搜都搜不明白的问题基本就通了。2.3 Skills 的文件结构与标准格式目前最主流的 Skills 格式是 Anthropic 提出的 Agent Skills 规范社区里不少项目包括 opencode skills、mattpococks skills也基本遵循这个规范。一个标准 Skill 的目录结构长这样my-skill/ ├── SKILL.md # 主指令文件必需 ├── assets/ # 辅助资源目录可选 │ ├── examples/ # 示例代码 │ └── references/ # 参考文档 └── scripts/ # 辅助脚本可选 └── helper.py # Python 脚本其中SKILL.md是核心文件开头有一个 YAML frontmatter用来声明元信息--- name: frontend-dev description: 前端页面开发与还原适用于 Vue/React 项目包括组件设计、样式实现和响应式适配。 when_to_use: 当用户要求生成或修改前端页面、还原设计稿、优化 UI 组件时使用。 version: 1.0.0 dependencies: [web_searchmcp, image_analyzemcp] ---下面就是正文部分要求用 Markdown 编写内容通常包含执行步骤、编码规范、注意事项、验收标准等。这一段是精髓所在写得越贴近实际项目的真实逻辑AI 表现越好。3. 主流程具现手把手开发一个自己的 Skill3.1 先找准场景明确边界很多新手开发 Skills 容易犯的第一个错误就是太贪心想一个 Skill 把前端开发、后端开发、数据分析全部覆盖。这种全功能型 Skill最后往往变成一个什么都能聊但什么都不精的废话合集AI 加载它之后反而更难干活。我的建议是——从一个你反复做过、且规则清晰的场景切入。我自己开发的第一个 Skill 是图片还原设计稿灵感就来自热搜词里的图片还原设计稿给前端开发 好用的 skills。这个场景非常典型手动还原设计稿是前端开发的重复劳动规则相对明确识别布局、提取颜色、匹配字体、实现响应式而且 AI 提升空间大。明确场景之后要梳理清楚这个 Skill 的边界。比如我的图片还原 Skill只在用户提供设计稿图片并要求生成前端页面时才会触发它不负责后端接口联调也不负责处理复杂动画。边界清晰AI 才不会在使用时产生歧义。3.2 编写 SKILL.md 的实操模板与细节写 SKILL.md 其实有点像写一份给新同事看的接手手册但要更精炼、更结构化。我通常按照下面这个框架来写--- name: image-to-frontend description: 根据设计稿图片还原前端页面输出 Vue 3 TS Tailwind 组件。 when_to_use: 用户提供设计稿截图或图片要求生成或还原前端页面时使用。 version: 1.1.0 dependencies: [image_analyzemcp] --- ## 职责范围 - 将设计稿图片转换为可运行的前端页面代码 - 技术栈固定为 Vue 3 TypeScript Tailwind CSS - 输出包含组件代码、样式文件和简要说明 ## 执行流程 1. 使用 image_analyze 工具分析设计稿提取以下信息 - 页面整体布局结构与区块划分 - 颜色主题主色、辅色、hover 状态色 - 字体类型与字号层级 - 间距规律内边距、外边距 2. 根据提取结果生成 Vue 组件代码 3. 使用 Tailwind 类名实现样式避免自定义 CSS 覆盖 4. 输出代码前检查移动端适配是否符合规范 ## 编码规范 - 组件文件使用 script setup 语法 - 所有字符串使用单引号 - 样式优先使用 Tailwind 原子类 - hover 状态必须在组件中明确处理 - 禁止使用图片替代文字内容 ## 验收标准 - 页面在 375px 和 1440px 宽度下均无横向溢出 - 颜色值与设计稿偏差不超过 5% - 组件无 console 报错 - 所有交互元素具备可访问性属性注意几个关键点description要写清楚适用场景这是 AI 判断是否触发 Skill 的依据执行流程要具体到用什么工具→拿什么信息→怎么处理→输出什么每一步都要有明确指令验收标准是很多新手容易忽略的但它恰恰决定了 AI 输出的质量底线。3.3 辅助脚本与资源文件的搭配对于复杂场景SKILL.md 里没法装下所有逻辑这时候就需要辅助脚本和参考资源。我最常用的是scripts/目录下放一些 Python 或 Node.js 脚本用来做 AI 本身不太擅长的事情——比如批量处理数据、生成目录结构、调用特定 API 等。以数学建模 skills 为例社区里比较成熟的做法是SKILL.md 负责定义分析思路问题拆解、模型选择、验证方法scripts 目录放数据预处理脚本和模型评估脚本assets 目录放经典论文的代码示例。这样 AI 在运行时可以调用脚本完成数值计算而不是自己凭空编结果。参考资源部分我建议放 1-2 个高质量示例而不是堆砌一堆可能有用的材料。AI 的上下文窗口是有限的塞太多内容反而会稀释真正重要的信息。我自己的经验是一个 Skill 的总内容控制在 3000 字以内脚本控制在 200 行以内这是一个比较舒服的平衡点。3.4 测试与迭代的完整闭环Skill 开发完成只是第一步测试和迭代才是真正决定好坏的关键环节。我会从三个维度测试第一是触发测试。用各种相关的、不相关的输入去试看 Skill 会不会被正确触发。最常见的坑是 description 写得太泛导致无关任务也触发 Skill或者太窄真正的任务反而不触发。第二是行为测试。给 AI 一个具体任务比如把这张设计稿还原成页面观察它是否按照 SKILL.md 里定义的流程执行有没有跳步骤、有没有偏离编码规范。第三是输出质量测试。连续让 AI 产出 5-10 个结果逐个检查质量是否稳定。如果发现有些输出明显不合格就去排查是流程定义不清楚还是规范描述不完整。每次测试后发现的问题都直接修订 SKILL.md这样一来一回迭代几轮之后Skill 才会真正达到值得分享的质量水平。4. 主流工具下 Skills 的实际使用路径4.1 Claude Code 中的 Skills 配置与调用Claude Code 是目前对 Skills 支持最完整的工具之一Anthropic 官方文档里有一整套关于 Agent Skills 的说明。我日常的使用路径是这样的首先在项目目录下建一个.claude/skills/文件夹把你的 Skill 目录放进去my-project/ └── .claude/ └── skills/ └── frontend-dev/ ├── SKILL.md └── assets/ └── example.vue装好之后Claude Code 启动时会自动扫描这个目录读取所有 SKILL.md 的 frontmatter。当你的对话内容匹配到某个 Skill 的when_to_use或description时它就会自动加载并应用这个 Skill。有一个技巧你可以在对话中显式指定使用某个 Skill比如输入frontend-dev 帮我处理这个设计稿这样即使自动匹配没触发你也可以强制执行。这在测试 Skill 是否编写正确时非常好用。4.2 Codex、Cursor 和 OpenCode 的差异性对比除了 Claude CodeCodexOpenAI 的 CLI 工具、Cursor 和 OpenCode 也在快速跟进 Skills 生态。我几个工具都试过简单说下感受Codex 的 Skills 机制跟 Claude Code 类似也是在项目文件夹里配置AGENTS.md但它的规则粒度更偏向项目级规范而不是场景级技能。你可以理解为——Claude Code 的 Skills 是按任务类型切分的技能包Codex 的 AGENTS.md 更像是整个项目的长期记忆。Cursor 作为 IDE 形态的 AI 编程工具它的 Skills 更偏向于人机交互工作流。你可以把常用的开发流程比如新建组件时自动生成测试文件代码提交前自动检查 lint固化成 Cursor 的 Rules 和 Commands本质上也属于 Skills 的变体。OpenCode 是一个新兴的开源工具它的 Skills 机制直接借鉴了 Claude 的规范而且社区版本迭代很快。如果你喜欢折腾opencode skills 这个仓库值得关注里面有不少精品 Skill 可以参考。4.3 搜索到的热门 Skills 推荐与分析顺着热搜词整理一下目前社区里比较受关注的 Skills 有这几类覆盖网页查询能力的 Skills 基本是刚需比如claude code 网页查资料的 skills——它本质上是把 web_search MCP 工具链封装成一个 Skill规定了搜索策略、信息提取规则和回答格式非常适合需要实时资讯支撑的场景。测试用例 skills和渗透测试 skills这两类在安全圈和测试圈很火。测试用例类的 Skill 会把等价类划分、边界值分析、场景法这些测试设计方法固化下来让 AI 按照工程化标准生成测试用例。渗透测试相关的 Skill 则更注重流程合规——先信息收集、再漏洞分析、最后输出报告每一步都定义了严格的边界约束这个场景下更需要自行注意合规边界这里不展开。数学建模 skills是大学生群体中的热门这类 Skill 通常集成了数据处理、模型选择回归、分类、优化、灵敏度分析等完整链路在数学建模竞赛场景下特别实用。github 上不少开源库都做了数学建模 skills 推荐合集覆盖了从选题到论文排版的全流程。4.4 如何获取、安装和验证第三方 Skills获取 Skills 的渠道主要有两条一是直接用 git clone 社区仓库里的 Skills 到本地目录二是自己造。我强烈建议新手先拿社区现成的练练手熟悉结构之后再自己动手。安装的步骤其实很简单克隆仓库到本地比如git clone https://github.com/xxx/awesome-skills.git。把需要的 Skill 目录复制到你项目对应的skills文件夹中。重启你的 AI 工具如果是 Claude Code 需要重启会话Cursor 可能需要刷新。用一句话描述相关任务测试能否正常触发。验证 Skill 是否生效有个小技巧直接问 AI你有哪些可用的 skills它会列出已经加载的 Skill 清单。如果没看到你刚装的 Skill优先检查文件路径和 frontmatter 格式。5. Skills 开发中的常见问题与实战排查5.1 高频出错点速查表实战中遇到过不少问题我整理成一张速查表方便对照排查问题现象常见原因解决方案Skill 一直不触发description 或 when_to_use 写得太宽泛/太狭窄重新描述适用场景用实际任务语句测试触发Skill 被不相关任务触发trigger 条件描述存在歧义增加否定的边界描述如不适用于XX场景加载 Skill 后输出质量反而下降Skill 文件太长关键指令被稀释精简内容突出核心流程和验收标准AI 不按 Skill 里定义的流程执行流程描述过于抽象缺少可操作步骤把每一步拆到用XX工具→获取XX信息→做XX处理粒度Skill 调用 MCP 工具时报错依赖的工具未安装或权限未配置检查 MCP 服务器状态确认依赖声明正确多个 Skill 规则冲突不同 SKILL.md 对同一场景给出了矛盾指令为 Skill 设置更精确的触发条件避免重叠5.2 几个我自己踩过的坑第一个坑是过度编写。最早我写前端 Skill 时恨不得把整个公司的编码规范都塞进去结果 AI 的输出变得更加僵硬连变量名都要按固定前缀来。后来我意识到Skill 的核心是关键约束而不是完整手册。删掉那些非核心规则之后AI 的表现反而明显提升。第二个坑是忽视 MCP 工具调用权限。我做网页数据抓取 Skill 时在 SKILL.md 里写了很多调用 search 工具获取信息的指令但忘了检查 MCP 工具的实际配置情况结果 AI 在运行时根本找不到这个工具。后来我把所有依赖的工具都在dependencies字段里明确声明了并且在文档里写清楚如果工具不可用停止执行并说明原因问题就解决了。第三个坑是版本管理混乱。Skill 文件改过几轮之后你可能已经忘了第一版是什么样也说不清哪次改动导致了行为变化。我现在给每个 Skill 都维护了一个 version 字段并且把重要改动记录在 SKILL.md 底部这样每次发现问题都能快速回滚到可用版本。5.3 调试 Skills 时的高效工作流调试 Skill 我有一套固定的工作流效率很高先用一个极简测试用例验证核心流程比如一个图片还原 Skill 就准备一张最简单的单色卡片设计稿看 AI 输出是否靠谱。极简用例跑通之后再逐步增加复杂度——加一个带渐变背景的、加一个有多列布局的、加一个包含 hover 交互的。每次只改一个变量你才能准确判断哪里出了问题。然后是分步观察调试法。如果输出的结果不符合预期我会在对话中让 AI逐步输出当前的执行计划看看它是否理解 SKILL.md 中的指令以及在哪个环节发生了理解偏差。找到偏差后直接针对那一段描述进行修改而不是整个重写。最后是回归对比。修改完 Skill 后用同一组测试用例重新跑一遍对比输出质量。我会保留每次测试的输出截图或文本这样能直观看到每次修订带来的实际差异。这一步很多人图省事跳过了但长期来看它才是最省时间的手段。6. 从个人使用到团队协作的扩展6.1 构建属于自己的 Skills 工具箱用熟练之后我建议按自己的日常工作流构建一套Skills 工具箱而不是东拿一个西用一个人家做的。比如我的工具箱目前包含一个项目启动Skill负责初始化项目结构、配置基础依赖、一个前端页面开发Skill负责页面还原和组件编写、一个代码审查Skill负责按团队规范检查代码质量、一个API 接口联调Skill负责生成接口请求代码和 Mock 数据。每个 Skill 都围绕一个具体的、高重复度的任务场景来开发累积到 5-6 个的时候你会发现大部分日常开发任务都可以直接触发对应的 SkillAI 的输出质量和稳定性会有一个肉眼可见的提升。6.2 团队内共享 Skills 的注意问题团队协作场景下Skills 的价值更大但坑也更隐蔽。最常见的问题是——不同成员本地的 Skills 版本不一致导致同一任务在不同人电脑上跑出来的结果完全不同。建议用 Git 仓库统一管理团队 Skills纳入代码评审流程和普通代码一样做版本控制和变更记录。另一个容易被忽略的问题是隐私和权限。如果你开发的 Skill 里包含公司内部规范、接口地址或者敏感信息共享时要格外注意脱敏处理。我在给团队分享内部 Skill 时会把涉及内部系统的信息用占位符替换并在文档里标注使用前需替换为实际配置。7. 最后分享一点长期使用的体会Skills 这个概念看起来很简单但实际用下来它对工作流的影响是长期的。我最大的感受是——它把调教 AI的成本做了前置化和复用化。以前每次使用 AI 都是一次全新的调教过程现在调教一次、长期复用而且越用越好用。但也别把它想得太神秘。Skills 本质上就是一套结构化的经验记录跟程序员写技术文档、老手带新人的道理是一样的。真正好用的 Skill 往往不是一次写出来的而是在一次次实际任务中打磨出来的。如果你现在刚开始接触我的建议很简单从自己最常做的一个重复任务开始写第一个 SKILL.md别追求完美先跑起来再迭代。用着用着你自然就会理解为什么这个工具能火起来也大概率会离不开它。