说实话我第一次认真研究 AI 编程代理里的skills是因为一个特别没面子的场景Claude Code 在同一个项目里连续三次把同样的 ESLint 配置改错我气得差点把终端砸了。后来朋友甩了一个词过来你没给它写 skill 吧当时我以为又是某种花哨的插件机制根本没当回事。直到真的花一个下午把一个数学建模类问题拆解的 skill 喂进去整个协作体验直接变了。这篇东西不是教程文档是我自己从skills 是什么到怎么写、怎么装、怎么清理完整踩过一遍之后整理下来的一套实操笔记。内容覆盖前端、数学建模、AI 漫剧这些高频场景主角是目前社区里最活跃的 Claude Code 和 Codex顺带聊聊 OpenCode。你如果正在用这些工具写代码、做竞赛、甚至批量产内容这篇应该能直接帮你少走很多弯路。1. 先搞清楚AI 的 skills 到底是个啥1.1 从 prompt 到 skill一次范式转变先说个最简单但最重要的认知skill 不是插件不是 MCP server它本质上是一份高质量上下文包。我以前用 AI 写代码习惯把一长串要求直接粘进对话里什么你是资深前端工程师注意性能、注意可维护性、注意边界情况每次都要重复一遍而且经常说着说着就被 AI 带偏。skill 的思路恰恰相反把这条冗长的指令变成一个可以被反复调用的独立模块里面除了指令还塞了示例、检查清单、代码片段、甚至脚本。AI 在合适的场景下会自动加载这个模块而不是靠你每次手写临时发挥。这个转变很关键。以前 prompt 是一次性消费skill 是资产化沉淀。你今天在某个项目里总结出来的那套处理 React 性能问题的方法论整理成 skill 之后明天开一个新项目AI 直接就能带着这套经验上岗。时间久了你手里的 skills 库就是你个人的AI 调教资产库越用越值钱。1.2 skill、plugin、MCP三兄弟别搞混很多人第一次搜 skills 的时候会看到 plugin、MCP、extension 这些词一起涌出来直接懵掉。我用一张表把它们的区别讲清楚。维度SkillPlugin / ExtensionMCP Server核心作用提供怎么做的行为指导扩展工具的界面和交互提供能干什么的外部能力表现形式文字指令 示例 脚本代码模块常有 UI独立服务通过协议调用是否需要网络通常不需要不一定通常需要典型用途让 AI 按你的规范写代码在编辑器里加按钮/面板让 AI 查数据库、发请求和 AI 的关系直接进入上下文间接辅助通过工具调用一个常见的误区是有了 MCP 就不需要 skill。实际上两者是互补的。MCP 给 AI 提供了手skill 给了 AI脑子。比如数学建模场景你接一个能跑 Python 的 MCP serverAI 确实能调用环境去算题了但如果没 skill 告诉它先拆问题、再选模型、再验证假设这套流程它很容易拿到数据就开始糊模型结果跑出来一堆没有业务意义的数字。所以正经的用法是 MCP 负责能力接入skill 负责方法论约束两个配合才稳。2. 值得关注的 skills 场景与热门推荐2.1 前端开发类 skills解决AI 改代码像瞎子一样的问题前端开发是 skills 受益最明显的领域之一。原因很简单前端项目对风格一致性的要求特别变态组件命名、状态管理方式、样式方案、目录结构任何一项不一致都会让后期维护炸裂。我给 Claude Code 配过一个前端规范类 skill里面就是把团队那套代码评审 checklist 全部写成指令再配上两个好的组件示例和坏的组件示例。效果就是 AI 生成的代码风格明显向团队规范靠拢而不是生成一堆能跑但味道不对的代码。社区里现在能搜到的前端 skills 主要分三类。第一类是全栈脚手架类你给它一个项目描述它能按照固定的架构模板把项目搭出来第二类是单点优化类比如React 性能分析 skill专门用来排查重渲染问题第三类是代码审查类让 AI 按指定标准对现有代码做 review 并直接输出带优先级的修复建议。我个人建议新手从第二类和第三类入手因为见效最快而且不用一次性给 AI 灌输太多规则。2.2 数学建模 / 竞赛类 skills华为杯、国赛都能用的实战组合数学建模是另一个让我彻底服气 skills 的场景。拿华为杯这类比赛来说时间紧、任务重每道题都得在几天内完成问题分析-模型建立-求解-验证-论文写作的完整闭环。以前我干这事的时候全靠人肉在多个文件之间来回复制粘贴提示词浪费时间不说AI 还经常忘了前面的约束。后来我组合了一套数学建模工作流 skill 包包含三个独立 skill第一个是问题拆解器拿到题目后强制 AI 先输出问题域、约束条件、目标函数和可选模型列表不经过这步不许碰数据第二个是模型选择器内置了常见的优化模型、统计模型、机器学习模型的适用条件对照表让 AI 基于第一个 skill 的输出做匹配推荐第三个是论文结构器按数模论文的标准章节结构组织写作把摘要、模型假设、灵敏度分析这些模块的要求都写进去。我自己的实测体验是用上这套 skill 之后AI 给出的建模思路从东一榔头西一棒子变成了有逻辑递进尤其在被追问为什么选这个模型的时候AI 能引用 skill 里的对照表给出理由而不是胡编。华为杯这种比赛评委特别喜欢看这种有依据的分析所以这套组合对竞赛人群来说非常值得复制。2.3 AI 漫剧 / 创意内容类 skills批量产出的稳定器AI 漫剧或者 AI 短视频这两年特别火很多工作室在批量做内容。这类场景的核心痛点其实是风格一致性同一部漫剧主角长相不能变、画风不能变、叙事节奏也不能变。光靠 prompt 去控制换个场景就翻车。skills 在这里的玩法是把整个叙事和视觉规范固化成几个模块比如角色一致性 skill里写好主视觉描述和禁止事项比如任何时候不得改变瞳孔颜色分镜脚本 skill里规定一场戏必须按远景定场-中景对话-特写反应的节奏来写。有人可能会问这不就是写几个模板 prompt 吗区别在于 skill 能被 AI 自动触发。比如你在对话里扔进一句下一场戏是主角在雨中回忆AI 会自动激活对应的分镜 skill 和角色 skill而不需要你每次手动把一大段规范复制进来。对于批量产内容的团队这个自动触发的价值不是省几分钟而是消灭了人为忘记带上下文的问题。2.4 通用效率类 skillssuperpower 这类全家桶要不要装社区里讨论度最高的通用型 skills 项目一个是 superpower skills另一个是 Anthropic 官方维护的 skills 仓库。superpower 这类全家桶的特点是全从写代码到写文档从做计划到做复盘塞了几十个 skill 进去。第一次装完那种感觉确实很爽感觉 AI 什么都懂。但我要泼一盆冷水全家桶对你来说可能太重了。我的实际体验是几十个 skill 全量塞进上下文之后AI 的响应变慢而且会出现选择困难明明一个简单的排序问题它非要调用那个算法设计大师的 skill输出一堆和问题不匹配的仪式感内容纯粹是浪费 token。所以我的建议是你可以把全家桶下下来当成 skill 写作的参考教材但实际使用一定要做瘦身只留高频使用的十个以内。这个清理方法后面专门有一节讲。3. 手动安装 GitHub 上的 skills以 Claude Code 为例3.1 先看懂一个 skill 仓库的结构很多人在 GitHub 上找到了心仪的 skills 仓库却卡在怎么装这一步。原因是不理解 skill 的目录结构。一般一个标准 skill 长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── check.py └── resources/ └── template.md核心就是那个SKILL.md文件它是一切的入口。里面一般带 YAML 格式的 frontmatter包含name和description两个关键字段。name是 skill 的标识description则是给 AI 看的触发条件AI 就是通过读这段描述来判断当前任务该不该调用这个 skill。所以一个 skill 能不能被 AI 正确触发一半的功劳取决于description写得好不好。剩下的scripts和resources目录都不是必须的看需要加。scripts放一些可以被 AI 调用的脚本比如格式检查脚本resources放辅助材料比如模板文件、参考文档。理解了这个结构安装就变得很简单本质就是把整个目录放进 AI 工具能扫到的地方。3.2 手动安装clone 到你不需要思考的位置以 Claude Code 为例它在运行时主要扫描两个位置的 skills一个是用户级目录~/.claude/skills/一个是项目级目录.claude/skills/。用户级目录对所有项目全局生效项目级只对当前项目生效。手动安装的步骤如下。第一步定位仓库先去 GitHub 找到目标仓库把仓库 clone 到本地任意临时目录。注意有些仓库根目录就是一整个 skill有些仓库则是多个 skill 的集合你还得进去找到对应子目录。第二步复制把单个 skill 目录复制到~/.claude/skills/下面。比如你下载了一个叫frontend-review的 skill最终路径应该是~/.claude/skills/frontend-review/SKILL.md这个结构不能错。第三步重启会话让 Claude Code 重新加载配置。用/skills命令可以列出当前已加载的 skills检查一下目标 skill 有没有出现在列表里。如果出现了就说明安装成功可以开始用了。# 安装命令示例 git clone https://github.com/xxx/awesome-skills.git /tmp/awesome-skills mkdir -p ~/.claude/skills cp -r /tmp/awesome-skills/frontend-review ~/.claude/skills/提示复制完目录之后先看一眼SKILL.md里的name字段和目录名是否一致。有些仓库的目录名和name不一致Claude Code 对这种情况的处理在不同版本里表现不太一样统一改一致最稳妥。3.3 Codex 和 OpenCode 的安装差异如果你用的不是 Claude Code而是 OpenAI 的 Codex 或者开源的 OpenCode安装思路一样就是目标目录不同。Codex 的 skills 通常放在.codex/skills/项目级或者~/.codex/skills/用户级OpenCode 的配置目录一般在~/.config/opencode/skills/这种位置。最笨也最有效的办法是装好工具之后先手动建一个测试 skill然后看它到底被扫描到哪个目录再去翻这个目录的路径。我个人的建议是如果你想在不同工具之间共享同一种 skills 管理体验可以把真正的技能内容集中放在一个自己的目录里比如~/my-skills/然后在各个工具的 skills 目录里建软链接指向它。这样你改一份内容所有工具都生效不用重复复制。3.4 安装失败最常见的三个原因安装这门手艺失败才是常态。我踩过的坑和看到别人踩的坑基本可以归结为三点。第一目录结构不对。最常见的是直接把整个仓库根目录复制进来导致SKILL.md没有在顶层而是埋在仓库名/某个子目录/SKILL.md里。这个问题最气人因为看起来啥都装了但 AI 就是不认。第二description 写得太差。有时候 skill 装上了也能列出但 AI 永远不触发它。这种多半不是安装问题而是 skill 自己的description写得像猜谜AI 根本不知道什么场景该调它。这类问题只能靠改写SKILL.md来解决。第三文件权限问题。在用软链接或者跨用户目录分享 skills 的时候容易遇到AI 工具进程读不了文件。用ls -l看一眼权限位给足读权限就行。4. 自己写一个 skill从零到能用的完整过程4.1 先搞清 SKILL.md 的骨架和写作顺序自己动手写 skill 并没有想象中那么难但也不是写一段 prompt 扔进去那么简单。一个能稳定发挥作用的 skill背后通常有一整套结构。我把 SKILL.md 的骨架拆给你看YAML frontmatternamedescription。name别起得太玄description则要尽量写清楚这个 skill 在什么情况下、解决什么问题。触发条件说明正文一开始用自然语言告诉 AI什么时候必须使用这个 skill相当于给 AI 一个开关。执行步骤把任务的执行流程拆成明确的、有序的步骤。注意步骤要拆到 AI 不用猜的地步。硬性规则列出绝对不能违反的铁律比如禁止使用全局变量不得修改用户未指定的文件。输入 / 输出格式定义调用这个 skill 的时候需要哪些输入以及 AI 应该输出什么格式的内容。示例一个完整的、好的示例比一百句解释都管用。写作顺序上我的习惯是先从示例开始。先把一个理想输出样例写好然后倒推需要什么样的步骤和规则才能产生这样的输出。最后再回头写description。很多新手搞反了先写描述再写内容结果描述写得花团锦簇实际执行逻辑全是漏洞。4.2 写 PROMPT 的进阶技巧别坐等 AI 理解给它决策树这是我写了几十个 skill 之后最大的心得好的 skill 不是指令大集合而是决策树。最简单的写法是告诉 AI如果 A 情况就做 X如果 B 情况就做 Y但真正的实战里情况往往是混合的、交错的。举个例子。我在写数学建模问题拆解这个 skill 时没有简单写先读题再拆解而是写了一套判断规则如果题目包含明确的目标函数和约束条件优先归入优化类问题输出模型候选列表时必须包含线性规划或整数规划的评估。如果题目给出时间序列数据且要求预测优先归入统计预测类必须做平稳性检验并在输出中给出检验结论。如果题目是分类问题但数据量小于阈值强制提醒优先尝试可解释模型而不是一上来就选神经网络。这种如果-那么结构让 AI 的执行路径稳定得多。因为 AI 天然喜欢顺着明确的逻辑链走你给它一个判断框架它输出的东西就具有了可预期性。写 skill 最忌讳的就是含糊的期望比如请给出高质量的分析这种描述等于没说。4.3 完整示例手写一个数学建模问题拆解 skill我直接把我用过的简化版贴出来你可以照着改。这个 skill 是前面说的建模 skill 包里的核心模块结构很典型。--- name: math-modeling-scaffold description: 用户给出一个数学建模竞赛题目或复杂实际问题时使用。用于在建模前完成问题结构化拆解输出问题域、约束条件、决策变量、目标函数和候选模型清单。任何数学建模相关请求都必须先经过此 skill 处理。 --- # Math Modeling Scaffold 你必须在使用本 skill 后按以下结构输出内容。未完成全部步骤之前禁止进入建模或求解阶段。 ## 步骤一问题域识别 - 用自己的话复述题目不超过 100 字。 - 列出问题所属的学科域运筹优化 / 统计预测 / 机器学习 / 微分方程等。 ## 步骤二要素抽取 - 约束条件列出题目中所有显式和隐式约束。 - 决策变量列出可能的决策变量并标出离散/连续属性。 - 目标函数如果题目隐含优化目标将其明确写成数学形式如果没有则说明该问题不是显式优化问题。 ## 步骤三候选模型生成 - 基于以上要素给出 3 个候选建模方向。 - 每个候选必须说明选它的理由、适用前提、以及如果前提不满足时的备选方案。 ## 步骤四硬性规则 - 禁止编造题目中不存在的数据。 - 禁止在未完成要素抽取前给出最终模型。 - 输出必须使用 Markdown 表格呈现候选模型对比。 ## 示例 此处粘贴 1-2 个之前做过的完整拆解案例这个 skill 核心就一个目的掐住 AI 建模前期的流程。我试过没有这个 skill 的状态AI 经常拿到题十分钟就开始列方程最后发现漏了一个关键约束整个模型推翻重来。加了 skill 之后它哪怕想飞也得先把前四步走完过程质量明显高一个档次。4.4 调试和迭代skill 不是写一次就完事写完 skill 只是第一步调试才是重头戏。我的调试方法非常简单粗暴准备三个不同类型的测试输入分别让开了 skill 的 AI 和没开 skill 的 AI 跑一遍然后对着输出差异找问题。如果发现 AI 的输出还是偏离预期通常不是 AI 笨而是 skill 里的规则有歧义需要改得更死板一点。迭代频次方面一个新 skill 我一般会经历三次左右的修改才达到稳定状态。第一次修逻辑漏洞第二次补边界情况第三次简化措辞减少 token 占用。修改完要记得重启会话再测试因为 AI 工具对 skill 的加载大多是在会话启动时完成的热更新能力有限。5. 常用 skills 源网站和获取渠道5.1 值得常驻的几个 GitHub 仓库社区里几个高质量的 skills 源我已经常驻了定期去翻翻更新。按我的使用频率排序仓库/来源特点适合人群anthropics/skills官方出品质量最稳示例规范所有想学写 skill 的人superpowers 类全家桶覆盖面广量大管饱想参考各类 skill 写法的人typesafe ai skills企业级工程实践偏 TypeScript 栈后端/全栈开发者codex-nature-skills偏 Codex 生态的自然语言类 skill用 Codex 做自动化的人各类awesome-skills聚合仓库收集大量第三方 skill到处找灵感的人有些名字你可能没搜到比如 cola skills这类通常是社区个人维护的集合型仓库特点是作者会把自己的实战经验打包进去风格更野但有时反而更对你的场景。我的建议是别只盯着 star 数高的多去搜skills和你的垂直场景组合词比如前端开发 skills数学建模 skills往往能挖到小众但好用的东西。5.2 在 GitHub 上筛选高质量 skills 的三个标准GitHub 上 skills 仓库鱼龙混杂我筛选的时候只看三点。第一看 SKILL.md 的 description 是否具体。凡是 description 写成帮助开发者提高效率这种片儿汤话的直接跳过。好描述会写清楚触发条件和使用边界我前面说过了。第二看是否带示例。一个好的 skill 必然带完整的输入输出示例。不带示例的 skill大概率是作者从某个 prompt 集合里复制粘贴过来充数的稳定性和效果都没保证。第三看最近更新时间和作者对 issue 的回复。skills 这个领域变化太快官方工具的加载规则说改就改长期不更新的 skill 大概率已经失效。作者如果在 issue 区积极回复适配新版工具之类的内容说明还在维护。5.3 自己搭一个私有技能源公共仓库只是起点认真玩 skills 的人最后都会走上自建这条路。原因很简单你自己沉淀的 skill 才最贴合你的工作流而且包含很多不能公开的团队规范或业务逻辑。我用的是最传统的方案一个私有 Git 仓库按类型建目录比如frontend/、math-modeling/、content/每个目录下放对应的 skill 子目录然后通过软链接的方式让 Claude Code 和 Codex 都能读取。自建技能源还有一个额外的好处就是可以做版本管理。我改一个 skill 改坏了可以直接回滚到之前的版本。这个习惯帮我避免过好几次灾难有一次我把一个本来运行良好的代码审查 skill 改成了全英文输出规范结果 AI 开始频繁输出英文注释团队差点炸锅亏得 git 回滚救了一条命。6. 技能库管理清理、去重和版本控制6.1 为什么要定期清理因为会技能通货膨胀我见过有个朋友装完 superpower 全家桶之后又装了两三个聚合包总共塞了 80 多个 skill 进系统。看起来壮观实际用起来是一场灾难。主要的副作用有三个token 浪费、选择困难、指令冲突。token 浪费发生在很多工具会把 skill 列表甚至内容加载进系统提示词选择困难是说 AI 面对几十个候选 skill 时经常挑一个次优的去执行指令冲突更离谱两个 skill 对同一个操作给出相反要求AI 直接精神分裂。这就像手机里装了几百个 App看似啥都能干实际上每个都想弹通知最后你连微信消息都看不清。技能库不是收藏夹装进去就是为了用的用不上就删别心疼。6.2 清理方法论按使用频率和场景归档关于清理我之前看到过一个叫 tibo 的开发者分享过一套思路核心是分类 频率 价值三维清理法。我自己实操下来觉得很有用具体做法是这样的。第一步把当前所有 skills 列个清单。 第二步按使用场景打标签比如高频关键低频备用实验性尝试过期废弃。这里可以靠/skills命令的输出和你的记忆来判断不用太精确。 第三步对每一类执行不同策略。高频关键的直接保留低频备用的移到单独目录别占着主目录实验性的只留最新那个版本过期废弃的直接删。 第四步每两个月做一次复盘把真的超过半年没用过的低频 skill 清理掉。这套清理的频率因人而异我自己的节奏是每个季度大扫除一次每次能删掉三五个曾经觉得有用、实际吃灰的 skill。释放的可不只是硬盘空间更重要的是 AI 的决策空间。6.3 用 Git 管理 skills 版本的实操细节用 Git 管理 skills 有几个容易忽略的细节。第一是目录结构要和工具的扫描路径解耦我建议真正的技能目录放在~/skills-repo/下然后用软链接接到~/.claude/skills/和~/.codex/skills/这样 git 仓库只管内容不管工具路径。第二是提交信息要写清楚改动意图。别写update skill这种废话我一般写frontend-review: 增加对 Vue 3 组合式 API 的检查规则一个月之后翻 log 还能想起来当时的思路。第三是要做示例基线。在每个 skill 的目录里放一个test/文件夹存几个标准测试输入和期望输出。每次改动 skill 之后用这些示例跑一遍回归测试。我见过很多 skill 越改越歪就是因为没有守住基线改着改着把 AI 的行为改偏了。7. 学习路径与实用心得7.1 新手最顺的学习顺序如果你完全零基础我的建议是先不要急着写自己的 skill按下面这条路径走大概一两天就能上手。第一步找一个靠谱的官方示例仓库比如 anthropics/skills把里面的 skill 挨个读一遍重点看SKILL.md的结构。先培养语感知道好 skill 长什么样。第二步选一个你工作中最高频的场景把现有的 prompt 整理成一个最简单的 skill先装上用起来。不用追求结构完整先体验调用 skill 之后的差异。第三步当你觉得现有 skill 不够用、AI 经常在某个环节跑偏的时候再开始学写决策树式规则逐步完善细节。这时候才算真正进入 skill 开发的状态。最忌讳的学习方式是一上来就研究全家桶源码试图理解所有类型。实际写作和调试的经验比阅读重要得多写坏三个 skill 之后你自然就懂那些最佳实践是为什么了。7.2 我踩过的几个值得记住的坑讲几个我用真金白银的 token 换来的教训。第一个坑是过度使用示例。我给一个前端 skill 塞了整整两个完整的项目示例结果每次 AI 输出都会不自觉模仿示例里的命名风格哪怕场景根本不同。示例不是越多越好一个正例一个反例足以。第二个坑是规则互相矛盾。我写完输出必须简洁的规则之后又在同一个 skill 里写了必须输出完整的逐步分析结果 AI 每次都在语句长度上纠结。写完 skill 之后一定要通读一遍把自己放在 AI 的位置上感受一下有没有左右互搏的地方。第三个坑是忽略工具升级。Claude Code、Codex 这些工具的加载规则是快速演进的一个月前能正常触发的 skill可能因为工具加了新的优先级机制就失效了。所以每逢工具提示升级我都建议花十分钟过一遍常用 skills 还正不正常。第四个坑是关于 token 的skill 不是塞得越详细越好。本地测试的时候用大模型感觉不明显但一旦进入长对话一个 3000 字的 skill 可能挤压真正对话内容的上下文空间。我这边的经验值是单个 skill 的正文控制在 800 到 1500 字之间执行规则写清楚但别写成百科全书。7.3 把 skills 当作团队资产来运营最后想多说一句是个人的价值判断。很多人把 skills 当成个人效率工具但我更愿意把它看作可沉淀的团队资产。一个好用的 skill本质上是你和团队把隐性知识显性化的过程。以前老程序员带新人靠的是口口相传和 code review 里一遍遍纠正现在你把团队规范写进 skillAI 就成了一个不厌其烦、永远遵守规范的新成员。所以我在团队里推过一个做法每次有人写了一个新的高效 prompt 或者解决了一个疑难 bug就顺手把它变成一个小 skill 提交到团队仓库里。一个月下来团队就有了一个集体调教的 AI。这件事的价值不是省了几个小时的提示词时间而是把每个人脑子里的经验沉淀成了可复用的资产。我自己的体会是skills 真正厉害的地方不是让 AI 变聪明而是倒逼你把问题想清楚——你不把流程琢磨透根本写不出一条稳定的规则。就凭这一点花在 skills 上的时间就一点都不亏。