1. 从第一性原理理解 skills它不是插件也不是简单提示词聊 skills 之前得先分清一个概念。很多人第一次接触“skills”这个词是在 Claude Code、Codex CLI 这类 AI 编码代理agent工具里。当时的第一反应往往是这不就是个预置提示词吗或者是一个插件如果你也这么想后面大概率会用不明白。我用一个生活化的类比解释一下。平常我们让 AI 干活就像你在公司里临时拉了一个新人给他交代任务“帮我把这个页面的登录功能写完”。这个新人很聪明但他对你们公司的代码规范、历史遗留问题、常用组件库完全不熟只能一边写一边问效率和正确率都上不去。有了 skills 之后相当于你在开工之前先给这个新人一份《公司内部工作手册》里面写清楚了“我们常用的表单组件是什么”“后端接口怎么封装”“遇到权限问题怎么排查”。他拿到手册之后再去做同一个任务速度和质量完全不同。所以 skills 的本质是把一个领域的完整工作方法和约束条件打包成 AI 代理可以直接读取和执行的“行动手册”。理解这一点很关键因为它决定了你使用 skills 的方式插件plugin是给编辑器或者浏览器装的功能模块改变的是工具本身的能力边界。提示词prompt是一次性的口头指令告诉 AI“这次任务怎么做”。skills 是介于两者之间的东西它有固定的文件结构、有身份说明、有操作步骤、有校验标准可以被 AI 代理在多个任务中自主查阅和调用。从系统设计的角度看skills 解决了一个核心矛盾大模型的知识是通用的但任务场景是具体的。比如 Claude 的底座模型知道“怎么写 Vue 组件”但它不知道你们团队封装的check-button组件在哪个目录下、有什么 API。skills 就是给通用模型注入场景知识的那一层“上下文增强机制”。这个概念我在实际用了一个月之后才真正体会到它的威力。之前觉得它不过就是“结构化提示词”写起来费劲还不见得有效。后来在 Codex CLI 里跑一个“分镜脚本生成”的任务装上别人写好的分镜 skills 之后同样的输入输出的分镜结构从“一顿乱写”变成了“符合镜头语言的表格化脚本”那一刻我才意识到skills 的价值不在“提示词写得好”而在“领域知识沉淀的方式发生了变化”。所以我建议所有用 AI 代理干活的人都把 skills 当成一个“可复用的知识库条目”来理解。它不是魔法不会让模型变聪明但它能让模型在特定任务里表现得像个“干过这行的人”。2. 找一个好用的 skills 比想象中困难我踩过的坑都在这开头说了 skills 的概念这一节直接讲实操。高频搜索词里有个很有意思的词组find skills还有“skills推荐”“skills下载平台有哪些”。这说明大部分人的第一需求其实是“找现成的来用”。我在找 skills 的过程中走了两条路一条是在 GitHub 上翻另一条是在各类聚合站点、官方市场里搜。两条路各有各的问题先说结论现阶段最靠谱的渠道是给 AI 编程工具做的官方 skills 市场以及 GitHub 上高星开源仓库其他平台鱼龙混杂要仔细辨别。先说官方市场。以 Claude Code 为例现在的市场里已经沉淀了一批相当不错的 skills覆盖前端开发、数据可视化、文档生成、代码审计这些高频场景。你可以在配置界面直接搜索关键词比如搜“frontend”或者“code review”找到想要的点击下载就行。这个渠道的好处是质量有基本保障装完基本能用不会出现“下载完报错还得自己改半天”的情况。再说 GitHub。搜索热词里那几个非常典型的项目值得重点关注仓库方向典型关键词适用场景通用代理增强superpower skills把主流 AI 代理工具的常用技能包整合起来前端专项前端开发 skills组件生成、页面还原、样式调试写作与论文写论文的 skills论文大纲、文献梳理、段落润色创意内容分镜 skills视频脚本分镜、短视频策划GitHub 仓库的问题在于增量更新快、质量差异大。有些仓库作者明显在用 GitHub 当博客写一股脑塞进去十几个文件夹实际上很多 skills 写得很空。判断一个 skills 质量的标准我总结了一个土办法打开它的 SKILL.md 文件看里面有没有“具体到文件名或命令”的操作步骤如果通篇都是“你要认真思考”这类废话直接跳过别浪费时间。第三方聚合平台我也试过比如一些导航站、资源站把 skills 打包成 zip 放在网盘里点进去全是广告。这种我建议谨慎原因有二一是网盘里的版本可能不是最新的二是你根本不知道里面有没有夹带私货。从安全角度不要用非官方渠道下载的 skills尤其涉及代码执行类的技能包。顺便提一个高频搜索词“codex 好用的 skills”。我实测下来Codex 的 skills 生态和 Claude Code 的 skills 生态不完全共用但原理一致。你从 Claude 市场里下的 skills稍微改改路径说明也能塞进 Codex 用前提是核心方法SKILL.md 的格式切出来之后手动调整一下项目描述部分。3. 五分钟跑通第一个 skills从下载到真实任务验证找好了 skills接下来最关键的一步就是安装和验证。很多人卡在这一步不是装不上而是装完之后不知道它到底有没有生效然后就开始怀疑“是不是我安装姿势不对”。我先给一个最常见的安装方式然后用一个具体案例演示完整流程。假设我要在 Codex CLI 里装一个“前端开发 skills”目的是让 AI 帮我生成符合公司规范的 React 组件第一步下载并放好目录大部分 skills 的目录结构是这样的skills/ frontend-dev/ SKILL.md references/ ...下载之后放进这个固定目录~/.codex/skills/frontend_dev/注意不同工具要求不同有的工具用横线命名有的工具用下划线以你的工具文档为准但从我实测的结果看宁可多试两种命名方式也别盲目相信 README 里的目录说明因为版本升级经常改路径。第二步用任务触发装完之后不用重启终端但也有情况需要重启。稳妥起见新开一个终端窗口输入一个特定任务测试触发codex 我要写一个React表单组件包含用户名和邮箱字段用公司的表单校验逻辑生成代码文件注意你不应该手动告诉 AI“请你使用 frontend-dev 这个 skills”。要让 AI 自己根据任务内容去匹配。它会在任务执行过程中自动读取 SKILL.md 文件然后按照里面的规范来写代码。第三步验证生效怎么确认它真的生效了方法很简单在任务执行过程中用详细输出模式查看。如果你在输出日志里看到类似“读取 skills 文件”“使用前端开发的编码规范”之类的记录说明技能包已经被加载。如果没有多半是命名或目录路径有问题。这个流程走一遍大概不到五分钟。我特意没有写具体到某个品牌工具的安装命令因为每个工具的配置入口不一样但核心逻辑是一致的找对放 skills 的目录放对格式的文件触发一个能匹配上下文的任务看日志确认加载。再补充一个技巧测试 skills 是否生效不要用太复杂的任务用最简单、最典型的场景去验证。比如前端 skills你就让它生成一个最简单的主页写作类 skills你就让它写一段 100 字的产品介绍。如果基础场景响应了说明技能包逻辑是通的。一上来就测一个复杂任务出问题了你都不知道是技能包的问题还是任务本身的问题。4. 自己动手开发一个 skills格式拆解与避坑指南熟悉了安装和调用下一步自然是学会开发自己的 skills。这里要讲得更细一点因为“skills开发”是搜索热度很高的一个方向但相关的中文文档非常零散我通过逆向工程几个优秀开源项目把整个格式和工作原理拆解了一遍。4.1 SKILL.md 的文件结构关键词就是入口一个标准的 skills 由一个主文件SKILL.md和若干辅助文件组成。这个主文件是整个技能包的大脑决定了 AI 代理何时调用、如何执行任务。我第一次拆解的时候发现它和普通提示词最大的不同在于它明确告诉模型“什么时候不要用”。这是很多自制 skills 容易忽视的一点。一个完整的 SKILL.md 应该包含以下部分主描述段Description简述技能的名字、使用场景、调用的关键词。使用条件段When to use / When NOT to use明确说明什么样的任务适用、什么样的任务不适用。执行步骤段Execution steps按顺序列出的操作流程直接影响模型的行为路径。输出标准段Output standards告诉模型最终交付物的格式、风格、校验标准。补充参考段References指向仓库里的辅助文档、示例代码、模板文件。看一段我实际用过的高质量 skills 核心部分简化版# React Component Generator ## Description Generates TypeScript React components following company design system. ## When to Use - User asks to create a new UI component - User requests a form with validation - User mentions company button or check-button ## When NOT to Use - User asks for styling only (use CSS skill instead) - User asks for a full page layout (use page-builder skill instead) ## Execution Steps 1. Read references/component-template.tsx 2. Map user requirements to component props 3. Generate code using the template patterns 4. Include validation rules from references/validation-patterns.md ## Output Standards - TypeScript, not JavaScript - Use named exports, not default exports - Include JSDoc for all props你有没有注意到“使用条件段”才是 skills 的灵魂。模型的调用策略比提示内容更容易出错——如果一个技能包被错误地用在 90% 的任务上不但不会提效反而会让基础能力大打折扣。我见过很多人做的 skills 只写了“这个技能可以做什么”完全没写“什么时候不要用它”结果一调用就出洋相。4.2 开发过程中的三个高频错误自己开发 skills 的时候最容易踩的坑集中在以下三个坑一写得像给人类的帮助文档不像给模型的执行指令。模型是通过概率匹配来理解文字的不要写“你应该根据情况灵活处理”要写“当用户提交的表单缺少 email 字段时自动补全一个默认邮箱格式的输入框”。给出的指令越具体、越有判断边界模型执行得就越精确。坑二引用文件路径写错了。skills 通常可以附带 references 文件但这部分路径在模型读取时极易出错。我建议在开发阶段专门用一个复杂任务来测试所有引用文件是否都能被正确读到不要只跑一次简单任务就觉得万事大吉。坑三没有边界测试。一个技能包写好了你得尝试用“不该触发它”的任务去测试它。比如你写了一个“分镜 skills”那就故意输入一个“给我写一篇美食测评文章”的任务看看它是不是还会跑出来乱接线。如果触发了错误的场景说明使用条件写得还不够明确。4.3 从“能用”到“好用”的三个进阶技巧写多了之后我发现优秀的 skills 和能用的 skills 之间差别往往就在几个细节第一在输出标准里加入对文件格式的硬性约束。比如“所有的 HTML 标签必须用双引号”“组件文件必须放在 src/components/”这种直接省掉 AI 产出后你手动改格式的步骤。第二把项目里最典型的错误范例写进去。不是只告诉它“应该怎么做”还要告诉它“你以前的代码里最容易犯的错误是啥”。AI 在生成代码时会刻意避开这些错误这对我们工程团队的代码质量帮助巨大。比如我们有个状态管理的 skills里面就记录了“不要在组件内部直接修改 redux store 的状态要用 reducer”这类反面约束。第三版本更新要谨慎。很多技能的迭代会破坏现有调用路径。我在实际使用中养成了一个习惯用 git 管理 skills 目录每次更新前先提交一版更新后跑一遍此前用过的测试任务。这样出了问题可以第一时间回滚而不是傻眼重写。5. 测试与场景验证如何系统化地评估一个 skills搜热词里面有个特别细节的词叫“agent skills测试”这说明很多人已经意识到测试的重要性了但很少看到有文章系统性地讲清楚测试方法。这里把我的测试方法论分享出来。我把 skills 的测试分成三层冒烟测试、边界测试、压力测试。这三层难度递增适合不同阶段使用。冒烟测试验证技能包能不能被正常加载和调用。方法很简单选一个该技能应覆盖的典型场景跑一次看能不能顺利走通。比如分镜 skills就让它生成一个 30 秒短视频的分镜脚本。边界测试验证技能包在“不该出现的时候”会不会出现。我一般准备三个不相关任务输入给 AI看是否误触发了这个技能包。如果误触发了问题出在 Description 和 When NOT to Use 写得不够好。压力测试验证技能包在复杂、多步骤任务中是否还能保持执行质量。比如让前端开发技能的模型一次性生成十个组件检查它们之间的一致性。很多技能包在简单任务里表现很好一上压力测试就原形毕露——输出开始重复、格式开始混乱。我做一个表格让你更清楚地对照不同测试方式的适用场景测试类型适用阶段核心目的通过标准冒烟测试技能包刚下载或刚开发完确认能被正常调用示例任务跑通输出符合预期边界测试调整调用策略时确认不会误触发三个无关任务均未触发该技能压力测试准备正式投入日常使用前确认复杂场景下稳定发挥多步任务执行完毕输出无错乱我在测试中发现一个很有用的技巧用同一套测试用例跑“装了技能”和“没装技能”两个版本的任务然后对比输出质量的差异。如果装了技能之后输出质量和没装差不多甚至更差说明这个技能包对你手头的任务没有正向价值直接删掉。这个体验非常反直觉因为很多技能包作者在写技能时想象了一个完美的场景实际跑出来的效果却不一定符合。我测试过的几十个技能包里真正能带来显著提升的大概只有三成左右。大部分技能包要么写得泛泛而谈要么和基础模型的能力重叠度太高。所以别收藏一堆技能包只留对你真实工作有帮助的否则每次任务触发时 AI 还要额外读取一堆无关的 SKILL.md白白浪费上下文窗口。6. 从效率工具到团队知识沉淀现实场景里怎么用好 skills前五节讲的都是个人使用层面的内容但 skills 真正让我兴奋的是它在团队场景里的应用潜力。我们团队目前在推进的一个实践是把团队内部的代码规范、技术文档、高频运维问题的解决方案统统沉淀为内部 skills。比如新同事入职的时候不用再花一周时间去翻各种文档直接在 AI 工具里就能基于公司自己的技能包干活。这不仅提升了效率还解决了团队知识沉淀的问题——以前写在 Wiki 里的知识没人看现在把它们变成 skills让 AI 在干活的时候自动带着规范走。但这里有个现实障碍目前的 skills 基本是跟着个人账户走的共享和分发的机制还不完善。如果你所在的团队要用我的建议是先统一工具的版本然后把技能包目录做成一个 git 仓库通过 code review 的方式来维护内容更新。这样既能用 git 管理版本迭代又能在多人协作时避免混乱。另外一个值得留意的场景是“自动挖洞 skills”。这个热词看起来很有意思但别误解为黑客工具实际上它更贴近自动化安全测试和漏洞扫描的范畴。我研究过几款这方面的开源 skills它们的思路是把安全测试的常见操作步骤打包进技能包让 AI 代理在接收到授权测试请求时自动按步骤走完信息收集、漏洞检测、报告生成这条链路。这种自动化能力依赖的是技能包把原本需要人工操作的流程固化下来然后交给代理自动执行。从正向开发的角度看这种思路完全可以迁移到日常的代码审计、依赖检查、权限配置检查这些场景里。7. 高频搜索里的疑难场景答疑附我的实测经验把搜索热词里涉及的问题集中整理一下有些是新手常问的有些是连老手也容易搞混的我按照自己实测的经验逐一回答。问装了 skills 之后为什么 AI 的表现没有明显变化答先做冒烟测试确认技能包确实被加载了。如果加载了但效果一般大概率是技能包质量一般或者它和你手头任务的匹配度不高。还有一种可能性你的任务本身就很简单基础模型已经能处理得很好技能包带来的增量感知不明显。这很正常技能的提升幅度取决于任务复杂度简单任务不需要技能包。问同一类 skills 装了多个会不会冲突答会。尤其是 Description 写的场景有重叠的技能包AI 代理可能会在同一个任务里同时参考两个技能包输出结果不伦不类。我的建议是同类技能包最多保留一个不要贪多。如果必须保留多个修改它们的 Description把应用场景区分得更清晰。问GitHub 上下载的 skills 和市场上的有什么本质区别答市场上的版本由官方审核和自动打包格式更有保障GitHub 上的往往包含作者的原始想法和最新迭代但你可能需要自己处理依赖和路径问题。如果你是新手优先用官方市场如果你喜欢折腾并且愿意看代码可以逛 GitHub。问自定义的 skills 可以分享给别人吗答可以。把整个文件夹压缩发过去或者在 git 仓库里共享别人放到自己的 skills 目录下即可。但注意技能包里如果包含你们公司的内部代码、密钥或者未公开的业务逻辑分享前一定要严格脱敏。我在开发团队内部技能包时习惯性地把代码里的业务关键词替换成演示用的 placeholder避免泄密。问skills 会不会被基础模型的版本升级影响答一定会。模型版本升级后模型对自然语言的理解方式会变化技能包里的指令描述可能产生歧义。所以每次工具升级后建议重新跑一遍冒烟测试。我经历过一次升级导致技能包里“When NOT to Use”部分被忽略的情况当时排查了很久才发现是升级导致的理解偏移。8. 最后一页笔记关于 skills 的几点个人体会走到这里关于 skills 是什么、怎么找、怎么装、怎么写、怎么测、怎么用都已经讲完了。最后再分享几条纯个人化的工作体会不系统但很真实。我在实际使用中发现“举一反三”是评估 skills 是否理解到位的最好标准。比如我装了一个代码审计类技能包如果它只能机械地告诉我“这里少了个分号”说明技能包没有真正理解业务上下文如果它能进一步提示“这段逻辑里缺少对空指针的判断和之前提过的某类异常场景相似”那这个技能包算是把领域经验吃透了。选技能包时我会刻意留意它对意外情况的处理这比它在标准流程上的表现更能说明问题。踩过几次坑之后我养成了一个习惯每周花半小时维护一下自己的技能包列表。删掉失效的、合并重复的、更新过时的。这个“整理衣柜”的习惯比不断下载新技能包更有效。技能包越多上下文越臃肿AI 的响应速度和准确率都在下降。最后还有一个建议用 git 管理你的 skills 目录别偷懒。有一次我调试一个自定义技能包改坏了不知道怎么回滚折腾了快一个小时。后来把整个 skills 目录纳入 git 管理每次改动前先提交一版改动后如果出了问题直接回退省心太多。这个习惯甚至帮我避免过几次团队里因为技能包更新导致的协作问题。skills 是一个正在高速演化的事物。也许再过一年它的格式、分发方式、和工具的集成深度都会发生巨大的变化但“把特定场景的专家经验固化下来让通用 AI 按需调用”这个底层思路一定会越来越成熟。希望这篇文章能帮你少走一些弯路更早地把 skills 用出真正的价值。
