上个月我在用 Claude Code 重构一个老项目发现同一个模型、同一套配置文件装了一组 Skills 前后的效率差别大到离谱。没装之前每次让它做代码审查都要重复交代“你要注意什么、按什么顺序看、最后输出什么格式”装完之后一句话“帮我 review 一下这次的改动”它自己就把流程跑完了。那时候我意识到AI 编程助手真正拉开差距的不是模型本身而是有没有沉淀出一套可复用的 Skills。这篇文章就围绕“Skills”这件事展开它到底是什么和普通提示词有什么区别怎么从 GitHub 手动装别人写好的怎么自己动手写数学建模、前端开发、AI 漫剧这些场景里怎么挑合适的以及最后怎么把 Skill 库维护干净。不管你是刚接触 Claude Code、Codex 还是 OpenCode这篇都值得看完因为 Skills 是把 AI 工具从“聊天机器人”变成“熟练工”的关键一环。1. Skills到底是什么以及它和普通提示词的本质区别1.1 同一个模型两种战斗力先讲个最直观的对比。比如让 AI 帮你搭建一个 React 项目脚手架。没有 Skills 的时候你得自己把需求拆成一堆话“请用 Vite 创建项目配置 TypeScript、ESLint、Prettier路由用 React Router状态管理用 Zustand然后装好 Tailwind最后把目录结构列出来。”它做完这一步你还得一步步指挥它继续装依赖、改配置、建目录整个过程像挤牙膏。有 Skills 的时候比如装了一个react-scaffolder技能你只需要说“帮我搭一个中后台管理项目的前端骨架”它就会自动读取 Skill 里的流程检查环境、执行脚手架命令、安装依赖、生成规范目录、补上 ESLint 和 Prettier 配置、最后输出一份项目说明。中间很多细节它通过 Skill 里固化的脚本和模板自己搞定了你只需要在旁边看结果。这个差别背后其实是知识存放位置的差别普通提示词把经验放在对话里关掉窗口就没了Skills 把经验放在文件里这次用完下次还在换个人用也能继承。1.2 Skills机制的内核不是提示词是“可复用能力包”很多人第一次接触 Skills以为它就是“预置好的一长段提示词”。这个理解不准确。Skils更接近一个“可复用的能力包”结构上通常包含四个层次元数据SKILL.md 开头用 YAML 格式写的 name 和 description负责告诉模型“你叫什么、适合在什么场景被调用”。过程指令主体部分写的执行流程告诉模型“接到任务后按什么顺序做、每一步做到什么程度”。附属资源脚本、模板、参考资料比如一个 Python 脚本、一份 LaTeX 论文模板、一组代码审查规则。按需加载机制Skill 的内容不会像系统提示词那样每次都全量塞进上下文而是模型判断任务匹配时才会把相关部分加载进来。做个类比普通提示词像一张写在纸上的菜谱每次做饭都要从兜里摸出来看一眼Skills 像一个“预制菜料理包”把菜谱、切好的食材、调料包和操作流程全打包了下锅前才拆开按步骤操作就行。它省的不只是写提示词的时间更重要的是省了模型的思考成本——不用每次从零理解你的项目习惯和偏好。1.3 Claude Code、Codex、OpenCode三套生态的差异不同的 AI 编程工具对 Skills 的支持方式不完全一样这个一定要先搞清楚不然你照着某个教程装完发现不生效还以为是自己操作错了。Claude Code比较典型的实现支持项目级.claude/skills/目录和用户级~/.claude/skills/目录也支持在对话里用/skill命令手动触发或者靠模型根据 description 自动触发。OpenAI Codex类似的能力通常放在~/.codex/skills/下也会配合AGENTS.md文件一起工作适合把项目的长期约定和一次性技能分开管理。OpenCode 等开源 CLI 工具各有各的约定有的读~/.config/opencode/skills有的直接兼容 SKILL.md 格式。装之前最好先看一眼官方文档的“Skills”章节。兼容性方面SKILL.md 这个文件格式在社区里越来越接近事实标准很多从 GitHub 下下来的 Skills稍微改一下目录位置就能在多个工具间迁移。但脚本和模板里的工具链依赖是没法通用的比如为 Claude Code 写的 Bash 脚本拿到 Codex 里可能要改执行权限或者路径。我的建议是先选定一个主力工具把它生态里最成熟的 Skills 吃透再考虑跨工具迁移不要一上来就铺开那是给自己找麻烦。2. 手把手从 GitHub 手动安装 Skills几步就能跑起来2.1 动手前先确认环境CLI工具版本不是小事安装 Skills 之前先把基础环境确认好否则很容易装了个寂寞。至少要做到以下三点确认你的 CLI 工具已更新到支持 Skills 的版本。Claude Code 早期版本对 Skills 的支持不稳定有些功能要开启 beta 或特定版本才有Codex 客户端也一样如果你很久没更新Skills 目录可能建了它也不读。确认安装位置。用户级目录对所有项目生效适合放通用技能项目级目录只对当前项目生效适合放和业务强相关的技能。两者可以共存同名时项目级优先级更高。确认目录不存在权限问题。~/.claude/skills这种目录如果不存在手动创建时要注意读写权限特别是用 Docker 或远程开发环境的时候挂载目录的权限经常导致技能读不到。另外如果你用的是公司统一管理的开发机装了终端管控或文件过滤工具也可能会拦截 Skills 目录里的脚本执行遇到“明明装好了却跑不起来”的情况可以先往这个方向排查一下。2.2 看懂一个Skill的目录结构从 GitHub 上下载的 Skills 项目通常长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── analyze.py ├── templates/ │ └── report.md └── references/ └── best-practices.mdSKILL.md是灵魂它决定了这个技能的名字、触发条件和执行流程。scripts/放可执行的脚本用来做那些“用自然语言描述太啰嗦、用代码一行就搞定”的事情。templates/放输出模板保证 AI 生成的结果格式统一。references/放参考资料体积比较大平时不加载进上下文只有需要深入细节时才按需读取。有些小而美的技能就只有SKILL.md单文件内部用清晰的段落描述流程没有任何附属资源这也完全没问题。目录结构的复杂程度应该和技能本身的复杂度相匹配没必要为了“显得专业”硬塞一堆文件。2.3 GitHub上搜到项目后手动安装的五个步骤假设你在 GitHub 上找到了一个想要安装的 Skill完整的手动安装流程如下先把仓库克隆到本地临时目录比如git clone https://github.com/某个仓库.git /tmp/xxx-skill。不要直接 clone 到 Skills 目录里因为仓库里通常还有 README、LICENSE、示例文件这些和技能运行时无关的东西直接放进去会干扰模型对 Skill 结构的识别。打开SKILL.md看一眼开头部分的 name 和 description确认你的工作场景和它匹配。这一步很关键因为 description 写得不好的 Skill装多少都没用AI 压根不会在正确时机调用它。把仓库里真正属于 Skill 的目录复制到目标位置。用户级就放到~/.claude/skills/或~/.codex/skills/项目级就放到当前项目下的.claude/skills/或对应工具的目录。复制后把目录名改成技能名比如react-scaffolder。检查一下scripts/下的脚本有没有可执行权限必要时执行chmod x scripts/xxx。这一步在 Linux 和 macOS 上很容易被忽略Windows 上用 Git Bash 也会遇到类似问题。重启你的 CLI 会话然后运行命令查看技能列表确认它出现在列表里。如果你不想用 git clone也可以直接在 GitHub 网页端下载整个仓库的 ZIP 包解压后执行同样的步骤。没有本质区别只是路径不同而已。2.4 装完怎么验证它真的生效了安装完最怕的就是“假装生效”。验证方法有两种第一种被动验证。用自然语言描述一个 Skill description 里明确覆盖的任务看模型会不会主动调起这个技能。如果它调起了说明自动触发机制工作正常如果没调起不一定是装坏了也可能是 description 匹配度不够高。第二种主动验证。用 CLI 命令直接调用Claude Code 里是/skill 技能名Codex 里可以直接把技能名作为任务的一部分。这种方式跳过自动匹配只要命令能执行就说明文件路径和格式没问题。我自己习惯的做法是装完先主动调一次确认它能跑再清理一下对话历史用自然语言触发一次确认自动匹配也没问题。两步都过了这个 Skill 才算真正装好了。3. 自己动手写 AI Skill核心规则与常见误区3.1 最小可用的SKILL.md长什么样先看一个能直接用的最小示例--- name: code-reviewer description: 当用户要求审查代码、查找 bug、评估代码质量或检查可维护性时使用。适合在提交前、合并前和代码重构后触发。 --- # Code Reviewer ## 执行流程 1. 先读取目标代码文件理解整体结构和职责。 2. 按优先级检查正确性漏洞、边界条件、错误处理、性能隐患、可读性。 3. 对每个问题给出文件路径、行号、问题类型、严重程度、修改建议。 4. 最后输出一份按严重程度分组的问题清单并用 markdown 表格呈现。 ## 注意事项 - 只报告真实存在的问题不要为了凑数量强行挑刺。 - 修改建议要具体到可以执行的代码片段。 - 如果代码有明显的外部依赖先确认依赖关系再下结论。这个示例麻雀虽小五脏俱全。YAML frontmatter 里的 name 和 description 是给模型看的“触发条件”正文里的执行流程是给模型看的“操作手册”。模型在对话中实时判断该不该调用这个 Skill靠的主要就是 description 里的关键词和意图描述。很多人第一次写 Skill正文写得很嗨frontmatter 随便糊弄两句结果 AI 根本不会主动用就是这个原因。3.2 description决定AI何时调用这才是核心中的核心如果让我从 Skill 的所有组成部分里只能选一个认真打磨我一定选 description。原因很简单模型不是把每个 Skill 的内容都读一遍再决定用哪个它的决策过程更像是一个“短名单匹配”——根据你的当前任务快速扫一遍所有 Skill 的 description看哪个命中。所以 description 写得好的标准是让模型在 0.5 秒内判断出“该用”或“不该用”。几个实用技巧用动词开头“当用户要求审查代码时”“当用户需要生成合同文本时”“当需要分析日志文件时”。把同义说法写进去比如审查代码的 Skill不只要写“审查代码”还要写“找 bug”“评估代码质量”“代码 review”“检查可维护性”。明确适用范围和排除项比如“适合 JavaScript/TypeScript 项目不适用于 Python”。不要写得太泛。一个 description 写着“处理所有常见编程任务”的 Skill实际上等于什么都没说模型宁可不用它。反过来description 写得太窄也有问题。我有一次写了个前端脚手架 Skill只有一句话“当用户要求创建 React 项目时使用”结果用户说“帮我搭个管理后台前端”模型就没触发。后来把 description 改成“当用户要求创建 React 前端项目、搭脚手架、初始化中后台项目、或需要生成前端项目目录结构时使用”触发率一下子就上来了。3.3 给Skill做上下文瘦身的三招Skill 装多了之后你会发现一个矛盾每个 Skill 都想把自己写详细但模型上下文窗口就那么大详细信息全堆进去反而挤占正常对话空间。这时候需要做上下文管理。第一招大段参考资料丢到references/目录正文里只写一句“必要时查阅references/xxx.md”。模型很聪明你告诉它哪里有资料它需要时会自己去看不需要时不会浪费 token。第二招能用脚本代替的静态清单就不要写在正文里。比如你希望 AI 遵循某个特定规范做代码检查与其在 Skill 里列 50 条规则不如写一个脚本读取规则文件并输出检查结果Skill 正文只需要告诉模型“运行scripts/check.py并根据输出结果整理报告”。第三招保持单一职责。一个 Skill 只做一件事做到极致。不要写一个“全栈开发助手”把前后端、数据库、部署全塞进去那样看起来全能实际上调用时上下文爆炸、执行时方向混乱远不如拆成四五个独立 Skill 好用。3.4 三种最常见的“写废Skill”姿势写废 Skill 不是报错那种“废”而是“看着能用、实际难用”。我见过的三种典型姿态你写完可以对照自查第一“功能清单型”。正文罗列了三十条它“可以做”的事但没有流程没有输出格式模型调用后完全不知道从哪一步开始。这种 Skill 本质上就是换了个文件的提示词价值很低。第二“没有验收标准型”。流程写到“检查代码质量”就停了什么算好输出什么格式用户拿到报告怎么处理全都没说。模型只能自由发挥十个任务给你十个不同的输出结构。第三“重流程轻脚本型”。一些流程明明可以用 20 行脚本自动化偏要用自然语言让模型读文件、找内容、再写小结既慢又容易出错。Skill 里凡是能固化成代码的步骤都应该优先考虑写成脚本。我自己踩过最深的一个坑就是写数学建模类 Skill 时贪图“全面”把数据预处理、模型选择、论文生成全塞进一个 Skill结果每次调用上下文直接顶到上限输出质量反而差。后来拆成数据处理和论文排版两个独立 Skill情况立刻好转。4. 实战推荐数学建模、前端开发、AI漫剧等场景的Skills选择思路4.1 数学建模/竞赛场景Codex Skill怎么选数学建模竞赛圈子里用 Codex Skills 的人越来越多。这类场景的需求非常典型数据预处理、模型选型、结果可视化、论文排版。如果你要参加华为杯这类比赛找 Skill 时注意这几点优先找“数据处理 pipeline”类技能。它通常包含读 csv/excel、缺失值处理、特征缩放、自动生成探索性图表。这类技能能极大节省赛前数据清洗的时间。论文排版类技能要选支持你所用模板的比如提供 LaTeX 或 Word 模板的那一种。它应该约定摘要写多少字、图表怎么编号、公式怎么引用、参考文献格式。模型选型辅助类技能重点看它是否包含“根据数据量和数据类型推荐算法”的逻辑。好一点的 Skill 还会附带时间复杂度和适用条件说明。需要特别提醒的是比赛场景通常对 AI 辅助有限制用 Skills 提效没问题但最终提交的论文和代码应对细节负责的是你自己。我在实际使用中会把 Skills 定位成“初稿生成器”所有关键结论都人工复核一遍再提交不然出了学术规范问题吃亏的是自己。4.2 前端开发场景项目脚手架与代码审查的成熟方案前端开发的 Skills 是社区里最成熟的方向因为前端工程化的痛点多、重复劳动多非常适合固化流程。我最常装的是这几类技术栈脚手架类对应 React、Vue、Next.js 等框架除了初始化项目还会自动配置 lint、格式化、目录结构、基础组件、路由和状态管理。迁移升级类比如把 webpack 项目迁移到 Vite把 JavaScript 改写成 TypeScript把 Class 组件改写成函数组件。这类 Skill 通常有脚本辅助改动量大但容错率高。性能优化类制定审查流程从 bundle 体积、渲染次数、网络请求三个维度分析瓶颈输出优化优先级列表。可访问性审查类检查语义化标签、键盘导航、对比度、aria 属性输出可执行改进清单。挑选前端 Skills 时最重要的判断标准是“是否匹配你的技术栈”。一个给 Vue 项目设计的审查 Skill用在 React 项目上会输出一堆无关建议。我在 GitHub 上下载 Skill 时一定先看它的 description 里声明了哪些技术栈没声明的默认不装。4.3 AI漫剧与内容创作跨领域的Skills思路AI 漫剧这类内容创作方向听起来和编程八竿子打不着但借用 Skills 的思路反而特别有用。创作类任务的核心痛点是“风格一致性”编剧的风格、分镜的风格、角色描述的风格每次对话都可能漂移。Skills 正好能解决这个问题。比如你可以写一个“AI漫剧编剧”Skill把固定的人设信息、世界观设定、冲突节奏模板、台词风格要求全部放进去。每次只写一句话“用这个 Skill 生成某场景的脚本”模型就会按统一风格输出不会再出现上一集角色高冷、下一集角色逗比的问题。再比如分镜描述把镜头语言规范写进 Skill让它每次输出都包含景别、角度、运动方式、时长和画面描述。这种结构化的输出对后续图生视频环节帮助非常大。内容创作方向装 Skills最需要想清楚的是“哪些东西是每次都要重复交代的”那些东西就是 Skill 的原材料。4.4 我最常驻的几个Skill来源整理很多新接触 Skills 的朋友最大的困惑不是不会装而是不知道去哪找优质技能。我整理了自己常用的几个路径按优先级排序GitHub 直接搜关键词比如claude skills、codex skills、awesome-skills。项目简介里看 star 数和更新时间star 高且最近一年还有更新的相对靠谱。Awesome 类列表仓库通常把社区里的 Skill 按场景分类整理适合系统性浏览。技术社区和社交平台上的推荐帖子不少开发者会把自己的 Skill 库开源还会写使用心得这些说明比单纯看 README 更有价值。某些短视频和博客里提到的“某博主分享了清理 Skills 的方法”这种具体方法通常不单独成文但思路你可以实践后面我专门讲。要不要下载一个 Skill我建议至少看三样东西README 的使用说明、SKILL.md 的 description 质量、以及最近更新日期。README 写得认真说明作者在维护description 质量直接决定触发率更新日期太老的很可能已经和当前 CLI 版本不兼容了。5. 管理、清理与迭代一个成熟开发者怎么维护自己的Skill库5.1 为什么要定期清理不用的Skill不只是占地方Skill 装多了以后我的第一反应是“反正放着也不碍事”。实际上不是。每次模型判断是否调用某个 Skill都需要把当前任务和所有 Skill 的 description 做一次匹配。虽然这个过程的 token 开销不算大但 Skill 数量过多后匹配准确率会下降经常出现“该调的没调、不该调的乱调”的情况。举个例子我有一段时间装了四五个和代码审查相关的 Skill分别来自不同作者description 还都写得特别宽泛。结果我让 AI “检查一下代码逻辑”它随机挑了一个开源的通用审查 Skill 触发忽略了我自己写的那个专门针对本项目规则的 Skill输出质量反而不如不触发。这就是典型的“技能太多、互相干扰”。定期清理本质上是在降低模型的决策噪音。把不用的删掉剩下的每个 Skill 才有更大的概率被准确触发。5.2 一个挺实用的清理方法和判断标准之前在社区看到有位博主分享过一套清理方法我自己用下来觉得很实用分享给你先不动手删。把你当前所有 Skill 列出来按照“最近一个月是否主动用过、是否在关键路径上被触发过、是否和当前业务方向匹配”三个维度打分。把明显不合格的禁用掉别直接删除禁用后观察一到两周。这期间如果没有任何一个任务表现出需要它再彻底删除。清理频率不用太高一个季度做一次就够。频繁清理会打断自己的工作节奏也会把一些不常用但关键时刻有用的技能误删。按照这个流程我以前 50 多个 Skill 精简到二十个左右触发准确率明显提升。尤其在我同时做前端项目和数学建模项目时把技能按项目分开后匹配错的概率小很多。5.3 目录组织与版本管理清理只是第一步维护一个有章法的 Skill 库还需要合理的目录组织和版本管理。我的做法是把通用技能放在用户级目录比如常用的代码审查、日志分析、文档生成。把项目相关技能放在项目级目录比如某个项目特有的目录结构检查、部署流程。项目级技能跟着项目走团队成员 clone 仓库后直接能用不需要每个人手动装一遍。用 Git 管理整个 Skills 目录每次增删改都提交一次。这样如果某个技能改坏了可以随时回退想换设备或者换公司直接把仓库 clone 过去就完成迁。在命名规范上建议全小写加连字符如code-reviewer、react-scaffolder、modeling-data-pipeline。命名清晰一是便于 CLI 命令手动调用二是避免同名技能在不同目录里产生覆盖混乱。关于归档我在清理时会把“以后可能还能用”的技能放进一个专门的归档目录不参与正常加载但也不删除。这个目录其实帮了我大忙——有次某个旧项目突然要求重新跑一遍数据处理流程直接从归档里拖出来就能用不用惦记重新写。最后再分享一个维护心得定期给 Skill 做“小版本更新”。每次你发现某个 Skill 的 process 和实际操作不一致不要嘴上说“下次再改”当场就把它改掉。我自己就吃过这个亏——有一个数据处理 Skill后来数据格式改版了我没及时更新结果比赛当天调用时逻辑全错只能现场救火。Skills 是死的业务是活的你的 Skill 库需要跟着业务一起迭代这才是它长期保持好用的根本原因。如果你现在刚开始接触 Skills我的建议很直接先别急着收藏一大堆挑一个和你日常工作最贴近的普通任务写一个最小可用的 Skill然后在真实场景里用起来。你会发现当那些重复交代了无数次的流程终于被自动化的时候那个“原来如此”的感觉就是 Skills 真正上手的开始。