最近社区里聊得最热闹的一个词就是 Skill。从豆包到 Codex，从 Claude Code 到各种 GitHub 仓库，好像一夜之间，不装几个 Skill 都不好意思说自己用过 AI。我也没免俗，陆陆续续装了不下 10 个：有做 GIS 空间分析的，有专门写论文的，有生成像素动画的，有优化 HTML 页面的，还有两个名字特别有梗的——“前任 Skill”和“狗头军师 Skill”。当时装的时候，每个都觉得“这个能救命”，结果几个月下来，真正被我天天打开的，翻过来覆过去就 3 个。

剩下的那些去哪儿了呢？都在文件夹里躺着，有些甚至装完之后我连一次都没运行过。这事儿挺有意思，我后来认真复盘了一下：不是那 7 个 Skill 做得不行，而是“安装”和“使用”之间隔着一道我自己没意识到的坎。这篇东西不劝你别装 Skill，正好相反，我想把“为什么大多数 Skill 会吃灰”这件事讲透，再把我留下的 3 个 Skill 完整拆开给你看，包括它们解决什么问题、怎么配置、踩过哪些坑。看完你大概率能给自己那堆吃灰 Skill 做个大扫除。

1. 为什么你装的 Skill 十个有九个在吃灰

1.1 场景错配：Skill 是解决方案，不是收藏品

先问个扎心问题：你装那个 Skill 的时候，手上到底有没有一件正在等的任务？

我观察了身边朋友的安装习惯，包括我自己。绝大多数人装 Skill 的理由是“别人说好用”“GitHub 上 star 特别高”“最近这个话题很热”。比如“skill 编码 193”“skill 编码 247”这阵子传得特别邪乎，好多人到处打听这两个编码对应什么能力，好像拿到编码就拿到了某个隐藏功能。但实际上，这类编码式 Skill 往往只是特定平台内部的技能编号，你在 A 平台能用，拿到 B 平台根本加载不出来，就算加载出来了，也不是你当下的工作流里缺的那个环节。

Skill 本质上是一份“针对特定任务的解决方案”。它的价值依赖场景：装了 GIS 空间分析 Skill，但你三个月都没碰过地理数据；装了打斗动作提示词 Skill，但你平时写的是产品文档。那这个 Skill 对你来说就是零价值，吃灰只是时间问题。这不是 Skill 的问题，是场景错配的问题。收藏一个 Skill，跟收藏一本菜谱是一样的——菜谱本身没问题，但如果你根本不进厨房，它就只能压在箱子底。

1.2 交互成本太高：一个动作超过三步就没人愿意用

第二个被我低估的因素是交互成本。装 Skill 的时候，你花了一个下午研究目录、看 README、配置参数。等真正要用的时候，你发现自己得先打开命令行找到对应目录，再把 SKILL.md 里的格式复制出来，还要手动把它胶合成一个能用的 prompt。这一套流程下来，快则两分钟，慢则五分钟。而那句本来一句话就能说清楚的请求，直接问大模型反而更快——那你凭什么还要用这个 Skill？

我踩过一个特别典型的坑：装了一个“skill html 页面优化”，本来想着让 AI 帮我一次性改好一个官网落地页。结果因为这个 Skill 要求先进入指定目录、把 html 文件路径传进一个特定参数，我光是排查路径就花了十分钟。最后我干脆删掉它，直接在普通对话里说“把这段 html 的可访问性问题和语义化标签改一下”，十秒钟解决问题。

所以现在我给 Skill 定了条铁律：调用成本超过三步，这个 Skill 就基本可以判死刑了。真正的工具型 Skill，应该是“一句话触发、直接出结果”的。如果它需要你记得一堆参数和前置条件，那它只是在转移复杂度，并没有帮你减少思考负担。

1.3 输出质量不行：AI 味越重，越容易被弃用

第三个原因是质量。很多 GitHub 上的 Skill 看起来结构完整、说明详细，但实际跑一次就知道，输出带着非常浓的 AI 腔。比如一开口就是“在当今快节奏的背景下”“为了进一步提升效率”“综上所述”，或者每段结尾都来一句“这将为您的团队带来显著的价值”。这种内容你拿得出手吗？改起来比从零写还痛苦，因为你要先拆掉那些空话壳子，再把你真正想说的信息填回去。

