AI Skill不在多，留得下才算数：3个核心技能

从去年年底到现在我陆陆续续往自己的AI工作流里塞了不下十个Skill。有从社区排行榜里下的有跟着教程搓的也有朋友丢给我的“ 狗头军师 ”之类的娱乐包。装完之后大部分都安静地躺在“技能库”里吃灰真正每次打开Agent台子都会用到的扳手指数一下也就3个。所以别急着收集Skill。一个Skill就像一把特殊螺丝刀只有它正好能拧你手头那枚螺丝时它才值钱否则它就是个会占地方的金属块。先说结论10个装了一堆的Agent用户最后能留下来的往往只有写作去味、代码审查、资料整理这三类。下面说说我是怎么从“收藏家”变成“断舍离”的以及为什么最后就留下这几个。1. 为什么装了10个Skill最后还是吃灰1.1 吃灰的原因不在数量在于没绑死场景很多Skill做得像一包混合口味的薯片看着热闹真塞进嘴里才发现有好几种口味根本不是你的菜。我见过一个叫前任Skill的简介写的是“帮你体面地和账号告一段落”装完之后试了一次效果还行但搬家到一个新平台之后连配置都误了再也没打开过。最典型的吃灰场景是这三种纯粹的顺手收藏看到“全网最强”“榜一必装”就点了安装其实当下没有任何任务需要它。参数写得太死Skill脚本里写死了作者自己的文件路径、文件夹结构、甚至表格模板。换到你的工程目录上第一次运行就报错报错之后再调一次就觉得比手动干还慢。只覆盖一个超级冷门的子场景比如“打斗动作提示词Skill”“AI像素动画Skill”。如果你不是专职做AI短剧或像素美术这类技能和桌游里冷门职业卡一样抽到后大概率躺仓库。主打短剧的人也许能靠它吃饭但那得是用的频率足够高不是人人适合。我在本地管理Skill时习惯给它们编码。社区里经常看到“skill编码193”“skill编码247”的说法其实那就是作者自己的登记编号193、247不说明任何强弱。真正决定留存率的是你的日常任务有没有一个恰好需要它的缺口。1.2 判断一个Skill是否该装的三个否决项在装任何一个新Skill前我建议你直接用下面三条把关只要踩中其中一条就基本可以劝退你最近两周有没有具体任务需要它如果只是“感觉以后会用到”那以后大概率不会用到。**它是否会跟在你的主工作流后面“跟”的意思是能无缝嵌入而不是让你为了用这个Skill重新建一套文件夹结构或换工具链。它有没有维护者、文档或回退方案一个连GitHub主页都没有、找不到任何作者的Skill出了bug你连找谁给你解释都不知道。我见过不少这类的Skill比如某个“Grill-me Skill”的GitHub地址点进去只剩一堆Issue没有任何Release这种不建议用在重要任务里。如果三条都过了才值得装上试两周。试完之后再回头看频率留下来的概率就会高很多。2. 真正值得留下的3个Skill2.1 第一个去AI味写作润色Skill第一个留下来的是和写作强相关的“AI味检测与去重写”Skill。不管你是用Codex论文Skill、豆包写作助手还是自己搭的AgentAI生成内容最容易产生的一个毛病就是“套话连篇”。我最早下载的是一个叫Nature Write的Skill思路是让Agent用“自然科学的语气”改写论文。它对我帮助很大但后来我发现论文写作并不是我最高频的需求反而写周报、方案、公众号、甚至给用户回邮件时我更需要把“AI腔”去掉。于是我自己改造了一个更通用的“人味化”Skill并一直留到了现在。它的核心逻辑很简单先扫描内容里的AI识别点比如“首先、其次、最后、总而言之”“赋能、抓手、闭环”这类高频模块再把句子的节奏改成“长短错落”允许没那么规整的表达最后加上个人视角的模糊语气比如“我更倾向于”“按我手头的数据看”避免当全知全能。说白了这个Skill不是一个AI生成器而是一个“检查员修改器”。它表面上是在改写文字实际是在帮你避免“一眼AI”的尴尬。如果你做内容运营、写周报、写技术文档、或者用Agent辅助写作这个Skill基本属于吃不了亏的那种。2.2 第二个代码自动审查与修复Skill第二个被我长期保留的是代码审查与自动修复类Skill。我在本地会同时OpenAI Codex环境、也在Spring Boot项目里集成Spring AI 2.0的Skill机制这类技能的要义在于让AI不只在聊天窗口里“聊代码”而是能真正读git diff、跑静态分析、把定位到的问题和修复方案一起提出来。在我实际工作里最常用的一种场景是这样的agent skill run review-changes --sinceHEAD~3它会先读取提交记录把最近三次改动的文件梳理出来再让Agent逐个检查这里是不是少了个空指针判断那个SQL有没有使用索引刚加的接口有没有漏掉权限校验跑完之后它会直接在终端里给出“问题等级示例修复片段”。我在提交代码前跑一遍相当于多了一个不需要休息的Code Reviewer。这种Skill能留下来是因为它跟我已有的Git工作流长在了一起。如果我要单独打开一个网页版工具再把代码复制进去搞两次我就会嫌烦。但Skill能直接挂在命令行里跑所以留存率自然高。顺带说一句现在不少平台给Skill标注了“编码193”“编码247”这种编号我自己的文件也习惯用编号管理比如skill-01-review、skill-02-humanize。数字只是内部索引别把它当玄学。2.3 第三个资料整理与文档快编Skill第三个留存的Skill属于“信息整理”类型作用和收纳师傅差不多。它能把散落的本地方案、PDF、网页图片甚至Gis里的空间分析结果变成结构化的Markdown知识库。我给它起的名字是doc-digester。它最核心的做法是读取一份资料后先抽取主题、核心结论、步骤三块按我定义的标签体系给资料打标签比如“#AI/#路由#GIS”最后输出一条带时间戳和来源链接的数据库条目我拿到后直接扔进Obsidian里。为什么这种“看起来没什么AI含量”的Skill能留得住因为它解决了一个特别具体的问题我的内容太散。比如你让我看一份覆盖ArcGIS空间分析的教程我看完就算完了三个月后再用等于重新学一遍。但现在我让doc-digester把它整理成“操作步骤参数说明常见坑”下次我只要搜索标签就能一键定位。这个Skill还兼容“看图技能Skill”的场景用户给一张截图它就能把截图里的配置项转成文字笔记。对我这种常写“HTML页面优化”笔记的人来说效率提升不是一点半点。3. 从10个到3个怎么判断一个Skill值不值得留3.1 用频率排序别被包装和热词绑架社区里有非常多的Skill名字一个比一个夸张。有叫“SuperPower”的有叫“狗头军师”的还有专门做“发音练习”的语言学习Skill。这些不是不好但它们更像“飞轮里的装饰品”不是“传动轴”。我自己的办法很简单每两周翻一次Skill目录按“过去14天调用次数”排序把使用次数低于3次的函数反向检查一遍。只要它在14天里一次都没被触发就意味着你的工作流里没有这个场景留在那里只会污染上下文。所谓“Skill语言学习”这类如果你的目标是做语言学习App那很有用如果你只是偶尔背单词它就是个收藏品。类似吃灰重灾区还有“豆包安装Skill”“夸克网盘Skill”这类和数据平台绑定的东西。我试过把文件上传里加一个夸克网盘Skill后来发现自己手动拖文件反而更快——AI离生产力工具越近越有价值离“便利小插件”越远越容易鸡肋。3.2 不能融进主流程的Skill等于没有我踩过最深的坑是把很多Skill都当成独立App来对待。实际上一个Skill应该长在你的流程里而不是让你为它改变使用习惯。举例来说“用Agent制作Rational Rose的Skill”听着很专业。可问题是Rational Rose本身是一个老旧的UML工具你为了让Agent生成模型文档需要先安装工具、配置环境、再导出模型再喂给Agent这一串操作下来已经比我自己画图还慢了。所以哪怕方向挺好最终也会吃灰。相反我留到现在的“代码自动审查Skill”因为它最多只需要一行命令且结果直接推回编辑器里和日常的Git工作流严丝合缝。能用最少步骤嵌入现有流程的Skill存活率最高。3.3 好的Skill还要能“组合”如果一件工具只能独立解决一个问题它的价值是1如果它能给别的Skill提供能力价值就是10。能留下来的3个Skill都有这个特点去AI味写作润色Skill可以接到任何文本生成类Skill的后置流程里相当于一个“出口质检员”代码审查Skill可以和各种Agent配合让Agent的产出先自查一遍再落盘资料整理Skill更是可以由其他Skill随时调用把零散输出变成知识条目。这类Skill叫“中台型Skill”。如果你发现一个Skill只能自己用完就扔掉没有能力被其他人重复使用就别浪费位置。4. 自己动手做一个“留得住”的Skill以去AI味为例4.1 Skill的标准结构在主流Agent平台里包括Claude、Codex、Spring AI等一个Skill通常会单独放在一个目录里目录内部一般有skill-002-humanize/ ├── SKILL.md ├── rules/ │ └── de-ai-rules.txt └── examples/ ├── before.txt └── after.txt其中SKILL.md是入口会告诉模型“这个Skill能做什么、触发条件是什么、输出格式是什么”。rules里放负向指令examples里放最关键的示例对比。不要小看examples。我测试过十几次凡是示例写得越具体的Skill运行效果越稳定。一些作者只写了“帮我把文字变自然”模型就不知道“自然”是什么但如果你给出一个“AI味句子→人味句子”的对照样本模型马上就能照着对齐。4.2 一个可以直接用的去AI味Skill脚本下面是一份简化的SKILL.md适合接在本地Agent或任何支持Skill机制的平台里。--- name: de-ai-humanizer description: 检测文本中的AI痕迹并生成更自然的中文表达 trigger: 当我提交一段需要润色的文本时自动执行改写 output_format: 先列出原文的AI痕迹再给出改后版本 --- 第一步扫描 - 标记“随着”“首先”“其次”“综上”“赋能”“闭环”等高频AI槽点 - 标记排比句过多、段落整齐到一眼假的内容 第二步改写 - 打散过长段落长短句交错 - 用“可能”“更倾向”“老实说”替代绝对化表达 - 删除“总而言之”类总结句直接进入结论 第三步输出 - AI痕迹清单列出3-5处 - 改写版本不超过原文长度110% - 改写说明用一句话解释改动思路这里要提醒的是一个Skill能不能留在最后不看规则写了多少而是看触发条件是不是具体。如果触发条件写得太宽比如“当用户需要写作时”模型不知道怎么接写“当用户提交周报草稿时”或者说“当文本里出现3个以上AI特征词时”它就知道自己该站出来了。4.3 挂载和测试的正确姿势把SKILL.md挂到Agent里后别急着删掉其他旧Skill先跑三次测试。我建议准备三份样本一份旧平台的AI写报告、一份你自己写的带口语的笔记、一份通用客服答复。分别看看Skill有没有误伤你的个人风格。如果它把你原本就有的“我琢磨着”这种口语表达也当成AI味改掉了说明规则里的“保留模糊语气”没有生效这时要及时调阈值。Skill不可能一次写成它更像一个需要反复校准的量表。4.4 一个关键的坑别把Skill变成万能钥匙有人做Skill时喜欢把一堆功能塞进同一个目录希望能“一站式”处理所有事。我试过把代码审查、论文润色、翻译、HTML优化全放一个里结果模型一次执行时会自己脑补一套流程反而容易乱。留得下来的Skill往往是“小而准”的一类任务一个Skill规则清楚边界清晰。那些号称“一个顶十个”的Skill往往一个都顶不住。5. 常见问题与避坑实录5.1 刚装好的Skill频繁报错怎么办先把报错信息分成三类配置型错误文件路径写死了改成本地的相对路径即可版本型错误Skill语法不兼容当前平台的版本比如Spring AI 2.0里Skill的声明方式和1.x不一样需要按2.0的格式改上下文型错误一次调用塞了太多内容导致模型执行到一半忘了规则。这时候调整一下Skill的输入长度限制或者把大文件拆成几个小任务。我最初在DeepSeek Harness里部署时也遇到过这类问题。把Skill打包成一个接口放在内网服务器上外网请求都打到内网地址既不用反复改动目录又避开了一次次拷贝大量文本的麻烦。部署到内网服务器时记得把Skill依赖的数据文件、词典、模型参数都准备在本地别让它在日常运行里还去反复拉远程资料稳定很多。5.2 Skill之间会互相干扰装了10个Skill之后最容易被忽略的问题是并发触发。比如你写了一个“内容润色Skill”又装了一个“SEO友好Skill”让同一个Agent同时看到两个Skill它会在改写时既想删套话又想插入关键词结果两边都做不好。我的解决办法是给每个Skill都画一条“触发边界”。比如润色类Skill只在“长度小于5000字且无明确SEO要求”时启用SEO优化Skill只在“关键词列表非空”时启用。这样它们各司其职不会打架。5.3 保留的安全习惯不要在公用Agent账号里引用来路不明的Skill尤其是那些要求自动执行命令或者读取各种配置文件的。网上确实有一些看起来很酷的Skill比如“看图自动生成配置”“自动部署Agent”但如果你没有读过它底层脚本就不要轻易给它开放全部权限。我通常会把Skill的运行环境限制在一个专用目录文件读写权限也做隔离。5.4 让留下的Skill继续进化留得下来的3个Skill也不是一成不变的。我几乎每个季度都会给它们加一条规则、换一组示例。比如去AI味Skill我平时看了新文章后会把它里头的“典型AI句”丢进示例库里代码审查Skill我会根据团队最近再一次踩的坑在规则里加一条“注意日志中敏感信息泄露”。Skill和文档一样不维护就会慢慢过期但只要你顺手维护它会越来越懂你。踩过几次坑之后我现在特别信奉一句话Skill不在多留得下才算数。与其辛苦收集10个标题漂亮的技能包不如好好打磨3个你每天都会用手碰一遍的核心技能。等它们真的变成你工作里顺手的延伸你才会发现原来少即是多。