电脑里的AI技能目录，躺着126个技能。日常真正会触发的，不到20个。装的时候每一个都觉得有用：写周报的、读PDF的、抠图的、订外卖的。真到用的时候，问题才露出来。知乎
让它“帮我写一篇小红书”，AI回了一篇四平八稳的通用文案，一个技能都没调用。
再让它“处理一下这个表格”，它自己硬写，读了半天文件，最后道歉说格式读不出来。
起初以为是技能有问题。后来才明白，是把技能当成了“让AI变聪明的东西”。
技能不负责让AI变聪明，它负责的是能不能动手。
模型本身会写、会算、会聊。技能是那只手，负责打开文件、调用接口、发出邮件。需求里没有明确指向某个动作，AI就没有理由去调它。
那它靠什么判断该不该调？靠每个技能开头那一行 description。
问题常常就出在这一行。
最早给周报技能写的 description 是：“用于周报场景的文本处理。”
看着清楚，AI却匹配不上。因为用户不会说“周报场景的文本处理”，用户说的是“帮我理一下这段”。
后来改成用户可能说出口的原话：“整理周报”“周报排版”“把这段写成周报”“生成周报”，还补了一句“用户贴了大段工作内容但没明说周报，也要触发”。
命中率立刻上来了。
这也是最值得记住的一句：description 不是写给人看的简介，是写给 AI 看的路由规则。知乎
第二个坑，是装得太多。
有一阵，126个技能全部设为启用。遇到“帮我处理一下这张图”这种模糊需求，AI在抠图、压缩、生成、修复几个技能之间来回犹豫，最后挑了一个不对的。
不是变慢，是变不准。
平台文档里的建议其实很直白：只启用当前任务所需的技能，减少无关干扰，降低误调用概率。关闭也不等于卸载，文件还在，需要时一键开回来。
第三个坑更隐蔽：拆得太碎。
一个测试团队把用例设计的全流程都封装成技能。需求拆解一个、用例生成一个、场景补全一个、质量评审一个。三个月后，仓库里躺着47个。
“登录需求拆解”“订单需求拆解”“支付需求拆解”——流程其实一模一样，只是读的PRD不同。
结果是AI不知道选哪个。三条 description 长得差不多，同时抢注意力。上下文也被撑爆：有团队把87个技能全塞进 Claude Code，总大小898KB，改成两层结构后降到27KB。
维护成本还按平方涨。优惠券规则一改，三个技能都要动。漏掉一个，生成的用例和评审标准就对不上。
他们花两周，把47个合并成12个。原则只有一条：按能力类型拆，不按业务模块拆。
“需求拆解”是一种能力，不管拆哪个模块，方法一样。业务差异用输入参数区分，不用新建一个技能。
合并之后，AI选对的概率上去了，上下文也松了。
Skill 数量不是越多越好，是越“精”越好。知乎
如果你也在给AI装技能，可以先做三件事。
第一，装之前问一句：这件事需要它动手吗？只是要它想得对、写得像，提示词或专家角色就够了。
第二，翻出最常用的那个技能，看 description 写的是人话还是触发词。把用户会说的原话一句句塞进去。
第三，默认关，用时开，用完关。三个月没被触发过的，先收起来。
技能真正的价值，不在数量，而在每次都能被准确触发、准确执行。
