最近刷技术社区满屏都是skills这个词。点进去一看和我最早以为的“个人技能提升清单”完全是两回事——在2025年的AI编程语境里它已经成了给Claude Code、Codex、OpenCode这类AI编程工具装“专业技能包”的标准玩法。很多老玩家在晒自己的技能库新人和我说想上手却不知道从哪看起毕竟搜skills出来的结果有项目、有教学、有资源站还有一堆场景包确实容易看懵。这篇文章我就围绕AI skills这个核心概念把大家搜得最多的几件事一次性讲透skills到底是什么、它靠什么原理生效、怎么把GitHub上的skills装进自己的工具、怎么写一份属于自己的skills以及数学建模、前端开发、AI漫剧这些热门场景里它到底能干什么。不论你是刚接触AI编程的新手还是已经在折腾Claude Code的老手这篇都可以当一份上手路线图用。1. 先搞懂它是什么从“通用技能”到AI技能包1.1 为什么这个词最近突然火skills这波热度靠的是背后几家AI编程工具的集体转向。Claude那边把Skills做成了Agent的原生能力Codex这边也有自己的skills生态加上OpenCode这类开源编辑器跟进整个圈子突然发现给模型塞“专业知识”这件事终于有了统一的载体。过去我们怎么让AI干专业活要么写超长的系统提示词要么准备一堆示例丢进上下文要么接MCP服务让它调外部工具。但这几种方式各有各的别扭。系统提示词会越攒越长上下文很快被废话占满示例放少了模型学不会放多了又费钱费时间MCP适合“调用工具”而不是“学会方法论”。skills的出现等于把“一段专业工作法配套模板辅助脚本”打包成一个标准文件夹模型遇到对应场景时会自己加载、按流程执行效果比纯提示词稳定得多。这个思路正好踩中了2025年AI编程工具代理化的节奏。当模型从“问答式助手”变成“执行任务的智能体”它需要的就不只是答得对而是“把事情按行家的流程做完”。Skills恰恰是干这个的。1.2 一个目录加一份说明书就是全部秘密很多人第一次看到skills的文件结构时会愣一下就这是的本质上就是这么简单。my-skill/ ├── SKILL.md └── resources/ ├── template.md └── helper.pySKILL.md是整个技能的核心里面用Markdown把“什么时候用这个技能”“怎么规范地执行任务”“每一步要注意什么”写清楚resources目录可以放模板、脚本、样例数据给模型当辅助工具。模型读到SKILL.md之后就会照着里面的流程开始干活。这和普通的“提示词模板”有本质区别。提示词模板是每次要手动粘贴进去的一段话用完就没了换会话照样要从零开始skills是一个常驻的、带名称和描述的独立模块模型能自己判断“这个场景我该调用哪个技能”还可以在技能内部引用脚本和模板实现半自动化的流程。你可以把它理解成提示词是一张便签skills是一本带目录和工具的手册。很多人在社区拿它和MCP对比这俩不是替代关系。MCP解决的是“模型怎么安全地操作外部系统”skills解决的是“模型怎么按专家方法思考和执行”。一个把知识和流程放进上下文一个把工具和权限暴露给模型配合使用才是目前比较顺手的组合。2. 一个目录看穿本质SKILL.md是如何被模型使用的2.1 触发机制靠description精准“唤醒”理解skills的加载机制对后续安装和写作都特别关键。以Claude Code为代表的主流实现里SKILL.md的前缀YAML元信息承担着“索引”功能其中最重要的就是name和description两个字段。--- name: math_modeling_workflow description: Use this skill when the user needs to solve a mathematical modeling problem, such as analyzing competition problems, selecting algorithms, or formatting competition papers. Do NOT use this skill for general code refactoring. ---description写得怎么样直接决定模型会不会在合适的时机调用它。模型在对话过程中会把所有可用技能的description过一遍就像搜索引擎根据摘要判断网页与查询的相关性。写得笼统模型会犹豫写得过于宽泛不该触发的时候它会强行触发。我见过不少人的技能失效不是执行部分写得差纯粹是description里没有把“什么时候用”和“千万别用”讲清楚。2.2 手动调用和自动调用两种模式都练熟除了自动触发skills也支持手动指定。在会话里直接用包含技能名的指令让模型加载对应技能比如“使用math_modeling_workflow帮我分析这道赛题”模型就会主动去找这个技能并按其流程执行。这给调试带来了很大的便利。我每次新装一个技能都会先手动调用一次确认流程能跑通再测试自动触发是否正常。如果一上来就依赖自动触发经常会被“模型选了另一个相似技能”“模型压根没加载”这些问题绕晕分不清是索引问题还是内容结构问题。手动调用的另一个好处是能绕过模型对“当前对话是否需要技能”的判断。有些时候任务确实跟某个技能沾边但模型觉得当前对话不用上结果就是技能没生效。这时手动点名是最快的兜底方案。2.3 它的核心原理把专家知识“注入”上下文很多人好奇一个文件夹为什么能改变模型的行为说穿了就一句话它在模型需要的时候把专家级别的工作流程直接构造进上下文。我们平时让AI干活讲究few-shot和上下文构造。Skills等于提前把一套高质量、可复用、经过验证的上下文片段准备好了。模型一加载技能就相当于临时聘请了一位懂行的专家按专家脑子里的SOP一步步推进。它不是靠什么神秘的黑魔法而是系统化地利用了上下文工程——把模糊的“让AI做建模”变成了结构化的“走一遍建模的完整流程问题假设、模型建立、算法设计、结果验证、论文摘要”。表格对比一下会更清楚能力项系统提示词MCP服务AI Skills知识沉淀靠人工编辑易膨胀不支持原生支持复用性跨会话复用难可复用可复用外部操作不适用适用可通过resources调用脚本自动触发不支持不支持支持最适合场景全局性格设定工具集成专业流程、方法标准化3. 别人的skills怎么装进自己工具不折腾的安装路线3.1 装之前必须搞清的三件事很多人在claude code里折腾了半天装不上GitHub上的skills多半是漏了三件事目录位置、配置文件、依赖处理。先说目录位置。Claude Code的skills默认分两种用户级的放在~/.claude/skills目录项目级的放在当前项目下的.claude/skills目录。用户级对所有项目生效项目级只对当前仓库生效。如果某个技能只在这个项目里用就不要放进用户级否则所有项目都能看到这个技能context容易被占满不说触发时也可能误伤。再说配置文件。Claude Code对skills的加载权限受~/.claude/settings.json或项目.claude/settings.json的影响。部分技能需要调用脚本如果allowedTools配置没放开技能加载之后跑不起来。最后是依赖问题。GitHub上很多skills不是纯Markdownresources里可能带Python脚本、Node脚本装完之后不装依赖技能在真正执行的时候会卡在“工具不可用”上。3.2 手动安装的完整步骤手动装一个GitHub上的skills核心操作就是“把技能文件夹放到正确的位置”。以Claude Code为例完整流程如下打开GitHub找到目标skills仓库复制仓库地址或者直接下载ZIP包。把技能文件夹放到~/.claude/skills或项目下的.claude/skills里。注意是“技能文件夹本身”在skills目录下不是仓库外层套一层。确认目录里能看到SKILL.md文件。如果技能是压缩包先解压再确认SKILL.md没有嵌套在多余的层级里面。查看skill仓库的README安装依赖。很多skill会包含requirements.txt或package.json按说明安装到本地环境。检查settings.json。如果技能要走脚本确认allowedTools里放开了对应路径或工具。重启会话或者新建对话手动点名技能做一次冒烟测试。这里头最容易踩坑的就是目录层级。我见过有人把整个仓库复制进了skills目录里面还套一层文件夹SKILL.md根本没直接出现在技能的根目录下。模型扫不到技能第一反应不是“路径错了”而是“这个技能没装”排查起来特别容易绕弯路。如果用的不是Claude Code是Codex或者OpenCode安装思路完全一致——找到该工具文档里约定的skills目录把技能放进去。OpenCode这类编辑器通常自带skills目录管理界面甚至能在网页端直接查找、导入技能操作比命令行更直观很多热搜里问的“skills网页版进入”其实就是这类图形化入口。3.3 搜集对路的技能搜什么、去哪搜、怎么避坑GitHub上skills相关仓库特别多质量也参差不齐。我的习惯是先找官方示例和整理型仓库再看个人项目的更新时间和使用人数。你如果自己搜推荐这几个搜索方向awesome skills汇总类仓库通常包含一票实践验证过的技能适合起步。superpower skills社区里很响的“超能力技能包”项目把大量场景技能打包在一起口碑不错但体量偏大建议按需挑选而不是整个塞进工具。typesafe ai skillsTypeSafe团队整理的有类型安全实践加持的技能集对各种编程任务的工程规范性很有帮助适合对代码质量敏感的人。opencode skillsOpenCode生态的技能集很多可以直接在图形界面里导入。具体场景关键词比如codex skills、math modeling skills、frontend skills适合找某个细分领域的现成方案。下载完技能记得留意tibo这类老玩家反复提醒的清理问题。技能的加载不是越多越好每个技能都会增加模型做“技能索引”时的信息噪声。你会看到有人半年攒了几十个技能最后发现模型经常选错或者根本不触发。tibo的清理思路很有参考价值每季度把技能库过一遍超过30天没触发过的先归档触发后效果不明显的直接删同类技能只保留一个最顺手的。保持一个精简的技能库比一味堆技能有用得多。4. 自己写一份像样的SKILL.md从模仿到落地4.1 写之前先做一次“专家流程拆解”如果你搜过ai skills怎么写应该已经看到不少零散建议了。但我的建议是动手写代码之前先坐下来把你脑子里的专业流程拆出来。就拿前端开发举例。很多前端技能写不好是因为作者没把“开发一个组件”拆细。正确的拆法可能是先问需求边界和交互细节再列组件结构和状态管理方案然后按无障碍、响应式、性能三条线写实现最后补测试用例和文档。每一步都要写得足够具体模型才知道往哪个方向使劲。拆解的产出是一份步骤清单清单上每一个节点都对应SKILL.md里的一个章节。你平时是怎么干活、遇到问题怎么判断、做完怎么验证这些都要变成可复现的指令。技能好不好用七成取决于这一步做得细不细剩下三成才看Markdown写得多漂亮。4.2 一份可以直接照抄的SKILL.md模板下面这份结构是我用过比较顺手的适合大多数“流程型”技能。你可以在它的基础上加章节但核心骨架照搬没有问题。--- name: example_skill description: Use this skill when ... (什么时候用、解决什么问题、千万别在什么场景用) --- # Example Skill ## 概述 用三段话解释这个技能的目标以及使用它的背景。 ## 前置条件 - 需要哪些工具或脚本 - 需要用户提供哪些输入 - 哪些数据是必须准备好的 ## 执行步骤 1. 第一步明确需求边界列出必须确认的问题清单 2. 第二步搜索或生成候选方案列出取舍标准 3. 第三步实现核心逻辑注意代码规范 4. 第四步自测与验证确认覆盖边界情况 ## 输出规范 - 输出格式 - 必须包含的内容 - 禁止出现的内容 ## 模板与示例 提供一两个可直接参考的输入输出示例减少模型的自由发挥空间。 ## 常见问题 - 问题A的常见原因与处理方式 - 问题B的常见原因与处理方式写的时候有一条原则宁可啰嗦不能含糊。模型不是行家你少写一个判断条件它就会在实际任务里漏掉那个判断。很多初次写技能的人觉得步骤写得太细会限制模型发挥其实恰恰相反边界越清晰模型在边界之内的创造力反而越稳定。4.3 description和步骤设计里的那些细节description值得单独拎出来说因为它是决定技能“能不能被正确触发”的关键入口。我建议用下面这个公式来写使用场景 具体任务类型 预期处理方式 不适用场景举个例子description: Use this skill when the user asks to design a landing page component, including responsive layout, accessibility, and style consistency. Do NOT use this skill for general backend API design.这样模型看到“landing page component”就能快速匹配看到“backend API”就会主动避开。注意不要堆太多形容词description不是营销文案信息越直接匹配越准。步骤设计上多考虑“回退路径”。技能里最怕写成一往无前的瀑布流第一步做什么、第二步做什么、第三步结束。真实工作流往往有分支模型卡在某个判断点上时需要知道“如果验证失败回去调整哪个参数”。我的做法是在关键步骤后面补一个“异常处理”小节降低模型出错后继续埋头硬扛的概率。4.4 测试和迭代别指望一次写好写完一份skill一定要在真实场景里跑几轮。我的习惯是准备三个档位的测试用例一个基本用例验证主路径一个边界用例验证技能描述里提到的“不使用场景”之外的情况一个错误用例故意给不完整输入看模型的兜底是否合理。跑测试时重点看两件事。第一模型有没有按我预想的流程走第二模型在哪里开始“自由发挥”。凡是模型自由发挥的地方大概率是SKILL.md里没写清楚的地方回去补一段指令再跑。反复迭代几轮之后技能就会从“能回答”进化为“做完整件事”。4.5 新手最容易踩的几个坑我见过的最常见问题一是把技能写成了大而全的百科全书一个人物类技能恨不得覆盖建模、画图、排版、Chat系全部功能结果模型加载起来上下文占了几千token每个功能都很平庸。正确做法是一个技能只解决一条任务线做“窄而深”。二是把路径写死。Skill里如果用了本地脚本记得用相对路径或者放在resources下统一引用。很多人写/Users/username/xxx这种绝对路径换个机器就废了。三是忽略项目级和用户级的边界。项目级的skill要额外考虑团队协作文件尽量不依赖个人环境变量不然提交到仓库后队友没法直接用。5. 场景版图从数学建模到AI漫剧的实战位置5.1 数学建模把竞赛打法沉淀成技能数学建模是codex skills被讨论最多的场景之一原因很简单建模流程非常稳定非常适合沉淀成SOP。华为杯、国赛、美赛这种限时竞赛里团队最怕的是时间浪费在“不知道该往哪个方向试”。一套好的建模skill会把流程做成读题 → 拆解问题 → 确定假设 → 选模型 → 写算法 → 跑数据 → 结果复盘 → 论文摘要。社区里推荐的数学建模skills大多围绕数学建模的节奏来设计有专门的赛题分析技能、算法选择技能、论文排版技能。如果你自己组队打比赛可以按角色拆技能包建模手用模型选择类技能编程手用数据清洗和算法实现类技能写作手用论文生成类技能。每类技能都不复杂但配套起来能让整支队伍的输出质量稳定一个台阶。5.2 前端开发团队规范和AI执行的统一口子前端开发是另一个skills高频关键词理由很实际前端工作重复度高、规范性强特别适合让技能去统一执行。往大里说组件生成、样式规范检查、无障碍标签补齐、响应式布局调试都能做成技能。这类技能最典型的用法是把项目自己的设计规范写进SKILL.md。同样一句“生成一个用户列表组件”没有技能时模型按它的默认审美自由发挥加载了团队前端规范技能后模型会先查组件库、走设计令牌、按项目的命名规则生成代码。这一下就把AI写码从“能用”拉到了“符合团队交付标准”。5.3 创作类场景AI漫剧的分工与一致性在创作场景里ai漫剧常用skills最近被搜得很多。漫剧生产链条长脚本、分镜、角色设计、配音文案、字幕样式环环相扣以前靠人一步步扯皮现在可以用多个技能协同推进。比较实用的搭配是一个脚本生成技能负责把剧情大纲扩成符合漫剧节奏的分集脚本一个分镜技能把文本转成视觉画面描述保持角色外貌和场景风格统一一个字幕和配音文案技能负责输出台词的时间轴和口播稿。这三个技能分开看都不算复杂但它们恰好卡在创作链条里最耗人力的三环能明显减少来回改稿的时间。和编程类技能相比创作类技能更强调“示例”。SKILL.md里的示例越具体模型的风格稳定度越高。写漫剧技能时至少放一个完整的“人物出场描述”模板和一个“分镜列表”模板。5.4 系统整理与日常维护清理和体型控制热搜里还有一群人搜的不是“怎么写技能”而是“怎么清理skills”。其实这不难理解——技能库和衣柜一样只进不出迟早变成灾难。社区里讨论比较多的tibo关于清理skills的方法核心思路就是给技能库定期做减负按“最近触发时间”和“真实效果评分”两个维度排出低价值技能该归档归档该删除删除该合并合并。这套方法放在日常使用里也是成立的。你装了几十个技能后真正高频触发的通常不会超过十个。与其让几十个技能互相抢占模型的注意力不如只留下高频使用的那几个把其余全部移出技能目录需要时再装回来。很多人在清理之后发现原来“技能不触发”“选错技能”的问题先靠砍掉一半技能就能缓解大半。另外技能的“体型控制”也重要。如果一份SKILL.md长得像长篇小说加载它就会消耗大量上下文。我的经验是单个技能的SKILL.md正文尽量控制在300行以内能用资源目录放模板和脚本的就不要全部塞进正文。这既是对自己token钱包的尊重也是提升技能触发准确率的有效手段。在真正跑起来之后我这边的体会是不要一上来就想搞一个包罗万象的巨型技能库。从你每天重复做、做到想吐、但步骤又很明确的那个任务入手把它写成第一个skill跑通了再慢慢扩充。技能这个东西真正的价值不是“多”而是“准”——在模型最可能掉链子的那个环节用结构化的专业流程把它兜住。这个逻辑放在Claude Code里成立放在Codex、OpenCode里也一样成立它本身就是给AI立规矩的新一代基础设施。