最近我的社交信息流里几乎全是同一个词skills。打开GitHub新增的仓库里有skills点开技术博客标题里有skills同事在群里讨论Claude Code的新功能聊的还是skills。这个词我太熟了——十年前背过一篇叫“Six Skills for Qualified Employees in the 21st Century”的口译材料那时候skills是写在简历上的东西现在同一个词变成了AI Agent的功能模块是一整套可以安装、可以开发、可以分享的“技能包”。我用了一周时间把自己的工作流从纯Prompt方式切到了带Skills的方式中间踩了不少坑也把网上那些零散的信息手工梳理了一遍。这篇内容不是那种“三分钟上手”的速成攻略而是想从一个实际使用者的角度把Skills到底是什么、它和Prompt有什么本质区别、主流的工具分别怎么实现、我自己是怎么安装和开发技能包、以及踩过哪些坑完整地讲清楚。不管你是刚听说这个词的新手还是已经装了十几个技能包的进阶玩家应该都能找到一点有用的东西。1. 当“skills”从简历热词变成AI圈的硬通货1.1 一个普通单词的三次语义跃迁以前学英语的时候我背过一篇口译材料《Six Skills for Qualified Employees in the 21st Century》讲的是一个合格员工需要具备沟通、合作、批判性思维之类的软技能。那个年代skills这个词几乎等于“个人能力的集合”是简历首页的高频词也是各类培训机构的卖点。但是这两年这个词在开发者社区里发生了明显的语义漂移。我第一次注意到是2024年下半年GitHub上开始出现越来越多叫“awesome-skills”或者“skill-collections”的仓库点进去发现里面根本不是人的技能清单而是一堆给大语言模型用的结构化文件——有说明文档、有示例、有脚本。当时我还没太当回事觉得这可能又是一波“新瓶子装旧酒”的热度跟之前的agent、workflow之类差不多。直到最近各个AI编程工具几乎在同一时间把“Skills”变成了核心功能模块。Claude Code内置了Skills机制Codex跟进了OpenCode也支持连一些非编程类的AI产品都在做“技能市场”。社区里刷屏的安装命令已经不是那种“git clone然后拖进目录”的粗糙方案而是像npm装包一样一条命令就把某个技能装进Agent里。比如那串反复出现的“npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y”本质上就是在给Claude Code装一个视频生成相关的技能包。1.2 吴恩达那篇PDF和GPT-6 Astra背后的信号说说我为什么会认真研究这个东西。第一个触发点是吴恩达那套关于Agent Skills的教程DeepLearning.AI上也发布了PDF版本。如果说普通开发者的项目还只是零散尝试那吴恩达亲自出来讲就说明“技能包”这条路线已经不是一个极客圈子的小众玩法而是被主流教育体系认可的Agent设计方向。第二个触发点是一篇流传很广的社区文章标题大概是《Rethinking Skills and Prompts for GPT-6 Astra》。虽然GPT-6 Astra可能还只是一个未来模型的代号但这篇文章的核心观点在社区里讨论了很久随着下一代模型的理解能力继续增强静态的、固定写死的Prompt的边际价值会越来越低真正值钱的变成了“动态加载的、可组合的、结构化的Skills”。换句话说未来你给Agent的不是一段话而是一套方法。这两个信号叠在一起让我意识到一件事如果把大模型比作一个刚毕业的大学生Prompt就是你对他的临时口头交代而Skills是他工作台上分类摆放的工具手册和模板。公司招人看的是后者Agent想干好活靠的也应该是后者。这个类比后面我还会反复用到。2. Skills和Prompt的实质性区别为什么说它是Agent工作流的分水岭2.1 Prompt是“即兴发挥”Skill是“职业分工”先说结论Prompt和Skill最本质的差别不在于文件格式也不在于调用方式而在于“知识是否在会话之外被结构化了”。我举个很直观的例子。以前我让AI帮我做代码审查我会写一大段Prompt“请你扮演一个资深的前端工程师按照安全、性能、可维护性、代码风格这几个维度检查以下diff每个维度给出问题等级……”这段话可能有三四百字。每次新开会话都要重新粘贴一遍而且AI的执行效果经常飘忽不定——有时候理解得准有时候给你列出一堆无关痛痒的建议。同一个问题不同模型、不同版本之间差异更大。用Skill之后我把这套审查流程写成了结构化的技能包SKILL.md文件里定义了触发条件、执行步骤、输出格式rules目录里放了安全、性能、可维护性这几类具体检查清单templates目录里放了审查报告的模板。开会话时我不需要再粘贴那三四百字的Prompt只要说一句“按团队规范审一下这个PR的diff”Agent会自己去看SKILL.md按步骤执行。我用一个表格把这个差异总结得更直观一些维度PromptSkill知识存储位置会话上下文关闭即消失文件系统项目在技能就在复用性每次复制粘贴改起来麻烦一份技能包随处安装集中更新版本管理基本没有可以打tag、对比、回滚多人共享靠复制文本容易走样发布为技能包统一分发结构化程度自由文本发挥不稳定元信息步骤模板输出可预期这个差异的本质是什么是知识存储的位置变了。Prompt的知识存在会话里会话一关就没了每次都是即兴发挥Skill的知识存在文件系统里项目在、技能就在可以被复用、被版本管理、被多人共享。这就像你带实习生每天口头交代一遍流程和把SOP文档放在他桌上让他自己查带出来的效果完全不一样。2.2 Skill清单、目录结构与加载原理从实现层面看目前主流的Skill机制普遍遵循“渐进式披露”的设计思路progressive disclosure。这个东西听起来玄乎其实很好理解就是“先给摘要按需给细节”。一个标准的Skill目录结构大概长这样my-skill/ ├── SKILL.md ├── references/ │ ├── security-checklist.md │ └── performance-guide.md └── scripts/ └── analyze-diff.py入口文件SKILL.md是整个技能包的“门面”里面通常包含三个核心信息技能名称、触发条件描述、使用说明摘要。Agent在会话中会先扫描所有可用的SKILL.md文件只读取它们的description字段构建一个“我有哪些技能”的索引。当用户请求和某个技能的描述匹配时Agent才会深入读取这个技能的完整内容和关联文件。这个设计解决了什么它解决了大模型上下文窗口的瓶颈。如果你的技能包里有100个技能每个技能5万字总共有500万字的内容不可能全部塞进上下文。渐进式披露让Agent只维护一个轻量的索引用到了哪个技能才加载哪个技能的完整说明。这和浏览器的懒加载是一个思路——页面打开时不加载所有图片滚动到哪儿才加载哪儿。2.3 一次完整的Skill调用流程还原我以自己写的代码审查技能包为例拆解一次完整的调用流程。第一步会话启动时Agent扫描技能目录读取所有SKILL.md的name和description形成索引。这时它只知道“我有一个叫code-review的技能作用是进行代码审查”。第二步用户发来消息“按团队规范审一下这个PR的diff。”Agent对文本进行语义匹配发现这条请求和code-review技能的description高度相关于是加载完整的SKILL.md。第三步Skill的说明文档指导Agent按预设流程执行先读取diff数据再按优先级调取rules目录下的具体检查清单逐项扫描最后把结论填入输出模板。第四步Agent把填充好的审查报告返回给用户。整个过程中用户只看到了第一步的触发和第四步的结果中间的“查找哪个技能、加载哪个文件、按什么顺序执行”全部由Skill层自动完成。这就是为什么说Skill改变了Agent的使用方式——你不再指挥Agent“每一步怎么做”而是告诉它“按哪个标准作业程序来”。3. 主流AI编程工具中Skills生态的真实对比3.1 Claude Code Skillsmattpocook和superpower skills为什么能火现在市面上能跑的Skills生态社区讨论最多、仓库最活跃的应该还是Claude Code这边。我记得最早把这股热度带起来的一个是Matt Pocock他本身就是TypeScript圈子的知名博主他维护的skills仓库质量和文档都算得上社区标杆另一个是Superpower Skills这个项目口号大致是“给Claude Code装上超能力”里面整合了一批开箱即用的技能包。它们的共同点是不玩花活每个技能都能讲清楚适用场景、执行逻辑和输出物。为什么Claude Code这边能先火我分析下来有三个原因。第一Claude Code的Agent自主性和文件操作能力比较强技能包里的脚本和引用文件能被真正用起来而不只是“读一读”第二它的Skills目录约定非常简洁就是一个~/.claude/skills文件夹往里面丢目录就能生效几乎没有学习成本第三Claude系列模型本身对长文档、结构化指令的理解比较好SKILL.md那种“摘要详细说明”的结构天然契合。3.2 Codex、OpenCode的Skill实现差异不过Skills并不是某一家独有。OpenAI的Codex在后续版本里也加入了类似的技能机制。我试下来的感受是核心思路类似但配置文件格式和加载优先级跟Claude Code不完全一样。OpenCode作为一个开源终端AI助手社区里也有人在为它开发和移植各类Skills但整体生态规模和成熟度目前还落后Claude Code半拍。对普通用户来说这意味着同一个技能包不一定能直接跨工具复用——这个话题我到第六部分会专门展开。在GitHub上搜“coding skills”或者“前端开发skills”你还能找到不少合集仓库基本是社区成员把自己在实际项目中沉淀下来的工作流变成了技能包。有人做了Vue3项目结构分析技能包有人做了Tailwind样式规范技能包还有人把公司内部的Git分支规范做成了技能包从React性能优化到Git提交信息规范、单元测试生成什么都有。这说明Skills已经不是一个实验室概念而是一个被大量真实项目验证过的生产方式。3.3 从“前端开发skills”到“编码skills”的社区现状我个人的体感是现在Skills仓库的火爆程度有点像2022年ChatGPT刚火时候的Prompt仓库但又有本质不同。Prompt仓库属于“点子合集”——你看看别人怎么写提示词学到了思路回去还是得自己复制粘贴。Skills仓库则是“可以直接安装的零件”——你装完就能用用了就能改变Agent的输出质量。当然繁荣背后也有鱼龙混杂的问题。有些所谓“技能包”就是把几段Prompt包装了一下命名成Style发出来里面根本没有结构化的执行逻辑和引用文件。这种包装货很容易误导新手让人以为Skill就只是“更长的Prompt”。真正成熟的Skill至少要满足三个条件有明确的触发场景描述有可重复的执行步骤有结构化的输出物。缺一个它都只能算Prompt不配叫Skill。4. 实战第一步用一条npx命令装好并跑通Skills4.1 拆解那串神秘安装命令的每个参数前面反复提到了那串安装命令我就以它为例把每一步拆开给你看。这条命令是npx skills add sandai-org/vidmuse-skills --agent claude-code -g -y从左到右逐段拆解npx是Node.js自带的包执行工具它的作用是“临时下载并运行某个命令行工具但不需要全局安装”。很多人第一次看到npx skills这种写法会误以为skills是系统内置命令其实它只是Node生态里的一个CLI工具包名背后通过npm registry分发。再往后的add是子命令表示“添加一个新的技能包”。sandai-org/vidmuse-skills这一段是技能包的来源定位。这里用的是npm工具链但为什么要用这种“组织名/仓库名”的URL风格原因很简单绝大多数知名的技能包已经不放在个人博客或者网盘里了而是托管在GitHub上项目本身的发布元数据里通常也包含仓库地址。用这种格式CLI就能直接解析并下载。最后--agent claude-code表示把技能包安装到Claude Code的技能目录中-g是全局安装的意思不加的话只对当前项目生效-y表示跳过交互确认非交互环境下跑命令时有这个参数能少一点麻烦。4.2 源码安装没有网络包管理器时怎么办不过不是所有人都习惯用npx这条链路也不一定所有技能包都发布成了npm包。我在内网环境或者想改代码时更常用的是源码安装方式流程也很简单。第一步把技能包仓库克隆到本地git clone https://github.com/sandai-org/vidmuse-skills.git第二步查看仓库里的安装说明确认它要求的安装目标目录。Claude Code默认读取~/.claude/skillsCodex是~/.codex/skills不同工具不一样。第三步把技能包目录放进对应的skills目录。一般有两种做法一种是把整个仓库克隆到skills目录下另一种是借助仓库里提供的安装脚本执行脚本自动完成文件拷贝和依赖配置。第四步重启Agent会话让技能索引重新加载。源码安装的最大好处是方便改。你可以直接进到技能目录里改SKILL.md调整触发描述或者输出格式改动是即时的不需要重新打包。对于想学习Skill机制的人来说源码安装是比npx更推荐的起点。4.3 验证Skill是否真正生效的三个检查点装完之后怎么才能确定技能包真的生效了我一般会做三个检查。第一直接问Agent它有哪些技能。以Claude Code为例你可以在会话里让它列出已加载的Skill列表看有没有包含你刚装的那个。如果列表里压根没有说明目录放错了或者扫描失败。第二用触发描述里的关键词发起一个简单请求。比如技能包描述写的是“视频生成工作流”你就用一句“帮我准备视频生成相关的工作流配置”来试探看Agent是否提到了它正在使用某个Skill。这能确认触发链路是通的。第三检查输出是否符合技能包定义的格式。一个技能包如果设计了标准输出模板那么你触发它之后返回结果应该沿着模板走。如果返回的结果和普通Prompt输出没什么区别大概率是AI虽然加载了索引但没有真正执行技能里的详细步骤。这时候需要检查描述是否写得太模糊或者完整说明文件有没有被正确放在引用路径上。5. 从零定义自己的Skill以团队Code Review规范为例5.1 为什么要先梳理“专家决策树”而不是急着写文件我一直觉得开发Skill最忌讳的事情是一上来就写SKILL.md。你在敲第一行内容之前应该先回答一个问题这个技能包要处理的场景一个资深专家接到任务后脑子里走的是一棵什么样的决策树以代码审查这个场景为例。团队里最资深的工程师拿到一个PR的diff他不会从头到尾按文件顺序逐行读。他心里实际运行的逻辑是先看有没有安全漏洞再看有没有明显的性能问题然后看代码的可维护性和可读性最后才是风格规范。这个优先级不是随意的——安全问题会导致线上事故性能问题会导致用户体验下降可维护性问题会导致后续开发成本增加风格问题影响最小。所以先梳理决策树就是在把资深专家的隐性经验显性化。我把这套决策树写下来之后才去动手创建目录结构。因为有了决策树哪些东西该放在references里、哪些该作为固定执行步骤、哪些该做成输出模板全都一目了然。5.2 Skill清单文件结构、描述策略与调试循环下面是我在实际项目中用得很顺的一个技能包结构你可以在自己的项目里直接套用code-review/ ├── SKILL.md ├── rules/ │ ├── security.md │ ├── performance.md │ ├── maintainability.md │ └── style.md ├── scripts/ │ ├── extract-diff.py │ └── generate-report.py └── templates/ └── review-report.mdSKILL.md开头是YAML格式的元信息至少包含name和description两个字段。我这里给一个可以直接用的写法--- name: code-review description: 对PR/MR的diff进行团队规范代码审查按安全-性能-可维护性-风格优先级输出审查报告。当用户提到“审查代码”“帮我看看diff”“code review”时使用。 --- # 代码审查流程 1. 获取并解析diff 2. 依次执行rules/下的安全检查、性能检查、可维护性检查、风格检查每项读取对应文件的具体检查清单 3. 将结果填入templates/review-report.md 4. 按严重程度排序输出description字段务必要写清楚触发场景因为它决定了Agent会不会在合适的时机调用这个技能。我见过太多技能包description写得云里雾里结果Agent永远不知道什么时候该用。写完初版之后调试循环也很重要。我的做法是先拿一个真实的PR做测试观察Agent是不是真的按预设步骤走了如果输出和预期不符优先检查SKILL.md里的步骤是否足够清晰如果AI漏掉了某个检查项则把该检查项在对应rules文件里加粗加详细跑三轮之后把触发词和常见失败案例补充到description里。这个循环通常迭代两三轮之后技能包的稳定性就会明显提升。5.3 发布给其他Agent使用的注意事项如果你想把自研技能包分享出去有几个注意事项。首要问题是兼容性。你在Claude Code下调试好的技能包换到Codex上可能路径就变了因为不同工具的技能根目录不一样配置文件格式也可能有细微差别。所以发布时最好在README里写清楚这个技能包面向哪个Agent、安装到哪个目录。能提供一份清晰的安装说明比技能本身写得好更重要。其次描述要克制。我这里说的克制有两层意思一是description不要写太长Agent的索引读的是摘要写得太长反而增加选择负担二是不要过度承诺别在描述里写“能自动完成一切审查”结果实际只能做diff扫描这会严重拉低用户体验。还有一点是关于License的。技能包本质上是内容和代码的混合体如果你引用了别人技能包里的检查规则或模板记得保留原始出处。这既是对原创者的尊重也能避免后续版权问题。6. 实测踩坑记录兼容性、权限与内容膨胀6.1 跨Agent兼容的“方言”问题我在实践中最头疼的坑是跨Agent的兼容问题。有一次我在Claude Code里费了半天劲把一个技能包调试到输出质量很高然后想装到Codex环境用结果发现它根本不识别。排查了一圈问题出在技能目录的路径和元数据字段上——Claude Code读~/.claude/skills而Codex是~/.codex/skillsClaude Code用SKILL.md里的description字段做索引但Codex期待的可能是另一个字段名。这就是我所谓“方言”问题。技能包的核心方法论是通用的但每个工具的加载约定都有自己的方言换个平台就要做适配。作为使用者我的建议是尽量选择已经适配了多个Agent的技能包或者自己维护一套“源技能包构建脚本”根据不同目标平台生成对应格式的副本而不是手工维护多份拷贝。6.2 权限边界Skill越权读文件、执行命令的安全隐患第二个坑比兼容性更值得警惕那就是安全权限。技能包不是纯文档很多技能为了干实事会包含可执行的脚本。这带来一个问题你的Agent原本只会在你授权的范围内读文件、跑命令但装了不必要的技能包之后它的行为边界可能被扩展。举个例子某个技能包声称能自动帮你分析项目结构于是它的SKILL.md里写了一大段“请读取整个仓库的目录树、读取所有配置文件、尝试执行依赖安装命令”。如果这个技能包来自不明来源这些读取和执行动作就可能变成数据泄露的通道。所以我对装技能包有一个安全底线只装我能打开源码看得懂、作者有可信来源的包对于要执行的脚本先通读一遍再跑。任何让你关闭安全审查、跳过许可确认的技能包都值得打上一个问号。这不是说Skills不安全而是说它是一个新引入的攻击面。以前你的Prompt再长也只是文本顶多被诱导输出一些不该说的话现在Skill可以携带脚本等于把执行能力也带进来了使用风险随之上升需要多留个心眼。6.3 Skill库膨胀后的维护策略版本化与按需加载第三个坑可能比较晚才会遇到但遇到了就很痛——技能包膨胀。当你装了二三十个技能包之后每次会话启动时Agent扫描索引都要花上几秒而且技能包之间的触发描述如果写得含糊Agent还会出现“选错了技能包”的情况。有一次我就遇到过我想让它整理会议纪要结果它启用了某个写作风格技能包输出全是营销话术我盯着屏幕哭笑不得。我的维护策略有三条。第一按项目维度来组织技能目录不是全局装一大堆而是在每个项目里只放这个项目真正需要的技能包做到按需加载。第二定期清理长期没触发过的技能包——如果三个月没用过说明你根本没有这个需求删掉比留着更安心。第三技能包也做版本管理我自己维护技能包时会打个tag升级前保留上一个版本万一新版本效果变差还能快速回滚。7. 数学建模、专利写作、技能扩散方向…… Skills正在进入更多领域7.1 非编程类Skill的写法从“步骤模板”到“领域方法论”一个让我比较兴奋的趋势是Skills正在快速溢出编程领域。最近社区里挤满了各类相关需求数学建模skills推荐、发明专利写作的skills推荐、微信公众号文章技能包、结构图skills……这说明大家已经意识到凡是“有方法论、有固定流程、有标准输出物”的知识型工作都可以沉淀成技能包。以数学建模为例一个合格的数学建模Skill应该把“拿到题目-梳理条件-拆解模型-选用方法-编写论文-绘图排版”的完整流程封装进去并且在references里预置常用算法说明、评审标准对照表、论文模板。这样一来参加数模竞赛的学生就不再需要反复告诉AI“请用层次分析法建模并输出论文初稿”而是直接说“用数学建模赛级流程处理这道题”AI就会按照技能包内置的方法论完整走一遍。再比如发明专利写作。专利的权利要求书有严格的逻辑结构和技术特征表述要求这些完全可以做成结构化Skill先读取技术交底材料按“前序部分特征部分”拆解权利要求再按专利审查指南的标准生成说明书摘要和具体实施方式。这类技能包的价值在于它把“领域老法师”的经验固化下来让新人也能按流程产出合规文档。还有一个经常被问到的方向是安全测试Skills。在这个领域我建议大家务必把技能包使用范围限定在授权测试场景。安全测试本质上是防御性工作是在系统所有者明确授权的前提下进行的漏洞评估。不应该将有攻击性倾向的操作固化到通用技能包里更不能打着“渗透测试”的旗号去接触未授权的系统。技能包应该用来建设系统而不是破坏它。7.2 我对Skills后续形态的看法最后说一点我的个人判断。Skills这一波某种意义上是Prompt工程的“产品化”——以前大家靠复制粘贴提示词来传递经验现在则是把经验做成可安装、可复用、可迭代的技能包。从我日常的使用体验来看装了合适技能包之后AI输出的稳定性提升非常明显。我可以不用操心怎么描述需求只要说“按某某技能的流程处理”就行了这就是够了。下一步我觉得社区很可能会把注意力放在两个方向上一是跨Agent的技能包标准统一让大家写一次技能到处都能跑二是技能包的安全签名机制让用户在安装之前就能确认作者身份和代码来源。这两个问题解决了Skills就会从一个“极客玩具”变成真正的基础设施。这种演变路径也谈不上有悬念一项技术只要真的好用社区会自动把它推向更规范、更安全的方向。