文章详细探讨了 2026 年 AI 领域的热点技术——Skills。作者认为 Skills 是可复用的专家知识包，其核心价值在于将人类的隐性经验转化为 AI 可执行的显性 SOP。文中清晰界定了 Skills 与 Prompt（指令）、MCP（工具协议）的区别：Prompt 是单次任务，MCP 是工具箱，而 Skills 是操作手册。文章重点介绍了 Skills 的分层设计（元数据、正文、附加资源）如何有效节省上下文空间，并结合阿里 Qoder IDE 演示了如何安装 Anthropic 官方 Skills 以及利用 skill-creator 自动生成自定义 Skill。此外，作者还分享了 Qoder 的语音输入、多智能体并行、内置浏览器和自主智能体 Quest 1.0 等前沿特性，强调了 Skills 对提升团队协同效率和沉淀方法论的重要意义。
最近 Skills 实在是太火了。2026 年 AI 圈里的第一把火。大家一定要亲自上手试试。昨天群里一哥们拿着这张图开涮：
我觉得真没必要。Skills 就是一个伟大的创新。也许以后会有更好的思路出来，但现在来看，它对我们超级有用。
开开玩笑逗乐子可以，但如果排斥，就是个糊涂蛋。
给大家看一个非常简单的案例。这是我用 AI 生成的一个网站。整体不错，但也有浓浓的 AI 风。
Anthropic 官方有一个叫 frontend-design 的 Skill，它可以专门优化这类网站。
之前，优化 AI 网站，我们其实也是攒一堆提示词，然后按照流程逐步优化。但这事，完全可以 Skills 化。
我从 Anthropic 的 GitHub 克隆下来对应的 Skill 之后。装到自己的用户目录下。
我用的是阿里的 Qoder，所以，在用户目录下创建一个 .qoder 的文件夹，把具体的 Skill 放到 .qoder 下的 skills 文件夹下就行。
紧接着，再打开阿里的 Qoder IDE，就能够看到安装好的 Skills 了。很多同学不习惯 CLI，昨天我发现，阿里的 IDE 也是支持 Skills 的。下载链接如下：
在 IDE 右侧输入框，输入/Skill，就能看到当前安装好的 Skill。
装好 Skill 之后，我直接运行对应的 Skill。
下面这是根据 Skill 创建的待办任务。这些思路都源于刚才那个 Skill。
相当于我把 Anthropic 团队内部关于怎么优化网站的经验复用了过来。这就是 Skill 的价值。
一分钟之后，完成优化。你看下面优化过的网页效果，是不是看起来好了很多（Logo 和底图是我自己加的）。
那到底什么是 Skills 呢？
昨天看了阿里 Qoder 团队的一场直播，激发了我写篇文章聊下 Skills 的意义，以及上手给大家做一个最简单的实操教程。
话说这个直播讲的太通俗易懂了。简直是我最近看过最好的 Skill 分享。去 Qoder 的视频号就能找到这期内容。如果有认识邓忠阳大佬的朋友，求帮忙介绍。
Skills 是什么？
用一句话来说，Skill 就是一个可复用的专家知识包：把一套判断逻辑、执行 SOP 以及必要工具打包成一个模块，这样 AI 就可以按照预设的方式来执行任务。
举个例子，我们公司的工作习惯是每天早上大家需要在群里同步自己当天的 Todo List。
小团队，我觉得这样做可以让大家充分协同起来，而且 Todo List 本身就是一种时间的承诺。
我对 Todo List 的要求是要具体，不是写“今天处理用户反馈”，而是写“上午 10 点前回复 3 个工单，优先处理付费用户”。
但这事，每次来新人，我都要教一次，要不然他怎么可能知道我们团队的规则。
教 AI 其实是一回事。
AI 能干活，只是没办法按照我们预期的流程和思路干。它不知道我们的代码规范是什么，不知道出了问题该先查哪个服务，不知道日志里哪些关键字才是重点。
这些东西都在老员工脑子里，从来没有写下来过。每次都要从头教，教完这轮对话结束，下次还是一张白纸。
所以就有了 Skills。
它做的事情，就是把脑子里的隐性规则变成显性的文档。只要在 Skills 里把流程和规则描述清楚，AI 就能像一个真正上过手的老员工一样干活。
它知道该怎么判断，知道流程该怎么走，知道什么情况下该调用什么工具。不用你每次都盯着，也不用每次都从头解释。
这就是 Skills 的核心价值：把经验从人的脑子里搬出来，变成 AI 可以反复执行的能力模块。
Skills 和 Prompt、MCP 有什么区别？
Skills 不就是保存 Prompt 的地方吗？和 MCP 有什么区别？
这个问题值得单独说说，因为它们确实容易混淆。
先说 Prompt 和 Skills 的区别。
Prompt 通常是告诉 AI 干什么。帮我写一个函数，帮我解释这段代码，帮我查一下这个 bug。这是任务层面的指令。
Skills 做的事情不一样。它告诉 AI 怎么判断、怎么决策、整个流程应该怎么走。
打个比方。Prompt 像是你跟同事说，帮我查一下线上这个报错。
Skills 像是你给他一本手册：先看是哪个服务报的错，然后按照 A 到 B 到 C 的调用链路往下查，日志里重点关注这几个关键字，如果是数据库问题就执行这个诊断脚本。
一个是单次任务，一个是可复用的工作流程。
再说 MCP 和 Skills 的区别。
MCP 是给 AI 提供工具的协议。你可以理解为它让 AI 有了手，能操作外部系统，比如读写文件、调用 API、查数据库。
Skills 是给 AI 提供判断力和流程。它让 AI 知道什么时候该用哪个工具，按什么顺序用，遇到不同情况怎么处理。
所以它们不是互斥的，而是配合使用的。你可以在一个 Skill 里定义：当执行这个任务时，先调用这个 MCP 工具获取数据，然后根据结果判断下一步，如果遇到异常就调用另一个工具处理。MCP 提供能力，Skills 编排能力。
一句话总结：Prompt 是一次性指令，MCP 是工具箱，Skills 是操作手册。它们解决的是不同层面的问题。
Skills 长什么样？
接下来讲讲 Skills 具体长什么样，以及怎么用。
先说结构。
Skill 其实很简单，极简的 Skill 就是一个文件夹加一个 SKILL.md 文件。文件夹的名字就是这个 Skill 的名字，SKILL.md 里面写具体内容。
再复杂一点的 Skill，会包含附加的资源目录。比如有的 Skill 会用到 Python 脚本，会有参考的文档，这些都可以放进来。
所以更准确的说 Skill 的完整目录结构应该是这样：
skill-name/
├── SKILL.md # 必需，包含元数据和正文
├── scripts/ # 可选，可执行脚本（Python/Bash）
├── references/ # 可选，参考文档（API 文档、规范说明）
└── assets/ # 可选，资源文件（模板、图片）SKILL.md 分两部分。
第一部分是元数据，放在文件开头，用三个短横线包起来。里面有两个字段：name 是技能名称，description 是描述。
比如一个生成 mock 数据的 Skill，元数据可能长这样：
---
name: api-mocker
description: |
根据 API 定义生成 Mock 测试数据。
当用户说"生成mock数据"、"造测试数据"时使用。
---这个 description 特别重要，它是 AI 判断什么时候该用这个 Skill 的依据。写得越清晰，AI 匹配得越准。
第二部分是正文，写具体的规则和流程。还是拿 api-mocker 举例：
# API Mock 数据生成器
## 规则
1. 分析用户提供的接口定义
2. 根据字段名推断数据语义（name→姓名，email→邮箱）
3. 生成 5 条真实感数据
## 字段映射
- name/姓名 → 中文姓名（王晓明、刘思远）
- email → user_xxx@example.com
- phone → 138-XXXX-XXXX
- avatar → https://api.dicebear.com/7.x/avataaars/svg?seed=随机
## 输出
JSON 数组，用代码块包裹看到没，这就是一套完整的 SOP。AI 拿到这个，就知道该怎么一步步执行，而不是每次都靠它自己发挥。
除了 SKILL.md，文件夹里还可以放附加资源。比如 scripts 目录放可执行的脚本，references 目录放 API 文档或规范说明，assets 目录放模板和图片。
正文里可以引用这些资源，比如写“执行到这一步时，先调用 scripts/check_health.sh 检查服务状态”。
为什么要分成三层？这里有个设计思想叫渐进式披露。
AI 的上下文窗口是有限的公共资源。像 MCP 工具、自定义命令这些，通常要常驻在上下文里，每次对话都会占用空间。
如果你配了很多工具，上下文很快就被挤满，token 消耗也跟着上去。
Skills 的分层设计不一样。
第一层，元数据，始终在上下文里。但它很轻量，就几行字，让 AI 知道有哪些技能可用、大概什么时候该用。
第二层，正文，只有触发时才加载。AI 判断当前任务需要用某个 Skill，才会去读 SKILL.md 的正文内容。
第三层，附加资源，按需加载。正文里如果写了"执行到这一步调用某个脚本"，AI 执行到那一步才会去读。
这就像一本书。目录始终在手边，让你知道有哪些章节。但你不会一开始就把整本书背下来，而是翻到哪章读哪章。这样你可以配很多 Skills，而不用担心上下文爆炸。
再说存储位置。
Skills 可以放两个地方。拿阿里的 Qoder 举例子。
一个是全局目录，在 ～/. qoder/skills/。放在这里的 Skill 所有项目都能用，适合那些通用能力，比如 PDF 处理、代码审查。目录结构像这样：
~/.qoder/skills/
├── pdf-processing/
│ └── SKILL.md
├── code-reviewer/
│ └── SKILL.md
└── ...另一个是项目目录，在项目根目录下的 .qoder/skills/。放在这里的 Skill 只有当前项目能用，适合那些跟特定项目强相关的能力。
比如这个项目的微服务架构知识、这个项目特有的排查流程。目录结构像这样：
your-project/
└── .qoder/
└── skills/
└── microservice-troubleshooter/
└── SKILL.md项目级的 Skills 有个好处：可以跟代码一起提交到仓库。团队成员 clone 下来就能用，不用再单独传文件、发文档。
新人入职第一天，项目的 Skills 就已经在他的工作环境里了。
再说怎么触发。
两种方式。
第一种是自动触发。你正常描述需求，AI 会根据 description 自动匹配。
比如你说“帮我查看这个 PDF 的内容”，它会自动找到 pdf-processing 这个 Skill；你说“帮我造点测试数据”，它会匹配到 api-mocker。
这就是为什么 description 要写清楚，它决定了 AI 能不能在对的时机调用对的技能。
第二种是手动调用。用斜杠加技能名，比如 /pdf-processing，强制使用某个 Skill。
或者在对话里明确说“用 pdf-processing skill 帮我处理这个文件”。当你明确知道要用哪个技能时，手动调用更直接。
想看当前有哪些 Skill 可用，输入 /skills 就能看到完整列表。
它会分开展示用户级和项目级的 Skills，还能看到每个 Skill 的描述。选中某个 Skill 回车，还能预览里面的具体内容。
在 Qoder 中实操 Skills
Qoder 是阿里的 Coding 工具，它的形态有 IDE、插件和 CLI。
接下来，我给大家演示下怎么在 IDE 里玩 Skills。现在 Qoder 对于新用户来说，前两周免费，所以大家完全可以在不付费的情况下体验。
如前面所说，Skill 可以装到两个地方。一个是我自己的项目目录下，这时候只对当前项目生效。一个是用户目录下，这会对所有的项目生效。
现在网上有很多别人做好的 Skills。比如下面这个链接，是 Anthropic 分享的一些好用的 Skill。
https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md
我们可以把这些 Skill 克隆下来，放到自己的文件夹下。比如下面的截图，我它放到了当前项目下。
咱们随便进入一个 Skill 的文件夹来看看，这和我们前面提到的结构一模一样。
紧接着，我们再在 IDE 里验证下这些 Skill 是不是已经装好了。
复制完文件之后，大家记得要重启下 IDE，这样才能检测到。如下图，右侧的列表，代表已经装上了。
现在这些 Skills 装好了之后，就可以像前面那样运行了。
接下来我想说说 Skills 怎么创建。
Skill 的核心是刚刚反复提到的 md 文件。这个 md 文件，如果纯手写，多少还是有些复杂的。所以官方也提供了一个 Skill 来帮我们创建 Skill。
哈哈，套娃了。
我现在使用的流程是，第一，先自己梳理一份自己的流程。用自然语言写就行。
第二，基于这个流程，让 skill-creator 来生成一个最终的 SKILL。
第三，在这个初稿的基础上，基于自己的经验手动修改。
下面我先根据自己的理解梳理了一个阿颖文风的 md 文档，然后告诉它，基于这个文档，用 skill-creator 创建一个 Skill。
可以看到，它已经调用了对应的 Skill。
等大概不到一分钟，这个 Skill 就能创建好：
其实很多场景下，第一步都不用自己手动梳理。可以先让 AI 去 Research，拿到结果后再让它生成 Skill 的初稿。
以上，就是整体的流程。
再啰嗦两句，我最近反而非常喜欢 CLI。我知道对于很多人来说，可能大家会觉得 CLI（终端）需要学习很多命令，不如图形界面方便。
但我的感觉是，只要熬过最初的 3 天适应期后，你立马会感觉到 CLI 很爽。因为它简单，沉浸。确实非常适合创造。
我公司的几个同事，都是非 IT 背景，我也教会了他们用 CLI。
其实就简单的学习下 cd（进入文件夹）、vim（编辑文件）、pwd（展示目录）、cp（复制文件）、mkdir（创建文件夹）这几个命令就好了，再配合 Tab 键，真的用起来非常爽，像飞翔一样的感觉。
Qoder 几个最新特性
我发现 Qoder 迭代速度还是非常快，而且最近上线了一些很好用的特性。我挑几个自己最喜欢的讲：
第一，语音输入。
我现在已经完全习惯了语音输入。包括写这篇文章，我也是先用语音输入法说出来，再润色优化。因为这能极大提升输入效率。
很多时候其实是手比脑子慢，脑子得等手。但语音就没这个问题，只要开始表达思路能一气呵成。
Qoder 最近上线了语音输入功能，就在右下角，点击麦克风图标就能直接输入，不用依赖任何第三方语音输入法。
我自己试了一下，在办公室里很小声地对着电脑麦克风说话，它都能完全准确识别出来。识别准确率挺高的。
第二，多智能体并行。
这个功能解决了我一个长期痛点。
以前经常遇到这种情况：正让 AI 帮我重构一段代码，突然想起还有个 bug 要定位，或者需要查个技术文档。
但因为是单线程对话，要么等它写完，要么打断当前任务.....特别麻烦。
Qoder 最新的多智能体并行会话，其实说白了就是让我可以同时开好几个对话窗口，各干各的活儿。
一个窗口在帮我写新功能，一个窗口在排查线上报错，一个窗口在梳理技术方案或者翻文档。这几件事可以同时进行，互不干扰。
最新的 0.3.1 版本已经支持这个功能了。我现在基本习惯了一个主线开发加两三个辅助窗口的工作模式。
第三个是内置浏览器智能体。
内置浏览器智能体可以实时打开网页、检索最新信息、分析页面内容。我们不再需要自己去复制链接、找资料、再贴回来问一次。
很多前端验证、网页操作、文档查阅类任务，终于可以交给它真上网完成。
比如写代码的间隙，我想看看 Elasticsearch 最近更新了哪些特性。
之前，我就得跳出 IDE，打开浏览器去翻腾。但现在，直接在 IDE 内，告诉我的需求就行。
类似的场景其实还有很多。调研竞品功能时，让它直接去目标网站上看实际交互逻辑。或者验证前端样式问题，让它打开测试环境页面自己检查元素。
第四，Quest 1.0。
Quest 1.0 终于发布了，我们可以把它理解成 Qoder 中的自主智能体。这个接下来绝对是重头戏。
今年 AI Coding 一个重要的迭代方向就是让 AI 像人一样自主的工作，而不是像之前一样，我们盯着流程，一步一步推进。
Quest 的目标，是让 AI 拿到一个明确目标后，自己往前推进。它会自己拆解任务，自己决定先做哪一步，然后执行，再检查结果。
如果发现有问题，会再改一轮。整个过程是循环推进的，不需要人每一步确认。
很多人用 AI 写代码，第一轮效果不错，后面反复修改时反而变差。原因在于模型原本训练形态更偏对话，对长时间连续执行的优化有限。
Quest 就是在补这块能力，让它在长链路任务里保持稳定。
并且在很多场景里，人反复参与微小决策，其实会拖慢整体节奏。
所以，Quest 这类产品的设计理念是，把人放在更高层做目标确认和方向判断，让 AI 在底层反复试错、修正，减少 human in the loop。
人负责大的判断，AI 负责具体的执行。
我举个自己最近的例子。
我们公司最近有一些美元业务，所以总需要开 invoice。我拿到一个 invoice 的 PDF 之后，直接让 Qoder 帮我做一个生成 invoice 的网站。
提示词非常简单，就是把需求说清楚。然后它自动调用了相关的 Skill，把指令理解之后就开始干活了。我就可以去忙别的，等一会儿回来看执行结果。
下面这是等了十分钟，它给我生成的效果。测试了下，直接能用。
类似的网站，我谷歌搜了几个，都是付费的。但我可以十五分钟按照自己的想法创造一个。
从这个角度看，Quest 已经不只是简单的 AI Coding 工具了，它真的已经是数字劳动力。
我只需要描述清楚想要什么，中间那些查文档、写代码、调样式的过程，都可以交给它自己完成。
确实是全新的编程模式。
写在最后
Skills 这个东西，之所以能这么火，肯定是它命中了一些痛点需求。我觉得这种设计让我们第一次可以把做事的方法，快速沉淀成能反复调用的流程和经验。
以前很多经验都在脑子里，或者散落在群聊、文档、旧项目里。现在这些东西可以被结构化，被安装，被共享。
这确实是一次质的突破。虽然 Workflow 在这两年里一直都很火，但 Anthropic 这家公司做出了更简单易用的方式。
最近我们团队在强调，所有可以流程化的事儿，是不是可以考虑抽象为一个 Skill。这样经验就可以在团队内复制，而且也能够用 AI 提升效率。
当我们开始用 Skill 的方式去思考问题，会慢慢发现：
原来很多重复劳动，其实都可以流程化。原来很多团队默契，其实都可以写清楚。原来很多所谓的老员工优势，也可以变成一个文件夹。
AI 已经可以开始承载团队的工作方法。这就是它带来的变化。
有意思的是，Skill 这东西千万不要理解成只对工程师有意义。
其实它对所有人都通用，只不过一开始在 Claude Code 里头，好多非工程师人群不会用，所以传播是从小圈子开始的。
我前面提过，我们团队从运营到产品经理到研发，都在用 Skill，都在玩 Skill。每个岗位其实都有自己的方法论，都有值得沉淀的东西。
所以与其围观，不如亲自装一个 Skill 跑一遍。哪怕只是把自己的一套小习惯写成 SKILL.md，试过一次就明白它的价值在哪儿。
2026 年刚开年，这把火已经点起来了。真正的差距，可能就是从愿不愿意上手开始拉开的。
这是最近写过最长的一篇了。阿里的 Qoder 非常好用，这次也是让我开天眼了。。。。IDE 做的很不错。