Skill 不是越多越强：真正好用的 Skill 库，靠的是分类和触发

最近大家对 Skill 的热情有点猛。

什么都想封装成 Skill。

写文章一个 Skill，做封面一个 Skill，生成 PPT 配图一个 Skill，整理会议纪要一个 Skill，改小红书标题一个 Skill……

听起来很专业，对吧？

但你真把几十上百个 Skill 塞进 Agent 里，问题马上来了：

Agent 不知道该用哪个
明明有 Skill，却经常触发错
一次任务要扫描一堆说明，Token 哗哗烧
速度变慢，结果还不稳定
维护起来像养了一窝猫，谁都不听话

Skill 的关键，不是“我有多少个”。

而是两个词：分类和触发。

这篇咱们就把这个事讲透。

Skill 的本质：不是工具箱，是分类系统

很多人把 Skill 理解成“功能封装”。

这个理解没错，但不够。

更准确地说，Skill 是给 Agent 用的一套分类系统。

Agent 面对一个任务时，需要判断：

这个任务属于哪一类？该触发哪个 Skill？触发后怎么执行？

所以 Skill 设计里最重要的不是代码多漂亮，也不是描述多炫。

而是：

这个 Skill 管什么？
它不管什么？
什么情况下该触发它？
触发后内部怎么继续分流？

如果这些没设计好，你装 100 个 Skill 也没用。

甚至会更乱。

Skill 太多，会把 Agent 搞懵

你可以把 Agent 想成一个新来的实习生。

你给他 10 个清晰文件夹，他大概率能找到资料。

你给他 100 个名字差不多的文件夹：

公众号封面生成
小红书封面生成
PPT 图片生成
活动海报生成
文章配图生成
营销图生成
产品图生成
视觉图生成

他会崩。

不是他笨，是你分类太碎。

Skill 数量越多，Agent 每次选择时要对比的东西越多。描述相似、边界模糊、触发条件重叠，都会让它选错。

有实验数据也证明过这个趋势：

Skill 数量在 20 个以内，准确率还能保持得不错
超过 30 个后，误触发开始明显增加
到 200 个左右，准确率会大幅下降，速度也会变得很慢

这个体感很真实。

咱们自己用的时候也能发现：Skill 装多了以后，Agent 经常像在抽盲盒。

你想让它调用“图片生成”，它偏偏去找“内容排版”。

你让它整理资料，它可能跑去触发“写作助手”。

然后你看着结果沉默三秒：哥，你在干嘛？

好 Skill 的核心：分类清楚，触发准确

一个好 Skill，至少要回答两个问题。

1. 它属于哪个大类？

比如：

图片生成
文案写作
数据分析
代码审查
服务器管理
简历优化
财务报表整理

这些是比较像“一级目录”的东西。

它们之间差异明显，任务边界也清楚。

图片生成和服务器管理，肯定不该塞进同一个 Skill。

但公众号封面、小红书封面、PPT 配图，要不要拆成三个 Skill？

不一定。

更合理的做法往往是：做一个“图片生成 Skill”，内部再处理不同场景。

2. 什么情况下触发它？

触发条件要具体。

不要写成这种：

当用户需要图片时使用。

太泛了。

可以写得更像这样：

当用户需要生成、修改、扩展、重绘用于文章封面、社媒封面、PPT、海报、产品展示的图片时，触发该 Skill。若用户只是讨论图片创意，不需要实际生成图片，则不触发。

这就清楚多了。

Agent 知道什么时候该用，也知道什么时候别乱用。

示例：别把每个图片需求都拆成 Skill

假设你经常有这些需求：

公众号封面图
小红书封面图
PPT 配图
文章插图
产品宣传图
活动海报

很多人的做法是每个场景建一个 Skill。

看着很精细。

实际问题很大。

因为这些需求的上层类别是一样的：图片生成。

它们的差异主要在内部参数：

尺寸不同
风格不同
文案密度不同
使用场景不同
构图重点不同

这些差异不值得在最顶层各占一个 Skill。

更推荐这样设计：

Skill：图片生成助手

适用场景：
- 公众号封面
- 小红书封面
- PPT 配图
- 文章插图
- 活动海报
- 产品宣传图

触发条件：
- 用户明确要求生成图片
- 用户要求设计封面、海报、配图、视觉稿
- 用户提供主题、文案、风格，希望输出可用于生图模型的提示词或直接调用图片 API

不触发条件：
- 用户只是让你评价一张图
- 用户只是讨论视觉创意，没有要求生成
- 用户要做排版方案，不涉及图片生成

