1. 从“提示词”到“技能包”Karpathy为何反复提Skills最近AI圈子里有个词出现频率高得吓人——skills。打开社交媒体铺天盖地是“前端开发skills”、“superpower skills”、“coding skills github”连Andrej Karpathy都在多个场合反复强调这个方向吴恩达也专门出过关于Agent Skills的教程PDF。这个从底层模型研究圈流传出来的概念正快速渗透到每一个用AI写代码、做分析、搞创作的普通人手里。先说清楚一件事skills到底是什么业内对它的定义正在收敛——它不是一条提示词不是一个插件而是一组结构化的、可复用的“能力封装单元”。你可以把它理解成给大模型配的一套“工作手册工具箱操作规范”的组合包。Karpathy在谈论这个话题时反复提到一个观点真正高效的AI使用方式不是每次都从零开始写指令而是让AI按照一套预先定义好的流程、规则、示例来执行任务。这篇文章我想结合Karpathy的观点、社区里大量开源skills项目以及我自己在Claude Code、Codex、OpenCode等工具里的实测经验把skills这件事彻底讲透。适合谁看所有已经在用AI编程或AI辅助工作的朋友。不管你是写前端、做数学建模、搞渗透测试还是写专利文本只要你想让AI从“聊天助手”进化成“干活老手”这篇内容都能给你一个清晰的路线图。顺便回答几个大家搜得最多的问题npx skills怎么用superpower skills怎么安装怎么开发自己的skills这些都会在后面的实操部分逐一拆解。2. Skills的核心原理为什么它比Prompt更接近“真正的能力”2.1 Prompt的瓶颈与Skills的破局拿我自己举例。最早用AI写代码我的做法是每次敲一大段prompt“你现在是一个资深前端工程师请用React写一个支持拖拽的文件上传组件要求……”。效果时好时坏原因是模型每次都在“临场发挥”。Prompt的本质是“一次性指令”——你给了模型所有约束但它没有任何“肌肉记忆”。同一个组件需求今天写的和明天写的风格可能完全不同复杂任务稍微换个场景输出质量就断崖式下跌。Skills的思路完全不同它把“怎么做好某类任务”的整套知识预先固化下来。一个设计良好的skill包内部通常包含行为定义这个技能用来解决什么问题适用边界在哪里流程步骤一套可执行的操作序列告诉模型先做什么、再做什么规则约束必须遵守的硬性要求比如代码规范、输出格式、安全红线示例样本高质量的输入输出对让模型有样可循评估标准怎么判断任务做得好不好这有点像带新人。Prompt方式是“你临时帮我干个活”Skills方式则是“你先把这个岗位的工作手册背熟然后按流程办”。Karpathy在多个访谈里把后者称作“superpower skills”——一旦积累了一批高质量技能包AI的产出稳定性会有一个质的飞跃。2.2 Skills Harness把技能真正“装”进模型热词里有一个“大模型 skills harness 深入理解”这里的harness直译“马具”指的是承载和调度skills的运行时框架。光有skill文件还不够总得有个东西负责加载、解析、调用这些技能把技能内容注入到模型的上下文中或者通过工具调用的方式执行技能内的指令。目前主流的实现方式有两种一种是把skill内容作为系统提示词的一部分注入适合轻量级场景另一种是把skill暴露为模型可调用的工具函数模型在执行过程中按需触发适合复杂多步骤任务。Claude Code的Agent Skills走的是后一种路线这也是它处理复杂项目时更稳的重要原因。我个人理解Karpathy之所以在这个时间点反复强调skills是因为大模型的能力上限正在从“模型参数”转移到“模型外部能力封装”的组合上。模型的底座再强如果要处理一个它从没见过的精细工作流依然容易翻车。而skills恰好提供了一条低成本的路径把这些专业经验沉淀下来让模型站在“经验”的肩膀上干活。2.3 与Prompt、RAG、Fine-tuning的边界划分聊skills绕不开和另外两个技术方案的对比。社区里常有人问“这不就是RAG吗”“直接微调模型不就行了”我的建议是别把它们搞混它们解决问题的层面完全不同Prompt一次性的即时指令灵活但缺乏稳定性适合简单任务RAG给模型提供外部知识库的“检索-注入”机制解决的是“模型不知道”的问题Fine-tuning用数据调整模型权重成本高周期长适合改变模型底层行为模式Skills介于Prompt和Fine-tuning之间解决的是“模型知道但不会规范地做”的问题用做饭来类比Prompt是“你给我炒个宫保鸡丁”RAG是“这里有一本川菜菜谱照着做”Fine-tuning是把厨师的味觉彻底改造成川菜师傅的水平Skills则像是给厨师一张“标准作业卡”——花生米炸到什么颜色、调汁用哪几种酱油按什么比例、出锅前分几步操作。它不改变模型的知识量但极大约束了模型的“操作规范”。3. 主流生态现状Claude Code、Codex、OpenCode里的Skills支持3.1 Claude Code的Agent Skills当前完成度最高Claude Code是目前对skills支持最成熟的工具之一热词搜索里“claude code skills”出现的频率非常高。它的Agent Skills机制允许你把skills定义成SDK项目里的独立模块包含SKILL.md文件和相关的示例/脚本在子代理中持久加载并允许模型主动调用。我自己实测下来的感受是Claude Code的skills机制和它的agent设计是深度绑定的不是简单拼凑。它有一个“技能管理”的框架层系统会在合适的时机自动匹配并加载相关的skill文件到上下文中。这比传统的“粘贴所有指令到系统提示词”更省token也让模型在复杂任务中的表现更专注。安装社区里现成的skills常见的命令格式是npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这条命令做的事情很直白通过npx从GitHub拉取vidmuse-skills这个技能包以Claude Code作为目标agent安装-g表示全局可用-y跳过交互确认。实测下来对于网络状况正常的机器整个过程一分钟内就能完成。3.2 Codex与OpenCode各有侧重的技能体系OpenAI的Codex也在推skills相关的能力。热词里的“codex skills”、“codex 分析项目的skills”说明已经有不少人在研究怎么给Codex配技能。Codex的skills机制更偏向规范化的代码托管和项目分析流程——比如代码审查、架构梳理、依赖分析这些任务可以用skill把检查清单和输出格式固化下来让AI批量、稳定地完成。OpenCode则是一个开源终端的AI编码助手它也支持类似skills的扩展机制。从社区讨论看OpenCode的skills生态还处于早期阶段但因为它开源且可高度定制开发者社区里已经有人在尝试把Claude Code的skills平滑迁移过来。如果你主要用OpenCode建议先关注它的插件体系skills支持未来大概率会持续增强。3.3 生态之间的兼容性问题目前skills生态最麻烦的问题是缺乏统一标准。一个给Claude Code设计的skill放到Codex里可能完全不认目录结构README里写了“支持所有AGENTS”实际一跑全是兼容性报错。我的建议是除非你的项目只绑定一个工具否则在选型时优先选“目录结构清晰、SKILL.md格式规范”的skill包。这类包即使原生的安装命令不兼容手动把文件拖到对应工具的skills目录也能跑。反过来那些和特定框架强行耦合、写满CLI命令的skill换工具基本等于重写。3.4 国内生态的适配情况热词里“前端开发skills”、“好用的skills”搜索量很大说明国内开发者也已经大量进入这个领域。目前国内社区主要做的事情是两件一是搬运和汉化优质英文skills二是针对国内技术栈比如微信小程序、国产框架开发本地化skills。“微信公众号文章相关的技有包skills”这个热搜词我特别注意了一下确实已经有人在做公众号排版、标题优化、选题策划类的skills包了。这类技能包对内容创作者确实有价值——把一整套公众号写作和排版规范封装好AI生成的初稿质量会明显高一个档次。4. 实操入门从安装第一个Skills到日常组合使用4.1 安装前置准备Node环境和npx大部分skills的安装命令基于npx所以第一个前置条件是Node.js环境。如果你还没装去官网下载LTS版本一路点下一步就行。装完后打开终端Mac/Linux用terminalWindows用PowerShell输入node -v npm -v能看到版本号就说明环境OK。这里有个小坑如果你用的是nvm管理Node版本注意确保默认版本是对的。我遇到过npx命令报错排查半天发现是nvm切到了一个特别老的Node版本npx根本不认识。4.2 安装一个真实可用的Skills以分析类Skills为例热词里“codex 分析项目的skills”搜索量不小我以这个场景演示安装流程。假设你找到了一个合适的skill包安装命令大概是npx skills add some-org/project-analysis-skills --agent codex -g -y执行后终端会打印进度信息。安装完成怎么确认技能真的生效了简单的验证方法是给你的AI助手发送一个和该技能相关的任务。比如这个技能是“代码仓库分析”你可以让它“分析当前目录下项目的整体架构”然后观察它输出的内容——如果它自动按照技能里定义的模块结构输出比如“技术栈总览”→“目录结构图谱”→“核心模块逻辑”→“潜在风险点”→“优化建议”说明skill已经被正确加载了。4.3 Skills的日常管理与版本控制skills装多了以后管理就成了新问题。我自己的习惯是把skills放进一个单独的目录用Git做版本管理。这样改坏了可以回滚换新机器也能快速恢复环境。还有一个点容易被忽略定期更新。GitHub上的skills项目迭代速度很快很多skill作者每周都会优化规则和示例。我用一个定时任务每隔两周跑一次批量检查看看已安装的skills有没有新版本。这不是必须的但对于追求产出质量的用户来说保持skill版本新鲜带来的收益很明显。4.4 Superpower Skills值得专门聊的高质量技能合集热词里“superpower skills 安装”搜索量很高这确实值得单独说一下。Superpower Skills是一套在网上传播度极高的skills合集作者抓住了很多AI使用的共性痛点比如让AI输出结构化内容、让AI记住跨对话的偏好、让AI以固定的高质量格式产出文档等。它安装起来也很简单同样是npxnpx skills add works-superpowers/superpowers --agent claude-code -g -y实测下来这套合集对内容创作和日常办公场景的提升比较明显。它有一个“工作流”能把一个复杂的创作任务拆解成“调研-大纲-章节写作-统一审校”多个阶段每个阶段自动加载对应的规则和示例。对比直接写prompt让AI“写一篇长文”用这套skill产出的内容在结构完整度和风格统一性上确实高出一截。5. 自己动手做Skills从入门到能用的完整流程5.1 一个合格SKILL.md该有的组成结构先看最核心的问题一个skill文件到底怎么写虽然没有唯一标准但社区里质量较高的SKILL.md文件都具备几个共同特征。我以Claude Code的SKILL.md为例拆解一下--- name: 技能名称 description: 什么情况下使用该技能触发条件是什么 --- # 技能说明 这个技能用于解决什么问题边界在哪里 # 使用步骤 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 # 规则与约束 - 硬性规则必须遵守 - 输出格式要求 - 禁忌事项 # 示例 ## 输入示例 ## 输出示例看起来很简单但很多初次写skill的人会犯同一个毛病——把SKILL.md写成了“自我介绍”而不是“操作手册”。一个好的skill文档重点不是告诉模型“我是什么”而是告诉模型“遇到这个任务你按什么流程做、每一步做到什么标准、哪些坑绝对不能踩”。5.2 明确“触发条件”让AI知道何时该用这个技能SKILL.md开头的description字段比很多人想象的重要得多。它是模型判断“当前任务是否需要调用这个skill”的依据。写得太泛模型会在不该调用的时候频繁调用浪费token写得太窄模型又会在该用的时候漏掉。给大家一个可参考的格式description: 当用户要求对代码仓库进行安全审计、漏洞扫描、风险检测时使用。 适用于代码审查、渗透测试、安全合规检查。 不适用于一般性的功能咨询、新的功能开发。这里的关键是有明确的“适用”和“不适用”边界。我在实际使用中体会最深的一点是给模型划清“什么时候别用”的边界比告诉它“什么时候用”更能提升准确率。5.3 把经验拆解成模型能执行的流程规则写skill最难的部分是把一个你脑子里“感觉这样做是对的”的任务拆解成模型能一步一步照做的清单。以“渗透测试skills”为例安全工程师会按信息收集→漏洞扫描→漏洞验证→利用尝试→报告输出的顺序开展工作。但如果你只写“对目标做渗透测试”模型生成的流程可能完全是另一套。你需要把每一步都细化信息收集域名解析、子域名枚举、端口扫描、指纹识别、目录探测漏洞扫描根据指纹选择对应的扫描策略输出扫描结果报告验证利用对潜在漏洞进行手工验证确认可利用性报告输出按固定模板生成渗透测试报告包含风险等级、修复建议每一步都需要定义明确的操作对象、输出格式和判断标准。这个过程很费时间但价值也在这里——当你的skill足够细致AI的输出就从“泛泛而谈”变成了“真正像你说的那么干活”。5.4 从“能用”到“好用”持续迭代Skill文件skills不是一次性写完就完事的。我的习惯是每用一段时间就回头复盘看哪些规则没起到预期效果、哪些示例和实际场景脱节、哪些描述容易让模型误解然后做针对性修订。一个简单有效的办法是建立“失败案例库”每当模型输出结果不及预期就把这个案例记下来分析是哪条规则没写到导致它走偏再把它写进skill的“规则与约束”或“示例”里。这样迭代几十轮下来你会发现AI在这个领域的能力越来越稳定甚至比一些初级从业者还靠谱。6. 场景实战与避坑记录6.1 前端开发Skills把AI变成你的组件库热词里“前端开发skills”、“编码 skills”热度很高。前端领域是目前skills落地效果最好的场景之一原因在于前端开发有大量重复的、规范明确的编码模式。我自己配了一套专门用于组件开发的skill里面写明了组件文件的目录规范、TS类型定义规范、样式约定以及每个新组件必须输出的配套测试用例清单。装好之后AI生成的前端代码风格基本不需要二次调整组件间的交互逻辑也稳定很多。针对“结构图skills”这类需求前端场景里最常见的应用是架构图生成。社区里已有skill能把项目代码扫描后生成结构化的目录树、模块依赖图用文本格式或者mermaid描述。这类skill的核心价值不在于图本身而在于它让AI先梳理再输出输出内容的逻辑性比直接问“这个项目结构是什么”要强很多。6.2 数学建模与文档类Skills通用办公场景的提效方案“数学建模skills推荐”和“发明专利写作的skills推荐”、“微信公众号文章相关的技有包skills”这几个搜索词说明大量非程序员用户也在尝试用skills提升自己的工作效率。数学建模方向社区目前有不少围绕算法模板、论文排版、建模流程的skill包。举个典型场景数学建模竞赛时间紧张团队通常需要快速完成题目分析、模型选择、论文撰写。一个合格的数模skill应该包含问题重新梳理的模板、常用算法库对应适用场景和建议参数、论文各章节写作规范。发明专利写作的skill则完全是文档场景。专利文本的结构是高度标准化的——技术领域、背景技术、发明内容、具体实施方式每一部分的语言风格和逻辑结构都有严格规范。把一套高质量专利模板拆解成skill后AI生成的初稿在格式完整度上能接近“可以直接交给代理机构审核”的水平。我个人判断基于微信公众号文章的skills会是内容创作领域的一个重要突破点。公众号排版、标题策略、段落风格、文风调性——这些在新媒体行业里有大量不成文的经验规则。如果把这些经验系统化地写进skillAI生成的公众号文章从“能读”到“像人写的”这个跨越会比改prompt明显得多。6.3 踩坑实录我在Skills使用中遇到的5个典型问题问题一安装命令失效不同工具对skill格式的支持不同有的安装源已经迁移或改名直接粘贴旧命令大概率报错。解决办法先去GitHub看仓库的最新README确认支持的目标agent和安装命令是否有更新。问题二技能没生效AI还是老样子最常见的原因是安装路径不对。不同AI工具读取skills的目录不同安装时指定的--agent参数和实际使用的工具不一致就会出现“装了等于没装”的情况。排查方法是向AI提问“你当前有哪些可用技能”它能列出加载的技能说明就说明装进去了。问题三上下文被无效内容撑爆很多skill打包了大量示例和参考文档但实际每个任务能用到的只有一小部分。如果系统把所有内容全量注入上下文token消耗非常快。解决策略是精简SKILL.md本身的长度把大段参考资料拆成独立文件在真正需要时才按需读取。问题四多skill冲突同时装了多个功能重叠的skill时AI可能不知道用哪个。比如同时装了“代码审查v1”和“代码审查专业版”模型有时会混用两个版本的规则。解决办法是避免安装功能重叠的skill或者把冲突的skill合并处理。问题五skill文件中的中文编码问题部分安装工具或AI框架对UTF-8中文支持不够友好skill文件里如果存在非UTF-8编码轻则解析出错重则整个skill加载失败。检查办法用编辑器打开SKILL.md确认编码是UTF-8无BOM。6.4 经验心得三个让Skill效果翻倍的使用技巧第一个技巧是“按项目隔离”。不同项目对同一个技能的细节要求可能不同别把一套规则用到所有项目。比如前端组件开发技能A项目用VueB项目用React组件规范差异很大——按项目建不同的技能配置AI输出的适配度会高很多。第二个技巧是“把规则写在JKILL里而不是写在prompt里”。部分人用了一段时间后还是会习惯在提问时临时补充各种要求。这样skill的作用就大打折扣了。正确做法是把你希望AI遵守的长期规则写进skill文件提问时才用最简单的自然语言不需要重复约束。第三个技巧是“给skill留一个退出机制”。在某些场景下AI过度遵守skill规则反而会带来麻烦。比如skill规定了严格的输出格式但用户临时要做一次快速问答模型还守着格式不放就很蠢。设计skill时加一条“当用户明确要求直接回答或简化输出时可以不遵循本技能的格式约束”局面会好很多。7. 从Skills到Agent这个方向还要往哪里走在聊skills的落地细节之外有必要抬头看看这个方向的大趋势。Karpathy和吴恩达在各自的内容里其实都在指向同一个方向未来的AI产品不会是“一个全知全能的单体模型”而是“一个灵活的模型内核一群可组合的专用技能”。热词里那条“rethinking skills and prompts for gpt-6 astra”很有意思虽然GPT-6/Astra相关的信息目前有限但标题透露出的思考方向是真实的——随着模型迭代prompt的作用会逐渐被更结构化的“能力封装”取代而skills正是当前最被看好的封装形态之一。我个人判断未来半年会出现的几个变化skills的统一格式标准会逐步形成GitHub上会出现更多面向垂直行业的高质量skill包AI工具内置的skill管理界面会从“命令行配置”演进到“可视化商店”。到那时候“给AI配技能”会像今天“给手机装App”一样普通。现在这个节点最值得做的事情反而不是追新工具而是尽早开始积累属于自己的skills库。每当你发现一个“AI明明能做但经常做不好”的任务就是一个值得沉淀成skill的时机。这种积累自带复利效应——你的技能包越厚AI能稳定帮你处理的任务边界就越宽长期下来省下的时间远远超过初期投入的成本。 AI Agent Skills实战指南：从Prompt到技能包，原理、安装与自研全解
1. 从“提示词”到“技能包”Karpathy为何反复提Skills最近AI圈子里有个词出现频率高得吓人——skills。打开社交媒体铺天盖地是“前端开发skills”、“superpower skills”、“coding skills github”连Andrej Karpathy都在多个场合反复强调这个方向吴恩达也专门出过关于Agent Skills的教程PDF。这个从底层模型研究圈流传出来的概念正快速渗透到每一个用AI写代码、做分析、搞创作的普通人手里。先说清楚一件事skills到底是什么业内对它的定义正在收敛——它不是一条提示词不是一个插件而是一组结构化的、可复用的“能力封装单元”。你可以把它理解成给大模型配的一套“工作手册工具箱操作规范”的组合包。Karpathy在谈论这个话题时反复提到一个观点真正高效的AI使用方式不是每次都从零开始写指令而是让AI按照一套预先定义好的流程、规则、示例来执行任务。这篇文章我想结合Karpathy的观点、社区里大量开源skills项目以及我自己在Claude Code、Codex、OpenCode等工具里的实测经验把skills这件事彻底讲透。适合谁看所有已经在用AI编程或AI辅助工作的朋友。不管你是写前端、做数学建模、搞渗透测试还是写专利文本只要你想让AI从“聊天助手”进化成“干活老手”这篇内容都能给你一个清晰的路线图。顺便回答几个大家搜得最多的问题npx skills怎么用superpower skills怎么安装怎么开发自己的skills这些都会在后面的实操部分逐一拆解。2. Skills的核心原理为什么它比Prompt更接近“真正的能力”2.1 Prompt的瓶颈与Skills的破局拿我自己举例。最早用AI写代码我的做法是每次敲一大段prompt“你现在是一个资深前端工程师请用React写一个支持拖拽的文件上传组件要求……”。效果时好时坏原因是模型每次都在“临场发挥”。Prompt的本质是“一次性指令”——你给了模型所有约束但它没有任何“肌肉记忆”。同一个组件需求今天写的和明天写的风格可能完全不同复杂任务稍微换个场景输出质量就断崖式下跌。Skills的思路完全不同它把“怎么做好某类任务”的整套知识预先固化下来。一个设计良好的skill包内部通常包含行为定义这个技能用来解决什么问题适用边界在哪里流程步骤一套可执行的操作序列告诉模型先做什么、再做什么规则约束必须遵守的硬性要求比如代码规范、输出格式、安全红线示例样本高质量的输入输出对让模型有样可循评估标准怎么判断任务做得好不好这有点像带新人。Prompt方式是“你临时帮我干个活”Skills方式则是“你先把这个岗位的工作手册背熟然后按流程办”。Karpathy在多个访谈里把后者称作“superpower skills”——一旦积累了一批高质量技能包AI的产出稳定性会有一个质的飞跃。2.2 Skills Harness把技能真正“装”进模型热词里有一个“大模型 skills harness 深入理解”这里的harness直译“马具”指的是承载和调度skills的运行时框架。光有skill文件还不够总得有个东西负责加载、解析、调用这些技能把技能内容注入到模型的上下文中或者通过工具调用的方式执行技能内的指令。目前主流的实现方式有两种一种是把skill内容作为系统提示词的一部分注入适合轻量级场景另一种是把skill暴露为模型可调用的工具函数模型在执行过程中按需触发适合复杂多步骤任务。Claude Code的Agent Skills走的是后一种路线这也是它处理复杂项目时更稳的重要原因。我个人理解Karpathy之所以在这个时间点反复强调skills是因为大模型的能力上限正在从“模型参数”转移到“模型外部能力封装”的组合上。模型的底座再强如果要处理一个它从没见过的精细工作流依然容易翻车。而skills恰好提供了一条低成本的路径把这些专业经验沉淀下来让模型站在“经验”的肩膀上干活。2.3 与Prompt、RAG、Fine-tuning的边界划分聊skills绕不开和另外两个技术方案的对比。社区里常有人问“这不就是RAG吗”“直接微调模型不就行了”我的建议是别把它们搞混它们解决问题的层面完全不同Prompt一次性的即时指令灵活但缺乏稳定性适合简单任务RAG给模型提供外部知识库的“检索-注入”机制解决的是“模型不知道”的问题Fine-tuning用数据调整模型权重成本高周期长适合改变模型底层行为模式Skills介于Prompt和Fine-tuning之间解决的是“模型知道但不会规范地做”的问题用做饭来类比Prompt是“你给我炒个宫保鸡丁”RAG是“这里有一本川菜菜谱照着做”Fine-tuning是把厨师的味觉彻底改造成川菜师傅的水平Skills则像是给厨师一张“标准作业卡”——花生米炸到什么颜色、调汁用哪几种酱油按什么比例、出锅前分几步操作。它不改变模型的知识量但极大约束了模型的“操作规范”。3. 主流生态现状Claude Code、Codex、OpenCode里的Skills支持3.1 Claude Code的Agent Skills当前完成度最高Claude Code是目前对skills支持最成熟的工具之一热词搜索里“claude code skills”出现的频率非常高。它的Agent Skills机制允许你把skills定义成SDK项目里的独立模块包含SKILL.md文件和相关的示例/脚本在子代理中持久加载并允许模型主动调用。我自己实测下来的感受是Claude Code的skills机制和它的agent设计是深度绑定的不是简单拼凑。它有一个“技能管理”的框架层系统会在合适的时机自动匹配并加载相关的skill文件到上下文中。这比传统的“粘贴所有指令到系统提示词”更省token也让模型在复杂任务中的表现更专注。安装社区里现成的skills常见的命令格式是npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y这条命令做的事情很直白通过npx从GitHub拉取vidmuse-skills这个技能包以Claude Code作为目标agent安装-g表示全局可用-y跳过交互确认。实测下来对于网络状况正常的机器整个过程一分钟内就能完成。3.2 Codex与OpenCode各有侧重的技能体系OpenAI的Codex也在推skills相关的能力。热词里的“codex skills”、“codex 分析项目的skills”说明已经有不少人在研究怎么给Codex配技能。Codex的skills机制更偏向规范化的代码托管和项目分析流程——比如代码审查、架构梳理、依赖分析这些任务可以用skill把检查清单和输出格式固化下来让AI批量、稳定地完成。OpenCode则是一个开源终端的AI编码助手它也支持类似skills的扩展机制。从社区讨论看OpenCode的skills生态还处于早期阶段但因为它开源且可高度定制开发者社区里已经有人在尝试把Claude Code的skills平滑迁移过来。如果你主要用OpenCode建议先关注它的插件体系skills支持未来大概率会持续增强。3.3 生态之间的兼容性问题目前skills生态最麻烦的问题是缺乏统一标准。一个给Claude Code设计的skill放到Codex里可能完全不认目录结构README里写了“支持所有AGENTS”实际一跑全是兼容性报错。我的建议是除非你的项目只绑定一个工具否则在选型时优先选“目录结构清晰、SKILL.md格式规范”的skill包。这类包即使原生的安装命令不兼容手动把文件拖到对应工具的skills目录也能跑。反过来那些和特定框架强行耦合、写满CLI命令的skill换工具基本等于重写。3.4 国内生态的适配情况热词里“前端开发skills”、“好用的skills”搜索量很大说明国内开发者也已经大量进入这个领域。目前国内社区主要做的事情是两件一是搬运和汉化优质英文skills二是针对国内技术栈比如微信小程序、国产框架开发本地化skills。“微信公众号文章相关的技有包skills”这个热搜词我特别注意了一下确实已经有人在做公众号排版、标题优化、选题策划类的skills包了。这类技能包对内容创作者确实有价值——把一整套公众号写作和排版规范封装好AI生成的初稿质量会明显高一个档次。4. 实操入门从安装第一个Skills到日常组合使用4.1 安装前置准备Node环境和npx大部分skills的安装命令基于npx所以第一个前置条件是Node.js环境。如果你还没装去官网下载LTS版本一路点下一步就行。装完后打开终端Mac/Linux用terminalWindows用PowerShell输入node -v npm -v能看到版本号就说明环境OK。这里有个小坑如果你用的是nvm管理Node版本注意确保默认版本是对的。我遇到过npx命令报错排查半天发现是nvm切到了一个特别老的Node版本npx根本不认识。4.2 安装一个真实可用的Skills以分析类Skills为例热词里“codex 分析项目的skills”搜索量不小我以这个场景演示安装流程。假设你找到了一个合适的skill包安装命令大概是npx skills add some-org/project-analysis-skills --agent codex -g -y执行后终端会打印进度信息。安装完成怎么确认技能真的生效了简单的验证方法是给你的AI助手发送一个和该技能相关的任务。比如这个技能是“代码仓库分析”你可以让它“分析当前目录下项目的整体架构”然后观察它输出的内容——如果它自动按照技能里定义的模块结构输出比如“技术栈总览”→“目录结构图谱”→“核心模块逻辑”→“潜在风险点”→“优化建议”说明skill已经被正确加载了。4.3 Skills的日常管理与版本控制skills装多了以后管理就成了新问题。我自己的习惯是把skills放进一个单独的目录用Git做版本管理。这样改坏了可以回滚换新机器也能快速恢复环境。还有一个点容易被忽略定期更新。GitHub上的skills项目迭代速度很快很多skill作者每周都会优化规则和示例。我用一个定时任务每隔两周跑一次批量检查看看已安装的skills有没有新版本。这不是必须的但对于追求产出质量的用户来说保持skill版本新鲜带来的收益很明显。4.4 Superpower Skills值得专门聊的高质量技能合集热词里“superpower skills 安装”搜索量很高这确实值得单独说一下。Superpower Skills是一套在网上传播度极高的skills合集作者抓住了很多AI使用的共性痛点比如让AI输出结构化内容、让AI记住跨对话的偏好、让AI以固定的高质量格式产出文档等。它安装起来也很简单同样是npxnpx skills add works-superpowers/superpowers --agent claude-code -g -y实测下来这套合集对内容创作和日常办公场景的提升比较明显。它有一个“工作流”能把一个复杂的创作任务拆解成“调研-大纲-章节写作-统一审校”多个阶段每个阶段自动加载对应的规则和示例。对比直接写prompt让AI“写一篇长文”用这套skill产出的内容在结构完整度和风格统一性上确实高出一截。5. 自己动手做Skills从入门到能用的完整流程5.1 一个合格SKILL.md该有的组成结构先看最核心的问题一个skill文件到底怎么写虽然没有唯一标准但社区里质量较高的SKILL.md文件都具备几个共同特征。我以Claude Code的SKILL.md为例拆解一下--- name: 技能名称 description: 什么情况下使用该技能触发条件是什么 --- # 技能说明 这个技能用于解决什么问题边界在哪里 # 使用步骤 1. 第一步做什么 2. 第二步做什么 3. 第三步做什么 # 规则与约束 - 硬性规则必须遵守 - 输出格式要求 - 禁忌事项 # 示例 ## 输入示例 ## 输出示例看起来很简单但很多初次写skill的人会犯同一个毛病——把SKILL.md写成了“自我介绍”而不是“操作手册”。一个好的skill文档重点不是告诉模型“我是什么”而是告诉模型“遇到这个任务你按什么流程做、每一步做到什么标准、哪些坑绝对不能踩”。5.2 明确“触发条件”让AI知道何时该用这个技能SKILL.md开头的description字段比很多人想象的重要得多。它是模型判断“当前任务是否需要调用这个skill”的依据。写得太泛模型会在不该调用的时候频繁调用浪费token写得太窄模型又会在该用的时候漏掉。给大家一个可参考的格式description: 当用户要求对代码仓库进行安全审计、漏洞扫描、风险检测时使用。 适用于代码审查、渗透测试、安全合规检查。 不适用于一般性的功能咨询、新的功能开发。这里的关键是有明确的“适用”和“不适用”边界。我在实际使用中体会最深的一点是给模型划清“什么时候别用”的边界比告诉它“什么时候用”更能提升准确率。5.3 把经验拆解成模型能执行的流程规则写skill最难的部分是把一个你脑子里“感觉这样做是对的”的任务拆解成模型能一步一步照做的清单。以“渗透测试skills”为例安全工程师会按信息收集→漏洞扫描→漏洞验证→利用尝试→报告输出的顺序开展工作。但如果你只写“对目标做渗透测试”模型生成的流程可能完全是另一套。你需要把每一步都细化信息收集域名解析、子域名枚举、端口扫描、指纹识别、目录探测漏洞扫描根据指纹选择对应的扫描策略输出扫描结果报告验证利用对潜在漏洞进行手工验证确认可利用性报告输出按固定模板生成渗透测试报告包含风险等级、修复建议每一步都需要定义明确的操作对象、输出格式和判断标准。这个过程很费时间但价值也在这里——当你的skill足够细致AI的输出就从“泛泛而谈”变成了“真正像你说的那么干活”。5.4 从“能用”到“好用”持续迭代Skill文件skills不是一次性写完就完事的。我的习惯是每用一段时间就回头复盘看哪些规则没起到预期效果、哪些示例和实际场景脱节、哪些描述容易让模型误解然后做针对性修订。一个简单有效的办法是建立“失败案例库”每当模型输出结果不及预期就把这个案例记下来分析是哪条规则没写到导致它走偏再把它写进skill的“规则与约束”或“示例”里。这样迭代几十轮下来你会发现AI在这个领域的能力越来越稳定甚至比一些初级从业者还靠谱。6. 场景实战与避坑记录6.1 前端开发Skills把AI变成你的组件库热词里“前端开发skills”、“编码 skills”热度很高。前端领域是目前skills落地效果最好的场景之一原因在于前端开发有大量重复的、规范明确的编码模式。我自己配了一套专门用于组件开发的skill里面写明了组件文件的目录规范、TS类型定义规范、样式约定以及每个新组件必须输出的配套测试用例清单。装好之后AI生成的前端代码风格基本不需要二次调整组件间的交互逻辑也稳定很多。针对“结构图skills”这类需求前端场景里最常见的应用是架构图生成。社区里已有skill能把项目代码扫描后生成结构化的目录树、模块依赖图用文本格式或者mermaid描述。这类skill的核心价值不在于图本身而在于它让AI先梳理再输出输出内容的逻辑性比直接问“这个项目结构是什么”要强很多。6.2 数学建模与文档类Skills通用办公场景的提效方案“数学建模skills推荐”和“发明专利写作的skills推荐”、“微信公众号文章相关的技有包skills”这几个搜索词说明大量非程序员用户也在尝试用skills提升自己的工作效率。数学建模方向社区目前有不少围绕算法模板、论文排版、建模流程的skill包。举个典型场景数学建模竞赛时间紧张团队通常需要快速完成题目分析、模型选择、论文撰写。一个合格的数模skill应该包含问题重新梳理的模板、常用算法库对应适用场景和建议参数、论文各章节写作规范。发明专利写作的skill则完全是文档场景。专利文本的结构是高度标准化的——技术领域、背景技术、发明内容、具体实施方式每一部分的语言风格和逻辑结构都有严格规范。把一套高质量专利模板拆解成skill后AI生成的初稿在格式完整度上能接近“可以直接交给代理机构审核”的水平。我个人判断基于微信公众号文章的skills会是内容创作领域的一个重要突破点。公众号排版、标题策略、段落风格、文风调性——这些在新媒体行业里有大量不成文的经验规则。如果把这些经验系统化地写进skillAI生成的公众号文章从“能读”到“像人写的”这个跨越会比改prompt明显得多。6.3 踩坑实录我在Skills使用中遇到的5个典型问题问题一安装命令失效不同工具对skill格式的支持不同有的安装源已经迁移或改名直接粘贴旧命令大概率报错。解决办法先去GitHub看仓库的最新README确认支持的目标agent和安装命令是否有更新。问题二技能没生效AI还是老样子最常见的原因是安装路径不对。不同AI工具读取skills的目录不同安装时指定的--agent参数和实际使用的工具不一致就会出现“装了等于没装”的情况。排查方法是向AI提问“你当前有哪些可用技能”它能列出加载的技能说明就说明装进去了。问题三上下文被无效内容撑爆很多skill打包了大量示例和参考文档但实际每个任务能用到的只有一小部分。如果系统把所有内容全量注入上下文token消耗非常快。解决策略是精简SKILL.md本身的长度把大段参考资料拆成独立文件在真正需要时才按需读取。问题四多skill冲突同时装了多个功能重叠的skill时AI可能不知道用哪个。比如同时装了“代码审查v1”和“代码审查专业版”模型有时会混用两个版本的规则。解决办法是避免安装功能重叠的skill或者把冲突的skill合并处理。问题五skill文件中的中文编码问题部分安装工具或AI框架对UTF-8中文支持不够友好skill文件里如果存在非UTF-8编码轻则解析出错重则整个skill加载失败。检查办法用编辑器打开SKILL.md确认编码是UTF-8无BOM。6.4 经验心得三个让Skill效果翻倍的使用技巧第一个技巧是“按项目隔离”。不同项目对同一个技能的细节要求可能不同别把一套规则用到所有项目。比如前端组件开发技能A项目用VueB项目用React组件规范差异很大——按项目建不同的技能配置AI输出的适配度会高很多。第二个技巧是“把规则写在JKILL里而不是写在prompt里”。部分人用了一段时间后还是会习惯在提问时临时补充各种要求。这样skill的作用就大打折扣了。正确做法是把你希望AI遵守的长期规则写进skill文件提问时才用最简单的自然语言不需要重复约束。第三个技巧是“给skill留一个退出机制”。在某些场景下AI过度遵守skill规则反而会带来麻烦。比如skill规定了严格的输出格式但用户临时要做一次快速问答模型还守着格式不放就很蠢。设计skill时加一条“当用户明确要求直接回答或简化输出时可以不遵循本技能的格式约束”局面会好很多。7. 从Skills到Agent这个方向还要往哪里走在聊skills的落地细节之外有必要抬头看看这个方向的大趋势。Karpathy和吴恩达在各自的内容里其实都在指向同一个方向未来的AI产品不会是“一个全知全能的单体模型”而是“一个灵活的模型内核一群可组合的专用技能”。热词里那条“rethinking skills and prompts for gpt-6 astra”很有意思虽然GPT-6/Astra相关的信息目前有限但标题透露出的思考方向是真实的——随着模型迭代prompt的作用会逐渐被更结构化的“能力封装”取代而skills正是当前最被看好的封装形态之一。我个人判断未来半年会出现的几个变化skills的统一格式标准会逐步形成GitHub上会出现更多面向垂直行业的高质量skill包AI工具内置的skill管理界面会从“命令行配置”演进到“可视化商店”。到那时候“给AI配技能”会像今天“给手机装App”一样普通。现在这个节点最值得做的事情反而不是追新工具而是尽早开始积累属于自己的skills库。每当你发现一个“AI明明能做但经常做不好”的任务就是一个值得沉淀成skill的时机。这种积累自带复利效应——你的技能包越厚AI能稳定帮你处理的任务边界就越宽长期下来省下的时间远远超过初期投入的成本。