如果你最近刷 GitHub 或者技术社区很难不注意到“skills”这个词被反复提起前端开发 skills、superpower skills、codex skills、opencode skills……好像一夜之间所有 AI 编程工具都在讲技能。说实话我第一次看到这个词的反应是这不就是换了个名字的提示词吗直到我自己在 Claude Code 和 Codex 里装了几个开源 skills跑完一个真实项目才意识到这东西和提示词完全不是一个量级。这篇文章我打算一次性讲透围绕“skills 是什么、怎么写、怎么手动装 GitHub 上的第三方 skills、不同场景怎么挑、资源站怎么找、装多了怎么清理”这六件事展开。中间会穿插我自己踩过的坑和验证过有效的操作适合两类人一类是刚入坑 AI 编程、只听过高频词但没实际玩过的同学另一类是已经用了一段时间觉得 skills 不好用、不会触发、装了没效果的老手。认真看完你应该能直接从零到一搭出一套自己用着顺手的 skills 仓库。1. 先搞清楚一件事AI 编程里的 Skills 到底是什么1.1 为什么 2025 年人人都在提 skills过去一年AI 编程工具的核心变化不是模型变聪明了多少而是工具的形态变了从“你问一句、它答一句”的聊天框变成了 Agent 自主开工的自动驾驶模式。Claude Code、Codex、OpenCode 这些工具已经能自己读仓库、跑命令、改文件、重复执行任务。这时候问题就来了——模型本身是通才但很多任务是需要行业专业流程的比如“数学建模的完整报告该怎么排”“前端组件怎么按公司规范生成”“评审一段代码要按哪些维度打分”。这些流程靠对话一次一次临时聊效率极低而且结果不稳定。skills 就是为解决这个问题出现的。它的本质是把某类专业任务的完整流程、判断标准、写代码模板、注意事项打包成一个固定模块预置到 AI 工具里。模型遇到对应任务时会自动读取这个模块按照里面的步骤去执行。你可以把它理解成给 AI 请了一组专科医生——平时不下诊断但一遇到对应科室的病就直接按 SOP 处理而不是临时翻书。真正让 skills 火起来的是几大主流工具都开始原生支持这套机制。Claude Code 有 skills 目录Codex 有 skills 目录OpenCode 也有。生态一统一GitHub 上的 skills 仓库就像雨后春笋一样冒出来前端开发 skills、建模 skills、内容创作 skills、清理类 skills……于是就有了你搜到的那些热搜词。1.2 Skills 和普通提示词、自定义指令的根本区别很多人把 skills 和提示词混为一谈这是最大的误区。我用一张表说清楚三者的差异维度普通提示词自定义指令如 CLAUDE.mdSkills作用方式每次对话临时输入常驻上下文任何任务都可能参考按需触发只有匹配任务才加载结构化无全靠模型发挥偏偏好声明缺少执行步骤有 YAML 头部 步骤 校验清单可复用性每次都要重新写长期有效但会占用上下文独立模块可安装、可卸载、可分享适合场景一次性问题项目级规范、偏好专业流程、专项任务对上下文的影响仅当次持续占用越多越挤不触发则基本无感新手最容易犯的错误就是把项目里所有专业流程都写成 CLAUDE.md 式的“注意事项”。你可以把 CLAUDE.md 想成是给 AI 的“员工手册”——它永远在那里适合写通用规范而 skills 是“操作标准流程文件”需要时才翻开。如果员工手册上千页员工反而没法干活。同理如果你把十几个专业流程全塞进自定义指令里模型每轮都要消化大量文字决策质量会明显下降。我自己的经验是只要是“能在 3 步以内说清楚的小偏好”放指令文件只要涉及“5 步以上的专业流程、需要稳定产出格式”的做成 skills。这个分界线越清楚你的 AI 工具用起来就越顺手。2. 从零开始手写第一个 Skills 的正确姿势2.1 SKILL.md 的核心结构拆解先看一个最基础的 skills 目录长什么样。以 Claude Code 为例一个合格的 skill 就是一个文件夹放在~/.claude/skills/下~/.claude/skills/ └── code-review/ # 技能目录名字用短横线 ├── SKILL.md # 技能主文件必须叫这个名字 ├── checklists/ # 可选子校验清单 │ └── review-detail.md ├── scripts/ # 可选辅助脚本 │ └── scan_security.py └── references/ # 可选参考资料 └── team_style_guide.mdSKILL.md 是灵魂它分两部分YAML frontmatter 和正文。frontmatter 是给工具做“路由”的正文是给模型做“执行”的。我用一个我自己在生产环境里验证过的例子讲--- name: code-review description: 对代码变更进行静态审查输出问题清单、修改建议和风险等级。 适用于 PR 评审、提交前自检、接手他人代码时的初步检查。 若不明确需要审查的具体文件可先列出变更文件再执行。 allowed-tools: bash, read --- # 代码审查技能 ## 适用边界 本技能面向常规工程代码不处理安全渗透类专项审查。 如需检查依赖漏洞请先执行依赖审计命令再进入本流程。 ## 执行步骤 1. 获取变更范围列出本次新增、删除、修改的文件。 2. 高亮重点文件优先审查逻辑密集、改动量大、涉及数据写入的文件。 3. 按以下维度逐项核对 - 正确性边界条件、异常路径、并发冲突 - 可读性命名是否清晰、函数是否过长 - 安全性外部输入是否校验、密文是否硬编码 4. 输出格式必须为 Markdown 表格包含文件路径、行号、问题描述、严重程度。 ## 验收标准 - 每个问题必须给出行号或可定位的关键字 - 严重程度只允许 critical / major / minor - 没有问题时也要明确说明“未发现严重问题”有没有发现关键点description 写得非常具体甚至写明了“若不明确需要审查的具体文件可先列出变更文件再执行”。这比“擅长代码审查”这种废话有用一百倍因为模型就是靠 description 里的语义向量去匹配触发条件的。2.2 让模型真正“会调用”的小技巧我做完第一个 skill 后最大的困惑是“它为什么不触发”。后来我总结出四个影响触发的关键因素缺一个都白搭。第一description 里必须写明触发场景和边界最好是“当出现 XX 情况时使用本技能”。不要写“这是一个用于代码审查的技能”而要写“当用户要求对代码进行审查、评审、检查代码质量时使用本技能。若用户只要求解释某段代码不使用本技能”。前后两句一起写触发准确率高很多。第二正文里要有“输入 → 执行 → 输出”的闭环。很多手写 skill 只有一堆注意事项没有步骤和产出格式。模型读完之后不知道第一步干什么也不知道最后要交什么于是输出就回到自由发挥的老路。我的经验是至少给 3 到 7 个明确步骤并指明最终产出格式。第三给一个冷启动样例。在正文最后加一个小节叫“示例输入与期望输出”用一段简短代码演示真实输入长什么样、输出长什么样。模型对样例的学习效率比对规则描述高得多这一点我在调 trigger 时反复验证过。第四学会验证。装完 skill 后不要直接问“你有 skills 吗”——模型大概率会回答有但那是它顺着你的话在说。正确的验证方式是给它一个具体的小任务观察它的输出是否明显贴近 skill 里的步骤和格式。比如审查技能的验证方法就是给模型一小段有明显 bug 的代码看它是否输出了带严重程度的 Markdown 表格而不是普通聊天式的回答。3. 手动安装 GitHub 上的 Skills一套能通吃的流程3.1 前置准备先确认你的工具支持哪种加载方式网上一搜“skills 安装”能看到各种说法有的是claude skills add有的是直接丢文件夹还有的要改配置文件。其实大部分工具目前都支持“目录扫描”和“命令注册”两种方式。我这里主要讲最通用、最不容易出错的目录方式以 Claude Code 和 Codex 为例工具默认 skills 目录支持命令生效方式Claude Code~/.claude/skills/claude skills新会话自动扫描Codex~/.codex/skills/codex skills新会话自动扫描OpenCode~/.config/opencode/skills/无内置命令手动放目录重启会话生效动手安装前先跑一下工具自身的版本命令确认版本别太老。某些早期版本对 skills 的支持是半成品装了也不会读。我自己就遇到过 Codex 某个版本skills目录识别时好时坏升级版本后问题消失所以推荐把“升级工具版本”放到排查第一步。3.2 从克隆仓库到正式生效的完整步骤GitHub 上绝大多数 skills 仓库结构都是这样的仓库根目录下有一个skills/文件夹里面一个子文件夹对应一个技能也有的是把技能直接放根目录。所以安装的正确姿势不是整个仓库塞进skills目录而是只复制需要的技能子目录。下面给一套完整的 bash 命令可以直接抄# 1. 把仓库克隆到临时目录 git clone https://github.com/example/awesome-skills.git /tmp/awesome-skills # 2. 看一眼仓库结构找到 skills 子目录 ls /tmp/awesome-skills ls /tmp/awesome-skills/skills # 3. 把指定技能复制到 Claude Code 的 skills 目录 # 注意是 cp 技能子目录不是 cp 整个仓库 mkdir -p ~/.claude/skills cp -r /tmp/awesome-skills/skills/code-review ~/.claude/skills/ # 4. 检查复制结果确认 SKILL.md 路径正确 ls ~/.claude/skills/code-review/SKILL.md # 5. 回到项目目录重启一个会话开始验证 cd ~/your-project这套流程在 Codex 上同理把第二步里的目录换成~/.codex/skills/就行。核心原则是SKILL.md必须位于“技能目录”的下一层而不是嵌套好几层。见过太多人把仓库直接 clone 进~/.claude/skills/下结果变成~/.claude/skills/repo-name/skills/skill-name/SKILL.md工具扫描不到然后跑来群里问为什么没反应。3.3 安装后不生效怎么办五个高频问题定位如果你按上面的步骤做了发现新会话还是不认识这个 skill别急着骂工具。按这个顺序排查大概率能解决。第一目录层级错误。SKILL.md不能直接放在~/.claude/skills/根目录下必须包在一层技能文件夹里。这是新手最高频的坑。检查命令find ~/.claude/skills -name SKILL.md如果输出路径里缺少技能文件夹那一层就重新 cp 一次。第二frontmatter 格式不合法。name必须是短横线格式不能用中文、不能用空格description不能写太长我一般控制在 200 字以内太多会让语义匹配变得很模糊。如果 YAML 里不小心用了 tab 缩进也会直接解析失败。用文本编辑器打开 SKILL.md 检查一下格式。第三命名冲突。两个技能用了同一个name工具只会加载其中一个具体加载哪个还不确定。安装新技能前先看一眼现有目录里有没有同名文件夹。第四对话上下文残留。有些工具在当前会话内不会重新扫描目录必须开一个新会话才生效。如果你是在跑了一半的项目里装的请先手动结束会话再重来。第五模型或工具版本不支持。这个前面提过升级工具版本后再试。很多 skills 仓库里的用法依赖比较新的 API老版本确实跑不了。4. 按场景挑 Skills从前端到数学建模的实战清单4.1 前端开发与 superpower 这类全能技能包前端是 skills 生态最成熟的领域之一。原因也简单前端开发流程高度规范从组件生成、样式整理、到可访问性检查都有标准的产出物非常适合做成技能模块。我自己常驻的几个前端 skills 是React 组件生成技能输入需求描述按团队规范输出组件代码、props 类型定义、单元测试骨架。TypeScript 类型补全技能把带any的代码重构为精确类型同时识别全局类型滥用。可访问性审查技能检查页面按钮、表单、图片 alt、键盘导航等维度输出问题清单。CSS 类名整理技能分析样式文件中的重复和冲突给出重命名建议。这里必须提一下 superpower skills。它是社区里很有名的一套“全家桶”型技能集合里面包含了几十个细分技能覆盖代码分析、需求拆解、测试编写等常见任务。如果你刚入门、不知道从哪里开始安装 superpower 是一个不坏的选择——它更像一个学习样本你能看到好的 SKILL.md 是怎么组织步骤和输出格式的。但它也有明显的缺点数量太多会让模型在触发判断时产生干扰装完后你会发现有些场景下触发的不是你想用的那个子技能。我的建议是拿来拆解学习结构而不是一股脑全量使用。4.2 数学建模、数据竞赛场景的高分技能组合数学建模和竞赛类场景是另一个被热搜推起来的领域。这场景的核心痛点是AI 容易一本正经地胡说八道数据清洗不干净、模型对比没标准、论文格式不达标。skills 恰好能压制这些痛点。我参加过的比赛里比较好用的组合是这样一套技能名用途关键产出>