最近大半年AI编程圈里最热门的词除了MCP就是Skills。你要是用Claude Code或者Codex写代码多多少少都刷到过“装了某个skill之后AI写前端速度快了一倍”之类的帖子。我自己从2025年Q3开始重度折腾skills前后装了几十个有的一装就香有的装完就吃灰中间踩的坑攒了一箩筐。今天就把这些经验一次性倒干净skills到底是什么、怎么手动装GitHub上的skills、怎么写自己的skill、数学建模和AI漫剧这些场景里怎么玩、最后怎么清理维护。新手照着操作能跑通老手也能捡几个我花时间换来的细节。1. Skills到底是什么一次说清定位、结构与运行逻辑1.1 一个skill包拆开来看是什么先直接点破一个skill在文件系统里就是一个目录。目录里必须有入口文件SKILL.md可选assets、scripts、references等子目录。SKILL.md内部用YAML frontmatter声明name和description后面是自由Markdown正文正文里可以写工作流程、输出模板、注意事项。我随便扒一个GitHub上热门仓库的典型结构my-skill/ ├── SKILL.md ├── scripts/ │ └── check_env.py └── references/ └── best-practices.mdClaude Code的agent skills机制会在对话时扫描这些目录Codex类似OpenCode也支持。关键点在于description是常驻在模型上下文里的而SKILL.md正文只有在任务触发时才被完整加载。这意味着什么同样一个能力用skill比把一整段提示词塞进system prompt要省token而且触发更精准。这也是为什么现在的AI编程工具都在推skills而不是让你继续写几百行的system prompt。1.2 为什么偏偏是SKILL.md这种设计要理解这个设计先得明白模型上下文是稀缺资源。你如果每次把一份几千字的专业流程全量塞进对话模型很容易被无关信息干扰中间部分还会被遗忘就是所谓的lost in the middle问题。Skills走的是渐进式披露progressive disclosure思路先用一小段description描述“什么时候用、能干什么”让模型判断要不要打开这个skill。一旦打开正文再逐步引导它读取references、调用scripts。这个思路本质上就是lazy loading——标签常驻内容按需加载。我实际做过对比同一个代码评审流程写在system prompt里大概多消耗30%的上下文触发稳定性还不如用一个skill。大模型的注意力是有限的你给它越少噪音它执行主任务就越不走样。注意description不是给你看的是给模型看的。你写“这是数学建模全面助手”这种废话模型根本不知道什么时候该调用它。好的description要包含触发条件、适用任务、能力边界后面我会给示例。1.3 Skills和MCP不是竞争关系很多人一上来就问“有MCP了还要skills干嘛”我理解这种疑问但它俩定位完全不同。MCP更像外接的“手”——通过工具调用帮模型拿数据、操作外部系统比如读数据库、调API、操作浏览器。而skill更像是“大脑里的操作手册”——告诉模型按什么流程、什么标准去完成一类任务。你可以用MCP让模型读取某个项目的代码再用一个code-review skill指导它按你的规范去评审两者配合非常顺。正确姿势不是二选一而是先把skill层做厚再按需接MCP。我在实际工作流里MCP工具不超过五个但skill会维持十个左右覆盖高频重复任务。2. 手动安装GitHub上的Skills三种主流工具的完整实操2.1 Claude Code里最省事的方式plugin marketplace如果GitHub仓库按Claude Code插件规范组织也就是根目录有.claude-plugin/marketplace.json那安装是命令行级的。在Claude Code里执行/plugin marketplace add owner/repo /plugin install skill名marketplace.json会声明这个仓库里有哪些plugin、哪些skill、各自的路径。装完执行/plugin status能看到清单。这种方式好处是后续拉更新方便缺点是需要仓库本身按规范组织。很多随手分享的skill仓库并不符合这时候就得手动装。2.2 真正的“手动装”直接把skills目录拷进去很多仓库其实就是纯skills集合没有marketplace.json。这时候不需要插件市场手动拷贝就行。核心逻辑就是把每个skill目录放进Claude Code的skills搜索路径。用户级路径一般是在~/.claude/skills/项目级路径是.claude/skills/项目级优先级更高。操作步骤把仓库clone到本地找到里面所有包含SKILL.md的目录一般是一级或二级目录把需要的skill目录完整复制到~/.claude/skills/下或者复制到当前项目的.claude/skills重启Claude Code会话用skill描述里的任务动词发起请求看是否触发这里我踩过一个很典型的坑只复制了SKILL.md没把scripts、references一起复制结果skill能识别但运行时找不到脚本。所以复制的时候要整个目录一起拷千万别精简。Codex和OpenCode的机制类似无非是路径不同一般都在各自配置目录下比如~/.codex/skills/、~/.opencode/skills/不同版本可能有差异但核心思路完全一致目录加SKILL.md。2.3 安装后怎么验证真的生效了很多人装完说“没看到效果”其实不是skill的问题是验证方法不对。我建议三步走确认路径对在对应工具里查看skills列表或者plugin status开一个干净会话用description里的触发词发起任务比如装的是代码评审skill就直接说“帮我review一下这段代码”别用模糊的“帮我看看”观察模型输出结构是否变化生效时它通常会按skill规定的章节、维度输出如果完全没变化多半是没识别到如果部分生效多半是description写得不够准导致模型触发不稳定。先分清是哪一种再对症下药。3. 自己动手写Skill一份能用的SKILL.md是怎么诞生的3.1 先写description决定这个skill由谁触发整个SKILL.md里最影响成败的就是frontmatter。给你一个我自己在用的模板--- name: math-modeling-guide description: 数学建模竞赛解题流程助手。当用户需要完成数学建模题目、选择模型、撰写建模论文时使用。覆盖问题分析、模型选择、求解、结果检验、论文结构五个阶段。不适合纯数值计算。 ---name保持简短英文小写加连字符description才是灵魂。我见过太多人的skill不生效都是因为description把“是什么”写得很华丽却没有写“什么时候用”。模型靠description判断是否调用skill所以触发指令要明确边界也要明确否则它会在不该用的时候硬套该用的时候反而漏掉。3.2 正文按流程写让模型一层层往下读正文不要一口气把全部细节倒出来。最好的写法是先给overview再分阶段给指令复杂的部分丢到references里。拿数学建模skill举例正文可以这样组织阶段一问题重述与假设要求先列出建模目标、约束条件、数据情况阶段二模型选择按数据类型和问题类型给出决策树阶段三求解步骤指明用什么工具、脚本怎么调阶段四结果检验包括敏感性分析和误差指标阶段五论文结构给出章节模板每个阶段用二级标题分隔模型读到哪一步就执行哪一步不会因为一次塞太多导致执行混乱。3.3 加脚本和参考资料让skill真正能落地纯文本的SKILL.md只能约束思考方式但很多任务需要实际执行。比如建模里要算熵权法、灰色关联度你可以写一个Python脚本放在scripts/下SKILL.md里用bootstrap声明依赖--- name: entropy-weight description: 计算熵权法指标权重。当用户需要做客观赋权、计算指标权重时使用。 bootstrap: python scripts/check_env.py ---或者直接在正文里指示模型当进入模型求解阶段时运行scripts/entropy_weight.py。这样skill就从“提示词”变成了真正的“工具包”。依赖要写清楚脚本开头做环境检查缺库就报清晰错误方便排查。注意skill不是越复杂越好。一个skill只干一件事复杂任务拆成多个skill互相配合维护起来比自己骗自己好用得多。我一开始写过一个巨大的“全能开发助手”skill后来发现模型经常只触发一半改成几个小skill之后稳定多了。4. 实战场景数学建模、前端开发与AI漫剧里怎么用Skills4.1 数学建模从“会聊天”到“按套路出活”数学建模比赛包括华为杯这种研究生竞赛最大的痛点不是AI不会做而是AI输出太散。每个队伍都要经历问题分析、模型选择、求解、检验、论文撰写如果让AI自由发挥它的回答每次都不一样风格和深度完全不可控。用skill把这些环节固化成流程后AI的输出就稳定得多。社区里流传的数学建模skills推荐做得好的基本都是把常见模型比如层次分析、回归、优化、微分方程、神经网络以及对应适用条件做成了决策表再配一套论文写作模板。我自己在实战里的做法是先装一个模型选择skill用它快速锁定问题类型再让一个论文结构skill接管后续写作。这样上下文切换干净不容易串味。之前也试过一个skill搞定全流程结果就是前后风格割裂效果反而不如拆分。4.2 前端开发把视觉需求变成代码的流水线前端大概是skills最早火起来的场景。从设计稿转代码、响应式布局检查、组件测试生成都有现成的包。superpower skills里的视觉拆分是很典型的一个。我自己常用的有两个一个负责从截图描述UI细节输出风格指南一个负责代码审查按性能、可访问性、可维护性输出修改建议。这两个配合起来等于给Claude配了个前端质检员。如果你是写React或Vue的强烈建议至少装一个能产出设计规范的skill。实测下来设计还原度和代码质量都明显上一个台阶模型不会再一脚踩进“凭感觉配色”的坑里。4.3 AI漫剧创意生成也需要流程化AI漫剧这种内容生产场景表面看是创意活实际极其流程化定角色、写分镜、生成画面描述、配文案。圈子里的常用skills本质上是把漫画分镜提示词做成了可复用模板。比如角色一致性skill会要求第一步定义角色卡第二步输出多视角参考图描述第三步给分镜脚本模板。这样做的好处是团队协作时每个人用同一套skill产出的风格和格式高度统一省掉大量后期对齐成本。我看了几个AI漫剧常用skills发现它们的共同点都是“把创作拆成固定步骤固定模板”你只要记住任何重复性的创作流程都可以沉淀成skill。5. 推荐技能库与维护清理别把家底装成垃圾堆5.1 值得关注的几个开源技能库聊几个我在GitHub上真装过、社区热度比较高的obra的superpowers我给它的定位是“流程启动器”里面每个skill都教模型按特定步骤推进任务比如深度研究、代码调试、任务规划。它不直接给你答案而是教AI怎么一步步想。适合当底层技能库。typesafe的ai skills偏工程化很多skill和主流开发框架强相关适合做后端和全栈的开发者。GitHub上有专门仓库分类清晰装前先看目录结构。社区合集类像codex nature skills、cola skills这类通常是网友按自己工作流整理的集合优点是场景具体缺点是质量参差。安装的时候别整个仓库全装只挑跟自己的工作流匹配的。我一开始见啥装啥最后光skill目录就几百兆AI反而变笨了——可选方案太多模型频繁误触发输出变得很“飘”。5.2 定期清理tibo的清理思路我也照着做过清理skills这件事我之前看到tibo分享过一套方法照着做了一遍非常实用先备份整个skills目录防止删错打开最近一个月的工作记录统计哪些skill被触发过把从没触发过的skill先移出主目录放到retired目录过两周确认不影响工作后再彻底删除还在用但有重叠的skill合并同类项这套思路看起来简单但比凭空看文件名猜用途靠谱得多。我的习惯是每季度做一次每次都能删掉至少三分之一从来没触发过的僵尸skill。别心疼那些吃灰的收藏留着它们只是给模型制造噪声。5.3 多工具共用时的注意事项如果你同时用Claude Code、Codex、OpenCode同一个仓库的skills可能要放在不同目录格式也可能有差别不要想当然认为完全通用。我的做法是在本地建一个skills-dev目录集中管理源码用脚本按目标工具复制到对应目录改完一处同步三处。别看这个动作小能避免“在Claude Code里更新了Codex那边还在用旧版”这种低级但极常见的问题。6. 常见问题与排查技巧实录6.1 装了没反应90%出在三个地方先说结论。第一路径不对或者SKILL.md文件名大小写不一致系统压根没扫描到。第二frontmatter格式错了YAML解析失败整个文件被忽略。第三description写得像产品宣传语模型判断不了什么时候用。排查时先看路径再看语法最后换一个带明确触发词的指令测试。不要一上来就怀疑工具本身不行我见过太多人把锅甩给AI其实问题就出在skill文件本身。6.2 多个skill冲突时怎么处理当两个skill的触发条件高度重合时模型会犹豫甚至同时触发输出就会很拧巴。解决办法是给description加边界词比如一个写“适用于前端项目评审”另一个写“适用于Python项目评审”让它们隔离。如果仍然冲突就直接合并成一个skill内部用条件分支区分场景。记住一个原则skill不是越多越好而是边界越清晰越好。6.3 脚本依赖和权限问题带scripts的skill最容易翻车。典型情况Python脚本用了某个库但环境没装脚本没有可执行权限Windows环境下shell脚本无法运行。我在写skill时会在脚本开头做环境检查并给出人类可读的错误提示同时所有脚本都显式设置执行权限。如果一个skill要给别人用务必在SKILL.md里写清楚依赖清单否则别人装完跑不起来体验会非常差。6.4 常见问题速查表现象可能原因快速处理完全不生效SKILL.md不在扫描路径内检查skills目录位置和文件名大小写偶尔生效description触发词不明确重写description加入任务动词和边界输出结构混乱多个skill触发条件冲突给description加场景边界或合并skill脚本报错依赖缺失或无执行权限安装依赖检查shebang设置执行权限上下文变大skill正文过长或常驻精简正文把细节移到references更新后没变化旧进程未重启重启会话确认加载了新路径踩过这么多坑之后我对skills的判断是这样的它不会取代MCP也不会取代工程经验但它把“如何让AI稳定输出”这件事从玄学变成了工程。你完全不用追求装几十个skill真正好用的通常是那几个跟你工作强相关的。先从手动装一个GitHub上的skill开始跑通之后试着自己写一个你会发现AI协作的质量会有一个明显的跳跃。哦对了最后再分享一个小技巧本地维护skills时把SKILL.md和脚本全部放进Git仓库管理每次改动用commit记录出问题随时回滚。我第一次因为改坏一个脚本又找不到原版硬是重写了半个下午从那以后就老老实实上Git了。