如果你最近经常逛技术社区应该被“Skills”这个词刷屏了。无论是 Claude Code、Codex 还是 Cursor几乎一夜之间都在强调“Agent Skills”这个概念。很多人以为它只是又一种提示词模板但实际用下来你会发现它带来的变化远超预期——它把“让 AI 帮忙干活”从一次性的对话变成了可复用、可分享、可团队协作的“能力包”。简单说Skills 就是给 AI 助手的一份标准化操作手册告诉它在某个具体场景下应该怎么思考、按什么顺序执行、调用哪些工具、最终产出什么格式的内容。这篇文章我想结合自己这段时间的实操经历把 Skills 是什么、怎么开发、怎么调用 MCP 工具、在哪些场景下最值得做以及我踩过的坑一次性讲透。1. Skills 到底是什么先搞清楚它和 Prompt、MCP 的区别1.1 从“提示词工程”到“技能包”的进化早些年我们调教 AI主要靠写长 Prompt。谁的提示词写得更细、更结构化谁得到的输出质量就更高。但 Prompt 有个天生的问题它是“一次性”的。每次开新对话都得重新贴一遍改起来也麻烦而且很难在团队里沉淀。Skills 要解决的就是这个“可复用”的问题。它把一套完整的工作流——包括目标拆解、执行步骤、判断条件、输出格式、甚至配套的脚本和模板——打包成一个独立单元让 AI 在遇到匹配任务时自动调用。用一句直白的话概括Prompt 是给 AI 的一句话指令而 Skill 是给 AI 的一整套 SOP。举个例子我之前写前端页面时经常会做“图片还原设计稿”这件事。过去每次我都要在对话框里写“请你分析这张设计稿的布局、颜色、字体、间距然后生成 Vue 组件注意响应式……”写多了真的很烦。后来我把它做成了一个 Skill里面包含了设计稿分析、组件拆分、样式变量提取、移动端适配检查、自检清单等步骤。之后我只需要说一句“用还原设计稿的 Skill 处理这张图”AI 就会按照既定的流程自动完成输出质量非常稳定。1.2 Skills 与 MCP 工具的关系很多人容易把 Skills 和 MCP 搞混这里我多说两句。MCPModel Context Protocol解决的是“AI 怎么连接外部工具”的问题比如让 AI 能去读数据库、操作浏览器、调用搜索 API。而 Skills 解决的是“AI 怎么组织工作流”的问题它决定了 AI 在拿到任务后先做什么、后做什么、什么时候用哪个工具。两者其实是配合关系。一个 Skill 可以声明自己依赖哪些 MCP Server也可以在执行步骤中明确指示“调用 MCP 的 fetch 工具抓取网页内容”。所以你可以这样理解MCP 是 AI 的手和脚Skills 是 AI 的大脑和工作流程图。只有手脚没有流程AI 会东一榔头西一棒子只有流程没有手脚很多步骤又完成不了。1.3 Skills 的核心优势让 AI 输出从“碰运气”变成“可预期”我之前用 AI 写代码最头疼的一点就是同样的需求有时候结果惊艳有时候结果离谱。原因很简单模型本身有随机性而且它对“好”的理解和我们不一样。但有了 Skills 之后这种不确定性大大降低了。因为 Skill 里明确写了每一步应该怎么做、什么情况算通过、什么东西必须检查AI 只能在这个框架内发挥。尤其是在团队协作中这个优势非常明显。比如我们后端团队统一使用同一个“代码审查 Skill”每个人提交给 AI 的代码都会按同样的标准检查一圈。新人不会因为没经验就漏掉关键检查项Senior 也不会因为今天心情不好就少查两块。这种标准化带来的收益比单个 Prompt 的提效要实在得多。2. 为什么最近 Skills 突然火了背后是 AI Agent 的成熟2.1 从“AI 对话”到“AI Agent”的转折点前两年我们使用 AI 的方式主要是对话我问一句它答一句。这种模式下的输出质量很大程度上依赖我把问题描述得多清楚。而 Agent 的出现改变了这一点——AI 开始能自己拆解任务、调用工具、根据中间结果调整方向。但 Agent 有个新问题如果不对它的行为做约束它很容易在复杂任务中跑偏。Skills 正好补上了这个缺口。它给 Agent 提供了“行为准则”和“操作模板”。比如你要让 AI 做数学建模光说“帮我建模”它肯定会懵但如果你有一个“数学建模 Skill”里面定义了问题分析、假设建立、模型选择、参数求解、结果验证、论文撰写这几个阶段AI 就会按部就班地推进。可以说Skills 是让 Agent 从“聪明但不可控”走向“聪明且可控”的关键组件。2.2 各大工具的跟进Claude Code、Codex、Cursor 都在押注这段时间我关注到几乎所有主流 AI 编程工具都在布局 Skills。Claude Code 推出了.claude/skills目录Codex 支持自定义 AGENTS.md 和相关技能文件Cursor 靠 Rules 机制实现类似能力OpenCode 也用配置文件支持技能扩展。这种趋势说明行业已经达成了一个共识纯靠模型能力的提升还不够必须给模型配一套可插拔的“职业技能包”。而且这些工具之间的差异主要集中在文件格式和加载方式上。比如 Claude Code 要求每个 Skill 放在独立目录里面必须有SKILL.md作为入口文件Codex 则更偏向于用AGENTS.md来声明技能Cursor 则是把规则文件放在.cursor/rules里。虽然细节不同但底层的思路是一致的让 AI 在项目上下文中知道“我有哪些能力可用”。2.3 吴恩达教程和社区热度的推动我相信很多人是看到吴恩达的 Agent Skills 教程才开始关注这个概念的。那套教程我很推荐因为它把 Skills 从“玄学”讲成了“工程学”。它里面提到一个很重要的观点Skills 不是一次性把整个任务交给模型而是把任务拆成几个小的、模型擅长处理的步骤每个步骤都可以验证、可以纠错。这个思路听起来简单但实际操作时很多人都做不到。社区里的热情也带动了一批现成的 Skills 模板。GitHub 上能搜到大量claude code skills、codex skills、opencode skills相关仓库有人专门做前端开发的有人做测试用例生成的还有人做学术研究辅助的。你不需要从零开始写站在别人的肩膀上改一改往往比自己憋半天高效得多。3. 手把手教你开发一个自己的 Skills3.1 Skills 的标准目录结构和核心文件目前最通用的 Skills 结构以 Claude Code 为参考非常简单清晰。一个 Skill 通常是一个文件夹里面最少包含一个SKILL.md文件其他辅助文件包括脚本、模板、示例等。下面是典型结构my-skill/ ├── SKILL.md ├── scripts/ │ └── helper.py ├── templates/ │ └── output_template.md └── assets/ └── example.pngSKILL.md是这个技能的“入口”AI 会优先读取它来决定是否调用以及如何执行。它的格式一般分两部分YAML 头部和 Markdown 正文。头部用来定义技能的基本信息比如名称、描述、适用场景、需要的工具等正文则编写具体步骤。一个最简单的SKILL.md长这样--- name: frontend-restore-design description: 将设计稿图片还原为高质量前端代码。适用于 UI 还原、切图、组件生成等场景。 allowed-tools: - read_file - write_file - browser_action metadata: author: your-name version: 1.0.0 --- # 前端还原设计稿 ## 步骤1分析设计稿 - 读取图片列出主要颜色、字体、布局结构 - 提取间距、圆角、阴影等设计细节 ## 步骤2生成组件代码 - 基于 Vue3 TypeScript Tailwind 输出组件 - 对重复样式使用 CSS 变量 ## 步骤3自检 - 检查响应式断点 - 检查可访问性aria 标签 - 输出自检清单3.2 编写 Skill 的核心步骤拆解任务、定义步骤、设置验收标准很多新手写 Skill 容易犯一个错误把 Skill 当成一个大 Prompt把所有要求堆在一起。这样做的问题在于AI 在执行长任务时容易丢失上下文到了后半段可能忘了前面的约束。正确的做法是像写程序一样拆解任务。第一步明确这个 Skill 的边界。是“写一个 Vue 组件”还是“把整个页面都还原出来”边界越清晰AI 越不会跑偏。第二步把流程拆成 3 到 7 个步骤。步骤太少了AI 缺少中间验证步骤太多了上下文可能不够执行效率也会下降。第三步每个步骤里都要有具体的输入、输出和判断条件。比如“分析设计稿”这一步可以明确要求 AI 输出一个 JSON 格式的设计规范包含颜色、间距、字体、圆角、阴影等字段。这样后面的步骤就可以基于这个 JSON 来生成代码。验收标准也很重要。我习惯在每个 Skill 的最后加一个“自检清单”强制 AI 在输出前逐项核对。比如“是否包含移动端适配”“是否使用语义化标签”“是否补充了注释”。这些标准不一定每条都会被 AI 认真对待但只要写进去了它就会在生成时额外花一点 token 来检查这能明显降低出错概率。3.3 Skill 如何调用 MCP 工具给 AI 一条明确的“工具使用路径”如果你的 Skill 需要跟外部环境交互那就要靠 MCP 工具了。在SKILL.md的allowed-tools声明中使用哪些工具同时在正文步骤里写清楚“什么时候调用、传入什么参数”。举个例子我写了一个“学术文献调研”的 Skill它需要联网搜索论文。我就在SKILL.md的头部声明了 MCPallowed-tools: - mcp__arxiv_search - mcp__web_fetch然后在正文里写上## 步骤2收集文献 - 调用 mcp__arxiv_search查询关键词相关的最新论文 - 对返回的论文列表调用 mcp__web_fetch 获取摘要 - 筛选出引用量最高且近三年内的论文输出表格这样做的好处是AI 不会在步骤 1 还没完成的时候就去访问外部工具也不会在不需要工具的时候乱调用。你其实是在给它画了一条清晰的“工具使用路径”什么阶段用什么工具用完工具后怎么处理结果。3.4 如何让 Skill 适配不同的 AI 工具Claude Code、Codex、Cursor不同工具的 Skills 加载机制有所差异但写 Skill 的核心思路是一样的。你写完一份SKILL.md之后可以通过简单的文件位置调整来适配不同平台。以 Claude Code 为例只需要把 Skill 文件夹放在.claude/skills/下面AI 会在会话中自动发现并加载。Codex 则更适合把 Skill 内容写在AGENTS.md中或者通过自定义命令来触发。Cursor 是放在.cursor/rules/目录使用.mdc后缀。OpenCode 更灵活可以在配置文件中注册本地 Skill 路径。我自己的做法是先写一个通用版SKILL.md然后在不同的项目下创建对应的软链接或复制文件。这样我只需要维护一套内容就能在多个工具中使用。不过要提醒一句不同工具对SKILL.md的解析细节可能有差异比如是否支持 YAML frontmatter、是否支持allowed-tools字段最好在切换工具后做一次快速验证。4. 热门场景下的 Skills 实战案例4.1 前端开发图片还原设计稿、生成组件、页面自检先说我做得最多的前端场景。前端开发是我使用 Skills 最频繁的领域因为前端工作流相对固定而且视觉还原度容易验证。目前社区里最受欢迎的一类 Skills 就是“图片还原设计稿”有的还专门针对 Figma 导出文件做了适配。我自己的“前端还原设计稿” Skill 里面除了分析设计稿、生成组件、自检清单之外还加入了一个关键步骤先生成一份设计规范 JSON再根据这份 JSON 生成页面。为什么这么做因为直接让 AI 看图片生成代码它经常会忽略全局的一致性导致每个组件颜色深浅不一、间距忽大忽小。先输出设计规范相当于给 AI 建立了一个“全局记忆”后续所有组件都基于规范生成效果会好很多。另一个非常实用的场景是“生成移动端页面”。我在 Skill 中写死了断点规则要求 AI 在生成每一个组件时都附带移动端适配方案。这样我不用每次都在对话里强调一遍AI 也会自动输出带有响应式样式的代码。4.2 测试用例生成从需求文档到测试计划测试用例生成也是一个非常适合做成 Skills 的场景因为测试用例的结构特别稳定。社区里能找到不少“测试用例 Skills”模板但我建议还是根据自己的项目定制一下效果会更好。我写了一个“前端测试用例生成” Skill输入可以是需求文档或者代码文件输出是一份包含功能测试、边界测试、异常流程测试的用例表格。我要求 AI 在生成用例之前先梳理业务规则列表再列出用户操作路径最后才写具体用例。这样生成出来的用例不会漏掉关键路径而且覆盖率更高。另外我在这个 Skill 里加入了一个强制步骤对于每一个测试用例必须同时标注预期结果和实际结果的验证方法。这样测试人员在执行的时候就能更快判断问题而不是对着一条“点击按钮后页面正常显示”这种模糊描述发呆。4.3 数学建模从问题分析到论文撰写数学建模是 2024 年以来很受关注的一个方向GitHub 上也有不少开源的数学建模 Skill。这类 Skill 通常把建模过程拆成几个阶段问题背景分析、假设条件梳理、模型建立、参数估计、灵敏度分析、结果可视化、论文撰写。我最喜欢的一个开源模板里每个阶段都附带了具体的输出模板。比如模型建立阶段要求输出模型名称、变量定义、数学方程、约束条件、求解方法。这样整篇建模论文的骨架在前期就已经搭好了后面只需要填充数值和图表效率非常高。如果你准备参加数学建模类竞赛强烈建议提前把这类 Skill 准备好比赛时能省下大量沟通和调整的时间。4.4 学术研究与安全测试常见现成 Skill 盘点学术研究方面比较成熟的 Skill 包括“文献检索与总结”“论文结构生成”“参考文献格式化”等。有些仓库还结合了 Semantic Scholar API 或 arXiv 的 MCP 工具让 AI 能实时获取论文信息。我特别喜欢“文献检索与总结”这类 Skill因为它能把“搜索-筛选-总结-引用”这套流程固定下来减少我在调研初期的重复劳动。安全测试方向的 Skills 也有不少比如“API 安全评估”“前端依赖风险检查”。在合规范围内这类 Skill 可以帮助开发团队做第一道自查但不能替代专业的安全测试。我的建议是如果你在团队里负责安全工作可以自己写一个清单型 Skill把你们团队常用的安全检查项固化下来这样每次做安全自查时AI 都能按同样的标准过一遍。5. 开发和使用 Skills 时我踩过的那些坑5.1 为什么 Skill 不生效排查头部描述和加载路径刚开始使用 Claude Code 时我遇到最多的问题就是“为什么我的 Skill 没有被触发”。后来我查了文档才发现Skill 的触发依赖SKILL.md里的description字段AI 会根据这个描述来判断当前任务是否匹配。如果描述写得太笼统比如“前端开发技能”AI 反而不容易匹配但如果写得具体一些比如“将设计稿图片还原为 Vue3 TypeScript Tailwind 代码”触发率就会高很多。另外路径也很重要。不同工具要求 Skill 放在不同的目录下放错了位置AI 根本不会加载。我在 Codex 上就吃过这个亏把 Skill 放在了.claude/skills目录而忘了复制到 Codex 的项目目录结果半天没生效。建议刚接触时用工具自带的调试命令查看当前加载了哪些技能。5.2 调用 MCP 工具失败检查工具配置和权限Skills 调用 MCP 工具失败通常不是 Skill 本身的问题而是 MCP Server 没有正确启动或者没有授予权限。Claude Code 默认会读取~/.claude.json里的 MCP 配置如果你新加了一个 Server 但没有重启终端AI 是感知不到的。Codex 则需要检查项目里是否有对应的工具配置。还有一个容易踩坑的点allowed-tools里的工具名称必须跟实际 MCP Server 注册的名称完全一致。你写fetch但 Server 注册的是web_fetchAI 会报“tool not found”。解决方案是先让 AI 列出当前可用的工具列表再根据实际名称修改 Skill 文件。5.3 上下文太长导致 AI 执行到一半“失忆”Skills 会把指令和上下文同时计算在 token 消耗里。如果你的 Skill 写得过长加上用户原始输入、中间结果很容易把上下文塞爆。AI 执行到后半段可能会忘记前面的步骤要求输出也会越过越马虎。我的对策是为 Skill 设置“步骤淘汰机制”。也就是说每个步骤处理完后AI 要输出一个简短的中间结果摘要然后清掉不必要的细节。在具体写法上我会在SKILL.md里明确“每个步骤只保留输出结果不要保留原始输入和分析过程除非后续步骤需要”。这样能让上下文一直保持在一个合理的长度。5.4 版本兼容性不同工具对 Skill 的解析不完全一致不同 AI 工具对 Skill 的支持程度还不统一。就拿SKILL.md的 YAML frontmatter 来说Claude Code 能正确解析name、description、allowed-tools但某些工具只认识name和description字段。所以我做跨工具复用时会先把 Skill 精简成最核心的版本确认基本功能可用后再逐个添加增强字段。另外有些工具更新版本后会改变 Skill 的加载逻辑。比如我用的某个版本突然要求SKILL.md文件名必须小写否则加载失败。所以当你升级工具后最好先检查一遍已有的 Skill 是否还能正常触发不要盲目相信“之前能用现在肯定也能用”。6. 如何从社区拿现成 Skills再改造成自己的6.1 去哪儿找高质量的 Skills 仓库现在 GitHub 上有不少 Skills 合集比如 Awesome Claude Code Skills、Superpowers Skills 合集等。“superpower skills”这个关键词最近特别热实际上就是社区里一套专注于增强 Claude Code 能力的技能集合里面包含了很多实用的工作流模板。找仓库的时候不要只盯着 Star 数量。我建议先看仓库的更新时间和 issues 里有没有人反馈问题。如果一个仓库长期不更新很可能里面的 Skill 已经不兼容新版工具了。另外优先选择那些带有示例和测试的仓库这样你能在本地快速验证。6.2 拿到别人的 Skill 后需要改哪些东西别人的 Skill 拿来基本不能直接用至少要做三处修改。第一把示例代码中的技术栈换成团队自己的技术栈比如别人写的是 React你们用的是 Vue那肯定要改。第二把步骤里的细节调整成符合实际项目规范的版本比如你们团队的 ESLint 规则、提交信息格式、命名规范都要注入到 Skill 里。第三检查description的描述是否符合你们的业务习惯确保 AI 能被准确触发。另外我强烈建议在 Skill 文件里加一个metadata字段记录作者、版本、最后修改时间。这样团队协作时每个人都能快速知道这个 Skill 是谁维护的什么时候更新过。这个习惯在多人协作的项目中尤其重要能避免好几个版本混乱不清的问题。6.3 自己开发 vs 使用现成模板怎么选我的经验是通用性强的场景直接使用现成模板比如代码审查、文档生成、测试用例生成这些。而涉及特定业务逻辑的场景自己开发更好。比如“还原设计稿”这种你的团队用 Tailwind 还是 CSS Modules会直接影响生成结果现成模板很难帮你做到完全匹配。自己开发的时候先从一个最小可用版本开始。只包含两三个核心步骤验证流程能跑通再慢慢加细节。不要一上来就写一个 60 行的复杂 Skill否则排查问题的时候会很痛苦。我现在开发 Skill 的习惯是先用纯提示词完成一次任务记录 AI 执行过程中的关键决策点然后把这些决策点转化为 Skill 步骤。这样做出来的 Skill 往往更贴近实际操作效果也最好。6.4 团队协作中如何维护和更新 SkillsSkills 既然是一种资产就需要有版本管理。我所在团队的做法是把所有 Skill 放在一个单独的 Git 仓库里每次修改都走 Pull Request代码评审的时候重点看步骤是否清晰、是否有安全风险、是否兼容当前工具版本。同时我们会在每个 Skill 里添加一个“测试用例”字段模拟几类典型输入让 AI 自我验证输出是否符合预期。当工具升级或者模型版本变化后我们会批量跑一遍所有 Skill 的测试提前发现兼容性问题。这套机制虽然前期有点麻烦但长期看能节省大量重复调试的成本。7. 结尾一点个人经验分享用了大半年 Skills 之后我的最大感受是它改变了我和 AI 协作的方式。以前我是每次手动指挥 AI现在更像是在给 AI“培训上岗”培训一次它以后就按照这个标准持续交付。尤其是把那些自己多年积累的检查项、坑点都写进 Skill 之后我自己写代码反而更轻松了因为 AI 会在关键环节帮我做一次“老手级”的检查。最后再分享一个小技巧写 Skill 的时候哪怕你觉得某些步骤是“常识”也建议写在文档里。比如“生成代码后必须运行一次 TypeScript 类型检查”这句话看起来多余但对 AI 而言没有写就意味着默认不执行。你写得越细AI 的表现就越稳定。每次在项目中遇到值得固化的经验我就顺手更新到对应 Skill 里久而久之这套技能包就成了我个人的“数字资产”也是团队里最好的文档之一。