最近几周我把业余时间基本都花在淘 Agent Skills、测 Skills、写 Skills 上。说实话这东西给人带来的爽感很直接——给一个 AI 助手装上“前端开发 skills”它写出来的代码风格、工程结构、注释规范立刻就不一样了装上“论文写作 skills”它甚至能主动规划章节、搭建论证逻辑、生成参考文献框架。这也是很多人把它叫superpower skills的原因不是给模型换脑子而是重新编排它干活的方式。Skills 的本质并不难理解但热词太多了容易绕晕。简单说它是一套由“说明文件 脚本 示例”组成的技能包Agent 在接到相关任务时会主动加载这套说明按里面的步骤、规范和模板去执行。和普通提示词相比它自带可复用的操作流程和 MCP 工具相比它解决的不只是“调用外部系统”而是“把一件事做得更专业”。下面把实际摸索出来的东西整理一遍包括设计思路、官方市场与下载平台怎么用、Claude Code / Codex / Reasonix 这些环境怎么装 skill、如何开发自己的 skill最后把踩过的坑和排查方法一并放出来。1. Skills 到底是什么——从“会说话”到“会干活”很多朋友第一次听说 skills第一个问题是它和提示词有什么区别我原来也这么想。我试了半年多各类提示词工程总结、角色扮演、思维链都玩过但效果总是不够稳定。提示词更像“叮嘱”模型每次都重新理解你的要求同一句话换个场景可能就跑偏。Skills 的逻辑完全不同它给 Agent 提供了一份结构化的“操作手册 工具箱”Agent 干活的时候可以随时翻手册、用工具而不是靠临场猜。1.1 一个 SKILL.md 背后是什么官方推荐的 skill 目录结构通常是这样my-skill/ ├── SKILL.md # 技能说明书Agent 的“操作手册” ├── scripts/ # 可执行脚本Agent 按需调用 │ ├── check.py │ └── generate.py └── examples/ # 输入输出示例帮助 Agent 理解任务类型 ├── input.md └── output.mdSKILL.md 是整个技能包的核心。它用 Markdown 写成开头有一段 YAML 格式的元信息类似--- name: frontend-review description: 用于前端代码审查检查组件设计、性能隐患和可访问性问题返回结构化评审报告。 --- # 使用场景 当用户要求审查前端代码、优化页面性能时使用。 # 操作步骤 1. 梳理组件树识别重复渲染点 2. 检查状态管理方案是否合理 3. 对照性能清单逐项打分 ...Agent 在决定调用哪个 skill 时首先读的就是 description。如果任务描述和 description 匹配它就会加载整个 SKILL.md按里面的步骤执行。scripts 和 examples 则给 Agent 提供更具体的工具和参考相当于把“操作手册”里的知识变成可运行的东西。1.2 Skills、MCP、Prompt 的定位差异三者放在一起看更清楚。MCP 解决的是“连接外部系统”比如读数据库、调 API、操作浏览器Prompt 解决的是“一次性告诉模型怎么做”Skills 解决的是“把一套专业流程固化下来让 Agent 反复使用”。对比维度Prompt 提示词MCP 工具Skills 技能包核心形式一段文字接口与工具协议文档 脚本 示例解决什么问题临场引导系统连接与数据访问流程规范与行为模式复用性弱每次都要重申强接口可复用强整套流程可复用可维护性差改一处影响全局中按接口维护好一个技能一个目录对模型的要求模型要“听懂”模型要“会用”模型要“照着做”用生活化的例子说Prompt 是你在景点门口给导游交代“我今天想看古迹”MCP 是给导游配上地图、交通卡和购票 AppSkills 则是直接带一位熟悉当地历史、会安排路线、还知道哪家餐厅不坑人的专家型导游。前两者解决“能到”Skills 解决“做得好”。1.3 为什么说它是 superpowerSkills 之所以被夸成“超能力”是因为它把 Agent 从“知识型助手”推向“操作型助手”。知识型助手只能回答你“应该怎么做”操作型助手真的能按专业流程做出来。举个例子。我用过一个叫 code-review 的 skill它会把评审流程拆成安全检查、性能评估、可读性检查、测试覆盖检查四个环节每个环节有具体打分规则。以前让 AI“帮我看看这段代码有没有问题”它只会泛泛说几嘴装上 skill 之后它会主动问有没有运行日志、要不要跑测试、组件边界在哪最后输出一份带修复建议的完整报告。这种专业度的提升不是多写几行提示词能比的。另一个关键点是Skill 是可以组合的。一个擅长写前端页面组件的 skill可以和另一个擅长做视觉走查的 skill 叠加使用。Agent 会像人一样先写组件再自查视觉细节。这种“能力组装”的体验才是 superpower skills 的核心感觉。2. 生态与平台选型——别再用“到处找安装包”的方式了Skills 的生态这两年长得很快。我一开始也是满互联网搜“skills 安装包下载”后来才发现最省事的路子其实是先看官方市场和 GitHub 上的公开仓库。很多整理好的 skills 合集质量比个人分享的散包高得多而且更新频率有保障。2.1 官方市场与下载平台现状目前主流 Agent 基本都有自己或社区维护的 skills 仓库。Anthropic 官方在 GitHub 上有专门的 skills 集合覆盖前端开发、后端编程、数据分析、文档处理等高频场景Codex 生态里也有很多用户分享的 skills尤其适合写论文、做代码补全和个人效率工具Reasonix 这类相对小众的 Agent 环境社区里也有现成的搬运整理。我在 GitHub 上逛得比较多的几类仓库场景合集型把几十个小技能放在一个仓库里安装时按需挑选适合新手快速体验。单技能深入型一个仓库就做一个技能文档详细、脚本完整质量普遍更高适合做生产级使用。平台适配型同一个 skills 目录同时兼容 Claude Code、Codex、Reasonix 等多个环境减少重复维护成本。判断一个 skills 仓库好不好我一般先看三点README 是否写了适用场景和依赖环境SKILL.md 的 description 是否清晰scripts 目录里的脚本有没有做异常处理。如果三样都全基本可以放心用。2.2 Claude Code、Codex、Reasonix 的安装差异不同 Agent 的 skills 安装方式大同小异核心都是“把技能目录放到 Agent 能找到的路径下”。以我常用的三个环境为例Agent 环境安装方式技能存放位置备注Claude Code官方插件市场或手动安装项目级./skills、用户级~/.claude/skills支持/plugin指令可加载 GitHub 仓库CodexCLI 命令安装~/.codex/skills或项目.codex/skillscommand 是codex skills addReasonix复制目录到指定文件夹~/.reasonix/skills需要手动创建 skills 目录文档较少我也见过有人把下载好的 skills 压缩包解压后直接扔进项目的.claude/skills或.codex/skills文件夹效果一样。很多所谓“支持全线 Agent”的技能包本质就是一个标准目录放到谁家都能被识别。2.3 安装前先想清楚的三件事装 skills 之前我不建议直接复制一堆热门包进去。先想清楚三件事能省后边很多事。第一任务边界。你要装的是解决“写文案”还是“做数据分析”的能力技能包不是越多越好每个技能包都会占据 Agent 的上下文和思考空间装太杂反而降低响应速度和准确度。第二依赖环境。有些 skills 依赖 Python 3.11、Node 18 或特定 CLI 工具装之前先确认本机满足条件不然技能包装上脚本却跑不起来。第三维护责任。第三方 skills 不一定长期维护如果它已经很久没更新遇到模型升级可能出现兼容问题要留好卸载方案。做过这步评估再去逛市场或 GitHub心里就有底了。我看到不少新手从“找安装包”到“安装失败”再到“放弃”基本都是因为跳过了这一步。3. 实战安装与开发——从“装一个”到“造一个”光看概念不够真正动手装一次才能理解 skill 的运行机制。这一节我把完整流程写细一点包括从官方市场安装、手动配置目录、写一个最小可用的前端开发 skill以及测试技能的三步方法。3.1 从官方市场安装一个 skill在 Claude Code 里安装官方市场 skill 最方便。先添加官方市场源再安装具体技能包# 添加 Anthropic 官方 skills 市场 claude plugin marketplace add anthropics/skills # 安装 skills 集合 claude plugin install skillsanthropic安装完成后可以通过/plugin status查看已加载插件。如果是 Codex命令稍有不同# 直接从 GitHub 仓库添加一个 skills codex skills add owner/repo-nameReasonix 这类没有专门命令的环境可以把下载好的 skill 目录放进~/.reasonix/skills然后重启对话让它重新扫描。实测下来多数 Agent 对目录结构并不挑剔关键就是路径正确、SKILL.md 解析正常。3.2 手动安装目录结构与 SKILL.md 写法手动安装适合两件事一是官方市场里没有你想要的功能二是自己开发了一个技能想先本地验证。手动安装的本质就是“把技术文档写好再配上一两个可执行的脚本”。目录结构保持跟官方推荐一致特别是 SKILL.md 必须放在技能目录的最顶层。SKILL.md 的开头 YAML 元信息我会特别注意 description 的写法因为它直接决定 Agent 会不会调用这个技能。模糊的 description 是失败最常见的原因。--- name: html-to-component description: 将 HTML 原型图或静态页面转换为可复用的 React / Vue 组件。 ---description 要写清楚“输入是什么、输出是什么、适用场景是什么”。不写“帮助用户”而是写“当用户给出 HTML 或页面截图时生成对应的 React/Vue 组件代码”。这样 Agent 在匹配任务时命中率会高很多。正文部分会包含使用步骤、编码规范、边界情况处理。Agent 执行任务时会把整份文档塞入上下文所以正文尽量精简、结构化用列表和代码示例避免大段散文。3.3 写一个最小可用的前端开发 skill以我写的html-to-component为例完整的 SKILL.md 是这么组织的--- name: html-to-component description: 将 HTML 原型图或静态页面转换为可复用的 React / Vue 组件包含样式提取和交互拆分。 --- # 使用步骤 1. 分析输入 HTML 的结构识别语义化标签 2. 提取样式类名映射到 CSS Modules / Tailwind 3. 拆分为子组件保持单一职责 4. 输出组件代码与使用示例 # 编码规范 - 组件使用 TypeScript 编写 - 样式优先使用 Tailwind必要时配合 CSS Modules - 事件处理函数统一以 handle 开头 - 导出版本支持 tree-shaking # 边界情况 - 遇到内联事件时提醒用户迁移到事件委托 - 遇到页面级布局时建议拆为 layout 组件不是页面组件scripts 里我会放一个extract_styles.py用来读取 HTML 并提取所有 class 名和对应样式减少人工拷贝。examples 里放一组“输入 HTML / 输出组件”的对比样例帮助 Agent 理解输出长什么样。整个技能包建好后放到./skills/html-to-component/下重启对话即可生效。3.4 测试技能的三步法技能写完先别急着发布我一般用三步测试法。第一步是“空跑测试”直接问 Agent“你会 html-to-component 吗”看它能不能正确描述技能用途并询问用户提供 HTML。这能验证 SKILL.md 有没有被正确解析。第二步是“标准样例测试”从 examples 里拿一个输入让 Agent 按技能流程走完对比输出是否接近预期。如果输出偏差大就检查步骤描述和代码示例是否明确。第三步是“边界测试”准备一些异常输入比如空文件、无样式标签、嵌套过深的 HTML看 Agent 在处理边界情况时会不会绕开技能规范、自己发挥。实测中发现很多技能没问题问题出在环境依赖上。比如某个 skill 的脚本要求 Python 3.10而本机装的是 3.8运行直接挂。所以脚本开头我会加一段环境检查不满足条件就给出明确提示而不是抛一堆看不懂的报错。4. 好用的 Skills 推荐与场景清单技能包的生态已经覆盖了很多具体场景。下面按我实际用过的场景整理一份清单也说说每个场景适合什么人、怎么选技能。4.1 高频场景速览场景推荐技能方向适用人群我的使用体感前端开发组件生成、代码审查、性能诊断前端工程师、全栈开发者组件生成最省时审查报告有点啰嗦论文写作章节规划、论证逻辑检查、参考文献格式化研究生、科研人员、公众号作者章节规划很有用参考文献格式能省半小时分镜创作分镜脚本生成、镜头语言分析短视频创作者、编剧镜头语言分析超预期能直接给分镜表数据分析数据清洗、图表推荐、报告撰写运营、数据分析师图表推荐不如直接让 AI 画但报告结构很好安全巡检自动化漏洞扫描、基线核查安全测试人员风险高只在授权的靶场环境里用个人效率邮件回复、信息整理、待办拆解所有知识工作者信息整理最实用待办拆解有点模板化GitHub 上还有一个容易混淆的概念叫 GitHub Skills那是官方推出的交互式学习仓库用来学 GitHub Actions、代码 review 流程等跟 AI Agent 的 skills 不是一回事。搜索时留意区分。4.2 如何评估一个 skills 值不值得装面对一堆“skills 大全”“skills 推荐”的帖子别急着全装。我一般先用“三看”过滤看场景是否高频比如每周都会写前端组件那装前端开发 skills 就值看 description 是否明确如果描述模糊到“帮助用户处理问题”基本可以先放进垃圾箱看维护记录最近半年有没有更新有没有人提 issue。第二步是“先试后留”装好后用一个真实任务跑一遍对比装之前和装之后的输出差异。如果差异不大说明技能包的内容没有真正进入 Agent 的工作流属于低价值技能。如果差异明显但效果变差比如结构僵化、过度模板化也需要调整或卸载。4.3 用组合的方式搭建自己的工作流单个技能解决单点问题组合起来才是完整工作流。我现在的日常流程是前端开发 skills 负责写代码code review skills 负责检查数据分析 skills 负责跑报表论文写作 skills 负责整理文档。四个技能组合使用后很多重复性的“搬砖”工作已经可以交给 Agent 独立完成。组合时要注意控制技能数量。我试过一次性挂 10 个技能Agent 每个技能都想用最终输出反而混乱。建议一个项目里只保留 3 到 5 个核心技能通过项目级目录隔离不要全部放到用户级目录里。5. 常见问题与排查技巧实录最后这部分把我踩过的坑集中写一下。多数问题不是技能包本身的问题而是使用和配置习惯导致的。5.1 技能已安装但 Agent 就是不调用这是我最初最头疼的问题。技能装上了目录也放了Agent 却像没看见一样。排查后发现大部分原因是 SKILL.md 里的 description 写得太模糊。Agent 决定是否调用技能时主要看 description 措辞如果描述和用户问题的语义不一致它就不会触发。解决办法是重写 description尽量用动词开头明确写出“当用户提供 X 时生成 Y”。比如“当用户粘贴 HTML 或请求把页面转成组件时输出 React 组件代码”就比“用于帮助用户理解 HTML 并生成组件”命中的概率高得多。另外要确认技能目录有没有被 Agent 加载有些环境需要在配置里指定额外的 skills 路径。5.2 依赖环境不一致导致脚本运行失败很多好用的 skill 依赖外部工具比如 puppeteer、python-docx、ffmpeg。装技能的人在自己的环境里能用不代表你的环境也能跑。At the beginning I wrote“装前先确认依赖”但总有漏网之鱼。我的习惯是在技能目录里加一个requirements.txt或dependencies.md写明需要的系统和库版本。手动安装第三方技能时先看一眼有没有这种文件没有就直接打开 scripts 目录看 import 和 require 语句反推它依赖什么。跑不通的概率能降到很低。5.3 上下文被技能包占满SKILL.md 会在 Agent 执行任务时作为上下文的一部分加载写得越长占的 token 越多。有些社区的“skills 大全”包一个 SKILL.md 能写三四千字夹带大量冗长的代码示例结果 Agent 还没开始干活上下文就吃掉一大半。我会遵守“SKILL.md 不超过 800 字”的原则正文只写步骤、规范和关键边界详细代码放 scripts 和 examples让 Agent 按需读取。如果发现某个技能让整体响应明显变慢第一反应就是精简它的 SKILL.md而不是换模型。5.4 避坑速查表症状常见原因排查/解决方案Agent 不调用技能description 不匹配或太模糊重写 description动词开头写清输入输出技能运行报错依赖环境不满足查看 requirements 和 scripts 里的 import响应变慢SKILL.md 太长上下文占满精简 SKILL.md控制在 800 字内技能互相干扰同时加载了太多技能项目级目录隔离保留 3~5 个核心技能输出太模板化技能步骤过死缺少灵活性在步骤中加入“根据用户反馈调整细节”之类的分支提示| 特定技能安装不上 | 仓库目录结构和官方格式不一致 | 检查 SKILL.md 位置、YAML 开头是否正确 | | 升级后技能失效 | 模型对新格式不兼容 | 查技能仓库是否有更新或改用官方维护版 |很多人一上来就追求“技能全装”我反而是反过来的。目前我最常用的仍然只有三个前端开发、论文写作、信息整理。真正深刻的东西不在“装了多少”而在于“用没用好”。Agent Skills 本质上是把你专业经验里的流程、标准、判断框架转成一份 Agent 能读得懂的说明书让它把你的活干得跟你一样细。如果我只能留一个建议那就是先别急着收藏别人的“skills 大全”挑一个你日常重复性最高的任务照着 SKILL.md 的格式把自己脑子里的操作流程写出来装进 Agent 里跑一次。只要体验过一次“它按你的方法来干活”你就会明白为什么那么多人把这个叫superpower skills。