Skill 怎么用才不浪费：把常做任务教给 AI，而不是每次从头解释

Skill 为什么最近又被反复提起

如果说前两年大家更习惯直接给 AI 下 prompt，这两年开始，越来越多人会提 skill 这个词。原因很简单，AI 已经不只是拿来问一句就走了。你让它写周报、审代码、查资料、整理知识库、跑一段固定流程时，重复动作越来越多。每次都从头解释，成本很快就会比生成本身还高。

很多人第一次听到 skill，会把它理解成“给模型加一个额外能力”。更贴近实际的理解，是把高频任务的背景、步骤、边界和输出格式提前教给 AI。这样下次再遇到同类任务，它不必从零猜你想怎么做。

不同产品叫法不完全一样，但核心差不多

不同产品里，这类东西的名字不完全一样。有的直接叫 skills，有的更像自定义命令、子代理、任务模板或固定工作流。实现方式虽然不同，核心其实差不多：把一类经常重复的任务，收成可复用的执行规则。

所以看待 skill 最好别太执着于名词。你真正该关心的，是这套东西有没有帮你减少重复说明，有没有让输出更稳定，有没有让 AI 在固定任务里少走弯路。

什么任务最适合做成 skill

最适合做成 skill 的任务，一般有三个特点。第一是高频，你一周里会反复碰到。第二是边界相对稳定，输入和输出差不多有迹可循。第三是你已经知道一条相对靠谱的做法，不是还在完全摸索阶段。

比如代码 review、日报整理、文章改写、需求拆分、Issue 分诊、资料核查、竞品信息归档，这些都很适合。它们的问题不是“模型会不会”，而是“每次做法都不一样”。skill 的意义就在这里，把做法固定下来，让质量别忽上忽下。

写一个 skill，最该先写清什么

很多人第一次写 skill，最容易写成一篇很长的说明文。背景讲了一堆，真正关键的触发条件、步骤和输出却很模糊。这样写出来的 skill，看起来很完整，用起来反而不稳定。

更实用的写法，通常先写清四件事。第一，这个 skill 在什么情况下该用。第二，输入需要什么，哪些上下文必须先拿到。第三，执行时按什么顺序做。第四，最后要产出什么格式。只要这四件事站住，skill 通常就已经能用了。

真正常用的写法，往往都很克制

好用的 skill 通常不会很花哨。它更像一份给 AI 的短工作说明，而不是一套宏大方法论。它告诉模型先看哪里，再做哪几步，遇到什么情况要停下来，最后按什么格式交付。写得越克制，真正跑起来往往越稳。

很多人会想把所有例外都提前塞进去，希望一次写完以后永远不用再改。结果就是 skill 越写越长，真正触发时反而抓不到重点。比起一开始就写成大全，更稳的做法是先拿一个高频场景跑起来，再根据实际使用补规则。

Skill 和 MCP 不是一回事

这两个词最近经常一起出现，但它们解决的问题不一样。MCP 更像“接入口”，负责把工具、资料和外部系统接进来；skill 更像“做法”，负责告诉 AI 拿到这些能力以后该怎么工作。一个偏连接，一个偏执行。

所以很多人装了 MCP 还是觉得不好用，原因未必在接入本身，有时候是因为没有把自己的常用流程固定下来。反过来也一样，只有 skill 有做法，没有 MCP 提供的工具和资料，很多任务也只能停在纸面上。

两者配在一起，效果才会明显

一条更顺的路径通常是这样：先用 MCP 把仓库、文档、数据库、网页这些入口接进来，再用 skill 把自己的工作顺序写清楚。比如“先查变更，再读文档，再给修改建议，最后按固定格式输出”。这时候 AI 不只是能碰到资料，也更知道该怎么用这些资料。

真正省时间的，通常不是单独多了一个 MCP server，也不是单独多了一条 skill，而是两者正好接上了同一条高频任务。

最常见的几个误区

第一种误区是把 skill 写得太大，恨不得让它包办所有任务。第二种是写得太抽象，只有一些判断词，没有真正能执行的步骤。第三种是把变化很快的事实也硬塞进去，比如版本信息、团队名单、临时地址，结果过几天就过时了。

还有一种常见问题，是写完 skill 就不回看。真正好用的 skill 通常都是迭代出来的，不是第一次就完美。你用过几轮以后，最该补的往往不是“更多背景”，而是哪一步最容易跑偏、哪种输入最容易漏掉。

更适合新手的起步方式

如果你现在也想试 skill，不用先写一大套。先挑一个自己最近一周已经做过三次以上的任务，把它收成一个很小的版本就够了。只要能稳定省掉一轮重复说明，这条 skill 就已经有价值。

等这一个小 skill 跑顺了，再继续加第二条、第三条，效果会比一开始就做一套“大而全”的体系好很多。skill 真正有用的地方，不在名字，而在它能不能把你已经验证过的做法，变成 AI 也能稳定复用的习惯。