最近一段时间我身边聊 AI 编程的人几乎都在提同一个词skills。从 GitHub 上的各种仓库到 Claude Code 的插件生态再到 Cursor、Codex 的进阶玩法到处都有人在问“前端开发 skills 有哪些”“数学建模 skills 推荐”“怎么开发自己的 skills”。如果你和我一样过去几个月一直在折腾各种 Agent 编程工具应该不难发现模型本身的能力已经很难拉开差距真正让人效率差出好几倍的反而是你喂给 Agent 的那套“技能包”到底是什么水平。所以这篇内容我想从自己实际折腾 skills 的经验出发把它的底层逻辑、目录结构、编写方法以及目前社区里最值得参考的玩法一次性讲透。无论你是刚听说这个词的新手还是已经在 Claude Code 里装过几个 skill 的老朋友这篇都适合你花十分钟读一遍。1. 先搞清楚Skills 到底是什么为什么突然这么火1.1 从一堆热搜词里看 skills 的真实内涵如果你把“前端开发 skills”“claude code skills”“opencode skills”“吴恩达的 agent skills 教程”这些关键词放在一起看会发现大家讨论的其实不是同一个层面的东西。有人是在找现成的技能包下载有人是想搞明白 skills 和 prompt 有什么区别还有人已经踩到了调用 MCP 工具的坑里。我的理解是在 AI Agent 的语境下skills 是一套结构化的“能力模块”。它不是一个普通提示词而是把某个场景下的操作流程、判断规则、示例代码、输出格式、注意事项打包成一个标准单元让 Agent 在遇到对应任务时能自动调用。你可以把它想象成给 Agent 装了一套“岗位手册”——它不告诉模型“你要聪明一点”而是告诉模型“遇到这类任务你应该按照这个流程来”。这也解释了为什么同样用 Claude Code有人让它写出来的代码风格统一、考虑周全有人却要反复纠正模型。前者很可能是给 Agent 配了覆盖完整工作流的 skills后者只是在靠模型的基础能力硬扛。1.2 为什么说 skills 是 AI Agent 的“外挂技能树”我在实际使用中有一个很直观的体会模型像是新入职的员工基础素质很好但不懂你公司的流程和规范。你给它一个任务它能完成但结果不一定符合你的预期。而 skills 的作用就是把这些“流程和规范”固化下来变成 Agent 可以随时查阅和执行的标准作业程序。过去我们做提示词工程核心是把指令写进每一段对话里。但问题是当一个 Agent 要处理多种任务时把所有指令都塞进系统提示词里既占上下文窗口又容易互相干扰。skills 的聪明之处在于按需加载Agent 先判断当前任务属于哪个技能领域再加载对应的技能包。就像游戏里角色有不同的技能树需要放魔法时切到魔法系需要近战时切到战士系。另外skills 目前已经成为很多 Agent 工具的原生概念。Claude Code 里有专门存放 skills 的目录OpenCode 社区也在大量分享各类 agent skills吴恩达甚至专门出过一套 Agent skills 教程 PDF 来讲解如何构建这类工作流。可以说这个方向已经从个人 hack 变成了行业共识。2. 拆解 skills 的构成与运行原理2.1 一个标准 skill 包长什么样我在本地给 Claude Code 做过好几个自用的 skill也在 GitHub 上参考过一些热门仓库。通常一个标准 skill 包不外乎这几部分一个目录目录名就是这个技能的标识比如frontend-layout、test-case-generator。一个说明文件通常是SKILL.md里面描述这个技能是干什么的、适用于哪些场景、有哪些关键步骤。可选的辅助脚本或模板文件比如生成测试用例时用到的数据模板、处理图片时调用的 Python 脚本。如果会用到外部工具还会有一个配置文件来声明 MCP 工具或其他依赖。其中SKILL.md是核心。它不是随便写一段教程而是要遵循一定的结构让 Agent 能快速解析。我常用的结构是技能名称、适用场景、输入要求、处理流程、输出格式、注意事项、示例。这里有个容易忽略的点SKILL.md里的语言和格式要尽量稳定。Agent 在加载技能时会对这个文件做解析如果你今天用中文写、明天用英文写或者一会儿用列表一会儿用大段落模型的解析效果就会打折扣。我自己的习惯是先定一个 Markdown 模板所有 skill 都按同一个骨架来写。2.2 skills 是怎么被 Agent 发现和调用的关于 skills 的调用机制很多教程里没有讲清楚我查了不少源码和文档才弄明白。大致分三个层次第一层是“前置扫描”。很多 Agent 工具在启动时或收到任务后会扫描配置好的 skills 目录把每个技能的名称、描述、适用场景汇成一份索引。这一步实质上就是“技能发现”。第二层是“意图匹配”。Agent 根据当前用户任务和技能索引做语义匹配。比如用户说“帮我分析这个项目的结构”如果索引里有一个project-analyzer技能描述里写着“分析项目目录结构与模块关系”模型就很可能选择加载它。第三层是“技能注入与执行”。匹配成功后Agent 会把对应技能包中的SKILL.md内容作为上下文的一部分读取进来然后按照里面的流程执行。如果技能里写了“调用 MCP 工具来获取数据”Agent 就会在后续步骤里发起 MCP 调用。这个机制最大的好处是省 token而且能做到任务和技能的解耦。我见过一些团队把整个公司的代码规范、测试流程、总结模板都做成了 skills然后放在共享目录里所有开发者的 Agent 都能使用效率提升非常明显。3. 手把手实战如何开发自己的第一个 skills3.1 确定场景与输入输出我第一次开发自己的 skill是给前端还原设计稿的场景做的。原因很简单每次让 Claude Code 根据图片生成页面它总是“自由发挥”布局和细节经常跑偏。我需要一套可复用的方法来约束它。开发 skill 的第一步不是写文件而是想清楚场景边界。我建议你拿张纸回答三个问题这个技能解决什么任务要具体不要写“帮助写代码”这种空话而要写“将图片设计稿还原为移动端 HTML/CSS 页面”。输入是什么是截图、设计稿文件路径、需求描述还是已有的代码文件输出是什么一份 HTML一套组件代码一份检查清单还是修改后的文件路径这些定义清楚了后面的编写才会有方向。否则你写出来的 skill 往往编译不过“意图匹配”这一关。3.2 编写 SKILL.md 的步骤与模板我给一个自己写过的 skill 做过简化你可以参考这个结构--- name: frontend-design-to-code description: 根据设计稿图片生成前端页面代码适用于移动端 H5 页面。 --- # 前端设计稿还原技能 ## 适用场景 - 输入设计稿图片路径或包含设计稿的目录 - 输出完整的 HTML/CSS 页面文件以及必要的说明文档 ## 处理流程 1. 分析设计稿中的布局结构识别功能模块。 2. 确定使用的技术栈默认使用移动端流式布局。 3. 先搭建页面骨架再填充样式最后处理交互细节。 4. 输出代码时特别注意间距、字体、色彩的统一。 ## 注意事项 - 不要使用固定像素宽度优先使用 rem / vw。 - 图片资源使用相对路径避免外部链接。 - 如果设计稿中存在模糊区域优先采用主流 UI 规范默认值。你会发现这个模板的重点是让 Agent 在每一步都有清晰的行为准则。不要写太玄的东西比如“要精益求精”模型没法执行。要写可检查、可执行的动作比如“先搭建骨架再填充样式”。写完初稿之后把 skill 放到 Agent 的 skills 目录下然后用一个真实任务测试。第一轮一般不会完全符合预期这时候要回到SKILL.md里补细节。我通常会连续测三次一次是正常场景一次是边界输入一次是故意给模糊需求看 skill 能不能兜底。3.3 测试与迭代的实操要点这里分享几个我踩过的坑。第一个坑是“技能描述写得太大而全”。有段时间我试图写一个“通用前端 skill”结果 Agent 每次匹配都会触发它但这个技能里面什么都有等于什么都没约束。后来我把技能拆成了layout-restore、component-style-check、mobile-adaptation好几个小技能匹配率和执行质量都明显提升。第二个坑是“过度强迫 Agent 遵守步骤”。如果流程里写了“先做 A再做 B再做 C”模型确实会按顺序执行但有时它会在 A 步骤上过度用力。解决办法是在每个步骤后面补充“终止条件”比如“当页面结构基本完整时即可进入下一步”。第三个坑是“没有版本管理”。skills 的迭代一旦多了改坏了很难回退。我现在会把所有 skill 放在一个 git 仓库里每次改动都提交。这样出了问题可以对比历史版本也方便和团队成员共享。4. 盘点社区里那些“出圈”的 skills 用法4.1 前端开发从设计稿到代码、移动端适配前端开发是 skills 应用最热闹的领域之一。从热搜词里能看到大家都关心“图片还原设计稿”“移动端 skills”“web 前端 mcp skills”。我实际用下来的感受是这类 skill 的核心价值不在“生成代码”而在“约束代码生成的方式”。比如在写移动端页面时普通模型可能会因为上下文太长而忘记用 rem、忘记考虑安全区、忘记做响应式断点。但如果你把一份写得足够细的 mobile 开发 skill 放在 Agent 面前它每一次生成都会遵守这些约定。还有一种很好用的前端 skill 是“代码审查”。我会把公司内部的前端规范整理成 skill 的注意事项部分然后让 Agent 在写完代码后自动对照审查一遍。以前人工 review 要花半小时现在 Agent 可以在我提交代码前把大部分风格问题和低级的可访问性问题挑出来。4.2 测试用例生成与数学建模测试用例生成也是同样道理。我自己在写一个 Python 服务时让 Agent 根据接口定义生成测试用例结果它生成的用例数量很多但缺少边界条件和异常场景。后来我在 skill 里加入了“必须覆盖正常路径、异常路径、边界值、空值场景”的规则输出质量一下子上来了。数学建模方向的 skills 也很有意思。很多做数模竞赛的同学会在 GitHub 上找“数学建模 skills 推荐”。这类技能通常会把常用的模型方法、论文写作框架、数据处理流程打包进去。比如解决一个预测类问题Agent 会被引导先做数据探索再尝试多种模型最后用统一格式输出对比结论。这样整个建模过程的可复现性就高很多。在这些场景里skills 的共同点是它们把“一个优秀从业者遇到这类任务时脑子里会过一遍的东西”显式写了下来。模型不需要凭空猜测你也不需要反复纠正。4.3 在 Claude Code、Cursor、Codex 里使用 skills 的注意事项不同的工具对 skills 的支持方式有细微差别但核心思路一致。我在 Claude Code 里用的是官方支持的 skills 目录在 Cursor 里常用的是通过规则文件和自定义指令来实现类似效果在 Codex 里则可以用社区里现成的 codex 常用 skills 仓库来加速分析类任务。这里给大家一个通用建议先确认你用的工具支持哪种方式的 skills 加载。有些工具只认特定目录下的 Markdown 文件有些工具需要额外的配置文件来激活技能索引还有些工具支持通过 MCP 路由来调用外部技能。如果你把一个仓库里的 skill 原样拷到另一个工具里不一定能直接用起来。另外用社区下载的 skill 前一定要通读一遍内容尤其是涉及执行脚本的部分。开源仓库里的 skill 质量差异很大有些只是把 prompt 换了个名字有些会要求 Agent 下载并运行外部脚本。出于安全考虑我从不运行来源不明的脚本。这一点在开源社区里再怎么强调都不过分。5. 常见问题与排查技巧实录5.1 为什么 Agent 总是不按我的 skill 执行我收到最多的问题就是“我明明写了 skill但 Agent 就像没看见一样。”这个问题八成出在匹配环节。第一你的技能索引信息可能不够具体。如果描述里只有“根据图片生成页面”这种模糊表达模型很难在多个技能之间做区分。我建议在description字段里写清触发条件比如“当用户提供设计稿图片并希望生成移动端页面时使用”。第二你可能有多个技能覆盖了同一场景。模型可能选到了另一个相似技能。检查方式是查看 Agent 运行时的日志看它实际加载了哪个技能。有的工具里能直接看到“loaded skill: xxx”的提示。第三你可能会话上下文里的冲突指令覆盖了 skill。如果你在对话里又说“不要用 rem”而技能里写了“用 rem”模型通常会服从更直接的近期指令。解决方法是保持一致要么把对话里的要求删掉要么改掉技能里的规则。5.2 与 MCP 工具的联动调用关系与冲突处理“skills 如何调用 MCP 工具”是近期被问得最多的问题之一。两者的关系我打一个比方MCP 是工具插口skills 是使用手册。技能里写清楚“什么情况下调用哪个 MCP 工具、传入什么参数、拿到结果后如何处理”Agent 才能正确完成为工具接线的过程。我在实际项目中遇到过一个问题某个 skill 本来只需要调用一个代码搜索工具但因为 MCP 配置里同时挂了十几个工具Agent 在意图识别时选了错误的工具导致输出结果很差。排查了很久才想到问题不在 skill 本身而在工具的数量和描述冲突上。解决方法是收敛 MCP 工具数量并给每个工具加上清晰的描述。如果某个 skill 只依赖特定工具可以在 skill 的注意事项里写明“本技能只使用search_code工具不要调用其他数据库相关工具”。这样可以有效减少模型的选择困难。5.3 技能复用、版本管理与团队协作最后聊一点团队层面的经验。如果你只是一个人折腾 skills 写到一定程度就会遇到两个问题一是自己都觉得乱了二是换台机器就找不到原来的技能。我现在的方法是建一个统一的 skills 仓库目录结构按场景划分命名为frontend/、backend/、test/、>