最近后台收到好多读者问同一个问题“skills到底怎么用”。确实从Claude的Agent Skills到Codex的skills再到GitHub上每天冒出来的各种技能仓库很多人跟我一样先是被各种“打开新世界”的分享刷屏然后自己尝试装了一两个却发现要么不生效、要么用起来很鸡肋。我花了两周时间把前端开发、分镜设计、论文写作、甚至安全审计这几个热门方向的skills都实际跑了一遍踩了不少坑也总结出一套相对稳定的玩法。这篇文章就想把“skills”这件事从头讲透它到底是什么、从哪找、怎么装、怎么用、怎么自己写一个可靠的skill。不管你是刚听说这个概念的新手还是已经在用Agent但被各种细节折磨的老手相信都能从里面拿到点东西。1. Skills到底是什么先把这个概念看清楚1.1 从一次“开箱即用”的体验说起先说一个我印象最深的例子。当时我需要把一个设计稿快速转成React组件按照我以前的做法得写一大段Prompt告诉AI用什么框架、目录结构怎么组织、样式怎么写、响应式要覆盖哪几个断点。写完这个Prompt本身就要花不少时间而且每次换一个任务又得重新写一遍输出还时好时坏。直到我试了一个“前端开发Skills”之后情况完全不一样了我只需要把设计稿拖进去再补一句“用frontend-dev这个skill处理”它会自动按照预先定义好的流程走——分析布局结构、拆解组件、生成TSX文件、补样式、检查边界情况。输出质量稳定得多命名规范和代码风格也始终保持一致。这就是Skills最核心的价值把过去靠Prompt反复调教的经验固化成一个可复用、可分享、可版本管理的模块。说得更直白一点Prompt是一张临时便签Skills是一本标准化操作手册。便签用完就丢手册可以反复查、反复用还能传给团队里的其他人。1.2 Skills和Prompt、MCP、插件的区别很多刚接触的人会把Skills和Prompt、MCP、插件混为一谈其实它们解决的是完全不同的维度。我用一个厨房的比喻来解释Prompt是“顾客的口味偏好”比如“少放盐多放蒜”。它是一次性的、对话级别的信息。Skills是“厨师的标准菜谱”里面写了这道菜需要哪些食材、按什么顺序操作、火候怎么控制。它是预先写好的、可复用的流程。MCP是“食材供应商”它定义了一套标准协议让AI能通过统一接口去调用外部工具、数据库、文件系统。它解决的是“连接”的问题而不是“流程”的问题。插件是“厨房电器”比如烤箱、料理机。它扩展了Agent宿主本身的能力边界而不是给Agent增加某个“任务怎么做”的指导。也就是说Skills关注的是“任务执行流程的标准化”它可以在内部调用MCP工具也可以和插件配合使用但它们不是一回事。在实际使用中一个好的Skill通常会描述清楚什么时候触发、输入是什么、输出什么格式、执行分几步、要注意哪些坑。Agent读到这份描述后会在合适的时机自动加载并执行。这也是我从“第一性原理”去理解Skills的方式它本质上是一种“程序化的专家经验包”把隐性知识变成显式、可执行的结构化文件。正因为这个定位它才能在Claude、Codex、甚至一些本地Agent框架里都通用起来。2. 安装与查找把Skills装进你的Agent2.1 从哪里获取靠谱的Skills现在Skills的主要来源有三个官方市场、GitHub社区仓库、以及自己编写。我建议优先从官方渠道和经过验证的社区仓库开始不要一上来就乱下载。Claude官方市场Claude的Agent Skills官方市场里已经有不少官方维护和合作伙伴提供的技能覆盖开发、写作、数据分析等方向。这类质量有保障更新也及时。Codex内置技能库OpenAI Codex也在逐步完善skills生态部分skills会随着Codex版本自带比如代码生成、代码审查技能。这些适合跟Codex深度配合的场景。GitHub仓库搜索“awesome agent skills”或者直接搜“claude skills”“codex skills”可以找到大量社区维护的列表。挑选时重点看三样东西star数量、更新频率、README里的使用说明是否完整。star数量多不一定绝对好但如果一个仓库半年没更新大概率已经和最新的Agent版本脱节了。这里要特别提一个热词——“GitHub skills”。其实GitHub上除了AI Agent的skills仓库微软官方还有一个“GitHub Skills”板块那是给开发者学习GitHub功能用的互动教程。两者虽然都叫Skills但用途完全不同搜索资料的时候别被带偏。2.2 安装流程与基本配置安装Skills的方式因Agent而异。我以Claude和Codex为例给出我实际验证过的流程。先说Claude。在Claude中安装一个Skills通常需要把技能文件放到项目目录或者指定配置目录下。比如下载一个名为“frontend-dev”的skill文件夹里面会有SKILL.md和若干辅助脚本。把它放到Claude的项目根目录的.claude/skills/下然后在会话中调用即可。如果用的是Claude Desktop或者API版本一般需要在配置里声明skills目录的路径。Codex的安装逻辑类似但路径不同。以我的习惯为例我会把下载好的skills文件夹放到~/.codex/skills/目录下这样Codex进程启动时就能扫描到。有些封装版本也支持项目级路径比如.codex/skills/放在项目根目录下适合团队共享。不管放在哪里装完之后都要看一眼SKILL.md里有没有特殊的依赖要求。很多Skills不是只有一个Markdown文件它可能还带了Python脚本、Node脚本甚至需要安装额外的第三方库。这时候需要在skill目录下阅读requirements.txt或package.json再手动执行安装。我见过不少人装完skill没生效排查到最后发现是没装依赖。另外要留意版本匹配。某些较老的Skills只针对旧版Agent设计在新版本里可能会因为工具接口变了而失效。如果安装后表现异常先去看看这个skill的README里写了“适用于Claude某版本以上”之类的说明。2.3 安装后如何验证生效装好之后迫不及待想测试的心情我懂但别直接丢复杂任务先用一个最小化测试确认它被Agent正确识别了。我的做法是在会话里直接问列出当前可用的skills。如果Agent能准确说出你刚装的skill名称和它的功能描述说明加载成功。打开对话的调试日志如果你用的客户端支持确认是否有读取SKILL.md的记录。用一个测试输入简单跑一次比如让“分镜skill”处理一个100字的小片段把输出格式和预期结构对比一下。这一步非常关键能帮你把“skill本身有问题”和“使用姿势不对”这两个问题区分开。很多时候不是skill坏了而是你的Agent版本没有真正启用它。3. 实战场景用Skills解决真实问题3.1 前端开发Skills从设计稿到组件落地前端开发是Skills用得最狠的领域之一。我实际用下来的感受是一个写好的前端skill能解决的不仅是“生成代码”更是“保证生成代码的一致性”。我用的那个前端skill流程大致是这样先分析输入的设计图或交互描述提取关键信息然后根据预设的技术栈模板拆分组件的层级关系接着逐个生成组件文件包括接口定义、样式文件、测试用例最后跑一遍静态检查并输出改动清单。最让我满意的是它每次输出的组件目录结构都完全一致不会像裸Prompt那样这次生成一个文件夹、下次生成三个文件夹。另外一个很实用的场景是“重构旧项目”。让skill读一个老页面的代码按新规范输出拆分建议再自动生成新版本。因为skill里已经预设了代码风格的检查规则所以生成结果很少出现“风格前后不一致”的问题。对开发团队来说这相当于把团队规范直接内建到Agent能力里。3.2 论文写作Skills从零乱文献到规范初稿论文写作也是被问到最多的方向。很多人下载了“论文写作skill”但用起来却效果不好原因多半是那个skill只教AI怎么写摘要和润色没有覆盖从文献整理到结构输出的完整链路。我找到一个相对好用的学术写作skill它的执行流程是先读取你上传的文献列表或PDF抽取核心观点然后根据你选择的论文类型自动生成章节框架再逐章节填充内容末尾自动附上引用格式支持GB/T 7714和APA最后做一致性检查比如术语是否统一、图表编号是否连续。这里有一个非常重要的提醒学术写作skill可以帮你整理思路、规范格式、润色语言但绝不能替代你自己的学术判断。AI生成的内容引用的文献可能是编造的或者把不同来源的观点混在一起。我的习惯是把skill输出当成“高质量初稿”和“思路卡片”所有关键论点、实验数据、文献引用必须自己核实一遍。尤其是引用格式即使skill声称支持某标准也要抽查几处因为有些格式细节比如页码、DOI大小写确实容易出错。3.3 分镜设计Skills把文字剧本变成可视化分镜“分镜skills下载”最近也是热词尤其短视频和动画领域的人需要它。分镜这件事听起来只是“写镜头描述”但真正做过的才知道它需要同时考虑景别、运镜、时长、台词、音效、特效备注还要保证画面衔接连贯。让AI裸写经常写出来的镜头像流水账缺少镜头语言。我测试的分镜skill输入是一段故事脚本输出是一个结构化分镜表。它会先按场景切分再对每个场景判定情绪曲线据此推荐镜头景别紧张情节用近景和快速剪辑情绪平缓时用全景和慢速运镜。每一行分镜都会给出建议时长、画面对应动作、对白、音效备注还能导出成CSV或Excel方便导入剪辑软件。实际用下来有一个让我很舒服的细节它对“镜头编号”处理得很严谨即使同一场景里插入了切换镜头编号也不会乱。这看起来简单但你要知道让普通Prompt生成一个大型分镜表经常遇到编号重复或顺序错乱。skill里如果没有强制约束输出格式很容易出这种低级问题。所以我现在做短视频脚本基本都会先让分镜skill生成表格再手工微调节奏。3.4 安全审计Skills在授权范围内做自动化排查“自动挖洞skills”这个词出现频率不低但我必须先强调一个前提只做安全审计不碰未授权目标。所谓“自动挖洞”在正规工作流里应该被理解成“自动化漏洞排查”或“安全基线检查”。这类skill可以对你自己维护的系统、内部测试环境、或已获得书面授权的目标进行检测输出一份可读的审计报告。我试过一个安全审计skill它的工作方式是读取目标服务的配置文件、依赖清单和暴露端口信息先做一次静态检查比如识别已知漏洞版本的依赖包、错误的权限设置、不安全的加密算法然后尝试用一组受限的探测规则去确认漏洞是否存在最后生成带严重级别和修复建议的报告。它内置了一套“只读非破坏性”的检查策略也就是不会对目标造成实际影响。这里必须提醒使用这类skill之前先确认你有明确的授权并且skill本身不会偷偷执行危险命令。我之前就见过一个来路不明的“安全测试skill”到了执行阶段居然带了个反向shell脚本这种情况非常危险。所以我给所有人的建议都是安全类skill要么自己写要么选超高star、代码逐行可查的仓库千万别好奇乱跑。3.5 还有哪些高频场景除了上面四个还有一些值得一试的场景数据分析自动读取CSV/Excel做数据清洗、统计汇总、生成可视化图表适合财务和运营团队。自动化运维根据日志文件快速定位异常生成系统巡检报告能省掉大量人工翻日志的时间。SEO内容优化按关键词分析现有页面生成标题、元描述、内链建议适合内容运营。课程设计把一个知识点大纲扩展成完整的教学案例包含练习、测验和扩展阅读。这些场景的共性都是“流程清晰、重复度高、容易标准化”正适合做成skills。4. 自己动手开发Skills核心逻辑与工程实践4.1 一个Skill的标准结构如果你已经用了不少别人的skill很快会想自己写。我强烈建议每个skill都遵循一个统一的结构方便维护和分享。标准结构通常长这样my-skill/ ├── SKILL.md ├── scripts/ │ └── run.py ├── assets/ │ └── template.md ├── requirements.txt └── README.mdSKILL.md是灵魂Agent靠它来理解这个技能是干什么的、该怎么用。scripts/放辅助脚本用于执行稳定的计算比如处理文件、调用API、生成图表。assets/放模板、样例数据、静态资源。requirements.txt列出Python依赖README.md则是给人看的说明书方便别人判断要不要装。4.2 怎么写好SKILL.md清晰比华丽重要很多人第一次写SKILL.md会写成长篇大论恨不得把每个细节都塞进去。这是个误区。Agent读取SKILL.md时会先通过frontmatter里的描述判断当前任务要不要加载这个技能。描述写得含糊它就会在错误的时间调用或者根本不调用。我的推荐写法是--- name: financial-report-analyzer description: 用于读取企业财务报表利润表、资产负债表、现金流量表生成结构化分析摘要。只在用户提供财务相关文件或询问财务数据时使用。 ---描述一定要包含三个信息触发条件、适用场景、不适用场景。比如可以加上“如果用户只是泛泛问财务概念不要使用此技能。”这能有效避免误触发。正文部分我习惯按下面的结构组织任务目标一段话说明这个技能要完成什么。输入要求明确接收哪些参数或文件格式是什么。执行步骤按顺序列出操作流程每一步尽量具体。输出格式定义最终输出的结构最好给出模板。注意事项写出容易翻车的地方比如编码、网络请求超时、边界情况。拿一个“截图生成报告”的skill举例它的执行步骤可以这么写定位用户提供的截图文件校验格式是否为PNG/JPG。调用视觉模型分析截图内容列出关键信息。将分析结果填充到assets/report_template.md中。检查结果完整性生成最终Markdown报告。这种写法能让Agent在执行时减少自由发挥保证输出稳定。4.3 辅助脚本的开发要点SKILL.md描述的是“怎么做”真正需要精确计算的时候还是得靠脚本。我的原则是凡是有固定逻辑的操作比如文件解析、数值计算、格式转换都应该放进脚本而不是让AI现写代码。开发脚本时要特别注意两点。第一是输入校验脚本接收任何来自用户的路径或参数都要先判断类型和安全性。我见过一个skill因为没做校验用户传了错误路径导致脚本把系统目录当文件读最后直接崩了。第二是错误处理脚本不能一报错就退出至少要把错误信息以结构化方式返回给Agent让Agent能自行调整参数重试。脚本和LLM的分工也值得强调。大多数时候脚本不需要“自己思考”它只负责输入输出转换决策部分交给LLM。比如一个“批量重命名”skill脚本负责读取文件名列表、执行重命名而哪些文件要改、改成什么规则由LLM根据对话上下文去决定。这样职责清晰调试起来也方便。4.4 测试与发布写完一个skill后别急着上传先用几组测试样例跑一遍。我通常会准备三组输入一组是正常输入一组是边界输入比如空文件、超长文本一组是容易误触发的干扰输入比如用户明明没有提相关需求但对话里出现了几个关键词。如果是带脚本的skill我还会对脚本单独做单元测试。Python的pytest或者Node的vitest都可以重点测输入校验、异常分支和输出格式。测试通过后再放到真实的Agent环境里试用几天看它在对话中是否会在正确时机被自动调用。如果经常误触发多半是frontmatter里的description写得太宽泛了要再收一收。发布的时候建议把README写全至少包括功能简介、安装方式、依赖要求、使用示例、已知限制。仓库命名用“AgentName-skill-description”这种格式比如claude-skill-financial-report-analyzer方便别人搜索。版本管理也很有必要哪怕只是用Git标签打个v1.0至少能让你后续改动时可追溯。5. 常见问题与排查实录5.1 装了Skills但没生效这个问题我遇到太多次了尤其是新手。多数情况下不是skill文件本身坏了而是下面几个原因路径放错了不同Agent要求的目录不一样有的要放在全局配置目录有的允许项目级目录。如果放错位置Agent启动时根本扫不到。SKILL.md格式错误frontmatter里的YAML格式写错比如冒号后面没空格或者编码不是UTF-8Agent可能在解析时直接跳过这个skill。模型版本太老部分skills依赖Agent的特定能力比如视觉分析、代码执行环境如果模型不支持技能加载了也跑不起来。权限限制有些skill需要访问网络或本地文件Agent默认的安全策略会拦截。这时候需要在配置里给这个skill开启相应权限。排查顺序建议先看文件路径再看格式然后看日志最后看权限配置。大多数问题都能在这四步里找到答案。5.2 多个Skills互相冲突装了十几个skills之后你会发现第二个问题Agent有时候会选错技能或者两个技能同时被触发导致行为混乱。这本质上是“技能边界不清晰”导致的。比如你同时装了“代码审查skill”和“代码优化skill”这两个功能高度重叠Agent看到代码请求时可能不知道用哪个。我的解决方法有三个给skill命名加前缀比如review-code和refactor-code让名称本身就有区分度。在description里显式写“本技能只用于代码审查不做优化建议”之类的排除项。调整技能优先级。部分Agent支持在配置里设置技能加载顺序或优先级把更常用、更具体的技能排在前面。如果你发现某个skill总被另一个“抢活”已经试过上面方法还不行那建议合并这两个skill做成一个技能下面的多个子命令。5.3 来路不明的Skills有安全风险这一点必须单独拿出来说。Skills的本质是“让Agent按预设流程执行操作”而流程里可能包含任意代码。一个恶意skill完全可以在你毫不知情的情况下让Agent执行这样的事读取你的本地密钥文件、把内容上传到一个服务器、用你的身份去调用外部API、甚至执行系统命令。我亲眼见过一个下载量还不错的“效率工具skill”打开它的脚本后发现里面藏着一段curl命令会把当前目录下的所有文件名打包发送到一个远端地址。这还只是冰山一角。所以我对所有下载场景的建议是只从官方市场或信誉极高的仓库下载。下载后打开每个文件特别是脚本逐行检查一遍。优先选择代码量小、依赖简单的skill。第一次运行时在隔离环境里测试比如容器或虚拟机。绝不在未检查的情况下把skill和你的密钥、生产环境目录放在一起。安全这条线怎么强调都不为过。一个skill给你省下的几小时时间远不如被它偷走的敏感信息来得值。5.4 性能与上下文问题Skill装多了还有一个隐藏问题上下文窗口被占满。因为Agent需要在对话里读取SKILL.md的内容来判断是否调用如果每个skill的描述都很冗长几十个skill加起来会消耗大量token导致真正的对话空间变小甚至让响应变慢。我踩过这个坑之后定了几条优化经验把description压缩到一两句话只保留触发条件和核心功能。大段的模板、示例代码尽量放在assets/里而不是直接写进SKILL.md。如果Agent支持懒加载也就是只有确认触发后才读取skill的正文那一定要开这个功能。定期清理不常用的skill别让它们堆积在配置目录里。实测下来这样调整之后对话速度和上下文利用率都有明显提升。对使用低上下文模型的人来说这一点尤为重要。6. 我的一点个人经验和建议折腾Skills这么长时间我自己最大的感受是它真正改变的不是Agent的“聪明程度”而是你使用Agent的“工程化程度”。以前我依赖临场发挥写Prompt每次结果靠运气现在我把常用的流程都沉淀成Skills每次调用都像在稳定的流水线上跑一遍结果可控性大大增强。如果你刚开始接触我建议不要一次性装一大堆先选一个你日常最高频的场景找一个口碑好的skill用它把一件事完整跑通再逐步扩展。你很快会发现自己对Agent的依赖从“问它该怎么办”变成了“吩咐它按技能流程办”这种转变很有成就感。最后再送一个小技巧写skill的时候永远假设使用者是一个“聪明但不知内情”的新同事。你写清楚一步它就走稳一步你写清楚为什么这么做它才能在异常出现时做出合理判断。这套思维方式才是Agent Skills背后的真正红利。