如果你最近逛GitHub、刷技术社区或者混在任何一个AI工具讨论群里应该都会注意到同一个词——skills。Claude Code官方在推skillsCodex在跟进skillsOpenCode、Cola都在往这个方向靠拢连数学建模比赛群里聊天的画风都变了有人直接问华为杯建模codex skills上哪找。这个现象很有意思。两年前我们还在研究提示词怎么写得更稳一年前开始讨论MCP协议现在大家张口闭口都是skills。它到底是什么为什么这么多工具不约而同选择了同一种设计作为一个从Claude Code刚开始支持自定义能力包就在折腾的老用户我前前后后装过别人的技能、自己写过技能、也踩过不少清不干净的坑。这篇文章就把我这一路积累的理解、实操步骤和翻车记录都写出来尽量帮你少绕几圈。1. Skills突然爆火从Claude Code到Codex的通用化之路先说结论skills本质上是一套能力包的标准化格式——把一个AI Agent在特定任务上需要的提示词、领域知识、脚本、参考文档、工作流规范打包成一个目录结构让模型在遇到相关任务时自动加载并按照预设流程执行。它解决的问题是怎么把一个成熟方法论稳定地复制到每一次对话里。在skills出现之前大家想让AI稳定做一件复杂的事基本靠三招复制粘贴超长提示词、写一堆AGENTS.md项目说明、或者靠各种外部工具链硬凑。这三招都不够好用超长提示词既占上下文又容易在长对话中被稀释AGENTS.md只能描述项目规范却难以绑定具体任务的执行流程外部工具链又要求每个人都有一样的本地环境。skills的聪明之处在于它把在什么情况下启用、按什么顺序执行、调用哪些工具、参考哪些资料全部写进了一个目录结构模型按需取用。你不需要在每轮对话里重申要求模型看到匹配的描述就会自动加载对应流程。为什么2024年下半年到2025年这个概念突然爆了关键信号是Claude Code把skills做成了官方能力并且有了一套看起来很像标准的格式。随后Codex、OpenCode、Cola等一批AI编码和内容生成工具跟进。这些工具虽然路径、命令有差异核心逻辑高度统一建一个SKILL.md文件用YAML头声明技能名和触发描述然后在正文里写详细执行步骤。如果你把一套skill从Claude Code迁移到Codex要改的往往只是放置路径。对普通用户来说这个趋势意味着什么意味着用AI干活这件事开始从现场即兴发挥转向预制能力复用。以前你让AI写一个前端页面它每次写得都不一样有时用React有时用Vue样式规范时好时坏。有了skills你可以把团队规定好的技术栈、代码规范、测试标准、提交规范全部固化成一个技能包之后AI每次遇到相关任务都按这套标准执行。对个人来说也是一样你有自己习惯的论文排版流程、数据分析工作流、甚至写小红书文案的口吻标准都可以打包成自己的skills。当然skills不是魔法。它没有给模型增加任何新能力——模型会的还是那些Skills提升的是执行过程的稳定性和复用性。这就像同样一位厨师你给他一本自家后厨的标准化菜谱和一套专用工具他出菜的速度和一致性会肉眼可见地提高。所以真正值得花时间的不是到处收集别人的技能包而是搞清楚怎么把自己的菜谱写成SKILL.md。2. Skills能做什么从自动写前端到数学建模的实战边界与其空谈概念不如直接盘点一下我现在实际在用、以及最近社区里讨论最多的skills场景方便你判断这东西到底跟你有没有关系。2.1 前端开发最常见的skills适用场景前端是我认为skills收益最大的落地领域。原因很简单前端项目的前置规范极其繁琐技术栈、组件库、命名规范、状态管理方案、样式方案、打包配置每一项都能影响生成结果。你可以写一个前端代码生成规范的skill里面约定用TypeScript还是JavaScript、用Tailwind还是less、组件文件怎么放、API层怎么封装、错误处理用什么模式。我建过一套类似的里面还绑了一个scripts/目录放着自动格式化命令和提交信息生成脚本。实测下来在配了这个skill的项目里跑出来的代码review成本比之前低了不少因为AI每次给的代码都长在固定范式里。前端场景里还有一类很受欢迎的是UI还原skill专门用来把设计稿转成页面——约定图片转出哪些基础信息、用什么组件库、断点怎么设、交互动效怎么做。这类技能很适合有固定视觉体系的团队。2.2 数学建模与竞赛场景华为杯、国赛都在用最近热词里华为杯建模比赛好用的codex skills排名很高说明学生群体已经开始把skills当常规武器用了。我了解到主流做法是把整个建模流程拆成几个技能一个是问题分析与模型选型技能里面写清楚拿到题目后先做什么数据预处理、按问题类型推荐模型、怎么处理参数假设另一个是论文LaTeX排版技能把摘要写法、图表规范、公式编号、参考文献格式全部固化还有的是数据可视化技能规定图表类型选择、配色、坐标轴标注规范。竞赛场景下skills的价值在于把AI当成一个有固定分工的协作队员而不是一个每次都要重新培训的实习生。参加华为杯那类比赛时从拿到题目到提交论文只有四五天很多团队用skills把初稿生成时间压缩到半天内剩下的时间全在打磨模型和验证数据。不过说实话竞赛类skills翻车的概率也高因为数学建模题目的变数太大一个描述写得太死的技能容易在没遇到对应题型时完全不会被触发所以在配置description时建议写宽泛一些后面我会专门讲。2.3 AI漫剧和内容创作技能机制开始出圈AI漫剧是短视频领域很火的方向用AI工具批量生成漫画风格的剧情短剧。这类内容最头疼的是角色一致性同一个角色在不同分镜里经常长得不像。现在有人把角色设定一致性做成了skill要求模型在每次生成前先读取角色卡文件、提取关键外貌特征、写入生成参数生成完后对比上一画面做微调。这类skill通常还包含分镜脚本生成和台词风格统一两个子工作流。这说明skills的适用范围早就超出写代码了。凡是需要AI按照一套固定规矩稳定输出内容的场景理论上都可以用技能包来约束。写作、翻译、PPT制作、数据清洗、简历优化——只要你能把自己的流程总结成步骤它就有机会固化成skill。我自己就把技术文章排版规范做成过一个简单版本里面约定了标题层级、代码块怎么放、表格怎么设计写文章时直接让模型按这套来。2.4 边界问题Skills能管什么、管不了什么聊完能做什么也得说清楚边界。Skills管得住流程和偏好管不住知识能力。比如skill可以规定模型遇到优化问题先用线性规划试试如果变量太多再换启发式算法但模型本身不懂优化理论再好的skill也救不回来。另外skills不能保证模型百分百服从它是通过提示级机制引导模型行为不是硬性代码约束。如果模型在当前对话里压根没有触发到你的skill或者技能描述写得太绕它就不会生效。所以我的建议是把skills定位成降低执行方差的手段而不是提升能力上限的捷径。看到网上有人吹装了某套skills之后AI直接变成专家助手对于这种说法我现在的态度是看看它里面到底装了什么再决定要不要跟风。3. SKILL.md到底写了什么拆解一个完整技能包的文件结构如果你准备自己写skills第一步要理解的就是目录结构和SKILL.md的写法。不同工具的细节稍有差异我先按Claude Code的主流格式讲这套格式在Codex、OpenCode上同样通用。3.1 一个技能包的目录结构典型的skill目录长这样my-skill/ ├── SKILL.md # 唯一必须存在的文件 ├── scripts/ # 可选可执行脚本或程序 │ └── format_check.py ├── references/ # 可选参考资料、模板、示例 │ └── api_style_guide.md ├── assets/ # 可选图片、静态资源 └── data/ # 可选数据文件、白名单等SKILL.md是这个包的核心。有的初学者会把技能做成一大段提示词垫在对话开头但skills的正式做法是把提示词拆成元信息声明和正文指令两个部分分别放在SKILL.md的YAML头和正文里。3.2 frontmatter里写什么、怎么写更科学SKILL.md开头三段横线中间的部分就是YAML frontmatter。以Claude Code的格式为例里面最重要的字段是name和description。--- name: frontend-code-review description: 用于对前端代码进行规范性审查当用户提到代码审查、review 或合并请求检查时启用。 allowed-tools: - Read - Grep - Glob - Bash ---这里有一个很多人第一次会踩的坑description必须写得可被模型判断。模型在对话中会根据当前用户消息的语义去匹配所有已加载skill的description。如果你的description写得太抽象比如负责代码质量相关工作模型可能在任何一次与代码有关的对话里都触发它写得太窄比如当用户输入/review命令时调用那只要用户没有用这个精确命令它一辈子都不会被触发。理想的写法是场景关键词意图三者结合也就是上面示例里那种说明适用任务类型列举常见同义词再加一句什么时候不适用。allowed-tools也是一个值得花时间配置的字段。它限制了该技能在执行时可用哪些工具能有效防止模型在技能流程里跑飞、调用那些跟本任务无关的操作。如果你的skill要执行shell脚本记得在allowed-tools里加上Bash否则模型明明有脚本却执行不了排查起来很容易一头雾水。3.3 正文该怎么写指令的可执行性比文采重要YAML头下面是正文也就是markdown正文。这里面的内容就是当技能被触发时你要按照这些步骤操作。我建议至少包含这几块任务目标说清楚这套流程要完成什么让模型对齐方向。执行步骤按顺序编号每一步说清楚做什么、产出什么、怎么验证。产出格式直接给输出模板比如最终结果必须包含以下三个部分或者给一段示例结果。参考文档引用如果有references目录在对应步骤里写明请先阅读 references/xxx.md。禁止事项明确写哪些动作不允许这比只写鼓励性指令要有效得多。举个例子我做过的技术文章排版skill正文关键部分是这样的# 技术文章排版与润色指南 ## 目标 将用户提供的草稿整理为符合个人博客风格的技术文章。 ## 执行步骤 1. 通读全文识别核心主题和章节结构。 2. 重写标题层级只允许使用 ## 和 ### 两级标题禁止出现一级标题。 3. 对超过6行的段落进行拆分保证每段控制在4-6行。 4. 检查语气全文使用第一人称经验分享口吻禁止使用通过本文...、综上所述...等套话。 5. 如文章涉及代码检查代码块是否标注语言类型。 ## 输出格式 按原文章节顺序输出全文不额外添加目录与总结。看完这段你就明白正文本质上还是一篇提示词只是受益于外层包装它能在被触发的时机里稳定注入。这也意味着你在写正文时可以更细致不用担心上下文空间——skill文件被加载时才占用上下文平时只是挂在元数据里。3.4 辅助目录的作用scripts目录用来放需要真实执行的脚本比如自动格式化、批量重命名、调用外部API处理数据。references目录适合放不需要模型背下来但必须能查得到的东西比如公司API文档、团队代码风格规范、长篇幅的模板案例。我把references当作外挂记忆库SKILL.md里只需要一句话让模型去查某个文件模型在需要时再打开它读取细节这样省下了大量上下文空间。4. 手把手开发第一个Skills从零到能跑的完整流程这一节直接带你走一遍完整开发流程。我自己前面几套skill都是这么折腾出来的按这个顺序来能省掉不少反复试错的时间。4.1 第一步定义任务、拆解流程别一上来就写文件。先拿张纸想清楚你希望AI在什么场景下、面对什么输入、执行哪些步骤、产出什么结果。最好是挑一件你已经做过很多遍、流程已经稳定的任务比如帮我生成周报、把这篇内容改写成本人文风、按团队规范新增一个前端页面。流程稳定的意思是你能说出第一步干什么、第二步干什么、边界条件是什么。如果你自己都说不清那也就别指望模型能照着执行。4.2 第二步搭建目录结构按第3节的格式创建目录和SKILL.md。这里强烈建议先用手写文本编辑器创建文件一开始不需要太复杂一个空frontmatter加几段正文就能跑。先把完整跑通再慢慢加references和scripts。很多人第一次失败是因为一上来就把架子搭得很大结果某个环节出错根本不知道是格式问题还是内容问题。4.3 第三步把正文写得crazy具体写正文时记住一个原则让AI当一名严格按规矩办事的新人。不要说分析代码问题这种模糊的指令要说先运行一遍测试命令针对输出中的错误类型进入对应处理分支遇到类型错误时列出文件与行号并给出修改建议。步骤越具体输出的稳定性就越好。合理利用禁止列表把你不想要的结果提前排除掉比如禁止输出空泛结论、禁止跳过数据验证步骤、禁止在没读参考文档时直接回答。4.4 第四步加载与测试不同工具加载skills的方式差不多以Claude Code为例把技能目录放到全局skills路径~/.claude/skills/或者放到项目级路径.claude/skills/。重启Claude Code或者直接开始新对话输入命令查看已加载技能列表。用一段符合description场景的测试消息触发它观察模型是否输出符合预期的流程化结果。如果没触发优先检查两件事description是否被自然语义覆盖目录是否存在路径权限问题。4.5 第五步迭代description和步骤测试后你大概率会调整。最常见的迭代路径是触发不了→把description写得更直白触发了但执行得不像样→把正文步骤写得更细执行步骤没问题但结果格式不合意→把输出模板直接贴进去。我自己平均要跑三轮左右才会稳定。记住要保留测试记录方便对比每次改动的效果。4.6 开发期常见的几个文件级问题我在写skills时遇到过的、也是社区里频繁被问到的坑集中列几个YAML头格式错误frontmatter里的字段漏了冒号、引号没配对会导致整个文件解析失败。allowed-tools漏配技能流程中用到了本来可以用的工具但因为限制太死实际执行时总是被拒。description与其他技能重复两个技能出现的触发条件高度重叠模型只会选中其中一个另一个就变成了僵尸技能——装了等于没装。把大段背景知识全塞进SKILL.md正文导致每次触发都消耗大量上下文空间建议把长内容挪到references目录仅让模型按需读取。5. 手动装载GitHub上的Skills安装路径与依赖处理很多人第一个问题不是写技能而是怎么把别人写好的skills装到自己工具里。这个热词一直居高不下因为网上教程总把安装过程写得一笔带过导致各种装了不生效的求助帖。这里把完整链路写清楚。5.1 从GitHub上拿到技能包在GitHub上找skills时先学会分辨仓库和技能目录。有些仓库本身就是几十个skills的合集有些仓库则是一个完整技能包。找到目标后直接克隆或者下载压缩包到本地# 克隆一个skills合集仓库 git clone https://github.com/xxx/some-skills-collection.git # 进入目录后找到真正代表skill的那一层通常包含SKILL.md的目录就是 cd some-skills-collection find . -name SKILL.mdfind命令的输出会告诉你哪些才是真正的skills根目录。比如一个仓库路径是/repo/frontend-helper/SKILL.md那frontend-helper才是你要安装的技能目录而不是把整个仓库复制过去。5.2 放到正确的路径安装位置看工具。拿Claude Code举例全局技能放这里~/.claude/skills/frontend-helper/如果只想在一个项目里生效就放到项目根目录.你的项目路径/.claude/skills/frontend-helper/Codex CLI目前对应的是~/.codex/skills/OpenCode类似。很多装了不生效的原因就是把它放到了别的路径或者直接把整个仓库目录原样放了进去导致模型始终找不到SKILL.md。5.3 验证是否加载成功装完以后重启对话输入加载列表命令比如Claude Code里的/skills正常情况看得到刚才装的技能名。这一步至关重要建议每次装完都确认一遍别问为什么我至少有三四次因为没验证、继续往下写对话结果发现模型根本没收到技能。5.4 依赖与权限为什么有时技能看得到但用不了有些skill会带scripts目录里面是自动化脚本。你要确认脚本所需的运行环境齐不齐Python版本、Node版本、系统命令、第三方依赖有任何一个缺失技能流程都会中途断掉。此外某些技能需要访问特定API或读取用户目录下的配置文件这类依赖未必写在README里。排查思路很简单手动在终端里跑一遍那个脚本看能不能正常执行。能跑才能算环境没问题。5.5 装了不生效的标准排查链路如果验证列表里有技能但对话里怎么都不触发按下面顺序排查先看description的触发条件你测试时说的话是否覆盖了它描述的关键词或场景。如果描述里写了当用户要求重构时启用而你输入的却是帮我改改这段代码它不触发是正常的。再看有没有同名技能冲突。如果两个技能同名、描述又相似工具通常只保留一个。查看是否使用了最新版本的客户端有些工具对skills的支持还处于快速迭代状态版本差异会导致加载失败。最后看日志或者用极简的触发词测试比如直接把技能名和相关场景关键词拼在一起发出去。如果这样都不触发基本可以判断是技能文件本身有问题或路径不对。6. 值得收藏的Skills资源清单与真实使用测评肯定有朋友希望我直接甩一份资源清单。这个安排上但我先说一句不要盲目收集。我自己曾经收藏了上百个skills真正常用的不超过十个。与其追求数量不如花精力挑精品。6.1 社区里讨论度高的集合型项目网上经常被安利的有superpower skills这里也出现在热词里。它是一整套预置技能覆盖的工作类型很广从写周报、做规划到代码审查、系统设计都有对应的技能包。它的安装方式不同版本略有差异基本逻辑依然是克隆仓库、把skills目录里的内容放到本地的skills路径下。它的优点是你装完立刻拥有一大批能用的技能方便理解好技能长什么样缺点是数量大、同质化高放到自己的技能列表里容易造成触发冲突建议装完挑几个真正需要的保留其余移出。还有一个热词是typesafe ai skills我之前也关注过。这类仓库比较偏类型安全和技术向配置适合想自己动手diy技能的人参考。另外像openai/codex相关的skills示例、Anthropic官方给的示例skills都是质量相对稳定、文档齐全的资源适合当作正确写法来学习。6.2 我实际测试后的推荐列表下面这张表是我在实际项目中验证过、或者说身边朋友反复确认过确实能提升效率的技能类型你可以根据自己需要去找对应的实现。技能类型适用场景我的使用体验前端规范生成按团队规范生成React/Vue页面代码风格统一效果明显适合团队协作代码审查对MR做规范性检查能节省预审时间但不能完全替代人工逻辑审查数学建模论文排版LaTeX格式、图表规范、摘要写法比赛场景确实省时间但描述要放宽以免不触发角色一致性AI漫剧/漫画生成需要配合固定角色卡效果取决于底层模型文档总结与周报会议纪要、周报生成简单实用几乎零配置成本项目脚手架初始化新项目统一目录结构和基础配置团队新成员上手神器6.3 找技能的渠道汇总如果你要找更多现成技能可以关注这几个方向GitHub的awesome-skills这类收录性质的仓库各AI工具的官方文档和社区板块还有不少博主会整理常用skills源网站。找的时候注意看更新时间和Issues如果一个仓库半年没更新、Issues里全是加载报错就别折腾了换个维护活跃的。另外skills下载这个热词背后有个常见的坑下载完压缩包解压后发现里面根本没有SKILL.md只有一堆散落的参考文档。这种一般不是完整的技能包顶多算素材遇到这种情况可以直接放弃。7. Skills日常维护与翻车经验清理、兼容与边界最后这部分聊聊维护因为很多人的技能库装着装着就乱了。光装不清理时间一长技能之间互相干扰反而比不装还难用。7.1 什么时候必须清理、怎么清我自己的触发点是装新技能后开始频繁出现对话里提到相关关键词但模型就是不按技能执行的情况。这时候十有八九是技能冲突了。清理方式不复杂按下面这几步来先列出所有已安装技能确认当前实际数量。检查有没有重复覆盖的比较name和description判断哪些技能可能被同类触发。把暂时用不到的目录移出skills路径放到一个备份目录别直接删除。备份目录路径可以记在笔记里。重启并验证确保留下的技能都能正常加载。如果之后再需要某个被移出的技能从备份目录拷回来就行。这个思路也跟社区里流传的清理建议一致重点是移出而非删除因为你根本不知道哪一天又会想用回某套流程。7.2 多工具兼容与目录差异同时使用Claude Code、Codex、OpenCode的人越来越多同一套技能往往想多处用。我的做法是建一个统一管理的目录然后针对不同工具做软链接而不是维护多份拷贝# 假设我的技能统一放在 ~/skills-store 下 mkdir -p ~/.claude/skills mkdir -p ~/.codex/skills ln -s ~/skills-store/frontend-helper ~/.claude/skills/frontend-helper ln -s ~/skills-store/frontend-helper ~/.codex/skills/frontend-helper这样技能本体只维护一份改完即同步生效。但也要注意工具之间的格式差异比如某些工具对frontmatter字段的敏感度不同同一份SKILL.md在Claude Code里运行良好放到另一个工具里却加载失败。跨工具复用时先小范围测试再大面积铺开。7.3 安全与来源信任问题安装第三方skill时一定要先全文读一遍SKILL.md和scripts里的脚本再决定是否启用。这个提醒不是吓人——skill本质上就是一段带指导性的指令恶意技能完全可以诱导模型输出危险命令、读取敏感文件、或者把数据传送到不该传的地方。尤其那种一键安装、无敌增强、效果炸裂类的分享资源更需要保持警惕。我自己的标准很简单只装来自可信作者、文档清晰、代码和指令都公开透明、且能看懂逻辑的技能包。看不懂的不装。7.4 我折腾skills之后的一点体会这几轮折腾下来我越来越觉得skills的核心不是收集更多技能而是提炼自己的方法论——把一个你反复在做、已经有成熟套路的事情固化成一套可以被AI稳定执行的标准动作。最值钱的不是某个大神的技能包而是你为自己工作习惯定制的那一套几十行的SKILL.md。如果你现在刚开始接触建议从一个小小的日常任务入手比如生成一份符合自己格式的周报或者给技术文章做排版跑通了再往复杂方向发展。等你积累了几套贴合自身习惯的技能再去看网上那些五花八门的合集就能一眼分辨出哪些是干货、哪些只是在堆字数了。