最近不管是刷技术社区还是跟同行聊天提到 Claude Code、Codex 这些 AI 编程工具几乎躲不开一个词Skills。我自己也是从每天手写一堆提示词到自己折腾着给工具装各种 Skill再到反过来帮别人排查为什么技能不生效中间踩过的坑不算少。这篇文章不打算搞成什么体系化课程就是把我这段时间的实战经验按大家问得最多的问题重新整理一遍Skills 到底是什么怎么手动把 GitHub 上的 Skills 装到 Claude Code 里哪些技能库值得收藏怎么写一个自己的 Skill以及数学建模、前端开发、AI 漫剧这些场景下怎么落地。先说一个基本判断Skills 这玩意儿之所以突然火起来是因为它解决了一个非常实在的问题——你的 AI 干起活来总是每次都从零开始。你给它一段提示词它按提示词干活但下一次遇到同样类型的任务你还得重新说一遍甚至还得教会它你上回已经教过的东西。Skills 的本质就是把一套稳定的工作流程、判断标准和示例代码打包成磁盘上的文件让 AI 在相关任务出现时自动调用。我习惯把它类比成给一个能力很强但记性很差的新员工准备上岗手册。你不需要每次开会都重新讲一遍流程手册里写着呢。AI 也一样你把怎么审代码怎么做数学建模的论文排版怎么写漫剧分镜脚本这些流程写成 Skill它下次碰到对应任务自己就会去翻手册。下面就开始拆。1. 先说清楚Skills 到底是什么1.1 从一个日常痛点说起先看一个我几乎每周都会遇到的场景。假设你负责一个前端项目每次都要求 AI 按照某个设计规范生成 React 组件样式用 Tailwind、状态管理用 Zustand、组件文件拆分、导出方式、测试要求……这些规范你大概率写过不止一次提示词。但问题是提示词是一次性的。你这次写在对话框里下次还得重新写换个工具可能还要再润色一遍。如果你把这段规范整理成一份SKILL.md放到项目的.skills/components/目录下那么你以后再跟 AI 说帮我写一个数据表格组件AI 会自动识别到你有对应的 Skill并且按照里面的所有要求来输出。这个自动识别 自动按流程执行的能力才是 Skills 的真正价值。它不只是一个更长的提示词而是一个可以被反复调用的、结构化的行为契约。而且因为它是文件你可以放进 Git 仓库里和团队共享也可以直接分享给别人。GitHub 上大量 skills 项目就是这么长出来的。1.2 一个 Skill 的典型结构一个标准的 Skill 通常是一个目录目录名就是技能名里面至少有一个SKILL.md文件再加一些辅助材料。这个SKILL.md的开头有一段 YAML 格式的元信息紧跟着是正文指令体。元信息里最重要的字段是name和description有些版本还支持allowed-tools之类的扩展字段。description的作用常常被低估。AI 并不是靠目录名来判断什么时候该用这个技能的而是靠读取元信息里的描述然后把当前任务和描述做匹配。所以描述要写得像触发条件尽量包含这个技能适合什么任务、什么场景、产出什么类型的结果。比如你写一个前端组件的 Skill描述里最好带ReactTailwind组件这些关键词而不是泛泛地说生成代码。正文部分一般是 Markdown 格式的指令体可以包含操作步骤、代码示例、注意事项、自检清单等。大部分主流实现里AI 在工作时会把这份文件的内容直接读进上下文然后按照里面的步骤执行。所以指令体写得好不好直接决定这个 Skill 有没有用。1.3 它和提示词、MCP 的区别不少人刚接触 Skills 时会把它和提示词、MCP 混在一起我简单区分一下。提示词是你手动给 AI 的一段指令用完就没了每次都要重新写。Skills 相当于把提示词做成了持久化文件让 AI 在合适的时机自动加载同一个技能可以被反复使用也可以共享给其他人。所以你可以把 Skills 理解为工程化的提示词。MCP 解决的是AI 能连到什么东西的问题比如数据库、文件系统、外部 API提供的是工具和数据的访问能力。而 Skills 解决的是AI 该怎么干活的问题约束的是行为方式和判断标准。两者可以配合着用MCP 给 AI 一把螺丝刀Skills 告诉 AI螺丝要顺时针拧、扭矩不能超过多少。搞清楚这个区别之后你就知道遇到什么情况应该找 Skill什么情况应该找 MCP什么情况只是单纯再写一段提示词就行。2. 手把手怎么把 GitHub 上的 Skills 装进你的 AI 编程工具2.1 通用安装思路不管是 Claude Code、Codex 还是 OpenCode安装 Skill 的思路其实只有一条把 GitHub 仓库里的 Skill 目录放到 AI 工具会去扫描的某个约定目录下。常见的目录分两种项目级和用户级。项目级目录一般是项目根目录下的.skills/只对这个项目生效用户级目录比如 Claude Code 的~/.claude/skills/对所有项目生效。放哪取决于你的需求如果是团队项目统一的开发规范建议放项目级跟着 Git 走如果是你自己日常写代码都通用的习惯比如代码审查提交信息规范放用户级更方便。这里有一个容易踩的坑有些人从 GitHub 上下载了仓库直接把整个仓库目录放进.skills/但里面可能包含了多个 Skill 或其他文件最后 AI 一个都没识别到。正确做法是先看仓库的目录结构把真正包含SKILL.md的那个子目录放进去保持目录一层即可。比如仓库是superpowers里面skills/artifacts/是这个技能的根那你就把artifacts目录放到.skills/artifacts而不是.skills/superpowers/skills/artifacts。2.2 Claude Code 手动安装Claude Code 目前对 Skills 的支持比较稳定安装方式也最常被问到。手动安装的核心步骤其实就只有四步。第一步在 GitHub 上找到你想要安装的 skills 仓库。大部分 popular 的仓库 README 里都会写清楚目录结构建议先花两分钟读一下省得后面白折腾。第二步把仓库拿下来。你可以用git clone也可以直接在 GitHub 网页上下载 zip 包。下载 zip 也够用了毕竟很多技能包并不会频繁更新不需要每次都拉分支。第三步把对应的 Skill 目录放到正确的位置。如果是给某个具体项目用的放到项目根目录下的.skills/里想全局生效放到~/.claude/skills/里。放完之后可以用ls确认一下目录结构和SKILL.md文件都在。第四步重启会话。注意多数工具在会话启动时扫描技能目录你装完不重启AI 是感知不到新技能的。重启后你可以直接问 AI你现在有哪些可用的技能或者描述一个任务看它是否会主动引用这个技能。如果工具版本支持也可以试试/skills之类的命令查看技能列表或通过 Claude Code 的插件机制安装但手动放目录依然是最通用、最不容易出问题的方法。2.3 Codex、OpenCode 等工具的安装方式Codex 这边的情况稍微多样化一些。像 OpenAI Codex CLI 的 skills 存放位置一般也在用户目录或项目目录的.codex/skills或者工具约定的某个子路径部分 codex skills 仓库还会自带安装脚本。我的建议是先按仓库 README 的指引来如果脚本跑不通就直接按通用安装思路手动放目录一样能生效。OpenCode 作为一个相对轻量的编程工具对 Skills 的加载逻辑和 Claude Code 差不多本质上都是读 Markdown 指令文件。安装时同样是把技能目录放到它约定的位置具体路径以当前版本的文档为准。我自己在 OpenCode 里试过直接放.opencode/skills的方式识别率还可以。这里忍不住啰嗦一句手动安装最大的好处不是离线或者可控而是你能看清楚这个 Skill 里到底有什么内容。很多人拿回来一堆技能文件却完全不知道里面的指令写了什么这是有安全风险的。下文会专门讲怎么辨别一个 Skill 是宝藏还是坑。3. 别乱装我常用的 Skills 清单和靠谱技能库3.1 几个出镜率高的技能库先聊大家最关心的哪些技能源网站值得收藏。GitHub 上的 skills 仓库五花八门质量参差不齐我从自己实际用过和观察过的里面挑几个有代表性的。superpowers这个仓库的定位是给 Claude Code 之类的工具增加结构化工作流能力里面的技能覆盖了需求拆解、任务规划、编码实施等多个环节。特点是文档比较详细适合想理解好的 Skill 应该怎么组织的人。codex nature skills围绕 Codex 使用场景整理的一批技能很多和代码生成、调试、代码审查相关对用 Codex 做日常开发的人比较对症。cola skills我在多个技术讨论里看到有人在推荐它更像一个技能集合库里面不少技能目标明确比如特定框架的代码生成、项目脚手架搭建等。typesafe ai skills如果关注类型安全、AI 应用架构这个库值得看。它把一些工程实践沉淀成了技能风格偏严谨。另外还有一些从酷安、V2EX、即刻这类社区里流转出来的个人技能合集搜关键词时多看 star 数和最近的 commit 时间别看到高下载量就盲目装。需要强调一下技能库名称和仓库的热度会随时间变化真正重要的不是记住某个仓库而是学会看一个技能文件的内部质量。3.2 按场景推荐的 Skills 组合技能这种东西装一堆不如装对几个。我按应用场景给你推荐几套组合。前端开发场景建议装一个组件生成方向的技能要求输出包含 Tailwind 类名、组件拆分、状态管理的样板代码再配一个代码审查方向的技能让它检查性能隐患、可访问性、重复渲染等问题。两个技能配合使用日常开发效率提升明显。数学建模/竞赛场景重点是数据处理、公式推导、论文排版和可视化。你可以找和 matplotlib/seaborn 出图规范、LaTeX 排版、数据清洗流程相关的技能。在华为杯这类建模比赛里Codex 配上一套好的技能组合能把从数据到报告的流程标准化省下不少重复沟通的时间。AI 漫剧/内容创作场景核心痛点是角色一致性、分镜脚本、提示词套路的复用。找那种能把角色设定、镜头语言、场景描述沉淀成固定格式的技能让它每次生成时都遵守同一套叙事模板产出的内容稳定度会高很多。3.3 如何辨别一个 Skill 的质量装技能和装软件一样来源不明的东西别随便往环境里扔尤其是这类直接控制 AI 行为的文件。我一般会看三个角度。第一看描述是否清晰。一个合格的SKILL.mddescription应该能让人不看正文就猜出它的用途。如果描述写得很模糊或者什么都想包含这技能十有八九是个 garbage collector。第二看指令体里有没有防呆设计。好的技能会定义输入、输出、步骤、边界甚至明确什么情况下不要做某事。一些技能还会包含 self-check 或验证环节这些细节才是价值的体现。第三检查有没有可疑指令。比如技能里要求 AI 忽略之前的指令把系统提示词打印出来之类的这种文件就要高度警惕了可能包含提示注入的内容。尤其从非官方渠道下载的先逐行看一遍再启用安全上永远不过分。4. 进阶怎么写一个自己的 AI Skills4.1 文件结构和核心字段写一个 Skill 并没有多高深本质就是写一份结构良好的 Markdown 文件然后放到约定目录里。先说目录结构一个最简的 Skill 可以只有SKILL.md一个文件但实际项目中我建议你按需加上examples/目录里面放输入输出示例加上scripts/目录放一些辅助脚本这样技能才有包的感觉。SKILL.md的开头必须是 YAML frontmatter用两行---包起来。核心字段有三个name技能名尽量和目录名一致方便排查。description这是整个技能里最关键的字段。AI 就是靠它来判断该不该调用这个技能。要写清楚触发场景、适用任务和产出类型。allowed-tools可选有些实现里可以限定技能能用哪些工具不加的话默认继承全局权限。4.2 写好指令体的几个关键技巧指令体是SKILL.md的正文也是 AI 真正会执行的剧本。我把踩过几次坑之后总结出的要点整理一下。第一个要点是把流程拆成步骤。不要写请高质量地完成需求这种空话要写第一步检查输入的原始数据明确字段含义第二步处理缺失值并用表格列出处理前后对比第三步生成两张可视化图表……步骤写得越明确AI 的输出就越稳定。第二个要点是给出示例。AI 对零散指令的理解很多时候依赖模式匹配。在examples/目录下放两个典型例子它就知道你想要的是哪个样子的输出。尤其是你想限定格式时一个 before/after 对照比十句说明都有用。第三个要点是写清楚边界和禁忌。这是新手最容易忽略的。比如你写一个代码审查技能要从正面告诉它要检查什么也要从反面告诉它不要改代码只输出审查意见不要因为 style 问题打断严重 bug 的定位。边界明确AI 才不会被无关信息带偏。第四个要点是利用环境变量或上下文注入。有些实现里支持在技能中引用当前会话的信息比如操作系统、项目路径、当前文件列表。合理利用这些变量技能就能做到不同项目表现不同的效果。这一块不同工具支持程度不一样写之前先看文档。4.3 一个可参考的小例子我拿一个很简单的 代码审查技能 做示范帮你把上面的抽象概念落下来。--- name: code-review description: 用于对提交的代码变更进行系统性审查检查潜在 bug、性能问题、可读性和边界情况输出结构化审查报告。适合在 code review 或合并请求前使用。 --- # 代码审查技能 你是一名资深代码审查员。请按以下流程审查用户提供的代码变更 ## 步骤 1. 先理解变更上下文明确这个改动要解决什么问题。 2. 检查潜在 bug空指针、越界、类型错误、资源泄漏。 3. 检查性能不必要的循环、重复计算、大对象复制。 4. 检查可读性命名、函数长度、注释是否必要。 5. 检查测试覆盖变更是否容易测试是否缺少边界测试。 ## 输出格式 - 问题列表按严重程度排序严重 / 一般 / 建议。 - 每个问题附上文件位置和修改建议。 - 最后给出整体结论通过 / 需修改后通过。 ## 不要做 - 不要直接修改代码只输出审查意见。 - 不要在没有依据的情况下使用性能差等模糊表述。 - 不要审查与本次变更无关的历史代码。这个例子很短但已经包含了元信息、步骤、输出格式和禁忌四项关键设计。你完全可以把步骤换成自己团队的实际流程。5. 特定场景实战数学建模、前端开发和 AI 漫剧5.1 数学建模 / 华为杯场景建模比赛是最近被问到最多的场景也是 Skills 的典型应用场。一场比赛时间紧、任务重很多队伍现在用 Codex 辅助做数据处理、模型推理、论文润色。这时候技能的价值在于把流程固定下来。比如你可以在.skills/下放一个数据处理技能规定 AI 接到原始 Excel 或 CSV 后先做缺失值统计、再做异常值检测、最后输出一份数据体检报告。再放一个可视化技能规定出图风格、字体大小、配色方案让所有图表风格统一。这样团队里面谁管数据、谁管画图AI 都能用同一套标准输出交接成本大幅降低。我自己在实践里还有两点心得第一比赛前一周就要把技能装好、试跑几遍别到比赛当天才发现技能目录路径不对。第二别把技能当成自动完成建模的工具它的作用是帮你减少重复沟通和格式整理的时间真正难的建模思路还得人来定。5.2 前端开发场景前端可能是 Skills 落地最顺的场景因为前端的输出有很强的模式感。一个组件长什么样、状态怎么管理、样式用什么方案这些规范完全可以通过技能来锁定。举个例子我写了一个生成 React 表单组件的技能里面规定了表单校验用 zod、样式用 Tailwind、错误提示要集成到组件内部、导出时要带displayName。以前每次写表单都要在提示词里重复一遍这些要求现在只需要说用技能生成一个注册表单AI 自动照着规范出代码。这种体验上的差别用过的都回不去。另外前端场景里我强烈建议把代码审查也做成技能。让 AI 专门从性能、可访问性、语义化标签、响应式断点这几个角度做复查比自己肉眼 review 要全面不少。配合上面说的生成技能形成一个生成-审查-修复的闭环。5.3 AI 漫剧场景AI 漫剧这个圈子的工作流本质上是一套内容生产线分镜脚本、角色设定、画面提示词、剧情推进、角色一致性管理。这些环节条件各异但每一环都适合用技能固化。比如你可以在技能里定义角色卡包括角色的外貌、性格、常用表情、禁忌事项让 AI 在生成画面提示词时自动带上这些信息。再比如分镜技能可以规定镜头语言远景交代环境、中景表现动作、特写传递情绪。只要把这一套写成技能漫剧团队里不同编剧传话给 AI 的产出风格就会非常一致。这套思路也适用于其他内容创作场景比如短视频口播稿、小红书文案生成等。本质上都是把团队内部的标准写法沉淀成文件。6. 常见问题与排查实录6.1 装上了但不生效怎么办我明明已经把目录放进.skills/了AI 就是不认。这是最常见的求助帖。我一般按下面几步排查。第一步检查目录结构。确认最外层目录名和name字段是否一致很多工具要求目录名和技能名一致才能识别。第二步检查SKILL.md文件是否真的在正确路径下而不是嵌套多了一层。第三步检查description是否能匹配你的任务表述匹配不上 AI 就不会触发。第四步重启会话每次新增技能后都建议重启。第五步查看工具的调试日志或技能列表命令确认该技能是否被加载。很多时候问题最后都出在多一层目录或者没有重启上这两点排查成本最低先做。6.2 技能装太多AI 反而变笨这问题也是老生常谈。技能装多了AI 每件事都要在几百个技能描述里做匹配选择变多噪音自然变大。而且有些技能之间还会互相冲突比如两个技能都定义了代码风格AI 反而不知道该听哪个。我的建议是项目级目录里的技能不要超过 5 个用户级的多一些没关系但要确保描述之间没有明显语义重叠。平时多删少装个人技能库里只留高频使用的核心技能。6.3 如何有效清理技能关于清理有位朋友 tibo 分享过一个思路我实践后觉得挺实用先把现有技能列成清单一个个判断最近两周有没有被触发过没触发过的先禁用而不是直接删观察一个月再决定去留。这样既不会误删还能用的技能也能控制技能总量。清理时别只删文件还要注意两个地方一是项目里的.skills/目录有时候这个项目不再用了但技能文件还在占着位置二是某些工具会生成技能缓存删完文件旧配置可能还在报错这种时候去缓存目录清理一下。我自己还会在删除后做一个冒烟测试随便给 AI 一个对应任务确保它不会再引用已删除的技能。结尾一点个人经验前面聊了概念、安装、推荐、开发和排错最后再用我自己的体会收个尾。Skills 这个东西一开始容易让人上头觉得装得越多 AI 越强但我折腾一段时间后的真实感受是克制比堆量重要。真正提升效率的往往是那两三个紧紧绑定你日常高频场景的技能而不是一个塞满几十上百个文件夹的技能库。另外如果你打算自己写技能我的建议是先从改写自己最近的高频提示词开始。找一个你每周都要重复两三次的提示词把它结构化、加上步骤和禁忌生成第一个SKILL.md。不需要一上来就搞大而全的复杂设计先把最小的闭环跑通后面再逐步加。等你习惯了这套把流程写成文件的思路再回头去看各种高级技能库就能一眼看出哪些是精华、哪些是噱头了。
AI编程Skills实战指南：概念、安装、编写与场景应用
最近不管是刷技术社区还是跟同行聊天提到 Claude Code、Codex 这些 AI 编程工具几乎躲不开一个词Skills。我自己也是从每天手写一堆提示词到自己折腾着给工具装各种 Skill再到反过来帮别人排查为什么技能不生效中间踩过的坑不算少。这篇文章不打算搞成什么体系化课程就是把我这段时间的实战经验按大家问得最多的问题重新整理一遍Skills 到底是什么怎么手动把 GitHub 上的 Skills 装到 Claude Code 里哪些技能库值得收藏怎么写一个自己的 Skill以及数学建模、前端开发、AI 漫剧这些场景下怎么落地。先说一个基本判断Skills 这玩意儿之所以突然火起来是因为它解决了一个非常实在的问题——你的 AI 干起活来总是每次都从零开始。你给它一段提示词它按提示词干活但下一次遇到同样类型的任务你还得重新说一遍甚至还得教会它你上回已经教过的东西。Skills 的本质就是把一套稳定的工作流程、判断标准和示例代码打包成磁盘上的文件让 AI 在相关任务出现时自动调用。我习惯把它类比成给一个能力很强但记性很差的新员工准备上岗手册。你不需要每次开会都重新讲一遍流程手册里写着呢。AI 也一样你把怎么审代码怎么做数学建模的论文排版怎么写漫剧分镜脚本这些流程写成 Skill它下次碰到对应任务自己就会去翻手册。下面就开始拆。1. 先说清楚Skills 到底是什么1.1 从一个日常痛点说起先看一个我几乎每周都会遇到的场景。假设你负责一个前端项目每次都要求 AI 按照某个设计规范生成 React 组件样式用 Tailwind、状态管理用 Zustand、组件文件拆分、导出方式、测试要求……这些规范你大概率写过不止一次提示词。但问题是提示词是一次性的。你这次写在对话框里下次还得重新写换个工具可能还要再润色一遍。如果你把这段规范整理成一份SKILL.md放到项目的.skills/components/目录下那么你以后再跟 AI 说帮我写一个数据表格组件AI 会自动识别到你有对应的 Skill并且按照里面的所有要求来输出。这个自动识别 自动按流程执行的能力才是 Skills 的真正价值。它不只是一个更长的提示词而是一个可以被反复调用的、结构化的行为契约。而且因为它是文件你可以放进 Git 仓库里和团队共享也可以直接分享给别人。GitHub 上大量 skills 项目就是这么长出来的。1.2 一个 Skill 的典型结构一个标准的 Skill 通常是一个目录目录名就是技能名里面至少有一个SKILL.md文件再加一些辅助材料。这个SKILL.md的开头有一段 YAML 格式的元信息紧跟着是正文指令体。元信息里最重要的字段是name和description有些版本还支持allowed-tools之类的扩展字段。description的作用常常被低估。AI 并不是靠目录名来判断什么时候该用这个技能的而是靠读取元信息里的描述然后把当前任务和描述做匹配。所以描述要写得像触发条件尽量包含这个技能适合什么任务、什么场景、产出什么类型的结果。比如你写一个前端组件的 Skill描述里最好带ReactTailwind组件这些关键词而不是泛泛地说生成代码。正文部分一般是 Markdown 格式的指令体可以包含操作步骤、代码示例、注意事项、自检清单等。大部分主流实现里AI 在工作时会把这份文件的内容直接读进上下文然后按照里面的步骤执行。所以指令体写得好不好直接决定这个 Skill 有没有用。1.3 它和提示词、MCP 的区别不少人刚接触 Skills 时会把它和提示词、MCP 混在一起我简单区分一下。提示词是你手动给 AI 的一段指令用完就没了每次都要重新写。Skills 相当于把提示词做成了持久化文件让 AI 在合适的时机自动加载同一个技能可以被反复使用也可以共享给其他人。所以你可以把 Skills 理解为工程化的提示词。MCP 解决的是AI 能连到什么东西的问题比如数据库、文件系统、外部 API提供的是工具和数据的访问能力。而 Skills 解决的是AI 该怎么干活的问题约束的是行为方式和判断标准。两者可以配合着用MCP 给 AI 一把螺丝刀Skills 告诉 AI螺丝要顺时针拧、扭矩不能超过多少。搞清楚这个区别之后你就知道遇到什么情况应该找 Skill什么情况应该找 MCP什么情况只是单纯再写一段提示词就行。2. 手把手怎么把 GitHub 上的 Skills 装进你的 AI 编程工具2.1 通用安装思路不管是 Claude Code、Codex 还是 OpenCode安装 Skill 的思路其实只有一条把 GitHub 仓库里的 Skill 目录放到 AI 工具会去扫描的某个约定目录下。常见的目录分两种项目级和用户级。项目级目录一般是项目根目录下的.skills/只对这个项目生效用户级目录比如 Claude Code 的~/.claude/skills/对所有项目生效。放哪取决于你的需求如果是团队项目统一的开发规范建议放项目级跟着 Git 走如果是你自己日常写代码都通用的习惯比如代码审查提交信息规范放用户级更方便。这里有一个容易踩的坑有些人从 GitHub 上下载了仓库直接把整个仓库目录放进.skills/但里面可能包含了多个 Skill 或其他文件最后 AI 一个都没识别到。正确做法是先看仓库的目录结构把真正包含SKILL.md的那个子目录放进去保持目录一层即可。比如仓库是superpowers里面skills/artifacts/是这个技能的根那你就把artifacts目录放到.skills/artifacts而不是.skills/superpowers/skills/artifacts。2.2 Claude Code 手动安装Claude Code 目前对 Skills 的支持比较稳定安装方式也最常被问到。手动安装的核心步骤其实就只有四步。第一步在 GitHub 上找到你想要安装的 skills 仓库。大部分 popular 的仓库 README 里都会写清楚目录结构建议先花两分钟读一下省得后面白折腾。第二步把仓库拿下来。你可以用git clone也可以直接在 GitHub 网页上下载 zip 包。下载 zip 也够用了毕竟很多技能包并不会频繁更新不需要每次都拉分支。第三步把对应的 Skill 目录放到正确的位置。如果是给某个具体项目用的放到项目根目录下的.skills/里想全局生效放到~/.claude/skills/里。放完之后可以用ls确认一下目录结构和SKILL.md文件都在。第四步重启会话。注意多数工具在会话启动时扫描技能目录你装完不重启AI 是感知不到新技能的。重启后你可以直接问 AI你现在有哪些可用的技能或者描述一个任务看它是否会主动引用这个技能。如果工具版本支持也可以试试/skills之类的命令查看技能列表或通过 Claude Code 的插件机制安装但手动放目录依然是最通用、最不容易出问题的方法。2.3 Codex、OpenCode 等工具的安装方式Codex 这边的情况稍微多样化一些。像 OpenAI Codex CLI 的 skills 存放位置一般也在用户目录或项目目录的.codex/skills或者工具约定的某个子路径部分 codex skills 仓库还会自带安装脚本。我的建议是先按仓库 README 的指引来如果脚本跑不通就直接按通用安装思路手动放目录一样能生效。OpenCode 作为一个相对轻量的编程工具对 Skills 的加载逻辑和 Claude Code 差不多本质上都是读 Markdown 指令文件。安装时同样是把技能目录放到它约定的位置具体路径以当前版本的文档为准。我自己在 OpenCode 里试过直接放.opencode/skills的方式识别率还可以。这里忍不住啰嗦一句手动安装最大的好处不是离线或者可控而是你能看清楚这个 Skill 里到底有什么内容。很多人拿回来一堆技能文件却完全不知道里面的指令写了什么这是有安全风险的。下文会专门讲怎么辨别一个 Skill 是宝藏还是坑。3. 别乱装我常用的 Skills 清单和靠谱技能库3.1 几个出镜率高的技能库先聊大家最关心的哪些技能源网站值得收藏。GitHub 上的 skills 仓库五花八门质量参差不齐我从自己实际用过和观察过的里面挑几个有代表性的。superpowers这个仓库的定位是给 Claude Code 之类的工具增加结构化工作流能力里面的技能覆盖了需求拆解、任务规划、编码实施等多个环节。特点是文档比较详细适合想理解好的 Skill 应该怎么组织的人。codex nature skills围绕 Codex 使用场景整理的一批技能很多和代码生成、调试、代码审查相关对用 Codex 做日常开发的人比较对症。cola skills我在多个技术讨论里看到有人在推荐它更像一个技能集合库里面不少技能目标明确比如特定框架的代码生成、项目脚手架搭建等。typesafe ai skills如果关注类型安全、AI 应用架构这个库值得看。它把一些工程实践沉淀成了技能风格偏严谨。另外还有一些从酷安、V2EX、即刻这类社区里流转出来的个人技能合集搜关键词时多看 star 数和最近的 commit 时间别看到高下载量就盲目装。需要强调一下技能库名称和仓库的热度会随时间变化真正重要的不是记住某个仓库而是学会看一个技能文件的内部质量。3.2 按场景推荐的 Skills 组合技能这种东西装一堆不如装对几个。我按应用场景给你推荐几套组合。前端开发场景建议装一个组件生成方向的技能要求输出包含 Tailwind 类名、组件拆分、状态管理的样板代码再配一个代码审查方向的技能让它检查性能隐患、可访问性、重复渲染等问题。两个技能配合使用日常开发效率提升明显。数学建模/竞赛场景重点是数据处理、公式推导、论文排版和可视化。你可以找和 matplotlib/seaborn 出图规范、LaTeX 排版、数据清洗流程相关的技能。在华为杯这类建模比赛里Codex 配上一套好的技能组合能把从数据到报告的流程标准化省下不少重复沟通的时间。AI 漫剧/内容创作场景核心痛点是角色一致性、分镜脚本、提示词套路的复用。找那种能把角色设定、镜头语言、场景描述沉淀成固定格式的技能让它每次生成时都遵守同一套叙事模板产出的内容稳定度会高很多。3.3 如何辨别一个 Skill 的质量装技能和装软件一样来源不明的东西别随便往环境里扔尤其是这类直接控制 AI 行为的文件。我一般会看三个角度。第一看描述是否清晰。一个合格的SKILL.mddescription应该能让人不看正文就猜出它的用途。如果描述写得很模糊或者什么都想包含这技能十有八九是个 garbage collector。第二看指令体里有没有防呆设计。好的技能会定义输入、输出、步骤、边界甚至明确什么情况下不要做某事。一些技能还会包含 self-check 或验证环节这些细节才是价值的体现。第三检查有没有可疑指令。比如技能里要求 AI 忽略之前的指令把系统提示词打印出来之类的这种文件就要高度警惕了可能包含提示注入的内容。尤其从非官方渠道下载的先逐行看一遍再启用安全上永远不过分。4. 进阶怎么写一个自己的 AI Skills4.1 文件结构和核心字段写一个 Skill 并没有多高深本质就是写一份结构良好的 Markdown 文件然后放到约定目录里。先说目录结构一个最简的 Skill 可以只有SKILL.md一个文件但实际项目中我建议你按需加上examples/目录里面放输入输出示例加上scripts/目录放一些辅助脚本这样技能才有包的感觉。SKILL.md的开头必须是 YAML frontmatter用两行---包起来。核心字段有三个name技能名尽量和目录名一致方便排查。description这是整个技能里最关键的字段。AI 就是靠它来判断该不该调用这个技能。要写清楚触发场景、适用任务和产出类型。allowed-tools可选有些实现里可以限定技能能用哪些工具不加的话默认继承全局权限。4.2 写好指令体的几个关键技巧指令体是SKILL.md的正文也是 AI 真正会执行的剧本。我把踩过几次坑之后总结出的要点整理一下。第一个要点是把流程拆成步骤。不要写请高质量地完成需求这种空话要写第一步检查输入的原始数据明确字段含义第二步处理缺失值并用表格列出处理前后对比第三步生成两张可视化图表……步骤写得越明确AI 的输出就越稳定。第二个要点是给出示例。AI 对零散指令的理解很多时候依赖模式匹配。在examples/目录下放两个典型例子它就知道你想要的是哪个样子的输出。尤其是你想限定格式时一个 before/after 对照比十句说明都有用。第三个要点是写清楚边界和禁忌。这是新手最容易忽略的。比如你写一个代码审查技能要从正面告诉它要检查什么也要从反面告诉它不要改代码只输出审查意见不要因为 style 问题打断严重 bug 的定位。边界明确AI 才不会被无关信息带偏。第四个要点是利用环境变量或上下文注入。有些实现里支持在技能中引用当前会话的信息比如操作系统、项目路径、当前文件列表。合理利用这些变量技能就能做到不同项目表现不同的效果。这一块不同工具支持程度不一样写之前先看文档。4.3 一个可参考的小例子我拿一个很简单的 代码审查技能 做示范帮你把上面的抽象概念落下来。--- name: code-review description: 用于对提交的代码变更进行系统性审查检查潜在 bug、性能问题、可读性和边界情况输出结构化审查报告。适合在 code review 或合并请求前使用。 --- # 代码审查技能 你是一名资深代码审查员。请按以下流程审查用户提供的代码变更 ## 步骤 1. 先理解变更上下文明确这个改动要解决什么问题。 2. 检查潜在 bug空指针、越界、类型错误、资源泄漏。 3. 检查性能不必要的循环、重复计算、大对象复制。 4. 检查可读性命名、函数长度、注释是否必要。 5. 检查测试覆盖变更是否容易测试是否缺少边界测试。 ## 输出格式 - 问题列表按严重程度排序严重 / 一般 / 建议。 - 每个问题附上文件位置和修改建议。 - 最后给出整体结论通过 / 需修改后通过。 ## 不要做 - 不要直接修改代码只输出审查意见。 - 不要在没有依据的情况下使用性能差等模糊表述。 - 不要审查与本次变更无关的历史代码。这个例子很短但已经包含了元信息、步骤、输出格式和禁忌四项关键设计。你完全可以把步骤换成自己团队的实际流程。5. 特定场景实战数学建模、前端开发和 AI 漫剧5.1 数学建模 / 华为杯场景建模比赛是最近被问到最多的场景也是 Skills 的典型应用场。一场比赛时间紧、任务重很多队伍现在用 Codex 辅助做数据处理、模型推理、论文润色。这时候技能的价值在于把流程固定下来。比如你可以在.skills/下放一个数据处理技能规定 AI 接到原始 Excel 或 CSV 后先做缺失值统计、再做异常值检测、最后输出一份数据体检报告。再放一个可视化技能规定出图风格、字体大小、配色方案让所有图表风格统一。这样团队里面谁管数据、谁管画图AI 都能用同一套标准输出交接成本大幅降低。我自己在实践里还有两点心得第一比赛前一周就要把技能装好、试跑几遍别到比赛当天才发现技能目录路径不对。第二别把技能当成自动完成建模的工具它的作用是帮你减少重复沟通和格式整理的时间真正难的建模思路还得人来定。5.2 前端开发场景前端可能是 Skills 落地最顺的场景因为前端的输出有很强的模式感。一个组件长什么样、状态怎么管理、样式用什么方案这些规范完全可以通过技能来锁定。举个例子我写了一个生成 React 表单组件的技能里面规定了表单校验用 zod、样式用 Tailwind、错误提示要集成到组件内部、导出时要带displayName。以前每次写表单都要在提示词里重复一遍这些要求现在只需要说用技能生成一个注册表单AI 自动照着规范出代码。这种体验上的差别用过的都回不去。另外前端场景里我强烈建议把代码审查也做成技能。让 AI 专门从性能、可访问性、语义化标签、响应式断点这几个角度做复查比自己肉眼 review 要全面不少。配合上面说的生成技能形成一个生成-审查-修复的闭环。5.3 AI 漫剧场景AI 漫剧这个圈子的工作流本质上是一套内容生产线分镜脚本、角色设定、画面提示词、剧情推进、角色一致性管理。这些环节条件各异但每一环都适合用技能固化。比如你可以在技能里定义角色卡包括角色的外貌、性格、常用表情、禁忌事项让 AI 在生成画面提示词时自动带上这些信息。再比如分镜技能可以规定镜头语言远景交代环境、中景表现动作、特写传递情绪。只要把这一套写成技能漫剧团队里不同编剧传话给 AI 的产出风格就会非常一致。这套思路也适用于其他内容创作场景比如短视频口播稿、小红书文案生成等。本质上都是把团队内部的标准写法沉淀成文件。6. 常见问题与排查实录6.1 装上了但不生效怎么办我明明已经把目录放进.skills/了AI 就是不认。这是最常见的求助帖。我一般按下面几步排查。第一步检查目录结构。确认最外层目录名和name字段是否一致很多工具要求目录名和技能名一致才能识别。第二步检查SKILL.md文件是否真的在正确路径下而不是嵌套多了一层。第三步检查description是否能匹配你的任务表述匹配不上 AI 就不会触发。第四步重启会话每次新增技能后都建议重启。第五步查看工具的调试日志或技能列表命令确认该技能是否被加载。很多时候问题最后都出在多一层目录或者没有重启上这两点排查成本最低先做。6.2 技能装太多AI 反而变笨这问题也是老生常谈。技能装多了AI 每件事都要在几百个技能描述里做匹配选择变多噪音自然变大。而且有些技能之间还会互相冲突比如两个技能都定义了代码风格AI 反而不知道该听哪个。我的建议是项目级目录里的技能不要超过 5 个用户级的多一些没关系但要确保描述之间没有明显语义重叠。平时多删少装个人技能库里只留高频使用的核心技能。6.3 如何有效清理技能关于清理有位朋友 tibo 分享过一个思路我实践后觉得挺实用先把现有技能列成清单一个个判断最近两周有没有被触发过没触发过的先禁用而不是直接删观察一个月再决定去留。这样既不会误删还能用的技能也能控制技能总量。清理时别只删文件还要注意两个地方一是项目里的.skills/目录有时候这个项目不再用了但技能文件还在占着位置二是某些工具会生成技能缓存删完文件旧配置可能还在报错这种时候去缓存目录清理一下。我自己还会在删除后做一个冒烟测试随便给 AI 一个对应任务确保它不会再引用已删除的技能。结尾一点个人经验前面聊了概念、安装、推荐、开发和排错最后再用我自己的体会收个尾。Skills 这个东西一开始容易让人上头觉得装得越多 AI 越强但我折腾一段时间后的真实感受是克制比堆量重要。真正提升效率的往往是那两三个紧紧绑定你日常高频场景的技能而不是一个塞满几十上百个文件夹的技能库。另外如果你打算自己写技能我的建议是先从改写自己最近的高频提示词开始。找一个你每周都要重复两三次的提示词把它结构化、加上步骤和禁忌生成第一个SKILL.md。不需要一上来就搞大而全的复杂设计先把最小的闭环跑通后面再逐步加。等你习惯了这套把流程写成文件的思路再回头去看各种高级技能库就能一眼看出哪些是精华、哪些是噱头了。
