最近在折腾AI编程助手的同学应该没少听人提skills这个词。点开GitHub搜一下跟skills相关的仓库成百上千前端开发skills、数学建模skills、AI漫剧常用skills甚至还有人专门整理了一套superpower skills合集。但大部分人在第一步就卡住了——找来一个skills仓库不知道往哪里放不知道怎么让Claude Code、Codex这些工具认出来更别说自己动手写一个。这篇文章把我自己从“装skills装到怀疑人生”到“能一口气写出三个能用skills”的全过程整理了一遍。不扯虚的直接讲清楚三件事skills到底是什么机制、怎么装、怎么写。顺便把之前搜罗到的、实测过确实好用的skills清单和踩坑记录一并放出来给正要入坑的同学省点时间。1. 先搞清楚skills是什么AI助手的“技能包”到底解决了什么问题1.1 从提示词到技能包skills机制的演进很多人第一次接触skills第一反应是这不就是一段提示词吗功能上有点像但底子完全是两码事。普通的提示词是你每次会话都塞给模型的一段“临时说明”说完就忘下次还得重新讲。而skills更像给代码仓库里放进了一套“可复用的能力模块”模型在对话开始前就能感知到这些技能包的存在并且知道自己应该用它们完成什么任务。拿Claude Code来说它的skills机制会在项目里建立一个.claude/skills目录每个技能包对应一个子目录目录里放一个SKILL.md文件再加若干辅助脚本、模板、参考文档。模型启动时会预扫描这个目录遇到相关任务就主动加载对应的技能定义。Codex这边也有类似的机制包括一些社区工具干脆把skills做成了可以直接拉取的技能库。这个思路本质上就是把“一次性提示词”升级成“项目内置能力”让AI从“你说一句它动一下”变成“看一眼项目就知道该按什么套路干活”。这套设计的厉害之处在于skills是跟项目走的。同一个技能包放在不同项目里模型会自动结合项目的上下文来使用。不像全局配置那样一刀切也不像临时提示词那样每次都要重讲一遍。1.2 skills到底解决了什么问题先说结论skills解决的是AI工具的“稳定输出”问题。你用Claude Code写了几天代码最深的感受应该是同一个问题换个问法结果差出十万八千里。这不是模型笨而是缺少一个结构化的执行框架。举个实际场景。你想让AI帮你写一份前端组件如果只丢一句话“帮我写一个表格组件”模型大概率会按自己训练数据里的“平均印象”来发挥用到的技术栈、命名风格、目录组织方式可能跟你项目完全不合拍。但如果你装了一个“前端组件开发skills”里面写了完整规范组件放src/components下、用TypeScript、样式用CSS Modules、必须导出类型定义、单测覆盖核心交互模型加载这套规则后会明显精准很多。再比如数学建模场景。竞赛里时间紧、任务急最怕AI给你东一榔头西一棒子。一个建模比赛专用skills如果提前定义好“数据清洗→EDA分析→特征工程→模型训练→论文图表输出”的完整流程模型就会按这个流程往下走省掉大量反复拉扯。所以skills真正解决的问题有三个一是把经验沉淀成规范让AI有章可循二是降低任务拆分成本不用每次重新跟模型描述你想要的执行方式三是让跨项目复用成为可能团队里一份skills所有人共享。1.3 一个典型的SKILL.md长什么样不亲眼看一下SKILL.md的结构很难理解skills为什么能影响模型的行为。这里给一个最简化的例子实际项目里会复杂很多--- name: frontend-component description: 按项目规范生成前端组件包含类型定义、样式文件与基础单测。 --- # 前端组件生成规范 ## 使用场景 - 需要新增一个React/TypeScript组件时 - 需要为现有组件补充样式或测试时 ## 执行步骤 1. 确认组件用途与props接口先写类型定义 2. 在 src/components/{ComponentName} 目录下创建组件文件 3. 样式文件使用 CSS Modules类名遵循 BEM 风格 4. 用 Vitest 编写核心交互的基础用例 ## 完成后检查 - 组件是否有类型错误 - 样式是否覆盖主要状态 - 测试是否通过你可以看到这个文件本质上是用模型最容易理解的方式把“什么时候用、按什么步骤做、做完怎么验收”讲清楚了。模型看到这个文件相当于拿到了一份岗位说明书自然比瞎猜你意图要靠谱得多。2. 手动安装GitHub上的skills一步步完整流程与避坑要点2.1 找对仓库怎么判断一个skills值得装GitHub上搜skills确实一搜一大把但质量参差不齐。我装了几十个之后总结出来的筛选标准基本就三条。首要看SKILL.md是否规范。一个靠谱的skills仓库每个技能包必须有自己的说明文件最好还带name和description的frontmatter。只有一堆脚本没有说明的模型根本不知道什么时候该用装了也白装。其次看维护活跃度。最后更新时间超过半年的基本可以跳过AI工具迭代太快旧定义很快失效。第三看项目文档里有没有 “installation” 或 “quick start” 一节作者写清楚安装方式说明他真的在真实环境里跑过。另外推荐一个思路先看热门集合型仓库比如superpower skills、common skills这类被社区验证过的合集再按需去逐个找细分技能。合集的好处是生态活跃、相互兼容不容易出现依赖冲突。2.2 Claude Code手动安装skills的3种方式第一种直接进项目目录把整个skills文件夹拉进来。这也是最朴素、最不容易出错的方式。先在你项目根目录建好.claude/skills文件夹然后把你想要的技能包目录整个复制进去。例如mkdir -p .claude/skills cp -r ~/Downloads/some-skill/ .claude/skills/这种方式的好处是依赖关系全靠目录自包含不会污染全局环境。坏处是每个项目都要手动复制一次。第二种用符号链接把技能包软链到项目目录。适合你自己维护了一批常用技能想同步更新多个项目。ln -s ~/skills-collection/some-skill .claude/skills/some-skill好处是改一处多处生效。坏处是换机器、换环境时链接容易断团队协作时别人clone你的项目会拿到一个失效的链接。第三种直接改全局配置目录。Claude Code支持在用户级别配置skills具体路径不同平台有差异常见的就是~/.claude/skills。放全局的好处是所有项目都能用但副作用也很明显项目一多模型扫描的技能数量暴涨反而容易出现“模型不知道选哪个技能”的尴尬。我个人的建议能放项目局部就放局部。skills这玩意儿跟依赖库一样精确到项目级别才能发挥最大价值。2.3 Codex等其他工具的安装差异Codex的skills安装路径跟Claude Code不完全一样。很多开源skills仓库支持多种平台的安装脚本但原理大同小异把技能包放到指定目录让模型启动时能扫到。个别工具还支持通过配置文件指定skills源路径这样技能包可以放在项目内也可以单独放一个目录统一管理。社区比较活跃的还有opencode、TypeSafe AI的skills方案它们的共同趋势是标准化SKILL.md作为技能定义的事实标准已经逐渐普及区别主要在扫描目录和加载方式上。所以学习成本并不高只要搞懂一个工具的目录约定其他工具迁移过去也就是改个路径的事。我最想提醒的反而是别为了追新工具而频繁迁移skills。你手里那几十个技能包花时间重新整理一遍目录结构真不如多花点时间写几个好用的新技能。2.4 安装完成后的验证清单装完skills最怕的就是“看着装上了模型根本不鸟你”。我一般用下面这个清单快速验证目录结构是否正确SKILL.md是否在技能包目录的根下frontmatter 里的 name 和 description 是否存在且描述是否清楚新开一个会话再用与该技能相关的问题触发看模型是否提到这个技能主动问模型“你有哪些可用的skills”看它能否正确列出来如果模型列出来了但用起来还是不带劲大概率是SKILL.md写得不够细。这个后面讲怎么写的时候会展开。3. 手把手写一个自己的skills从目录结构到实测调优3.1 目录结构与命名规范写skills这事动手比看教程管用。但动手之前先把目录结构定下来。推荐的最小结构如下my-skill/ ├── SKILL.md ├── scripts/ │ └── run.sh ├── templates/ │ └── example.txt └── references/ └── docs.mdSKILL.md是主文件描述整个技能何时用、怎么用。scripts放辅助脚本templates放输出模板references放补充资料。如果技能本身很简单不涉及脚本和模板只有SKILL.md也是完全可以的。但一旦技能复杂度上来全部塞进SKILL.md会让文件变得很臃肿模型读取效率下降。命名上技能目录名尽量用kebab-case小写加短横线比如code-review-helper而不是CodeReviewHelper。frontmatter里的name也保持一致。description要写清楚触发条件别写“一个有用的技能”这种废话要写“当用户需要检查代码变更时提供按规范执行代码评审的流程”这样模型才能准确匹配。3.2 SKILL.md的写作要点前置条件、执行步骤、校验规则我写过十几个SKILL.md之后发现最有效的写法是先写“什么时候不要用这个技能”再写“什么时候用”。你可能会奇怪为什么先写不适用场景因为模型对边界条件的理解往往比适用条件更重要。比如一个“数据分析”技能如果不说明“只处理表格数据、不处理图片”模型就可能拿着这个技能硬套所有问题。执行步骤要尽量原子化每步只做一件事。比如“先读取目录下所有csv文件格式再统一列名风格再做缺失值统计”这比“清洗数据”这种概括性描述好一百倍。模型理解粒度越细执行越稳定。校验规则是很多人会漏掉的部分。写完步骤后一定要加一个“完成标准”比如“输出文件包含三列” “脚本返回0” “测试覆盖率不低于80%”。没有校验规则模型做完就停根本不检查自己做得对不对。3.3 把skills“教”给模型的技巧写完SKILL.md只是第一步真正让模型形成肌肉记忆还得靠补充示例。我在技能包里放一个examples/目录每个技能至少配一个输入输出示例。示例不用多一两个就够但必须覆盖最常见的场景。你用自然语言跟AI描述一百遍都不如给一个“这就是我想要的结果”的样例直接。另一个技巧是让SKILL.md开头的description里包含关键词触发词。一个数学建模技能description里就写“竞赛、建模、数据清洗、论文图表、baseline模型”这些关键词。别怕被说是堆砌关键词对模型来说这反而是一种无监督的分类标签能显著提高技能匹配准确率。但注意关键词要真实反映功能千万别写跟实际无关的词来凑数。3.4 实测用例与迭代新写的技能不能一次成型我通常会用三个测试用例来验证。第一个是标准场景用例就是按你预想的主要场景问一遍。第二个是边缘场景用例故意少给一些信息看看模型会不会主动找你要。第三个是恶意场景用例故意给一个完全不相干的问题看看技能会不会被错误触发。跑完三个用例后基本能发现SKILL.md里描述不清晰的地方。最常见的场景是标准场景下模型表现很好但边缘场景下模型直接跳过了你定义的步骤。这时候我会回看描述是不是写得太绝对然后把边缘情况的处理方式补进去。迭代两三轮之后技能基本就稳定了。4. 常用skills分类与实战推荐前端、建模、漫剧都能用4.1 前端开发必须装的那几个类型前端是skills应用得最密集的领域。为什么因为前端工程化本身就有一堆重复规范组件目录组织、样式方案、状态管理、代码提交格式这些都是高度流程化的事最适合写成技能。我前端项目里常驻几个skills一个是“组件生成器”严格按照项目技术栈输出组件代码带好类型、样式、单测一个是“项目脚手架”能快速拉一个新页面并接好路由、状态、接口层还有一个是“代码审查助手”按团队规范review变更内容特别擅长挑命名和逻辑一致性的毛病。前端AI应用有个老问题模型往往“太聪明”会用各种奇怪的语法糖。技能包里写死技术栈约束能明显压制这种自由发挥。比如“禁止在无必要情况下引入新npm包”这种规则写进SKILL.md实测下来能省掉大量没用依赖的审查时间。4.2 数学建模与数据分析竞赛党可以省下大量重复工时数学建模是skills另一个很值得玩的领域尤其华为杯这类时间紧张的比赛。建模流程从数据清洗到论文成稿中间大量工作是可以标准化的。我现在看到建模场景下最有价值的skills有三类数据处理类、图表绘制类、论文排版类。数据处理类技能可以定义好完整规范缺失值怎么处理、异常值怎么检测、数值列和类别列怎么识别。图表绘制类技能则固定视觉风格比如统一使用matplotlib或seaborn颜色主题、标注格式全部写死保证论文里图表风格一致。论文排版类技能更硬核直接把LaTeX/Markdown模板放进去模型生成的内容起点就是“半成品”而非一片乱码。竞赛场景还有一个隐形痛点AI生成代码第一次往往跑不通。一个建模技能如果能内置“运行前检查清单”比如所有路径相对化、依赖包安装完整、随机种子固定能帮你少走大量弯路。4.3 AI漫剧与创意生产把工作流变成技能包很多人以为skills只能用在代码场景其实不是。AI漫剧、短视频脚本这类创意生产工作同样能沉淀成技能包。你日常做漫剧肯定有一套固定的流程写脚本→生成分镜→逐帧出图→配音→剪辑前对时间轴。这套流程完全可以写成一个创意生产skills。我见过做得不错的漫剧类skillsSKILL.md里定义了每张分镜要包含的“机位、景别、人物表情、背景描述”这样AI生成的脚本就能直接喂给绘图工具不用人为二次加工。还有人在技能里内置了分镜表模板模型按表格逐行生成内容结构极其工整。这类技能最大的价值是稳定“风格”。你做AI漫剧最怕风格飘忽今天这种画风明天那种画风。把画风描述、色彩倾向、角色一致性要求写进技能包输出就能稳定在一个调子上。创意行业里“可复用的审美标准”用skills来固化其实是个很妙的应用。4.4 常用的skills源网站与整理清理方法找skills除了直接在GitHub搜还可以关注几个社区聚合站点。有些开源项目把常用技能打包成合集比如superpower skills这类大合集安装一个就能用上几十个技能类型覆盖广泛。社区里也常有“awesome skills”风格的整理列表里面按领域分门别类适合按需翻找。但装了太多skills之后会碰到另一个问题目录越来越乱模型扫描负担越来越大。这时候就要定期清理。社区开发者tibo分享过一个清理思路我按照那个思路实践后觉得非常实用大致是这几步先用一个会话让AI列出所有已安装skills统计哪些技能从未被触发过接着按“最后使用时间”和“是否被项目引用”两个维度分类确定要淘汰的技能直接删掉或移到archive目录保留的则统一规范化命名和描述。我清理过一轮之后明显感觉到模型响应速度更快了误触发也少了。5. 装完不生效维护混乱问题排查与整理实录5.1 装完skills完全没反应先别重装第一类高频问题技能包明明放进去了模型就跟没看见一样。遇到这种情况我的建议是按顺序排查先确认目录路径再看SKILL.md文件名大小写最后检查frontmatter。真实案例里文件名大小写不统一是最常被忽略的坑。有些仓库的文件写的是skill.md而工具只认SKILL.md大小写不对模型直接跳过。另外frontmatter的name字段有没有写错也很关键有的AI工具有特定的技能声明格式不写或写错都不会被索引。还有一点容易被忽略模型上下文长度有限如果项目里技能包太多或者某个SKILL.md写得特别长模型可能因为上下文放不下而丢弃部分技能定义。这种情况的解法是精简SKILL.md把大段内容挪到references目录里只保留核心信息在主线文件里。5.2 多个skills互相冲突模型不知道选哪个第二个高频问题技能装多了模型开始精神分裂。你的项目里有一个“数据分析”技能又有一个“建模比赛全流程”技能都声称覆盖数据清洗环节。模型遇到任务时可能随机选一个执行输出风格就不稳定。解决冲突的核心思路是“职责单一”。每个技能只负责一个专业场景描述中明确圈定边界。如果两个技能确实有交叠就在其中一个的适用场景里写上“若用户明确要求建模比赛流程请优先使用另一技能”。这听起来有点笨但实测对模型选型很有帮助。我更推荐的还是定期合并同类项把功能相似的技能整合成一个更通用的技能包。5.3 模型不按SKILL.md的步骤走怎么办第三类问题最恼火技能加载成功了模型也承认有这个技能但执行时就是不走你写的流程。最常见的原因是步骤写得过于抽象模型“理解”了但不知道怎么转化为具体操作。比如你写“检查代码质量”模型可能会觉得代码能跑就算质量合格。但如果你写“检查代码中是否存在console.log残留、错误边界是否覆盖、异步请求是否有超时处理”它就知道你要的具体是什么了。所以遇到不按步骤走的情况先别怪模型回头看看你写的步骤是否足够具体可操作。如果步骤已经很具体但模型还是坚持自己的做法那就要考虑是不是其他技能或系统提示词里的某些内容影响力更大。我遇到过一次项目里有另一个工具链配置跟我的技能定义打架模型每次都在两者之间摇摆。排查了半天最终把工具链配置里跟技能重复的约束去掉才解决。5.4 版本更新带来的兼容性GitHub仓库更新后我踩过的坑最后一个提醒skillsp包的更新兼容性问题。GitHub上很多开源skills会不定期更新拉新版本回来之后旧目录没删干净新旧两份同时存在模型加载了重复定义行为变得很诡异。我的习惯是每次更新技能前先把旧技能目录彻底删掉再重新复制新版本。别迷信“直接覆盖”会更干净覆盖往往留下旧文件残骸。用软链方式管理的话更新就更简单了直接更新源目录内容就行但要注意先停掉正在使用的会话避免模型用加载中的旧定义做了一半。还有个更隐蔽的坑是主题和大版本升级。有些skills明确写了“适用于Claude Code某个版本”升了大版本后可能失效。装之前先看一下仓库说明里的兼容性表别等用了半天发现模型完全不理会技能定义才回头查文档。聊到这我把这段时间积累的skills经验基本都倒出来了。这里分享一个我自己最常用的顺手做法我会单独建一个名为 “daily-routine” 的技能包把写代码前最常做的动作都放进去——比如优先读取项目README、检查当前分支、确认测试命令、梳理changelog。每天早上开新会话第一件事就是让模型先加载这个技能把项目状态过一遍。不用它解决什么高级问题但能保证一上来就和项目同步后面交互明显顺滑很多。这个技巧说起来简单我自己用下来受益很大推荐你试试。