1. 先把“skills”这词拆开看它到底改了什么东西最近AI编程圈子里“skills”几乎成了新的标配热词。打开推特刷到的是“superpower skills”去GitHub搜一下是“anthropics/skills”连Codex和OpenCode都开始把skills当作第一方特性来宣传。我一开始也以为这只是某个仓库的营销概念直到我自己在Claude Code里装了一个GitHub上的skills包、并且真正感受到工作流的变化之后才意识到这玩意儿和之前那些“提示词方案”“插件系统”有本质的区别。Skills直译过来就是“技能”放到AI编程工具里它指的是给AI模型预先准备好的一组“局部知识可执行指令可能伴随的脚本与参考文件”。你可以把它理解成给实习生准备的那本SOP手册——里面不光写了“遇到什么情况该做什么”还直接把对应的工具、模板、检查清单都放在旁边让他照着走一遍就能干活而不是每次都要从头临时教一遍。它解决的核心问题其实特别朴素大模型本身是“无知”的它的知识停留在训练语料里。你说“把这份文档转成docx”它能写大概率的代码但未必知道你们团队要求的字体规范、目录层级、图片嵌入位置。过去我们要么把这一大段要求每次都写进提示词里要么放进CLAUDE.md或者AGENTS.md当全局规则。Skills的做法则是把这些碎片化的要求封装成一个独立单元只在需要的时候被加载进来。和MCPModel Context Protocol相比MCP更像给AI接了一根外部数据线让它能实时读写外部系统的数据而Skills更像在AI脑袋旁边放了资料夹和常用工具箱不需要网络连接也可以直接用。和全局规则文件相比Skills是按需加载的局部技能而不是给每一次对话都背上一整套包袱。CLAUDE.md适合放“关于项目的常识”Skills适合放“针对某类任务的完整操作方案”。逻辑一下就顺了如果你的日常工作只有一种固定模式全局规则就够了但如果你的场景多变——今天要写数学建模报告明天要维护前端组件库后天要生成漫剧分镜——你就应该把每个场景封装成独立的skills用的时候调用不用的时候完全不占上下文。我自己的体会是Skills真正改变的不是“AI能不能做”而是“AI做得像不像熟练工”。同一个模型挂上经过设计的技术Skills之后输出质量稳定提升尤其适合那些“步骤固定、但细节容易翻车”的任务。2. 翻遍GitHub之后我总结出的几个值得关注的Skills源既然要深入玩skills绕不开的问题就是去哪里找现成的、靠谱的Skills我花了一整晚把目前社区里讨论最集中的仓库、技能库网站和安装方式过了一遍这里给出一份我个人实测后的观察结论。2.1 官方仓库和社区资源各有各的门道GitHub上现在能看到的Skills源大致分成三类官方维护的示例仓库、社区发起的工具集合型仓库、以及围绕特定平台的skills聚合仓库。第一类是Anthropic官方仓库anthropics/skills很多人的Skills启蒙就是从它的README开始的。里面收录了文档转换、PPT生成、表格提取等偏“基础办公”类的技能特点是格式规范、目录结构清晰非常适合拿来做模板拆解学习。第二类是社区大佬写的大型技能集合比如superpower skills。这类项目通常一上来就打包几百个skill有PDF处理、SQL分析、前端调试、音频剪辑等安装方式也很粗暴一条命令全部复制到本地Skills目录。优点是开箱即用、量大管饱缺点是维护节奏完全取决于作者而且因为一次性安装太多反而可能造成干扰真要遇到需要精准触发的时候还得自己改。第三类是围绕特定工具的第三方封装比如typesafe ai skills、codex nature skills、cola skills、opencode skills。这些属于“应用开发者看了官方规范后基于自己的使用习惯重新编排的产物”。它们往往比官方仓库更贴近实际工作流但同时也更依赖特定工具的版本跨工具迁移时需要注意兼容性。我在实际使用中更偏爱的组合是官方仓库的规范文档作为样板superpower skills这类集合源作为灵感速查表具体某个高频场景则自己封装一个干净的skill。这样既不缺灵感也不会被别人的冗余内容绑架。下表整理了我翻过的几个典型仓库和它们的定位方便你快速决定该从哪个开始。仓库/资源目标工具适合场景我的评价anthropics/skillsClaude Code、Claude App官方样例、规范学习、基础办公技能目录干净适合当模板superpower skillsClaude Code、其他兼容工具一次性体验大量技能、找灵感功能多但需要自己裁剪typesafe ai skillsTypeScript、主流AI工具偏代码生成与工程化方向精准适合开发者codex nature skillsCodex配合Codex执行的工程任务跟Codex生态绑定比较深cola skillsCodex/兼容工具通用任务、文档处理新兴项目变动比较快opencode skillsOpenCodeOpenCode下的技能扩展跟着OpenCode本身走2.2 技能库网址和查找思路除了GitHub仓库现在还出现了一些专门汇总skills的网页和导航站。你搜“skills技能库网址”或“常用skills源网站”能看到不少个人维护的索引页、Awesome列表和带在线预览的Git仓库。这类站点的价值在于帮你建立“技能地图”哪个技能解决哪类问题、由谁维护、最近更新时间是什么一目了然。看的时候重点关注三个信息第一是描述文件是否足够清晰第二是依赖的外部命令是什么第三是最近的提交时间和issue状态。如果一个技能已经半年没更新而它依赖的工具版本却迭代了很多次装上大概率要翻车。另外还有个花小钱办大事的办法多看别人仓库里的issues。很多用户会在issue区反馈“这个skill的description触发不了”“跟某版本的Claude Code冲突”“这条命令在Windows下跑不通”等实际问题。这些信息比README更值钱能帮你安装前就排除掉一大半坑。3. 手动安装GitHub上的Skills以Claude Code为例的完整实操现在说说大家最关心的部分如何把GitHub上的技能包装进自己本地的工具里。网上很多攻略默认你用的是官方市场一键安装但实际情况是大量项目根本没有上架任何市场源代码直接躺在GitHub仓库里。这时手动安装就绕不开了。3.1 为什么推荐手动安装而不是一键脚本市面上很多skill集合自带一键安装脚本像superpower skills就支持curl管道直接执行。我个人不排斥脚本安装但强烈建议你在执行之前先把脚本打开看一遍确认它到底往哪些目录写了什么、会不会覆盖已有配置、有没有回滚机制。我曾经因为图省事跑了一键安装结果本地的技能目录被整体替换之前辛苦调整过的几个技能配置直接没了一半。从那以后我的原则就变成了能用git clone解决的就不用管道脚本能先备份的绝不裸装。手动安装其实并不复杂带来的额外好处是你清楚知道每一个技能文件的物理位置后面想改、想删、想备份都有据可查。3.2 三种手动安装路径和适用场景手动安装前需要先确认一个基础概念Claude Code的Skills目录默认是~/.claude/skills/macOS/Linux下每个子目录就是一个独立技能包。如果仓库结构里已经包含完整的技能目录比如某个repo的目录结构是skills/xxx-skill/SKILL.md那么复制整个xxx-skill目录到~/.claude/skills/下就可以了。方法一适合“单个技能包复制”比如你只想安装仓库里的某一个技能就把它从仓库里单独复制出来放到本地Skills目录中。这种方式最干净不会带入仓库里的其他杂物。方法二适合“整个仓库作为技能包源”直接把仓库克隆到本地某处然后手动把仓库里s/xxx-skill对应的目录做软链接或复制到~/.claude/skills/。好处是后续拉取更新非常方便git pull之后技能文件自动同步坏处是如果仓库里技能很多目录会显得杂乱。方法三适合“想用命名空间隔离不同来源的技能”在~/.claude/skills/下按来源分类建二级目录比如github-superpower/pdf、custom/react。这样一段时间后你往回看自己的技能库时能一眼判断哪些来自社区、哪些是自己写的清理和迁移成本都低很多。具体操作步骤如下以把某个GitHub仓库的单一技能包装进Claude Code为例# 1. 先clone整个仓库到临时目录 git clone https://github.com/author/awesome-skills.git cd awesome-skills # 2. 查看仓库结构确认技能包目录位置 ls -la skills/ # 3. 把需要的技能包复制到Claude Code的Skills目录 mkdir -p ~/.claude/skills cp -r skills/document-to-docx ~/.claude/skills/ # 4. 检查复制结果确保SKILL.md在正确位置 ls ~/.claude/skills/document-to-docx/SKILL.md如果你用的是Codex或OpenCode不要着急套用上面的路径先看对应工具的官方文档。不同工具对Skills目录的默认位置、加载方式、描述文件格式都有自己的约定。比如Codex常见的技能目录是~/.codex/skills/OpenCode则可能把技能放在项目级的.opencode/skill/目录下而且它们对SKILL.md的解析规则也可能不一样。多花两分钟读README比装完发现不生效再排查要快得多。3.3 验证技能是否真的生效安装不是终点装完必须验证“能不能被正常加载和触发”。我自己的验证步骤一般分三层第一层是物理检查确认文件路径、文件名大小写、目录嵌套层级没有出错。很多技能装完不生效最后查下来是多了个嵌套目录——比如把skills/document-to-docx复制成了~/.claude/skills/skills/document-to-docx工具自然读不到。第二层是查看工具的加载情况。Claude Code在启动时会扫描技能目录你再打开对话界面时用技能描述里的触发动作测试一下比如“把这份文档转成docx”如果它真的调用到了对应技能说明链路已经通了。第三层是看错误输出。如果发现技能完全无响应优先确认SKILL.md的frontmatter格式是否正确、description是否足够具体、脚本是否给了可执行权限。chmod x scripts/xxx这种“看似无关但其实至关重要”的操作经常被新手忽略。提示在Windows下手动安装时注意路径斜杠、大小写和脚本换行符。技能里的bash脚本如果是从Unix系统拷贝过来的常常会因换行符问题在执行时报错建议用VS Code打开后统一转成LF。我自己在给同事演示这套流程时最大的坑就是“复制了整套仓库结果技能目录层级不对”。大家记住一个原则工具识别Skills是靠扫描特定目录下的子目录而不是扫描Git仓库结构。所以复制时一定要看清楚你放的目录里面第一层就应该能看到SKILL.md而不是再多套一层。4. 从“拿来主义”到“自己写”一个最小可用的Skills项目拆解装了别人的技能包、能跑通之后接下来一定会遇到的问题就是我想要的功能社区找不到或者找到的跟我的工作流不匹配。这时候就需要自己写技能包了。4.1 技能包的标准目录长什么样先看一个最小可用的目录结构react-component-generator/ ├── SKILL.md ├── scripts/ │ ├── generate_component.py │ └── validate_props.js └── assets/ ├── component-template.tsx └── checklist.mdSKILL.md是这个技能包的核心里面用YAML frontmatter加Markdown正文描述整个技能的元信息和执行逻辑。scripts/放的是可执行脚本可以是Python、JavaScript、Shell甚至只是几条命令的封装。assets/放的是模板、样例、参考文档等静态文件脚本和模型都可以读取这些内容来辅助生成输出。很多人的误区是不写scripts想让模型凭空生成所有内容。但实际经验是凡是可以用脚本确定性完成的工作比如格式化、校验、批量重命名都尽量写进scripts里让模型把精力集中在判断和创造上。这样技能的稳定性和可回归性会高很多。4.2 SKILL.md的写法frontmatter和正文都别偷懒先上一个具体的SKILL.md示例--- name: react-component-generator description: 当用户需要生成新的React组件或者需要按照团队规范改造成组件时使用。适用于函数组件、TypeScript写法、Tailwind样式。不适用于类组件项目。 --- # React组件生成器 ## 触发条件 - 用户要求“新建一个组件”“生成Badge/Button/Card等UI组件” - 用户粘贴了设计稿描述或需求说明并希望转换成组件代码 ## 执行步骤 1. 询问组件名称与用途如果用户已提供直接进入下一步。 2. 根据props类型定义参考assets/component-template.tsx里的骨架生成代码。 3. 使用scripts/validate_props.js校验props命名和类型定义是否符合规范。 4. 输出组件的最终代码并附上使用示例。 ## 质量要求 - props必须用interface定义不要用any。 - 样式使用Tailwind类名不写内联style。 - 组件默认导出并同时提供命名导出。这个示例里有几个细节特别值得注意首先是description要写出“适用/不适用于什么场景”。这直接决定了模型的触发准确率。你写“生成React组件时使用”模型很难判断什么时候该调用但你写出“需要生成新的React组件...不适用于类组件项目”触发命中率会明显提高。其次是正文里的执行步骤必须可操作。不要让模型自由发挥而是给它固定的路径用哪个模板、跑哪个脚本、输出什么格式。很多人写的技能像话术模板模型看完还是不知道该先干什么。要把技能当成“给AI的SOP”不是当成“给AI的提示词”。再次是frontmatter的name要唯一。如果你的技能库里同时存在两个重名的技能后加载的会顶掉先加载的而且你很难察觉。4.3 脚本和模板的最佳实践脚本的作用是把那些“模型不擅长但机器很擅长”的事情接住。比如校验代码格式、解析JSON、调用外部API、生成批量文件。脚本写得越简单越好别在一个脚本里追求太多功能保持单一职责。模板文件则承担“风格锚点”的作用。让模型的输出风格稳定与其在SKILL.md里反复描述“要专业、要优雅”不如直接放一个真实项目里已经验收过的模板文件。模型看到具体例子之后模仿起来远比读抽象要求精准。4.4 如何避免写出“AI根本不会调用”的技能写技能包最忌讳的一件事就是SKILL.md写得花团锦簇但模型在实际对话里从来不会调到它。出现这种情况大概率是description写得太抽象。你写“帮助用户处理前端相关任务”永远不如“当用户需要生成或重构React/Tailwind组件时使用可识别设计稿描述或组件名称”。另一个容易被忽略的点是别一次想在技能里塞太多功能。曾经有一位朋友把“数据分析图表生成报告排版邮件发送”全部写进同一个技能结果触发率极低因为模型很难在一次对话里准确判断用户到底触发了哪个子任务。拆技能的正确姿势是“按任务拆”而不是“按流程拆”数据清洗一个技能、图表生成一个技能、报告模板一个技能每个技能聚焦一个可交付的成果。提示技能不是越复杂越好。判断自己的技能设计是否合理有一个简单的检验标准——假设你把这个技能交给一个刚入职的实习生他能不能照着里面的步骤独立完成任务如果不行说明写得还不够具体如果可以模型大概率也能执行得很好。5. 常见场景的Skills实践前端、数学建模、AI漫剧Skills的价值最终还是要在具体场景里体现。下面挑三个近期讨论度最高的场景来展开正好覆盖了“工程开发”“学术竞赛”“内容创作”三条线。5.1 前端开发Skills从组件生成到工程规范落地前端开发是目前skill数量最多的领域之一。搜索“前端开发skills”“superpower skills”能看到大量和React、Vue、Tailwind、UI组件库相关的技能包。一个典型的前端skill应该覆盖三层内容第一层是项目规范层比如组件目录结构、命名规范、是否使用TypeScript、是否禁止内联样式第二层是模式层比如怎么写原子组件、怎么拆hooks、怎么组织状态管理第三层是校验层比如生成代码后跑lint、跑类型检查。我自己在这个场景里最常用的是一个自己写的React组件生成器技能它读团队现有的组件模板自动生成带storybook故事、单测用例和文档注释的新组件。它把“生成组件”从“每次都要重复描述团队规范”的对话式任务变成了“一句话触发然后等结果”的固定动作。还有一类前端技能很有价值旧代码迁移。比如把Vue2的组件语法迁移到Vue3或者把JavaScript改成TypeScript。这类任务特别适合用skills固化一套检查清单和执行顺序因为一次性提示词很难记住所有迁移步骤而技能可以加载一份完整的迁移手册。5.2 数学建模与竞赛场景推荐哪些Codex/Claude Skills每次到了数学建模比赛季“数学建模skills推荐”“华为杯建模比赛好用的codex skills”就会变成高频搜索词。我自己虽然没有直接参赛但辅导过几支队伍使用AI辅助建模积累了一套还算有效的skill组合。第一优先级是数据清洗与探索性分析技能。建模第一步是理解数据这个技能应该包含缺失值处理、异常值检测、特征分布初探等标准流程并自动生成一套基础图表。第二优先级是模型选型与评估技能。这个技能用来解决“拿到问题不知道用什么模型”的痛点它会读取问题描述对比多个候选模型给出每个模型的适用条件、训练成本和预期精度并自动跑交叉验证。第三优先级是论文排版与图表规范技能。很多队伍算法没问题最后挂在论文表达上。技能包里放着摘要写作模板、公式排版规范、图注说明写法、Table格式标准整体就能把论文质量拉到及格线以上。如果你用的是Codex建议重点关注codex nature skills这类跟Codex执行链配合得比较好的项目。它跟Codex自带环境的衔接更顺滑跑Python脚本、管理和调试依赖都比通用skills更省心。需要提醒的是竞赛场景最大的风险不是技能不够而是过度依赖技能输出导致思考过程被带偏。技能给你的是执行SOP和格式规范模型选择和结果解释还得靠参赛者自己把关。我辅导队伍时一直强调技能负责提效思维负责保底。5.3 AI漫剧与创意内容Skills如何帮内容创作者稳定输出“AI漫剧常用skills”这个热搜词看起来有点意外其实是内容创作者在用AI批量产出漫画分镜、配音脚本、角色设定时遇到了一致性问题同一个角色在不同镜头里描述不一致分镜脚本缺乏画面感台词风格前后飘忽。这类场景下的skills通常包含角色一致性描述技能把每个角色的外貌、服装、性格关键词沉淀成固定描述块每次生成画面时统一引用分镜脚本技能把“景别、镜头运动、画面内容、台词、音效”拆成固定字段输出格式统一脚本节奏技能专门处理“喜剧节奏”“剧作节拍”这类稍微抽象的表达要求。我自己测试过的最有效的做法是让AI先调用角色设定技能把角色库加载进上下文然后基于角色库生成分镜最后再用视觉风格技能统一画面关键词。这样一条完整的生产链被拆成了三个技能接力而不是靠一个又长又杂的单次提示词去硬撑。创意类内容用skills时有个反直觉的点越固定的格式越能释放创意。很多人以为技能会限制发挥但分镜脚本真正需要的恰恰是统一的字段和结构——把“格式”这个变量固定下来之后创作者反而可以把精力放在剧情创意上模型的发挥空间也更稳定。6. 关于Skills的避坑记录、清理方法与边界思考再说几句踩坑经验。这个部分假如早看到能帮我省下不少排查时间。6.1 “技能装越多越好”是我见过最普遍的坑你一旦开始逛GitHub就会发现好的skill实在是太多了很容易陷入“收藏即学会”的状态。但技能装得太多和全局规则文件写得过长是一样的下场模型在触发判断时会产生混淆经常出现“看着像A任务但被B技能截胡”的场面。我个人的经验是技能数量控制在20到30个以内比较合适。如果超过就定期做一次断舍离。判断一个技能值不值得保留只需要问三个问题过去两周有没有实际触发过如果我删掉它工作流会不会立刻变麻烦它描述的功能是否已经跟其他技能严重重叠如果三个答案里有两个是“没有”“不会”“重叠了”就大胆删掉。删除前把技能目录加个后缀重命名而不是直接rm这样冷静一周后如果确实不需要再做物理删除。6.2 清理网络博主的建议本质上都是“可恢复的减法”最近不少博主都聊过清理skills的方法我在YouTube和推上也看到过类似思路比如tibo推荐的清理流程。大家的核心逻辑其实一致先把不用的技能移到备份目录确认稳定后再彻底删除。还有一点常被忽略就是清理技能的同时要清掉相关的全局规则配置。很多技能在安装时会往CLAUDE.md或者工具配置里追加内容只删技能目录不删引用反而会留下大量悬空指令让AI在后续对话里做一些莫名其妙的动作。另外清理完技能后建议重启一下工具。部分工具对技能目录的扫描只在启动时执行一次运行过程中即使你改了目录也不会实时加载。我遇到过几次“清理后反而更卡”的怪现象排查半天才发现是新改的技能目录格式有问题重启工具后就一切正常了。注意很多第三方技能为了适配不同操作系统会在scripts里写一堆条件分支。这类技能装到纯净环境经常跑不通。如果你发现某个技能在别人机器上正常、在你机器上报错请优先检查自己的Shell版本、python版本和依赖是否齐全而不是第一时间怀疑技能作者的代码有问题。6.3 什么时候不建议用Skills最后说一个很多人不爱听但很真实的话不是所有事情都适合做成skill。一次性任务、以后大概率不会再遇到的操作就直接写提示词让AI临时处理个性化特别强、只服务于某个特定项目的流程放到项目级的规则文件里比全局技能更合适需要频繁连接外部API实时数据的能力应该考虑MCP而不是静态的技能包。Skills的核心优势是“可复用、低上下文的固定SOP”。这个优势发挥出来就能明显提工作效率。优势没必要发挥的时候强行套用反而增加理解成本和维护成本。经过这段时间的折腾我现在的习惯是每周花十分钟扫一眼自己的技能目录看到用不上的果断移走遇到重复的顺手合并。工作流的稳定性靠的不是技能的堆砌而是每个技能都经得起实际场景的考验。真正用过一轮、清理过一轮之后你才会慢慢找到适合自己节奏的skill管理方式。