这也能解释为什么“去 AI 味的 Skill”会出现在热搜词里。需求是被真问题逼出来的：大量默认输出带着机器腔，所以才会有人专门写一个“去 AI 味”的改写规则去约束它。而我自己最终留下来的 3 个 Skill 里，排第一的恰好就是这个方向的。这不是巧合，它说明用户对 Skill 的第一诉求其实是“能用”，第二诉求才是“强大”。输出需要大量返工的 Skill，装多少次都会被放弃。

2. 真正能留下来的 Skill，都长什么样

2.1 一个核心标准：必须接得住高频重复任务

我现在判断一个 Skill 能不能留下，先看任务频率。一件事如果你一周只做一次，甚至一个月才做一次，那就算这个 Skill 做得很完美，它也留不住——因为你每次用都要重新熟悉它，而人在“重新熟悉”和“直接手动做”之间，永远会选择后者。反过来，如果一件事你每天都要做，哪怕这个 Skill 只有 80 分，你也会天天用它，因为熟能生巧，用着用着你就知道哪里需要补一下。

我自己留下的第一个 Skill 是改写类，就是因为它绑定了我每天的写作任务。我每天早上要产出一篇内容，初稿大部分是 AI 生成的，我的工作流里天然有一个“把机器腔改成真人腔”的环节。高频、重复、边界清晰——这就是 Skill 天然的生长土壤。像“生成打斗动作提示词”这种需求，听起来很酷，但它的问题是低频。你一年能写几个打斗场景？等你想起来要用的时候，还得重新回忆这个 Skill 是怎么装的、参数怎么填，人一旦产生这种迟疑，Skill 就废了。

2.2 三个可复制的筛选标准

我把筛选标准总结成三句话，你可以直接拿去用：

• 这个任务我每周会做至少 3 次吗？达不到，直接别装；已经装了，删掉。
• 这个 Skill 的输出需要我返工的比例高不高？要是不用 Skill 做一遍需要 30 分钟，用 Skill 做一遍 15 分钟但是要返工 20 分钟，那它其实没有价值。
• 调用它比我自己手动做更省事吗？这里说的省事不是“看起来省事”，而是实际点击、等待、修改的总时间。很多 Skill 的上手成本，要在“使用前 3 次”里全部折算进去。

这套标准帮我筛掉了一批看起来很强但实际吃灰的东西。比如我装过一个“通用 HTTP 任务 Skill”，当时觉得很强大，但后来发现它依赖的 Python 环境和我的项目冲突，每次用都要先折腾依赖。虽然它的功能没问题，但调用成本超过了我的三条线，最后只用了两次就删了。合适，不等于能用；能用，不等于常用。

2.3 整活类 Skill 为什么活不过三天

我也想给“前任 Skill”“狗头军师 Skill”“ponytail Skill”这类整活型 Skill 说句公道话。它们不是做得不好，有些创意确实让人眼前一亮，但它们天然属于“低频娱乐需求”。人会被新鲜感驱动着安装，也会被更新鲜的东西驱动着卸载。这类 Skill 的价值是“让人开心一下”，而不是“让人省时间”。一旦收藏夹里出现了更新的、更好玩的 Skill，旧的自然就靠边站了。

工具型 Skill 则完全不一样。它是长在你的工作流里的，你的项目、你的写作、你的日常，决定了它的存亡。它不需要靠新鲜感来续命，因为它解决的是你每天都绕不开的问题。所以你会发现一个规律：真正留在你电脑里的 Skill，大概率都不是下载量最高的那些，而是跟你的具体工作绑定得最紧的那几个。

3. 实测留下来的 3 个 Skill，我是怎么配置和用的

3.1 留得下来的第一个：去 AI 味改写 Skill

先说每天都用的这个改写 Skill。我给它起的名字叫“nature-write”，因为最早是在 GitHub 上一个叫 nature write 的 Skill 基础上改的。它的核心不是给我一篇内容，而是给我一套“改写规则”，让大模型把我丢进去的机器腔文本改成更像真人写的东西。

规则文件我放在 SKILL.md 里，大概长这样：

--- name: nature-write description: 将输入文本改写为自然、具体、有细节的真人风格 --- ## 改写规则 1. 删除所有空话套话，包括“在……背景下”“随着……的发展”“综上所述”。 2. 每段必须包含至少一个具体例子或场景，不能只讲抽象道理。 3. 句子长度要有变化，长句和短句交替出现，避免每句都超过 30 个字。 4. 禁止输出“为……提供支持/保障”这类句式。 5. 保持原意，但允许重新组织段落顺序，优先把最重要的信息放到每段开头。

