最近后台和私信被问得最多的一个话题就是 AI skills不管是 Claude Code 怎么手动装 GitHub 上的 skills还是 superpower skills、opencode skills、codex skills 这些让人眼花缭乱的技能库大家都在问同一个问题这东西到底怎么用到底有没有用。前端开发 skills、数学建模 skills、AI 漫剧常用 skills听起来好像每个场景都能套一套但真上手装完发现不是不触发就是把模型带偏。这篇文章我一次性把 skills 的原理、安装、推荐、开发、清理这几个实操环节全部捋一遍适合正在用 Claude Code、Codex、OpenCode 这些 AI 编程工具的开发者也适合想从零开始沉淀自己 skills 库的效率型用户。你不需要懂太深的机器学习知识照着下面的路径走半小时以内就能把一个 skill 装进你的工作流里并且保证它真的能被调用。1. 先搞清楚AI Skills 到底是什么以及为什么大家都在折腾它1.1 从往对话框里粘贴规范到给模型配一个工作手册过去两年我用 AI 写代码、写文档、做数据分析最烦的一件事就是每次都要把同样的上下文手动塞进对话框。比如让我写数学建模论文我必须把建模步骤、格式要求、常见模型清单一遍一遍粘贴进去让我做前端代码审查我得把团队的规范规则复制粘贴给模型它才能按照我们的标准来输出。这种用法不是不行但效率很低也很啰嗦。Skills 解决的就是这个问题。它把一段高质量的指令、一套固定的工作流程、一些配套的脚本或模板打包成一个标准目录结构存放在模型客户端指定的路径下。当用户提出一个任务时AI 会先扫描所有可用的 skills通过每个 skill 的描述信息判断这个任务是不是适合调用这个技能包。如果匹配它就加载对应的内容按照其中的流程和规范来执行。你可以把 skill 理解为给模型配了一本工作手册。模型本身还是那套大模型但它手里的手册变了输出的稳定性和专业性就会完全不一样。这也是为什么很多人说 skills 是AI 模型能力的一种催化剂——它不是在改变模型而是在改变模型被使用的方式让同样的模型在同样的任务上输出更稳定的结果。1.2 一个 Skill 的标准结构长什么样目前市面上主流的 AI coding 工具对 skill 的目录格式已经形成了基本共识。以 Claude Code 为例一个最简 skill 的目录结构是这样的my-skill/ ├── SKILL.md ├── assets/ │ └── templates/ └── scripts/ └── helper.pySKILL.md是核心。它和其他 Markdown 文件的最大区别在于头部有一段 YAML 格式的 frontmatter里面至少包含name和description两个字段。description尤其重要因为模型是否在某个任务中触发这个 skill几乎完全取决于这段描述是否与用户的意图匹配。说得直白一点如果你的 description 写得太泛模型会分不清什么时候该用写得太窄模型在合适的场景下又想不到用它。assets目录用来放模板、示例、参考文件scripts目录用来放可执行的脚本。skill 里的脚本不是必须的但对于数据处理、格式转换、代码生成这类任务有了脚本能显著提升结果的可控性。整体的设计思路并不复杂复杂的是把做什么、怎么做、有什么限制、给出什么示例这套信息用模型最容易理解的方式组织起来。1.3 为什么 skills 能明显提升效率而不是玄学用一个生活化的比喻一个新手厨师如果只拿到一堆食材面对做一顿晚餐的需求可能只能凭直觉发挥但如果给他一本菜谱上面写着切配流程、调料比例、火候要点、成品示例他做出来的菜就会稳定得多。Skills 就是那本菜谱。模型本身的知识储备很丰富但面对具体任务时如果没有外部 constraints 的引导它倾向于给出最通用而不是最适合你的场景的答案。我实测下来的感受是一个好的 skill 能让模型在重复性任务上的输出质量提升一个档次。比如我写了一个数学建模竞赛答题的 skill把问题重述、模型假设、符号说明、模型建立、求解、灵敏度分析、评价与推广这套论文结构全部写死并且塞了两篇往年的优秀论文结构示例进去。之后我再让模型写建模论文它自动就按照这个框架输出不需要我每次在对话里重新交代一遍格式要求。这种效率提升不是模型变聪明了而是你学会了如何给模型下更专业的指令。2. 手动安装 GitHub 上的 Skills从查找到验证的完整实操2.1 怎么在 GitHub 上找到靠谱的 skill 仓库现在 GitHub 上已经出现了大量 skills 合集最典型的检索方式就是搜索awesome claude skills、awesome codex skills这类关键词。你会看到一些 star 数量很高的大合集比如anthropics/skills这种官方项目也有大量个人维护的分散仓库。我的习惯是先看三个指标star 数量、最后更新时间、issue 区有没有人反馈问题。star 多不代表一定好用但如果一个 skill 已经几个月没更新很可能适配的工具版本已经变了。其次要看 README 里给出的适用模型和安装方式有些 skill 明确写着只适配 Claude Code 3.5有些则在 Codex 环境下才能发挥最佳效果。如果你用的是 opencode 或 superpower skills 这类基于插件体系的工具安装路径还会更特殊。还有一个容易被忽略的点很多合集仓库里塞了几十个 skill但真正维护得好的可能不到三分之一。不要因为一个仓库 star 高就全部照搬我习惯只挑选其中描述写得清楚、目录结构完整的个别 skill 手动安装。这样既能看到源码怎么组织也方便后面自己写 skill 时模仿。2.2 Claude Code 手动安装流程用户级与项目级两条路径Claude Code 的 skills 安装路径分两个层级用户级全局可用~/.claude/skills/skill_name/SKILL.md项目级仅当前项目可用你的项目目录/.claude/skills/skill_name/SKILL.md这里我的建议是全局目录只放那些你在任何项目里都用得上、且不会干扰模型的 skill比如通用的代码审查、git commit 规范。而项目级目录则放这个项目专属的规范比如你一个自动生成报表的项目里面用到的字段定义、目录结构、图表风格这些东西放到项目级是最好的避免污染其他项目。手动安装的具体步骤以从 GitHub 克隆一个 skill 为例# 进入用户级 skills 目录 cd ~/.claude/skills # 克隆某个 skill 仓库假设它的目录结构直接以 SKILL.md 作为顶层 git clone https://github.com/your-user/awesome-skill.git my-skill # 如果仓库里有很多额外文件只保留 SKILL.md、assets、scripts cd my-skill rm -rf README.md tests .git如果只是下载一个单独目录也可以用svn export或直接在网页上下载 zip 解压。这里有个细节从 GitHub 克隆下来的仓库通常会带.git目录和 README如果不删掉Claude Code 在扫描 skill 时虽然不会出错但一些工具类脚本会误扫描隐藏目录里的文件所以我装完后习惯性清理一下只保留必要目录。装好之后重启 Claude Code。接下来就是验证环节这一步很多人会跳过但恰恰是最关键的。你直接输入一个和该 skill 描述匹配的任务然后观察它的回复。如果模型使用了那个 skill在 Claude Code 界面里通常会有明显的日志提示比如Using skill: my-skill。如果你想看得更细可以加--verbose参数启动日志里会完整展示模型读取了哪个 skill 文件和对应的上下文。2.3 Codex、OpenCode、Superpower 这些工具链又该怎么装Claude Code 是现在讨论度最高的但它不是唯一支持 skills 的工具。Codex CLI 的 skills 机制出现得比较早目录结构和 Claude Code 基本一致通常放在~/.codex/skills或项目.codex/skills下。OpenCode 则更强调插件机制它本身支持通过 plugins 加载 skill也有人直接把 skill 放进配置目录的skills子目录中。这类工具的更新频率很高官方文档变动也快我最推荐的方式就是装之前直接看一眼官方的 README而不是在网上找一篇可能已经过时的教程。Superpower Skills 是另一条路线它依托的是 VS Code 插件体系更像是一个技能增强套件。它的安装方式通常是通过插件市场的扩展入口而不是手动去创建目录。这类生态和 Claude Code 的纯文件体系不一样好处是图形界面操作方便坏处是自由度低一些而且你很难精确控制模型什么时候加载哪个技能。不管用哪个工具底层逻辑是一致的先找到 skill 存放目录把符合格式的 SKILL.md 放进去然后重启客户端验证。只要目录格式正确大部分工具都能识别。2.4 安装后如何验证 skill 真的生效我见过太多人装了一堆 skills 然后说没感觉其实问题往往出在验证方式上。正确的验证方法是分三步走。第一步直接命中。输入一个明显匹配该 skill 的场景。比如你装了一个typescript api 生成的 skill就输入帮我根据这个接口定义生成完整的 TypeScript client。如果模型用了 skill回复的开头通常会主动说明它正在应用某个 skill 的规则。第二步给一个模糊任务。这能测试 skill 的描述是否写得足够好。比如同一个 skill你只输入这个接口怎么调看它会不会自动联想到那个技能。如果它没有触发那多半不是安装问题而是这个 skill 的description写得不够精准。第三步看日志。Claude Code 的--verbose和 Codex 的 debug 日志都能让你看到模型实际扫描到的 skill 列表。这一步能排除路径错误和权限问题。如果工具扫到了 skill 文件但模型在任务中还是没使用那就是描述和任务匹配度的问题需要自己编辑SKILL.md的 description 来调优。3. 常见场景下的 Skills 推荐清单3.1 数学建模与编程竞赛华为杯好用的 codex skills 选择数学建模是我被问得最多的场景之一。你可能已经发现了每次建模比赛都要重复地做同一件事数据预处理、相关性分析、模型选型、论文排版。这里如果有一个好的 skill能省掉大量重复劳动。我推荐的标准数学建模 skill 应该包含以下几块内容问题背景分析模板、数据处理代码模板包括缺失值处理、标准化、离群值检测、常见模型的适用条件表回归、分类、聚类、时间序列、微分方程、模型灵敏度分析的步骤、论文各章节的写作要点。对于华为杯这种偏应用型的研究生建模赛事还应该额外加上问题重述要突出实际背景、模型假设要明确限制条件、方案要强调可行性这类针对性要求。在动手找这类 skills 时我建议你优先看那些在 GitHub 上附带历年论文示例的仓库。没有具体示例的 skill模型只能凭空产出一些套路化内容很难真正做到像参赛选手一样思考。我自己的习惯是即使下载了别人的数学建模 skill也会把往届优秀论文的框架整理成assets/example_layout.md放进去让模型在输出时有一个明确的结构锚点。3.2 前端开发、TypeScript 工程化与 API 客户端生成另一个高频场景是前端开发尤其 TypeScript 工程化。社区里比较出名的typesafe ai skills项目它专门用于生成类型安全的 API 客户端能根据 OpenAPI 文档自动生成 TypeScript 类型声明和请求封装代码。这对前后端协作比较紧密的团队非常实用因为接口一变类型也跟着变人工维护类型定义是最容易出错的环节。除了类型生成我在前端日常开发中最常用的还有三类 skills代码规范审查、组件脚手架生成、单元测试生成。代码规范审查的 skill 会内置团队的 ESLint 规则摘要、命名规范、组件结构要求让模型在 review 的时候不是空泛地说建议优化,而是能指出具体违反了哪条规则。组件脚手架生成的 skill 则是把项目中反复出现的页签、表格、弹窗组件模板沉淀下来模型生成新页面时就直接复用这套结构。单元测试生成的 skill 更讲究它必须包含项目的 mock 数据模式、断言风格和覆盖率指标否则生成的测试很难真正纳入 CI 流程。3.3 内容创作与 AI 漫剧保持人设和风格稳定很多人觉得 skills 是程序员专属其实内容创作场景同样适用。比如 AI 漫剧制作核心痛点是剧本风格不稳定、角色人设容易飘。一个设计良好的漫剧 skill 应该包含角色设定表外形、性格、口头禅、情绪反应、分镜结构模板开场钩子、情节推进、高潮、收尾、画面提示词生成规则景别、角度、光线、色彩、台词节奏规范短句为主避免长篇大论。模型加载了这个 skill 之后生成的剧本和分镜不管怎么改核心人设都能保持连贯。我在日常写作中也会用 skills 来管理文章语气。比如写技术教程时套上一个教程写作 skill它会强制要求每个章节给代码示例、给出失败排查、用类比解释复杂概念写个人随笔时换另一个 skill让语言更松弛、少用术语。本质上这就是把写作风格固化成一个个模板而不是每次开新文档时重复叮嘱模型请口语化一点请给出示例。这种用法同样适用于小红书文案、短视频脚本、电商详情页这些重复性很强的内容场景。3.4 常用 skills 源网站和合集仓库网上关于 skills 的讨论虽然多但信息和宝藏往往分散在很多地方。这里我整理几个我实际用下来比较有价值的查找路径GitHub 上的awesome-claude-skills、awesome-ai-skills类合集star 多覆盖面广。Anthropic 官方仓库anthropics/skills质量高但数量少适合看官方写法。各大 AI 编程工具的官方文档因为 skills 规范经常更新官方文档永远是最准确的来源。技术社区里的一些个人制品仓库通常针对具体问题很简陋但思路值得借鉴。我的建议是把这些源网站当成图书馆不要大面积一键全部安装。从里面挑三五个真正契合自己工作流的 skill手动装进去用两周时间做测试保留有效的删掉无效的剩下的精力放在自己复刻一份上这才是可持续的做法。4. 自己动手写一个 Skill从需求分析到落地4.1 写之前先想清楚一个合格 skill 的验收标准在动手写 skill 之前你要先想清楚一个问题什么任务是你反复让 AI 做的但每次都因为缺少上下文而需要补充大量说明。如果一件事你每周只做一次可以考虑不写如果一件事你每天都要做而且做完之后还需要花时间校对 AI 的输出那这个 skill 就值得投入时间。在我看来一个合格 skill 至少要满足三条标准第一触发准确即该用到的时候模型一定能用到不该用的时候不会被误触发第二输出可预期给定相同输入每次输出的结构和质量波动可控第三维护成本低后续新版本的模型甚至新工具链出现时修改 skill 的成本足够小。我见过很多人第一次写 skill一上来就想把几百条规则塞进去结果模型每次输出都要读一大堆内容反而变慢变笨。正确的做法是先写一个最小版本验证流程再逐步迭代加细节。4.2 搭建目录结构别忽略 assets 和 scripts目录结构可以直接复用行业通用的格式。以我自己写的一个代码审查 skill 为例code-review-skill/ ├── SKILL.md ├── assets/ │ ├── review-checklist.md │ └── security-patterns.md └── scripts/ └── analyze_imports.pySKILL.md负责整体逻辑assets/review-checklist.md里是审查时的检查清单scripts/analyze_imports.py是一个小脚本用来扫描代码里未使用的 import 和高复杂度函数。这样拆分的好处是主文件不会被规则细节堆满模型在加载 skill 时能快速抓住核心流程需要细节时再访问assets中的文件。4.3 写 SKILL.md 的核心技巧描述要具体规则要可验证SKILL.md最关键的部分就是这个 frontmatter 和正文的组织方式。写description的时候我建议用当用户想要……时使用此技能这种句式把触发条件写精确别写帮助用户审查代码这种空话。原因是模型在每次任务中扫描技能库时实际上是在比对description和用户意图的语义相似度。空泛的描述会降低匹配精度。正文部分我习惯用几个固定区块目标任务、工作流程、输入要求、输出要求、约束条件、示例参考。在工作流程里尽量使用明确的步骤动词比如第一步阅读用户提供的文件并识别其类型第二步执行代码审查清单第三步生成修改建议清单。在输出要求里直接规定输出格式比如使用表格列出问题等级、问题描述、位置、修改建议。在约束条件里写清边界比如如果代码量超过 1000 行按函数逐个审查不在同一个回复中一次性输出全部结果。这里有一个很容易被忽略的点模型给出的回复不是每次都能自动遵守你写的规则所以在写规则时要尽量把具体到可验证作为目标。比如不说检查安全性而说检查是否存在 SQL 注入风险如果发现则标注具体行号和触发路径。这样的表述模型更容易执行你的验收也会客观得多。4.4 配套脚本怎么组织什么时候才需要脚本不是所有 skill 都需要脚本但如果你想做的事情涉及本地文件处理、数据格式转换或者计算逻辑脚本是最可靠的。模型本身的代码生成能力强但执行环境不稳定而 skill 里附带脚本能在模型控制之外的部分保证结果的一致性。我举一个实际例子我写过一个用于日志解析的 skill里面放了一个 Python 脚本专门用来解析各类日志文件提取出错误码、时间戳、请求耗时并输出结构化 CSV。模型在调用这个 skill 时会先看到脚本的使用说明然后会按照说明调用脚本再把脚本输出结果嵌入到它的分析中。这个流程中模型的角色是看懂脚本结果并给出解释而不是靠记忆猜测日志结构。写脚本时要注意环境依赖声明。比如脚本需要pandas就要在SKILL.md里写明安装要求或者在脚本头部加个自动检测依赖的函数。我自己踩过不少次坑脚本本身没问题但因为环境缺某个依赖模型建议用户手动装整个流程就断了。4.5 一个最小可用 skill 的完整示例以最简的Git Commit 信息生成 skill 为例。假设你希望 AI 生成的 commit message 符合 conventional commits 规范并且带上 jira 单号。你可以建一个commit-style-skill目录里面放一个SKILL.md--- name: commit-style-skill description: 当用户需要生成 git commit message 时使用该技能。适用于所有 git 提交场景能根据 diff 自动生成符合 conventional commits 规范的提交信息并自动关联 Jira 单号。 --- # Git Commit Message 生成 ## 工作流程 1. 获取用户提供的 git diff 内容。 2. 识别变更类型选择对应的 commit typefeat、fix、docs、style、refactor、perf、test、chore。 3. 从当前分支名或 diff 内容中提取 Jira 单号格式为 PROJ-1234。 4. 生成 commit message格式为 type(scope): 描述 [PROJ-1234]。 5. 如果识别到 breaking change在 message 末尾添加 BREAKING CHANGE: 说明。 ## 约束条件 - 描述部分使用英文还是中文取决于用户当前回复使用的语言。 - 当 diff 内容为空时不生成任何 commit message提示用户先暂存或提交文件。 - 不猜测 Jira 单号如果无法从上下文提取省略该后缀。这个例子非常简单但它展示了 essentials描述具体、流程顺序清晰、有边界条件。你完全可以用这个模板去扩展更复杂的技能。4.6 如何测试和迭代你的 skill写完之后不要急着投入使用先在空目录下跑几个测试用例。如果 skill 是代码审查类的就故意提交一段有明显问题的代码看模型能否按技能中的清单逐项审查如果是写作类的就分别给它一个高度匹配的主题和一个边缘化主题看它会不会误触发。我一般会准备一个测试清单包含匹配场景、模糊场景、完全不相关场景、边界场景。比如测试 commit 生成 skill匹配场景是帮我写 commit message模糊场景是看看这次改了什么不相关场景是解释一下什么是 git边界场景是diff 为空。通过这些测试你才能判断description的描述是否覆盖了你真实的意图空间。5. 清理、维护与管理让 Skills 不失控5.1 为什么 skills 越多反而越乱很多开发者一看到好的 skill 就装不知不觉全局目录下堆了一两百个。这会造成一个非常现实的问题模型在每次任务中都要扫描一遍所有可用的 skill 描述技能越多扫描的上下文成本越高而且误触发的概率也会增加。也就是说你以为装了更多技能会让模型更聪明实际上它可能因为选择困难而在多个相近技能之间摇摆。有一次我全局装了七八个偏代码相关的 skill分别是代码审查、代码优化、重构、复杂度分析、单元测试生成。结果用户发一句帮我看看这个函数的性能问题模型居然同时参考了三个不同 skill 的内容输出变得很矛盾。后来我不得不花了一个下午挨个测试把重叠的 skill 全部合并。5.2 借鉴 tibo 关于清理 skills 的方法分类和归档社区里关于清理 skills 的方法tibo 那种思路算是比较实用的。核心不是把不用的删掉而是建立一套归档机制。具体操作是在 skills 目录下建一个archive文件夹把暂时不用的 skill 移入其中再建一个active文件夹只放最近一个月真正用过的技能。这样既避免误删又降低了模型的扫描负担。我的实际操作流程是打开~/.claude/skills用ls -lt按时间排序查看最近改动的目录。查看每个 skill 的SKILL.md里的description回想最近一个月有没有在对话中见到它被调用。把三个月没有触发过的 skill 移入archive子目录不会删除。如果某个 skill 功能相近保留其中最简洁、描述最精准的那个。如果你用的是 Claude Code 这类工具日志里有时能看到实际调用了哪几个 skill这比靠记忆判断准确得多。5.3 用 Git 管理 skills团队共享和个人备份skills 本质上就是文本文件加上一些脚本非常适合放进 Git 仓库管理。我自己的做法是在本地建一个my-skills仓库里面按claude/、codex/、opencode/分类存放每次修改 skill 都提交一次。这样既能回到稳定版本也能在换新电脑时一键恢复。对于团队协作我建议把项目级 skills 放在项目仓库的.claude/skills里随代码一起走。这样新同学 clone 仓库后不需要额外配置AI 工具就能读取同一套规范。需要注意如果团队中有多个工具链不要在一个目录里混放多个工具的配置否则很容易造成路径冲突。我踩过的一个坑是在项目仓库里放了 Claude Code 的 skills后来团队又统一使用 Codex结果因为目录结构不一致大家一度以为 skills 坏了。实际上只需要把对应配置放到 Codex 的目录下就行。工具不同目录不同这是最容易被忽略的一点。6. 避坑清单我在使用 Skills 时踩过的具体坑6.1 描述写得太宽泛模型永远不触发这是新手最容易踩的坑。我最初写的 skill 里description就写着用于代码审查结果模型频繁误触发甚至让它写一个排序算法的时候也触发。后来我把描述改成当用户提供一段函数或文件并要求评估其代码质量、安全隐患和可维护性时使用该技能触发准确率立刻提升了。好的描述本质上是给模型一个清晰的边界感。6.2 塞了大量规则但没有示例输出依然空泛在写 skill 的时候我给过一个很长的规则清单包括语句要简洁、结构要清楚、逻辑要严密结果显示模型输出一大堆正确的废话。问题在于这些规则无法被验证。后来我把每个规则都替换成具体示例比如在代码审查中如果发现循环嵌套超过 3 层应指出并建议将内层逻辑抽取为独立函数。模型在有具体示例的情况下输出质量明显提升。6.3 把不常用的 skill 放在全局目录导致项目级被干扰全局目录里的 skill 对所有项目可见。我之前把一个SQL 生成的 skill 放在全局结果某个 Java 后端项目在写实体类时居然被触发了输出内容完全没有意义。后来我把所有非通用技能全部移入项目级目录全局只保留与语言无关、跨项目通用的少数几个技能。这个习惯让我省了不少排查时间。6.4 手动安装时路径搞错工具扫不到技能如果你直接在~/.claude下建立了skills目录但工具版本升级后把默认位置改成了~/.config/claude/skills那你放进去的技能永远不会被发现。我建议每次手动安装之前先确认当前工具的 skills 目录路径。你可以用一个故意写错路径的 skill 测试也可以直接在对应客户端的配置页面查看。路径不对后面所有努力都白费。6.5 脚本依赖未声明流程中断在最关键一步Skill 里带脚本时依赖声明极其重要。我写过一个依赖requests库的脚本结果在别人电脑上就因为没有安装这个库而失败。后来我在SKILL.md里加了一个依赖检查小节并且在脚本开头加了自动检测和提示安装的逻辑。这里的教训是脚本不是写给你自己用的而是给 AI 在不同环境中执行的所以它必须足够健壮。我个人在踩过不少坑之后现在已经形成了固定的管理习惯所有新 skill 先放项目级测试一周验证有价值再升级到全局所有全局 skill 每个季度清理一次把闲置技能移入归档所有 skill 的修改都必须走 Git 提交保留完整的演化历史。这些习惯听起来很繁琐但长期下来真的能让你的 AI 工作流又稳又准。如果你正准备开始整理自己的 skills不妨先试着手动装一两个用两周感受一下它到底改变了什么然后再决定要不要把这套机制变成你日常的一部分。