最近AI编程圈里有个词出现频率高得吓人——“skills”。不管你是刷GitHub、逛技术社区还是看各种AI工具更新日志都会撞见它。有人用它把Claude Code调教成数学建模老手有人用它批量生产漫剧脚本还有人把前端工作流整个塞进去让AI从“能聊”变成“真能干”。这玩意儿到底是什么、怎么装、怎么写、怎么用在刀刃上我今天一次性说透。我前前后后折腾了大概两个月踩过路径不对、格式错误、上下文爆炸各种坑最后形成了一套比较顺手的玩法。这篇文章就按我自己的实践路径来写从概念、安装、编写到场景实战和问题排查尽量让没接触过的人也能照着操作。1. 先搞清楚skills到底是什么鬼1.1 从“会聊天的AI”到“会干活的AI”先说个很直白的问题为什么大家突然对skills这么上心以前你用Claude、ChatGPT或者各种编程助手本质上是在“对话”。你给它一段指令它在通用知识库里检索然后给你回复。这个过程能用但有两个非常明显的毛病。第一AI对你手头项目的上下文一无所知每次都得现聊聊半天还不一定聊到点上。第二AI的技能是“平均化”的它可能什么都会一点但什么都不精尤其在特定领域、特定工具链、特定操作流程上表现就是不够用。skills解决的就是这两个问题。它本质上是一个结构化的技能包里面装着一份或多份标准化的技能定义文档加上可能的脚本、模板、参考资源。AI工具在启动会话的时候会扫描这些技能包加载里面的指令和知识相当于给AI“上了个岗前培训”。培训完之后它再帮你干活就不是随便发挥而是按照你预定义的最佳实践、检查清单和操作流程来执行。我自己的体会是以前让AI帮我写一个React组件它给我写一个能跑的版本就完事了。但挂了前端开发skills之后它会主动考虑类型定义、错误边界、测试用例、文档注释甚至自动匹配我项目里的代码风格。这就是有没有“技能包”的区别一个像实习生自由发挥一个像有SOP的老员工照着流程干活。1.2 skills、普通提示词和MCP到底啥关系这块容易把人绕晕因为市面上概念太多。我花了不少时间才理清它们的边界简单类比一下。普通提示词像是你在路边给一个人口头描述怎么走到某个地方。你说“往前走左转再右转”说完就完了信息是一次性的对方能不能走对全看悟性。MCPModel Context Protocol像是给这个人装了一个实时导航APP它能动态查询路况、随时获取实时数据、调用外部工具。而skills更像是给他一本详细的岗位手册里面写清楚了你公司的办事流程、审批规范、代码规范、常见问题处理方案他在动手之前先翻阅手册然后照着手册执行。所以这三者的关系不是替代而是互补。MCP解决的是“实时能力接入”skills解决的是“专业流程内置”普通提示词解决的是“单次任务的即席指令”。在实际项目中我通常把MCP当作手脚把skills当作大脑里的操作规程两边配合用效果最好。有人问那我费劲写skills干嘛直接写个超长的system prompt不就行了吗能行但不好维护。prompt越长token消耗越大上下文窗口被挤占得越厉害。skills是独立加载、按需启用的不占对话的主上下文而且可以做到项目级复用。同一个skill这个项目能用那个项目也能用换台机器拷贝过去还能用。这种工程化的组织方式是长prompt永远比不了的。2. 装别人的skills从GitHub到本地的完整路径2.1 手动安装的门道现在最主流的获取渠道是GitHub毕竟skills本身就是开源生态的产物。网上的热词里有一串“claude code怎么手动装github上的skills”我估计不少人在这一步卡住了。其实手动安装没有那么玄乎核心就是搞清楚三件事装到哪个目录、以什么结构放、怎么让工具认出来。不同的AI工具skills的存放路径不一样。以Claude Code为例它默认会去项目根目录下的.claude/skills文件夹里找同时也会扫描用户全局目录下的skills。Codex用的是~/.codex/skills这个位置OpenCode则是看它的配置目录。本质上都是把GitHub仓库下载下来再把对应的skills子目录解压或clone到规定路径下。我第一次手动装的时候犯了个低级错误把整个GitHub仓库的zip包直接塞进了skills目录结果那个目录里嵌套了一层仓库名AI根本扫不到。后来我才明白大部分仓库是“聚合仓库”一个仓库里放着十几个技能包你不能整个丢进去得把里面真正包含SKILL.md的那个子目录放到指定位置。2.2 Claude Code、Codex、OpenCode各自的打开方式我三个工具都实测过分别说下安装路径上的差异方便你对照操作。Claude CodeStep 1进入你的项目目录查看是否存在.claude/skills文件夹没有就手动建一个。Step 2从GitHub仓库里找到目标技能包把整个包含SKILL.md的文件夹下载下来放到.claude/skills下面。Step 3在Claude Code的会话里输入/skills应该能看到已加载的技能列表。如果能看见说明安装成功。这里补充一个注意点.claude目录默认是隐藏的在Finder或资源管理器里记得开“显示隐藏文件”或者直接用命令行操作不然容易以为自己没装成功。CodexCodex的skills生态起步得早而且它跟Claude Code的目录结构还不太一样。安装路径一般是~/.codex/skills同样把技能包文件夹放进去。在Codex里可以用/skills命令列出可用技能。还有一个细节Codex支持在codex.json配置里对某些skills做开关设置如果你希望某个技能只在特定项目里生效可以在这个配置文件里做项目级绑定。OpenCodeOpenCode更偏向轻量级终端工具它的配置路径在安装文档里有明确说明。我实测下来把技能包扔到对应的skills目录后重启会话就能加载上。如果你用的版本比较新甚至支持在配置里远程引用GitHub仓库地址省去了手动下载这一步。2.3 装完怎么验证真的生效了很多人装完技能包不知道到底有没有生效傻乎乎地直接问AI“你现在有什么skills”得到的回答五花八门根本判断不了。这里教你两个更靠谱的验证方法。方法一在会话里输入/skills看看列表里有没有你刚装的那个技能名。有就说明文件被扫描到了。没有说明路径或者目录结构有问题。方法二直接让它执行一个技能相关的任务。比如你装的是一个“git commit message生成器”技能就让AI“用git commit技能帮我生成这次的commit信息”。如果它给出的commit信息符合你的规范模板说明技能真的被调用了。如果它答得跟普通对话没区别大概率是技能没被加载或者是技能描述写得不够清晰AI不知道什么时候该用。这个方法二特别重要因为有些技能包装好了但AI根本不知道它存在也不会主动调用。这不是bug是你的技能描述description字段写得不合格。这个问题我在第3章会详细说现在先记住描述写不好技能等于白装。2.4 值得收藏的skills源网站网上关于“常用skills源网站”的提问很多我把自己试过且觉得靠谱的几个方向整理一下。第一梯队是GitHub上的知名聚合仓库。主流的AI编程工具基本都有官方或社区维护的skills合集比如Claude Code官方仓库里的skills目录、Codex官方文档推荐的skills列表。这些包质量有保障更新也勤快建议新手从这里起步。第二梯队是各类技术博主整理的“skills精选合集”。这类合集往往带有评测和横向对比比你自己在GitHub漫无目的地搜索效率高得多。搜索的时候可以带上“awesome skills”这类关键词往往能翻出不少精筛过的资源。第三梯队是直接搜你要解决的问题。比如你想找“数学建模skills”就去GitHub搜“math modeling skills”或者“codex skills mathematical”你想找“前端开发skills”就搜“frontend skills claude code”。以问题为导向搜索比泛泛收藏强得多。注意下载第三方技能包之前务必花30秒看一眼仓库的目录结构留意一下最近更新时间。有些仓库两年不更新里面的配置格式早就过时了装进去不仅不生效还可能因为引用了旧版本的工具API导致频繁报错。3. 自己写skills生产一个能被AI调用的技能包3.1 SKILL.md的结构深度拆解自己的需求永远比现成的技能包贴合这也是为什么我强烈建议你掌握skills开发的基本功。一个标准技能包的核心是一个名为SKILL.md的Markdown文件这个文件名是统一的不能改AI就靠它来识别技能。这个文件一般分成两部分。上半部分是YAML格式的frontmatter为AI提供技能的基础元信息下半部分是正文填充技能的具体执行逻辑。frontmatter里最关键的字段有name技能的唯一标识尽量用短横线连接的小写英文。description这个字段极其重要它决定了AI什么时候会主动启用这个技能。写的时候不要写“这个技能用于帮助用户”而要写“当用户需要XXX时使用此技能”要把触发场景描述清楚。allowed-tools指定这个技能可以调用的工具白名单不写的话默认继承全局配置。正文部分则完全是自由发挥但优秀的技能包都有几个共同特征先写技能的触发条件和预期输出再写详细的执行步骤接着给一个可复用的模板或示例最后补上一个检查清单来兜底。我自己写技能包的时候最花心思的就是description这个字段。我见过太多人在这里敷衍了事写一句“提供XX帮助”就完了结果AI根本不知道这个技能在什么情况下该被翻出来。要记住AI在调用技能之前靠的是语义匹配你的描述越贴近用户问题的表达方式技能被启用的概率越高。3.2 写skills最容易翻车的三个地方第一试图把技能包做得“大而全”。一个技能只负责一类任务就够了你非要在一个SKILL.md里塞下前端开发、后端开发、数据库优化、部署运维全部的流程结果就是每个任务都干不深AI会因为上下文太长而丧失对关键细节的关注度。正确的做法是拆拆成一个一个独立的技能每个技能只聚焦一条主线。第二忽略技能的幂等性和环境假设。你写技能的时候脑补的运行环境和用户实际的环境很可能是两回事。比如你让AI执行一段bash脚本但没明确说你假设的是macOS还是Linux没说明需要提前安装什么依赖结果脚本跑到一半就因为环境问题挂掉。技能包写得越显式越好不要把任何前提条件当作“理所当然”。第三不给AI提供“判断余地”。有些技能写得太死AI只能照着弯路走到黑遇到不符合预期的情况也不会灵活变通。好的技能应该同时包含“标准流程”和“异常分支”明确告诉AI在什么情况下应该偏离标准流程。3.3 实战示例写一个“数学建模辅助”技能我看热词里有“华为杯建模比赛好用的codex skills”“数学建模skills推荐”说明这个领域需求很大。我就以“数学建模辅助”为例演示一个技能包从零到成为的过程。先创建目录结构math-modeling-assistant/ └── SKILL.md再写SKILL.md的内容--- name: math-modeling-assistant description: 当用户需要数学建模相关的解题思路、模型选择、论文撰写或代码实现时使用此技能。适用场景包括但不限于竞赛建模、课程建模、数据分析和算法设计。 allowed-tools: - python - bash --- # 数学建模辅助技能 ## 触发条件 用户提出以下类型需求时启动此技能模型选型建议、建模思路设计、算法代码实现、论文结构优化、结果分析。 ## 执行流程 1. 解读问题先帮助用户把问题的数学描述整理清晰明确变量、约束、目标函数。 2. 模型推荐根据问题特征推荐2-3个候选模型并列出每个模型的适用条件和优缺点。 3. 代码实现使用Python实现推荐模型优先使用numpy、scipy、pandas、sklearn、pymoo等库。 4. 结果分析输出结果时必须包含可视化图表matplotlib或plotly和数值评估指标。 5. 论文辅助提供建模假设、模型建立、模型求解、模型检验的标准论文结构模板。 ## 常见模型速查 | 问题类型 | 推荐模型 | 关键库 | |---------|---------|-------| | 预测问题 | 回归、时间序列、LSTM | statsmodels, prophet, torch | | 分类问题 | 逻辑回归、随机森林、XGBoost | sklearn, xgboost | | 优化问题 | 线性规划、遗传算法、粒子群 | scipy.optimize, pymoo | | 评价问题 | AHP、TOPSIS、熵权法 | 自实现 | ## 检查清单 - [ ] 是否明确了建模目标 - [ ] 是否给出了模型选择理由 - [ ] 代码是否有详细注释 - [ ] 结果是否有可视化图表 - [ ] 是否附上了敏感性或鲁棒性分析这样一个技能包放到对应的skills目录下AI下次遇到建模相关需求时就会主动按照这个流程来执行。你不需要在每次对话里重复交代“要用哪些库”“要输出什么格式”技能包把这些都固化了。3.4 调试与迭代让技能从能用到好用技能的第一次版本基本上不会太好用这太正常了。我的做法是每写完一个技能包先小范围实测三轮。第一轮输入一个最简单的场景看AI能不能识别到技能并触发。只要触发就说明description写得及格了。第二轮输入一个复杂场景看AI执行流程是否符合预期检查它在哪个步骤跑偏了。跑偏的地方往往就是文案有歧义的地方。第三轮故意输入一个边界场景试试技能包会不会给出错误引导。每轮测试完回SKILL.md改描述、补流程、加约束迭代两三次之后技能基本就能达到“拿得出手”的水平。我有个前端开发的skill前后迭代了五版才稳定下来但一旦稳定下来它带来的效率提升是指数级的。4. 高频场景实战前端、漫剧、超级技能4.1 前端开发skills从工具链到UI生成前端是skills应用最成熟的方向之一。热词里“前端开发skills”的搜索量一直很高确实前端的工具链长、规范多、重复劳动密集太适合用技能包把经验沉淀下来了。我自己维护的前端技能包里包含了几个子模块。第一个是初始化规范让AI在创建新项目的时候自动按我指定的目录结构建文件装好我惯用的依赖版本组合。以前新起一个项目光配置文件就要折腾半小时现在一句话就把骨架搭起来了。第二个是组件生成规范要求AI产出的React组件必须包含类型定义、props校验、默认值、样式方案不能只是“能跑就行”。第三个是代码审查清单我在做完功能后会让AI照着清单过一遍代码检查边界条件、性能隐患和可访问性问题。这里我分享一个心得前端skills用得好不好很大程度上取决于你把自己的工作流梳理得有多清楚。如果你自己都说不清要什么AI就更不可能知道。所以动笔写技能之前先把你的日常流程从头到尾整理一遍把那些你闭着眼睛都会做的步骤写下来它们就是技能包最好的素材。前端还有一个热门方向是AI生成UI。有博主已经在用skills统一管理“从需求描述到设计稿再到前端代码”的完整链路一个技能包负责拆解需求另一个负责生成Tailwind组件还有一个负责无障碍检查。这种做法很有参考价值相当于把一个人工智能前端小组装进了你的编辑器里。4.2 漫剧创作skills从分镜到配音“AI漫剧常用skills”出现在热词里我一开始还挺意外深入研究了一下发现这个场景比我想象的成熟得多。AI漫剧的生产链路大致是先有小说或剧本然后拆成章节和分镜再生成画面素材最后配上音效和配音。这条链路里有大量结构化的工作非常适合用skills来承接。我见到有人做了“分镜拆解”技能能把一段小说文本自动拆成分镜表包含景别、角色动作、台词、时长预估。还有人做了“提示词工程”技能把画面生成的提示词按“角色一致性”“光影风格”“构图比例”等维度组装好专门喂给绘图模型用。这些技能包的共同点是它们都是把“老师傅的经验”翻译成了AI能执行的清单。如果你也想搞漫剧创作我建议先从最耗时的环节下手。就我了解到的情况很多创作者最痛苦的是“角色一致性”问题同一个角色在不同镜头里长得不一样。这个问题的核心其实不完全是skills能解决的模型本身的限制占大头但技能包里可以通过强制性的角色描述符来缓解。比如要求每次生成画面时都带着同一套角色特征描述而不是让AI自由发挥。4.3 superpower skills是啥值不值得装“superpower skills”在热词里出现了好几次这个项目在GitHub上star数很高很多人把它当作“必装技能合集”来推荐。我来给个稍微冷静点的评价。它的本质是一个大型技能包合集里面包含了从代码开发、文档写作到项目管理、数据分析的一系列技能。优点是覆盖面广安装一次就能获得很多能力而且它的设计思路确实有水准很多技能包的触发条件和执行流程写得比我见过的大多数个人技能包都要专业。你要是刚接触skills不想自己动手从头写装它试试完全值得。但它的缺点也很明显。第一技能太多会导致上下文负担加重AI每次扫描技能列表的时间变长在个别场景下甚至会出现技能互相干扰的情况。第二它是通用型合集针对性不强。你做一个垂直领域项目时里面的大多数技能可能都用不上但你依然要为它们付出扫描成本。第三它是别人定义的工作流不一定符合你的习惯。你用了它的代码审查技能就得接受它的审查标准这个标准不一定适配你团队的风格。我的建议是新手阶段可以装整套用来感受“有技能”和“没技能”的区别。等你用熟了想清楚自己在哪些场景里高频用哪个技能了就建立自己的精简技能库只留高频的、好用的把用不上的全部清理掉。4.4 不同工具的skills生态差异同样一个技能包在Claude Code、Codex、OpenCode里的体验和兼容性可能完全不同。Claude Code的skills生态最丰富社区贡献最多而且它的目录规范和技能识别机制相对成熟。我测试下来大部分为Claude Code写的技能包都能稳定运行。Codex的skills体系跟OpenAI的Agent体系绑定比较深对工具调用的支持更底层但正因为这样它的技能写起来自由度很大上限很高同时对开发者的要求也更高。OpenCode的生态还在早期但胜在轻量适合只想快速跑通流程的实验用户。在这些工具之间切换使用时要注意同一个技能包可能因为frontmatter字段的解析差异而在不同工具里表现不一致。比如某个技能在Claude Code里能被正常识别换到Codex里却不生效多半是字段命名或格式不兼容。我的实操建议是以你主力工具的文档为准把技能包写成“最小公共子集”格式尽量只用所有工具都通用的字段这样换工具的时候不至于完全报废。5. 常见问题与排查技巧实录我把自己实操中踩过的坑和一些高频问题整理成了一张速查表方便你遇到问题时直接对号入座。现象可能原因解决办法技能列表里看不到刚装的包路径不对或目录嵌套错误确认目录里直接包含SKILL.md不要多套一层仓库文件夹技能能被看到但从不被调用description字段写得太模糊重写description明确写出哪些用户需求会触发本技能AI执行技能时行为不符合预期技能文档步骤不清晰或有歧义增加更细的执行步骤补充示例用更显式的指令会话响应速度变慢skills数量过多、扫描负担大清理不用的技能包只保留高频使用的不同工具间技能包不通用frontmatter字段格式不兼容改用各工具都兼容的字段子集按主力工具文档调整技能执行时报工具缺失技能包假设的环境与实际情况不符在技能包的环境准备段落补充依赖安装说明还有一个高频问题我必须单独拿出来说就是“怎么清理skills”。很多人装了十几个技能包发现问题之后根本不知道哪些技能在生效、哪些是僵尸技能占着位置。我自己的管理习惯是每个技能包文件夹的命名都带一个前缀标识用途比如web-开头的是前端相关、math-开头的是建模相关。这样清理的时候扫一眼目录名就知道去留。清理的时候需要注意直接在文件管理器里删除文件夹前先看一下你的AI工具是否正在运行建议先退出会话再删。删除后重启会话再次用/skills命令确认一下列表干净了。这个方法被很多人问过我干脆把它写成了自己的固定操作步骤。6. 个人实操心得与建议说到这最后分享几个我自己的结论。skills这套机制的核心价值不在于“让AI多会几个技能”而在于把你自己从重复性工作里解放出来。以前我写一个PDF表格提取工具从搭建环境到调试完成得花大半天。现在我把“表格识别与结构化输出”的技能包写好之后类似任务基本一句话就能完成。这种边际成本趋近于零的感觉用过一次就回不去了。对于刚开始接触skills的朋友我的建议是不要贪多。先选一个你每天都会做、流程最固定、最消耗时间的任务专门为它写一个技能包。把这个技能包写到“真正能帮你省时间”的程度你会获得极大的正反馈然后再用它驱动自己去开发第二个、第三个技能包。反过来如果你一开始就装了几十个技能包天天被系统提示、上下文占用、格式兼容这些问题折磨很容易对这个机制失去信心。如果你的目标是参加数学建模竞赛之类的高强度任务那我特别建议提前把技能包准备好。建模比赛最缺的就是时间而skills恰好能帮你把“模型选型”“代码生成”“论文排版”这些环节压缩到极致。我之前给朋友写过一套比赛用的技能组合从读题到出初版论文花了不到四个小时放到以前是难以想象的。最后再留一个小技巧写技能包之前先去看几个star数高的开源技能包是怎么组织内容的。好的技能包读起来像一份教科书级的SOP它的触发条件、执行流程、检查清单都写得清清楚楚。你不需要模仿它的具体业务逻辑但完全可以借鉴它的结构框架。看五六个优秀案例之后你写出来的技能包质量会有肉眼可见的提升。所有这些经验都是我在大量试错之后攒下来的。skills这套东西还在快速演进今天的写法明天可能就变了但你只要掌握了一件事——理解AI是如何“阅读”和“执行”技能包的那么无论生态怎么变你都能快速跟上。