先说个最近的体会AI编程工具卷到现在这个阶段真正拉开差距的反而是最基础的“skills”。我身边不少朋友还在花大量时间调提示词、拼上下文而用Claude Code、Codex、opencode的人已经通过一套整理好的skills把重复劳动全部固化成了可复用技能包。GitHub上一堆开源的skills仓库看起来很好用但真要手动装到自己环境里很多人第一步就卡住了——不知道放哪个目录、不知道怎么启用、装完也不确定到底生效没有。这篇文章把我自己从“只会复制粘贴长提示词”到“能自己维护一整个skills库”的完整过程写出来重点讲清楚三件事skills到底是什么、怎么把GitHub上的skills手动装进本地工具、以及如何写一个属于自己的skills。适合刚听说skills、想上手但还没摸清门道的新手也适合已经用了一段时间、但总觉得触发不灵、技能之间互相打架的老手。全文不聊虚的全部按实操来写。1. 先搞懂skills到底是什么它解决了什么问题1.1 从“临时写提示词”到“固化工作流”很多人对skills的直觉理解是“给AI的提示词模板”这个说法对但不完整。更准确的定位是skills是一组“按需加载的专家指令包”。它把某一类任务的完整方法论、约束条件、执行步骤、质量标准写进一个文件里平时不占模型上下文等模型判断你需要这个能力的时候才把对应内容读进来。我举个例子就明白了。以前做前端代码审查每次都要在对话里贴一大段规则比如“注意组件拆分、关注性能瓶颈、检查无障碍属性、指出可维护性问题”这个提示词还得根据项目情况反复调整。而用skills之后只要写一个frontend-review技能把审查的维度、规范、输出格式全部固化到SKILL.md里。下次模型发现你在聊前端代码并且需求是审查它就会自动加载这套规则。好处是显而易见的少打字、少重复、结果更稳定。背后的本质是模型的能力上限并没有变但你把“专家经验”通过文件形式交给他了。就像给一个很聪明但没干过这行的新人配了一本浓缩的岗位手册他上手速度会快好几倍。我们现在说的AI skills本质上就是干这件事的。1.2 skills和提示词、插件、MCP有什么区别这里把几个容易混淆的概念放一起对比很多人分不清它们的关系。普通提示词每次对话你需要手动写出来用完就没了不适合重复性高的工作流。Project Instructions也有人叫CLAUDE.md或AGENTS.md常驻在项目里的全局指令每次对话都会读适合写“项目级约定”但不能太臃肿否则会浪费大量上下文。MCP给模型提供外部工具和数据源访问能力比如连数据库、搜网页、操作文件系统。它解决的是“AI能做哪些事”的问题。Skills解决的是“AI知道该怎么做”的问题重点在方法与流程。当然高级的skills也可以调用脚本和MCP配合使用。打个比方MCP像是给AI接上了手和眼睛让他能触达外部世界skills像是给他一套标准作业程序告诉他拿到任务后先做什么、再做什么、遵循什么标准。两者配合才是完整形态。理解了这层区别再看GitHub上那些被反复讨论的skills仓库就不会一头雾水了。像superpower skills这类大而全的库本质上是把大量“标准作业程序”打包给你你要做的不是所有都装而是挑出适合自己工作流的那些。2. 手动装一个GitHub上的skills全套实操2.1 安装前先确认你要用哪个工具不同AI编程工具的skills目录位置不完全一样而且工具版本更新很快安装前一定要先用工具自身的命令确认一下当前版本支持的技能目录。目前主流的几个工具常见的路径是这样的Claude Code全局技能放~/.claude/skills/项目级技能放.claude/skills/。Codex CLI全局技能放~/.codex/skills/项目级技能放.codex/skills/。opencode全局技能通常放~/.config/opencode/skills/。这里的全局路径是“对当前机器上所有项目生效”项目级路径是“只对当前项目仓库生效”。我的习惯是通用能力放全局和具体业务强相关的能力放项目里。比如代码审查、数学建模这类放全局公司内部技术栈约定这种就放项目级。还有一个容易踩的坑有些人用的是集成IDE里的AI插件或者是网页版入口这些环境未必支持直接读磁盘上的skills目录。先确认你的使用入口是本地CLI否则安装步骤会不生效。2.2 从GitHub搬到本地三种常见方式找到心仪的skills仓库之后安装方式取决于仓库的目录结构。我把常见情况拆成三种。第一种单仓库就是全套skills整个拉下来直接认。以著名的obra/superpowers为例作者在文档里给出的做法一般是直接把仓库克隆到技能目录git clone https://github.com/obra/superpowers.git ~/.claude/skills这个操作会把整个仓库所有技能一次性放到全局技能目录下。好处是省事坏处是仓库如果很大、技能很多会让模型在“技能选择”时多出很多候选偶尔还会出现多个技能description互相干扰的情况。所以这种方案只建议在“我就是要全面体验”的阶段使用。第二种仓库里包含多个技能我只要其中一部分。很多skills仓库的目录结构是仓库根目录/skills/技能名/SKILL.md或者仓库根目录/技能名/SKILL.md。如果只想装其中一两个技能就不要整仓拉取而是用稀疏检出或者直接复制子目录。用Git稀疏检出的命令大致是git clone --depth 1 --filterblob:none --sparse https://github.com/xxx/some-skills.git cd some-skills git sparse-checkout set skills/frontend-review skills/math-modeling然后把对应的两个目录内容复制到你的技能目录cp -r skills/frontend-review ~/.claude/skills/ cp -r skills/math-modeling ~/.claude/skills/这一步看着简单实际是很多人装完“不生效”的重灾区原因在2.3小节说。第三种用工具内置的安装/插件命令。Claude Code等工具后续版本陆续加入了skills管理命令。有的可以用类似/plugin的入口浏览已安装插件有的支持直接指定GitHub仓库地址安装。如果工具支持优先用官方命令装因为路径和权限它会帮你处理。但手动装永远值得掌握因为很多小仓库并不会被插件市场收录。2.3 装完怎么验证有没有真正生效我见过太多人装完skills后问“为什么没反应”问题基本出在目录结构上。工具识别skills的最低要求是在技能目录下要直接存在一个名为SKILL.md的文件。这里说清楚~/.claude/skills/仓库名/SKILL.md这种结构工具是能识别的因为技能名就是“仓库名”。但如果你把整个仓库clone下来以后仓库里还有一层嵌套的skills目录也就是变成了~/.claude/skills/仓库名/skills/具体技能名/SKILL.md很多工具并不会递归搜索两层目录最后结果就是“装了但没生效”。我在安装superpowers这类仓库时实际更推荐用软链接而不是直接复制。软链接的好处是后续拉取更新极其方便不用重复搬运。git clone https://github.com/obra/superpowers.git ~/tools/superpowers ln -s ~/tools/superpowers/skills ~/.claude/skills/superpowers这样做的前提是仓库内部真的有一个skills目录并且里面每个子目录都直接包含SKILL.md。装完以后验证方法分两步第一步看工具能不能列出技能。在Claude Code的对话里输入/skills能看到已加载的技能列表如果这里没出现新装的技能说明路径或结构有问题不用继续往下排查。第二步实际触发测试。不要直接问“你有什么技能”而是模拟一个真实使用场景。比如你装的是数学建模技能就丢一个赛题摘要进去看模型是否自动调用对应技能以及输出风格是否符合技能里定义的规范。如果你不确定模型有没有加载技能可以让它先复述“你正在使用哪个技能里面定义了哪些步骤”一套有效的技能文件模型是能准确回答出来的。3. 值得收藏的开源skills推荐3.1 通用型大而全的技能包怎么挑现在GitHub上最出圈的skills项目里superpower skills、codex nature skills、typesafe ai skills这种都属于“全家桶”型仓库。全家桶里塞了几十个甚至上百个技能覆盖写代码、做审查、写文档、重构、数据分析等等。我的建议是全家桶装可以但不要全部启用。一种更优雅的做法是把整个仓库clone到本地某个目录然后通过软链接只把真正用得上的几个技能链接到~/.claude/skills/下面。这个做法也顺便解决了“清理skills”的问题——想禁用哪个技能直接把对应软链接删掉就完事原文件还留在仓库里随时可以重新链回来。选技能包的时候有一个判断标准很关键看这个仓库的SKILL.md写得是否具体。一个合格技能文件至少要包含任务的适用场景、执行时遵循的步骤、输出的标准格式、常见的坑。如果某个技能文件只有两三句话那大概率只是把提示词换个扩展名这种装不装差别不大。3.2 场景型数学建模、前端开发、AI漫剧热搜里提到的高频场景我挑几个典型的说说实际使用体验。数学建模技能这类技能的目标用户很明确就是打数模竞赛比如华为杯、国赛、美赛的团队。好的数模技能一般会拆成几个独立技能环境准备、赛题拆解、数据清洗、模型选择、论文写作、LaTeX排版。每个技能负责一段工作流。比如“赛题拆解”技能会要求模型先复述问题、拆约束条件、列出可选的模型类型、评估数据可得性最后给出一个解题计划。“论文写作”技能则强制套用论文结构模板把摘要、模型假设、符号说明、结果分析这些部分都按规范输出。竞赛场景时间紧这种sop型技能是真的能救命。前端开发skills我目前高频率在用的是代码审查和性能优化两个技能。前端审查技能会把“组件边界是否合理、依赖是否合理、a11y是否达标、有无内存泄漏风险”等维度固化下来每次审查都按这个框架走不会因为模型状态波动而漏项。性能优化技能则内置了“先埋点分析再改代码”的流程避免模型一上来就瞎猜瓶颈。AI漫剧/短视频技能最近做AI漫剧和短剧脚本的圈子很流行用skills核心是把“分镜脚本生成、提示词转写、角色一致性描述、节奏控制”这些环节做成标准模板。比如一个“分镜脚本”技能会要求模型按照景别、运镜、角色状态、台词、旁白、音效提示来生成表格化脚本直接方便后续丢给AI绘画或视频工具使用。这类技能不需要多高深的技术含量胜在把行业套路写成规则让AI生成的东西风格统一。3.3 快速找skills的途径和筛选标准找skills去哪里找很多人会去GitHub搜awesome skills、claude skills这类关键词能找到一批聚合列表。看仓库的时候我一般按这个顺序筛选看更新时间超过半年没更新的基本不考虑AI工具的命令和目录结构变得太快旧技能很容易失效。看SKILL.md里的描述开头如果description写得太泛比如“帮助用户完成任务”这种触发的准确率会很低。看是否有配套示例比如给了一段输入和期望输出。有示例的技能说明作者真的跑通过。这里也提醒一句GitHub上所谓的“技能源网站”质量参差不齐有很多只是把别人仓库重新打包。优先选原仓库、看star数、看有没有人提issue比什么都重要。4. 动手写一个自己的skills4.1 SKILL.md文件结构和YAML头部自己写skills说难不难说简单也不简单。核心就是要理解SKILL.md这个文件的三段式结构。文件最前面是YAML格式的frontmatter两个关键字段是name和description一个可选字段是allowed-tools这种声明。--- name: frontend-review description: 当用户要求审查前端代码、发现性能问题、检查可访问性或组件设计时使用。可以处理代码片段、仓库路径或页面URL。 --- # 前端代码审查 ## 任务目标 ...name必须简短且唯一建议用英文小写加连字符。description是整个技能里最重要的部分它直接决定模型会不会自动调用这个技能。不要写成静态标签比如“前端、代码、审查”这种词列表而要写成“在什么情况下、用来做什么事”的行为描述。我写过一版只有三个标签的description结果就是模型经常不触发改成上面那种带着场景和输入类型的描述之后命中率才正常。正文部分反而没有太多格式要求它本身就是给模型读的指令。我的写法风格是先用一两句话说明这个技能的目标然后列出具体执行步骤再给输出模板最后写“不要做什么”。这个“不要”清单非常有用它能把模型的自由发挥约束在可控范围内。4.2 手写一个前端开发skills实例直接看一个我目前正在用的简化版前端审查技能。它的正文结构其实很朴素--- name: frontend-review description: 当用户要求审查前端代码、定位性能瓶颈、评估组件设计或者检查可访问性时使用。支持代码片段、文件路径、Git仓库地址三种输入。 --- # 前端代码审查 目标是按照统一标准找出代码中的问题并给出可执行的修改建议。 ## 执行步骤 1. 读取输入代码先识别技术栈React/Vue/小程序/原生JS等。 2. 按以下维度逐项审查 - 组件边界和职责划分 - 状态管理使用是否合理 - 渲染性能是否存在不必要的重复渲染、大数据列表是否虚拟化 - 可访问性按钮是否有语义化文本、图片是否缺失alt、焦点管理是否完整 - 错误处理和边界条件 - 依赖和包体积隐患 3. 对每个问题标注严重级别P0必须修复 / P1建议修复 / P2可选优化。 4. 输出格式按“问题位置 - 问题描述 - 修改建议 - 示例代码”四段式输出。 ## 输出模板 ### P0 必须修复 - 位置 - 风险 - 建议 - 示例 ### P1 建议修复 ... ## 不要做 - 不要逐行点评代码风格。 - 不要在没有证据的情况下推测性能瓶颈。 - 不要输出泛泛的“代码很优雅”之类的评论。写完后把文件放到~/.claude/skills/frontend-review/SKILL.md然后再做一次触发测试。我自己的感受是第一版永远不够好用需要反复调整description和步骤粒度。判断标准很简单模型输出的结果是否稳定是不是每次都能覆盖你想让它检查的几个核心维度。4.3 进阶给skills加脚本和附件当SKILL.md里的文字指令满足不了你就可以上脚本了。工具规范的常见做法是技能目录里除了SKILL.md还可以放scripts/子目录存放可执行脚本以及attachments/存放供模型读取的参考文档。典型场景一个“日志分析”技能SKILL.md里让模型读取日志文件但日志文件可能很大模型直接读不现实。这时候可以在scripts里放一个预处理脚本先把日志按错误级别归类、提取关键堆栈再把精简后的结果交给模型分析。SKILL.md里需要明确告诉模型“遇到大文件时先执行scripts/preprocess.py读取输出结果做分析。”这种设计最大的好处是你把“该做的事”分配给了确定性程序把“该怎么理解”留给了模型各干各擅长的事。技能的可控性一下子就上去了。写脚本的时候注意一点权限问题。模型执行脚本通常受沙箱限制如果脚本依赖网络、依赖某些系统工具第一次运行前先手动跑一遍确认环境没问题再让它自动调用。我遇到过好几次脚本写得没问题但模型执行时被权限挡住了排查半天才知道是沙箱策略。5. 常见问题与排查经验速查5.1 技能装了但根本没生效这是被问得最多的问题按下面顺序排查很快能定位。先确认路径。用/skills列一下技能列表如果列表里根本没有这个名字大概率是技能文件没被扫描到。重点检查两点文件名大小写必须是SKILL.md技能目录层数不能多最外层技能目录下应该直接就是SKILL.md或者最多隔一层。再确认描述触发。有些工具对技能名和description的敏感度不一样即使列表里有模型也可能一直不主动调用。这时候改用明确指令在对话里手动指定技能名再观察输出。能手动触发就说明文件和加载都没问题剩下的只是优化description的问题。5.2 技能触发了但输出完全不像技能里定义的样子这种问题的根源多半是技能正文写得太模糊或者被项目里其他指令覆盖了。比如项目目录里有一个很长的CLAUDE.md模型加载技能后还是要遵守项目整体指令两者的约束冲突时输出就会跑偏。对策是技能正文里明确写出“本技能的执行优先级”并且在关键步骤上给出具体模板。模板是一个很强的锚点模型只要照着填空输出风格基本就能稳住。另外还要检查是不是同时装了多个职责相近的技能比如既有frontend-review又有code-review模型很可能选错一个。此时可以把其中一个技能的description改得更具针对性甚至在description里加上“本技能仅用于React/TS项目其他场景请勿使用”来降低误触发概率。5.3 技能越装越多怎么清理和维护我自己有段时间也陷入了“装技能上瘾”看到一个不错的仓库就想拉进来。结果技能数量超过50个以后模型在“决定调用哪个技能”这一步明显开始犹豫甚至出现一个任务同时套用两三个技能的情况。后来我给自己定了一套清理规则分享出来给你参考一个月以上没触发过的技能先软链接禁用不是删除而是移到~/.claude/skills_disabled/目录。同名技能以自己维护的版本为准仓库里的旧版不再启用。每季度做一次整体review把功能重叠的技能合并或者删掉。不要同时用“大而全技能包”和大量“单一小技能”推荐选一边。有人可能会问禁用掉的技能以后想再用怎么办这就是为什么我推荐用软链接而不是直接复制。重新启用一个技能只是敲一条ln -s的事哪怕是检查一个不常用的老技能也不会有什么心理负担。及时给技能“瘦身”其实比不断加新技能更能提升实际使用体验。最后再分享一个我自己的习惯每接触一个新工具链第一件事就是先建一个最小可用的skills目录放一两个自己每天都会用到的技能比如代码审查、提交信息规范。先让工作流跑起来再慢慢往里面补充场景技能。这样即使工具更新换代你迁移到新环境时技能库也能平滑搬过去。AI编程工具迭代越来越快但一套亲自整理过的技能库才是真正属于你自己的长期资产。