大概从2024年底开始skills这个词在AI编程圈里的热度就没下来过。我最初是在Gemini的Skills功能上线后跟着教程把官方示例装进本地环境后来Claude Code、Codex、opencode这类工具都把skills当作核心能力往前推GitHub上的相关仓库也越起越多从数学建模到前端脚手架、从漫剧分镜到数据分析几乎每个方向都能找到现成的技能包。这一轮的变化不在于提示词本身有多神奇而是把重复的、经验性的工作方法打包成Agent可以稳定执行的模块等于给AI配上了一套岗位说明书。这篇文章不打算写成官方文档的复读机主要分享几件我实际摸过之后才理解的事skills和普通提示词到底差在哪、没有图形入口怎么手动装GitHub上的skills、自己写一个能用的skills需要哪些组成、以及不同场景建模、前端、漫剧、日常开发该从哪些地方挑skills。如果你想快速上手又不想被各种仓库的README绕晕这篇应该能帮你省下不少时间。1. 先别急着装skills先弄明白它到底是什么1.1 Skills和普通提示词的本质区别很多人第一次接触skills时会下意识觉得这不就是一段写好的提示词吗。我第一次也是这样想的直到我把同一个任务分别用直接在对话里粘贴提示词和挂载一个skills去跑才意识到两者完全不是一回事。普通提示词是一次性的。你今天让它按数学建模论文的格式整理摘要它做完了这段经验就留在对话历史里换个新会话又得重新讲一遍。而且提示词是线性文本Agent在执行到一半时如果发现缺少某个工具或者需要参考某个模板文件它只能靠猜猜错了就是一顿瞎折腾。Skills则是结构化的。它包含一个描述文件通常叫SKILL.md里面写清楚这个技能解决什么问题、适用于什么场景、有哪些执行步骤、输出格式怎么定它还可以携带脚本和模板文件。Agent加载skills之后相当于多了一个可查阅的手册可调用的工具箱它会根据当前任务判断是不是要走这套流程走流程时每一步都有据可依。用个不恰当的比方普通提示词是你在路边找了一个临时工交代一句干一句skills是给这个临时工发了一本工作手册、一套工具和一份验收标准他自己就能按工序干活。1.2 一个skills包的典型目录结构不管是Gemini的skills、Claude Code的skills还是社区里的codex skills目录结构大差不差。我随便找一个开源仓库举例my-skill/ ├── SKILL.md # 技能说明核心文件 ├── scripts/ # 可选可执行的辅助脚本 │ └── check_output.py ├── templates/ # 可选输出模板、论文模板、代码模板 │ └── report_template.md └── assets/ # 可选参考图片、样例数据SKILL.md是灵魂Agent加载skills时第一时间读的就是它。脚本和模板属于弹药什么时候用、怎么用都在SKILL.md里说明。我见过有人把一整套数据处理流程写进SKILL.md然后配一个几十行的Python脚本直接在建模比赛里跑出一版带图表的分析报告效果相当可观。1.3 为什么全网都在收集skills这波skills热潮不是某个厂商造出来的概念而是被实际效率推起来的。以前换工具要重新调教换模型要重写提示词现在装一个skills基本能跨工具复用——同一份SKILL.md只要兼容标准放进不同Agent工具的skills目录下都能跑。再叠加开源社区的自发贡献GitHub上已经有大量现成技能包覆盖数学建模、前端开发、AI漫剧、简历优化、论文润色这些高频场景安装成本越来越低收益又是立竿见影的。所以我的建议是不要一上来就自己写。先去摸清现有的skills有哪些、长什么样、别人踩过什么坑再决定是直接拿来用还是改造成自己的。动手之前先看货这是我这几个月下来最深的体会。2. 手动装GitHub上的skills不走官方市场的那条路2.1 为什么需要手动安装现在不少工具内置了skills市场或一键安装入口但它有几个现实问题一是市场里的技能包数量有限很多优质仓库只在GitHub维护二是部分工具的市场功能还没全面开放或者需要特定版本才支持三是你在公司内网环境访问在线市场往往受限。我所在的团队就有过这样的情况官方市场里找不到合适的数学建模技能反而是GitHub上一个个人维护的仓库非常对口。所以学会手动安装是必须的。手动安装不依赖任何图形界面只需要两样东西一个GitHub仓库地址一个能用的终端。2.2 手动安装三步走以Claude Code为例整个流程可以拆成三步。其他工具大同小异无非是目标目录名不一样。第一步把仓库克隆到本地。假设你想装一个superpower skills套件在终端里执行git clone https://github.com/example/superpower-skills.git如果你只是想要仓库里的某一个子目录不需要整个clone可以用稀疏检出避免把无关文件拉下来污染本地环境git clone --filterblob:none --sparse https://github.com/example/superpower-skills.git cd superpower-skills git sparse-checkout set math-modeling第二步把skills目录复制到工具的skills路径下。Claude Code通常读取~/.claude/skills/目录Codex一般用~/.codex/skills/opencode则有自己对应的配置目录。先确认你用的工具实际读取哪个目录最稳妥的办法是看官方文档或者在一个空目录下建一个SKILL.md然后问Agent你现在有哪些skills可用它会直接告诉你。假设确认好了执行mkdir -p ~/.claude/skills cp -r math-modeling ~/.claude/skills/第三步重启会话让Agent重新扫描skills目录。这一步看着简单但很多人会忘不重启的话新装的skills不会出现在可用列表里。重启后可以输入几句测试话术比如列出你拥有的所有skills并简要说明各自用途确认目标技能已经加载。整个安装过程五到十分钟真正容易出问题的反而是那些想当然的细节。2.3 安装后必做的三件事第一件事看权限。Skills如果带了可执行脚本Agent调用时会请求执行权限。不同工具对脚本执行的管控方式不一样有的需要你在配置里显式放行有的会在调用时弹确认。建议先找一个无害的小技能跑一遍确认权限链路是通的别等到比赛前两小时才发现脚本根本执行不了。第二件事查依赖。很多skills都有附加依赖比如Python包、Node模块、外部API Key。SKILL.md里通常会写但有些人写得不全需要你去scripts目录翻一翻import语句手动补齐环境。我在装某个数据处理skills时就遇到过缺pandas-gbq的情况补齐之后才能正常读数据库。第三件事跑官方的demo或测试用例。如果仓库里自带示例输入一定要跑一遍。跑通了再看输出质量再决定要不要长期保留。跳过这一步直接上生产项目风险很高因为有些skills在你预期的场景里表现很好换个场景输出就是另外一回事。3. 手写Skills从看别人的到写自己的3.1 动手之前先回答三个问题收藏了一堆skills之后你大概率会冒出我也想写一个的念头。我的建议是先回答三个问题再动手。这个技能服务于什么高频重复任务哪些步骤可以标准化成固定流程输出结果有没有明确的验收标准如果三个问题都能给出清晰答案这个skills值得写。如果只是我觉得AI应该帮我做这件事先忍住很可能你需要的只是一段提示词。以我自己写的数学建模选题评估skills为例。当时的任务背景是华为杯这类建模比赛里队伍经常要在选题阶段快速判断赛题适不适合我们做需要综合考虑数据可得性、模型复杂度、团队擅长方向等多个维度。这个过程每届比赛都要重复且决策逻辑相对固定非常适合打包成skills。3.2 一个最小可用skills的文件构成我写skills的习惯是先用最小结构跑通再迭代加细节。最小结构就是一个SKILL.md顶多加一个脚本。SKILL.md不需要长篇大论但要具备几个关键字段我一般用YAML开头--- name: math-modeling-topic-evaluator description: 用于数学建模竞赛选题评估从数据可得性、模型匹配度、团队能力三个维度分析赛题可行性输出评分建议。 ---然后正文写清楚的执行步骤。这里特别关键的一点是不要写抽象口号要写Agent能照着做的动作。比如评估数据可得性这种表述太笼统应该拆成检查题目是否给出数据源如果没有判断常见公开数据平台是否可能覆盖按1到5打分并给出分数依据。我还会在SKILL.md里放一个输出格式示例让Agent照着填空。不要指望它自由发挥出你要的结构给模板是最省心的方法。3.3 迭代打磨自己的技能体验写完第一版不要急着分享先拿真实任务压测几轮。我发现几个常见问题一是流程描述顺序和实际执行顺序不一致Agent会严格按照文本顺序执行所以步骤先后一定要反复确认二是输出模板给得太死一旦输入边界超出预期Agent反而不知道怎么填空三是缺异常处理比如数据缺失时该走什么分支。以我的选题评估skills为例第一版没有考虑赛题数据不完整的情况结果Agent在遇到一道数据描述很模糊的赛题时评分直接僵硬。后来我在SKILL.md里加了一条规则数据可得性低于2分时直接输出建议放弃并触发备选赛题分析流程。改完之后它的判断逻辑明显更接近我们队伍真实做决策的思路。迭代的原则很简单用真实案例喂它每次跑完看输出哪里不对劲回到SKILL.md里补规则。一个成熟的skills往往十几次迭代之后才真正懂你的需求。4. 分场景挑skills建模、前端、漫剧这些热门方向怎么选4.1 数学建模赛道的skills怎么挑数学建模是这波skills热潮里需求最旺的场景之一。原因很好理解建模比赛的流程高度固定——选题、查文献、数据预处理、建模、求解、写论文、做可视化每一步都有大量重复劳动而且评判标准相对明确。我用过好几个相关的codex skills总体感受是有用的skills不是替你建模而是把流程和组织工作管起来。比如有些skills负责自动抓取赛题数据并做初步清洗有些负责按论文模板生成LaTeX骨架有些负责从结果数据里直接产出图表。这些技能包的价值在于节省准备时间让你把精力放在真正的模型设计和分析上。挑的时候有几个过滤条件优先选近期仍在维护的仓库看issues里有没有人反馈跑不通优先选带示例数据和示例输出的方便快速验证优先选SKILL.md写得详细且带决策分支的说明作者真的在实战里磨过。另外提醒一句比赛用的skills一定要提前装好并完整跑一遍流程别指望临场边比赛边调试。4.2 前端开发与superpower skills前端开发方向的skills数量不少其中superpower skills这类综合性技能包经常被人提及。它的定位更接近一个超级工具箱把常见的前端任务——组件生成、项目脚手架、样式规范检查、代码审查——都收纳到统一的技能体系里。它的价值不在于某个单一任务做得特别深而在于工作流的连贯性。以前让AI帮我做一个表单组件它给你一段代码就完了你还得自己嵌入项目、检查规范、调整样式。挂上superpower skills后它会按技能定义的流程走先识别项目技术栈再参考团队规范生成组件后自动检查接口和样式是否符合约定最后给出集成建议。整个过程像多了一个熟悉团队规范的初级开发。选前端skills时我建议关注它覆盖的技术栈和你的项目是否吻合。一个偏向Vue生态的skills套件放在React项目里可能水土不服反之亦然。另外注意看它是不是过度依赖某个特定版本的构建工具这类技能升级成本往往很高。4.3 AI漫剧和内容创作场景的skills形态AI漫剧是近两年内容创作领域的新热点对应的skills也很有意思。这类skills通常不是给程序员用的而是给创作者准备的形态上更偏工作流模板分镜脚本生成器。我之前研究过一些漫剧相关skills它们一般做三件事一是把小说或剧本章节拆成漫画分镜包括场景描述、角色表情、镜头角度二是根据分镜生成详细的图像提示词供绘画模型使用三是统一人物设定的描述方式避免同一角色在不同画面里出现风格漂移。这三个能力对AI漫剧的生产效率影响巨大也恰恰是纯靠对话问答很难稳定输出的内容。内容创作类skills和编程类skills有个明显区别前者更依赖模板和提示词工程后者更依赖脚本和代码。所以你在挑选内容创作skills时重点看它的分镜逻辑是否合理、角色一致性方案是否可靠、输出格式是否容易被下游工具绘画模型、视频合成工具直接消费。它的SKILL.md通常比编程类技能更长因为要容纳大量风格描述和示例。5. 装了太多skills之后清理、冲突与隐私底线5.1 什么时候必须清理skillsskills装多了之后你会发现一个问题Agent的可用skill列表越来越长它每次做任务前都要翻手册反而增加了决策成本。有些技能甚至会在你不希望它介入的场景里主动触发干扰正常对话。我自己的判断标准是一个skills如果连续两周没有被动用过就进入待清理名单。另一个更强烈的信号是当Agent在处理简单任务时频繁引用某个无关技能的步骤——说明它已经干扰了判断必须立刻卸掉。另外比赛季结束之后也要及时清理。数学建模类的skills在赛前是利器赛后留着除了占地方还可能在普通开发任务中误导Agent。我通常在赛后一周做一次大扫除把时效性强的skills归档或删除。5.2 清理方法论以tibo的方法为基础之前看到tibo分享过一套清理skills的方法思路很实用。它不是让你看哪个顺眼就留哪个而是分三步走。第一步盘点。先让Agent列出目前加载的所有skills及描述导出一份清单。第二步分类标记。把skills分成经常用偶尔用基本不用三类这一步不需要太精准凭感觉即可。第三步测试性卸载。把基本不用类的技能移出目录但别急着删放到一个disabled备份目录里正常使用一周。一周后如果你根本没想起来它们再彻底删除。这套方法的最大好处是安全。你永远不会因为一次冲动清理导致某个重要技能被误删同时又给Agent减了肥。我按这个思路清理过两次每次清理完都能明显感觉Agent的响应速度更快上下文里的干扰信息更少。清理时还要注意依赖关系。有些skills看起来不常用但它可能是另一个常用技能的辅助技能。删之前翻一下常用技能的SKILL.md看看有没有引用外部技能。如果拿不准就先保留。5.3 权限和隐私的红线千万别踩最后说一个容易忽略但极其重要的问题skills的权限和隐私边界。GitHub上的skills大多是开源社区贡献的质量参差不齐。有些技能包会带着脚本执行本地命令、读写文件、甚至调用外部API。装之前一定要看一遍SKILL.md和scripts目录里的代码确认它不会偷偷上传数据、不会访问不该访问的目录、不会执行危险命令。尤其是用于数学建模比赛或商业项目的skills数据敏感度很高。比赛题目、企业业务数据属于非公开信息如果某个skills里有自动上报数据的逻辑后果会非常麻烦。我的习惯是所有外部skills安装后先断网跑一遍测试用例观察它的文件访问记录和网络请求再决定是否正式使用。有条件的话可以在一个隔离环境里先跑通。另外DIY skills同样要注意边界。你在SKILL.md里写的规则Agent会严格执行。如果某个规则涉及读取特定目录的敏感文件那以后每个加载了该技能的会话都有可能读写这些文件。尽量给技能设定明确的工作目录和权限范围不给Agent留下越权的空间。我个人在实际操作中还有个小习惯每个skills的目录名都会加一个版本号后缀比如math-modeling-topic-evaluator-v2方便回滚和区分新旧版本。这个习惯帮我避免过好几次改到一半不知道哪版能用的窘境。如果你也常年在多个skills之间折腾不妨试试这个套路。