内部流程：
1. 判断图片用途
2. 判断平台尺寸
3. 提取核心文案
4. 选择视觉风格
5. 生成提示词或调用 API

这样 Agent 顶层只需要判断一件事：

这是不是图片生成任务？

进入 Skill 后，再由 Skill 内部判断：

这是公众号封面，还是 PPT 配图？

这就是分类颗粒度。

分类颗粒度：不是越细越好

很多人做 Skill 的坏习惯，是一看到新需求就新建一个。

今天要写周报，建一个周报 Skill。

明天要写日报，建一个日报 Skill。

后天要写项目复盘，再建一个复盘 Skill。

过几天你就会得到一堆边界暧昧的 Skill。

Agent 看到“帮我总结一下这个项目进展”，它可能会犹豫：

用周报？
用日报？
用复盘？
用会议纪要？
用项目管理？

这不是智能，这是选择困难症现场。

更好的方式是往上抽一层。

比如建一个：工作汇报 Skill。

内部覆盖：

日报
周报
月报
项目进展
复盘总结
OKR 更新

顶层分类少一点，内部结构清楚一点。

这比堆一堆小 Skill 好用得多。

判断一个 Skill 值不值得存在：看这 3 个问题

每次你想新建 Skill 时，先别急。

问自己 3 个问题。

问题一：这个场景有没有明确边界？

边界模糊的 Skill，最容易误触发。

比如“提升写作质量 Skill”。

这玩意太宽了。

写标题算不算？改错别字算不算？重写文章算不算？写邮件算不算？

边界不清，Agent 就会乱用。

更好的命名和边界可以是：

长文结构优化 Skill
小红书标题生成 Skill
商务邮件润色 Skill
技术文档改写 Skill

但也别拆太碎。

关键看它们是不是任务逻辑真的不同。

问题二：这个场景会不会高频出现？

一年用两次的东西，别急着做 Skill。

Skill 不是收藏夹。

它会占用 Agent 的判断空间。

如果一个场景你每周都用，甚至每天都用，那值得封装。

比如：

每天写公众号标题
每周整理会议纪要
经常生成产品图
高频处理客服反馈
固定格式输出投放日报

这种适合做 Skill。

如果只是某次临时任务，直接在对话里说清楚就行。

别为了“看起来很自动化”给自己加负担。

问题三：它能不能归到已有 Skill 里？

这是最重要的一问。

你想新建“小红书封面 Skill”。

已有“图片生成 Skill”吗？

有的话，先塞进去。

你想新建“周报 Skill”。

已有“工作汇报 Skill”吗？

有的话，先做内部场景分支。

你想新建“Python 报错修复 Skill”。

已有“代码调试 Skill”吗？

有的话，先别重复建。

一句话：

能归类，就别新建。

一个实用的 Skill 分类模板

你可以按下面这个结构整理自己的 Skill 库。

别一上来就追求完美。

先把常用场景梳理清楚。

一级分类：内容生产
- 文章写作 Skill
- 标题生成 Skill
- 短视频脚本 Skill
- 社媒文案 Skill

一级分类：视觉生成
- 图片生成 Skill
- 海报设计 Skill（如果海报任务非常高频且流程复杂）

一级分类：办公自动化
- 会议纪要 Skill
- 工作汇报 Skill
- 表格整理 Skill

一级分类：研发工程
- 代码审查 Skill
- Bug 定位 Skill
- API 文档生成 Skill

一级分类：运营分析
- 用户反馈分析 Skill
- 投放数据分析 Skill
- 竞品拆解 Skill

这里有个重点：

一级分类不一定是 Skill 本身，它可以只是你脑子里的目录。

真正装进 Agent 的 Skill，要控制数量。

对于个人用户，建议长期保持在 20～30 个以内。

除非你有非常成熟的路由机制，不然别轻易破百。

破百之后，不是你掌控 Skill，是 Skill 反过来折磨你。

CLAUDE.md 和 Skill 怎么分工？

很多人还会混淆一个问题：

哪些内容该写进 CLAUDE.md，哪些内容该做成 Skill？

可以这样分。

适合放进 CLAUDE.md 的内容

这些是“长期背景”和“全局偏好”：

你的写作风格
你的常用表达习惯
你的项目背景
你的输出格式偏好
你不喜欢的词
你的品牌调性
你的技术栈
你的默认工作原则

比如：

我的文章风格：短句、口语化、少用抽象词，多给例子。
默认输出中文。
代码示例优先使用 TypeScript。
不要使用夸张营销词。

这类内容不需要每次触发某个 Skill。

它应该像“常驻记忆”一样存在。

适合做成 Skill 的内容

这些是“特定任务流程”：

