最近AI圈子里最热的一个词就是skills。从 Anthropic 官方发布 Claude Agent Skills到 OpenAI Codex 把 skills 当作默认扩展机制再到 GitHub 上冒出一堆“superpowers”“awesome-skills”之类的合集仓库几乎一夜之间所有人都在讨论“怎么给 AI 装外挂”。我前阵子把一个写了很久的内容生成流程全部改造成 skills 体系顺手把几个前端项目里的重复性工作也封装成了技能实测下来效率提升非常明显。今天就把我对 skills 的理解、上手过程、踩过的坑、以及目前值得关注的下载平台和资源完整整理出来希望能帮到正在观望或已经入坑的同学。先给一个定义方便对得齐频道skills 是面向 AI Agent 的可复用技能包本质上是把“一段提示词 若干参考脚本/数据文件 使用说明”打包成一个标准目录让 Claude、Codex 这类编程智能体在不改代码的情况下学会执行某个具体任务。它不是插件不是 API更像是一种“给 AI 看的使用说明书 工具箱”。1. 为什么 skills 突然就火了1.1 从“聊天”到“干活”AI 工作流的范式转移过去两年大家用 AI 的主要方式是对话打开对话框把需求打进去AI 给你一段代码、一篇文章、一个方案。这种方式适合“问问题”但干不了“重复性的复杂活儿”。举个很直观的例子我想让 AI 帮我做一份前端项目的代码规范审查每次都要把规则、目录结构、检查项重新描述一遍AI 还不一定理解到位输出水准忽高忽低。skills 解决的就是这个问题。相当于你把“如何做代码规范审查”这个过程包括审查清单、检查脚本、报告模板、典型问题库一次性打包成技能。之后无论何时需要AI 都能稳定复现这套流程输出质量稳定、风格统一而且不需要你反复解释需求。这就是工作流的范式转变从“每次重新描述”到“一次封装、反复使用”。这跟我们以前写函数、封装组件的思路一模一样——编程领域早就证明了“复用”的价值AI Agent 领域现在正在走同样的路。1.2 skills 和插件、工具调用的本质区别刚接触 skills 的人最容易困惑它跟插件Plugin、工具调用Function Calling有什么不一样我用一个生活化的类比解释。插件相当于你给 AI 装了一个“新器官”——比如装了浏览器插件AI 就有了“眼睛”能看网页装了代码执行器AI 就有了“手”能跑代码。每个插件都对接了具体的 API 或运行时能力。而 skills 更像是“操作手册 工具箱”。它不一定调用新 API更多时候是教 AI 如何更好地使用已有的能力。比如我有一个“代码审查” skill里面没有调用任何外部服务只是提供了一套完整的审查方法论、规则列表、评分标准和示例报告AI 用自己的语言理解能力加上这套方法论就能输出高水准的审查结果。本质上插件解决“能不能做”skills 解决“怎么做更专业”。两者可以配合使用插件提供能力底座skills 定义专业流程。理解了这一点你就能明白为什么 skills 对多数普通用户和开发者来说门槛更低——你不需要会写 API 集成只需要会写文档就能做出一个很有用的技能。1.3 为什么 Claude 和 Codex 都在押注 skillsAnthropic 在 2025 年公开了 Claude Agent Skills 规范紧接着 OpenAI 的 Codex 也把 skills 作为官方推荐的扩展方式。巨头们不约而同押注同一件事说明这不是临时起意的功能点而是 Agent 时代的底层基础设施。往深了说这背后有一个共识大模型的通用能力已经很强了但“专业能力”必须靠外部知识来补充。模型再大也不可能记住所有领域的全部方法论而 skills 恰好提供了一种低成本、高灵活性的外部知识注入方式。不用微调、不用向量数据库、不用重新训练写几个 Markdown 文件就能让 AI 变专业这是所有厂商都愿意支持的轻量方案。对我们普通用户来说这也意味着 skills 是一个值得长期投入的技能方向。今天学会的技能明天换一个 Agent 平台大概率还能用学习成本不会浪费。2. skills 的核心原理第一性原理解读2.1 SKILL.md一份“给 AI 看的使用说明书”所有 skills 的核心都是SKILL.md文件。这个名字起得很直白SKILL 点 MD就是技能说明书。我最初以为这玩意儿玄机很深看完规范才发现它本质上就是我们再熟悉不过的 Markdown 文档只是按特定结构组织。一份规范的SKILL.md通常包含几个部分技能名称与简述让 AI 快速理解这个技能是干什么的适用场景什么时候该用、什么时候不该用避免 AI 误触发工作流程一步步列出执行步骤AI 会严格按照这个顺序操作输入要求需要用户提供哪些信息格式是什么输出规范最终产物应该长什么样包含哪些部分注意事项边界、禁忌、容易出错的地方。你可以把它理解成一份“给 AI 看的操作 SOP”。大语言模型的强项就是读文档你把流程写得越清晰它执行得就越准确。这也解释了为什么 skills 的官方规范里反复强调“用自然语言写清楚步骤”而不是写代码——AI 是靠语义理解的不是靠函数调用。2.2 目录结构与文件组织一个技能一个文件夹除了SKILL.md一个完整的 skills 还包含其他资源文件组织方式非常朴素一个文件夹就是一个技能文件夹里放着说明文档和配套资源。我见过一个写周报的技能结构大致是weekly-report/SKILL.md技能说明书weekly-report/templates/周报模板weekly-report/examples/几份优秀的周报示例weekly-report/checklist.md自查清单。这种“一个文件夹承载一个完整技能”的设计带来两个巨大好处。第一分发极其简单拷贝文件夹就能分享第二迭代极其方便想改进技能直接改文件就行不需要任何编译或构建流程。这种极简设计背后其实体现了非常好的工程判断想让人人都能创造和分享门槛必须足够低。2.3 触发机制AI 怎么知道“该用技能了”这是我自己琢磨了很久的一个问题我装了 50 个技能AI 怎么知道在什么场景用哪个目前的实现方式主要是“靠模型自主判断”或者说叫“语义触发”。AI 在读取系统提示或了解自身能力清单时会看到所有可用技能的简述。当对话内容与之匹配时模型会自动检索并调用对应的技能。比如你让 AI“帮忙审查这段代码”它看到代码审查技能的描述是“检查代码质量、发现潜在问题、给出规范建议”就会自动把技能内容加载进来然后按里面的流程执行。这种机制很像人类专家的知识调用记忆里存了很多方法论遇到具体问题时调出对应的方法。好处是灵活不需要用户手动指定但代价是描述质量决定触发准确度——如果你的技能描述写得模棱两可AI 就容易在错误的场景调用它。所以我的经验是给技能写“适用场景”和“不适用场景”时宁可多写几句也别用太模糊的话。后面讲开发实战的部分我再展开聊这个细节。3. 从零上手安装、启用、管理 skills 的实操全流程3.1 Claude 官方市场的安装路径如果你用 Claude上手 skills 最直接的方式就是官方市场。操作路径非常清晰打开 Claude 客户端或 Claude Code进入设置里的 Skills 或能力市场浏览分类列表选中需要的技能一键启用。我在第一次安装时其实犯了个小错误——没有注意技能是否需要在特定目录下生效。后来弄清楚了Claude 的 skills 默认放在用户目录下的某个.claude/skills文件夹里你也可以在项目里放.claude/skills实现“仅对当前项目生效”。这是个特别有用的特性全局技能处理通用事务项目技能处理特定代码库的专属任务。安装第三方技能时最常见的方式是把技能目录手动拷贝到.claude/skills下然后重启会话。注意是新开一个会话才生效已经开着的会话不会自动加载新技能。这个细节我踩过还以为是技能写错了排查了半天。3.2 Codex 环境下的 skills 引入OpenAI Codex 支持 skills 的方式跟 Claude 大同小异同样是目录扫描加语义识别。把技能文件夹放进 Codex 指定的 skills 目录新会话里 AI 就能看到并调用。我个人的体会是Codex 在技能发现和加载的“透明感”上做得更激进一些你甚至可以直接在对话里问 AI“你有哪些可用技能”它会列出当前环境加载的技能清单。这个能力用来排查问题特别有用比如技能没生效你一问就知道是根本没加载还是加载了但没被触发。如果你经常在 Claude 和 Codex 之间切换建议保持两套技能目录都指向同一个文件夹或者用同步脚本把技能目录推送到两边。我目前是维护一个主技能目录用一个小脚本同步到各个 Agent 环境方便统一管理。3.3 手工安装第三方技能正确姿势与避坑从网上下载的第三方技能包安装步骤其实很死板但很多人第一步就搞错了。正确做法是首先解压或克隆技能仓库检查里面是否包含SKILL.md文件——如果连这个都没有那它就不是一个标准技能包装了也没用。然后把整个技能文件夹注意是包含SKILL.md的那层目录而不是仓库根目录放到 Agent 对应的技能目录里。这里有个特别容易混淆的地方很多技能仓库里还有README.md、LICENSE、示例代码等无关文件你只需要拷贝包含技能定义的那部分即可别一股脑全塞进去。最后重启会话测试。测试时不要直接提完整需求而是先用一句话喊出技能目标比如“使用代码审查技能分析 src 目录下代码”看 AI 是否进入了对应的工作流。确认生效后再逐步提升任务复杂度。一定要认准技能文件的格式和 Agent 平台的兼容性。有些技能是为 Claude 定制的里面用到了 Claude 特有的 prompt 技巧放到 Codex 下效果可能打折。反之亦然。选技能时不能只看标题炫不炫要看它的设计对象。4. 自己动手开发一个 skills完整实战记录4.1 选场景什么样的任务最适合做成技能不是所有任务都值得做成技能。我的判断标准很简单这个任务是否具有“可重复的专业流程”。比如“帮我写一段 Python 代码”就不适合太泛了但“帮我给 API 接口写 OpenAPI 文档并附上每个字段的说明样例”就非常适合因为接口文档有固定的结构规范和检查项。初次尝试时建议从“你本人非常熟悉、且流程高度标准化”的任务入手。因为 skills 的核心是输出你的方法论只有你自己最懂这件事的完整流程和常见坑点。我这个“代码审查”技能就是从自己平时 review 代码的清单里梳理出来的前后花了大概两小时第一版就很能打。我强烈不建议为了做技能而做技能去网上找一个冷门流程文档翻译一下就当技能用。那样做出来的东西AI 执行起来很木因为你本身不了解里面的细节遇到边界情况根本不知道该给 AI 补充什么。4.2 编写 SKILL.md一份能“指挥” AI 的说明书有了场景之后最核心的工作就是写SKILL.md。我写这份文件的原则是“像给刚入职的实习生写操作手册”每一步都要明确、无歧义。下面是我实际用的一个精简示例基于“前端代码审查”技能--- name: frontend-code-review description: 对前端项目进行代码质量审查检查组件设计、依赖使用、可访问性、性能隐患并输出分级问题清单。 --- # 前端代码审查 ## 适用场景 - 用户要求对某个前端项目/目录进行代码审查 - 用户提交了一段 React/Vue 组件代码要求给出改进建议 - 希望在上线前发现潜在问题 ## 不适用的场景 - 用户只要求解释代码含义不涉及质量评估 - 用户要求自动修改代码那是另一个技能 ## 执行流程 1. 先查看项目根目录下的 package.json了解技术栈和脚本命令 2. 扫描目标目录下的所有 .tsx/.ts/.vue 文件排除 .test. 文件 3. 按以下检查维度逐项审查 - 组件拆分是否超过 200 行是否需要抽离子组件 - 依赖引用是否有未使用的 import是否有引入整个库但只用了个别函数的情况 - 可访问性img 是否有 alt按钮是否有可读文本 - 性能是否存在不必要的内联函数重复创建、大列表渲染 4. 生成审查报告按 [严重/一般/建议] 分级输出这个文件看起来简单但它已经说清楚了“什么时候用、不用在哪儿、先做什么后做什么、重点查什么、输出什么”。AI 照着执行查出来的问题往往比我口头提示它时更全面。这里我特别想强调描述description字段的分量。它写在文档开头的 YAML 头里是模型判断“何时触发技能”的主要依据。我第一次写的时候只写了“前端代码审查”后来发现 AI 经常在读代码时不戴上这个技能。改成上面这种带场景细节的描述后触发准确率提升非常明显。4.3 配套资源与示例把“经验”固化下来只有SKILL.md的技能能干活但离“好用”还有距离。真正让技能产生质变的是配套资源。我通常会在技能文件夹里加一个examples目录放入 2 至 3 份“优秀的输出样例”。这些样例对 AI 的约束作用比任何文字描述都强相当于给模型一个“照着这个样子输出”的锚点。举个例子我的“接口文档生成”技能里放了两个示例文档一个是简洁版、一个是详细版。AI 生成新文档时会自觉匹配其中一种风格而不是自己发挥出一版格式奇怪的东西。这在调模型输出一致性时是最省力的手段。另外如果任务涉及重复的机械判断强烈建议把判断逻辑写成一个脚本放到scripts目录里。比如审查技能里我放了一个check-unused-deps.jsAI 可以调用它快速扫描未使用的依赖。这比让 AI 一行行读代码靠谱得多——人眼读一万行会累AI 的注意力窗口也是有限的。4.4 迭代与测试像调参一样打磨技能技能做出来不是一劳永逸的。我每次用技能只要发现 AI 有理解偏差或产出质量不达标就回去改SKILL.md把歧义句改得更细把遗漏的步骤补上。这种“用后即改”的迭代一周下来技能就会变得极其顺手。测试阶段我建议准备一个“最小化测试集”3 至 5 个不同难度的任务每次修改技能后全部跑一遍看输出是否稳定。这其实跟做软件开发一个思路要有回归测试意识。否则你今天改好了 A 场景很可能把 B 场景改坏了自己还没察觉。5. skills 生态与下载平台去哪里找现成的技能5.1 官方与半官方渠道最省心的选择我先说渠道优先级能走官方就走官方。Claude 的官方市场聚合了大量经过审核的技能包质量和安全都有一定保障适合新手。OpenAI 的 Codex 同样内置了技能浏览能力可以直接在界面上查找启用。这些官方渠道的另一个好处是更新及时会跟随模型能力的变化而优化技能写法。除官方市场外Anthropic 和 OpenAI 的官方 GitHub 仓库里也公开了不少示例技能。这些示例往往结构非常规范非常适合新手当作“活教材”来学习——我自己就是通过读官方示例学会了SKILL.md的标准写法。如果你是技能开发者逛这些仓库的收益比逛什么教程都大。5.2 社区聚合平台量大但需要筛选社区生态是我目前找技能的主战场。GitHub 上搜 “awesome-skills” 或 “skills collection” 能翻到大量聚合仓库里面按场景分类整理了成百上千个技能包。还有几个专门收录 AI Agent 技能的镜像站点和导航站做得像当年的插件商店浏览体验很好。使用社区技能时我强烈建议看看三个指标更新时间超过半年没更新的技能大概率跟不上当前模型能力慎重Star 数/下载量不是绝对标准但能反映其他用户的试用反馈作者后续维护记录看作者是否在持续修问题而不是一次性发布就消失。我把常用的下载来源整理成了一个小表格方便快速对照渠道类型典型资源特点适合人群官方市场Claude Skills 市场、Codex 技能库质量把关、更新及时、安全可靠新手、生产环境官方示例仓库Anthropic skills GitHub、OpenAI examples规范标准、学习价值高技能开发者、进阶学习者社区聚合仓库awesome-skills 类仓库数量庞大、场景齐全、但质量参差有筛选能力的老手技术博主/开发者个人仓库各类 personal-skills通常带有独特方法论、风格鲜明对特定领域有需求者5.3 怎么判断一个技能值不值得装我的筛选清单网上技能这么多看到标题感兴趣就装很快你的技能目录就变成垃圾场了。我总结了一套筛选办法分享给大家。第一看SKILL.md的前 30 行。如果前 30 行里没有写清楚触发条件、使用流程、输出规范之一那么这个技能的沉淀程度基本不够装了大概率不好使。真正高质量技能一定会在开头就把“什么时候用、怎么用”说明白。第二看有没有示例输出。我自己发布技能时必然带examples所以我也要求别人发布的技能带示例。没示例的技能AI 输出全凭想象质量波动很大。第三上手测试时先用“玩具数据”。不要一上来就把核心工作交给它。让 AI 用技能处理一个极小的简化任务看它的行为是否符合预期。这个 5 分钟测试能省下后面一整天的返工时间。6. 高频踩坑与排查技巧实录6.1 技能装了半天不生效先查这几个地方这是新手遇到最多的问题我把它放在第一位。技能不生效八成不是技能本身的问题而是环境问题。优先排查路线如下技能文件是否放在了正确的目录层级很多技能包解压后外层多套了一层父文件夹导致 Agent 扫描不到是否重启了会话前面说过已开启的会话不会加载新技能必须新开会话技能文件夹里是否有SKILL.md没有这个文件整个文件夹会被忽略是否有重名技能互相覆盖两个同名技能放一起系统可能只加载其中一个。我还遇到过一种极具迷惑性的情况技能部分生效。AI 能说出技能的名字但执行流程不对。后来发现是我在调用时需求描述里给了太多额外信息把技能流程覆盖了。这种情况下你只要明确说一句“严格按 XX 技能的流程执行”通常就能拉回来。6.2 技能冲突与目录污染如何管理一大堆技能技能装多了冲突问题就会浮现。最常见的冲突是“功能相似但方法论不一致”——比如装了三个写周报的技能每个要求的输出格式都不一样AI 触发时不知道选哪个或者混着用。我的管理方案是分类子目录。把所有技能按“写作 / 编程 / 数据分析 / 研究检索 / 生活管理”分成几个大类每类只保留 1 至 2 个最顺手的技能。这个做法有两个好处一是减少 Agent 扫描时的选择混淆二是降低冲突概率同类技能只留一个最强方案。另一个容易忽略的问题是“技能幻觉”AI 描述自己有某个能力其实那个技能文件早已被删除或失效。每次遇到这种情况我会让 AI 列出当前可用的技能清单跟磁盘上的实际文件对照一遍清掉失效条目。6.3 上下文窗口与性能技能不是越多越好一个不常被讨论但其实很关键的点技能会消耗模型的上下文窗口。Agent 在会话开始时加载技能描述加载得越多留给实际对话内容的空间就越少。有段时间我装了 20 多个技能结果发现 AI 聊天质量明显下降回答变得泛泛而谈。排查后发现就是技能描述把上下文挤占了。这背后的逻辑不复杂但值得想透模型处理上下文的能力是有限的你塞给它的系统知识太多它就没有足够的余地来处理你的具体问题。所以做减法很重要。一个会话场景下让 AI 加载的技能控制在 5 个以内质量是最稳的。其他技能让它按需动态加载就好。6.4 安全问题别什么技能都往自己环境里装老实说skills 的安全风险比大多数人意识到的要大。因为技能天然包含“指引 AI 执行一系列操作”的能力恶意技能完全可以诱导模型去执行危险的命令、读取敏感文件、外传信息。我的安全底线是三条不装来源不明的技能尤其是不认识的小号发布的、只有 README 没有代码审阅记录的技能不装需要联网回传数据的技能即使要用我也会先读一遍它的脚本和输出逻辑对技能目录做定期审查每个月清理一次不认识的、不再用的技能。另外要特别提醒前阵子安全圈分析了一些恶意技能包表面上是“自动挖洞”“脱壳”之类的工具背后却夹带了数据收集逻辑。这类所谓“黑客专用技能”一方面是合规风险高另一方面安全质量毫无保障。碰都别碰。最后分享一点个人体会我做完整个 skills 体系改造后回头看发现它给我最大的收益其实不是“效率提升”那部分而是倒逼我把自己的工作方法论给整理了出来。写SKILL.md的过程就是把你脑子里模糊的、跳步的、靠感觉的做事习惯变成清晰、步骤化、可传授的经验。这件事本身的价值甚至比让 AI 干活还要大。所以如果你今天只打算做一件事我建议不要把时间花在到处下载技能上而是选一件你每天都在做的重复性工作把它写成一个技能。哪怕写得粗糙哪怕只给自己用这个过程会让你以一种全新的视角审视自己的工作方式。下一次再遇到什么“XX 又出了新技能合集”的热搜你也不用焦虑了。技能这种东西就像工具屋里的一把把螺丝刀真正值钱的不是攒一大堆而是你手里那几把最趁手、最懂自己活路的好家伙。
AI Skills是什么？从原理到实战，给AI装外挂的完整指南
最近AI圈子里最热的一个词就是skills。从 Anthropic 官方发布 Claude Agent Skills到 OpenAI Codex 把 skills 当作默认扩展机制再到 GitHub 上冒出一堆“superpowers”“awesome-skills”之类的合集仓库几乎一夜之间所有人都在讨论“怎么给 AI 装外挂”。我前阵子把一个写了很久的内容生成流程全部改造成 skills 体系顺手把几个前端项目里的重复性工作也封装成了技能实测下来效率提升非常明显。今天就把我对 skills 的理解、上手过程、踩过的坑、以及目前值得关注的下载平台和资源完整整理出来希望能帮到正在观望或已经入坑的同学。先给一个定义方便对得齐频道skills 是面向 AI Agent 的可复用技能包本质上是把“一段提示词 若干参考脚本/数据文件 使用说明”打包成一个标准目录让 Claude、Codex 这类编程智能体在不改代码的情况下学会执行某个具体任务。它不是插件不是 API更像是一种“给 AI 看的使用说明书 工具箱”。1. 为什么 skills 突然就火了1.1 从“聊天”到“干活”AI 工作流的范式转移过去两年大家用 AI 的主要方式是对话打开对话框把需求打进去AI 给你一段代码、一篇文章、一个方案。这种方式适合“问问题”但干不了“重复性的复杂活儿”。举个很直观的例子我想让 AI 帮我做一份前端项目的代码规范审查每次都要把规则、目录结构、检查项重新描述一遍AI 还不一定理解到位输出水准忽高忽低。skills 解决的就是这个问题。相当于你把“如何做代码规范审查”这个过程包括审查清单、检查脚本、报告模板、典型问题库一次性打包成技能。之后无论何时需要AI 都能稳定复现这套流程输出质量稳定、风格统一而且不需要你反复解释需求。这就是工作流的范式转变从“每次重新描述”到“一次封装、反复使用”。这跟我们以前写函数、封装组件的思路一模一样——编程领域早就证明了“复用”的价值AI Agent 领域现在正在走同样的路。1.2 skills 和插件、工具调用的本质区别刚接触 skills 的人最容易困惑它跟插件Plugin、工具调用Function Calling有什么不一样我用一个生活化的类比解释。插件相当于你给 AI 装了一个“新器官”——比如装了浏览器插件AI 就有了“眼睛”能看网页装了代码执行器AI 就有了“手”能跑代码。每个插件都对接了具体的 API 或运行时能力。而 skills 更像是“操作手册 工具箱”。它不一定调用新 API更多时候是教 AI 如何更好地使用已有的能力。比如我有一个“代码审查” skill里面没有调用任何外部服务只是提供了一套完整的审查方法论、规则列表、评分标准和示例报告AI 用自己的语言理解能力加上这套方法论就能输出高水准的审查结果。本质上插件解决“能不能做”skills 解决“怎么做更专业”。两者可以配合使用插件提供能力底座skills 定义专业流程。理解了这一点你就能明白为什么 skills 对多数普通用户和开发者来说门槛更低——你不需要会写 API 集成只需要会写文档就能做出一个很有用的技能。1.3 为什么 Claude 和 Codex 都在押注 skillsAnthropic 在 2025 年公开了 Claude Agent Skills 规范紧接着 OpenAI 的 Codex 也把 skills 作为官方推荐的扩展方式。巨头们不约而同押注同一件事说明这不是临时起意的功能点而是 Agent 时代的底层基础设施。往深了说这背后有一个共识大模型的通用能力已经很强了但“专业能力”必须靠外部知识来补充。模型再大也不可能记住所有领域的全部方法论而 skills 恰好提供了一种低成本、高灵活性的外部知识注入方式。不用微调、不用向量数据库、不用重新训练写几个 Markdown 文件就能让 AI 变专业这是所有厂商都愿意支持的轻量方案。对我们普通用户来说这也意味着 skills 是一个值得长期投入的技能方向。今天学会的技能明天换一个 Agent 平台大概率还能用学习成本不会浪费。2. skills 的核心原理第一性原理解读2.1 SKILL.md一份“给 AI 看的使用说明书”所有 skills 的核心都是SKILL.md文件。这个名字起得很直白SKILL 点 MD就是技能说明书。我最初以为这玩意儿玄机很深看完规范才发现它本质上就是我们再熟悉不过的 Markdown 文档只是按特定结构组织。一份规范的SKILL.md通常包含几个部分技能名称与简述让 AI 快速理解这个技能是干什么的适用场景什么时候该用、什么时候不该用避免 AI 误触发工作流程一步步列出执行步骤AI 会严格按照这个顺序操作输入要求需要用户提供哪些信息格式是什么输出规范最终产物应该长什么样包含哪些部分注意事项边界、禁忌、容易出错的地方。你可以把它理解成一份“给 AI 看的操作 SOP”。大语言模型的强项就是读文档你把流程写得越清晰它执行得就越准确。这也解释了为什么 skills 的官方规范里反复强调“用自然语言写清楚步骤”而不是写代码——AI 是靠语义理解的不是靠函数调用。2.2 目录结构与文件组织一个技能一个文件夹除了SKILL.md一个完整的 skills 还包含其他资源文件组织方式非常朴素一个文件夹就是一个技能文件夹里放着说明文档和配套资源。我见过一个写周报的技能结构大致是weekly-report/SKILL.md技能说明书weekly-report/templates/周报模板weekly-report/examples/几份优秀的周报示例weekly-report/checklist.md自查清单。这种“一个文件夹承载一个完整技能”的设计带来两个巨大好处。第一分发极其简单拷贝文件夹就能分享第二迭代极其方便想改进技能直接改文件就行不需要任何编译或构建流程。这种极简设计背后其实体现了非常好的工程判断想让人人都能创造和分享门槛必须足够低。2.3 触发机制AI 怎么知道“该用技能了”这是我自己琢磨了很久的一个问题我装了 50 个技能AI 怎么知道在什么场景用哪个目前的实现方式主要是“靠模型自主判断”或者说叫“语义触发”。AI 在读取系统提示或了解自身能力清单时会看到所有可用技能的简述。当对话内容与之匹配时模型会自动检索并调用对应的技能。比如你让 AI“帮忙审查这段代码”它看到代码审查技能的描述是“检查代码质量、发现潜在问题、给出规范建议”就会自动把技能内容加载进来然后按里面的流程执行。这种机制很像人类专家的知识调用记忆里存了很多方法论遇到具体问题时调出对应的方法。好处是灵活不需要用户手动指定但代价是描述质量决定触发准确度——如果你的技能描述写得模棱两可AI 就容易在错误的场景调用它。所以我的经验是给技能写“适用场景”和“不适用场景”时宁可多写几句也别用太模糊的话。后面讲开发实战的部分我再展开聊这个细节。3. 从零上手安装、启用、管理 skills 的实操全流程3.1 Claude 官方市场的安装路径如果你用 Claude上手 skills 最直接的方式就是官方市场。操作路径非常清晰打开 Claude 客户端或 Claude Code进入设置里的 Skills 或能力市场浏览分类列表选中需要的技能一键启用。我在第一次安装时其实犯了个小错误——没有注意技能是否需要在特定目录下生效。后来弄清楚了Claude 的 skills 默认放在用户目录下的某个.claude/skills文件夹里你也可以在项目里放.claude/skills实现“仅对当前项目生效”。这是个特别有用的特性全局技能处理通用事务项目技能处理特定代码库的专属任务。安装第三方技能时最常见的方式是把技能目录手动拷贝到.claude/skills下然后重启会话。注意是新开一个会话才生效已经开着的会话不会自动加载新技能。这个细节我踩过还以为是技能写错了排查了半天。3.2 Codex 环境下的 skills 引入OpenAI Codex 支持 skills 的方式跟 Claude 大同小异同样是目录扫描加语义识别。把技能文件夹放进 Codex 指定的 skills 目录新会话里 AI 就能看到并调用。我个人的体会是Codex 在技能发现和加载的“透明感”上做得更激进一些你甚至可以直接在对话里问 AI“你有哪些可用技能”它会列出当前环境加载的技能清单。这个能力用来排查问题特别有用比如技能没生效你一问就知道是根本没加载还是加载了但没被触发。如果你经常在 Claude 和 Codex 之间切换建议保持两套技能目录都指向同一个文件夹或者用同步脚本把技能目录推送到两边。我目前是维护一个主技能目录用一个小脚本同步到各个 Agent 环境方便统一管理。3.3 手工安装第三方技能正确姿势与避坑从网上下载的第三方技能包安装步骤其实很死板但很多人第一步就搞错了。正确做法是首先解压或克隆技能仓库检查里面是否包含SKILL.md文件——如果连这个都没有那它就不是一个标准技能包装了也没用。然后把整个技能文件夹注意是包含SKILL.md的那层目录而不是仓库根目录放到 Agent 对应的技能目录里。这里有个特别容易混淆的地方很多技能仓库里还有README.md、LICENSE、示例代码等无关文件你只需要拷贝包含技能定义的那部分即可别一股脑全塞进去。最后重启会话测试。测试时不要直接提完整需求而是先用一句话喊出技能目标比如“使用代码审查技能分析 src 目录下代码”看 AI 是否进入了对应的工作流。确认生效后再逐步提升任务复杂度。一定要认准技能文件的格式和 Agent 平台的兼容性。有些技能是为 Claude 定制的里面用到了 Claude 特有的 prompt 技巧放到 Codex 下效果可能打折。反之亦然。选技能时不能只看标题炫不炫要看它的设计对象。4. 自己动手开发一个 skills完整实战记录4.1 选场景什么样的任务最适合做成技能不是所有任务都值得做成技能。我的判断标准很简单这个任务是否具有“可重复的专业流程”。比如“帮我写一段 Python 代码”就不适合太泛了但“帮我给 API 接口写 OpenAPI 文档并附上每个字段的说明样例”就非常适合因为接口文档有固定的结构规范和检查项。初次尝试时建议从“你本人非常熟悉、且流程高度标准化”的任务入手。因为 skills 的核心是输出你的方法论只有你自己最懂这件事的完整流程和常见坑点。我这个“代码审查”技能就是从自己平时 review 代码的清单里梳理出来的前后花了大概两小时第一版就很能打。我强烈不建议为了做技能而做技能去网上找一个冷门流程文档翻译一下就当技能用。那样做出来的东西AI 执行起来很木因为你本身不了解里面的细节遇到边界情况根本不知道该给 AI 补充什么。4.2 编写 SKILL.md一份能“指挥” AI 的说明书有了场景之后最核心的工作就是写SKILL.md。我写这份文件的原则是“像给刚入职的实习生写操作手册”每一步都要明确、无歧义。下面是我实际用的一个精简示例基于“前端代码审查”技能--- name: frontend-code-review description: 对前端项目进行代码质量审查检查组件设计、依赖使用、可访问性、性能隐患并输出分级问题清单。 --- # 前端代码审查 ## 适用场景 - 用户要求对某个前端项目/目录进行代码审查 - 用户提交了一段 React/Vue 组件代码要求给出改进建议 - 希望在上线前发现潜在问题 ## 不适用的场景 - 用户只要求解释代码含义不涉及质量评估 - 用户要求自动修改代码那是另一个技能 ## 执行流程 1. 先查看项目根目录下的 package.json了解技术栈和脚本命令 2. 扫描目标目录下的所有 .tsx/.ts/.vue 文件排除 .test. 文件 3. 按以下检查维度逐项审查 - 组件拆分是否超过 200 行是否需要抽离子组件 - 依赖引用是否有未使用的 import是否有引入整个库但只用了个别函数的情况 - 可访问性img 是否有 alt按钮是否有可读文本 - 性能是否存在不必要的内联函数重复创建、大列表渲染 4. 生成审查报告按 [严重/一般/建议] 分级输出这个文件看起来简单但它已经说清楚了“什么时候用、不用在哪儿、先做什么后做什么、重点查什么、输出什么”。AI 照着执行查出来的问题往往比我口头提示它时更全面。这里我特别想强调描述description字段的分量。它写在文档开头的 YAML 头里是模型判断“何时触发技能”的主要依据。我第一次写的时候只写了“前端代码审查”后来发现 AI 经常在读代码时不戴上这个技能。改成上面这种带场景细节的描述后触发准确率提升非常明显。4.3 配套资源与示例把“经验”固化下来只有SKILL.md的技能能干活但离“好用”还有距离。真正让技能产生质变的是配套资源。我通常会在技能文件夹里加一个examples目录放入 2 至 3 份“优秀的输出样例”。这些样例对 AI 的约束作用比任何文字描述都强相当于给模型一个“照着这个样子输出”的锚点。举个例子我的“接口文档生成”技能里放了两个示例文档一个是简洁版、一个是详细版。AI 生成新文档时会自觉匹配其中一种风格而不是自己发挥出一版格式奇怪的东西。这在调模型输出一致性时是最省力的手段。另外如果任务涉及重复的机械判断强烈建议把判断逻辑写成一个脚本放到scripts目录里。比如审查技能里我放了一个check-unused-deps.jsAI 可以调用它快速扫描未使用的依赖。这比让 AI 一行行读代码靠谱得多——人眼读一万行会累AI 的注意力窗口也是有限的。4.4 迭代与测试像调参一样打磨技能技能做出来不是一劳永逸的。我每次用技能只要发现 AI 有理解偏差或产出质量不达标就回去改SKILL.md把歧义句改得更细把遗漏的步骤补上。这种“用后即改”的迭代一周下来技能就会变得极其顺手。测试阶段我建议准备一个“最小化测试集”3 至 5 个不同难度的任务每次修改技能后全部跑一遍看输出是否稳定。这其实跟做软件开发一个思路要有回归测试意识。否则你今天改好了 A 场景很可能把 B 场景改坏了自己还没察觉。5. skills 生态与下载平台去哪里找现成的技能5.1 官方与半官方渠道最省心的选择我先说渠道优先级能走官方就走官方。Claude 的官方市场聚合了大量经过审核的技能包质量和安全都有一定保障适合新手。OpenAI 的 Codex 同样内置了技能浏览能力可以直接在界面上查找启用。这些官方渠道的另一个好处是更新及时会跟随模型能力的变化而优化技能写法。除官方市场外Anthropic 和 OpenAI 的官方 GitHub 仓库里也公开了不少示例技能。这些示例往往结构非常规范非常适合新手当作“活教材”来学习——我自己就是通过读官方示例学会了SKILL.md的标准写法。如果你是技能开发者逛这些仓库的收益比逛什么教程都大。5.2 社区聚合平台量大但需要筛选社区生态是我目前找技能的主战场。GitHub 上搜 “awesome-skills” 或 “skills collection” 能翻到大量聚合仓库里面按场景分类整理了成百上千个技能包。还有几个专门收录 AI Agent 技能的镜像站点和导航站做得像当年的插件商店浏览体验很好。使用社区技能时我强烈建议看看三个指标更新时间超过半年没更新的技能大概率跟不上当前模型能力慎重Star 数/下载量不是绝对标准但能反映其他用户的试用反馈作者后续维护记录看作者是否在持续修问题而不是一次性发布就消失。我把常用的下载来源整理成了一个小表格方便快速对照渠道类型典型资源特点适合人群官方市场Claude Skills 市场、Codex 技能库质量把关、更新及时、安全可靠新手、生产环境官方示例仓库Anthropic skills GitHub、OpenAI examples规范标准、学习价值高技能开发者、进阶学习者社区聚合仓库awesome-skills 类仓库数量庞大、场景齐全、但质量参差有筛选能力的老手技术博主/开发者个人仓库各类 personal-skills通常带有独特方法论、风格鲜明对特定领域有需求者5.3 怎么判断一个技能值不值得装我的筛选清单网上技能这么多看到标题感兴趣就装很快你的技能目录就变成垃圾场了。我总结了一套筛选办法分享给大家。第一看SKILL.md的前 30 行。如果前 30 行里没有写清楚触发条件、使用流程、输出规范之一那么这个技能的沉淀程度基本不够装了大概率不好使。真正高质量技能一定会在开头就把“什么时候用、怎么用”说明白。第二看有没有示例输出。我自己发布技能时必然带examples所以我也要求别人发布的技能带示例。没示例的技能AI 输出全凭想象质量波动很大。第三上手测试时先用“玩具数据”。不要一上来就把核心工作交给它。让 AI 用技能处理一个极小的简化任务看它的行为是否符合预期。这个 5 分钟测试能省下后面一整天的返工时间。6. 高频踩坑与排查技巧实录6.1 技能装了半天不生效先查这几个地方这是新手遇到最多的问题我把它放在第一位。技能不生效八成不是技能本身的问题而是环境问题。优先排查路线如下技能文件是否放在了正确的目录层级很多技能包解压后外层多套了一层父文件夹导致 Agent 扫描不到是否重启了会话前面说过已开启的会话不会加载新技能必须新开会话技能文件夹里是否有SKILL.md没有这个文件整个文件夹会被忽略是否有重名技能互相覆盖两个同名技能放一起系统可能只加载其中一个。我还遇到过一种极具迷惑性的情况技能部分生效。AI 能说出技能的名字但执行流程不对。后来发现是我在调用时需求描述里给了太多额外信息把技能流程覆盖了。这种情况下你只要明确说一句“严格按 XX 技能的流程执行”通常就能拉回来。6.2 技能冲突与目录污染如何管理一大堆技能技能装多了冲突问题就会浮现。最常见的冲突是“功能相似但方法论不一致”——比如装了三个写周报的技能每个要求的输出格式都不一样AI 触发时不知道选哪个或者混着用。我的管理方案是分类子目录。把所有技能按“写作 / 编程 / 数据分析 / 研究检索 / 生活管理”分成几个大类每类只保留 1 至 2 个最顺手的技能。这个做法有两个好处一是减少 Agent 扫描时的选择混淆二是降低冲突概率同类技能只留一个最强方案。另一个容易忽略的问题是“技能幻觉”AI 描述自己有某个能力其实那个技能文件早已被删除或失效。每次遇到这种情况我会让 AI 列出当前可用的技能清单跟磁盘上的实际文件对照一遍清掉失效条目。6.3 上下文窗口与性能技能不是越多越好一个不常被讨论但其实很关键的点技能会消耗模型的上下文窗口。Agent 在会话开始时加载技能描述加载得越多留给实际对话内容的空间就越少。有段时间我装了 20 多个技能结果发现 AI 聊天质量明显下降回答变得泛泛而谈。排查后发现就是技能描述把上下文挤占了。这背后的逻辑不复杂但值得想透模型处理上下文的能力是有限的你塞给它的系统知识太多它就没有足够的余地来处理你的具体问题。所以做减法很重要。一个会话场景下让 AI 加载的技能控制在 5 个以内质量是最稳的。其他技能让它按需动态加载就好。6.4 安全问题别什么技能都往自己环境里装老实说skills 的安全风险比大多数人意识到的要大。因为技能天然包含“指引 AI 执行一系列操作”的能力恶意技能完全可以诱导模型去执行危险的命令、读取敏感文件、外传信息。我的安全底线是三条不装来源不明的技能尤其是不认识的小号发布的、只有 README 没有代码审阅记录的技能不装需要联网回传数据的技能即使要用我也会先读一遍它的脚本和输出逻辑对技能目录做定期审查每个月清理一次不认识的、不再用的技能。另外要特别提醒前阵子安全圈分析了一些恶意技能包表面上是“自动挖洞”“脱壳”之类的工具背后却夹带了数据收集逻辑。这类所谓“黑客专用技能”一方面是合规风险高另一方面安全质量毫无保障。碰都别碰。最后分享一点个人体会我做完整个 skills 体系改造后回头看发现它给我最大的收益其实不是“效率提升”那部分而是倒逼我把自己的工作方法论给整理了出来。写SKILL.md的过程就是把你脑子里模糊的、跳步的、靠感觉的做事习惯变成清晰、步骤化、可传授的经验。这件事本身的价值甚至比让 AI 干活还要大。所以如果你今天只打算做一件事我建议不要把时间花在到处下载技能上而是选一件你每天都在做的重复性工作把它写成一个技能。哪怕写得粗糙哪怕只给自己用这个过程会让你以一种全新的视角审视自己的工作方式。下一次再遇到什么“XX 又出了新技能合集”的热搜你也不用焦虑了。技能这种东西就像工具屋里的一把把螺丝刀真正值钱的不是攒一大堆而是你手里那几把最趁手、最懂自己活路的好家伙。