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用terminal，Windows用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以固定的高质量格式产出文档等。
它安装起来也很简单，同样是npx：
npx 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会是内容创作领域的一个重要突破点。公众号排版、标题策略、段落风格、文风调性——这些在新媒体行业里有大量不成文的经验规则。如果把这些经验系统化地写进skill，AI生成的公众号文章从“能读”到“像人写的”这个跨越，会比改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项目用Vue，B项目用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能稳定帮你处理的任务边界就越宽，长期下来省下的时间远远超过初期投入的成本。