有明确输入
有固定步骤
有稳定输出
高频复现
需要调用工具或 API

比如：

Skill：会议纪要整理
输入：会议录音转写文本
流程：提取议题 → 总结决策 → 标注负责人 → 输出行动项
输出：Markdown 会议纪要

再比如：

Skill：图片生成
输入：主题、用途、平台、风格
流程：识别场景 → 生成视觉方案 → 生成提示词 → 调用图片 API
输出：图片链接或生图提示词

简单记：

CLAUDE.md 管长期偏好
Skill 管可重复执行的任务流程

别把所有东西都塞进 Skill。

也别把复杂流程都扔进 CLAUDE.md。

分工清楚，Agent 才不容易乱。

写 Skill 触发条件时，别偷懒

触发条件是 Skill 的门牌。

门牌写错，快递就送错。

很多 Skill 不好用，不是能力差，是触发条件写得太飘。

不推荐这样写

用于帮助用户写文章。

太宽。

Agent 看见“写邮件”“写标题”“写总结”都可能触发。

避坑清单：这些 Skill 设计习惯很危险 ⚠️

1. 见一个需求就建一个 Skill

这是最常见的坑。

短期很爽，长期崩盘。

Skill 越多，路由越难。

2. Skill 名字太像

比如：

文案优化
文案润色
文案改写
文案增强
文案升级

Agent 看了也想辞职。

名字要有边界，不要搞同义词堆叠。

3. 触发条件只写一句话

一句“用于处理图片需求”，基本不够。

至少写清楚适用和不适用。

4. 把低频需求做成 Skill

一年用一次的东西，别污染 Skill 库。

临时提示词就够了。

5. 顶层分类太细

公众号封面、小红书封面、PPT 配图，很多时候都可以归到图片生成。

别让内部变体占据顶层位置。

6. 没有定期清理

Skill 库要像冰箱一样定期清。

过期的、重复的、半年没用的，删。

别心疼。

你可以直接照着做：整理 Skill 库的 5 步法

不用搞复杂。

拿出你现在的 Skill 列表，按这个流程走一遍。

第一步：列出所有 Skill

把名字全拉出来。

不用美化。

先看全貌。

第二步：标注使用频率

给每个 Skill 打标签：

每天用
每周用
每月用
几乎不用

“几乎不用”的先放进删除候选区。

第三步：找重复和相似

看到名字很像的，放一起。

比如：

标题生成
小红书标题
公众号标题
爆款标题
文章标题优化

它们可能可以合并成一个“标题生成 Skill”，内部按平台分支。

第四步：重新设计大类

按任务类型归类：

写作
图片
数据
代码
办公
运营

让每个 Skill 都有明确归属。

第五步：重写触发条件

每个 Skill 都补上：

什么时候触发
什么时候不触发
输入是什么
输出是什么
内部流程是什么

整理完，你的 Skill 库会立刻清爽很多。

Agent 也会更听话。

一个好 Skill 长什么样？

给你一个可直接套用的模板。

# Skill 名称：图片生成助手

## 适用场景
当用户需要生成、修改、扩展、重绘图片时使用。常见用途包括公众号封面、小红书封面、PPT 配图、文章插图、活动海报、产品宣传图。

## 不适用场景
- 用户只是评价图片
- 用户只是讨论设计想法，没有要求生成图片
- 用户需要排版文档，而不是生成图片
- 用户需要写文案，不涉及视觉输出

## 输入信息
- 图片用途
- 平台或尺寸
- 主题
- 关键文案
- 风格偏好
- 禁止出现的元素

## 执行流程
1. 判断图片用途
2. 确定尺寸和构图
3. 提炼画面主体
4. 生成视觉描述
5. 生成生图提示词
6. 如有 API 权限，调用图片生成接口

## 输出格式
- 图片方案说明
- 生图提示词
- 负面提示词
- 尺寸建议
- 图片链接（如已调用 API）

注意，这个 Skill 没有把每个图片场景都拆出去。

它把“图片生成”作为顶层类别，再在内部处理细分需求。

这才是稳定的结构。

真正的原则：如无必要，别新增 Skill

有个很适合 Skill 设计的原则：

如无必要，勿增实体。

翻成大白话：

用不到的 Skill，别装。能合并的 Skill，别拆。边界不清的 Skill，先别建。

Skill 的数量不是战斗力。

清晰的分类才是。

准确的触发才是。

你要做的不是攒一个看起来很豪华的 Skill 库，而是搭一个 Agent 真能理解、真能调用、真能复用的任务系统。

少一点，准一点。

你的 Agent 会好用很多。