看到“Claude Code 装了一堆 Skill用了三个月我删掉了 80%”这个标题我第一反应是这不就是我吗而且我敢说只要你在过去几个月碰过 Claude Code大概率也经历过同样的心路历程——从“这个 Skill 好像能救命”到“这东西怎么越装越乱”再到“老子当初装它是图啥”。先说结论我现在 Claude Code 里只剩 8 个 Skill去掉的那些不是不好而是它们解决的根本不是我该让 Skill 解决的事。这篇文章就把我这三个月的装、用、删完整复盘一遍聊聊 Skill 到底是个什么东西、哪些值得留、哪些纯属自我安慰以及我最后留下来的那份精简清单是怎么筛出来的。先说个背景方便不同基础的朋友对齐。Claude Code 是 Anthropic 出的命令行 AI 编程助手可以理解成一个跑在终端里的 Agent它能读写文件、执行命令、调用各种工具而 Skill技能是它的一种扩展机制——本质是用 SKILL.md 文件定义一套“当遇到某类任务时按这个方式去处理”的指导流程。社区里现在已经有一堆现成 Skill从写代码、做 PPT、写小红书文案到给打斗场面写动作提示词五花八门而且还有一套“skill 编码”体系比如 247、193 这种编号很多人在群里晒自己收集了多少个“技能卡”跟集邮似的。如果你正处于“什么 Skill 都想装一个”的阶段这篇文章能帮你省下至少两个月的试错时间。我会把 Skill 的内部结构拆开讲清楚告诉你什么样的 Skill 是真正能给工作流提效的“亲兵”什么样的只是看起来有用的“气氛组”再给出我实测三个月后留下的清单和淘汰标准最后附上安装、调试、清理过程中的常见坑和排查方法。1. Skill 狂热一场空为什么我们总想“装全家桶”1.1 三个月前我也在“集邮”我入坑 Claude Code 的时间不算早真正开始重度使用是三个月前。当时社区里最热闹的除了“今天又出了什么新模型”就是“你装了什么 Skill”。GitHub 上有各种 awesome-Claude-Skills 仓库Reddit、X 上每天都有人在晒“我的 Skill 全家桶”配上各种花哨的目录结构和 README 截图真的很难不心动。我当时的心理活动非常典型万一以后用得上呢先装上总没错。于是我的~/.claude/skills目录就像家里的储物间什么都往里面塞。装的过程本身太简单了简单到让人失去警惕。大部分 Skill 就是 git clone 到 skills 目录或者手工创建一个文件夹塞一个 SKILL.md再放几个脚本。我当时还专门整理了一张 Excel 表给每个 Skill 标注了来源、功能、适用场景好像在做某个严肃的资产管理工作。结果呢真到干活的时候我能想起来用的不超过五个。大多数 Skill 的下场是装上的那一刻看了一遍 README然后永远封印在目录里。1.2 社区生态的推波助澜说实话这件事不能全怪自己贪心社区生态本身就是按“多多益善”的思路在设计。你去看那些 Skill 集合仓库目录是按场景分的前端、后端、数据分析、写作、营销、教育、绘画提示词……每个分类下面几十个 Skill作者还在 README 里写着“持续更新中”配上 star 数和更新日期产生的心理暗示就是——这些你都应该装。更要命的是“skill 编码”这套玩法。社区有人给 Skill 搞了编号体系什么 247、193搞得像收藏卡牌一样。再加上“book to skill”这类工具的出现——能把一本书转成一个 Skill——让门槛进一步降低甚至产生了一种幻觉只要把书变成 Skill书里的知识就等于被我掌握了。后来我才想明白这个逻辑就跟下载了一堆 PDF 就以为自己读完了一样纯属自我安慰。咱们待会儿细说这里面的认知误区。1.3 先泼一盆冷水Skill 的数量和效率不呈正相关我拿自己两个月的使用数据说话装了 30 多个 Skill 的时候我每天的 Claude Code 会话大概 20 次左右真正触发 Skill 的不到 5 次剩下的都是在普通对话里完成的。更扎心的是装得越多Claude Code 启动时加载上下文越慢有时候模型还会“困惑”——因为它需要在一个会话里同时看到几十个 SKILL.md 的说明反而不知道该优先参考哪一个。这就好比你给一个新员工发了一本三百页的公司制度手册还告诉他“每条都很重要”结果他遇到问题反而不清楚该按哪个流程走。模型也是这样Skill 说明书塞得太多它会在多个“建议做法”之间犹豫最后给你一个平庸的折中方案。后来我数了一下自己真正高频触发过的 Skill两只手数得过来这还没算重叠的部分。从那一刻起我开始动了删的心思。2. 先看清 Skill 的本质再谈删不删2.1 Skill 拆开看就三样东西在我决定精简之前先花了一晚上把所有 Skill 的结构摸了一遍。结论是不管社区里的 Skill 叫什么花哨名字拆开看就三样东西——SKILL.md 说明文件、辅助脚本、以及可选的参考文档。SKILL.md 是灵魂里面写了这个 Skill 的触发条件、使用步骤、输出格式、注意事项相当于给模型的一份“操作手册”辅助脚本通常是 Python、Shell 或者 Node 写的用来做一些模型本身不方便做的事比如读 Excel、调 API、解析日志参考文档则是给模型提供背景知识用的比如“公司编码规范”、“某框架的 API 速查”。明白这个结构之后很多判断就清晰了。比如有的“Skill”根本撑不起这三个要素——只有一个几行的 SKILL.md里面写着“你是 XX 专家请回答 XX 问题”这种本质上就是一条夹带了“人设设定”的 prompt它和你在对话里直接说“你现在是前端专家”没太大区别。再比如有的“Skill”洋洋洒洒几千字全是某本书的浓缩笔记——这种本质上是知识库不是技能放进 skills 目录反而没有单独用 RAG检索增强生成或者直接添加为上下文来得干净。2.2 它和普通提示词、MCP 的真实关系很多人分不清 Skill、Prompt提示词、MCPModel Context Protocol模型上下文协议三者的区别导致装了半天不知道自己在装什么。我说个最直白的理解Prompt 就是一张“纸条”你每次跟模型对话时递过去告诉它该怎么表现Skill 是一套“带说明书的工具箱”你告诉模型“遇到这类任务打开对应工具箱按照里面写的流程操作需要时用里面的工具”MCP 则是“万能插座”它负责让 Claude Code 能接入外部系统和数据源比如连上你本地的数据库、云端文档、设计软件。所以 Skill 可以调用 MCP 提供的工具但 Skill 不等于 MCP也不等于 Prompt。你要是装了一堆 Skill 却看不见效果先想想是不是把三者搞混了。我见过有人花了一下午配置某个“全自动 coding Skill”结果它里面写的要求是需要一个 MCP server 去对接内部接口而那个 server 压根没配——那这 Skill 跑得起来才怪。2.3 为什么大多数现成 Skill 对你没用社区里的现成 Skill它们的适用前提通常高度个人化。有的是作者根据自己的工作流设计的里面写死了文件路径、目录结构、偏好格式你直接拿来用大概率水土不服有的是通用场景的比如“代码审查”“写单元测试”这类看着通用但深度不够——因为真要写好代码审查你需要结合自己项目的上下文和团队规范一个通用 Skill 最多做到“让模型记着从哪些维度去审”深不了。更麻烦的是版本兼容性问题。Claude Code 更新迭代很快Skill 规范和 MCP 的衔接方式也在变很多早期 Skill 当时能用现在跑起来全是报错。我装过一个挺有名的“全自动生成前端页面”Skill第一次用是两个月前当时还算流程通畅上个月再触发它调用的一个脚本已经因为依赖库升级跑不动了而作者已经停止维护。所以我现在看到“三个月没更新”的 Skill 基本直接划走。一句话现成 Skill 不是不能用但你必须做好“拿回来自己改”的准备否则它大概率就是个一次性玩具。3. 三个月实测我留下哪几类 Skill3.1 值得留的类型画像经过三轮大扫除我从 30 多个 Skill 删到 8 个留下的这几类我觉得画像非常清晰你可以照着去对照自己装的那些。第一类高频且跨项目的通用动作。比如代码提交信息生成。这东西我几乎每天用它做的事情是让模型先git diff看一下改动再按 Conventional Commits 规范生成几条提交信息候选控制长度最后让我挑选。它不挑项目、不挑语言任何仓库都能用而且效果稳定属于装一次长期受益的类型。第二类带领域知识的专用流程。比如我留了一个“特定前端框架重构”Skill里面封装了公司内部项目的目录约定、状态管理偏好、组件设计规则。这些都是我亲手写的不依赖任何第三方纯针对我自己项目。这种 Skill 的价值在于把隐性的团队约定显性化成一份模型可执行的操作手册效率提升非常明显——模型少问七次废话直接按套路来。第三类嵌入本地工具链的辅助型 Skill。比如我留了一个 Python 脚本类的 Skill用来把 Claude Code 输出的结构化数据转换成特定格式的报告。它本质上是个封装得很好的本地工具模型只要知道“有这个东西可以用”就行。它对我的价值在于减少手动复制粘贴和格式微调而不是什么“高级智能”。第四类极少数让我省心的高质量“别人家 Skill”。我没那么自闭好用的第三方 Skill 也有留下的但标准很严格——源码短小、维护活跃、逻辑透明出问题了我自己也能改。这四条缺一不可。3.2 我的最终清单按类别举例具体清单我就不全列了有些涉及公司内部信息但可以给出类别和典型代表你类推就行开发提效类git 提交信息生成、代码审查清单、测试用例生成领域流程类公司前端项目重构规范、后端接口文档生成文本处理类文章去 AI 味、小红书文案改写本地工具类日志分析脚本封装、结构化报告生成这个结构有个特点每个 Skill 都对应我至少一周一次的实际触发频率而且都是“不依赖特定外部 API、不依赖某次会话魔法”的稳定型功能。另外我特意把“打斗动作提示词 Skill”这种猎奇类删得干干净净——不是说它烂是它对我的主线工作毫无贡献留着只会让目录混乱。3.3 我从 30 个删到 8 个的判断标准删的时候我对自己下了死命令每个 Skill 必须过四关过去 14 天是否真的触发过没触发过的直接待定。注意“我觉得以后会用到”这种理由无效以后的事以后再说。它做的事是否无法用一句 prompt 替代我先测试如果我在对话里输入一小段指令能达到八成效果那这个 Skill 就该被裁掉因为 prompt 更轻、更好维护。它是否引入了不可控的外部依赖需要连第三方 API、依赖某个 MCP server 且没配好、需要特定数据库账号的全部先冻结合格——等真正要用的时候再解冻配置。它的 SKILL.md 我是否看懂了如果我读完之后无法在脑子里复述它的触发条件和执行流程说明这份说明书不够清晰这种 Skill 放到上下文里只会给模型添乱。这四关走完该删的基本都浮出水面了。让我意外的是很多当初觉得“还挺重要”的 Skill真用四关一测连第一关都过不去——14 天没触发过说明它就是我的“收藏夹焦虑”产物。4. 自己动手怎么判断一个 Skill 该装还是该删4.1 安装前的“三连问”与其删得辛苦不如装得精明。我现在遇到任何 Skill不管是在 GitHub 看到 star 很多还是群里人疯狂推荐安装之前必须回答三个问题第一个问题它解决的是我最近两周内真实遇到的痛点吗注意是“最近两周”不是“可能未来会有”。如果一个 Skill 宣称能帮你写周报但你最近一个月都没写过周报那现在就不要装。等你下周真要写周报了再装也不迟这玩意安装成本不到五分钟根本不存在“不装就来不及”的情况。第二个问题我理解它的工作原理吗如果它的介绍里全是“智能、自动、全流程、一键生成”这种词但我说不出它底层调了什么命令、读取了什么文件、需要哪些依赖那这个 Skill 对我来说就是个黑盒。黑盒 Skill 是最危险的因为出问题你不知道从哪排查。我现在倾向安装那些作者把工作流程写得明明白白的 Skill哪怕实现粗糙一点但至少我能随时改。第三个问题如果它坏了我能自己修吗这就涉及到源码阅读能力了。一个好 Skill 应该是“透明”的——SKILL.md 最多几百行脚本逻辑清晰依赖少。如果你连它的脚本输出日志都看不懂那它坏掉的时候你只能等作者更新这种被动感在工作流里非常致命。4.2 快速验证的半小时测试法装完之后别急着正式使用我有一套半小时的快速验证流程。第一件事是构造一个包含典型触发条件的任务直接跑一遍。比如装了一个“前端代码审查”Skill那就拿一个故意埋了几个坑的小项目去测看它能不能把 SKILL.md 里的审查维度真正用起来。第二件事是故意给它一个边界情况——比如任务描述很模糊、缺少必要参数——看它是会主动追问还是默默地输出一个四不像结果。这个测试很能暴露 Skill 的真实质量好的 Skill 遇到信息不足时会明确告诉你需要哪些输入烂的 Skill 会硬着头皮瞎输出。第三件事是看运行日志确认模型到底有没有按 SKILL.md 走还是只是被“人设”带偏了随便发挥。这个测试跟招聘试用期一个逻辑——装的时候谁都说得好听跑一跑才能见真章。4.3 实际清理步骤与目录整理这里我分享一下当时做的具体清理操作方便你照着来。先备份把整个~/.claude/skills目录打包再逐个子目录检查并记录每个 Skill 的最近触发时间确定淘汰目标后把候选 Skill 移到~/.claude/skills_disabled而不直接删让你需要回滚时还有机会。确认使用一到两周没有影响后再彻底删掉并顺手把那些失效的编辑器插件、MCP 配置同步清理干净。skills_disabled这个方法我现在很推荐——它给了自己一个“缓冲期”避免误删后懊恼也不至于让你一步到位地产生断舍离的焦虑。等两周后你会发现那些被停用的 Skill 你已经完全想不起来它们的存在了这时候再删一点心理负担都没有。5. 常见问题与排查技巧实录5.1 Skill 不生效怎么排查很多人在群里问“为什么我的 Skill 不生效”我印象里第一次问出这个问题的朋友通常都会先去看是不是没重启 Claude Code——你新装的 Skill需要重启会话或者重新加载配置才可能被模型感知。我还见过配置了 Skill 路径但大小写写错了的情况看似无伤大雅结果模型根本找不到文件。排查思路其实很朴素第一步看日志。Claude Code 在 verbose 模式下会输出完整的上下文加载记录你能看到模型到底加载了哪些 SKILL.md、有没有报错。第二步看路径。Skill 的目录结构和命名必须符合当时的版本规范很多教程写的路径是新版改过的你按旧版放系统当然找不到。第三步看描述。SKILL.md 里写触发条件和关键词时如果语义太狭窄模型在日常对话里根本意识不到“这时候该用这个 Skill”它就会走普通对话流程看起来跟没装一样。还有个小技巧是安装后在会话里主动用一句“请根据 XX 情况触发对应 Skill”来测试能直接判断是加载问题还是触发条件问题。5.2 Skill 之间“打架”怎么办Skill 数量一多互相干扰的情况就有了。我遇到过一个真实场景一个“代码优化”Skill 和一个“前端性能审查”Skill 同时出现在上下文里同一个按钮组件一个建议用 Web Worker 优化计算另一个建议用 Canvas 重绘方案模型夹在中间左右为难最后给了一个拼凑版本两个方案各自实现了一半几乎没法用。解决办法有两个方向。第一是减少同时加载数Claude Code 按需加载能力是有限的先区分哪些 Skill 是“常驻”的哪些是“按需”的尽量别把一堆技能全塞进默认配置。第二是写清楚 Skill 的边界在 SKILL.md 里增加“不要处理 XX 类问题”之类的排除性描述明确指出和其他 Skill 的分工边界。我留下的那些 Skill 中每个都在开头用一两句话写了“本 Skill 包含什么、不处理什么、遇到边界外问题直接在回复里说明”这样至少模型知道什么时候该婉拒。5.3 部署到内网和接入其他模型的坑不少朋友关心怎么把 Claude Code 的 Skill 部署到内网服务器或者接入 DeepSeek、Qwen、GLM 这类模型。我测试过几轮在这块踩过不少泥但要点其实挺明确第一Skill 本身不绑定某一家模型SKILL.md 和脚本大多是通用的真正要改的是 API 配置和基础地址第二切换到非 Claude 的模型时调用方式会有细节差异特别是工具调用格式一定要在接入层做好适配。社区里有人用 cc-switch 这类工具做多模型切换我的经验是可以但切换后第一时间要跑的就是那几个核心 Skill别等到正式干活才发现某个工具调用不兼容。内网部署方面基本的思路是把 Skill 目录同步到服务器上再把 Claude Code 的配置文件指过去最后确认服务器上有没有安装所需的依赖和脚本环境。很多“怎么部署都失败”的情况最后都卡在依赖缺失而报错信息又不直观。实际测试时我踩过最典型的坑是服务器上的 Python 版本不对Skill 脚本用了一个较新特性比如 3.11 才有的语法内网环境还是老版本直接红色报错。这类问题排查起来不难但很烦人所以我现在每部署一个 Skill都会先看脚本头部的 interpreter 声明和 requirements 文件。5.4 几个典型的“看着有用实则没用”案例聊几个有代表性的淘汰案例帮大家建立直觉。第一个是“狗头军师 Skill”。它升级了 prompt加了“全方位多层次分析”“从 15 个角度给建议”之类的输出框架看起来确实能有效延长回答长度看起来有理有据但这个 Skill 不读任何外部材料所有信息都是模型生成时在脑子里瞎编。我后来发现类似的长篇分析用一条经过精心设计的 prompt 也能达到同样效果完全没必要占用一个 Skill 名称。第二个是“图书转 Skill”类产物。把一本书压成一份 SKILL.md 放进技能目录看起来是“把作者经验注入模型”实际上在缺少检索上下文的情况下模型不会因为“书上说”就有更高的正确率反而可能在引用时表现得异常笃定这是最危险的。真正需要领域知识时更好的方案是把资料作为参考文档按需检索出来再结合当前任务使用而不是把它写成一份万能说明书。第三个是“去 AI 味”Skill。这类写作辅助 Skill 我留了一个其余全删了。原因是这类东西高度依赖场景和受众且它的作用容易衰减——同一个去 AI 味模板用几星期后输出就有了新的套路感你会陷入反复调参的循环。说得直白点这种 Skill 治标不治本它真正教会你的应该是建立自己稳定的写作风格。6. 写在最后精简后的工作流给我带来了什么6.1 我才发现少即是多这事是真的删完 Skill 后的第一周我的 Claude Code 体验发生了两个明显变化上下文加载更快了、模型回复更贴线了。失去 20 多个“潜在可能有用”的 Skill换来的实际收益是我在处理日常任务和编码工作时模型不会再频繁跑偏、不再被一堆相互冲突的触发条件牵着走。那种“工具箱越满越自信”完全就是错觉真正让你安心的是每一个留下来的 Skill 都见过血、都上过线、都在真实任务里顶过用。6.2 一套可持续的 Skill 管理习惯我现在的习惯是每个月最后一个周末花半小时做一次“Skill 审计”。打开skills目录对照过去四周的使用记录凡是没被触发过的先移到skills_disabled等下个月再复核一次如果依然没用就删除。这套流程看起来朴素但坚持下来后我的 Skill 数量基本稳定在 10 个以内。另外每当我发现某个任务连续三次需要给 Claude Code 写几乎一样的长指令时我才会考虑把它固化成一个新的 SKILL.md——也就是说我现在走的是“需求驱动型”路线而不是“工具驱动型”。社区里的东西永远是你拿回去改完、剪完了、适配了自己的过程才真正属于你。6.3 给刚开始接触 Skill 的人一句忠告如果你刚接触 Claude Code 没几天我给你一句实在话先别急着装任何 Skill老老实实用默认配置跑两周真实项目。这两周里每次当你觉得“如果 Claude 能记住某个套路就好了”的时候把这个“套路”记下来。两周后回头看你列出的那几个高频重复场景才是你真正需要 Skill 的地方。那时候你去社区找对应的现成 Skill再按自己的实际情况改一版效果会远超你现在“先装 40 个再说”的策略。Skill 从来不是越多越好它是越准越好。装一堆用不上的 Skill跟囤一屋子过期罐头一样除了占地方就是给自己制造幻觉。