如果你最近在关注AI编程圈一定被Skills这个词刷屏了。GitHub上随便一搜就是一堆skills仓库Claude Code、Codex、Cursor这些主流工具也都把原生支持skills当成重要更新朋友圈里还有人晒用一套skills把前端需求从“一天一版”压缩到“一小时一版”。这种热度确实像2026年AI工具链里最值得学的东西。但很多人的第一反应是Skills和Agent到底啥关系一个叫“技能”一个叫“智能体”听着像同一件事的两种叫法真用起来却完全是两层东西。我在不少技术群里看到有人把“给Agent写提示词”和“配置Skills”混着说结果调了一下午效果就是不对。这篇文章不搞玄学我把什么是Skills、怎么和Agent分工再到怎么挑、怎么写、怎么装、怎么排一条线讲透。先说明白“100倍”不是玄学它只发生在那些重复、流程化、知识密集的环节里方法对路之后这些环节的耗时压缩一到两个数量级完全可能。适合两类人看一类是天天被新概念刷屏、想搞清楚底层逻辑的技术人另一类是已经在用Claude Code、Codex、Cursor想让工具真正替自己干活的人。1. Skills到底是什么为什么身边人都在聊1.1 一句话定义Skills就是AI的“岗位说明书”Skills技能在AI Agent语境下的定义其实很朴素一份把某个专业工作流固化成文档形式的知识包。它通常以SKILL.md为核心文件里面写清楚这项技能适用于什么场景、执行时按什么步骤来、产出要符合什么规范、最好再附上一两个示例。你可以把它理解成给AI雇员的一份“岗位说明书”——新人入职时你不会指望他凭空知道“发版前要检查哪些东西”而是会给他一张清单SKILL.md干的就是这件事。这份岗位说明书不是给人看的而是给模型看的。模型在对话中判断当前任务适合调用哪个技能时会先读技能的description字段匹配上了再加载完整内容。所以现在业界的做法往往是一个技能文件夹里除了SKILL.md还可以带脚本、模板、参考代码、甚至子目录。比如前端开发skills可能包含一个生成组件模板的脚本一个读取设计稿的说明文档数学建模用的skills可能带一套数据清洗脚本和出图配置。把可执行的知识和文件打包在一起这也让skills天然比纯提示词更适合工程化。1.2 从“提示词”到“技能”这一步到底进步在哪如果你用过AI编码大概率经历过这样的阶段最早我们把一大段prompt复制进对话框让模型扮演前端专家、数据分析师每次都要复制粘贴改一处规则还得全文找替换效果还不稳定。后来有了system prompt和rules文件总算不用每次复制了但rules通常是“全局生效”的——你的所有对话都背着一大堆背景知识上下文窗口被无关内容白白占掉。Skills的出现改变了这个局面。它把知识拆成一个个可按需加载的模块模型遇到“帮我生成一个Vue表单组件”的需求时会主动去加载对应的前端组件skill遇到“写一段SQL做数据去重”的时候才去加载数据处理skill。没被触发的时候这个技能几乎不占上下文。换句话说Skills解决的不是“提示词写得好不好”而是“工具如何组织知识、如何分配注意力”的问题。这一点是它和传统提示词工程本质上的不同也是它能在2026年这个时间点集中爆发的原因模型的理解和编码能力到了一定水平之后大家的竞争焦点开始从“模型聪明不聪明”转向“你给模型准备了什么样的工作环境”。实际上最近各家的更新都在朝这个方向靠。Claude Code把Skills作为原生能力推广Codex、OpenCode、Cursor也在用类似规格跟进连pi agent、hermes agent这类开源智能体项目都把skills当成自己的核心能力单元。GitHub上以“superpower skills”为代表的一系列第三方技能包也越来越完善。可以说2026年如果你还在用“裸奔”的模型就等于让一个高材生在没有SOP、没有工具库的公司里工作——上限再高也会被组织方式拖累。2. Skills和Agent到底差在哪一次说清2.1 一个是“知识包”一个是“执行者”很多人混淆Skills和Agent是因为它们都在“让AI变得更专业”这件事上起作用。但两者的本质差异非常明显Skills是一个静态资产它不会自己去调用工具不会主动执行步骤更不会因为你一时兴起就扩大任务范围。它躺在那里等着被某个执行体读取。Agent则是那个执行体——它有目标、有计划、能循环调用工具、能在出错后调整策略甚至能维护自己的记忆状态。举一个类比你就明白了。把Agent当成一个实习生Skills就是他工位上那本《工作手册》。手册写得再详细没有实习生去翻阅和执行它也只是印着字的纸而实习生再聪明没有手册指导他做事的质量和稳定性就取决于临场发挥。在AI工作流里大模型本身是那个实习生skills是手册agent则是“实习生手册主管指令”的组合体——它知道什么时候该翻哪本手册也知道翻完之后要产出什么结果并且自己检查一遍。还有人在问harness和agent的区别那属于更细的编排层概念但无论怎么细分skills作为“被调用的知识资产”这个位置不会变。2.2 两者协作起来才是完整的工作流搞清楚了区别再看协作就顺了。一个完整的工作流通常长这样用户提出目标agent先规划规划过程中判断当前阶段需要哪个技能于是去加载对应的SKILL.md按里面的步骤执行或生成内容然后根据结果决定下一步。这个循环里agent负责“大脑”和“手脚”skills负责“肌肉记忆”。换句话说Agent解决的是“做什么、下一步干什么”Skills解决的是“具体怎么干、干到什么标准才收手”。缺了任何一层另一层都很难独立工作。我记得吴恩达在agent课程里反复讲过一个观点工作流、工具调用、自我反思是Agent能力提升的三大杠杆。Skills正是“工具调用”和“工作流”的最佳载体。没有skills的agent面对“生成一份数据分析报告”这种任务只会泛泛地写一段Markdown图表、格式、结论全靠模型临场发挥接了数据分析skills的agent会严格走“读数据→清洗→出图→写结论→按模板排版”的流程每一步输出都有标准。所以严格说Skills不是Agent的下位替代而是Agent的零部件二者配合才谈得上真正可控的生产力。2.3 一张对照表快速判断你缺的是哪个很多朋友问我我到底应该去开发skills还是去做agent这个问题本身问得有点跑偏因为它默认了两者是二选一的对立关系。但从我接触的项目来看绝大多数情况两者是叠着用的你需要一个稳定的执行体也需要一套高质量的知识包。做判断时你只需要看自己的痛点在哪个环节再决定优先补什么。为了方便对照我直接把两个概念拆成一张表你可以对着手头的项目来判断。对比维度SkillsAgent本质静态知识/技能包动态执行体核心载体SKILL.md及配套脚本、模板规划循环工具调用记忆是否能自主行动不能等待被调用能自主规划并逐步执行作用范围单点专业任务端到端目标上下文占用仅在调用时加载平时近乎为零需要持续占用维持状态和规划更新方式改文档、改脚本改工作流、改工具配置、改提示典型问题“这个技能怎么让模型识别何时使用”“这个任务怎么不让Agent跑偏”判断逻辑也很简单如果你的痛点是“AI做某类具体事情质量不稳定、步骤不固定”你缺的是Skills如果你的痛点是“AI无法把一个多步骤目标完整推进、不会用工具、不会自我纠错”你缺的是Agent能力。多数情况下先把前者补齐后者的问题会好解决一半。3. 真正提升效率的4个关键点逐个拆3.1 关键点一会挑Skills别让“技能满库”拖垮Agent先说第一个关键点也是最容易踩坑的挑Skills的品味。GitHub上skills仓库多到翻不完随手一搜就是几百个很多人看着这个也好、那个也强一股脑装了三十几个。结果呢agent每次做决定前要在几十个description里做匹配轻则决策变慢重则匹配错技能把数据分析的流程套到代码生成上。我发现一个规律真正用得顺的配置往往是“少而准”保持在5到10个核心技能之间。怎么挑我一般看四个维度一看description写得清不清楚——如果连描述都含糊说明作者没想明白这个技能什么时候该被触发二看示例文件是否具体——好的技能一定带可运行的示例而不是空转的文档三看依赖是否克制——一个前端skills如果要求安装一堆npm包你得评估自己环境接不接受四看维护时间——更新日期在一年以外的通常已经跟不上工具版本。再补一句前端开发skills、数学建模skills这类方向社区里成熟度最高适合新手从这些领域入手。3.2 关键点二会写Skills把重复劳动固化成资产光会挑还不够真正让你效率拉开差距的是会写。写一个可用的SKILL.md流程比想象中简单但细节决定成败。第一步确定名字要求是“看到就知道用途”比如generate_vue_form而不是前端这种大而全的词。第二步写description这决定了模型什么时候匹配它要把触发场景写具体比如“当用户要求创建Vue2/Vue3表单组件、字段较少且需要统一风格时使用”。第三步写核心步骤按顺序列出模型必须执行的操作尽量给判断分支比如“如果数据来源是数据库先执行schema检查”。第四步给输出规范和示例这是新人最容易忽略的示例的存在能让模型少走很多弯路。我特别想提醒一点一个技能只干一件事。有人喜欢写一个“全能技能”里面既管代码生成、又管测试、还管部署看起来省事实际上模型很难在长文档里精准定位当前该执行哪段。这就像给实习生一份八十页的手册他反而不知道怎么干活。我自己写的时候习惯把大流程拆成几个小技能比如“代码生成”一个“测试补全”一个“部署检查”一个然后让agent按顺序调用。每个技能控制在二十到五十行核心指令满载示例。记住它是“技能”不是“部门制度”。3.3 关键点三会装Skills让工具真正认账写好的skills不能直接复制到对话里要装到工具认账的位置Claude Code才能自动识别。新手在这个环节最容易蒙圈因为不同工具的目录不一样。以Claude Code为例全局生效的技能要放在~/.claude/skills/技能名/SKILL.mdWindows是%USERPROFILE%\.claude\skills项目级生效的放在你项目根目录的.claude/skills/技能名/SKILL.md。装完后在会话里输入/skills命令能看到已经加载的技能列表确认你的技能出现在里面才算真正“认账”。我见过不少人把SKILL.md放在桌面然后问为什么模型不理他。记住它不是给模型发个文件路径就完事的是要落到约定目录、遵循约定结构模型才会在需要时去扫描和读取。如果你用的是Cursor情况也类似它有一套以.cursor/skills为主的技能目录同时Cursor官方也推荐把通用规则写在.cursor/rules里两种方式的适用范围有区别rules更偏向全局行为约束skills更偏向任务能力注入。具体的安装对比我在下一章用一整节来讲。3.4 关键点四会排Skills让Agent编排而不是乱撞最后一个关键点是“排”——编排。Skills开发得再好如果agent没有清晰的调用顺序和终止条件过程中很容易跑偏。所谓编排就是在你的工作流层面提前想好用户一句话进来agent先调哪个技能、再调哪个技能、什么时候算完成。这部分可以把一部分逻辑写进SKILL.md的前置条件里也可以在system prompt里告诉agent“先读取技能清单匹配后再行动”。这部分看起来偏“方法论”但实际踩坑时编排问题比技能质量问题更常见。举个我实际用过的例子。有次帮朋友准备数学建模比赛的赛题分析我用的是一套“数学建模skills”赛题理解、数据清洗、可视化出图、论文提纲生成四个技能。我把它们装好之后没有让agent自由发挥而是给了它一个明确的编排指令先调赛题理解输出题目拆解和假设再调数据清洗处理缺失值然后调可视化技能产出三张探索性图表最后调论文提纲技能把结论和图表组织成初稿。结果相当稳定从读题到出初稿大约四十分钟。而以前不排流程的时候模型可能会先画图再看题做出来的东西七零八落最后还得返工。这段经历说明一个道理技能是积木编排才是建筑图纸图纸没画好再好的积木也只能搭出歪房子。4. 实操从Claude Code到Cursor的Skills安装全流程4.1 Claude Code手动装GitHub上的Skills七步搞定前面三章偏理念和策略有人可能觉得不过瘾那这里开始就是能直接复制进终端的操作了。我以“从GitHub手动安装一个skills到Claude Code”为例把过程拆成七步几乎是照着敲一遍就能跑通的程度。需要说明的是这条流程在macOS和Linux下直接可用Windows用户把路径中的~换成%USERPROFILE%即可。先在你的GitHub上搜索目标技能仓库关键词可以组合claude skills、awesome-claude-skills这类列表里能挖到不少好东西。找到之后把仓库clone到本地临时目录比如git clone 仓库地址。进入仓库找到包含SKILL.md的文件夹。有的仓库一个项目就是一个技能有的仓库是多个技能的集合注意看目录结构别把整个仓库当单个技能装进去。确认该文件夹的结构至少要有SKILL.md可以附带scripts、assets等子目录。如果不满足看看作者有没有提供构建脚本或说明。打开终端创建目标目录mkdir -p ~/.claude/skills/技能名。如果是项目级就换成项目的.claude/skills目录。把整个技能文件夹复制过去命令类似cp -r ./技能文件夹 ~/.claude/skills/技能名/。文件夹名字最好不要带空格和特殊符号最好全小写加下划线。重启Claude Code或者在会话里输入/skills刷新并查看技能列表。此时你应该能看到该技能出现在可用列表里。做一个冒烟测试直接用一句能触发该技能的话去调用它比如“帮我用这个技能处理一个测试样例”观察输出是否符合预期。如果毫无反应回头检查description是否写清触发动机或者技能目录名是否和文件夹内技能name字段对得上。这套流程看起来啰嗦实际熟练之后两分钟就能装完。关键点是第2步和第7步一个是找对目录一个是验证有效。很多“装了没反应”的问题九成出在这两步。如果你是一次装多个技能建议每次只装一个并测试混着装会让排查成本翻倍别问我怎么知道的。4.2 Codex、OpenCode、Cursor的Skills配置对比Claude Code不是唯一支持skills的工具。现在各家几乎都在对齐同一套“目录SKILL.md”的约定但具体路径有差异。我把主流工具的配置位置和特点整理成一个对照表方便你换工具时不用重新学一遍。工具用户级技能目录项目级技能目录主要特点Claude Code~/.claude/skills.claude/skills支持/skills查看description驱动Codex~/.codex/skills.codex/skills与AGENTS.md结合可在项目级预置OpenCode全局配置目录下skills项目根目录skills/开源支持社区provider的插件式技能Cursor~/.cursor/skills.cursor/skills常与.cursor/rules配合rules管行为、skills管能力这里的“用户级”意思是不管你在哪个项目里工具都能认得这个技能“项目级”意思是只在这个项目里生效。如果你改了一个技术栈或者换了个新项目项目级技能能保证AI不把上一个项目的习惯带过来。别小看这个区别我在多项目切换时用项目级技能确实避免了模型各种“串味”——在Python项目里突然按前端思路生成代码这种事少了很多。Codex用户要注意一点它除了看skills目录还会读取项目根目录的AGENTS.md里面有关于“如何组织代码、有哪些约定”的说明。这两者配合相当于你既给了模型工作规则又给了它专业技能。OpenCode因为是开源的skill市场生态比较活社区里有不少现成配置可以直接拉。Cursor的玩法相对灵活我建议新手先只用一个目录别同时写rules和skills等跑通了再加。4.3 可以直接抄走的SKILL.md模板如果你看完上面的介绍还是不知道SKILL.md长什么样这个模板可以直接抄。我拿“代码提交前自查”这个日常场景举例它既简单又高频适合当你的第一个练手技能。写完按4.1的方式装进去就能用前五分钟就能看到效果。--- name: review_before_commit description: 在代码提交前执行自查检查未提交文件、调试残留、密钥泄露风险和测试状态并生成提交信息。当用户说“帮我review代码”“准备提交”“提交前检查”时使用。 allowed-tools: - bash - read - grep --- # 代码提交前自查 ## 背景 代码评审时经常因为格式问题、漏测、提交信息不规范被打回。本技能把检查清单固化为可执行流程适用于所有提交前场景。 ## 执行步骤 1. 查看当前工作区状态列出修改和新增文件。 2. 逐文件检查是否存在以下残留TODO、debugger、console.log、硬编码密钥。 3. 运行测试命令或静态检查记录失败项。 4. 根据变更内容生成一条符合规范的提交信息。 ## 输出格式 按表格输出检查结果 | 检查项 | 状态(PASS/FAIL/WARN) | 说明 | | --- | --- | --- | ## 示例 变更修复登录接口空指针异常新增JWT过期判断。 输出检查项工作区状态状态PASS说明共3个文件变更检查项密钥残留状态WARN说明配置文件中发现疑似测试密钥建议移除。保存为review_before_commit/SKILL.md之后装好然后触发一次。注意模板里的description写得越具体模型匹配的准确率越高allowed-tools字段则用来限制技能执行时能使用的工具推荐按最小权限原则写只写必要项避免技能失控胡来。如果你今天只想做一件事我建议就把这个技能建起来它会让你每次提交代码时的“最后一步”变得非常省心。5. 推荐清单、常见报错与维护建议5.1 值得先收藏的Skills方向前端、数学建模、日常装技能的品味体现在选择方向上。我自己的经验是从这三类开始不会错。第一类是前端开发相关比如组件自动生成、设计稿转页面、样式一致性检查、原型转响应式布局。前端开发skills之所以成熟是因为任务边界清晰、输入输出结构稳定模型的代码能力又能最大化发挥。我身边用Cursor和Claude Code做前端的小伙伴装上这类skills之后体感提升最明显的是“UI琐事”耗时比如表单校验、表格分页、状态管理样板代码以前一个上午现在基本是几分钟的事。第二类是数学建模和数据分析相关。赛题理解、数据清洗、统计检验、可视化出图、论文提纲生成这些技能几乎是为模型“量身定做”的。数学建模skills特别适合准备竞赛的同学我前文提到的那个四技能组合基本可以覆盖赛题处理的主流程。建议新手先收集数据清洗和出图这两个因为它们通用性最强日常分析也能用等比赛临近再补赛题拆解和提纲技能。第三类是日常效率类像提交信息生成、代码Review、SQL优化、会议纪要整理、邮件回复草稿这些技能不挑项目、不挑技术栈装上就能提高每天的产出。寻找来源方面我目前用得最多的入口有三个一是GitHub直接搜索skills加工具名按stars排序二是像awesome-claude-skills这类汇总列表里面按用途分好了类三是社区化的skills市场比如不少人在用的skillsmp可以直接浏览和复制配置省去自己clone的麻烦。需要提醒的是任何来源的技能拿到手都先浏览一遍SKILL.md再装别用“人肉盲装”因为你不知道里面到底写了什么。5.2 高频报错“agent execution terminated due to error”排查实录聊完怎么装来说说最让人头疼的问题。不少朋友在跑skills和agent组合的时候都会碰到一句让人血压升高的报错agent execution terminated due to error.。这句话本身非常笼统它的意思是agent在执行过程中遇到了致命错误被终止了但具体是什么错得往上报错堆栈里找。我总结了几种最常见的原因按出现频率排序。第一是上下文爆掉。尤其当某个skills附带了很长的模板、示例或历史记录加上agent循环之后上下文窗口一满就崩。解决思路是用更精简的技能文档、减少对话历史、或者把长文本拆到文件里按需读取。第二是依赖工具缺失。skills里写了运行测试、执行脚本但环境里要么没装脚本解释器要么路径不对。解决思路是检查allowed-tools声明与实际命令是否匹配再看终端环境能不能直接执行那些命令很多skills对bash脚本路径有默认假设换个系统就不认了。第三是权限不足技能要写文件结果目录是只读的直接报错。第四是递归过深agent反复调用同一个技能或者两个技能互相触发形成死循环被运行框架拦截。排查时别慌按三步走能解决大部分问题先看完整的错误堆栈定位是在哪个步骤炸的再把问题缩小临时注释掉SKILL.md里最可疑的步骤或者拆掉一半指令跑最小案例最后加日志或打开工具的debug模式观察agent在调用技能前后的输出变化。很多情况下把单个skills从“全能”改成“专注一个任务”问题就自然消退了——这也从反面印证了前面说的“一技一事”。5.3 安全与维护别把“家底”写进Skills最后必须提醒安全与维护这是最容易忽视的部分。Skills本身是明文的Markdown和脚本任何能运行你的工具、能触发agent的人都能看到里面的内容。所以切记不要把API密钥、数据库连接串、内部服务器的真实地址写进SKILL.md或附带脚本里。更隐蔽的风险是提示词注入如果agent在处理外部内容时发现网页或文件里的指令与技能文档冲突可能被恶意引导。我建议对skills做最小权限声明allowed-tools只给必要工具同时定期审查你安装的第三方技能尤其是那些来路不明的“一键性能提升包”。维护层面我现在的做法是给自己建的技能库做版本管理每个SKILL.md都记录更新日期改过之后在文档顶部source里写一句变更说明。每次工具大版本升级我会抽时间把常用技能过一遍看描述是否还匹配新工具的行为。最近社区里对agent安全也越来越重视像a-memguard这类针对LLM Agent记忆的防御框架也已经出现这说明“给agent加技能给系统开门”的风险链路正在被认真对待。一个原则记清楚技能的边界就是安全的边界。6. 写在最后我现在的skill工作流长什么样写到这里该聊点真实的。我现在的日常开发工作流里用的技能其实不多长期保持的只有六个左右前端组件生成的、代码审查的、提交信息整理的、数据库查询优化的、数据清洗出图的、每周总结生成的。每个技能都只干一件事每个技能我都亲手改过至少两版。刚开始我自己也被“技能越多越好”骗过装到过二十几个最后真正高频用的只剩这几个其余的全都归档了。效率数字我不爱吹但有个对比很直观以前给新项目搭前端表单模块从写组件、配校验、调样式到自测正常要半天左右现在我用一个组装好的前端skills配合Claude Code的agent跑一遍先把组件结构生成出来再由我人工过一遍样式细节一般四十到五十分钟能收工。这不是“AI代替我写代码”而是“我把重复劳动的方法固化成了技能让模型按我的标准执行”。这个体验比看任何抽象的“效率提升”帖子都实在。最后分享一个小技巧每次你觉得一个任务“我好像总在做同样的事情”就是该给它写个skills的信号。先别追求完美把最核心的步骤列出来让模型先跑通后面根据失败案例慢慢加边界条件。技能库是你的不是别人的别人那几百个star的技能包再炫不如你自己写的那份“只属于你业务的SKILL.md”好用。