最近大模型编程工具圈子里大家聊得最多的一个词就是skills。不是简历上那种“技能”而是指Claude Code、Codex、OpenCode这类AI编程助手能识别、能按需调用的“专项技能包”一个文件夹、一份SKILL.md、若干脚本和模板。我最早注意到skills是因为一个很简单的痛点——同一个项目里AI老是犯同样的错每开一次新会话就要把几十行规矩重新贴一遍费劲不说模型还经常把我的要求读歪。后来我把工作流里那些反复出现的任务从前端组件生成到数学建模赛题拆解都整理成了独立的skillsAI的行为一下就稳定了。这篇东西不是官方文档复读是我这几个月手动装skills、改skills、清理skills攒下来的一套实操经验适合正在用Claude Code、Codex或OpenCode又不想每次重复调教模型的朋友。1. 先把概念说透AI Skills到底是什么1.1 从“会聊天”到“会干活”Skills补齐了关键一环大模型本质上是一个“对话器”你给它一段话它回你一段话。但在真正的开发场景里我们要的不是漂亮话是它能独立完成“理解需求、查资料、改代码、跑测试、出结果”这一整条流水线。早期大家靠的是在系统提示词里塞超长一段“请你务必这么做”也就是CLAUDE.md那套思路。问题在于提示词越长模型越容易抓不住重点你塞了30条规矩它可能只记住前5条。Skills的思路完全不同。它把一套完整的工作方法打包成一个独立的目录模型平时不读它等遇到了匹配的任务才把这个“技能包”翻出来照着做。换句话说CLAUDE.md解决的是“你平时是什么风格”skills解决的是“遇到具体任务时该怎么干”。前者像公司墙上贴的价值观后者像工位抽屉里的岗位操作手册平时看不见碰到活才拿出来。1.2 Skills、Agent、MCP三者是怎么分工的很多新手把Skills和MCP、Agent混为一谈其实它们分工很明确。Agent是那个负责调度的“实习生”它决定下一步该调用什么MCP是给实习生配备的“工具箱”里面是一堆可以实时调用的外部工具比如读写数据库、访问浏览器Skills则是“操作手则”它不长得像工具更像一份带步骤、带范例、带脚本的说明书。举一个我实际遇到的例子。让Claude Code去爬一个公开网页并整理数据MCP给你提供抓取网页的接口Agent负责安排步骤而一个写好的“网页数据抽取skil”会告诉模型该用什么选择器、怎么处理反爬、列名怎么统一、输出JSON的格式是什么。没有这份说明书模型也能做但每次做出来的格式都随缘。有了它输出就稳定成同一套结构。这也是为什么现在越来越多人说“Skills是给大模型补经验的地方”。1.3 一个SKILL.md到底长什么样我见过不少朋友以为skills是某种魔法文件其实拆开看特别朴素。一个标准的skill目录长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── run.sh └── assets/ └── templates/核心只有SKILL.md这一个文件。它的开头是一段YAML格式的元信息主要写name和descriptiondescription里必须说清楚“什么场景下该用这个skill”。后面正文就是给模型看的操作指南工作流的步骤、要注意的坑、输入输出的格式要求、甚至附上几条输入输出范例。模型怎么决定用不用这个skill靠的就是description。你写“当用户需要生成一个React组件时使用”模型遇到相关请求就会自动加载。这就是为什么我在下面第二部分花了不少篇幅讲安装路径因为路径放不对模型根本扫不到你的skills。2. 手动安装GitHub上的Skills完整实操流程2.1 先搞清楚Skills会被放在哪不同工具读取skills的路径不一样但大逻辑一致要么放在用户全局配置目录要么放在项目目录。以Claude Code为例我实测下来项目级别的目录是.claude/skills/全局的是~/.claude/skills/。放在项目里意味着只有这个项目能感知到放在全局则所有项目都能用。我的建议是和具体业务强相关的放项目里比如某个比赛的建模流程通用能力放全局比如代码审查、commit message生成。Codex那边社区通常放在~/.codex/skills/或项目下的.codex/skills/OpenCode也有类似约定不过我用的版本不同不同版本对目录名的识别会有点差异。最稳妥的办法是看对应工具的官方文档里关于“skills”或“agents”目录的说明别照搬网上的教程路径踩过这个坑之后你就会长记性。2.2 手动安装一个GitHub skills包的详细步骤假设你在GitHub上找到了一个想用的skills仓库手动装其实就三步下载、放对目录、验证。第一步是克隆仓库到本地。我习惯先建一个临时中转区不直接克隆到最终位置因为很多仓库里塞了README、图片、多余示例直接拖进去会让目录变乱。命令大致是这样git clone 仓库地址 /tmp/awesome-skills第二步是挑选需要的skill目录。很多聚合仓库不像单个skill项目那么干净里面可能有几十个技能。我只复制自己需要的那个目录到Claude Code的skills目录mkdir -p ~/.claude/skills cp -r /tmp/awesome-skills/frontend-code-review ~/.claude/skills/第三步是重启会话并验证。Claude Code通常只会在会话启动或者执行重载命令时扫描skills目录。验证方法很简单在对话里描述一个你希望触发该skill的任务看模型是否给出了严格按照SKILL.md步骤走的回复。有些工具的界面还能直接列出现有skills如果你的工具支持看一眼列表比对话试更省事。2.3 安装后不生效大概率是这三个原因第一个原因就是路径不对。你把skill放到了.claude/skill而不是.claude/skills差一个字母模型就完全看不见。第二个原因是SKILL.md的frontmatter写错了最常见的是YAML开头少了三个横杠或者description写得太泛模型根本不知道什么时候该调用它。第三个原因是没重启会话模型的上下文里还没刷新skill列表。还有一个很容易被忽略的坑目录嵌套别搞太深。我看到过有人把skill放成skills/frontend/setup/code-review/SKILL.md以为自己组织得很清楚结果模型按一层目录去扫描只扫到了第一层里面的skills全废了。保持每个skill直接放在skills目录下的一级子目录别套娃。2.4 Codex和OpenCode安装上的差异Claude Code的skills生态相对成熟Superpowers这一类聚合仓库装完就能用。Codex那边的情况不一样因为OpenAI的Codex CLI早期并没有把skills当成正式功能社区里多是靠自定义指令文件模拟出来的。后来陆续有人整理了codex-skills这样的项目让Codex也能识别SKILL.md。安装方式大同小异关键点是配置里要把skills目录的扫描路径明确指出来否则模型不会自己去找。OpenCode则更折腾一些我记得当时装一个模块化skill还得在配置文件里注册路径。如果你主要在OpenCode里用我的建议是优先选择专门为OpenCode设计的skill包比如社区里那些带opencode.json声明文件的不要硬塞Claude Code生态的包。不是说不能互用而是说明书格式和触发机制有细节差异硬上的结果往往是模型看得见却用不对。3. 我实测过留得下来的Skills按场景逐个说3.1 前端开发Skills从组件生成到代码审查前端是skills应用最成熟的领域之一。我留了两个一个叫“组件工厂”一个叫“提交前审查”。组件工厂这个skill解决的是重复劳动问题。过去让AI生成一个表格组件每次都要在提示词里写“要用TypeScript、要带loading态、要写测试”。现在这个skill的SKILL.md里把这些约束全部固化下来description里写的是“当用户要求创建或重构一个前端组件时使用”。每次会话里只需要说“给用户列表页生成一个支持筛选的表格组件”模型就会自动读取skill里的规范按照约定的组件结构、样式方案和测试标准来写。提交前审查则解决的是质量一致性问题。它的工作流很固定先读取暂存区diff再对照项目里的代码规范逐项检查最后输出一份带优先级的修改建议。装上之后我commit之前都会让模型跑一遍发现过不少遗漏的console.log和未捕获的错误。3.2 数学建模与竞赛Skills华为杯这类比赛怎么用数学建模是我近期投入比较多的场景尤其是华为杯、国赛这类竞赛。比赛时间紧、任务重核心流程就那么几段读题拆解、数据清洗、模型选型、求解实现、论文排版。这里面每一步都有大量重复性工作非常适合用skills固化。我实际用下来最有价值的是“赛题拆解”和“数据清洗”两个skill。赛题拆解skill会引导模型把一道大题目拆成若干个子问题为每个子问题标注可能的模型类型和数据需求输出一张结构化的问题清单。这个动作很多人靠脑补但一旦比赛现场脑子一团浆糊清单就是救命稻草。数据清洗skill则固定了一套标准操作缺失值处理策略、异常值识别阈值、特征分布检查、清洗报告模板所有操作都有章可循。另外一个很好用的场景是Codex CLI配合建模skills跑实验。华为杯那类题目经常要试多种模型对比效果。Codex的编码能力强再配上建模skill告诉它“数据长什么样、结果要什么格式”它能快速地跑出一组对比实验省掉的都是最宝贵的调试时间。还有团队里的同学把LaTeX排版做成了一个skill模型直接按论文模板生成章节内容排版问题几乎绝迹。3.3 AI漫剧常用Skills拆脚本、画分镜、保一致性AI漫剧是最近短视频平台上很火的内容形态纯用AI生成漫画式连续剧。这种创作最大的痛不是画得不好看而是“一致性”。同一个角色上一集是黑色长发下一集可能就变成棕色短发观众立刻出戏。社区里针对这个问题已经积累了不少skills核心思路是把“角色描述卡”固化成文件每张图生成前都强制读取。一个完整的AI漫剧工作流我拆开看至少需要四个skill脚本拆解skill负责把一段小说或文案转化成带镜头编号的分镜脚本角色设计skill负责生成每个角色的详细外貌描述包括发型、瞳色、服装、标志性特征出图参数skill负责统一画面比例、风格标签和负面词审核比对skill负责在批量生成后抽出关键帧做角色一致性检查。这四个skill串起来之后整个漫剧生产线就稳定了。我见过有人把分镜脚本的模板和出图prompt模板都塞进skill的assets目录里每次生成时模型自动读取模板填充内容这样出来的片子哪怕不同批次的图风格也保持在同一个调子上。3.4 通用效率类Skills清理、重构、复盘除了业务相关的skills还有一类通用skills值得装。我留了两个代码清理和任务复盘。代码清理skill严格干三件事删除没用到的变量和引用、清理注释掉的死代码、统一日志和错误处理风格。每次大功能上线前跑一遍胜过请人做代码审查。任务复盘skill是我的记录习惯。它会在一次会话结束后自动提取做了哪些事、遇到了什么问题、最后怎么解决的生成一份简报追加到项目日志里。这个skill的SKILL.md特别短但description写得很精准“当用户要求总结本次会话或记录工作日志时使用”。装了之后我再也不用手写周报了日报素材全靠它。4. 没有现成的就自己写AI Skills开发全流程4.1 开发Skills的通用套路先看别人的SKILL.md这是最快的学习路径。打开任意一个开源skills仓库你就会发现它本质上就是一份写得特别好的操作手册好到模型看了不会跑偏的程度。自己写时抓住一个核心每个skill只解决一类任务description里把触发场景写得非常具体宁窄勿宽。结构上我建议遵循老套路先说什么时候用再说怎么做最后给范例。SKILL.md正文里第一步永远是“读取并确认输入”因为模型很容易自作主张假设输入第二步才是真正的处理步骤尽量用编号列表一步是一步别让模型跳步第三步是输出格式明确要求JSON还是Markdown还是表格。如果涉及脚本就把脚本放到scripts目录里并在正文中告诉模型“遇到什么情况时执行哪个脚本、传什么参数”。4.2 手写一个“数学建模竞赛”Skills的实操记录我拿最近的建模训练赛举例现场写了一个叫“math-pipeline”的skill你要写可以直接抄这个骨架。目录结构很简单.claude/skills/math-pipeline/ ├── SKILL.md └── scripts/ ├── clean_data.py └── generate_report.pySKILL.md内容我是这样组织的--- name: math-pipeline description: 当用户提供赛题或数据文件并要求进行数学建模分析、数据清洗、模型选型或论文写作时使用。尤其适用于华为杯、国赛等竞赛场景。 --- # 数学建模流水线 ## 何时使用 - 用户给出赛题文本要求拆解问题 - 用户给出数据文件要求清洗或探索 - 用户需要比较多个模型并输出结果 - 用户需要生成论文摘要或建模章节 ## 执行步骤 1. 读取所有输入文件输出问题拆解清单 2. 运行 scripts/clean_data.py保存数据质量报告 3. 基于数据报告选择候选模型对比至少两个方案 4. 输出结果表和图表图表统一使用论文风格配色 5. 按需调用 scripts/generate_report.py 生成LaTeX片段 ## 输出约定 - 问题清单使用有序列表标明优先级 - 结果对比使用Markdown表格 - 图表统一存放至 output/figures/写的时候最难的部分不是格式而是让模型“不跳步”。我一开始没在步骤里强调“必须运行脚本”结果模型自认为做了清洗实际数据一点没动。后来加了“必须运行clean_data.py并把输出报告粘贴到对话里”这句行为就老实多了。这就是我常说的模型默认走捷径你得在SKILL.md里把捷径封死。4.3 学习Skills开发怎么进阶如果从零开始学怎么开发skills我的建议是螺旋式前进先原样装一个成熟skill跑通流程第二步打开它逐行读SKILL.md把不理解的地方标注出来第三步尝试改description里的一个触发词观察模型在什么情况下会调用它第四步把自己写的一份工作流哪怕只是“每周写周报”这样的流程整理成自己的第一个skill。进阶的关键在于收集“模型犯过的错”。每次它没按你预期做事其实都是SKILL.md里缺了一句约束。把这些错误作为反馈写进skill里你的skill会越迭代越稳。一个skill从v1到v3往往不是新增了多少功能而是堵住了多少个坑。5. Skills管理和清理装多了之后的真实体验5.1 装多了是什么感受模型反而变“笨”如果你也像我一样看到GitHub上热门的skills就克隆进目录很快会面临一个问题模型被一堆skill搞糊涂了。你装了10个skilldescription写得又模糊模型在你提出请求时会对到底调用哪个拿不准最坏的情况是它把所有相关skill都加载一遍上下文被瞬间塞满回答质量直线下降。我经历过一次特别典型的事故我同时装了“代码重构”和“组件生成”两个skilldescription里都提到了“生成代码”这个关键词。结果让模型写一个新组件时它先按重构skill把现有代码清洗了一遍又按组件skill重新生成两套逻辑互相打架输出一团糟。从那以后我学乖了skills不是越多越好而是越清晰越好。5.2 tibo式清理思路按产出物类型归类技术博主tibo分享过一个清理思路我看着很有共鸣不要按“工作流名称”去整理skills而要按照“产出物类型”来梳理。比如你的skills产出物是代码、文档、图片参数、日志这四类那就检查每个skill最终交付的是不是某一类产出物。如果一个skill的产出物含糊不清说它既能生成代码又能写文档说明它不聚焦要么拆开要么删掉。我按这个思路做了一次大清理把原本28个skill删到9个。删除的原则很简单过去30天没触发过的先归档description里出现两个以上触发场景的拆成多个或合并精简发现有相同功能的重复skill只留描述更精准的那个。清理完明显的变化是模型响应更快而且调用skills的准确度提升了一大截。5.3 常用的Skills源网站和仓库整理不管装还是找知道去哪找都很关键。我常逛的几个地方简单整理成一张表方便你按图索骥来源特点适合找什么Superpowers聚合库社区人气高更新活跃覆盖领域广通用能力、前端开发、自动化流程Awesome-claude-skills按领域分类的精选清单快速检索某一领域的skillTypesafe AI skills偏向TypeScript/类型安全生态前端、全栈工程化skillCodex-skills相关仓库专门适配Codex CLICodex环境下的建模、代码生成各工具官方社区/讨论区作者直接发帖质量参差但最前沿新发布的skill、Ecosystem动态数学建模/科研类的开源包竞赛后用爱发电分享建模流程、论文排版skillGitHub上的搜索也别只会用关键词。我常用的搜索方式是“claude skills 数学建模”“codex skills 数据清洗”“opencode skills 前端”比搜“skills”有效得多。还有一点经验下载前先看仓库最近有没有更新长期不维护的skill大概率跟新版工具不兼容。6. 常见问题与排查技巧实录6.1 一张表和几个亲测有效的排查方法我把自己和身边朋友踩过的坑汇总成了一张问题速查表按这个去排查基本都能解决现象可能原因排查/解决办法模型完全不理会skill路径不对或目录嵌套过深确认放在.claude/skills/下的一级子目录skill内容被加载但没按步骤做SKILL.md里步骤太模糊改成强制性的编号步骤明确要求“必须执行”两个skill经常混乱调用description触发词重叠精简description明确边界上下文总是被skill内容占满装得太多清理低频skill或把通用skill移出项目目录同一个skill这次生效下次失效会话未重启或缓存未清重启会话必要时重新加载配置SKILL.md里写了脚本但没执行脚本权限或路径问题检查scripts目录权限并在正文写清执行方式中文路径下读取异常路径编码兼容性问题一律使用英文目录名避免中文/空格排查时我有个习惯让模型自己报一下“你目前可用的skills列表”。能列出来说明加载没问题列不出来就从目录扫描和配置入手。这个操作比反复试对话高效太多。6.2 我给新手的三个配置建议如果你准备在自己的工作流里正式引入skills我有三个建议。第一先从一个和业务强相关的skill开始别一上来就追求覆盖面一个能解决真实痛点的skill带来的价值远大于十个泛泛的skill。第二在description里写触发场景时一定要用工具体系里的术语比如“组件”“模型对比”“分镜脚本”这些需要精确免得描述模糊引出错误调用。第三定期清理。我给自己定的规矩是每个月的最后一天过一遍skills删掉不再用的顺手更新一把那些长期没更新的老skill。6.3 最后分享一个自己的小技巧写SKILL.md的时候在正文末尾固定加一个“反例”小节专门记录“不要怎么做”。比如建模skill里写上“不要在没有运行清洗脚本的情况下直接拟合模型”前端组件skill里写上“不要生成没有测试文件的组件”。大模型对“不要做什么”的记忆效果往往比“要做什么”更深刻。这在经验里反复验证过靠这一条我那些skills的稳定性又上了一个台阶。说穿了skills就是一个把你自己踩过的坑、验证过的方法原原本本交给AI去执行的容器。多装、多用、多改时间久了你会发现它比任何花哨的Agent框架都来得实在。