1. Skills到底是什么从“反复调教”到“一次说清”大概从今年年初开始我身边越来越多写代码的朋友开始高频提到一个词Skills。不管是Claude Code、Codex还是Cursor都开始把Skills当成一个核心能力来推。坦白讲我第一次看到这个概念时是有点懵的——提示词Prompt我懂工作流Workflow我也懂那Skills到底多了点什么后来我连续用了一周才真正体会到这个区别提示词是“这一次告诉AI怎么干”Skills是“永远让AI知道该怎么干”。举个最直观的例子。我经常需要把一个带有复杂格式的Word文档转成Markdown再补上合适的frontmatter、拆分章节、压缩图片引用。这套流程至少有六个步骤每一步都有固定的处理规则。在过去我每次都要把这一大段规则粘贴进对话里辛苦倒还好说问题是AI偶尔会忘记某一步比如漏了frontmatter里的tags或者把代码块的语言标注搞错。有了Skills之后我只需要在对话里写一句“帮我把这份周报转成Markdown”AI会自动匹配到对应的技能包加载里面的全部规则、模板和示例然后一股脑把活干完。而且最关键是你不需要每次重复描述流程AI也不会“忘记”你之前的要求。如果你去看Claude官方文档里的定义Skills被描述为“Git工程目录下的技能集合通过SKILL.md来定义”。听起来很学术但说白了就是你给AI准备的一本“操作手册工具箱”。手册里写了遇到什么情况该怎么做、按什么顺序做、做到什么标准算合格工具箱里放了它执行任务时可能需要用到的脚本或者模板。还有一个区分点很适合新手Skills不是MCPMCP是给AI装“手脚”的Skills是给AI装“大脑回路”的。MCP让AI能调用外部数据、连上数据库或者运行工具Skills让AI在面对某个特定类型的任务时能按一个成熟的、经过验证的思路去执行。两者可以配合但不能互相替代。所以如果你想真正把AI从“偶尔聪明但经常需要指挥的实习生”变成“你只需要说一句就能自己搞定整条流水线的老员工”那Skills绝对值得你花一个下午好好研究。2. 一句话背后的“暗线”Skills是怎么被AI调用的很多人第一次使用Skills时会有一种错觉这玩意儿是不是就是把几个提示词打包了一下直到你深入了解运行机制才会发现它背后有一套相当严谨的调用流程。2.1 触发阶段AI先在“目录”里选技能每当你在Claude Code里发起一次对话AI会先扫描当前项目目录下的.claude/skills/文件夹以及用户全局目录下的~/.claude/skills/。它会读取每个技能的SKILL.md文件里的YAML头部信息——包括技能名称、描述、适用场景。这一步很像图书馆的检索系统AI不会先把所有书都读一遍而是先看“书名和摘要”判断哪本书跟当前任务有关。如果用户在对话里说“整理一下这份PDF的数据”AI就会对比每个技能的description发现有一个叫“pdf-data-extractor”的技能描述写着“用于从PDF中提取结构化数据支持表格和财务报表”于是大概率选中它。这就是为什么Skills的description描述一定不能乱写它直接决定了AI能不能“认出”你这个技能。很多人写Skills时随便糊弄两句描述结果AI压根不触发还以为是功能没装对。2.2 加载阶段按需读取完整规则AI选中技能后会去读取该技能SKILL.md文件里的详细内容。这些内容一般会包含任务处理的完整流程第一步做什么、第二步做什么输入格式要求什么样的文件、什么样的数据结构输出格式模板Markdown模板、JSON结构等质量检查清单完成前要逐项核对哪些要求参考示例给出一两个典型输入输出对让AI“照着样子画”SKILL.md文件的文本量一般在几十到几百行之间远大于普通提示词一次能承载的长度。但AI在常规对话时不会把所有技能内容全塞进上下文只在确实需要的时候才去读——这个“按需加载”的设计非常聪明既能保证响应的具体性又不至于把上下文窗口撑爆。2.3 执行阶段把“复杂”拆成“步骤”加载完SKILL.md之后AI的执行方式会有明显变化。它不再像一个“单轮问答机器”那样直接给出答案而是会呈现出“分步执行”的状态它会先读取输入文件按技能规定的第一步处理然后进入第二步每一步都会说明自己在干什么。你甚至会感觉到它像在“跑一个程序”而不是“聊天”。这个体验上的跃迁我感触特别深。去年我用AI处理一份300页的技术文档翻译AI翻到后面忘了前面的术语表把同一个接口名翻译成三种写法。后来我把它整理成一个翻译Skills里面规定了术语表必须在开头加载、每翻完一章要回填术语、最后要统一全文——从那以后翻译质量直接上了一个台阶。2.4 为什么“按需加载”是精髓我见过不少开发者对Skills提出质疑“既然本质是文本规则为什么不干脆写进System Prompt里”这里有个非常现实的问题上下文空间是有限的。System Prompt塞得越多AI用来处理实际内容的空间就越少响应质量和速度都会受影响。Skills的按需加载机制巧妙避开了这个问题——日常对话时它不占用太多上下文只有任务被判定“命中”某技能时才加载对应规则。这好比你家工具箱里的所有工具都挂在墙上平时不会占满你的双手需要用哪个拿哪个。理解了这一层你就明白了Skills不是简单的“提示词堆砌”而是一套兼顾灵活性和高效性的调度机制。3. 从安装到实战一步一步让你跑通Skills讲了这么多原理我知道你已经等不及想动手了。先把最常见的安装和配置方法梳理一遍。目前市面上主流的AI编程工具包括Claude Code、Codex、Cursor等虽然目录规范略有差异但基本思路是相通的。3.1 找Skills的两个途径第一个途径是GitHub上的各类awesome集合仓库比如awesome-claude-skills这类列表会按“文档处理”“数据分析”“开发辅助”等分类收集大量社区贡献的Skills。第二个途径是各工具自带的插件市场比如Claude Code目前支持CCPClaude Code Plugins规范可以直接通过命令搜索并安装社区发布的插件。我个人的建议是刚开始不要贪多先装三到五个跟你的日常工作高度相关的跑通了再继续扩充。装太多Skill反而会让AI在匹配时出现“选择困难”影响触发准确性。3.2 手动安装的完整过程以Claude Code为例这里我拿最常用也最典型的手动安装来演示因为磨刀不误砍柴工理解了手动安装你就理解了所有安装方式的底层原理。第一步创建一个存放技能的目录如果还不存在的话mkdir -p ~/.claude/skills第二步从GitHub上克隆你感兴趣的Skills仓库git clone https://github.com/some-user/some-skill.git ~/.claude/skills/some-skill第三步确认目录结构是否正确。一个标准的Skills目录长这样~/.claude/skills/some-skill/ ├── SKILL.md ├── scripts/ │ └── run.py ├── assets/ │ └── template.md └── reference/ └── examples.mdSKILL.md必须放在技能目录的根目录这个是硬性规定。scripts目录放辅助脚本assets目录放资源文件reference目录放参考资料。不是所有目录都必须有但SKILL.md是灵魂。第四步重启Claude Code在对话里描述你的任务看AI是否会加载对应的技能。如果你在对话中看到类似“我将使用xx技能来处理这个任务”的输出就说明安装成功了。如果你嫌命令行麻烦也可以用Claude Code自带的插件市场机制执行/plugin marketplace add命令来添加市场地址然后通过/plugin install一键安装。这个方式其实是在帮你自动完成上面的克隆过程本质上没有差别。3.3 不同工具的目录配置差异几款主流工具的Skills目录我整理了一个对照表方便你按需查阅工具全局 Skills 目录项目级 Skills 目录补充说明Claude Code~/.claude/skills/.claude/skills/同时支持CCP插件市场安装Codex配置文件加载路径AGENTS.md中声明通过AGENTS.md引用技能文件Cursor.cursor/skills/.cursor/skills/新版支持Rules与Skills结合OpenCode~/.config/opencode/skills/.opencode/skills/对目录命名和索引敏感这里提醒一句项目级目录优先于全局目录。如果你的项目里有.claude/skillsAI会优先使用项目里的版本这在团队协作中非常有用——新成员拉到代码仓库后项目自带的Skills也会一并同步省去了人人单独配置的麻烦。3.4 图片生成类Skills的特殊处理热搜词里有“图片生成skills安装包”我猜不少人已经试过给AI装“画图技能”了。这里有一个常见的认知误区图片生成类Skills并不是让AI“学会画画”而是让AI学会“正确调度绘画接口”。比如一个体验不错的图片生成Skills它的SKILL.md里记录的是根据用户输入的描述判断图片风格写实、卡通、水墨等、确定画幅比例、补全绘画提示词、然后调用底层的绘图API比如Midjourney接口或Stable Diffusion的本地服务最后对生成的图片进行文件名规范和存档。如果你装了一个图片生成Skills但始终不生效十有八九是以下几个原因底层的绘图API没配置好比如缺少API Key或本地服务没启动Skills里的脚本引用了不存在的Python依赖SKILL.md的description写得太模糊AI识别不了在什么场景该用它我能给的最实用的建议就是装好之后先看AI的执行日志它会告诉你卡在哪一步。绝大多数问题都出在依赖或API配置上而不是Skills本身。4. 从提示词到Skills手把手开发你自己的第一个技能说实话用别人的Skills总是隔着一层毕竟别人的流程不一定完全适配你的工作习惯。真正让Skills价值最大化的方式是把你自己的高频工作流沉淀成一个技能包。这个过程并不难我用一个非常典型的场景来演示完整流程。4.1 场景设定做一个“会议纪要整理”Skills假设我每周都要开好几个项目会每次的会议录音转写稿通常几百行对话需要整理成结构化的会议纪要包含决议事项、待办清单、责任人、截止时间、风险提示。过去我每次都要手写一遍整理要求现在我打算把它固化成一个Skills。第一步先把“散落的提示词”整理成“标准作业流程”。我打开自己过去写过的提示词发现整理纪要时我实际上按这个顺序工作先通读全文提取主题和背景然后按逻辑片段而不是对话轮次来切分内容接着提炼决议和待办每个待办项必须关联责任人和截止时间最后输出统一格式的Markdown纪要。第二步把这些步骤写成SKILL.md文件存放于~/.claude/skills/meeting-notes/SKILL.md--- name: meeting-notes description: 将会议录音转写稿或会议对话记录整理为标准化会议纪要适用于周会、项目评审会、需求讨论会等场景。 --- # 会议纪要整理技能 ## 适用场景 - 输入会议录音转写出的纯文本对话记录 - 输出标准化 Markdown 会议纪要 ## 处理流程 1. 通读全文提取会议主题、时间、参与角色。 2. 按逻辑主题切分内容忽略寒暄和无意义对话。 3. 对每个逻辑主题提取关键讨论点。 4. 从讨论中识别“决议事项”并单独归纳成节。 5. 从讨论中识别“待办任务”每条待办必须包含 - 任务描述 - 责任人如原文未明确标注“待确认” - 截止时间如原文未明确标注“待确认” 6. 输出统一格式的 Markdown 会议纪要。 ## 输出格式 markdown # 会议纪要{主题} ## 会议信息 - 日期{日期} - 参与人{参与人} ## 讨论要点 {逐条列出} ## 决议事项 {逐条列出} ## 待办清单 - [ ] {任务}责任人{姓名}截止时间{日期}注意事项如果原文中某个人名指向不明确不要猜测统一标注“待确认”。决议事项必须确保是“已经拍板的结论”不要把讨论中的备选方案写成决议。待办清单以复选框形式呈现方便后续转成任务管理系统。第三步写一个简单的验证脚本放在scripts/目录下用来检查输出的格式是否合规比如标题是否齐全、时间格式是否正确。这个脚本不一定要多复杂一个几十行的Python脚本就够用。 第四步也是很多人忽略的一步**准备示例输入和输出**。在reference目录放一个之前处理好的会议纪要作为示例AI在不确定格式时可以参考示例来“照猫画虎”。 第五步实测。开一个新的对话把一段带有明显噪音比如有寒暄、有跑题的会议记录扔给AI只说一句“用meeting-notes整理一下”观察AI的反应。如果AI没有自动触发先检查description是否写清楚了再检查目录结构是否放对了位置。 ### 4.2 从提示词到Skills的“三步迁移法” 很多用户问我如何把手头一段可用的提示词改造成Skills我觉得可以总结为三个步骤 第一步叫“拆动作”。把你提示词里隐式的处理流程显式化拆成一步步可执行的动作。这是最重要的一步因为Skills的SKILL.md本质上就是一个“执行SOP”。 第二步叫“定标准”。明确每一步的输出标准和格式规范。是输出JSON还是Markdown是多详细算合格这些都必须写清楚。AI的“自由发挥”空间越小结果的可复现性越高。 第三步叫“给范例”。找一个你处理过的典型样例连同输入和输出一起放到reference目录。对AI来说一个活生生的例子胜过十行抽象规则这和带新人是一个道理。 我自己写Skills有一个习惯**每写完一个Skill先用自己已知的高质量结果去“回放检验”**。如果按SKILL.md的流程执行能不能得到和当时人工处理一样的结果如果得不到就说明流程里还有信息缺口需要继续补。 这个习惯帮我避免了很多“看起来能用、实际用起来不稳定”的Skills我强烈建议你也试试。 ## 5. 踩坑记录我在Skills使用和开发中遇到的五个典型问题 无论什么工具用得多了总会踩坑。下面这几个问题是我在实际使用中最常遇到的也算是一份排错笔记希望能帮你省下几个小时的排查时间。 ### 5.1 问题一目录位置对了但AI就是不触发 这个问题的概率之大超出了很多人的想象。最常见的三个原因 - **description写得像“说明书”而不是“检索摘要”**。比如一个用于处理Word文档的Skillsdescription写的是“包含Word处理相关功能”这种描述给AI的匹配信息量太少了它判断不了该在什么场景下用。更好的写法是“将Word文档转换为Markdown支持标题层级识别、表格提取和图片导出适用于写博客草稿或整理存量资料”。 - **文件的编码有问题**。SKILL.md必须用UTF-8编码保存如果你在Windows上用记事本默认保存成了ANSI编码AI读取YAML头信息时就有概率解析失败。 - **目录层级有误**。SKILL.md必须直接放在技能根目录下不能多套一层子目录。我在社区里见过不少人把仓库克隆下来之后发现里面还嵌套了一层文件夹导致AI找不到SKILL.md。 排查方式很简单在对话里直接问AI“你目前在我的技能目录里发现了哪些技能”如果它回答不出来或者报错再去检查上述三个原因。 ### 5.2 问题二技能脚本运行时依赖缺失 如果你的Skills里有scripts目录里面是Python脚本或Shell脚本那么运行时依赖缺失是绕不开的问题。比如某个脚本用到pandas但你的全局Python环境里没装。 很多Skills在README里不会主动告诉你依赖清单所以我的习惯是**装完一个带脚本的Skill后先手动把scripts里的脚本跑一遍确认能正常运行再正式使用**。 如果脚本是Python写的建议在Skill目录里单独配置一个requirements.txt方便后续维护。还有个小技巧脚本里引用第三方库时尽量用importlib做懒加载在真正需要时才导入这样能减少无用开销同时让错误信息更明确。 ### 5.3 问题三Skills与项目规则Rules冲突 在Cursor里很多用户会同时配置.cursor/rules和.cursor/skills。Rules是永久生效的项目规则Skills是按需加载的技能包当两者对同一件事有不同规定时AI的执行结果就变得不确定。 比如Rules里规定“所有代码注释必须用英文”但你加载的一个代码生成Skills可能默认输出中文注释AI在遵从时会产生冲突。 我的解决方案是在设置Rules时明确加一条“如果某个Skills与本规则冲突以本规则为准”同时在开发Skills时尽量在SKILL.md的注意事项里预留一个“遵循项目级Rules”的字段让技能在执行前先读取项目规范。这有点像把系统级配置和应用级配置分层的思路。 ### 5.4 问题四安装太杂导致匹配混乱 有一段时间我见到什么Skills都往目录里装结果出现了很尴尬的情况我明明要做A任务AI却匹配到了B技能或者匹配到了一个技能但执行逻辑跟当前场景不搭。 后来我限制了全局Skills目录里只有5个高频技能其他都改放到项目级目录并根据项目类型管理。这样做的原因是**全局目录的技能是“任何项目都可能用到的”项目目录的技能是“这个项目专用”的两者职责分明后匹配准确率会高很多**。 如果你的技能包数量实在太多建议在技能命名上做“前缀区分”比如文档类统一用doc-前缀数据处理类用data-前缀让AI在检索时更容易分类决策。 ### 5.5 问题五Skills开发后自己都忘了怎么用 这其实是“开发者自身的维护问题”而不是技术问题。Skills目录里的技能一多你自己都记不清哪个技能对应哪个流程了更别说AI。 我的办法是给每个Skill都写一个简短的README.md记录使用场景、依赖、作者、最近修改日期。这不是给AI看的是给未来的自己和其他协作者看的。 有一个实用技巧**在SKILL.md文件的末尾加一段“更新日志”**记录你每次修改了流程里的什么内容。这样过一个月回来看你能清楚地知道这个技能包经历了怎样的演进也方便回溯出问题时的版本。 ## 6. 进阶用法让多个Skills协同工作与团队复用 如果说单技能是“工具”那多技能协同就是“流水线”了。这是我认为Skills真正的威力所在——通过精心设计让AI在一次任务中串联多个Skills完成远比单技能更复杂的整体流程。 ### 6.1 技能编排用一句话启动一条流水线 我举一个我们团队实际在用的例子。我们需要把客户发来的PDF可能是中文论文、可能是英文报告转化为一篇结构化的中文技术摘要并整理出关键数据表格。这个任务表面上看是一个“摘要生成”但拆解开来至少包含三步**PDF内容提取、术语规范化翻译、数据表格整理**。 我分别做了三个Skillspdf-content-extractor负责将PDF转成带段落标记的Markdown文本academic-translator负责按术语表翻译并统一文风data-table-builder负责把文中的数据整理成规范表格。 关键在于我在每个Skills的description里都加了一句“本技能常与其他技能配合使用当前一个步骤完成后后续步骤建议调用xx技能”。这样一来当AI完成了PDF提取后它会“主动觉得”下一步应该做术语翻译然后触发翻译Skills接着再触发表格整理Skills——整个过程我只说了一句“把这份PDF整理成技术摘要”AI就自动完成了整条流水线。 通过这种方式**Skills从“单一流程自动化”进化成了“跨步骤流程自动编排”**。 ### 6.2 团队级Skills目录的共享方案 实际项目中如果团队的每个人都在自己电脑上装一套Skills配置漂移是早晚的事。解决思路其实和代码版本管理一样**把Skills当成代码库的一部分来维护**。 具体做法是 - 在项目仓库中创建.claude/skills/或.cursor/skills/目录 - 把所有项目相关的Skills直接提交到Git仓库 - 团队成员拉到最新代码后Skills自动同步无需手动安装 - 修改流程时走Merge Request评审流程确保流程变更是可追踪的 这种做法在中期项目中的收益非常明显。我在一个持续了三个月的项目里实践过团队里四个人的AI行为始终统一新成员加入后的上手成本也大大降低。 ### 6.3 从社区获取灵感和现成方案 如果你不想从零开始写社区里已经有大量现成的参考。比如GitHub上的awesome-claude-skills仓库定期收录优秀的Skills一些开发者会在博客里发布“我每天在用的Skills合集”这些内容的质量参差不齐但总能找到适合自己的灵感。 我在搜索时通常关注三点**Stars数量、最近更新时间、目录结构是否规范**。一个半年没更新的Skills大概率已经跟不上最新工具版本了如果目录结构都不规范说明作者对Skills机制的理解可能也有限。 ## 7. 关于Skills的边界与未来方向 聊了这么多实操内容最后想再聊聊我的一些观察和思考。 Skills的边界在哪里我认为是“所有AI能自主完成的数字化流程”。只要一套任务的处理步骤可以被明确拆解、输出格式可以被规范化就有资格做成Skills。但如果是需要物理世界反馈的任务——比如“帮我把桌面的文件物理整理好”或者需要联网实时交互的任务——那就不是Skills能完全覆盖的范畴了得配合MCP或者其他工具。 未来的方向我比较看好两个一是**技能编排的标准化**目前社区里对技能包的格式还没有完全统一Claude Code、Codex、Cursor各自为政目录结构、描述规范都有些差异二是**技能市场的成熟**现在找技能主要靠GitHub仓库或者第三方集合页但信息组织方式还不够友好真正成熟后应该像包管理工具一样一条命令就能安装、升级、卸载。 从长期来看Skills的最大意义可能不是“省掉了几次复制粘贴”而是让AI的使用方式从“每一次对话都从零开始”变成了“每一次对话都站在以往固化经验的基础上”。我越来越觉得**个人或者团队积累的Skills集合才是AI使用能力上真正的护城河**。 就我个人来说我现在建任何新项目时第一件事已经不是搭代码框架了而是先把这个项目可能涉及的Skills目录建好把已知的流程规则提前放进去。项目跑起来之后AI就像一个“入职第一天就拿到了全套SOP”的新员工而不是一个“边学边干”的实习生。 如果你也经常需要用AI处理重复性、流程性的工作我真的建议你也用一个下午的时间把第一个Skills写出来。也许过程不算完美但一旦跑通你就会有源源不断的想法冒出来自己动手做更多的技能包。希望这篇内容能给你一些可落地的启发。