最近这段时间“skills”这个词在技术社区里出现的频率高得吓人。不管是 Claude Code、Codex 还是 OpenCode讨论区里全是“怎么手动装 GitHub 上的 skills”“有哪些常用的 AI skills”“skills 到底怎么写”之类的问题。我自己的项目里已经反复装卸过不少 skills从最开始的盲目复制到后来的按需定制踩了不少坑也攒下一些经验。这篇文章就把我整理过的思路完整写一遍。它不搞概念玄学就是一份能直接照着做的实操手册先说清 skills 是什么再讲手动安装的全流程然后拆解怎么写出一个好用的 skill最后给出场景推荐和清理维护方法。适合正在折腾 AI 编程助手的人也适合想把某类重复工作固化给 AI 的普通用户。1. Skills 到底是个什么东西从“会做”到“自带方法论”1.1 为什么突然这么多人聊 skills说穿了很简单AI 对话模型的上下文窗口再大也不可能每次都把“该怎么做这件事”的完整方法论塞进提示词里。尤其在做数学建模、前端开发、AI 漫剧这类流程长、步骤多、规范杂的任务时每次都要重新描述背景、约束、输出格式不仅累而且结果不稳定。Skills 解决的就是这个问题。它把某一类任务的执行知识打包成一个可在会话里被自动加载的单元。你不需要反复教模型“先做什么、再做什么、注意什么”只要它识别到当前任务和某个 skill 的描述匹配就会主动按技能里预置的方法论执行。说白了它让 AI 从“这一次会做”变成“以后都会做”。这也是为什么和“插件”“工作流”等概念相比skills 能在这么短时间里被大量讨论。它不需要复杂的可视化编排界面本质上就是一个有结构、约定清晰的文本目录复制到指定位置就能生效。GitHub 上大量的 skills 仓库也印证了这一点大家更愿意用“一个目录 一份 SKILL.md”这种轻到极致的方式沉淀经验。1.2 Skills 和普通提示词、插件有什么区别很多人第一反应是这不就是提示词模板吗我一开始也这么以为真正对比之后发现差别很明显。普通提示词是你临时塞给模型的一段话它没有“被自动识别”的能力。每次要用都得手动粘贴用完之后不留痕下个项目还得重新写。而 skill 不一样它有元信息也就是SKILL.md里的 name 和 description。模型在收到用户需求时会先扫描本地 skills把当前请求和 description 做匹配匹配上了才把对应的完整内容读进来。这个过程是自动的不需要你手动指定。插件则更像一个完整的程序扩展可能有独立的 UI、回调逻辑、第三方库依赖安装和升级都要走插件系统。Skill 大多没有这些负担它只是给模型增加“领域知识 操作流程”实体文件往往就是一个 Markdown 加几个参考文件。所以两者可以共存skill 更轻、更贴近提示词到自动执行的中间地带。1.3 当前主流生态Claude Code、Codex、OpenCode 下的 skills 形态现在聊 skills基本绕不开三个环境。第一个是 Claude Code它把 skills 作为一项核心能力通常建议放在项目的.claude/skills/目录下或者用户的全局目录里每个 skill 是一个独立文件夹内部必须有SKILL.md。第二个是 OpenAI Codex在它的 CLI 版本里也支持类似的 skills 机制目录常见于~/.codex/skills/。第三个是 OpenCode它是开源社区里相对轻量的编码助手很多配置思路和 Claude Code 接近通常放在~/.config/opencode/skills/这样的位置。这三个环境的加载逻辑大同小异扫描技能目录、读取 SKILL.md 的元信息、根据用户输入做自动匹配。区别主要在路径规则、允许的辅助文件格式和少数参数上。所以你在 GitHub 上看到一个通用型 skills 仓库完全可以在不同工具里复用最多就是调整目录位置。后面我会专门讲手动安装的具体操作。2. 手动安装 GitHub 上的 skills不用命令行也能照做2.1 安装前先搞清楚 skills 的目录结构我在 GitHub 上翻 skills 仓库时发现新手最容易困惑的就是“到底该把哪个文件夹拷进去”。一个仓库里往往既有 README又有 example还有几十个 skill 子目录看得人眼花。这里先记住规则一个 skill 就是一个包含SKILL.md的目录。哪怕目录里只有一个SKILL.md只要这个文件名存在它就能被当成技能加载。辅助文件比如参考文档、模板、脚本、示例数据都放在这个目录里通过相对路径引用。以仓库里常见的skills/xxx/为例真正要复制的是xxx这一层也就是包含SKILL.md的那层而不是整个仓库。判断方法很简单打开 GitHub 网页进到某个目录里如果看到了SKILL.md那这一层就是一个 skill直接下载这一层的内容即可。如果看到的是很多子目录那就说明这个仓库是合集你需要按需选取。2.2 Claude Code 手动安装的完整步骤Claude Code 手动安装 GitHub 上的 skills我实践下来最稳的路径是这样第一步在 GitHub 网页上找到目标 skills 仓库。想省事就看仓库里有几个含SKILL.md的目录先下载整个仓库的 ZIP 包在本地解压。第二步确定安装位置。如果你希望这个技能只在某个项目里用就放到项目根目录下的.claude/skills/里如果希望全局所有项目都能用就放到用户目录下的~/.claude/skills/。没有这个目录就手动创建。第三步把解压出来的 skill 文件夹完整复制进 skills 目录。注意复制后检查一下路径最终结构应该是.claude/skills/你的技能名/SKILL.md中间不能多套一层不必要的父目录。第四步重启当前会话或者退出 Claude Code 后重新进入。我测试过新建会话时扫描最可靠旧会话偶尔会出现识别不到新技能的情况。第五步验证安装。直接在当前会话里提一个和该 skill 描述匹配的任务观察模型是否自动调用。如果不确定可以试着问“你现在有哪些可用技能”能列出刚才装的名字就说明加载成功了。注意安装后如果模型完全无视这个 skill先别急着怀疑路径。打开SKILL.md看 description 写的是不是足够具体的触发场景。我之前装过一个技能description 写得太宽泛结果模型宁可自由发挥也不加载它。2.3 Codex / OpenCode 的安装差异Codex 和 OpenCode 的安装逻辑和 Claude Code 大同小异最大的区别就是目录位置。Codex 这边常见路径是~/.codex/skills/也有的项目会提到.codex/skills/。我建议先确认一下你自己的 Codex 版本支持哪个路径直接看官方文档的配置说明最靠谱。复制方式和前面一样保证技能名/SKILL.md的结构不变。OpenCode 这边常见路径是~/.config/opencode/skills/同样是复制目录后重启会话。如果装完不生效可以检查两件事一是目录权限确保当前用户可读二是技能目录名里不要带空格和特殊符号命名尽量用连字符连接的小写单词。至于微软出品的 VS Code 扩展生态里也有类似机制但和这三个命令行工具不完全一样安装时别混着用。同一个 skills 目录不要同时复制给两个工具共用容易因路径依赖出问题。2.4 安装后的验证与权限小坑手动安装看起来简单但有几个坑我每次都要提醒自己。第一个坑是路径层级错误。把整个下载目录复制进去导致出现skills/仓库名/技能名/SKILL.md很多工具扫描不到。解决办法就是安装完立刻核对路径深度保持skills/技能名/SKILL.md。第二个坑是辅助文件的相对路径。如果 skill 目录里引用了references/xx.md或scripts/xx.py复制时要把这些子目录原样搬过去不能只搬SKILL.md。我之前偷懒只复制主文件结果 skill 加载了但找不到参考文件执行质量大打折扣。第三个坑是权限。Linux 和 macOS 上偶尔会有权限问题尤其是从压缩包解压出来的文件可读权限可能没设对。复制完可以用ls -l看一眼如果权限不足就手动加上读权限。第四个坑是缓存。有些工具会缓存已扫描的技能列表新装技能在旧会话里不生效非常正常。遇到这种情况新建一个会话比反复刷新更省事。3. 怎么写一个自己的 AI skill从需求到 SKILL.md3.1 先别急着写把流程拆成四件事很多参考教程上来就教 YAML 语法但我觉得真正该先做的是“拆流程”。你准备把哪类任务固化成 skill就要先把这类任务的标准动作拆成几件事。以我自己为例。我写过一个“数学建模赛题审题” skill起因是每次拿到赛题都要花二十分钟整理思路而且整理出来的结构不稳定。我先把这个任务拆成四件事读题并提取约束、判断问题属于哪类模型优化、预测、评价还是分类、列出数据需求和缺失项、生成初步的解决框架。拆完之后skill 的内容自然就有了骨架一个输入环节赛题原文、四个处理步骤、一个输出格式结构化的建模方案草稿。所以第一步不是学语法而是拿纸笔把任务流程写下来。一个任务如果连你自己都说不清步骤AI 也不可能通过 skill 学会。3.2 SKILL.md 的骨架长什么样一个标准的SKILL.md通常分两部分YAML 格式的元信息和正文内容。元信息里最重要的就是 name、description有些还会加 allowed-tools、license、metadata 等字段初学者可以先忽略。name技能名保持简短和目录名一致。description这行字是整个 skill 的灵魂决定了模型什么时候主动加载它。要写“什么场景下使用、能解决什么问题”不要写“这是一个能干的技能”。正文部分一般包含使用场景、前置条件、执行步骤、输出格式、常见错误和示例。用中文写完全没问题关键是步骤要具体。不要写“深入分析数据”要写“先计算描述性统计再检查缺失值比例超过 20% 的字段需要单独说明”。3.3 一个“数学建模赛题审题” skill 的编写实例我直接贴一个简化版的结构方便你理解实际长什么样。元信息可以这么写--- name: math-modeling-problem-review description: 当用户提供数学建模竞赛赛题或者提出需要拆解建模问题、判断模型类型、 梳理数据与假设时使用。适合赛题审题、论文建模部分启动阶段。 ---正文部分拆成步骤。第一步是“要素提取”要求模型列出目标、约束条件、已知数据、未知数据、评价指标。第二步是“题型判断”按优化、预测、评价、分类四个方向识别。第三步是“初步方案”给出每个候选模型的适用理由。第四步是“输出”固定用表格加短段落呈现。这个 skill 写好后我每次拿赛题进去试都能得到结构一致的审题结果后续建模思路的推进快了不少。我还在目录里加了一个examples/子目录放了几份真实赛题的分析结果作为 few-shot 参考实测下来比纯文字描述更稳。3.4 前端开发、AI漫剧场景的 skills 写法差异不同领域的 skill 侧重点不同。写前端开发类技能重点在规范约束和工程化步骤。比如一个“页面还原” skill我会在流程里强制要求先拆解设计稿的布局层级再定组件树然后处理状态管理最后才是生成代码并且要求生成代码后跑一遍边界检查清单。这类 skill 的价值是把“还原页面”从一次随意的代码生成变成按固定套路走的工程流程。写 AI 漫剧类技能重点在角色一致性和分镜逻辑。角色一致性靠的是角色卡描述包括外貌特征、服装、性格关键词、台词风格和禁止出现的变动项。分镜类 skill 则要规定镜头语言、场景切换规则和画面描述的统一格式。相比前端类技能它的参考文件更多通常需要references/里放角色设定和风格示例。所以写 skill 之前先分清你是在固化“工程流程”还是在固化“创作风格”这两类的正文写法完全不一样。工程流程适合用步骤清单和检查项创作风格适合用示例参考和反面约束。3.5 写 skill 的几条经验命名、粒度、依赖命名用英文小写加连字符目录名、name、SKILL.md尽量保持一致。粒度宁小勿大。一个 skill 只解决一类重复任务比如“审题”和“写论文摘要”拆成两个 skill不要合成一个大杂烩。依赖外部脚本时脚本路径用相对路径并把脚本也放进技能目录。description 里可以包含触发关键词但不要罗列几十个关键词写清楚“当用户想做 X 类任务时使用”就够。版本号可以写在 YAML 里方便以后维护到 git 仓库时区分版本。多写“禁止做什么”。比如数学建模审题技能里我会写“禁止在数据不完整时强行给出确定结论”这类负面约束比正向引导更有效。3.6 如何避免“写出来像个提示词模板”这是我被问得最多的问题。很多人照着语法写出来的 skill用起来和粘贴一段提示词没区别原因就在于没有“内部逻辑”。提示词是让模型自己发挥skill 是给模型一个规定路径。区别体现在正文的结构上提示词通常是“请你帮我做 X要求怎样怎样”而 skill 必须给出“第 1 步做什么、第 2 步基于什么判断、第 3 步输出什么格式”的可执行流程并且每一步之间要有前后依赖关系。另外一个关键点是 skill 里要有“决策分支”。比如数学建模审题技能里我会明确写如果数据缺失超过 30%应当先建议补充数据渠道而不是继续建模如果目标是分类则优先提示评估类模型的适用性。这种条件判断就是提示词模板给不出来的东西。写完以后还要做一次测试复盘。拿三到五个真实任务去跑每个任务明确四个问题有没有自动命中、输出是否稳定、步骤有没有遗漏、有无多余的废话。根据结果反推修改正文而不是一次写完就觉得大功告成。4. 值得收藏的 skills 推荐与技能库网址4.1 通用型 skillssuperpower skills 是什么水平GitHub 上被讨论最多的通用型技能合集之一就是 superpower skills。我一开始也挺好奇装完之后的第一感觉是它不是某一个技能而是一整套覆盖日常任务的基础库里面包含写作、阅读、编程、研究等方向的技能分类。这些通用技能适合当“底座”。比如它提供的研究分析类技能会在你给一个陌生主题时自动执行拆解、找信息、整理结论的流程写作类技能会先要求明确读者和文体再动笔输出。和单个工具类技能相比它更像一个能力框架适合刚接触 skills 机制、还不确定自己要什么的人。不过我要说一句实话通用技能库不是越多越好。superpower skills 的价值在于让你理解“好的技能长什么样”但具体项目里真正高频使用的往往还是你自己写的那几个专用技能。装它当学习资料和基础能力没问题别指望装完就一劳永逸。还有一类值得关注的是 typesafe AI 风格的 skills核心特征是注重类型定义和接口描述适合 TypeScript/前端工程化项目。这类技能会把输入输出结构定义得非常清楚模型生成代码时更少出现格式漂移。4.2 前端开发方向 skills前端方向的 skills 我比较常用的是这几类页面还原类输入设计稿截图或描述输出组件拆分、样式方案、响应式适配建议。组件开发类输入组件需求输出 Props 定义、状态逻辑、样式方案和单元测试。状态管理选型类根据项目规模和复杂度推荐合理的状态管理方案并给出迁移步骤。性能优化类输入性能问题描述输出排查流程、优化方案和验证方式。这类技能的共同点是“规范先行、生成在后”。否则 AI 生成的前端代码虽然能跑但和团队现有代码风格完全脱节改起来更痛苦。把团队的代码规范、目录结构、命名规则写进技能正文效果会好很多。4.3 数学建模方向 skills数学建模场景下我还真在华为杯等建模比赛筹备时整理过一套可复用的 skills核心价值就是让比赛期间的重复性工作更稳定。赛题审题类前面已经举过例专门解决“拿到题不知道怎么下手”的问题。数据探索类自动执行缺失值检查、异常值筛查、相关性初探并输出一份可放论文的数据说明草稿。灵敏度分析类针对优化模型自动生成参数扰动实验的设计方案和结果表格模板。论文结构类按赛题规定结构生成章节框架把摘要、问题分析、模型建立、求解、检验等环节规范化。这些技能不需要多复杂的代码重在把比赛流程中反复要做的事沉淀成标准动作。比赛时间紧张的时候这类技能省下的不只是几十分钟而是减少“这次又漏了一步”的随机失误。4.4 AI漫剧/内容创作方向 skillsAI 漫剧这两年讨论度很高相关技能的核心难点不在“画得好看”而在“角色稳定、剧情连贯”。我拆过这类 skills常见方向有角色卡管理类保存每个角色的固定描述、参考图要点、禁止变更项生成画面时自动引用。分镜脚本类把剧本拆成分镜表包含景别、镜头内容、角色动作、配音文案。风格一致性类固定画风关键词和负面提示词减少画面风格漂移。对白与字幕格式类输出统一的字幕断句和时间轴标注格式。这类技能大量依赖示例文件。我在写分镜类技能时会在目录里放几个分镜表示例作为参照比在正文里描述“要写清楚景别”有用得多。4.5 常用 skills 源网站整理我平时找 skills 主要靠这么几个渠道整理成一张表方便你对照。渠道主要用途备注GitHub 直接搜索搜awesome claude skills、codex skills等关键词认准仓库里真的有SKILL.md目录各种 awesome 合集仓库按领域浏览已经被分类好的技能列表注意看最后更新时间太久没更新的谨慎下载skill 作者个人主页关注活跃作者跟踪新技能发布优先看有配套示例的作者官方文档的示例区学习标准写法和推荐目录结构适合刚开始写 skill 的人开发者讨论区查看真实用户反馈和踩坑记录注意区分宣传话术和实测结论有了这些渠道最容易犯的毛病就是“装到停不下来”。我建议每次逛技能库网站都给自己定个规矩今天只挑一个最匹配当前项目的装完立刻试用不合适就删而不是批量下载后再慢慢试。4.6 挑选 skills 的三条铁律第一优先选有示例目录的。只有SKILL.md没有任何参考文件的技能单靠文字描述很难保证实际效果。第二看 issue 区有没有人报错。技能这类东西很容易在版本更新后失效如果评论区有人反馈“不生效”且作者没回应果断跳过。第三先读SKILL.md再决定装不装。很多技能仓库的“包装”做得很好但正文内容空泛。打开之后如果发现步骤含糊、大量套话直接放弃这种技能装进去只会增加扫描负担。5. 多用之后必踩的坑Skills 清理与维护5.1 为什么 skills 越装越乱任何长期使用员工技能的系统都会面临一个共同问题——随着时间推移技能数量不断增加但真正高频使用的可能就那么几个。我见过某人目录里躺着四五十个技能每周真正被命中的不超过十个。很多技能运行时还会互相干扰一个技能的 description 写得太宽泛把原本属于另一个技能的任务抢走了导致输出不稳定。另外技能目录里的参考文件越攒越多每次模型加载全部元信息也会增加额外的上下文开销影响响应速度。所以别把技能库当收藏夹。你收藏的每个技能都有运行成本定期做“断舍离”是必备动作。5.2 清理 skills 的方法与思路网上流传着很多清理思路tibo 那类做法我实践过核心就是三步盘点、分类、处置。第一步盘点。把 skills 目录下的技能全部列出来逐一看SKILL.md里的 description记下每个技能宣称的用途。第二步分类。按使用频率分成三组一周内至少用一次的保留一个月内用过但频率不高的搁置装了之后完全没被命中过或者总是重复冲突的列为待清理。第三步处置。不建议直接删。把待清理的目录移动到skills_disabled这样的备份目录观察两个星期。如果期间完全不影响正常工作再决定是否彻底删除。这个“观察期”能有效避免手滑删掉某个偶尔才用到的关键技能。5.3 给 skills 做“卫生管理”的日常习惯清理是治标日常习惯才是治本。我现在每周花十分钟做技能卫生管理主要就三件事检查新技能有没有触发过。过了两周还没被触发过的要么是 description 写得不到位要么是压根没需求先找原因。统一命名风格。目录名全部用小写连字符避免出现一个叫数据分析、一个叫DataAnalysis的情况。维护一份 README 清单。记录每个技能是干什么的、来源在哪里、最后修改时间。等技能多了你就会发现这份清单比技能本身还值钱。版本管理也很重要。如果你自己维护了一批技能别只放在本机目录里用 git 仓库管理起来每次修改按小步提交这样出问题还能回滚。5.4 冲突与优先级同名 skills 覆盖问题多技能环境下最常见的坑就是同名覆盖。一个技能叫code-review来自某个合集仓库另一个也叫code-review是你同事分享的。两个复制到同一个 skills 目录里后者会覆盖前者或者加载顺序不稳定导致行为不可预测。解决办法是安装时就改好目录名在每个技能目录名里带上来源标识比如code-review-zen。更稳妥的做法是在管理清单里记录每个技能的来源 URL出问题能快速定位。还有一个容易忽略的优先级问题项目级技能和全局技能同名时哪个生效取决于工具自己的加载规则。别靠猜直接试在项目目录里放一个同名但行为不同的技能看工具实际加载的是哪个然后记住这个规则以后就不再踩同一个坑。我在实际整理这些 skills 的过程中最深的体会是真正值钱的不是技能数量从 0 涨到 100 的成就感而是把某类重复工作彻底标准化之后AI 输出质量和原先相比稳定太多了。这中间当然有安装失败的烦躁也有写了新技能第一次就命中的惊喜。最后再分享一个小技巧每次新学一个技能不要只把它当成“装备”装上便走花十分钟读一遍它的 SKILL.md看懂作者为什么这么设计这比装十个技能都长进快。