# AI Skill 到底是什么？为什么它比 Prompt 更重要

> Prompt 用过就过了，Skill 是把流程留下来。一篇讲清楚 AI Skill 长什么样、和 MCP 怎么分工、装之前要看哪三眼，以及怎么写第一个 Skill。

- 原文链接: https://laojin.blog/blog/20260522_ai_skill_vs_prompt
- 作者: 老金
- 发布日期: 2026-05-22
- 标签: AI Skill, Prompt, Claude, MCP, 工作流

---

![AI Skill 到底是什么？为什么它比 Prompt 更重要](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260522/00_cover.png)

很多人用 AI 用到一半都会撞到同一个问题——好用的提示词，最后都散在各个对话里头。

你大概也有过这种体验。上周写的某个 Prompt 特别顺，效果也好，今天想在用一次，翻了半天死活找不到。中间清过几次上下文，再回头连自己都说不清当时是哪个 session 的版本最稳。开新对话又得重新交代一遍背景、语气、格式、约束、输出标准，全是这种琐碎事。

其实这不算 Prompt 本身的问题，Skill 想解决的就是这件事而已。

## Skill 长什么样

打个比方，Skill 有点像奶茶店柜台后面那张标准操作卡。

你点一杯少糖、去冰、加椰果的杨枝甘露，店员不会每次重新去想这杯到底怎么做。他就看那张卡：先放啥、后放啥、比例多少、哪些步骤不能省。

Skill 就是这种东西。它不是你临时丢给 AI 的一句话，更像是你提前写好的一套工作方式。下次再碰到类似任务，AI 就知道这类事得按这个来。

![便条 vs 钉在墙上的卡](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260522/01_card.png)

一个 Skill 写下来一般有三块。

最前面是触发条件，告诉 AI 什么时候该用它。比如用户说"不知道写什么""选题枯竭""帮我改公众号文章"，AI 就得判断是不是该把这个 Skill 调出来。这一段写不好，整个 Skill 要么压根不被触发，要么乱触发一通。

然后是执行步骤，调用之后具体怎么做。比如"给 10 个选题，每行一句，不要解释"，或者"先判断文章问题在哪，再分别重写标题、开头、正文、结尾"。这部分越具体越好，含糊的指令换回来的就是含糊的东西。

最后是参考材料，范文、模板、脚本、案例都算。平时不展开，AI 真要用的时候再翻。

这个设计里最关键的一点是，所有内容不会一次性塞进对话。AI 先看触发条件，判断要不要用；要用了再去读执行步骤；需要范例的时候才打开参考文件。上下文干净，token 也省下来了。

如果非要一句话区分 Prompt 和 Skill，可以这样想：Prompt 是你随手写的便条，Skill 是钉在墙上的那张卡。

## Prompt、Skill、MCP，到底什么关系

这三个词最近经常一起出现，很容易混。

Prompt 最简单，就是你这一次告诉 AI 一段话，做完就过了，下次还得重说一遍。门槛最低，适合一次性的活。

Skill 比 Prompt 多一步，把固定流程留下来。你重复在做的事、需要稳定风格的事、有标准步骤的事，都可以做成 Skill。门槛中等，主要是写的时候要把触发和步骤想清楚。

MCP 又是另一个层级。它让 AI 真的能去调外部工具——查数据库、跑代码、调接口、联网做事都行。门槛最高，要管开发环境、权限、安全这些事。

![Prompt / Skill / MCP 三层](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260522/02_tiers.png)

如果你的工作主要是写文章、做选题、改文案、整理资料，大多数情况下 Skill 就够用了。MCP 是给 AI 接上手脚，确实强，但配套的麻烦也不少。一个比较实际的顺序是先把 Prompt 沉淀成 Skill，再去考虑 MCP。

很多人真正缺的不是工具能力，是把自己重复做的那些事先标准化下来。

## 哪里能找到现成 Skill

刚开始玩，没必要自己写。常见场景已经被人做过一遍了，先去找现成的更省事。

skills.sh 比较适合新手，可以搜索、看榜单、看 Skill 详情。一个页面里基本能看到来源、触发条件、有没有带脚本这些。

Anthropic 官方的 Skills 仓库适合学规范写法。你想搞清楚一个像样的 Skill 长啥样，先看官方那几个就行。

