别再把 AI 工具当 App 了:一个 skill 到底是个啥

很多人第一次听说“我装了个 skill”，反应是：装了个 App？装了个插件？——然后就卡住了：它不编译、不上服务，凭什么打一行命令就能让 AI 换一种性格？

你不是不会，是缺一层“地基”。今天不拆任何东西，先把最底下的那块砖讲透——什么是 AI skill。

很多人第一次听到“我装了个 skill”，脑子里自动映射成：装了个 App、装了个插件。

不是的。两点掰开说：App 是程序，它是一堆编译好的代码，有自己的进程、界面和运行逻辑，你点一下它在后台干活；skill 是文本，它就是一份 Markdown 文件，里面写的是“给大模型看的说明书”，没有编译、没有进程、没有服务，客户端把它塞进对话上下文，模型读完后照着演。

这就是为什么 skill 看起来“神出鬼没”——它压根不是个程序，它是一段被临时加载进对话的“指令”。

拆开看，一个最小可用的 skill 长这样（下面以 grill-me 这个公开 skill 为例，去掉了无关内容）：

就这么多。拆开看，这个文件（SKILL.md）的格式是两段式——记住这两段就够：

一个 skill 不是一个文件，而是一个文件夹——客户端只认 SKILL.md 这一个文件，其余都是给它的“补给”，指令要用到时才加载：

说到底，你本来就习惯“用文本去描述一个系统该怎么做事”——写配置、写文档、写注释都是这个思路。skill 只是把这套思路，从驱动计算机，搬到了驱动模型身上。

所以“懂代码”在这里不是负担，是捷径：你早就熟悉了“用一段文字去指挥一个系统”这件事，现在只是换了一个会读这些文字的“员工”。

skill 没有“运行”这个动作，只有“加载”。agent 不是执行代码，而是把 Markdown 文本塞进对话上下文，让模型按新指令改变行为。

那 agent 到底怎么用一份 SKILL.md？三步走：

举个具体例子走一遍

这也解释了为什么好的 skill 设计会把“入口”和“逻辑”拆成两层：薄薄的一层入口（SKILL.md 那几行）负责被触发，真正的复杂逻辑放在另一个文件里。入口可以很轻，火力可以很重。

先把一个可能让你意外的结论摆这：

听起来像劝退？别急——对写代码的人，这反而是最该松口气的一章。因为把需求翻成指令这件事，你天天都在干，只是从来没往模型身上想过。

下面这几组对照，你现在的工作经验和 skill 是一一对应的：

看懂了吗？你不是在学一门新手艺，是在把老手艺换了个对象用。写函数时你教计算机做事，写 skill 时你教模型做事——底层能力一模一样，只是听话的对象从编译器变成了大模型。

所以真正拦住大多数人的，从来不是技术，而是AI 心智那一层：知道模型怎么读指令、什么时机该被谁触发。把这一层补上，你就能从“会用”走到“会做”，而不是停在“只会用”。

而“怎么把需求翻成模型真听得懂的指令”，恰恰是后面几篇要慢慢补的硬功夫。今天你先拿住一件事就够：skill 的本质你已经懂了，剩下的是熟练度，不是天堑。

讲完是什么、怎么跑，你大概率会想：那我怎么把它装到我自己用的 agent 里？先把一个关键结论放这——skill 不是某一家私有的格式，而是一套开放智能体技能标准：一份 SKILL.md 走天下。我们上一篇拆的 grill-me 用的就是这套标准，所以 Codex 能直接读它的说明、不用改写。下面就用 Codex 演示这套标准具体怎么装：

装上之后怎么用？两种叫法：

补充一句：Claude Code 用 /skill-name 前缀，Codex 用 $skill-name，前缀不同但机制一样——这正是同一份 SKILL.md 两边都能跑的原因。一个接地气的判断标准：同一件事你跟 AI 解释过三遍以上，就值得做成 skill。比如每周都按「Jest 格式、覆盖主要分支、中文注释」写测试，写成 skill 后，$unit-test 一句话就搞定。

看到这，你已经具备做第一个 skill 的全部前提：会写文本、会描述需求。下面给一个“今天就能跑”的最小流程，以做一个「周报生成器」为例。

SKILL.md 长这样：

就这三步、这几行，你就拥有了一个“专属周报助手”。它当然很薄——但“薄”正是 skill 的起点：先让一个典型任务跑通，再慢慢加脚本、加资料。

真正的火候在后面：怎么把需求写成模型真听得懂的指令、怎么动手写你的第一个完整 agent，后面会专门讲。这一篇先把“它长什么样、怎么装、怎么起步”讲到你敢动手，就够了。