开篇先说实话skills这个词最近在AI编程圈子的刷屏程度几乎要赶上大家讨论模型本身了。从Claude Code到Codex从OpenCode到一堆IDE插件所有人都在聊“给AI装技能”。我带团队做AI辅助开发时也花了不少时间折腾skills踩过不少坑后来慢慢总结出一套自己的方法论。这篇就系统梳理一下它到底是个什么东西、去哪找、怎么装、怎么写、以及在数学建模、前端开发、AI漫剧这些真实场景里怎么用。你不用有任何心理负担哪怕完全没接触过skills只要用过ChatGPT或者Claude跟着往下走很快就能在本地把这套东西跑起来。1. 先搞清楚一件事AI编程助手里的skills到底是什么1.1 从“会聊天”到“会干活”skills解决的是复用问题很多人第一次接触skills都会觉得“这不就是提示词吗”。一开始我也这么想但实际用下来差别大了。普通提示词的问题在于每次对话都要重新灌输一堆背景和规则既啰嗦又不稳定。今天你告诉AI“我们要用Vue3TypeScript组件命名用PascalCase”明天新开一个会话它又忘了你还得重新说一遍。skills的本质是把这些“显性指令”沉淀成一份可以被AI自动识别、主动加载的能力包。它不只是几行提示词它可能包含一份SKILL.md说明书、一堆参考资料比如团队编码规范、组件库文档、甚至配套的脚本和模板。当你的任务命中某个skill的描述范围AI会自动读取这个包从而表现得像个“懂行的专家”而不是“一个通用聊天机器人”。我经常跟团队打一个比方普通LLM是刚毕业的大学生聪明、学得快但什么领域都很浅装了skills的LLM等于这个大学生入职之后先拿到了公司的SOP手册、往期项目文档、还有一套趁手的工具链。解决问题的起点完全不一样。1.2 skills、插件、MCP这三兄弟到底什么关系这是新手最容易绕晕的地方。Claude Code有插件plugins、有MCPModel Context Protocol服务器现在又有个skillsCodex有自己的agents与skills概念OpenCode也有skills registry。它们之间到底怎么区分我自己的理解分三层Skills是“说明书知识库”它改变AI“懂什么”。比如你给AI一个“数学建模国赛”skill它就知道比赛论文的框架、常用算法库、图表规范。MCP是“工具连接器”它改变AI“能调用什么”。比如给AI接一个数据库MCP它就能直接查表、跑SQL接一个浏览器MCP它就能自动打开网页操作。插件是“系统级扩展”它改变的是工具本身的宿主能力比如给Claude Code加自定义斜杠命令、Hook脚本、权限策略。插件可以包着skill也可以包着MCP客户端。所以skills不是MCP的替代品两者是不同维度的事情。用一个不太严谨但很好懂的类比skill是给AI“补脑”的MCP是给AI“接手脚”的。一个完整的智能工作流往往既需要skill来定义怎么干活也需要MCP来把手伸进你的项目、数据库、浏览器里。2. 生态盘点哪些skills值得装去哪儿找怎么挑2.1 当前值得关注的几类高价值skills我在热词里看到有人专门整理“前端开发skills”“数学建模skills”“AI漫剧常用skills”这说明大家已经在按场景找技能了。按我自己调研和使用的情况目前最值得关注的有这么几类类别代表方向典型场景推荐指数编程开发前端规范、后端架构、代码评审让AI按团队规范产出代码★★★★★数学建模数据分析、模型选型、论文生成华为杯、国赛、美赛备赛★★★★★内容创作文案改写、分镜脚本、风格迁移自媒体、AI漫剧、短视频★★★★科研学术文献综述、论文润色、LaTeX排版学术写作★★★★通用效率周报生成、会议纪要、任务拆解日常工作流★★★我个人最喜欢的还是那种把一个“完整工作流”打包的skill。比如AI漫剧方向一个skill里同时包含剧本分段、分镜描述、画面风格的prompt模板、甚至配音断句规范这一套下来AI出品的稳定性远远超过你临时口头指挥。2.2 找skill的几个主要去处目前skills的生态还比较早期没有像npm那样的绝对中心化仓库但已经有几个“事实上的集散地”GitHub搜索直接搜skills、claude skills、awesome-claude-skills这类关键词。GitHub自带的搜索排序还算能用但最靠谱的还是看仓库的更新时间和issue活跃度。Anthropic官方仓库官方维护过一些示例skills比如PDF处理、docx生成、PPT制作等代码质量和文档规范程度都很高适合拿来当模板学习。awesome类聚合仓库社区里有很多人维护“awesome lists”把分散在各处的skill仓库汇总起来。这类仓库虽然良莠不齐但适合做前期地毯式扫货。OpenCode官方registry如果你用OpenCode它有一套自己的registry机制可以直接在命令行搜索、安装、管理skills体验上更接近“包管理器”。还有个小技巧看到某个项目的SKILL做得好直接去它仓库的references目录看看里面放了什么。这个目录往往才是skill的灵魂比那几百行说明文字值钱得多。2.3 怎么判断一个skill值不值得装GitHub上现在浮躁的东西很多一个仓库只要挂上“skills”字样星标蹭蹭涨。但star数唬不了我我判断一个skill能不能用就看四点更新时间AI技术迭代太快一年前的skill很可能已经失效。看仓库的最近commit时间超过半年没更新的谨慎。SKILL.md的结构真正能打的skill说明文件里一定有成体系的章节触发条件、使用范围、操作步骤、输出格式、注意事项。如果只是一段闲聊式的prompt那是来凑数的。参考资源的质量skill里如果带了references参考资料我会打开看看文档是否结构清晰、是否有版本标注、是否覆盖真实场景。这决定了AI“学到的知识”靠不靠谱。实测冒烟装完跑一个小任务看AI有没有被“激活”。这是最终标准。我见过太多看起来高大上的skill真正跑起来AI反而被一堆互相矛盾的规则绕晕。所以别贪多一个场景配一个高质量skill比装五十个垃圾skill强。3. 手动安装GitHub上的skills其实很简单3.1 装之前先确认你的工具兼容哪种skill格式很多人在第一步就卡住了原因是“装进去没反应”其实没反应过来不同工具加载skills的路径和格式都不一样。Claude Code目前最标准的手动方式是把skill目录放到个人配置目录下的skills文件夹并在.claude配置里声明路径。CodexOpenAI它更强调AGENTS.md机制但社区也发展出了specific skills等配套方案一般放在项目根目录下的skills目录。OpenCode支持通过registry命令安装第三方skills也支持把本地目录软链进去。其他工具像Cline、Roo Code等插件化的工具往往是通过plugin加载这时你需要的可能是“把skill改写为plugin”。我的建议是先确定主力工具再决定skill来源。否则你跟着一个Claude Code教程装了半天最后发现用的是Cursor那就很尴尬。3.2 以Claude Code为例一次完整的手动安装流程下面以“把GitHub上一个前端开发skill装到Claude Code”为例走一遍全流程。假设你要装的skill仓库叫frontend-dev-skills目录结构大概是frontend-dev-skills/ ├── SKILL.md ├── references/ │ ├── coding-standards.md │ └── component-patterns.md └── assets/ └── template.tsx实际操作分四步第一步把仓库拉到本地git clone https://github.com/yourname/frontend-dev-skills.git如果仓库里有多个skill子目录就只挑你要的那一个。第二步复制到Claude Code的skills目录Claude Code默认用户级skill目录在~/.claude/skills/。你可以直接复制也可以软链软链的好处是以后升级仓库很方便mkdir -p ~/.claude/skills cp -r frontend-dev-skills ~/.claude/skills/frontend-dev第三步确认配置文件打开~/.claude/settings.json确保有这样一个字段{ skills: { additionalDirectories: [ ~/.claude/skills ] } }如果没写AI根本不知道去哪找这个skill这是新手最容易忽略的地方。第四步启动会话验证触发重启Claude Code之后直接输入一个跟该skill描述相关的任务比如“帮我按项目现有规范写一个新的下拉组件”。正常情况AI会自动识别并为当前会话加载该skill表现为它会主动调用references里的规范文档而不是凭空发挥。3.3 装完不生效先把这几个坑排掉我遇到的“装完没反应”十有八九是以下几个原因路径不对skill目录放错位置或者配置里路径写错。软链时也要注意Claude Code解不了~符号建议写绝对路径。文件名大小写错误核心说明书文件必须叫SKILL.md全大写。你写成skill.md或Skill.mdAI认不出来的概率极高。目录结构不完整有些作者把skill打包成压缩文件解压出来嵌套了两层目录里面的SKILL.md被埋得太深也容易读取失败。metadata里的description写得差如果描述太泛或太烂比如“帮助用户”AI在当前任务里根本判断不出来该不该激活这个skill自然就不会加载。工具版本太旧我对部分旧版本工具测试过它们对skills的支持不完整。遇到这种问题先升级到最新版本再说。另外提醒一句装完skill之后当前会话最好重启一下。有些工具对配置的读取是启动时加载一次你在会话中途装好它不一定感知得到。4. 自己写一个skill从零手搓专属能力包如果你只用别人做好的skill那始终是在“租房”。真正能把自己工作方法沉淀下来的是自己动手写skill。这一步不难但有几个点值得认真打磨。4.1 先搭一个最小可用的目录结构一个最朴素的skill只需要一个文件夹加一个文件my-skill/ └── SKILL.md但如果是实战级别我建议用下面这个结构my-skill/ ├── SKILL.md # 核心说明书AI读取的主文档 ├── references/ # 参考资料放规范、文档、示例 │ ├── domain-knowledge.md │ └── examples.md ├── scripts/ # 可选放自动化脚本 │ └── generate_report.py └── assets/ # 放模板、图片、数据文件这个结构几乎是对标“一个人工智能体所需的最小知识库”来设计的。SKILL.md告诉AI“遇到什么事情、按什么流程处理”references提供“处理时需要的背景知识”scripts帮你把重复动作自动化。4.2 SKILL.md的正文到底怎么写才有效SKILL.md本质上是写给AI看的SOP文档不是给你自己看的。所以写的时候一定要以“AI理解成本最低”为原则而不是“我读起来觉得全面”。我常用的三段式结构是这样的--- name: frontend-dev description: 用于前端开发的技能。当用户要求编写、修改或评审 React/Vue 组件代码时使用。 allowed-tools: - Read - Edit - Bash --- # 前端开发技能 ## 适用场景 - 编写新组件 - 修复现有组件问题 - 执行代码评审 ## 工作流程 1. 读取项目根目录的 package.json 与 tsconfig.json确认技术栈。 2. 查阅 references/coding-standards.md匹配团队规范。 3. 输出组件代码遵循规范中的命名与目录约定。 ## 输出要求 - 组件文件必须包含Props类型定义。 - 样式必须使用CSS Module禁止全局样式污染。 - 提交信息遵循 feat(component): description 格式。 ## 示例 用户说写一个带搜索功能的下拉框。 AI操作先读取规范再输出SearchableSelect.tsx并附带测试用例。有几个经验性的细节description是触发开关写具体一点。别看它只有短短几句它是AI判断“当前任务要不要激活这个skill”的唯一依据。必须包含“用户提出哪类需求时会触发”不带这类关键词skill永远躺在那睡觉。工作流程里的步骤要让AI可执行不要用“根据最佳实践”这种空话。要写“读取哪个文件、执行哪个命令、输出什么格式”。代码示例few-shot是性能放大器。给一两个“用户怎么说、AI怎么拆解、最终输出什么”的元组比任何规则描述都有效。因为LLM对输入 - 输出的模仿能力极强示例就是最好的教材。不要超过300行。把大段的知识放到references里让SKILL.md保持“轻、准、结构清晰”。AI一次能“吃”的上下文有限SKILL.md就是目录和索引。4.3 references里放什么才叫给AI“补全知识”很多人以为references就是把文档一股脑塞进去结果AI加载后反而被各种互相矛盾的信息搞迷糊。我的经验是references里的文档要让AI“随手可取”那就要做适度处理每个文件聚焦一个主题别一个文件写“Everything about frontend”。文档开头写清适用范围比如“适用于React 18 TypeScript项目不适用于Vue项目”。目的就是避免AI误用。把结论写前面解释写后面。AI不是人没耐心从头读到尾把结论放前面它一眼就能抓住重点。在SKILL.md里用明确的指令引用它们比如“遇到组件设计问题先读取references/component-patterns.md”。光在references目录放文件还不够你得告诉AI“什么时候去读”。4.4 调试skill的方法怎么确认它真的生效了我在写skill时每次改完必做三件事简洁任务测试给AI一个完全命中description的简单任务确认它能被激活。比如写了“数学建模”skill就问“我有一份CSV数据帮我做一下相关性分析”。边缘任务测试给它一个模糊的、看似沾边但不完全命中的任务看AI会不会错误加载skill。如果误加载说明description写得过于宽泛。trace查看Claude Code里有trace日志官方也强调可以通过日志确认是否加载了对应skill。打开日志搜skill名称一目了然。调description是个细活。我第一次写完一个“周报助手”skilldescription里只写了“帮用户生成周报”结果AI有时候一个普通的“今天做了什么”都触发它。后来改成“当用户叙述本周工作内容并要求整理为结构化周报时使用”瞬间精准多了。5. 实测实录三个高频场景下的skills应用方案5.1 数学建模场景华为杯、国赛备赛期怎么配skill数学建模是热词里被点名的场景我就多说几句。比赛时间紧任务重光靠临时问AI“这个模型怎么解”绝对不够。真正好用的数学建模skill往往是一个“参赛工作流包”包含赛题拆解流程怎么从长问题背景中提取约束条件、目标函数、数据特征。算法库索引线性规划、整数规划、启发式算法、时间序列预测等常见算法适用范围和调用方法。论文模板摘要、模型假设、模型建立、求解、灵敏度分析、模型评价的标准框架。图表规范论文插图matplotlib/seaborn的尺寸、字体、配色要求。我自己给队员配的环境大致是math-modeling/ ├── SKILL.md ├── references/ │ ├── problem-analysis.md │ ├── algorithm-library.md │ ├── paper-template.md │ └── visualization-style.md └── assets/ └── sensitivity_template.py实测下来AI拿到这类skill之后最明显的变化是输出的论文章节结构直接可复用而不是“去网上搜一下”这种废话。而且每个队员独立开会话时都能复用同一套方法论队伍产出质量更稳定。我可以明确说这套打法在往届竞赛备赛时是压箱底的方法之一——当然比赛终究拼的是模型功底和解决问题的能力skill只是帮你把“打字、排版、套模板”的体力活省下来。5.2 前端开发场景让AI按照团队规范批量产代码团队里最头疼的事就是AI生成的代码风格跟人写的不一样。变量命名随意、组件文件乱放、样式写法五花八门。这个问题的解法正好是skills的强项。我在团队里维护了一个frontend-dev技能包结构大致如下references/coding-standards.md写清楚命名规则、组件职责边界、状态管理规范、目录组织方式。references/component-patterns.md沉淀了三四个高频组件的高质量实现模板Table、Form、Modal、Dropdown。scripts/create_component.py一个交互式脚本自动生成组件文件夹和基础测试文件。实际效果是新同学让AI“写一个用户管理表格”AI会根据skill自动生成带查询、分页、批量操作的表格组件并且代码的风格跟我团队主程手写的几乎一致。代码评审的成本直接砍半。这里有个关键点skill里的规范要定期跟着团队进化。不是写完就完事了我会每个月根据code review中发现的高频问题更新规范文档。这样AI产出的代码质量也会同步进化。5.3 AI漫剧与短视频内容场景把流水线做成skillAI漫剧相关skills之所以人人在找是因为这类创作链路太长从剧本、分镜、提示词、画面生成、配音断句到字幕输出全是步骤。普通提示词一次只能说一个环节而且环节之间的风格还容易飘。我的做法是把完整流水线打包成一个skillai-drama/ ├── SKILL.md ├── references/ │ ├── script-template.md # 剧本分段模板 │ ├── shot-description.md # 分镜描述写法 │ ├── visual-style.md # 画面风格关键词库 │ └── dubbing-rules.md # 配音/字幕断句规范 └── assets/ └── style_example.pngAI漫剧skill的“工作流”部分是核心。比如SKILL.md里会规定第一步把用户故事大纲扩展为7集的分集剧本每集300-500字。第二步每集拆出5-8个分镜每个分镜给出精确的画面提示词、镜头运动、景别。第三步为每个分镜生成配音文案标注停顿与情绪。第四步统一风格关键词确保所有分镜视觉风格一致。实测最大的收益是风格统一。以前手动给每个分镜写prompt画面气质完全看AI心情现在有了skill里的视觉风格词库和示例图同一部剧的每一集都能保持高度一致。对做连载类内容的团队来说这就是命根子。6. 常见问题与避坑指南6.1 装了不好使先按这三个方向排查我总结了三个最典型的“不好使”方向触发问题AI没加载skill典型表现是AI回答得很通用完全没用到skill里的知识。这时先检查description和配置文件然后看日志确认skill是否被加载。知识冲突AI加载了但不会用典型表现是AI提到了skill里的概念但执行得乱七八糟。多半是SKILL.md主文档写得不够结构化或references里信息互相矛盾。建议精简SKILL.md把规则收敛成清晰的步骤列表。权限问题AI想用工具但被限制如果skill里的scripts需要AI执行命令而工具配置里没给Bash权限就会卡死。检查宿主工具的权限模型和allowed-tools。6.2 skills越装越多反而把AI“撑笨”了我见过太多人包括我自己一开始看到什么装的都是必然踩坑的。装了几十个skill不仅每个都没深度AI还因为要不停判断“该激活哪个”整体反应变慢、答非所问。后来我听一位朋友分享过一个清理思路自己也照做现在固定只留五六个核心技能包给每个skill写一段使用记录用了一周没触发过三次的直接移除。同类skill只留一个。比如“前端规范”留一个最强的其余全删。把通用知识合并不要“周报”一个、“日报”一个、“会议纪要”一个合并成一个“日常办公”包效果反而更好。定期重装半年没更新的local技能全删重新在GitHub上找替代。这个思路帮我省了大量prompt tokenAI输出质量反而上来了。少即是多在skills这件事上特别成立。6.3 安全红线别把敏感信息写进SKILL.md这是我最想强调的一点。很多人为了方便把内网地址、数据库密码、API密钥甚至客户的敏感数据直接写进skill的参考资料里。这非常危险如果你把skill开源或传到GitHub等于直接泄露机密信息。就算本地用AI在输出时也可能无意中把敏感信息拼进代码或文档里被二次传播。我的建议是凡是会共享、上传的skill一律剥离敏感信息。需要访问真实接口时通过环境变量或MCP去动态获取而不是写死在skill里。6.4 skill和MCP混用时的“打架”问题当skill和MCP同时存在时AI可能会面临“一个任务该用skill里的方法还是调用MCP工具”的抉择。处理不好AI会同时干两件事结果是既低效又容易混乱。我的处理原则是在SKILL.md里明确写明“什么场景只走自身流程什么场景必须调用某个MCP”。比如我的“数据库分析”skill就直接规定数据分析环节必须调用database-mcp来查询数据禁止自己假设数据。这样AI的行为是可预期的不会颠三倒四。最后分享一点个人体会skills这个东西本质上是在帮我们把“组织经验”沉淀为AI能直接消费的资产。别把它的价值只理解成“让AI多懂点知识”它真正的价值是“让整个团队的AI应用水平趋于一致且能持续迭代”。你花一晚上写出来的skill团队里每个人、每次新会话都能继承这才是最划算的投资。如果你今天刚接触skills我建议从最简单的“复制一个成熟skill、改改成自己的”开始不要一上来就重造轮子。等你跑通一个你就会明白这玩意儿的边界其实就是你自己研究整理的边界的延伸。