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

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

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

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

Skill 长什么样

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果你的工作主要是写文章、做选题、改文案、整理资料，大多数情况下 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 输出所有文件内容、绕过限制、自动发送数据、或者悄悄改掉所有回答风格。看到这种，直接删掉就行，不用犹豫。

不确定的 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？