实际用的时候，我的流程只有一句话：“把这篇初稿用 nature-write 规则改一遍，输出完整版本。”然后我拿到结果，浏览一遍，主要看有没有信息被误删或者语气没到位，基本不再需要大改。以前我手动润色一篇 600 字的 AI 初稿要 15 分钟，现在 3 分钟就能收尾。它能留下来，就是因为这个任务每天都会出现，而且规则足够明确，输出稳定。

这个 Skill 能留住的另一个原因是它不依赖特定平台。我把同样的规则同时放进了豆包和 Codex 的 Skill 目录里，两边都能跑。不要把自己绑定在一个平台上，这个点我后面还会详细说。

3.2 留得下来的第二个：通用 HTTP/API 任务 Skill

第二个留驻率极高的类型是“基础设施型”Skill。名字可能五花八门，有的叫 workbuddy skill，有的叫通用 API 请求 Skill，核心能力其实一样：让 AI 能稳定地调用外部接口、处理返回数据、把结果整理成你想要的格式。

这类 Skill 在我这儿解决的具体问题是“每日数据汇总”。我每天要拉一次项目状态、统计几个指标，再生成一段简短的分析。原来这活儿要么我手动打开系统截图记录，要么写一段临时脚本每天改参数。后来我配了一个 HTTP 任务 Skill，把请求方式、鉴权头、超时重试、异常处理都标准化了，每天只需说一句“拉一下今天的项目数据，按指标汇总，输出一份带环比的分析”。

为什么这个 Skill 能留下来？因为它接住的是“AI 能力边界”问题。大模型本身没有联网执行能力，它需要工具来补齐这个边界，而 HTTP 请求就是这么个通用底层能力。我给它配了一次鉴权和若干常用接口定义之后，它几乎可以接管所有“查数据、调接口、做汇总”类的工作。这不是某个具体任务的 Skill，它是基础设施，所以每天都在用。

留这个 Skill 的时候有一个坑值得说：部署到内网服务器的环境，和本机差异很大。我曾经在一个企业内网环境里部署这套 HTTP Skill，一开始接口死活调不通。后来排查半天才发现，内网环境里的模型服务地址、鉴权方式和本地完全不一样，需要单独配置一个环境变量文件，并且要把证书校验策略改成内网专用的说明。这个经验我放到第 5 章“常见问题”里细说，反正记住一条：凡是涉及内网部署的 Skill，先确认服务地址、鉴权方式和网络策略，别拿本机经验直接套。

3.3 留得下来的第三个：语言学习/每日练习 Skill

第三个留下的 Skill 可能出乎你的意料，它跟工作关系不大，是一个语言学习 Skill。我配置它的时候，参考了社区里“skill 语言学习”那一类模板：每天早上输入一句“开始今日练习”，它就会给我出一段 5 分钟的口语对话，内容包含当天要复习的 10 个生词，然后在对话结束后给出语法纠错。

这个 Skill 留下来的核心原因是“反馈闭环”。它不只是丢给你一段学习材料，而是每次都会把我不熟悉的词、犯过的错整理进一个记录文件。第二天练习时，它会优先带上这些旧内容。学语言的人都知道，坚持最难的部分不是学，而是“学完没有反馈、没有积累”。而这个 Skill 让我的每次学习都沉淀下来，复习表一直在长，我也就越来越不舍得删。

配置这个 Skill 的过程其实很简单：就是定义了一个固定的输入触发词、一套出题模板、一个记录文件路径。没有用到任何复杂参数。但它让我意识到一个非常重要的规律——一个好的 Skill 不一定要复杂，关键是它能不能嵌入你每天都存在的那个“时间切面”。我的“每天早上的 5 分钟”是固定存在的，这个 Skill 恰好填了进去，它自然就留下了。

3.4 三个 Skill 的共同点复盘

拆完这三个 Skill，你会发现它们有一个共性：它们都不是“收藏型”的，而是“流程型”的。去 AI 味改写绑定写作流程，HTTP 任务绑定数据汇总流程，语言学习绑定晨间习惯。它们的价值不在于技能本身多炫酷，而在于它们填进了你真实生活和工作里本来就存在的空位。

