你要是最近混AI编程圈肯定躲不开“skills”这个词。GitHub上带skills后缀的仓库一个接一个冒出来Claude Code、Codex、OpenCode都在聊怎么装skills华为杯建模的帖子里有人问“有没有好用的codex skills”就连做AI漫剧的都在找能一键生成分镜脚本的skills。火是真的火但我也发现一个现象大部分人对skills的理解还停留在“哦就是给AI加个技能插件吧”这种程度真正能说清楚它和普通提示词、和MCP到底有什么区别能自己动手写一个、甚至围绕它建立一套工作流的人很少。这篇文章我想从实际使用的角度把skills这玩意儿彻底拆开聊聊。它是什么、为什么这么香、主流的几款AI编程工具分别怎么装、怎么从GitHub手动搞一个下来、怎么写一个自己的skills以及不同场景前端、数学建模、AI漫剧下怎么搭配。最后还会讲讲skills的管理和清理——这一块基本没人系统写过。先说清楚这不是什么官方文档翻译是我自己踩坑踩出来的经验汇总适合理清概念后想直接上手的人。看完你至少能达到一个水平看到一个GitHub上的skills仓库知道它值不值得装装完知道怎么调不合适知道怎么删。1. 先搞清楚skills是什么以及它为什么突然值钱了1.1 skills不是提示词也不是MCP它是中间那一层很多人第一次接触skills时会陷入一个混乱这东西看起来不就是一段文字描述加几个示例文件吗跟写进系统提示词里的角色设定有什么区别有区别而且区别很大。你可以把AI编程工具的工作方式理解成核心模型负责思考上下文窗口负责装载信息工具负责执行动作。而skills站在一个很巧妙的位置——它是一份“可被检索、按需加载、结构化描述”的操作手册。普通提示词是“随叫随到”的。你把它写进系统提示词它就永远占着上下文窗口不管这次任务用不用得上。比如你塞一个“你是数学建模专家擅长数据分析、论文排版”的长篇设定它就一直待在那里写前端页面的时候也在聊家常的时候也在。MCP则是“外接设备”比较重。它通过标准协议把外部工具、数据源接进来比如连个数据库、调个外部API。MCP解决的问题是“AI能摸到哪些东西”它更像是在给AI接网线、插硬盘。skills则更像是“战术手册”。它平时不占用任何资源安安静静躺在项目目录或者全局配置里只有当AI发现自己正在做某类任务时才会主动去翻这本手册按照里面的规范、步骤、示例来执行。它的核心价值在于精准触发、按需加载、用完即走。这就好比你去一家餐厅普通提示词是餐厅里永远循环播的BGMMCP是后厨接的水电气管道而skills是厨师手边那本翻到烂的菜谱——只有要做那道菜时才会拿起来看看完放回去不占台面。1.2 skills的一次完整工作流程搞懂了定位我们再看一次具体的触发流程。以Claude Code为例一个skills从“躺在那儿”到“发挥作用”要经历大概这么几个环节扫描发现Claude Code启动时会扫描项目目录下的.claude/skills/文件夹或者用户全局的skills目录把每个技能子文件夹里的SKILL.md文件名和简短描述建立索引。语义匹配当对话中出现与技能描述高度匹配的任务时模型会将这个技能标记为“需要加载”。按需加载模型读取这个SKILL.md文件的内容把它作为临时的操作指导放进上下文。执行遵循模型按照SKILL.md里定义的步骤、规则、示例来执行具体动作。这时候skills里引用的其他文件比如模板、脚本、参考示例也可以被按需读取。退出释放任务完成后这个技能不再参与后续对话上下文空间被释放。这个流程里最关键的点是第4步——模型对SKILL.md的遵循度通常远高于普通对话里的指令约束。因为skills的结构天然促使模型把这些内容当作“规则”而非“参考信息”来处理这算是一个无意但极其好用的特性。你可以用它约束代码风格、规定输出格式、强制进行某些检查。2. 主流AI编程工具的skills支持现状2.1 Claude Codeskills的“原产地”Claude Code是Anthropic官方的命令行AI编程工具它最早提出了Agent Skills这个概念并在2024年10月的v2.0版本中正式支持。默认目录结构如下项目级.claude/skills/全局级~/.claude/skills/每个skill是一个独立文件夹里面必须有一个SKILL.md文件作为入口描述这个技能是干什么的、应该怎么用同时可以附带脚本、模板、参考文档等辅助文件。个人实测下来Claude Code对skills的遵循度是几款工具里最稳定的加载时机也很合理。只要描述写得清晰基本指哪打哪。安装方式也比较灵活可以通过/plugin命令在线安装市场里的插件也可以手动把GitHub仓库clone到skills目录自由度很高。2.2 Codex与OpenCode各有各的玩法OpenAI的Codex是另一个拥抱skills生态的重量级选手尤其是它CLI版本codex cli直接内置了codex skills命令可以列出、安装、管理技能。Codex在AGENTS.md规范里也留了专门的skills配置块允许把技能通过YAML元数据关联到特定目录和任务类型上。OpenCode是一款开源终端AI编程助手它把skills拆成了agent skills和workflow skills两种类型适配。前者类似Claude Code的技能包后者则偏向自动化流程模板。它的社区生态很活跃很多开源玩家会把写好的skills以仓库形式发布一条命令就能装进项目里。这三家工具虽然目录结构、触发机制、安装命令各有不同但底层逻辑是高度一致的以目录为单位、以标记文件为入口、以自然语言描述来驱动。2.3 Superpower Skills和Typesafe等现成技能库如果你不想从零开始写GitHub上已经有不少整理好的skills合集搜一下就有不少Superpower Skills目前社区里最出名的合集之一打包了大量实用技能比如代码审查、测试生成、文档撰写、系列化重构等。它做得比较好的地方是每个技能都有独立描述和示例触发准确率普遍较高。Typesafe AI Skills这是Scala/TypeScript生态里一个偏工程化的技能库特点是结构规范、模板完整很多技能可以拆出来单独复用适合作为学习如何写skills的参考范本。这类合集的优势是即装即用劣势是体积大。尤其Superpower这类全量装下来会占很多上下文我个人建议挑着装别一把梭。3. 从GitHub手动安装skills的完整流程3.1 怎么挑一个靠谱的skills仓库装skills之前得先学会看货。GitHub上skills仓库鱼龙混杂有的质量极高有的就是拿几个提示词拼出来的装进去纯属浪费上下文。我挑仓库一般看四个维度判断维度简单标准更新频率最近三个月内有没有commit说明作者还在维护SKILL.md规范度有没有清晰的名字、描述、适用场景、分步说明结构完整度是否有示例、模板、脚本等多文件支撑还是只有一个说明文件作者背景是个人玩家还是团队维护过往仓库质量如何这里有个我自己的偏好在里面我会优先选那些每个技能目录都带examples的仓库。因为skills这玩意儿写得好不好看示例最直观——示例能让你一眼看出这个技能是“认真设计过的”还是“随便写了段提示词充数的”。3.2 手动安装步骤详解手动安装其实不复杂整个流程大概分四步第一步把仓库clone到本地。假设你看中了某个skills仓库先把它克隆到一个临时目录不需要放进项目里先看清楚结构git clone https://github.com/xxx/awesome-skills.git cd awesome-skills第二步确认目录结构。一个合格的skills目录一般是每个技能一个文件夹文件夹里必须有一个SKILL.md。如果整个仓库只有一个Markdown文件那它不是skills集合只是篇文章。第三步按需拷贝到目标位置。确定要用哪几个技能后把它们对应的文件夹复制到项目的skills目录# Claude Code项目级 cp -r awesome-skills/skills/code-review .claude/skills/ # 如果放全局 mkdir -p ~/.claude/skills cp -r awesome-skills/skills/code-review ~/.claude/skills/如果项目里还没建过.claude/skills目录用mkdir -p一并创建就好。第四步重启工具会话让它重新扫描目录。如果一切正常你在对话里触发相关任务时模型就会自动加载这个技能。3.3 安装后的校验与调优装完不是结束是调试的开始。第一次使用一个外部skills时我的习惯是给它一个“信任测试”先在简单任务上测试别一上来就用它处理核心业务观察它是否在正确的时机触发有没有出现“没叫它它自己来了”“叫了它不来”的情况测试过程中被触发了看它输出的行为是否和SKILL.md里描述的一致如果发现触发时机不对优先检查SKILL.md里的description字段——这个字段是模型判断“什么时候用这个技能”的依据写得太泛容易误触发写得太窄又容易漏触发。调描述的过程本质上是在调“触发边界”。如果发现行为不对那就要看正文的步骤和规范够不够具体。模型遵循度再高也架不住你写了个“提高代码质量”这种空话它不知道“提高”具体指什么。必须写明“检查是否有未处理的异常”、“所有函数必须有类型标注”、“禁止使用any”这种可执行标准。4. 自己动手写一个skills结构、规范与技巧4.1 SKILL.md的结构设计看完别人的就该自己上手写了。一个标准的SKILL.md长什么样这里给出一份我自己常用的模板骨架--- name: skill-name description: 一句话说清楚该技能做什么以及应该在什么场景下使用。 --- # 技能名称 ## 适用场景 - 哪些任务应该使用这个技能 - 哪些任务不应该使用这个技能 ## 执行步骤 1. 第一步要做什么产出什么 2. 第二步要做什么有什么检查点 3. 第三步...直到任务完成 ## 注意事项 - 有哪些禁忌、边界、容易出错的地方 ## 参考示例 - 给一个完整的输入输出对让模型理解期望的行为模式这份模板看着朴素但它是能被模型稳定执行的关键。尤其不要小看YAML frontmatter里的description——它不是给人看的是给模型看的决定触发时机。有一点要注意技能名不要起得太宽泛。叫code-review比叫review好叫python-api-generator比叫coding好几百倍。名字宽了触发边界就糊了最终结果是模型要么不加载要么乱加载。4.2 让skills能被稳定触发写skills最大的痛点是“明明写了但模型不触发或者触发不准”。这个问题大多出在描述和实际使用场景不匹配上。举个我改过多次的例子。一开始我写一个“前端review技能”description是“审查前端代码质量”结果它经常被漏触发。后来改成了“在用户要求检查React组件、CSS样式、页面性能或代码可维护性时使用本技能特别适用于提交PR前的代码审查”触发准确率一下子提上来。原因在于模型是通过语义相似度来判断任务匹配的——描述里出现的具体词汇越接近真实任务里会出现的词汇匹配成功率越高。“审查”这个动词模棱两可“检查”和“提交PR前”这些才是任务现场会出现的词。另外一个小技巧在description里明确写“非适用场景”也就是负向排除。比如“本技能不适用于新功能开发仅适用于已有代码的检查”。这能显著减少“顺手就给你触发”的误伤情况。4.3 写skills时的常见坑我写过大概二十几个skills总结下来有几个高频翻车点新手几乎必踩第一个坑是文件引用路径写错。SKILL.md里可以引用同目录下的附件的比如模板文件、示例代码但相对路径必须写对而且要用相对SKILL.md文件的位置来写。一旦路径错了模型加载时找不到文件技能表现就会跟废了一样。第二个坑是技能内容超过上下文承受能力。一个SKILL.md恨不得写到五千字各种场景全覆盖结果是模型一加载就直接把上下文占掉大半后续干活的空间被严重挤压。我的经验是把SKILL.md控制在一千五百字以内复杂场景拆成多个技能或者把细节放到辅助资文件里按需加载。第三个坑是过度设计输出格式。有些skills写出来要求每一步都输出特定格式的报告结果模型为了凑格式反而把核心工作做砸了。正确做法是先管结果再管格式。比如测试生成技能先保证测试能跑过再要求输出规范注释。5. 高频场景下的skills搭配推荐5.1 前端开发场景前端是skills使用最多的领域之一因为前端开发的流程高度模式化——组件开发、样式检查、构建配置、性能优化每一步都有标准动作可以沉淀成技能。我自己配置前端技能的习惯是三个一组一个负责组件生成严格按项目的代码风格和目录规范一个负责PR前自检检查类型错误、未使用变量、可访问性问题一个负责样式审查CSS规范、响应式断点合理性、移动端适配。一个比较关键的配置心得是组件生成类的技能一定要绑定你项目的目录规范。默认生成的React组件很多人会放错位置或者文件名风格跟项目不一致。把这些规范写进SKILL.md让模型严格按你的规范创建生成的代码才能直接用。相比之下泛泛的“帮我写一个React组件”这种技能可以直接过滤掉。5.2 数学建模与华为杯场景数学建模这个方向的skills需求很旺盛尤其是在华为杯这类赛事期间选手需要在短时间内完成数据分析、模型构建、论文排版。网上很多人找“建模好用的codex skills”其实找的就是那几样数据处理技能快速完成数据清洗、缺失值处理、特征工程减少重复写pandas代码的时间模型报告技能每次跑完模型自动输出系数表、显著性检验、拟合优度等关键指标说明论文排版技能按学术规范把分析结果转成LaTeX表格和描述性文字这类技能组合下来最大的价值不是“替你想模型”而是把“从数据到报告”这条流水线上的重复劳动压缩掉。选手真正要花脑子的地方是选题和建模思路而不是写几十行通用数据处理代码。我实测过的一个组合是Codex CLI接数学建模skills相比纯手写对话代码生成稳定性高了不少。原因也简单skills里写了数据处理的标准流程和常见坑模型不会在清洗步骤上自由发挥出错率自然降下来。5.3 AI漫剧的内容生产场景AI漫剧这个方向比较新但热度上升极快。所谓AI漫剧是通过AI工具批量生成分镜图、配音、剪辑脚本形成短剧或漫画条漫类内容。它的生产链路长环节多每个环节都有标准化操作空间天然适合skills来加持。我听一个做AI漫剧的朋友聊过他的做法他把整个生产流程拆成了五个技能——剧本分镜技能、角色一致性技能、场景描述生成技能、配音脚本技能、剪辑脚本技能。每个技能对应链路上的一个环节模型在进入下一环节时自动加载对应技能按里面设定的表格和格式输出。有趣的是这类内容生产场景对skills的要求跟编程场景完全不同。编程更强调逻辑正确性和规范一致性而漫剧生产更强调输出格式的稳定性——比如分镜描述必须包含镜头编号、景别、画面描述、台词、时长五个字段一个不能少而且格式不能变因为后面要喂给其他工具做批处理。skills在这里本质上是在当“格式保险丝”。6. skills的日常管理和清理6.1 目录组织与命名的最佳实践技能装多了之后管理就变成大头。我见过最夸张的案例是有人把整个Superpower Skills仓库全塞进全局目录结果每次对话光扫描技能索引就要卡一下。我的组织策略是分三层全局只放那些跨项目通用、使用频率极高的基础技能比如代码审查、文档生成项目级放跟当前项目相关的特定技能比如某个项目的API封装规范第三层是临时实验区在项目下建一个.claude/skills-experimental/目录专门放还没验证过的新技能跑顺了再转正。命名上我建议统一用kebab-case短横线分隔小写单词比如pr-review-checklist、> AI编程Skills全解析：从GitHub安装到自建工作流
你要是最近混AI编程圈肯定躲不开“skills”这个词。GitHub上带skills后缀的仓库一个接一个冒出来Claude Code、Codex、OpenCode都在聊怎么装skills华为杯建模的帖子里有人问“有没有好用的codex skills”就连做AI漫剧的都在找能一键生成分镜脚本的skills。火是真的火但我也发现一个现象大部分人对skills的理解还停留在“哦就是给AI加个技能插件吧”这种程度真正能说清楚它和普通提示词、和MCP到底有什么区别能自己动手写一个、甚至围绕它建立一套工作流的人很少。这篇文章我想从实际使用的角度把skills这玩意儿彻底拆开聊聊。它是什么、为什么这么香、主流的几款AI编程工具分别怎么装、怎么从GitHub手动搞一个下来、怎么写一个自己的skills以及不同场景前端、数学建模、AI漫剧下怎么搭配。最后还会讲讲skills的管理和清理——这一块基本没人系统写过。先说清楚这不是什么官方文档翻译是我自己踩坑踩出来的经验汇总适合理清概念后想直接上手的人。看完你至少能达到一个水平看到一个GitHub上的skills仓库知道它值不值得装装完知道怎么调不合适知道怎么删。1. 先搞清楚skills是什么以及它为什么突然值钱了1.1 skills不是提示词也不是MCP它是中间那一层很多人第一次接触skills时会陷入一个混乱这东西看起来不就是一段文字描述加几个示例文件吗跟写进系统提示词里的角色设定有什么区别有区别而且区别很大。你可以把AI编程工具的工作方式理解成核心模型负责思考上下文窗口负责装载信息工具负责执行动作。而skills站在一个很巧妙的位置——它是一份“可被检索、按需加载、结构化描述”的操作手册。普通提示词是“随叫随到”的。你把它写进系统提示词它就永远占着上下文窗口不管这次任务用不用得上。比如你塞一个“你是数学建模专家擅长数据分析、论文排版”的长篇设定它就一直待在那里写前端页面的时候也在聊家常的时候也在。MCP则是“外接设备”比较重。它通过标准协议把外部工具、数据源接进来比如连个数据库、调个外部API。MCP解决的问题是“AI能摸到哪些东西”它更像是在给AI接网线、插硬盘。skills则更像是“战术手册”。它平时不占用任何资源安安静静躺在项目目录或者全局配置里只有当AI发现自己正在做某类任务时才会主动去翻这本手册按照里面的规范、步骤、示例来执行。它的核心价值在于精准触发、按需加载、用完即走。这就好比你去一家餐厅普通提示词是餐厅里永远循环播的BGMMCP是后厨接的水电气管道而skills是厨师手边那本翻到烂的菜谱——只有要做那道菜时才会拿起来看看完放回去不占台面。1.2 skills的一次完整工作流程搞懂了定位我们再看一次具体的触发流程。以Claude Code为例一个skills从“躺在那儿”到“发挥作用”要经历大概这么几个环节扫描发现Claude Code启动时会扫描项目目录下的.claude/skills/文件夹或者用户全局的skills目录把每个技能子文件夹里的SKILL.md文件名和简短描述建立索引。语义匹配当对话中出现与技能描述高度匹配的任务时模型会将这个技能标记为“需要加载”。按需加载模型读取这个SKILL.md文件的内容把它作为临时的操作指导放进上下文。执行遵循模型按照SKILL.md里定义的步骤、规则、示例来执行具体动作。这时候skills里引用的其他文件比如模板、脚本、参考示例也可以被按需读取。退出释放任务完成后这个技能不再参与后续对话上下文空间被释放。这个流程里最关键的点是第4步——模型对SKILL.md的遵循度通常远高于普通对话里的指令约束。因为skills的结构天然促使模型把这些内容当作“规则”而非“参考信息”来处理这算是一个无意但极其好用的特性。你可以用它约束代码风格、规定输出格式、强制进行某些检查。2. 主流AI编程工具的skills支持现状2.1 Claude Codeskills的“原产地”Claude Code是Anthropic官方的命令行AI编程工具它最早提出了Agent Skills这个概念并在2024年10月的v2.0版本中正式支持。默认目录结构如下项目级.claude/skills/全局级~/.claude/skills/每个skill是一个独立文件夹里面必须有一个SKILL.md文件作为入口描述这个技能是干什么的、应该怎么用同时可以附带脚本、模板、参考文档等辅助文件。个人实测下来Claude Code对skills的遵循度是几款工具里最稳定的加载时机也很合理。只要描述写得清晰基本指哪打哪。安装方式也比较灵活可以通过/plugin命令在线安装市场里的插件也可以手动把GitHub仓库clone到skills目录自由度很高。2.2 Codex与OpenCode各有各的玩法OpenAI的Codex是另一个拥抱skills生态的重量级选手尤其是它CLI版本codex cli直接内置了codex skills命令可以列出、安装、管理技能。Codex在AGENTS.md规范里也留了专门的skills配置块允许把技能通过YAML元数据关联到特定目录和任务类型上。OpenCode是一款开源终端AI编程助手它把skills拆成了agent skills和workflow skills两种类型适配。前者类似Claude Code的技能包后者则偏向自动化流程模板。它的社区生态很活跃很多开源玩家会把写好的skills以仓库形式发布一条命令就能装进项目里。这三家工具虽然目录结构、触发机制、安装命令各有不同但底层逻辑是高度一致的以目录为单位、以标记文件为入口、以自然语言描述来驱动。2.3 Superpower Skills和Typesafe等现成技能库如果你不想从零开始写GitHub上已经有不少整理好的skills合集搜一下就有不少Superpower Skills目前社区里最出名的合集之一打包了大量实用技能比如代码审查、测试生成、文档撰写、系列化重构等。它做得比较好的地方是每个技能都有独立描述和示例触发准确率普遍较高。Typesafe AI Skills这是Scala/TypeScript生态里一个偏工程化的技能库特点是结构规范、模板完整很多技能可以拆出来单独复用适合作为学习如何写skills的参考范本。这类合集的优势是即装即用劣势是体积大。尤其Superpower这类全量装下来会占很多上下文我个人建议挑着装别一把梭。3. 从GitHub手动安装skills的完整流程3.1 怎么挑一个靠谱的skills仓库装skills之前得先学会看货。GitHub上skills仓库鱼龙混杂有的质量极高有的就是拿几个提示词拼出来的装进去纯属浪费上下文。我挑仓库一般看四个维度判断维度简单标准更新频率最近三个月内有没有commit说明作者还在维护SKILL.md规范度有没有清晰的名字、描述、适用场景、分步说明结构完整度是否有示例、模板、脚本等多文件支撑还是只有一个说明文件作者背景是个人玩家还是团队维护过往仓库质量如何这里有个我自己的偏好在里面我会优先选那些每个技能目录都带examples的仓库。因为skills这玩意儿写得好不好看示例最直观——示例能让你一眼看出这个技能是“认真设计过的”还是“随便写了段提示词充数的”。3.2 手动安装步骤详解手动安装其实不复杂整个流程大概分四步第一步把仓库clone到本地。假设你看中了某个skills仓库先把它克隆到一个临时目录不需要放进项目里先看清楚结构git clone https://github.com/xxx/awesome-skills.git cd awesome-skills第二步确认目录结构。一个合格的skills目录一般是每个技能一个文件夹文件夹里必须有一个SKILL.md。如果整个仓库只有一个Markdown文件那它不是skills集合只是篇文章。第三步按需拷贝到目标位置。确定要用哪几个技能后把它们对应的文件夹复制到项目的skills目录# Claude Code项目级 cp -r awesome-skills/skills/code-review .claude/skills/ # 如果放全局 mkdir -p ~/.claude/skills cp -r awesome-skills/skills/code-review ~/.claude/skills/如果项目里还没建过.claude/skills目录用mkdir -p一并创建就好。第四步重启工具会话让它重新扫描目录。如果一切正常你在对话里触发相关任务时模型就会自动加载这个技能。3.3 安装后的校验与调优装完不是结束是调试的开始。第一次使用一个外部skills时我的习惯是给它一个“信任测试”先在简单任务上测试别一上来就用它处理核心业务观察它是否在正确的时机触发有没有出现“没叫它它自己来了”“叫了它不来”的情况测试过程中被触发了看它输出的行为是否和SKILL.md里描述的一致如果发现触发时机不对优先检查SKILL.md里的description字段——这个字段是模型判断“什么时候用这个技能”的依据写得太泛容易误触发写得太窄又容易漏触发。调描述的过程本质上是在调“触发边界”。如果发现行为不对那就要看正文的步骤和规范够不够具体。模型遵循度再高也架不住你写了个“提高代码质量”这种空话它不知道“提高”具体指什么。必须写明“检查是否有未处理的异常”、“所有函数必须有类型标注”、“禁止使用any”这种可执行标准。4. 自己动手写一个skills结构、规范与技巧4.1 SKILL.md的结构设计看完别人的就该自己上手写了。一个标准的SKILL.md长什么样这里给出一份我自己常用的模板骨架--- name: skill-name description: 一句话说清楚该技能做什么以及应该在什么场景下使用。 --- # 技能名称 ## 适用场景 - 哪些任务应该使用这个技能 - 哪些任务不应该使用这个技能 ## 执行步骤 1. 第一步要做什么产出什么 2. 第二步要做什么有什么检查点 3. 第三步...直到任务完成 ## 注意事项 - 有哪些禁忌、边界、容易出错的地方 ## 参考示例 - 给一个完整的输入输出对让模型理解期望的行为模式这份模板看着朴素但它是能被模型稳定执行的关键。尤其不要小看YAML frontmatter里的description——它不是给人看的是给模型看的决定触发时机。有一点要注意技能名不要起得太宽泛。叫code-review比叫review好叫python-api-generator比叫coding好几百倍。名字宽了触发边界就糊了最终结果是模型要么不加载要么乱加载。4.2 让skills能被稳定触发写skills最大的痛点是“明明写了但模型不触发或者触发不准”。这个问题大多出在描述和实际使用场景不匹配上。举个我改过多次的例子。一开始我写一个“前端review技能”description是“审查前端代码质量”结果它经常被漏触发。后来改成了“在用户要求检查React组件、CSS样式、页面性能或代码可维护性时使用本技能特别适用于提交PR前的代码审查”触发准确率一下子提上来。原因在于模型是通过语义相似度来判断任务匹配的——描述里出现的具体词汇越接近真实任务里会出现的词汇匹配成功率越高。“审查”这个动词模棱两可“检查”和“提交PR前”这些才是任务现场会出现的词。另外一个小技巧在description里明确写“非适用场景”也就是负向排除。比如“本技能不适用于新功能开发仅适用于已有代码的检查”。这能显著减少“顺手就给你触发”的误伤情况。4.3 写skills时的常见坑我写过大概二十几个skills总结下来有几个高频翻车点新手几乎必踩第一个坑是文件引用路径写错。SKILL.md里可以引用同目录下的附件的比如模板文件、示例代码但相对路径必须写对而且要用相对SKILL.md文件的位置来写。一旦路径错了模型加载时找不到文件技能表现就会跟废了一样。第二个坑是技能内容超过上下文承受能力。一个SKILL.md恨不得写到五千字各种场景全覆盖结果是模型一加载就直接把上下文占掉大半后续干活的空间被严重挤压。我的经验是把SKILL.md控制在一千五百字以内复杂场景拆成多个技能或者把细节放到辅助资文件里按需加载。第三个坑是过度设计输出格式。有些skills写出来要求每一步都输出特定格式的报告结果模型为了凑格式反而把核心工作做砸了。正确做法是先管结果再管格式。比如测试生成技能先保证测试能跑过再要求输出规范注释。5. 高频场景下的skills搭配推荐5.1 前端开发场景前端是skills使用最多的领域之一因为前端开发的流程高度模式化——组件开发、样式检查、构建配置、性能优化每一步都有标准动作可以沉淀成技能。我自己配置前端技能的习惯是三个一组一个负责组件生成严格按项目的代码风格和目录规范一个负责PR前自检检查类型错误、未使用变量、可访问性问题一个负责样式审查CSS规范、响应式断点合理性、移动端适配。一个比较关键的配置心得是组件生成类的技能一定要绑定你项目的目录规范。默认生成的React组件很多人会放错位置或者文件名风格跟项目不一致。把这些规范写进SKILL.md让模型严格按你的规范创建生成的代码才能直接用。相比之下泛泛的“帮我写一个React组件”这种技能可以直接过滤掉。5.2 数学建模与华为杯场景数学建模这个方向的skills需求很旺盛尤其是在华为杯这类赛事期间选手需要在短时间内完成数据分析、模型构建、论文排版。网上很多人找“建模好用的codex skills”其实找的就是那几样数据处理技能快速完成数据清洗、缺失值处理、特征工程减少重复写pandas代码的时间模型报告技能每次跑完模型自动输出系数表、显著性检验、拟合优度等关键指标说明论文排版技能按学术规范把分析结果转成LaTeX表格和描述性文字这类技能组合下来最大的价值不是“替你想模型”而是把“从数据到报告”这条流水线上的重复劳动压缩掉。选手真正要花脑子的地方是选题和建模思路而不是写几十行通用数据处理代码。我实测过的一个组合是Codex CLI接数学建模skills相比纯手写对话代码生成稳定性高了不少。原因也简单skills里写了数据处理的标准流程和常见坑模型不会在清洗步骤上自由发挥出错率自然降下来。5.3 AI漫剧的内容生产场景AI漫剧这个方向比较新但热度上升极快。所谓AI漫剧是通过AI工具批量生成分镜图、配音、剪辑脚本形成短剧或漫画条漫类内容。它的生产链路长环节多每个环节都有标准化操作空间天然适合skills来加持。我听一个做AI漫剧的朋友聊过他的做法他把整个生产流程拆成了五个技能——剧本分镜技能、角色一致性技能、场景描述生成技能、配音脚本技能、剪辑脚本技能。每个技能对应链路上的一个环节模型在进入下一环节时自动加载对应技能按里面设定的表格和格式输出。有趣的是这类内容生产场景对skills的要求跟编程场景完全不同。编程更强调逻辑正确性和规范一致性而漫剧生产更强调输出格式的稳定性——比如分镜描述必须包含镜头编号、景别、画面描述、台词、时长五个字段一个不能少而且格式不能变因为后面要喂给其他工具做批处理。skills在这里本质上是在当“格式保险丝”。6. skills的日常管理和清理6.1 目录组织与命名的最佳实践技能装多了之后管理就变成大头。我见过最夸张的案例是有人把整个Superpower Skills仓库全塞进全局目录结果每次对话光扫描技能索引就要卡一下。我的组织策略是分三层全局只放那些跨项目通用、使用频率极高的基础技能比如代码审查、文档生成项目级放跟当前项目相关的特定技能比如某个项目的API封装规范第三层是临时实验区在项目下建一个.claude/skills-experimental/目录专门放还没验证过的新技能跑顺了再转正。命名上我建议统一用kebab-case短横线分隔小写单词比如pr-review-checklist、>