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、mattpocock's skills，还有各种"数学建模 skills"“渗透测试 skills”“测试用例 skills”等垂直领域的合集。
这篇文章我会从几个层面来拆解 Skills：它是怎么设计的、在不同工具里怎么用、如何从零开发一个自己的 Skill、以及实操中常见的坑。不管你是前端、后端、测试还是搞数据分析的，只要你在用 AI 辅助写代码，这玩意儿都值得花半小时了解一下。
2. Skills 的设计思路与核心原理
2.1 从 Prompt 到 Skills 的进化逻辑
要理解 Skills 的价值，得先回到 Prompt 这个老话题。过去我们使用 AI 编程工具，本质上是在做"一次性指令"——你写一段 Prompt，AI 根据上下文生成回答。这个模式最大的问题在于，上下文是临时的、脆弱的。一旦开启新会话，所有约定都得重新建立；一旦任务变得复杂，Prompt 越长，AI 越容易"忘掉"中间的关键要求。
Skills 的进化逻辑，就是把"临时的 Prompt"变成"持久化的职业技能"。它借鉴的是人类社会的分工模式：一个前端工程师不需要每次写代码前都背诵一遍 HTML 标签和 CSS 属性的含义，这些是内化的技能；同样，一个 Skill 文件就是 AI 的"内化技能"，告诉它在什么场景下应该遵循什么规则。
从技术实现角度看，Skills 的核心由三部分组成：
- 触发器（Trigger）：描述这个 Skill 适用于什么场景，AI 根据用户输入自动判断是否激活。
- 指令体（Instructions）：详细描述执行流程、技术约束、编码规范、输出要求。
- 参考资源（References）：示例代码、常见问题、目录结构规范等辅助材料。
这三者组合在一起，形成一套完整的"工作流说明书"。AI 工具会在每次对话开始时读取所有可用的 Skill 描述，如果当前用户消息匹配某个 Skill 的触发器，就把整个 Skill 文件加载进上下文，相当于给你这个会话"附了身"。
2.2 Skills 与 MCP 的关系，很多人的理解是错的
聊到 Skills 就绕不开 MCP（Model 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、mattpocock's 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_search@mcp", "image_analyze@mcp"] ---下面就是正文部分，要求用 Markdown 编写，内容通常包含执行步骤、编码规范、注意事项、验收标准等。这一段是精髓所在，写得越贴近实际项目的真实逻辑，AI 表现越好。
3. 主流程具现：手把手开发一个自己的 Skill
3.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_analyze@mcp"] --- ## 职责范围 - 将设计稿图片转换为可运行的前端页面代码 - 技术栈固定为 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 Code，Codex（OpenAI 的 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 个的时候，你会发现大部分日常开发任务都可以直接触发对应的 Skill，AI 的输出质量和稳定性会有一个肉眼可见的提升。
6.2 团队内共享 Skills 的注意问题
团队协作场景下，Skills 的价值更大，但坑也更隐蔽。最常见的问题是——不同成员本地的 Skills 版本不一致，导致同一任务在不同人电脑上跑出来的结果完全不同。建议用 Git 仓库统一管理团队 Skills，纳入代码评审流程，和普通代码一样做版本控制和变更记录。
另一个容易被忽略的问题是"隐私和权限"。如果你开发的 Skill 里包含公司内部规范、接口地址或者敏感信息，共享时要格外注意脱敏处理。我在给团队分享内部 Skill 时，会把涉及内部系统的信息用占位符替换，并在文档里标注"使用前需替换为实际配置"。
7. 最后分享一点长期使用的体会
Skills 这个概念看起来很简单，但实际用下来，它对工作流的影响是长期的。我最大的感受是——它把"调教 AI"的成本做了前置化和复用化。以前每次使用 AI 都是一次全新的调教过程，现在调教一次、长期复用，而且越用越好用。
但也别把它想得太神秘。Skills 本质上就是一套结构化的经验记录，跟程序员写技术文档、老手带新人的道理是一样的。真正好用的 Skill 往往不是一次写出来的，而是在一次次实际任务中打磨出来的。如果你现在刚开始接触，我的建议很简单：从自己最常做的一个重复任务开始写第一个 SKILL.md，别追求完美，先跑起来，再迭代。用着用着，你自然就会理解为什么这个工具能火起来，也大概率会离不开它。
