认识 Agent Skills：为什么光会写提示词不够了
上一篇系列讲的是怎么用好一个 AI 助手，这一篇系列换一个角度：怎么让这个助手把你的一套固定做法真正学会，而不是每次都靠你现说现教。
先说一个你一定遇到过的场景。你有一套做事的固定流程，比如发一篇文章之前，要核对标题、描述、分类、标签、链接有没有错；或者审查一段代码之前，要先看改了哪些文件，再查注入、越权这些固定项。第一次你把流程说得很清楚，助手做得很好；第二次换个对话，你又得把同一套流程从头说一遍。不是助手笨，是你每次给它的都是一次性的提示词，说完就忘，下次还得重说。
Agent Skills 要解决的，就是这个问题。
一、Skill 是什么：一套做法，写成一个文件夹
用一句话说：Skill 是把一套可重复的做法，写成一个文件夹，让 Agent 在合适的任务上自动照着做。
这个文件夹里最少只需要一个文件，叫 SKILL.md。它分成两部分：上面是一小段元数据，下面是具体的操作说明。还可以再配三个可选的文件夹：scripts 放可执行的脚本，references 放需要时才查的参考资料，assets 放模板和静态素材。
打个比方，提示词像是你每次打电话口头交代一遍做法，Skill 像是你给新同事写的一份入职指南：写一次，放在那里，以后每次遇到这类任务，Agent 自己翻出来照着做，不用你再口头交代。
这个格式不是某一家工具的私有东西。它最早来自 Anthropic 的 Claude Code，后来发布成了开放标准，由 Agentic AI Foundation 维护，现在 Claude Code、Codex、Cursor、Gemini CLI 这些工具都支持。也就是说，你写一份 Skill，不用为每个工具各写一份，这是它和“某个工具里的自定义指令”最大的区别。
二、提示词、记忆、Skill、MCP，各管什么
这四个东西经常被混在一起，先把它们分清楚，后面才不会用错地方：
- 提示词：管这一次对话。你说什么，它这次就按什么做，对话结束，约定也就结束了。
- 记忆：管长期偏好。比如你习惯用什么语言、怎么称呼你、哪些事必须先问你。记忆回答的是“你这个人是什么样”，不回答“这件事具体怎么做”。
- Skill：管一套固定做法。回答的是“这类任务的标准步骤是什么”，比如审查代码先看什么、发文章前核对什么。
- MCP：管连接外部工具和数据。回答的是“Agent 能拿到什么、能操作什么”，比如能读某个数据库、能调用某个接口。
简单记：提示词是一次性的话，记忆是关于你的事，Skill 是关于做法的事，MCP 是关于工具的事。四样东西配合起来，助手才既懂你，又会做事，还能拿到数据。
三、Skill 是怎么被用起来的：只加载需要的部分
Skill 有一个很关键的设计，叫渐进加载。它的意思是，Agent 不会一上来就把你所有 Skill 的全文都读进上下文，那样既贵又挤占注意力。它分三级加载：
- 启动时，只读元数据：每个 Skill 的名字和描述，大概 100 个 token。Agent 靠这些描述判断，当前任务和哪个 Skill 有关。
- 触发时，才读正文：当任务和某个 Skill 的描述对上号，Agent 才把这个 SKILL.md 的正文读进来，通常不到 5000 个 token。
- 执行时，再按需读附件：正文里提到的脚本、参考资料、模板，只有在真正需要的时候才加载，平时不占地方。
所以，Skill 写得好不好，关键不在正文写得多细，而在描述写得准不准。描述太模糊，Skill 永远触发不了；描述太宽泛，又会在不该触发的时候乱触发。下一篇文章会专门讲怎么写好这个描述。
四、举个例子：发文章前的检查 Skill
拿我们都熟悉的事举例。假设你每次发文章前都要做同一套检查：标题有没有错别字、描述有没有写、分类和标签对不对、文中的链接能不能打开、图片有没有缺失。没有 Skill 的时候，你每次都要把这五条重新说一遍，还容易漏掉一条。
写成 Skill 之后，做法就变成这样：文件夹名叫 publish-checklist，SKILL.md 里写清楚“这是一个发文章前的检查流程，在用户说要发布文章、或者要检查一篇文章时使用”，下面列出五条检查步骤和每条的通过标准。以后你只要说“帮我检查一下这篇文章能不能发”，Agent 自己就会翻出这个 Skill，一条一条照着查，最后告诉你哪条过了、哪条没过。
这个例子里有两点值得注意。第一，Skill 里写的是步骤和标准，不是某一篇文章的具体内容，所以它可以反复用在不同的文章上。第二，Skill 不替你做决定，它只是把检查做全、做稳，最后发不发，还是你点头才算。
五、什么时候不需要 Skill
不是所有事都值得写成 Skill。先问自己三个问题，有一个答案是“不”，就先别写：
- 这件事会不会重复出现？ 只做一次的事，写 Skill 的成本比现说一句话还高，直接说一句话更快。
- 做法是不是已经固定了？ 还在摸索、每次做法都不一样的事，写成 Skill 反而会把还没定型的流程锁死，等流程稳定了再写。
- 步骤能不能说清楚？ 如果做法全靠临场感觉、说不清标准，那它还不是一个 Skill，先把它做几次，把步骤提炼出来再说。
反过来，只要一件事每周都会出现、步骤已经固定、标准能够说清楚，它就是一个很好的 Skill 候选。先从一个开始，别一上来就建一整套库。
六、Skill 的边界：它管做法，不管判断
最后要说清楚一条边界，免得后面用错。Skill 让 Agent 的做法更稳，但它不替你做判断。遇到花钱、对外发消息、删数据、改设置、发布这些不可逆的事，Skill 里应该写的是“先停下来，等用户确认”，而不是“直接做下去”。这一点和上一个系列最后一篇讲的安全原则是一致的：日常习惯可以交给它，关键决定必须留给你。
同样，Skill 也不是万能的。它不能让一个不会做某件事的 Agent 突然会做，它只能让一个本来就会做的 Agent，每次都按你认可的标准做。先有正确的做法，再谈把它写成 Skill，这个顺序别反了。
练一次：挑一件每周重复的事
不用写代码，十分钟就够：
- 挑一件你每周都会重复做的事，比如整理周报、检查文章、审查代码。
- 把它的步骤写成三到五条，每条写清楚做到什么样才算通过。
- 再写一句话，说明在什么情况下应该用这套步骤，这句话就是以后 Skill 描述的底稿。
写完这三样，你其实已经有了一个 Skill 的骨架。下一篇文章，我们就把这个骨架变成一个真正能用的 SKILL.md 文件：名字怎么起、描述怎么写、正文控制在多长、脚本和参考资料怎么分工。