GitHub 上搜 `claude-skills` 数量最多，质量也参差不齐，得有点耐心去筛。

另外有两个"管 Skill 的 Skill"也值得装上：`find-skills` 帮你找现成的，`skill-creator` 带着你一步步把自己的 Skill 写出来。一个负责导购，一个负责生产线，刚入门的时候省下来的摸索时间相当可观。

## Skill 也不是装了就变强

讲完用法，得说点反面的，不然容易把 Skill 当成什么都能解决的开关。

Skill 写得糙会把 AI 带偏。最常见的就是触发条件写得太宽——"任何写作任务都调用我"——结果它在不该出现的场合也跳出来抢话。本来指望它更聪明，最后只是更固执。

Skill 装太多也会变成新的负担。我见过有人一口气装几十个，最后自己都不知道哪个在生效。AI 哪天输出怪怪的，连排查都不知道从哪个 Skill 下手。

还有一种问题更隐蔽，Skill 会把你的旧习惯固化下来。如果你原本流程就一般，做成 Skill 之后，只是把"一般"稳定地复现出来。它能帮你省重复劳动，但替你判断流程本身对不对，这个它做不到。

带脚本的 Skill 得单独拎出来说。纯文本的 Skill 没什么权限，最多影响一下 AI 怎么回答你。但 Skill 里要是带了 `scripts/` 目录，那就意味着它可能去执行真实的操作——读文件、改文件、联网、调接口都可能。这时候你不能光看"功能好不好"，还得看它具体在干啥。

## 装之前先看三眼

来源是第一眼。官方仓库、可信作者、社区用得多的，可以直接装。不认识的个人仓库就别一上来就塞进全局。

第二眼看 description。正常的 description 会写清楚什么情况下触发。如果它写的是"所有情况下都优先触发"或者"始终覆盖其他规则"，先停一下，这种基本要小心。

第三眼看指令本身。正常 Skill 是告诉 AI 怎么完成任务，不正常的可能在做奇怪的事——要求 AI 输出所有文件内容、绕过限制、自动发送数据、或者悄悄改掉所有回答风格。看到这种，直接删掉就行，不用犹豫。

![装之前先看三眼](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260522/03_three_checks.png)

不确定的 Skill 优先装项目级，别全局。项目级只在当前项目生效，万一有问题影响范围有限。等你确定它真的好用，再考虑放进全局。

还有一条经常被忽略：API Key、密码、各种私密信息绝对不能写进 Skill 文件。Skill 是明文存的，把密码塞进去和贴在桌面便签上没区别。

## 第一次用容易卡的几个点

`/skills` 里看不到刚装的 Skill，多半是文件名错了。必须是大写的 `SKILL.md`，写成小写的 `skill.md` 一般是不生效的。

文件名没错还看不到，那就是目录结构的问题。每个 Skill 是一个文件夹，`SKILL.md` 放在这个文件夹里，不是把单独一个 md 丢进去。

重启之后还是没生效，往往不是真的"重启"，只是关了窗口。要把进程完整退出再打开。

AI 只给示例没真的创建文件——这个最简单，提示词里加一句"请直接创建文件，不要只给示例"就好了。

项目级 Skill 装了但看不到，确认你是在对应项目目录里打开工具的。换个项目自然看不到，那是设计如此。

## 从第一个 Skill 开始

第一次写 Skill 不用想得太复杂。最直接的办法是把一个你已经跑顺了的对话流程整段交给 AI：

> 基于现在这个流程，帮我整理成一个全局 Skill，名字叫 XXX。请直接创建文件，不要只给示例。

这就是最低门槛的 Skill 实践了。你不用先成为什么"Prompt 工程师"，也不用一上来就把所有机制全搞明白。重要的是把你反复做、反复解释、反复校准的那些事，慢慢沉淀下来。

写得清楚的 Skill 能省很多事，写得混乱的 Skill 也会给你制造新的麻烦。它不是自动变强按钮，更像一份工作规程——你给它什么底子，它就稳定输出什么水平。

下次再碰到那种"我上周明明写过一个特别顺的 prompt"的时刻，可以直接停下来想想：这个能不能就做成一个 Skill？