最近这几个月不管是技术群还是行业朋友圈大家不约而同都在聊一个新词AI skills。我观察到的规律很一致最早拼的是谁提示词写得好后来拼的是谁的上下文管理更细现在拼法又变了——“我手头上攒了多少个能直接投入生产的skills”。不管是拿Claude Code跑前端项目还是用Codex处理数学建模比赛里的数据又或者靠AI漫剧做批量内容最后都会绕到同一个问题这个活儿能不能沉淀成一个固定可复用的skill。我的答案是能而且这件事本身就是今年最值得花时间投入的方向之一。这篇文章我把从零摸skills的完整路线讲一遍包括它到底是个什么、怎么找、怎么选、怎么装、怎么写以及我在真实项目里踩过的那些坑。1. 先搞明白AI助手里的skills到底是个什么东西先说个最简单的定义。skills在AI Agent语境里就是一套写给模型看的、结构化的操作说明书。它不是普通prompt不是临时问一句的提示词而是有目录、有内容、有约束条件的规范文档。模型在接收到用户指令时会检索有没有相关的skill可以用如果有就按skill里的要求去执行动作。你可以把它理解成做菜的菜谱而不是菜名。你说“给我做一道宫保鸡丁”模型可能做得乱七八糟你给它一本菜谱上面写着食材清单、火候大小、下锅顺序、判断标准它做出来的东西就有基本保障。一个标准skill通常包含两个核心要素一是SKILL.md这个主文件里面写了技能的目标、适用范围、执行步骤、输出规范二是可选的一组辅助资源比如脚本、模板、参考文档、配置文件。主文件负责“告诉模型做什么、怎么做”辅助资源负责“提供现成的素材和工具”。这个结构几乎已经成为各家Agent工具的通用约定所以同一个skill可以在不同工具之间迁移前提是路径和配置方式一致。那它和普通prompt的本质区别在哪里普通prompt是“一次性沟通”你每次都得重新描述需求、重新交代背景、重新规定输出格式而且换一个话题就全作废。skill则是“资产沉淀”你把最常用、最成熟的工作流固化下来下次遇到同类任务模型自己会去调用你不用再啰嗦。我自己的体感是一个打磨好的skill能让重复性任务的产出质量稳定上一个台阶因为它把高手的工作习惯、踩坑结论、输出模板全部封进了文件里。为什么这个东西在2025年开始集中爆发核心原因是Agent的应用方式变了。以前模型是“问答器”你问一句它答一句现在模型是“执行器”它会规划、调用工具、写代码、操作文件。执行器最怕的是什么是每一步都凭着“感觉”来。而skill正好解决了这个问题它给执行器一套确定的行动指南让它在面对同类问题时不必每次重新发明一遍轮子。越是复杂工具链越需要这种标准化约束。另外需要注意skills不等于插件也不等于MCP。插件往往绑定特定平台的能力扩展MCP解决的是外部系统连接而skill本质上是纯文档规范重点约束模型自身的行为方式。搞懂这个定位后面找资源、写skill的时候就不会跑偏。2. 为什么值得花时间搞skills——从“勉强能用”到“真正能打”很多人一开始会质疑我直接用自然语言把需求说清楚不就完了吗为什么非要搞一套skill体系这个问题我当初也问过自己直到连续吃了好几次亏才明白。第一个亏是输出不稳。同一个任务今天给的结果格式漂亮、结构完整明天就给你交一份逻辑跳脱的初稿。为什么因为模型每次的推理路径都有随机性你的prompt如果不够明确它就在各种方式之间摇摆。skill的本质就是把这个随机性压下去把关键步骤、关键判断点全部固定住让模型只能在一个限定范围内发挥。第二个亏是成本太高。我一度在每次做数据分析前都要把同样的背景信息、同样的处理流程重新粘贴一遍。上下文一长注意力就开始漂移经常前面对了后面错了。把整套流程固化成skill之后相当于把那些背景和流程提取成了稳定模块模型的注意力可以全部集中在当前数据上。第三个亏是协作困难。团队里几个人同时用同一个Agent工具每个人都有自己的“祖传提示词”互相之间没法复用也不便于评审优化。skill则是一种可评审、可版本管理、可共享的资产Git仓库一放谁都能看到改了什么东西这对团队协作的价值非常大。很多社区项目干脆把成体系的skill集合称做“superpower skills”意思就是给Agent装上超级外挂。这类大礼包的思路很直接不再追求单个prompt的巧妙而是打包了几十个不同场景的高质量skill从需求分析到代码评审从数据库建模到前端调试Agent只要在对应场景启动对应skill立刻进入专家状态。我自己的体验是这种组合拳用习惯之后再回头跟模型裸聊会感觉效率落差特别明显。不同岗位对skills的需求差异也很大。前端开发者需要的可能是UI生成、代码review、性能排查这一类技能搞数学建模的人更需要数据清洗、算法设计、论文排版这一条龙做AI漫剧的人则更关注分镜脚本、角色一致性描述、镜头语言控制。所以不存在一套万能skills关键是找到你业务场景里最高频、最消耗精力的那几件事把它沉淀下来。最后说一点学习路径上的经验。不要一开始就追求自己写skill也不用看到几千星的skill合集就全部装上。正确顺序是先熟练使用别人写好的把优秀skill的结构、写法、粒度都看明白然后再从自己的痛点里挑一个小而高频的场景从头写一个试一遍。通了之后再慢慢扩大形成自己的技能库。3. 从哪找、怎么选——skills资源与甄别方法很多人第一次接触skills时最大的困扰不是不会写而是不知道去哪找。GitHub是最主要的集散地但直接搜索的时候会被海量项目淹没。我自己的经验是先认准几个公认的元仓库然后再顺着它们的收录列表去发掘。社区里比较有价值的通常是两类一类是官方出品的示例仓库里面有各种真实场景的skill案例因为是一线维护格式最规范注释也最清楚另一类是社区定期整理的awesome列表专门收录高质量的skills资源相当于一个技能集市的索引。这类列表的好处是已经有人帮你筛过一轮分类也很清晰按前端、后端、数据处理、内容创作、编程辅助等维度排列基本能做到按需取用。搜索技巧方面直接搜“awesome agent skills”“skills 集合”“SKILL.md”这些关键词比搜“AI skills”更精准。因为现在“AI skill”这个词被很多概念混用搜出来的东西太杂。另外GitHub的星级只能作为参考线我见过不少star很高的项目实际装进去之后各种水土不服也见过藏在冷门仓库里的好skill写法干净利落一用就爱不释手。更靠谱的判断标准就三条一是结构是否规范删了辅助文件也能通过SKILL.md把事说明白二是描述是否精确能不能清楚界定什么场景用、什么场景不用三是例子是否充分有没有给模型可参考的输入输出对。具体到场景选型上我更建议直接搜场景关键词而不是泛泛地找。比如你做前端就搜“前端开发skills”“React skill”“代码审查skill”你要参加数学建模竞赛就搜“数学建模skills”“codex skills 数据分析”你做AI漫剧就搜“分镜脚本skill”“AI漫剧工作流”。针对场景找出来的skill往往比大而全的合集更贴近实际需求。还需要特别留意兼容性问题。AI产品迭代速度快skills的规范也一直在调整你现在下载的skill可能是几个月前写的字段格式、触发方式可能已经变化。所以选定之后最好先看两个东西一是README里有没有写适配版本二是最近有没有更新提交。如果项目已经一年多没动静又不在官方兼容列表里风险会有点高。挑选时还有个小技巧先看辅助资源的文件结构再判断这个skill的复杂度合不合适。一个真正好用的skill不会把所有逻辑都塞在一份SKILL.md里它通常会拆分成几个子任务把常用模板、验证脚本、示例数据放在独立文件里。如果你看到的SKILL.md长达两千行那基本是设计上偷懒了维护成本会很高。4. 手动安装GitHub上的skills——Claude Code实操记录现在很多工具都集成了skills的一键安装功能点个按钮就能装好。但实际情况往往没这么理想有些优秀的skill藏在插件的底层包里没有独立入口有些是刚发布的新版本还没上集成清单还有些你只想要其中某一个技能没必要装整个合集。这时候手动安装就是必备技能。我先以Claude Code为例把完整操作过程拆细一点。手动安装的底层逻辑很简单把skill文件放到工具能扫描到的目录里让它在启动时能发现你新加的技能。Claude Code有两层目录结构一层是用户级目录对所有项目生效一层是项目级目录只对当前项目生效。用户级的默认路径是~/.claude/skills项目级的是你项目根目录下的.claude/skills。如果你是个人使用装到用户级最省事如果是团队协作建议放项目级这样仓库克隆下来每个成员都能共享同一套技能配置。操作上我习惯直接打开终端。第一步先建立目标目录然后进到目录里再用git clone把GitHub仓库拉下来。比如你在GitHub上看到了一个整理好的skill包包名是某个技能的名称那么大概的命令是这样mkdir -p ~/.claude/skills cd ~/.claude/skills git clone https://github.com/example/some-skill.git拉下来后要做一步检查确认目录结构符合要求。规范的skill根目录里应该直接放SKILL.md下面可以带辅助文件夹。如果clone下来发现外面还包了一层同名目录比如some-skill/some-skill/SKILL.md那就要把内层目录挪出来让SKILL.md直接位于~/.claude/skills/对应技能名/SKILL.md。这个细节很多人会忽略结果装完发现工具根本识别不到。如果你只想装某个大仓库里的单个skill不需要把整个仓库都clone下来可以考虑用GitHub的“Download directory”或者是手动点击文件页面的下载链接也可以只做sparse checkout。小体积的仓库直接下载zip解压反而更省事cd ~/.claude/skills wget https://github.com/example/some-skill/archive/refs/heads/main.zip unzip main.zip mv some-skill-main some-skill rm main.zip文件放好之后验证安装是否成功的办法很简单直接在当前项目里开一个会话跟工具确认一下它能列出多少已加载的技能再用一句话简要描述这个skill的功能问它是否识别。如果列得出来说明路径和结构都没问题。这里有一个我反复踩过的坑Linux或macOS环境下某些带辅助脚本的skill脚本文件没有可执行权限导致模型调用时直接报错。这种问题一眼很难看出来因为看起来文件都在。处理方法是在装完以后对目录下所有脚本文件统一加一下执行权限chmod -R x ~/.claude/skills不过这里要提醒一下chmod加权限要适度不要对整个系统目录瞎加。另外还有个容易忽略的点如果SKILL.md文件名的大小写不对或者不小心存成了skill.md、SKILL.MD工具也会识别不到。命名这个东西看着细出了问题却最妖。装完也不要急着高兴最好做一轮实际功能测试直接分配一个真实小任务给这个skill观察输出是否符合预期。如果行为异常先查辅助文件路径引用的对不对再查内容格式有没有过期语法。安装这件事本质上就是路径、结构、权限三步谁在这三步上马虎谁就会在后续使用里跑来跑去地填坑。5. 从零写一个自己的AI skill——AI skills到底怎么写把别人写好的skill用熟练之后你大概率会产生一个念头我也要写一个自己的。这个念头非常值得鼓励因为写skill的过程其实就是你把自己脑子里那些“只可意会不可言传”的经验变成结构化文档的过程。先看一个最小的skill样子。它本质就是一个SKILL.md文件头部是YAML格式的元信息写名称和描述下面是正文写具体步骤和规则。我随手写过的前端代码审查类skill结构大致是这样--- name: frontend-code-review description: 用于审查前端代码变更重点检查组件拆分、渲染性能、状态管理合理性和可维护性 --- # 前端代码审查规范 先读取变更内容按以下维度逐项审查 1. 组件职责是否单一拆分粒度过粗或过细都给出建议 2. 渲染逻辑有无明显性能隐患例如循环内重复创建对象 3. 状态管理是否合理跨组件共享的状态是否有必要提升 4. 样式方案是否可维护是否有硬编码魔法值 5. 根据审查结果按照“问题描述-影响范围-修改建议-参考代码”的格式输出 注意事项 - 若变更内容低于50行可直接输出结论超过50行先给出总体评价再逐项列问题 - 所有建议必须给出具体代码示例不得只说“建议优化” - 如果发现紧急安全风险标题需要加【阻断】前缀写这种文件的核心原则就是“具体、可执行、有边界”。你写的每一条规则都必须是模型能够直接执行的指令不能是抽象口号。比如你说“注意代码质量”模型不知道怎么落地你说“循环内不允许重复创建对象”模型就知道该怎么找问题。这和带新人是一个道理你说得越清楚对方做出来的东西越接近你的预期。再扩展一步如果你希望skill承载更复杂的业务逻辑可以用辅助脚本来配合。比如写一个数学建模数据预处理的skillSKILL.md负责描述整个流程数据清洗脚本、统计检验脚本、图表示例模板放在assets目录里模型在执行时可以调用这些脚本直接完成任务。这种组合形态才是skills真正的威力所在它不再只是告诉模型“该怎么做”还给了模型“做这件事需要的工具”。写的过程中有几个关键注意点。第一描述要设置边界尽量清晰写明“什么时候不该用这个skill”。因为模型调用skill的依据就是描述文本如果描述写得太宽泛它可能在不需要的时候强行套用反而帮倒忙。第二内部步骤的编号要清晰最好和输出格式强关联这样模型才知道先做什么后做什么。第三一定要写示例给几个输入输出的样例模型模仿样例比理解抽象规则要容易得多。我自己的调试方法是“喂case法”写完一个skill就找几个真实任务去跑看它哪个环节的行为和预期不一致然后回头改文档。这里有个技巧不要追求一次跑完美一开始只覆盖最核心的路径等稳定了再逐渐增加边缘情况。我在最初写skill时就是太贪心一口气写了几十条规则结果模型每步都在纠结该按哪条规则走反而拖慢执行。后来砍掉一半只保留最高频、最有价值的约束效果立竿见影。还有一个容易忽略的点skill之间是可以引用嵌套的。一个大的业务链路可以拆成几个skill然后在一个总控skill里调用它们。比如一个“建模比赛全流程”skill可以细分成“数据探索skill”“特征工程skill”“模型对比skill”“论文排版skill”之间通过统一的文件命名进行衔接。这个设计能有效降低单个skill的复杂度也方便单独维护和复用。6. 场景化实战配置自己的skills工具箱知道怎么写还得知道怎么用。实战中最有价值的不是某一个孤立的skill而是一套能覆盖完整业务链路的skills组合。我拿三个最常见的场景来拆解一下。先看数学建模。这类竞赛时间紧、节奏快、产出物多从题目理解到最后论文交付每个环节都适合用skill来约束。一个典型的建模流程可以拆成四到五个skill数据探索阶段用统计描述加可视化来快速理解数据特征工程阶段做缺失值处理、异常值检测、标准化建模阶段要能快速跑通几种经典算法并对比效果论文阶段则需要统一的排版规范和图表输出风格。把这些skill串起来之后相当于给整个参赛团队配了一个标准化流水线每个人只需要按流程执行结果的稳定性会明显提高。我自己见过不少团队代码写得好论文排版稀烂最后得分反而不如代码一般但论文规范的队伍这种情况在技能配置里完全是可以提前规避的。再看前端开发。高频场景通常是新页面生成、代码审查、性能优化、Bug定位。我建议的前端基础组合是一套“生成审查修复”的闭环页面生成skill负责搭出整体骨架和交互逻辑代码审查skill把上一环节的质量漏洞筛出来性能优化skill专门处理渲染、打包、请求这一类典型问题。动手配置时其实不需要从零造轮子很多现成模板可以改造主要改的是你团队的代码风格约定、组件库版本这些特化信息。然后是AI漫剧场景。这个领域的核心难点不是单张图片画得好不好而是一致性和叙事的连贯性。角色一致性描述skill可以固定每个角色的外形描述词分镜脚本skill负责把剧情转化为镜头语言提示词生成skill负责把每个镜头的描述转成可执行的绘画指令配音对口型skill则处理音画同步。做漫剧最怕的是一集里十几个镜头主角的脸完全对不上这个是靠人为提醒根本管不过来的细节只有把角色描述统一封装进skill里才能从根本上解决。我整理了一个简单的对照表方便按场景快速定位需要哪些skill场景典型skill组合核心目标数学建模数据探索、特征工程、模型对比、论文排版从数据到论文的标准化产出前端开发页面生成、代码审查、性能优化、Bug定位开发流程闭环、质量稳定AI漫剧角色一致性、分镜脚本、提示词生成、配音对轨叙事连贯、画风统一通用办公会议纪要、周报生成、文档润色、数据分析日常效率提升配置整套工具箱时还有一个组织层面的建议把skills按功能分层。第一层放基础通用技能任何项目都能用第二层放场景专用技能只在特定任务时触发第三层放项目特化技能里面可能引用项目内的私有配置和模板。这样分层的好处是排查问题时能快速定位是哪个层面的因素导致行为异常不会出现“整个工具箱都受影响”的糟糕局面。7. 常见问题与排查技巧实录我在使用和安装skills的过程中踩坑无数这里挑几个典型问题分享出来基本能覆盖大多数人会遇到的情况。最常见的一个问题装完技能没生效。遇到这种情况先按顺序检查三件事第一目录路径是不是正确是否放到了工作目录对应的搜索范围第二目录结构对不对SKILL.md是不是直接在技能根目录下第三文件名和大小写有没有写错。做完这三步七成问题都能解决。第二常见的问题技能能被识别但表现和预期严重不符。这种多半是描述写得有歧义导致模型错误触发了别的东西。还有一个隐蔽原因多个skill产生了冲突。比如前端审查类技能装了三个模型检索时会混淆选择一个综合方案输出结果反而两头不靠。这种时候就要舍得做减法同类技能只保留一个最顺手的其他的清理掉。说到清理我特别想强调管理好技能库的重要性。技能装多了以后最大的问题不是磁盘占用而是模型在检索时出现了混淆和负担。一些社区大佬也分享过清理思路核心做法其实很简单定期审查技能列表分类归档删掉不用的合并重复的。我自己是每个月底会做一次整理保留一个“已启用”目录和一个“已归档”目录归档的虽然不参与运行但万一以后要用还能快速找回。这个方法在技能数量超过十个之后尤其重要。再一个常见坑是权限问题。前面说过辅助脚本没有执行权限会直接导致功能不正常但还有更隐蔽的情况——脚本依赖某些软件包没有安装或者路径写的是绝对路径跨机器之后就直接失效。解决这个问题的策略是在所有涉及外部脚本的描述里明确要求“先检查依赖是否满足不满足时先安装”同时在写技能文档时尽量使用相对路径降低迁移成本。还有一类问题是工具版本迭代导致的兼容性问题。某个skill在一个版本里正常升级之后就开始抽风大概率是底层调用方式变了。遇到这种情况不要急着怀疑skill写得不好先去官方发布说明里确认有没有破坏性变更。处理办法也可以很实际如果升级后有兼容问题短期内锁定在稳定版本如果长期用就自己改几行文档让它适配新版。最后分享一个排查方法论给每个skill设置“最小验证路径”。比如一个数据分析skill你就准备一份三行数据的测试文件跑一遍全流程能走通就说明基础功能正常业务数据出了偏差问题大概率出在数据特点上而不是skill本身的步骤逻辑。这个方法能帮你快速切分“skill的问题”和“业务的问题”省下大量无头绪的排查时间。8. 最后再聊几句从最开始对skills一知半解到后来能熟练安装、写自己的技能集合我最大的体悟是skills的本质是把你的专业判断沉淀成可复用的操作标准。它看起来是在训练AI实际上是在逼自己反思工作流——哪些步骤是必要且固定的哪些标准是可以量化的哪些输出是业务真正关心的。这个过程本身就是一种能力的升级。所以我的建议是不用追求一步到位也别嫌一开始写的东西很粗糙。挑一个你每天都在做、做着又有点烦的重复劳动花一个下午把它写成人生第一个skill然后连续用一周不断改。你会发现一周后这个家伙比你自己还懂你的套路。把十几个这样的小技能攒起来你的AI工具箱就开始真正值钱了。