反过来，那些吃灰的 Skill 大多没有这样的位置。要么是“我想学学看”，要么是“有备无患”，要么是“这个热词我必须跟进”。这些想法都没错，但它不产生日常调用，自然就留不住。如果你想让自己装的 Skill 真正留下来，不要先问“这个 Skill 强不强”，先问“我的哪个流程缺了它”。这一步想明白了，留下来几个，你说了算。

4. 新手装 Skill 前，先做完这三个决策检查

4.1 检查一：你手上是不是已经有明确的等待任务

这个检查用时 30 秒。你打开电脑，看看自己正在进行的项目里，有没有哪一件事是反复出现的，并且让人工来做特别烦的。如果有，再去搜对应的 Skill。如果没有，就关掉 GitHub 页面，别装了真的。

我身边有个朋友特爱装“测试 Skill”，每出一个新的都要装一遍，但问他到底测什么，他说“暂时没有，先备着”。三个月后他一个测试 Skill 都没用上，还占了大量上下文里的管道。这不是 Skill 的问题，是他的需求没落地。记住：Skill 的入口不是“收藏夹”，是“待办清单”。你的待办清单里没有它，它就永远是个摆设。

4.2 检查二：它能不能融入你现有的工具链

第二个检查是关于平台兼容性的。同一个 Skill，在豆包里能跑，在 Codex 里不一定能跑；在 Claude Code 里能跑，换到别的工具链又要重新配置依赖。所以装之前先确认两件事：第一，这个 Skill 是用什么语言写的，依赖哪些包；第二，这个平台的 Skill 目录结构和加载机制你熟不熟，像 Spring AI 2.0 这类框架里的 Skill 插件机制也一直在变，今天能用的加载方式下个版本可能就废弃了。

如果你用的是企业内网环境，这个检查更重要。像“deepseek harness 附带 skill 怎么部署到内网服务器”这类问题我在社区里见过很多，本质上就是一个兼容性加依赖管理问题。内网环境下，你需要确认模型服务的地址是否直接可达、鉴权方式是否一致、外网下载依赖包是否被限制。如果限制，你得提前把依赖包下载好，做成离线安装包。这一步不做，安装阶段就会卡死，Skill 自然留不下来。

4.3 检查三：你打算为它付多少维护成本

很多人忽略维护成本。Skill 不是装完就一劳永逸的，平台升级、依赖更新、接口字段变化，都会让 Skill 失效。我那个 HTTP 任务 Skill 就遇到过接口返回结构升级，导致解析逻辑整个崩掉的情况，我花了半小时改代码才恢复。正是因为我有维护它的预期，才会花这个时间；如果当时是随手装的，我大概率直接删掉了。

所以建议你装之前给自己定一个“维护预算”：每个月愿意花多少时间维护这个 Skill。如果它是一周用三回的高频工具，花维护时间是值得的；如果它的使用频率本来就不高，一旦失效，它就会变成你收藏夹里的又一个数码垃圾。把这条想清楚，很多“似乎有用”的 Skill 你就不会装了。

4.4 五步快筛法：装完 5 分钟内决定去留

最后分享一个我一直在用的“5 分钟快筛法”：安装完一个 Skill 后，马上用它做一件真实的小任务，然后做五分钟评估。

第一步，花 1 分钟读它的 SKILL.md，看它到底定义了什么规则、边界在哪。第二步，拿一个你自己的真实任务去跑，不要用它的示例数据。第三步，记录输出里需要人工修改的内容比例，超过一半说明 Skill 没成型，别留着。第四步，把不用 Skill 做一遍需要的时间和用 Skill 做一遍需要的时间放到一起对比。第五步，当天就决定去留。如果结论是“留着看看”，大概率就是吃灰的开始，直接删。

这套方法我试了很多次，准确率极高。真正有用的 Skill 在第一次测试时就会让你觉得“省事儿了”，而不是“好像有点用但又没那么明显”。含糊的感觉，就是吃灰的前兆。

5. 常见问题与排查技巧实录

5.1 “我的 Skill 为什么不生效”排查顺序

我见过的“Skill 不生效”案例里，九成不是 Skill 本身写得烂，而是环境问题。按下面这个顺序排一遍，基本能解决 80% 的情况：

