1. 从提示词到“技能包”的进化这两年搞AI编程和AI自动化我最大的感受是光会写提示词已经不够了真正拉开效率差距的是你有没有把提示词、工作流、工具调用固化成一整套可复用的能力模块——圈内现在把这玩意儿叫“skills”中文语境里有人翻译成“技能”但我更愿意叫它“技能包”或者“操作模式”。我在实际项目里经常遇到这种场景同一个团队里明明大家都在用Claude Code或者Codex这样的AI编码工具但产出质量天差地别。有的人能把代码生成、项目分析、测试用例、Bug修复这些环节做成一条流水线丢进去一个需求就能稳定产出高质量结果有的人还在靠每次手打几百字的提示词一天下来能折腾三四个来回。差别在哪就在有没有把“经验”沉淀成“skills”。今天这篇东西我打算把围绕着“skills”这词的坑和心得一次性讲清楚。不管你是正在折腾Claude Code、Codex、OpenCode、Cursor这类工具还是想给自己搞一套专属的skill体系甚至是想弄明白“skills如何调用MCP”“agent skills有哪些推荐”这篇文章应该都能给你一个比较完整的答案。先说重点结论skills本质上是一种结构化的指令包让AI不只是记住你说的一句话而是拥有一个可以跨项目、跨场景复用的专业操作能力。它把提示词、步骤规范、约束条件、工具调用方法、示例参考全部封装在一起类似于给AI装了一个岗位说明书加操作手册。早期大家诟病AI“智商高但不会干活”很大程度上就是因为缺少这种结构化能力约束。2. 核心概念与工作原理拆解2.1 skills到底是什么一个“岗位说明书加操作手册”的复合体我复盘了市面上主流的AI编程工具包括Claude Code的官方技能生态、Codex的skills、OpenCode里的agent技能还有社区里Matt Pocock这些大佬在推的实战技能包发现它们虽然在实现细节上各有差异但底层设计逻辑是高度一致的。一个典型的skill包含这么几层东西第一层是触发描述也就是告诉AI“当用户遇到什么场景时你应该调用这个技能包”第二层是操作步骤把完成这个任务需要走的流程规定清楚不讲废话直接干活第三层是规则约束比如代码风格、文件命名、测试要求、输出格式这些是保证质量和一致性的关键第四层是参考示例放两到三个高质量的输入输出例子AI才能准确理解你的预期第五层是工具调用说明如果这个技能需要操作外部工具比如跑测试、查文档、读数据库在这里面定义好调用方式。我拿吴恩达在agent skills教程里说过的一个观点来印证给AI系统配置角色和技能本质上是在做“工程化”不是在做“提示工程”。提示词决定一次对话的走向skills决定一个智能体在整个生命周期里的行为模式。2.2 为什么不能把skills做成“一个大提示词”很多人刚开始接触skills的时候会觉得这不就是把提示词放个文件里嘛有什么了不起的。还真不是。我自己踩过这个坑。最开始我确实尝试过把一份非常详细的任务说明直接塞给AI让它当成系统提示词来处理“代码审查”这件事。结果是什么呢第一上下文窗口被大量占用一个几千字的提示词塞进去真正处理业务上下文的空间就少了第二提示词太长之后AI的执行稳定性明显下降它会在执行到最后时报错或者偏离最初的规则要求注意力被稀释第三完全没法模块化复用。我想让它在代码审查时顺带生成测试用例就不得不改整个提示词牵一发动全身。skills的聪明之处在于它将原本“一坨”内容按职责拆分描述文件只管“什么时候触发这事”SKILL.md文件只管“怎么干活”脚本和模板文件负责具体执行。AI在第一次读取的时候就知道你这个技能包的边界在哪里知道哪些规则是必须遵守的哪些是参考建议执行效率和稳定性都提升了一个量级。2.3 从“会聊天”到“会干活”的能力跃迁我观察到一个比较有意思的现象同样是让AI写一份数学建模论文的辅助分析直接问和用skills驱动展现出来的水平差异是“业余助手”和“专业顾问”之间的差异这个判断我对比过很多次得出的结论。核心原因是skills内嵌了领域专家的操作惯性。拿数学建模来举例一个专门为建模设计的skill它的操作流程大概率会是先拆解问题确定建模类型再列出假设条件然后给出一套从数据预处理到模型求解的框架最后按论文结构输出结果。而如果让通用AI自由发挥它常常会跳过需求确认直接开写一个看起来很像样但实则泛泛而谈的方案如果被追问又容易推翻重来。所以我在实际推技能方案的时候总跟人说一句话skills解决的不仅仅是“AI会不会”更核心的是解决了“AI会不会稳定地、按专业套路地做”。3. 主流平台的skills生态与选择建议3.1 Claude Code的skills体系生态最完整的先行者先说Claude Code。这个工具应该是当前AI编程助手里面把skills玩得最明白的社区生态也最丰富。在GitHub上搜claude code skills你能找到大量现成的技能包从PPT生成、代码审查、前端还原设计稿到专利写作、渗透测试、移动端开发五花八门。很多人第一次看到这个列表会觉得“太夸张了吧”但实际上正是这种丰富的生态让Claude Code从一个命令行工具变成了一个真正意义上的“智能体工作台”。那Claude Code里的skills文件是放在哪儿的呢常规路径是在项目的.skills目录里放一个SKILL.md或者放在用户级目录~/.claude/skills下面这样每个项目都能直接调用。更核心的一点是Claude Code支持在skills里直接调用MCP工具这一点等会儿我会单独展开讲因为它把技能的能力边界拓宽了很多。我之前用过一个社区推荐度很高的npx命令来安装生态技能命令行大概是npx skills add xxx/yyy --agent claude-code这么一行就能把远程的skills仓库拉下来装进本地的技能目录里整个过程非常丝滑。我个人的建议是新手上路先别急着自己造轮子把社区里评价高、star多的skill用起来用熟练了你自然知道自己的技能包应该怎么写了。3.2 Codex与OpenCode同一个理念的不同生态Codex在skills上做了挺多差异化的尝试。它的核心特点是侧重项目级分析场景比如Codex分析项目结构、梳理技术栈、识别架构瓶颈这类工作用skills固化之后效果很明显。据了解GitHub Copilot底层的一些代码生成工作流也做了类似的“技能化”改造只不过对外名称不一样。OpenCode这个工具可能对国内用户来说稍微冷门一点但它在agent skills上的设计非常值得关注。它允许用户以非常细的粒度定义工具并且把“技能创建器”做成了可视化的配置流程。如果你本身已经用熟了Cursor这种编辑器想往外探索一下命令行风格AI工具OpenCode的skills设计应该会给你不少惊喜。Baoyu skills在国内社区讨论度也很高它的特点在于把一套开箱即用的技能配置打包得很整齐基本上拉下来就能跑对想快速体验agent skills效果的人来说是最省事的一条路。不过我用下来的感受是这类聚合技能的通用性有了但具体到你的业务场景还是要做个性化调整的。别人的鞋合不合脚只有自己穿了才知道。3.3 场景向skills推荐怎么选不踩坑下面这张表根据我实际使用和社区反馈整理出来的按场景选技能的建议含个人主观判断仅供参考应用场景推荐技能方向选型要点前端开发设计稿还原、移动端适配、组件生成必须选择包含代码风格约束和图片处理说明的技能包代码审查与分析项目结构解析、架构审查、安全扫描优先选带规则清单和输出模板的方便接CI测试工程测试用例生成、边界条件发现一定要找带“覆盖率校验”和“断言规范”的数学建模/学术建模思路拆解、论文结构生成选有完整案例库的否则AI容易空泛创意/文书PPT生成、专利写作、结构化文档关注输出格式是否与目标平台兼容如果你需要的是渗透测试、代码审计这类偏安全的技能我多说一句千万别拿你搜到的脚本直接往生产环境怼先看明白它的每一步在做什么再在隔离环境里跑通安全合规这根弦任何时候都不能松。4. 从零开发一个自己的skill完整实操4.1 前置准备与目录结构开发自己的skill之前先把自己的使用场景想明白再动手写文件。我推荐一个最简单通用的目录结构my-skills/ ├── SKILL.md # 技能的主文件必备 ├── scripts/ # 放辅助脚本可选的 └── assets/ # 放参考模板、示例文件可选的SKILL.md的内容格式一定要用标准Markdown头部建议加YAML格式的frontmatter来声明技能名称、描述和适用场景。这里有一个特别重要的细节描述部分一定要写清楚“什么情况下触发”AI是靠语义匹配来决定调用哪个技能的描述写得太模糊它会在需要的时候完全不调用或者在最不该调用的时候蹦出来。4.2 编写SKILL.md的核心步骤技能主文件的编写我习惯按照四个模块来组织第一块是“角色目标”用一两句话告诉AI它在这个技能里扮演什么角色。比如说你这个技能是“前端设计稿还原助手”那角色目标可以写成“你是专业的前端开发工程师负责根据设计稿图片生成还原度高、兼容性好的页面代码”。第二块是“执行流程”把整个任务拆分成几个有序的步骤。步骤不能太粗也不能太细太粗了AI不知道该怎么做太细了会限制它的灵活性。我以前碰到的问题就是步骤写得太大AI在执行到一半时就在原地打转。第三块是“规则约束”把你最在意的几条硬性规则写清楚。这里语法上有一点小技巧规则尽量用肯定句而不是否定句。比如说“推荐使用flex布局实现页面结构”比“不要用table布局”要有效得多。第四块是“输出模板”规定AI输出的最终格式。这一点在处理PPT、专利、测试用例这类需要输出标准文档的场景里格外重要。4.3 一个可直接复用的例子图片还原设计稿技能这里举一个我最近刚做的例子也是热词里提到过的场景给前端开发用的“图片还原设计稿”技能。因为很多团队目前设计稿是以图片形式给的AI虽然有视觉能力但如果不对它做专门的约束它还原出来的页面经常是“远看还行、近看全歪”。我的SKILL.md核心内容大概是这样设计的角色目标定义“像素级还原设计稿”的前端开发角色。执行流程先分析图片的整体布局和设计风格再识别颜色体系、字体大小、间距规律然后生成HTML结构再写CSS样式最后输出样式说明文档。规则约束必须使用语义化标签样式优先使用CSS变量定义主题色禁止硬编码奇怪的颜色值必须标注哪些参数需要后端接口提供。输出模板代码文件结构与说明文档的固定格式。设置成技能之后我再丢设计稿给AI输出质量就明显稳定了尤其是颜色、间距这类细节很少再乱来。为什么因为技能里的规则约束把AI潜意识里“随便设计一下”的欲望压住了让它走标准化的前端还原流程。4.4 命令行如何源码安装skill自己写好技能之后如果只在本地项目里用放到项目的.skills目录下就行了。但如果想跨项目使用或者分享给别人推荐用npx方式放到用户级目录或者直接推送到GitHub。源码安装这块我多说一句。很多人在网上看到类似npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这样的命令就直接复制粘贴结果在安装的时候莫名其妙卡住了其实很多问题都出在本地CLI版本和安装脚本不兼容上。安装之前先确认环境变量和Node版本没问题再执行安装命令如果网络环境不稳定还有更稳妥的源码安装方式直接把仓库clone下来然后手动拷贝到对应的skills目录里。# 示例放到Claude Code用户级技能目录 git clone https://github.com/xxx/my-skills.git ~/.claude/skills/my-skills5. skills如何调用MCP工具进阶技能必学5.1 MCP给skills带来的能力扩充MCP我简单说两句它的全称是Model Context Protocol即模型上下文协议本质上是一条让AI模型与外部工具、数据源进行标准化通信的“通用USB接口”。以前的AI工具之间互相不认你在Claude里写好的脚本换到Codex上就不能直接用有了MCP之后工具和模型之间的对话有了统一格式跨越了平台边界。skills和MCP的关系可以理解成skills是大脑里的操作手册MCP是手和脚。操作手册告诉你该用什么工具MCP负责把你的指令翻译成工具能听懂的语言并执行。为了让AI基于项目上下文去检索并把检索结果融合进分析结论里演示如何构造能自动执行的“skills去调MCP工具”其实是一种很标准的做法。也就是说一个skill里可以写明“第一步调用MCP工具检索项目文档第二步根据检索结果生成方案”AI在执行时就会按照这个流程去使用外部工具。5.2 一个具体配置例子测试用例生成技能我用测试用例生成技能来举例说明。测试用例生成这个场景让很多团队很头疼因为光靠大模型的直觉去写测试用例覆盖率和断言质量往往不稳定。通过把测试用例生成能力做成一个skill并在里面配置MCP调用我就能保证每次生成的用例都符合我个人的工程规范。在skill的规则约束里明确写上调用MCP工具获取被测函数/模块的源代码和API定义分析函数输入输出参数与边界条件基于代码实现生成最小完备的用例集每个用例必须包含正常路径、异常路径和边界条件三类。这样配置完之后AI不再凭空脑补测试场景而是先通过MCP拿到真实的代码上下文再结合技能里固化的测试设计原则来生成用例。说实话这个效果是我自己手动写prompt时很难稳定复现的。5.3 实测案例文档检索加PPT生成的双技能组合再分享一个更复杂一点的场景。我做过一个自动化写PPT的流程它结合了“文档检索”和“PPT生成”两个skills实际技术链路是先用文档检索skill去检索项目仓库里的设计方案、周报、竞品分析再把检索结果输入到PPT生成skill由它来决定版式、提炼要点、调用MCP工具渲染最终文件。这个流程如果没有MCP基本上是不可能实现的因为AI没有办法主动从仓库里把资料捞出来然后再把结果喂给绘制工具。但有了MCP之后两个skill之间可以实现无缝的数据流转。如果你研究过“skills如何调用MCP工具”这个热搜词下面这个原则值得牢记skill负责“怎么用”MCP负责“用什么”界限划分清晰才不会在复杂场景里变成一笔糊涂账。6. 常见问题排查与避坑心得6.1 skills不生效常见的三个原因“我明明把SKILL.md放进去了AI怎么完全不按套路来”这个问题在社区里被问了无数次我也遇到过。根据实操经验八成是以下三个原因造成的。原因一是描述写得不行。AI加载技能靠的是语义匹配如果SKILL.md开头那段描述写得跟你的需求对不上就会发生“看不到技能”的问题。解决方案是把技能适用场景、触发条件、关键词都写明确越具体越好。原因二是文件路径不对。Claude Code的skills和Codex的skills存放目录不一样你在网上抄代码的时候最好先弄清楚对方用的是哪个工具路径照搬大概率报错。原因三是缓存。有些AI工具会缓存上下文或技能列表你修改了SKILL.md之后它可能还是按旧版本执行。按我的经验改完技能之后最好重启一次会话重新加载一次上下文不要指望热加载。6.2 表格速查SKILL.md编写常见错误与修正方向常见错误表现修正方向描述太宽泛技能不被触发或乱触发写清楚触发场景和关键词步骤过于抽象AI输出质量不稳定拆到可执行的粒度并逐步校验规则全用否定句执行时摇摆不定尽量用肯定句表述规则缺少输出模板输出格式五花八门强制定义输出结构没有示例对质量预期理解有偏差给2-3个典型输入输出示例6.3 技能越多越好吗控制“技能过载”随着可用skill越来越多我开始遇到一个比较反直觉的问题装了太多技能之后AI反而更“不会干活”了。原因不复杂技能列表一长AI在选择调用什么技能时会出现混乱有时甚至会把几个不相关的技能组合叠加产生令人哭笑不得的结果。用了一段时间后我的习惯是每个项目只保留最多两三个真正核心、常用的技能把其他的统统移出到备份目录。特别是那些一次性用过的“一次性技能”用完就删不然它躺在目录里还会干扰后续调用。技能的核心价值不在多而在准、稳、可复用。6.4 多工具协同时的路径兼容问题还有一个细节值得提醒。如果你像我一样在多个AI编码工具之间切换使用比如同时用Claude Code和Codex那就要注意它们对技能目录的约定不太一样包括URL路径的格式和处理策略也都不同。我在opencode上正常用的技能配置切到Claude Code之后如果不改路径就完全识别不到。建议在换工具时先到它们各自的文档里查一下技能目录路径再决定是复制还是软链接。7. 经验心得技能建设这件事的长期回报最后说点个人体会。我见过太多人折腾skills是为了“跟上热点”或者“显得专业”但在我自己把技能成体系地建设了大半年以后我的真实感受是skills真正改变的是你对AI的使用哲学。以前我写提示词每一句话都是在“教”AI怎么做现在我写技能是在“定义”AI怎么持续稳定地做一件事然后把管理过程交给配置本身。这种思维方式转变之后我对“AI会不会取代程序员”这件事的看法也变了。工具不会取代会用工具的人但会用工具的人之间差距会越来越大。如果你现在的工作里有哪一类任务是你每周都要重复处理的我会特别建议你把那件事做成一个skill。花一个下午的时间写SKILL.md之后每次都能省下至少几个小时的重复劳动这个投资回报率是非常可观的。你写第一个技能的时候可能会觉得麻烦写到第五个之后你自己就能总结出一套属于自己的技能设计方法论了。毕竟真正好用的人工智能系统不是从一个宏大的需求开始的而是从一个“打破重复”的念头开始的。