如果你最近刷 GitHub 或者技术社区很难避开一个词Skills。从 Claude Code 的官方文档到 Codex 的使用指南再到各种 Agent 框架的 README几乎都在提它。很多人第一反应是这不就是提示词换了个名字吗还真不是。Skills 要解决的问题是让大模型 Agent 具备“可复用的专业工作流”而不是只会针对单条消息即兴发挥。这一篇是「Skill 从入门到精通」的第一章我会先把它的核心认知和工作原理讲透不急着堆配置。适合刚接触 Skills 的 AI 工具用户也适合想系统梳理“到底为什么这么设计”的进阶开发者。这波热度最大的推动力来自 AI 编程工具的进化。以前我们打开对话窗口问一个答一个现在 Claude Code、Codex、Cursor 这些工具会把任务拆成多步执行自动读写文件、运行命令、调用外部服务。任务变复杂以后每次都要在系统提示词里重复“你是前端专家”“先看设计稿再写代码”“输出要符合我们的规范”这类背景效率极低。Skills 就是把这些反复使用的“做事方法”打包成标准化模块让 Agent 在需要时自动加载于是它就成了 Agent 工作流里非常重要的基础设施。1. 认知Skills 到底是什么为什么值得单独研究1.1 Skills 不是提示词也不是插件而是一套“做事方法”的封装我先给一个最直白的类比。你带过新人就会明白口头交代一句“帮我做个页面”和递给他一份《前端开发规范手册》效果完全不同。普通 prompt 就是口头交代信息一次性、不持久聊完就没了Skills 更像那本手册有目录、有步骤、有检查清单、有参考模板新人Agent拿到之后能按流程做而且这本手册可以长期复用、跨项目携带。从技术实现上看一个 Skill 通常是一个目录里面有一个入口文件 SKILL.md用结构化 Markdown 来写清楚“这个技能什么时候用、要怎么执行、要遵守什么约束”。目录里还可以放参考文档、模板、脚本。和插件的区别在于插件是写死的代码提供确定的功能Skill 是给模型读的指令和经验靠模型的推理能力来落地。和普通 prompt 的区别在于Skill 不是临时粘贴的一段话而是有元信息、有目录结构、能被 Agent 按描述自动匹配的文件模块。这个差异非常重要因为它决定了 Skill 的核心价值模块化。你可以把“图片还原设计稿”“生成测试用例”“做数学建模”分别封装成独立技能仓库里放一堆 skillsAgent 只会在遇到对应任务时加载那一个不会互相污染上下文。1.2 为什么 Skills 偏偏在现在火起来问题来了这套思路不是今天才有为什么现在突然成了热门词汇我的判断是三件事撞到了一起。第一Agent 任务从“单轮问答”变成了“多步执行”。当 AI 编程工具需要自己读目录、改文件、跑测试、查文档的时候仅仅靠聊天框里的上下文已经不够了。它们需要把领域知识和工作流注入到执行过程中Skills 提供的就是这种“按需注入”的通道。第二上下文窗口虽然变大了但不会无限大而且塞太满会干扰模型判断。与其把几十页知识库全部压在上下文里不如拆成多个 Skill用到哪个加载哪个。就好比电脑内存不够大但你有磁盘需要用的时候再换页效率反而更高还不会让模型被无关信息带偏。第三社区开始沉淀大量成熟模板。大家发现同一个任务比如“前端还原设计稿”别人已经总结出非常完整的流程直接打包成 skill 分享比自己从零开始写 prompt 省太多时间。GitHub 上已经有 superpower skills、baoyu skills 这类仓库核心逻辑都是把 Claude Code、Codex 等工具的最佳实践收集成可导入的技能包。1.3 真实场景里的 Skills 长什么样只看定义容易空看几个实例就清楚了。前端开发。社区里很热门的一类 skill 是“图片还原设计稿”。它的 SKILL.md 会写当用户给截图或设计稿时先分析页面布局、识别颜色和字体再按照设计系统的规则生成 HTML/CSS最后用浏览器工具自测。里面还会带上若干规范文档比如“不要使用图片当背景文字”之类的团队约定。一个前端工程师拿到这个技能等于瞬间拥有了一套标准化的“设计稿转页面”流程。数学建模。数学建模类 skill 会把比赛或项目里反复用到的套路固化成步骤先做数据清洗再画探索性图表接着建模、评估、调参最后输出分段清晰的报告甚至规定 LaTeX 公式怎么写。对参赛团队来说这能省下大量沟通成本。学术研究。academic research skills 在热搜词里反复出现这类技能通常负责文献检索、摘要提取、引用格式整理。它会把“先查哪些库、怎么判断文章质量、怎么生成文献综述”这些经验直接写成可执行流程。你会发现这些例子有一个共同点它们都包含明显的领域经验而不仅是“帮我写个代码”这种通用能力。把经验沉淀成文件就是 Skills 能提供的最实在的价值。2. 原理一次 Skill 调用的完整链路2.1 先看文件结构SKILL.md 是入口不是全部理解原理第一件事是认识 Skill 的物理形态。最典型的结构是这样的my-skill/ ├── SKILL.md ├── scripts/ │ └── build.py ├── templates/ │ └── reset.css └── refs/ └── design-tokens.mdSKILL.md 是唯一必须存在的文件它的开头通常有一段 YAML 元信息后面是 Markdown 正文。元信息里最关键的是 name 和 description这两个字段直接决定 Agent 能不能在正确的时机想起这个技能。正文则是给模型看的操作手册会拆成“使用场景、执行步骤、输入输出规范、禁止事项”几个部分。为什么说 SKILL.md 是入口而不是全部因为真正支撑一个复杂任务的材料往往不应该全塞进 SKILL.md 里。比如一份 30 页的设计规范如果直接复制进技能正文会占掉大量上下文影响模型在关键步骤上的注意力。正确做法是把长篇资料放到 refs 目录在 SKILL.md 里只写“遇到颜色规范时参考 refs/design-tokens.md 中的值”需要时再读取。这就是按需加载的精髓。2.2 Agent 如何决定“用哪个技能”一次实时的意图匹配很多人有个误解以为写好了 SkillAgent 每次就一定会用。实际上Agent 触发 Skill 的过程更像“搜索引擎”而不是“菜单点击”。当用户发来需求后Agent 会把当前任务意图和所有可用 Skill 的 description 做相关性匹配匹配度够高才加载对应的 SKILL.md。所以 description 写得好不好直接影响技能能否被命中。一个好的 description 不是一句“处理前端任务”这种废话而是要覆盖触发场景和关键词比如“当用户提供设计稿截图、网页预览图、Figma 导出图需要生成 HTML/CSS 时使用”。在部分实现里用户也可以用显式方式指定技能比如在指令里写出 skill 的名字或者通过斜杠命令调用。但大多数主流工具还是以意图匹配为主。提示如果你发现一个 skill 完全没有被触发第一个要查的就是 description 是否写得像“搜索摘要”。名字叫什么不重要描述才是触发开关。2.3 执行阶段把 SKILL.md 当作行为约束与工作记忆一旦命中SKILL.md 的内容会被注入到模型的可访问上下文中。这里有个关键点它和普通对话历史不是一回事。对话历史是“已经发生的对话”SKILL.md 则是“当前任务的行为准则”会持续约束模型接下来的每一轮动作直到任务结束或状态切换。好的 SKILL.md 会刻意使用祈使句比如“先分析布局再编写 HTML”“未经确认不要修改其他文件”“生成后必须用本地预览做自测”。这些指令会直接影响模型后续的决策。如果技能里设计了中间产物比如“把提取出的图片路径保存到 notes/assets.md”模型就会在步骤之间落盘形成工作记忆这样即使上下文滚动关键信息也不丢。这也是为什么复杂任务喜欢拆成阶段分析阶段、编码阶段、自测阶段。每个阶段在 SKILL.md 里有明确产出模型就知道自己进行到哪一步不会跳来跳去。这个设计思路和工程师写任务拆解文档的风格很接近。2.4 Skills 与 MCP一个负责“脑子”一个负责“手脚”很多人在搜索“skills 如何调用 mcp 工具”这里单独说明。MCPModel Context Protocol解决的底层通信问题让 Agent 能标准化地连接外部的文件系统、数据库、浏览器、设计工具等。Skills 解决的是方法论问题把“遇到设计稿时应该怎么做”这套流程交给模型。两者不但不冲突反而天然互补。一个 Skill 的内部步骤里可以写“调用 MCP 的浏览器截图工具获取页面截图”Agent 看到这句话就知道要按协议去执行。也就是说MCP 提供能力Skill 编排用法。Skill 里写的是“什么时候调用什么工具、拿到结果后怎么办”MCP 负责真正把结果拿回来。实际操作中我建议在 SKILL.md 里把外部工具依赖写清楚例如在“使用前提”部分列出“需要开启浏览器 MCP server”。这样 Agent 在缺少工具时要么主动提示用户要么跳过相关步骤而不是闷头往下走。这也是评估一个 skill 质量高低的重要维度它有没有说清楚自己的依赖边界。3. 实操手写一个“截图还原设计稿”的 Skill3.1 先定目标与目录结构说再多不如练一个。我挑前端开发里最常被搜索的场景图片还原设计稿。目标很清晰用户丢一张 UI 截图过来skill 能让 Agent 输出一套符合规范的前端页面代码并且完成基础自测。设计上我不追求一步到位先做最小可用。目录结构定为screenshot-to-code/ ├── SKILL.md ├── scripts/ │ └── extract_assets.py ├── templates/ │ └── base.html └── refs/ └── frontend-guideline.md每个文件的职责SKILL.md 是流程入口extract_assets.py 负责从截图里提取颜色和图片资源base.html 是输出模板统一页面骨架frontend-guideline.md 是团队的编码规范。这样拆的好处是模型在每一步只需要读当下相关的文件不需要一次性把所有东西吞进去。3.2 编写 SKILL.md元信息、步骤与禁止项SKILL.md 的正文我会这么写。开头元信息强调触发场景正文分成“目标、前置条件、执行步骤、输出要求、禁止事项”五块。执行步骤要非常具体宁可啰嗦也不要让模型自由发挥。例如第一步不是“分析图片”而是“用视觉识别列出版块结构包括导航、主内容区、页脚记录每个色块的十六进制值”。越具体结果越稳定。--- name: screenshot-to-code description: 将 UI 截图、设计稿图片、Figma 导出图转换为前端页面。适合用户提供图片并要求实现网页时使用。 --- # 截图还原设计稿 ## 目标 将输入图片还原为结构清晰、风格一致、可直接运行的前端页面。 ## 前置条件 - 输入必须是一张清晰的设计稿或 UI 截图。 - 如果目标包含交互逻辑用户需要额外说明。 ## 执行步骤 1. 观察图片列出页面结构导航、内容区、页脚等。 2. 提取色彩记录主要背景色、文字色、强调色。 3. 按 refs/frontend-guideline.md 的规范编写 HTML/CSS。 4. 使用 templates/base.html 作为基础骨架。 5. 生成后启动本地预览确认布局与图片一致。 ## 输出要求 - 输出文件路径默认放在 ./output/ 目录。 - 同时输出一份简短的实现说明列出关键色值和字体方案。 ## 禁止事项 - 不要使用网络图片作为页面资源。 - 不要在未确认的情况下修改已有的非目标文件。这段内容看起来简单其实已经隐含了触发、加载、执行、约束的完整闭环。禁止事项尤其重要它能把模型“过度发挥”的概率降下来。3.3 补充附件脚本与模板如何服务主流程前端 skill 里最好带一个小脚本。比如 extract_assets.py做一件非常简单的事用 Python 读图片把主色提取出来并输出成 JSON。模型在步骤 2 可以调用它拿到颜色也可以直接用视觉能力肉眼看图两者互补。关键是脚本必须“小而可靠”不要指望一个脚本解决所有问题。base.html 是骨架模板里面预置了标准的 meta、视口设置、reset 样式入口。如果团队有设计系统可以把 token 文件放到 refs 里。附件的价值在于给模型确定性支撑避免每次生成完全不同的页面结构。这是 Skill“可复用”的另一层含义同一团队、同一技术栈输出能保持统一。3.4 安装、加载与调试三步验证法不同工具的安装路径不完全一样但逻辑相通。以 Claude Code 这类支持本地 skills 目录的工具为例通常会读取用户目录下的 skills 文件夹比如~/.claude/skills/。把写好的技能目录放进去重启或重载会话skill 就进入了可用列表。Codex、Cursor 等工具也有各自的存放位置官方文档会写明。放进去不代表能用我习惯做三步验证。第一步直接问“你有哪些可用技能”看能不能在列表里看到刚写的名字。第二步给一个明确的触发输入比如一张 UI 图片看模型是否会自动提及使用该技能。第三步看输出是否满足 SKILL.md 里定义的“输出要求”不满足就逐条反查。调试阶段最实用的技巧是给 SKILL.md 的某个步骤临时加一行“执行到此处时先向用户汇报当前进度”。这样你能完整看到模型有没有按流程走就像给代码加日志。等流程稳定后再删掉这行。4. 高频问题与排查技巧实录4.1 技能一直不被触发先别怪模型检查 description我遇到过很多次skill 写得很完整但 Agent 就是不用。90% 的情况是 description 太泛。比如写着“前端页面生成”模型根本不知道什么场景该触发。把它改成“当用户提供设计稿截图、UI 图片并希望实现网页时使用”命中率立刻大幅上升。还有一点部分工具对技能搜索有数量限制如果仓库里放了 50 个 description 写满“前端”的 skill彼此之间还会互相干扰命名时要刻意区分场景关键词。4.2 结果不稳定、步骤频繁走样怎么办同一个 skill这次按流程走下次乱跳这是使用复杂技能最常见的痛点。原因通常有三类。一是步骤写得不够“可验证”模型做着做着就飘了解决办法是给每个步骤明确产出物。二是附件材料缺失SKILL.md 里引用了某个 refs 文件但实际没放进去模型只能瞎编。三是外部工具不稳定依赖的 MCP 服务没有启动导致中途失败。先按这三类排查比反复改 prompt 有效得多。4.3 上下文太长、加载太慢怎么优化有些 skill 把几千行参考文档全部写进 SKILL.md加载后直接吃掉大量上下文。负责任的做法是把大文档放 refs 目录在步骤里按需求读取。如果单文件仍然过大可以在 SKILL.md 里指定“用 grep 搜索 refs 目录里的关键词不要整篇读取”让模型按需查询。这个技巧在能直接执行 shell 命令的工具里非常实用。4.4 权限和安全边界新手最容易忽视的坑Skill 的本质是让模型按固定流程执行操作这意味着它会自动跑命令、写文件。如果 SKILL.md 里包含“删除临时目录”“全局安装包”这类高风险命令一旦触发条件被误命中后果可能很难收拾。我自己的习惯是三条原则默认不写危险命令必须写的时候加“先经用户确认”的强制步骤每个 skill 在正式使用前做一次代码审查重点看它允许调用哪些工具、会改哪些路径。注意不要在生产环境直接执行未经审查的 skill。哪怕只是导出一个“看起来只读”的文档也可能因为附件脚本里的路径问题产生意外修改。4.5 常见问题速查表症状可能原因处理方式技能不被触发description 太泛或不准确重写 description加入触发场景与关键词执行步骤混乱步骤缺少产出物给每个步骤定义明确的输出结果引用的附件无效refs 文件缺失或路径错误检查目录结构按相对路径引用上下文过大长文档都写在 SKILL.md移到 refs用按需读取方式工具调用失败依赖的 MCP server 未启动在技能前置条件里标明依赖并检查生成了危险操作技能内包含高风险命令审查 SKILL.md高危险操作强制用户确认5. 生态值得关注的 Skills 方向与选型心得5.1 前端开发与设计稿还原是最成熟的方向从热搜词的密度就能看出来前端相关 skill 需求量最大。设计稿还原、组件代码生成、样式调试都能做成 skill。这类技能胜在闭环清晰输入是图片或 Figma 链接输出是 HTML/CSS验收标准肉眼可见。团队里只要有人积累了一套成熟的“前端规范型 skill”新人上手前端开发的速度会快很多。社区里不少项目已经把“设计稿转页面”做成了完整的技能包建议直接拿现成的改。5.2 学术研究、数学建模这类“流程型”技能潜力很大数学建模 skill 和 academic research skill 属于典型的流程型技能。它们的特点是没有很强的代码闭环但对推理步骤要求高。比如学术研究 skill 会把“查找文献→筛选质量→摘要提取→格式化引用”串成固定流程数学建模 skill 则会约束模型“先清洗数据再建模先做探索性分析再下结论”。这类技能的价值不在于帮模型“自动完成”而在于约束模型不要跳步。对于学生和研究人员来说相当于把一位导师的工作习惯复制给了 Agent。吴恩达的 agent skills 教程在社区里流传也比较广核心思路就是把复杂任务拆成技能集合并串联起来使用和这里的逻辑一致。5.3 如何挑选社区里的现成 Skills现在 GitHub、Substack、付费社区里到处是 skills 合集但质量参差不齐。我选技能包的核心标准有四个一看 README 和 SKILL.md 是否写清楚适用场景二看是否声明了外部依赖三看附件目录是否真的有内容很多“干货”只有一个空壳四看有没有示例输出。如果一个 skill 连“什么时候不该用”都没写我基本不会用。这跟选开源库的直觉是一样的约束透明、边界清晰才值得信任。5.4 个人选型心得最后分享一点个人体会。我在团队里推广 skills 快两个月最大的收获不是“AI 写代码更准了”而是团队的隐性经验终于有了承载形式。以前前端规范散落在群里、文档里、老同事脑子里现在沉淀成 skill 之后谁用 Agent 都是同一套标准。踩过最大的坑是“一次性写太复杂”总想把所有场景都覆盖结果技能包越写越大模型反而不知道该听哪条。后来我改成小步快跑先写执行主链路再逐步加附件、加边界条件、加异常分支。这个思路应该也适合你现在准备做的第一个技能。