我最早对 skills 不以为意觉得不过是把提示词换了个马甲塞进一个目录里而已。直到有一次我把一个数学建模老手的技能包塞进 Codex原本计划花两小时整理数据、贴公式、排版论文的工作四十分钟全跑完我才意识到这玩意儿比单个提示词整整高一个维度。现在社区里最火的说法叫 superpower skills翻译过来就是“给 AI 装上可复用的超能力”我觉得一点都没夸张。你手里的 Claude Code、Codex、OpenCode 其实都已经是相当强的 Agent但默认情况下它们更像一个“什么都会一点但不够专”的实习生。你给它们一份前端开发的 skill它就会按团队的代码规范写页面你给它们一套数学建模的 skill它就知道赛题数据该怎么做清洗、相关性分析、模型对比、论文排版。换句话说skills 解决的是“AI 懂通用知识但不懂你的行业规矩和项目套路”这个核心问题。这篇文章我打算聊透几件事skills 到底是什么、为什么值得当超能力用如何手动安装 GitHub 上的现成技能包前端开发、数学建模、AI 漫剧这几个热门场景分别怎么挑技能最后从零手写一个 skill分享我在实际使用和清理维护中踩过的坑。无论你是刚接触 Agent 编程的新手还是已经在折腾技能库的老手应该都能在里边找到能直接抄作业的东西。1. 什么是 AI Skills为什么会被当成“超能力”1.1 从 Prompt 到 SkillAI 工作方式的转变纯 Prompt 的方式是这样的你每次跟 AI 说“帮我写一个 React 组件遵循公司规范要测试用例”AI 只能靠它训练时的记忆去猜“公司规范”长什么样。如果你换了项目、换了模型、换了会话窗口这些要求都得重新说一遍。信息是碎片化的模型每次都在“盲猜”。Skill 走的是另一条路把一份完整的“岗位说明书 操作手册 范例 校验脚本”打包成目录。Agent 在干活之前会先扫描目录里的 SKILL.md读一读描述判断当前任务跟哪个技能匹配。一旦匹配上它就把整套手册读进上下文然后按手册里的步骤执行。同样写一个 React 组件这时候它手里已经拿着你们团队的目录结构、组件命名规则、测试断言风格、甚至历史优秀代码片段。打个比方Prompt 是你在电话里口头叮嘱“到了现场看着办”Skill 是直接甩给对方一本带图纸、带清单、带验收标准的施工手册。你能放心让施工队干的事完全不是一个量级。1.2 Skills 的本质是“给模型一套可执行的操作手册”一个标准的 skill 不像一个函数那样只有一个文件它通常是一个有结构的目录my-skill/ ├── SKILL.md ├── scripts/ │ └── validate.py ├── templates/ │ └── report-template.md └── references/ └── style-guide.md其中 SKILL.md 是入口头部有一段 YAML 格式的元信息下面是正文--- name: frontend-component-generator description: 生成符合项目规范的前端组件包含样式、测试、Storybook 示例。 --- 当用户要求创建新组件时按以下步骤执行 1. 先读取 references/component-patterns.md 2. 在 src/components 下按 PascalCase 命名...为什么说它“可执行”因为这些步骤不是写给人看的建议而是模型会被要求逐条遵守的操作指令。更关键的是整个目录里还可以放脚本。模型在完成代码生成后可以自己跑一遍校验脚本检查生成的组件是否满足规范。出错就自动修修完再跑直到通过。这种设计解决了一个根本问题模型上下文窗口是有限的你没法把一百个技能的所有细节一股脑塞进去。平时每个技能只暴露一段描述等 Agent 判断“这个任务可能需要它”的时候才把完整手册加载进来。这就好比一个大型公司不会让所有员工背诵全部 SOP而是每个岗位只保留自己的那份流程手册接到对应工单才翻开看。1.3 为什么“superpower skills”突然这么火GitHub 上出现了一批高星项目名字都起得很张扬最常见的标签就是 superpower skills。我观察到的原因有三个第一工具链终于支持了。Claude Code、Codex、OpenCode 陆续开放了自定义技能目录社区立刻跟进各种技能包呈井喷式增长。以前“给 AI 装技能”只是个概念现在复制一个文件夹进去就能用。第二真实收益太明显。前端开发场景里一个团队把组件规范、代码 review 要点、提交信息格式做成 skillAI 生成代码的一次通过率肉眼可见地提高数学建模场景里赛题数据处理、论文排版这些“不聪明但繁琐”的活技能包能做到标准化交付。效率提升一倍不夸张自然口口相传。第三分享门槛足够低。一个 skill 本质上就是一个带说明文档的目录GitHub 上 clone 下来就能用改起来也简单。于是出现了大量“常用 skills 源网站”、聚合仓库、各类榜单还有人专门做“skills 网页版进入”让你在浏览器里直接浏览技能介绍和安装命令不用先把仓库拉下来再翻文件。生态一旦滚起来热度就很难降下去。2. 先把现成的 Skills 用起来安装与引入2.1 技能包长什么样目录结构与 SKILL.md 规范不同工具的技能目录位置不太一样但装好之后你在命令行里看到的形态大同小异。这里拿 Claude Code 举例项目级技能放在.claude/skills/下用户级技能放在~/.claude/skills/下。Codex 对应的是.codex/skills/或~/.codex/skills/OpenCode 则是.opencode/skills/或~/.config/opencode/skills/。目录里的核心就是 SKILL.md。我建议第一次接触技能的人先找一个现成仓库打开 SKILL.md 看看比读任何教程都直观。里面通常分两块头部的元信息负责“给 Agent 看”正文的步骤和示例负责“给 Agent 用”。--- name: math-modeling-report description: 用于数学建模竞赛论文的框架生成、公式排版校验与图表规范检查。当用户提到建模报告、论文排版、公式规范时使用。 ---description 这块千万别小看它是整个 skill 能否被正确调用的关键。Agent 不是每次对话都把每个技能完整读一遍它只是快速扫描所有技能的 description然后做匹配。你描述写得含糊它可能该用的时候没用描述里塞满无关关键词它又会不该用的时候乱用。2.2 手动安装 GitHub 上 Skills 的两种方式总有人问“claude code 怎么手动装 github 上的 skills”其实核心就两步找到技能目录复制到正确位置。最直接的方式是先把整个仓库 clone 下来再把其中某个技能目录复制过去git clone https://github.com/username/awesome-skills.git # 查看仓库里有哪些技能 ls ./awesome-skills/skills/ # 安装到用户级目录所有项目可用 mkdir -p ~/.claude/skills cp -r ./awesome-skills/skills/frontend-component ~/.claude/skills/ # 如果你只想在某个项目里用可以放到项目级目录 mkdir -p .claude/skills cp -r ./awesome-skills/skills/frontend-component .claude/skills/Codex 和 OpenCode 的安装逻辑几乎一样只是路径名不同。# Codex 全局目录 mkdir -p ~/.codex/skills cp -r ./frontend-component ~/.codex/skills/ # OpenCode 项目级目录 mkdir -p .opencode/skills cp -r ./frontend-component .opencode/skills/第二种方式适合只想要某一个技能的情况直接在 GitHub 网页上进入那个技能的目录逐个文件复制粘贴。虽然啰嗦但如果你用的是公司内网环境、不方便 git clone 外部仓库这种手动复制反而是最稳的。复制的时候注意保留目录结构别把 SKILL.md 直接丢到 skills 根目录底下那样技能名会丢失Agent 扫描的时候会犯迷糊。还有一个容易踩的坑很多技能包会带 scripts 目录里面是 Python 或 Bash 脚本。复制到本地后如果脚本没有执行权限Agent 调脚本时会直接报错。装完技能之后记得给相关脚本加权限chmod x ~/.claude/skills/frontend-component/scripts/*.py chmod x ~/.claude/skills/frontend-component/scripts/*.sh2.3 安装后验证与权限设置装完不是就完了一定要验证。Claude Code 里直接输入/skills会列出当前所有可用技能Codex 通常可以在启动日志里看到它扫描了哪些目录也可以直接在对话里问“你现在有哪些技能”。如果列表里没出现你刚装的技能先别急着怪工具按这个顺序排查目录路径是不是放错了层级技能目录必须直接放在 skills 根目录下不能再套一层文件夹。SKILL.md 是不是放对了位置文件命名不能变。YAML 头部是否完整name 和 description 是必须字段缺一个就可能被静默忽略。是否已经重启会话技能扫描一般在会话启动时加载。权限这块多说一句给 Agent 技能本质上是授予它一套“自动化操作权限”尤其是带脚本的技能相当于让 AI 能在你的机器上执行代码。从可信仓库下载的还好来历不明的技能包建议先打开 SKILL.md 和 scripts 目录里的脚本看一遍再装。这不是危言耸听技能描述写得再漂亮脚本里要做坏事你也拦不住。2.4 常用 Skills 源网站推荐GitHub 是目前技能包最集中、更新最勤的地方。你可以直接搜“awesome claude skills”“awesome codex skills”或者看社区维护的聚合仓库。我常用的几类来源通用聚合型仓库一个仓库收录几十上百个技能分类清晰适合初学者批量浏览。比如有些仓库会按“前端开发 skills”“数学建模 skills”“写作与翻译 skills”做目录分组。场景专精型仓库比如专注于前端工程化的 typesafe ai skills 这类 GitHub 项目里面技能偏 TypeScript、类型安全、组件规范适合工程团队直接引到项目里。网页版技能库现在不少项目做了“skills 网页版进入”的体验浏览器打开就能看到技能卡片、描述、标签和安装命令比翻 GitHub 目录方便得多。这类站点通常也支持搜索直接搜“前端开发 skills”就能筛出来。我自己的习惯是先看网页版或 README 里的技能列表锁定三五个再单独 clone 仓库看细节。不建议一口气装几十个技能后面我会专门说清理的事但这里先提一句技能不是越多越好你的 Agent 每次启动都要扫描所有技能描述装得太杂反而增加匹配误差。3. 分场景挑 Skills前端开发、数学建模、AI 漫剧3.1 前端开发 Skills把重复劳动交给 Agent前端是目前技能包生态最繁荣的场景之一原因很现实前端规范多、样板代码多、重复劳动多。一个组件从创建到验收涉及命名风格、目录位置、样式方案、测试断言、文档示例每个环节都有大量“约定俗成”的规则。这些规则靠嘴说AI 记不住写进技能里AI 才能严格执行。我在项目里实际用过的前端技能大致分几类组件生成类读取项目已有组件风格再按同样风格生成新组件。迁移重构类把旧的 class 组件改写为函数组件把 CSS 迁移到 CSS Modules批量替换 API 调用方式。质量保障类检查是否缺少 key、是否存在隐式 any、样式是否使用了被禁用的属性然后自动修复。协作规范类根据 git diff 生成符合团队模板的 PR 描述、根据提交信息规范生成 commit message。这类技能的共通点是“绑定项目规范”。一个从 GitHub 上直接拉下来的通用组件生成技能到了你的项目里未必好用因为它不知道你们团队的目录结构、不知道你们用的是 Tailwind 还是 styled-components。真正好用的做法是拿社区的技能包当模板把 references 目录里的规范文件替换成你们项目自己的文档把 examples 换成真实代码。我试过几次替换之后 AI 生成代码的贴合度能上一大截。3.2 数学建模 Skills从数据分析到论文成稿的加速器数学建模可能是“用技能收益最大”的场景之一因为整个流程高度标准化从拿到赛题到最终论文提交中间要经历数据分析、模型选择、参数调优、可视化出图、公式规范化、论文排版每一步都有固定套路。这些套路正好适合沉淀成技能包。我身边参加竞赛的朋友包括被华为杯等比赛虐过的人现在基本都会准备一个 codex 技能包里面至少包含下面几个模块赛题拆解拿到题目后自动提取问题层次、列出假设条件、梳理数据字段。数据清洗检测缺失值、异常值、量纲差异生成清洗报告。模型速选根据数据类型和目标函数推荐候选模型并用交叉验证做初步对比。论文框架生成标准论文大纲把图表编号、公式编号、参考文献格式固定好。图表规范输出统一风格、统一字体、带标题和图例的图表。这类技能写起来有个特点数学建模涉及的模型 library 更新很快技能里不要写死“用哪个版本、哪个函数”而是写“先尝试哪些方法、按什么指标比较、怎么输出结果表”。把判断力留给模型把流程固定交给技能。如果你不想自己从头写GitHub 上搜“数学建模 skills”能找到不少现成的。安装后先拿一套往年赛题数据跑一遍把不贴合你习惯的步骤改掉。基本上改一版之后后面每次拿到新题目AI 都会自动进入那条熟悉的流水线。3.3 AI 漫剧与内容创作 Skills风格统一才是王道AI 漫剧是最近很热的内容创作方向这类作品的制作链条很长角色设定、分镜脚本、画面生成、对白配音、后期剪辑而且最大的痛点是“风格一致性”。同一个角色这一集长这样下一集可能就换脸了同一个场景换个模型参数氛围就全变了。Skills 在里边能干的事是把“风格约束”做成一个可复用的技能包。比如说你写一个角色一致性技能目录里可以放角色卡角色外貌、服装、语气、口头禅、风格词表固定的画风关键词、调色倾向、光影描述、分镜模板景别、运镜、转场规则、对白风格示例。这样一来无论哪一集、哪个阶段AI 在生成或检查内容时都先加载这套规范输出的东西才不至于东一榔头西一棒槌。内容创作类技能还有个特殊用法反推。很多创作者会把自己过往爆款作品的关键词、镜头语言、台词节奏整理成参考文档塞进技能包让 AI 在创作新内容时先学习旧风格。这比我手动写一百句“注意保持风格统一”有效得多因为风格是抽象的模型需要靠具体范例来理解而不是靠空泛的形容词。坦白说内容创作类技能到现在还没有统一标准社区里“AI 漫剧常用 skills”这类分享也多是各家用各自的经验拼出来的。我的建议是别指望找到一个现成技能包就能搞定期望的效果把它们当成起点往里填入你自己的角色卡和风格样本慢慢迭代。4. 写一个属于自己的 Skill从零到可用的完整流程4.1 设计 Skill 的边界先想清楚“给谁用、解决什么”我见过很多第一次写技能的人上来就想做一个“万能助手技能”什么都能干结果写完发现 Agent 根本不知道该在什么时候用它。写技能跟写函数是一个道理职责单一边界清晰。动手之前先回答三个问题这个技能只在什么时候触发它替用户省掉的是什么工作它的输入和输出分别是什么举个例子你想写一个“前端技能”最好拆成“React 组件生成”、“样式迁移”、“PR 描述生成”三个技能而不是写一个“前端全能技能”。因为 Agent 是按描述匹配的职责越聚焦匹配越精准。另外技能不是越详细越好。SKILL.md 正文里堆砌八百行指令模型未必都能记住。更合理的做法是写清楚步骤框架、关键约束、验收标准把细节放进 references 目录由模型按需读取。一句话正文给主流程参考文件给细节。4.2 目录与文件组织以及一个可直接改的模板一个最小的技能目录只需要一个 SKILL.md但为了好维护我习惯按下面这种方式组织format-report/ ├── SKILL.md ├── templates/ │ └── report-template.md ├── examples/ │ └── good-example.md └── scripts/ └── check_format.pySKILL.md 基本长这样--- name: format-report description: 将杂乱的数据分析结果整理成结构化的报告。适用于数学建模、数据分析项目中的结果汇总和排版。 --- # 报告格式化技能 ## 触发条件 - 用户要求“整理结果”“生成报告”“格式化输出” - 用户提供了一堆表格、图表或统计结果 ## 执行步骤 1. 读取 templates/report-template.md 中的报告结构。 2. 将用户提供的数据填入对应章节。 3. 所有表格必须包含表头、单位、数据来源。 4. 所有图表引用必须使用“图1: 说明文字”的格式。 5. 跑一遍 scripts/check_format.py检查是否遗漏必填字段。 ## 注意事项 - 不要修改用户原始数据只调整呈现格式。 - 如果数据缺失标注“待补充”不要编造。这个模板可以直接复制改。你会发现最核心的东西其实就三块触发条件、执行步骤、注意事项。触发条件写得好不好直接决定了 Agent 会不会“主动抄起”这个技能。4.3 打磨细节描述、参数、示例缺一不可description 是最容易被低估的部分。你写“用于报告生成”看似没问题但 Agent 面对“把这段数据整理一下”这种模糊请求时未必会联想到这个技能。更可靠的写法是带具体触发词“当用户提供数据集并要求整理、汇总、输出结构化报告时使用。适合数学建模、数据分析场景。”让描述跟真实对话用语贴近匹配率才会高。examples 目录也有大作用。模型擅长从示例里学模式光靠文字指令描述“好的报告长什么样”不如直接扔一个优秀范例。我第一次写技能的时候没有放 examplesAgent 生成的模板总差点意思放进两个范例之后输出质量肉眼可见地提升。后来我把这条经验用在了所有技能上凡是涉及格式要求的技能必须带“好例子”和“坏例子”。参数这块大多数技能其实不需要搞复杂的参数声明。模型能从对话上下文里推断出大部分信息比如文件路径、目标语言、输出格式。不要为了“看起来专业”硬设计参数徒增使用门槛。4.4 调试与迭代本地跑通再考虑共享技能写完一定要实测。测试方法很简单开一个新会话只加载这一个技能拿一个真实任务让它跑一遍。重点看三件事技能有没有被触发、执行步骤有没有被完整遵守、输出是否符合预期。调试过程里最常遇到的问题就是“技能没被触发”。排查思路是先看 description 是否包含用户可能说的词其次看技能目录路径是否正确。有时候 Agent 加载了很多技能匹配分数被稀释这种情况下可以适当把 description 里无关的词删掉让它更聚焦。迭代方面给技能目录挂个 git 仓库是我强烈推荐的做法。技能是会演化的你可能今天加一条新规范明天改一个模板。没有版本管理改坏了想回退都难。放到 Git 仓库里每次修改都有记录等稳定之后还能分享到 GitHub 上变成你个人的“常用 skills 源网站”里的一个条目。5. 避坑指南Skills 使用与维护中的真实问题5.1 常见问题速查表我把实际使用中遇到的典型问题整理成了一张表方便你快速定位现象可能原因解决思路技能完全没触发description 与任务描述不匹配重写 description加入真实对话用语技能触发了但执行步骤不完整正文步骤太长、模型上下文被挤占精简正文把细节移到 references多个技能同时触发、互相干扰技能职责重叠或描述关键词相近合并同类技能或删除低质量技能脚本执行时报权限错误复制后丢失可执行权限chmod x 脚本文件安装后 /skills 列表里看不到目录层级多套了一层保证技能目录直接位于 skills 根目录下新装技能不生效会话启动时没有重新扫描重启会话再试技能描述里的中文匹配差部分工具对中文分词不友好在 description 里同时写中文和英文关键词这里特别说一下中文匹配问题。Claude Code、Codex 这类工具描述匹配底层大多依赖向量检索或关键词打分中文分词效果确实不如英文稳定。我处理的办法是description 里先用中文写清楚触发场景再补一句英文关键词比如“用于数学建模报告整理math modeling report formatting”。这样无论模型用什么匹配策略命中概率都会更高。5.2 清理与更新skills 用久了会“脏”网上有人分享过“tibo 关于清理 skills 的方法推荐”说白了就是定期给技能库做减法。我自己的经历也印证了这个必要性技能装多了之后启动扫描时间变长匹配容易串味该用的技能反而不被触发。清理思路只有一条让 Agent 每次加载技能时面对一个精简、高相关的集合。我习惯每两周做一次全量检查。先列一下所有已安装技能看看哪些在过去两周根本没用上果断删掉。保留的技能再看一眼 description 是否还符合现在的项目风格不符合就改。最后把正在使用且足够稳定的技能做一次版本归档方便回退。这里给一个简单排查脚本可以快速列出每个技能的核心描述find ~/.claude/skills -name SKILL.md | while read f; do echo $(basename $(dirname $f)) head -5 $f echo done跑完一遍哪个技能讲了什么一目了然。删之前注意一点团队共享的技能不要只改本地要做变更同步给队友否则你这边清理完了别人那边还在用老版本同一个项目里 Agent 行为不一致埋雷。5.3 我的几条实操心得先交代背景我日常主要用 Claude Code 写前端项目用 Codex 跑数学建模相关任务OpenCode 作为轮换工具。以下体会只代表个人经验但都是我实际踩过了坑之后才得出的。第一项目级优先于全局级。全局目录里的技能所有项目都能看到听起来很方便但跨项目的时候描述匹配容易乱。比如前端项目里最常触发的是组件生成技能你把它放到全局目录写后端代码的时候它也可能跑出来凑热闹。更合适的做法是全局目录只放跨领域通用技能比如“提交信息规范化”项目目录放这个项目专属规范比如“商城前端组件生成”。第二描述里要写“什么时候不要用”。很多技能作者只写了触发条件不写排除条件结果 Agent 在边界场景乱用。我在自己的技能模板里固定加一块“不适用场景”效果非常明显。第三技能要跟着项目走。项目代码在演进、规范在变化技能如果不更新很快会变成“一本过时的操作手册”。每次项目规范有调整时顺手改一改对应的 skill 文件不要攒到问题集中爆发再处理。第四尽量看官网或官方模板再写自己的。很多人写技能喜欢凭空臆想格式其实各工具对 SKILL.md 字段都有参考文档。照着官方示例写一遍再改内容比从零摸索省非常多时间。这个内容后续再做深挖的话可以往技能调试工具、技能质量评分、团队技能库共享平台这几个方向扩展。就我目前的使用体验来说skills 最迷人的地方不是“让 AI 变聪明”而是让 AI 的行为变得可控、可复制、可沉淀。一份好技能就是一个团队或一个人多年经验的实体化。它不像聊天记录那样被冲散也不像口头经验那样容易失真它会跟着你的项目一起迭代。先把一个最顺手的小技能写出来跑通一次你大概就能理解为什么社区里这么多人对这玩意儿着迷了。