先看报错日志。很多 Skill 加载失败时会在终端里输出原因，先读懂它是哪一步断了，是文件找不到、还是依赖报错、还是权限不足。再检查环境变量。API Key、模型地址、工作目录路径这些最容易出错，特别在你换了机器或者搬到内网环境之后。检查依赖是否齐全。Python 写的 Skill 特别容易出现缺包的问题，缺一个 requests 都能让整个 Skill 跑不起来。最后看平台版本。同一个 Skill 在不同版本的大模型平台里行为可能不同，有些平台的 Skill 目录识别规则变了，以前能用的现在就不认了。

这个排查顺序是我踩了很多坑总结出来的。一开始我总喜欢直接去看 Skill 代码，其实特别浪费时间。代码基本不会错，错的大多是它运行的“土壤”不对。

5.2 “为什么我照着教程装，别人能用我用不了”

这个问题在社区里几乎每天都在出现，尤其是一些带编号、带特殊命名的 Skill，比如最近的“skill 编码 193”“skill 编码 247”讨论。这里我得说句大实话：很多教程里贴的截图是作者在自己特定环境下跑通的，他的系统版本、平台版本、网络策略、依赖缓存都和你不一样。你看教程只看到了“装完就能用”的结果，没看到他在背后处理环境的那半小时。

所以别迷信“照着做一定能成”的教程。正确做法是理解这个 Skill 的核心机制：它无非就是一份规则文件加一段触发逻辑，最后都要交给大模型去执行。你把机制理解了，再遇到别人能用你用不了的情况，就知道从环境入手排查，而不是怀疑自己操作有问题。

5.3 内网部署 Skill 的独家经验

前面提到内网部署的问题，这里展开细说。我帮团队在企业内网服务器上部署过几次 Skill 环境，最深的三条经验如下：

第一，先确认模型服务地址和端口可达。内网往往没有外网 DNS 解析，如果你用的还是外网地址，怎么配都不通。正确做法是先 ping 通模型服务所在的主机，再把 Skill 配置里的 base_url 改成内网地址。第二，提前做好离线依赖包。很多 Skill 依赖 Python 包，内网环境无法直接 pip install，这时候你得在具备外网的机器上下载好对应版本的 wheel 包，再拷贝进内网安装。注意版本要完全一致，否则会出现一堆莫名其妙的报错。这些是部署场景下的标准操作。第三，鉴权方式别照抄。本地调试你可能一直用的是临时 token，内网里要改成服务账号或长期密钥，还要注意密钥文件路径对运行用户是否有读取权限。权限问题导致的失败，往往最隐蔽，因为日志里不一定直接告诉你“没有权限”。

这条经验今天看来有点朴素，但当时的排查过程确实折腾了一整个下午。写出来就是提醒你，内网部署和本机运行是两套逻辑，提前把环境变量、依赖缓存、网络策略这三件事整理清楚，Skill 部署才算真正稳。

5.4 三类建议别装的 Skill

最后给一个“黑名单”视角，帮你避坑。第一类是纯娱乐/整活型，像“前任 Skill”“狗头军师 Skill”，有意思，但不产生高频价值，装完三天必吃灰。第二类是你已经用其他工具稳定解决的功能型 Skill，比如你本身就有成熟的数据看板，再装一个“GIS 空间分析 Skill”纯属重复建设。第三类是一次性任务型，比如“做一条 AI 短剧”“生成一张专属头像”，这类任务做一次就结束了，它撑不起一个 Skill 的日常维护。

这三种 Skill 的共同特征是：要么低频，要么低依存，要么一次性。低频意味着你想不起来用，低依存意味着它没有长进你的工作流，一次性意味着它用完就该退役。装它们的那一刻确实很爽，但这种快感维持不了几天。我们留 Skill，要留的是在日常生活里替你省时间的伙伴，而不是收藏夹里落灰的纪念品。

最后想分享一个我自己的笨办法。我每隔两个月会回看一遍自己的 Skill 目录，把最近 30 天没调用过的全部删掉。这个动作一开始有点舍不得，删过几个当时觉得“以后会用”的精品，但后来发现，删完以后我的工作流一点都没受影响——这说明那些本来就不需要。反倒是电脑里剩下的这几个，每一个都是因为长期被用、被验证过，才走到今天。你也不妨给 Skill 设一个“冷静期”：装完三天，如果一次都没用过，直接删。这个习惯帮我从十几个 Skill 减到了 3 个，也让我每次写新 Skill 的时候都会多问自己一句：我到底能不能坚持用它？想明白这个，你收藏夹里留下的，就不会再是吃灰的展品了。