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个Skill

2.1 第一个：去AI味写作润色Skill

第一个留下来的，是和写作强相关的“AI味检测与去重写”Skill。不管你是用Codex论文Skill、豆包写作助手，还是自己搭的Agent，AI生成内容最容易产生的一个毛病就是“套话连篇”。

我最早下载的是一个叫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 --since=HEAD~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的运行环境限制在一个专用目录，文件读写权限也做隔离。