前几天有位读者在后台问我Claude Code 怎么手动安装 GitHub 上的 skills那一刻我突然意识到“skills” 已经从一个模糊的概念变成了 AI 编程圈里实实在在的基础设施。如果你这几个月也在刷各类 AI 编程工具的更新日志大概会频繁看到这个词——Claude Code 有 SkillsCodex 有 SkillsOpenCode 也在往这个方向靠。Skill 正在成为继提示词、MCP 之后又一个值得花时间研究的核心概念。这篇我打算把它彻底讲透Skills 到底是什么、去哪找、怎么装、怎么写、怎么清理。不管你是刚接触这些 AI 编程工具的新手还是已经在用技能包但总觉得不顺手的老玩家应该都能从中找到点有用的东西。我会按我自己实际折腾过的流程来写不整虚的。1. 先搞懂 Skills 是什么别把它和插件、MCP 混在一起1.1 从“提示词”到“可复用技能包”的变化过去我们想让 AI 按特定规范干活通常得复制一大段提示词你是资深前端请按照以下清单 review 代码……第一次好用换个项目就得再复制一遍换个人协作还得重新解释一遍。更麻烦的是提示词写多了以后全散落在聊天记录里根本没法维护。Skills 解决的就是这个“沉淀”问题。所谓 AI Skills本质上是一份“带结构的任务说明书 可选工具集”。它把“某类任务应该怎么干”固化成独立文件AI 在遇到相关任务时会根据文件名和描述去读取这份说明然后照着执行。它不再是你临时发给 AI 的一段话而是模型可以在工作过程中主动发现、主动加载的知识包。我经常打一个比方提示词就像冰箱上随手贴的便利贴skills 则是贴着标签的工具箱。便利贴看一次就没了工具箱是长期放在那里你一伸手就能拿到对应工具。1.2 一套 Skills 的目录结构长什么样不管哪种工具实现skills 的核心结构都大同小异。拿一个前端代码审查技能举例它的文件目录一般长这样frontend-review/ ├── SKILL.md ├── scripts/ │ └── check-a11y.py └── reference/ └── react-best-practices.md这里的SKILL.md是技能的唯一入口也是 AI 最先读取的文件。它通常由两部分组成文件头部的一段 YAML 元信息以及正文里的具体操作指令。元信息里的name和description是 AI 判断“什么时候该用这个技能”的关键直接决定了技能能不能被准确触发。scripts/目录放的是辅助执行脚本比如自动检查代码可访问性的脚本reference/则是参考资料AI 在执行任务时可以按需查阅不用把内容全部塞进主指令里。这个分层设计我觉得是 skills 最聪明的地方轻量入口加延后加载的细节既保证了触发效率又留足了执行深度。1.3 和插件、MCP、Agent 的边界到底在哪很多人刚接触 skills 时最容易问这不就是插件吗不是。传统 IDE 插件是重量级的存在有自己的 UI、配置项、生命周期适合做复杂的集成。MCP 则是给模型提供“调用外部工具”的能力相当于给 AI 装了一双能动手的手。Agent 是动态的流程控制者自己规划、自己调工具、自己验证结果。Skills 更像是静态的“说明书 工具包”。它不负责执行外部操作而是告诉 AI在这种场景下你应该按什么步骤、什么标准去完成工作。它们之间不是替代关系而是协作关系。一个 MCP server 给 AI 提供读写文件、查数据库的能力skills 负责告诉 AI 具体怎么用好这些能力。2. 装 Skills 的正确姿势以手动安装为主线2.1 先确认你的工具认哪个目录动手安装之前最重要的一件事是搞清楚你的工具从哪个目录读取 skills。不同工具约定不同盲目乱放只会让技能“隐身”。以 Claude Code 为例它同时支持项目级和用户级两个位置项目级放在当前代码库的.claude/skills/目录下用户级放在~/.claude/skills/目录下。Codex、OpenCode 这类工具也有类似机制通常也叫 skills 或类似的目录名具体路径以官方文档为准。我的建议是跟具体项目强相关的技能比如“这个仓库特有的代码规范检查”放项目级跨项目通用的技能比如“写提交信息”“做 code review”放用户级。这样既能跟着团队走也不会污染全局环境。2.2 Claude Code 手动装 GitHub 技能的完整流程总有人问我“手动装”到底怎么操作其实套路非常固定。假设我在 GitHub 上看到了一个不错的技能仓库想要里面某一个技能我会按这四步走。先克隆仓库然后只复制我需要的那个技能目录到 Claude Code 的 skills 目录git clone https://github.com/example/awesome-skills.git mkdir -p ~/.claude/skills cp -r awesome-skills/skills/frontend-review ~/.claude/skills/复制完以后别急着用先打开SKILL.md看一眼。重点检查三件事name是否简短明确、description是否写清楚了触发场景、正文里的步骤是否完整。很多仓库里的技能质量参差不齐有的描述写得跟没写一样这种装进去大概率也触发不了。确认没问题后重启一次会话或者用工具的重载命令让配置生效。然后在对话里直接抛一个小任务测试比如“帮我 review 一下 src/App.tsx”看 AI 是否主动读取了技能。如果它开始按技能里的清单逐条输出说明安装成功。如果毫无反应优先检查目录路径和 frontmatter 格式九成问题是这两处。2.3 Codex、OpenCode 这类工具怎么装这几类工具的技能机制还在快速演化版本不同、目录位置也可能不同。但万变不离其宗找到符合约定的 skills 目录把技能文件夹放进去然后让工具重新加载。以现在常见的方式为例有的工具会把技能目录放在~/.codex/skills/或者通过配置文件指定OpenCode 也有自己的配置目录。我个人的习惯是拿到一个新工具先在官方文档里搜 skills 或者 custom commands确认好路径再动手不要凭记忆拼命令。装完之后一定做一次实际触发测试因为“放对位置”和“能被正确识别”是两码事。3. 好用的 Skills 都在哪我的收藏渠道与筛选标准3.1 我常用的几个技能来源渠道GitHub 是目前最大的 skills 集散地直接用claude skills、superpower skills、awesome skills这些关键词去搜能翻出不少好东西。很多开发者把自己的技能包开源出来质量参差不齐但其中确实藏着一批设计得非常讲究的作品。技能索引站也是个好渠道。有些人把分散的技能整理成了带分类和说明的网页风格类似早期的 awesome-list逛起来比在 GitHub 里漫无目的地搜索高效得多。至于那些从热搜里冒出来的具体项目名比如 superpower skills、typesafe ai skills、cola skills、codex nature skills我的态度一直是不看星数看内容。下载之前先把 SKILL.md 打开读一遍比 star 数量可靠得多。3.2 怎么筛选一个技能值不值得装筛选技能我有一个简单的三步法。第一步看 description 能不能一句话讲清楚“什么场景、干什么活”。比如“当用户要求审查 React 组件时可触发输出含问题列表和修改建议”就是好描述“用于前端代码审查”这种就是模糊描述AI 很容易误判。第二步看 SKILL.md 正文是操作指南还是口号集。合格的技能应该包含清晰的执行步骤、约束条件和输出格式而不是通篇“请确保代码质量、请注重用户体验”这类正确的废话。第三步看有没有配套脚本和参考文档。一个带scripts/和reference/的技能通常说明作者动过真格真的在自己的项目里跑通过。只有孤零零一个 SKILL.md 的技能也不一定差但对格式和步骤的要求会更高。3.3 比赛向技能怎么选数学建模和华为杯的实战思路数学建模类场景是我最近看到讨论比较多的一块不少人在找能辅助比赛全流程的 skills。建模比赛的时间窗口很短通常需要快速完成数据探索、模型选择、结果可视化和论文写作。针对这类需求我不建议找一个“全能型技能”而是把流程拆开每段配一个专项技能。比如>--- name: frontend-review description: 当用户要求 review 前端代码、检查组件质量时使用适用于 React/TypeScript 项目。 --- # Frontend Review 目标输出可执行的前端改进建议不空谈。 执行步骤 1. 读取目标文件识别组件结构。 2. 检查 props 设计是否合理是否存在不必要的 re-render。 3. 检查 useState/useEffect 用法指出可能导致内存泄漏或无限循环的问题。 4. 检查样式方案是否一致。 输出格式 - 问题列表位置、严重程度、原因、修改建议。 - 最后列出“下一步改哪里”的优先级。把这段内容保存到.claude/skills/frontend-review/SKILL.md再测试一次你会发现 AI 的行为方式立刻变得不一样。它不再是自由发挥式地给建议而是照着你的步骤框架走输出结构也稳定了。写完这个基础版本之后你可以把更细致的规范放到reference/目录比如项目自己的代码规范文档让 AI 在需要时按需读取。这样做的好处是 SKILL.md 保持轻量和稳定不会因为规范文档变大而拖慢触发速度。4.2 设计原则一个技能只做一件事写 skills 最核心的原则是单一职责。你可以把它理解成写函数一个函数只做一件事参数清晰、返回值明确才好测试、好复用。技能也是这样把“前端代码审查”和“编写单元测试”塞进同一个技能结果往往是 AI 哪件事都做不彻底。我的写法套路是“目标-步骤-约束-输出格式”四段法。目标写清楚这个技能要达成什么效果步骤给出执行的主流程不要写得太琐碎给 AI 留一点根据实际情况调整的弹性约束写明白边界比如“不要修改文件只输出建议”“不要使用外部 API”输出格式则确保每次结果都长得差不多方便你对比和后续处理。4.3 写技能时我踩过的一堆坑第一个坑是把整个项目的文档复制进技能。有一阵我为了做代码审查把团队几十页的规范文档全塞进 reference结果会话上下文暴涨AI 反而抓不住重点。正确做法是在 SKILL.md 里只写“需要时读取 reference/team-rules.md”让 AI 按需加载。第二个坑是 description 写得太泛。我早期写过“帮助用户完成编程任务”这种废话式描述结果 AI 在遇到任何问题时都想触发它整个技能库乱成一锅粥。后来我强制自己用“当……时使用适用于……”的句式触发准确率立刻上来了。第三个坑是无视依赖。有些技能会调用脚本但脚本依赖的 Python 包没有写清楚换台机器后技能直接罢工。现在我的习惯是每个带脚本的技能都在 SKILL.md 里加一节“运行环境”把依赖和版本写明白宁可啰嗦不能缺。第四个坑是没有版本号。技能改过几轮之后自己都忘了当前文件是哪个版本回退都无从下手。加一个version字段成本几乎为零收益却很大。5. 不同场景下的高价值玩法前端、建模、AI 漫剧5.1 前端开发类的技能组合怎么搭前端是目前技能生态里最成熟的场景之一。常见的高质量技能包括组件评审、可访问性检查、CSS 规范审查、依赖安全分析等。以组件评审技能为例它可以内置一套“组件 quality checklist”从 props 设计、状态管理、副作用处理、性能隐患到无障碍属性逐项让 AI 检查并输出结构化报告。实际用下来最舒服的是“项目级技能”的玩法把团队自己的代码规范写进 reference技能作为固定入口。新同事加入项目时不用再口口相传规范AI 自己就能按团队标准执行review。这让代码审查从“看人经验”变成了“看技能质量”可复制性强了很多。5.2 数学建模的流水线技能怎么串建模比赛里的 AI 辅助核心价值不是帮你“想出模型”而是把实验过程中的重复劳动标准化。一次完整流程通常涉及数据清洗、特征工程、模型对比、可视化、论文撰写和 LaTeX 排版。我建议按这个链条去组 3 到 4 个技能不要让单个技能试图贯穿全程。具体来说eda技能负责读取数据、检查缺失值、生成描述性统计并输出一份“数据体检报告”model-benchmark技能负责准备多个候选模型、划分训练集与验证集、输出对比表格paper-writer技能根据实验结果按论文结构生成初稿latex-polisher技能统一排版。每个技能独立维护赛前一旦测通过比赛期间就非常稳。需要注意的是比赛中的创新点和模型选择是无法外包给 AI 的技能能帮你压缩的是“从数据到报告”的机械时间。赛前必须反复演练整套流水线提前把参考材料、脚本文档和环境依赖都准备好不要指望比赛时临时装技能还能好使。5.3 AI 漫剧与内容创作类技能的特点AI 漫剧是最近很热的内容创作方向技能在这里的形态和编程场景不太一样。这类技能更接近“工作流模板”核心要解决的是画风一致性、分镜可控性和批量产出效率的问题。常见的做法是把风格参考图描述、镜头语言规范、角色一致性检查步骤写进 SKILL.md同时在 reference 里放几组示例对话和分镜脚本。这类技能对格式的要求非常严格。生成一集漫剧如果每张图的 prompt 风格都漂移后期根本没法剪。技能里最好约定一个固定的 prompt 模板包含画风描述、角色特征、光影方向和镜头类型AI 每次生成都按模板填内容稳定性会好很多。另外内容创作一定要留意版权和平台规则生成涉及特定角色、特定风格的作品时该规避的必须提前规避。6. 技能库的管理与清理别让技能变成一坨垃圾6.1 什么时候该清理技能库很多人装技能像囤书看到 GitHub 上有点意思的仓库就拖进来结果技能库越来越臃肿。你可能会发现 AI 开始经常选错技能、响应变慢甚至输出质量明显变差。这不是幻觉技能文件太多确实会干扰模型的检索判断尤其是那些 description 写得不清不楚的技能会像噪音一样挤掉真正该触发的那一个。我的判断信号很直接一是同一类任务连续两三次没触发正确技能二是某次会话里 AI 同时加载了两个互相冲突的技能。出现这两种情况就该给技能库做一次体检和瘦身了。6.2 我自己的清理流程也是社区里常被提到的做法清理技能这件事社区里有不少方法论我自己的流程大致分五步。第一步先导出当前所有技能目录和描述列出清单第二步按“最近 30 天是否真正触发过”给每个技能排序没触发过的标记为候选删除第三步合并功能重复的技能留下设计最好的那个其余删掉第四步对暂时拿不准的技能先改名禁用观察一周再决定去留第五步清理完后给留下的技能补全 description、增加版本号保证下一个 30 天它们依然好用。这一步做完通常技能库体积能缩掉一半AI 的触发准确率会有肉眼可见的提升。技能不是越多越强精准才是目标。6.3 评估一个技能好坏的四维打分表如果看完以上内容你还不知道怎么挑那就直接拿下面这个四维表去套评估维度好技能的表现差技能的表现触发准确性description 明确写出场景和适用条件一次命中描述宽泛常被无关任务误触发步骤可执行性有清晰的步骤、边界和输出格式大段理论阐述缺少操作指引输出稳定性固定输出格式多次运行结果结构一致每次输出都长不一样难以复用维护活跃度近期有更新有 issue 反馈和修复长期没有维护依赖的脚本已经失效这套标准我用下来一直很顺手。看到新技能想装先花两分钟对着表打一遍分四分都过线的才值得占用目录空间。这比装完再后悔高效得多。我个人的习惯是装任何技能之前先读一遍 SKILL.md装完立刻执行一次用例跑通了才留下跑不通就直接删掉。现在每个技能都当代码库维护定期看触发情况写清楚版本。技能库保持精简AI 输出稳定比什么都重要。如果你刚开始折腾 skills不妨从一两个真正高频的场景入手比如前端代码审查或者建模论文写作先体会一下它到底能改变什么。