★ FEATURED ARTICLE 最近社区里聊得最热闹的一个词就是 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 加载时报“目录不存在”平台 Skill 目录识别规则变了检查平台当前加载路径把 Skill 移到正确目录调用模型接口超时内网服务地址不可达或 DNS 未配置ping 模型服务主机修改 base_url 为内网地址输出结果出现乱码或半截上下文长度限制或返回被截断检查 max_tokens 参数精简 Skill 输出模板明明装了却识别不了平台版本不兼容或 SKILL.md 头信息不完整核对平台版本要求补全 name 和 description 字段这个排查顺序是我踩了很多坑总结出来的。一开始我总喜欢直接去看 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 的时候都会多问自己一句我到底能不能坚持用它想明白这个你收藏夹里留下的就不会再是吃灰的展品了。
阅读完成 · 觉得有帮助？
