1. 从“装了一堆”到“删掉八成”一个真实的使用轨迹去年秋天我开始认真用 Claude Code 做日常开发那时候的心态跟很多人一样——看到社区里有人分享一个 Skill觉得有用装看到另一个能自动生成测试用例的也装再刷到一个能帮我写周报的顺手也装。三个月下来.claude/skills目录里塞了四十多个文件夹每个里面都躺着一份SKILL.md。结果呢真正每天在用的掰着手指头数得过来不超过八个。这个标题说的“删掉 80%”不是夸张。我最后清理完四十多个 Skill 只留了七个。剩下的要么功能重叠要么触发条件太模糊根本轮不到它上场要么就是当初装的时候觉得“以后可能会用”结果三个月一次都没被调用过。如果你也在用 Claude Code或者刚开始接触 Skill 这套机制正在纠结“到底该装哪些”“怎么管理这些 Skill”那这篇就是写给你的。我会把自己踩过的坑、删掉的那些 Skill 到底为什么被删、留下来的七个又凭什么活下来全部拆开讲清楚。涉及到的SKILL.md写法、settings.json配置、npx skills的用法都会给到可以直接抄的示例。先说一个核心判断Skill 不是越多越好每多一个 Skill你的上下文里就多一份“噪音”。Claude Code 在决定调用哪个 Skill 的时候需要读取所有 Skill 的描述信息来做匹配。Skill 越多匹配的准确率反而会下降因为相似描述之间会互相干扰。这跟你在一个塞满工具的抽屉里找螺丝刀是一个道理——工具越多找起来越慢还容易拿错。2. Skill 机制到底怎么工作的先搞懂原理再谈取舍2.1 SKILL.md 的加载逻辑与触发条件很多人装 Skill 的时候根本没看过SKILL.md里面写了什么直接复制粘贴就完事了。但你要做取舍就必须先理解它是怎么被触发的。Claude Code 启动时会扫描.claude/skills目录下的所有子文件夹读取每个文件夹里的SKILL.md。这个文件通常包含两部分元信息名称、描述、触发关键词和正文内容具体的指令、步骤、示例。元信息部分会被加载到上下文里用于判断“当前这个任务要不要调用这个 Skill”正文内容只有在 Skill 被真正调用时才会完整加载。这就意味着一个关键结论元信息的质量直接决定了 Skill 会不会被用上。我见过太多SKILL.md的描述写得含糊其辞比如“帮助处理代码相关任务”——这种描述等于没写Claude 根本判断不出来什么时候该用它。一个写得好的描述应该是这样的--- name: api-test-generator description: 当用户需要为 REST API 接口生成单元测试时使用支持 Express、FastAPI、Spring Boot 三种框架输入接口定义文件路径即可生成对应的测试代码 trigger: 生成接口测试、写 API 测试、接口单测 ---对比一下那种“帮助生成测试代码”的模糊描述上面这个明确说了什么时候用为 REST API 生成单元测试、支持什么三种框架、怎么用输入接口定义文件路径。Claude 在匹配的时候命中率完全不是一个级别。2.2 上下文窗口的“隐性成本”这是很多人忽略的一点。每个 Skill 的元信息虽然不长但四十多个 Skill 加起来光描述信息就能占掉一两千个 token。这些 token 是每一轮对话都要消耗的不管你这次有没有用到那个 Skill。我做过一个粗略的测算一个中等复杂度的SKILL.md元信息部分大约 50 到 80 个 token。四十个 Skill 就是 2000 到 3200 个 token 的固定开销。听起来不多但当你上下文窗口用到后期这几千个 token 可能就是“还能不能塞下一整个文件”的区别。更关键的是干扰效应。当你有五个 Skill 的描述里都出现了“代码审查”这个词Claude 在匹配的时候就会犹豫可能选了 A 但其实 B 更合适或者干脆一个都不选。删掉冗余的 Skill 之后剩下那个“代码审查”Skill 的调用准确率会明显上升。2.3 npx skills 与手动管理的区别社区里有个工具叫npx skills可以快速安装和管理 Skill。用法很简单npx skills install skill-name npx skills list npx skills remove skill-name但我要说的是不要完全依赖工具来管理。npx skills帮你做的是下载和放置文件它不会帮你判断“这个 Skill 跟已有的有没有冲突”“描述写得够不够好”。我早期就是无脑npx skills install装了一堆功能重叠的后来手动整理的时候才发现光“生成 commit message”这个功能就有三个不同的 Skill描述还都差不多。手动管理的核心工作是两件定期审查SKILL.md的描述质量以及合并功能重叠的 Skill。这两件事工具替你做不了。3. 我删掉的 80% 都长什么样五类典型“僵尸 Skill”3.1 第一类功能重叠的“多胞胎”这是数量最多的一类。我装了三个跟“代码格式化”相关的 Skill分别来自不同的作者功能大同小异都是读取文件、按规则格式化、写回。区别只在于一个支持 Prettier 配置一个支持 ESLint 配置还有一个两个都支持。这种“多胞胎”Skill 的危害在于它们互相干扰导致 Claude 在需要格式化的时候反而不知道该调哪个最后可能一个都不调直接用自己的默认行为处理了。我删掉两个只留了那个两个配置都支持的调用成功率立刻上来了。判断标准很简单如果两个 Skill 的描述里有超过 60% 的关键词是重叠的那大概率只需要留一个。留哪个留描述更具体、覆盖场景更广的那个。3.2 第二类触发条件模糊的“万金油”有一类 Skill 的描述写得特别宽泛比如“帮助提升代码质量”“辅助代码重构”“优化项目结构”。这种 Skill 的问题在于Claude 根本判断不出来什么时候该用它——因为几乎所有编程任务都可以算作“提升代码质量”。我删掉的一个典型例子是一个叫“code-helper”的 Skill描述是“帮助处理各种代码相关问题”。装了一个月一次都没被调用过。因为 Claude 在面对具体任务时会优先匹配描述更精确的 Skill这种“万金油”永远排在后面。注意如果你在写自己的 Skill描述里一定要包含具体的触发场景和明确的输入输出。宁可写窄一点也不要写宽。窄了可以后续扩展宽了等于没有。3.3 第三类低频使用的“偶尔用一次”这类 Skill 最让人纠结——它确实有用但使用频率极低。比如我装过一个“生成数据库迁移脚本”的 Skill三个月里只用了两次。还有一个“生成项目 README”的用了一次。这种 Skill 要不要删我的判断标准是如果一个月用不到一次就删掉。需要的时候再装回来就是了npx skills install几秒钟的事。留在那里它每天都在消耗你的上下文资源而收益是一个月才兑现一次。有人可能会说“删了万一要用怎么办”。我的实际经验是真正需要的时候你花两分钟重新装一个比让它在那里躺三个月只为了省这两分钟划算得多。3.4 第四类质量不过关的“半成品”社区里分享的 Skill 质量参差不齐。我装过几个用的时候才发现SKILL.md里的指令写得模棱两可示例代码跑不通甚至有的连基本的错误处理都没写。这类 Skill 的危害不只是“没用”而是会误导 Claude 产生错误的输出。一个写得不好的 Skill比没有 Skill 更糟糕。因为 Claude 会认真执行里面的指令但指令本身有问题结果就是产出垃圾。我删掉的一个典型是一个“自动生成 API 文档”的 Skill它的指令里说“读取所有路由文件提取注释生成文档”但没有说明注释的格式要求。结果 Claude 把代码里所有的//注释都提取出来了包括那些“TODO”“FIXME”之类的生成的文档完全不能用。3.5 第五类跟当前项目无关的“外来户”我同时维护着几个不同类型的项目——有 Node.js 后端、有 Python 数据处理脚本、还有一个纯前端的 React 项目。早期我把所有项目相关的 Skill 都装在全局目录里结果就是写 Python 的时候一堆 Node.js 相关的 Skill 在干扰匹配写前端的时候Python 的 Skill 又在旁边“凑热闹”。后来我改成了按项目配置 Skill。Claude Code 支持在项目根目录下放.claude/skills这样每个项目只加载自己需要的 Skill。全局目录只留那些真正跨项目通用的比如“生成 commit message”“代码审查”这种。这个改动带来的效果非常明显每个项目的 Skill 数量从四十多个降到了五到十个调用准确率大幅提升。4. 留下来的七个 Skill凭什么它们能活下来4.1 高频刚需每天至少用一次留下来的第一个标准就是高频。我统计了一下最终留下的七个 Skill 里有四个是每天至少用一次的Skill 名称功能日均调用次数commit-writer根据 diff 生成规范的 commit message5-8 次test-runner运行测试并解析失败原因3-5 次code-reviewer对指定文件做代码审查2-3 次doc-generator为函数和类生成文档注释1-2 次这四个是真正的“日用品”每天都要用而且用起来确实省时间。比如commit-writer我只需要说“帮我写个 commit”它就会读取当前 git diff按照 Conventional Commits 规范生成消息我确认一下就能提交。整个过程不到十秒比我自己想 commit message 快多了。4.2 描述精准Claude 一匹配一个准留下来的 SkillSKILL.md的描述都写得非常精准。以test-runner为例它的描述是这样的--- name: test-runner description: 当用户要求运行测试、检查测试结果、或排查测试失败原因时使用。支持 Jest、Pytest、Go Test 三种测试框架自动识别项目使用的框架并执行对应命令 trigger: 跑测试、运行测试、测试失败了、看看测试结果 ---这个描述的好处是触发词覆盖了用户可能说的各种表达方式“跑测试”“运行测试”“测试失败了”同时明确了支持的范围三种框架和自动识别的能力。Claude 在匹配的时候只要用户提到跟测试相关的内容基本都能命中。4.3 维护活跃作者还在更新这一点可能有点主观但确实是我考虑的因素之一。留下来的 Skill 里有几个是社区里比较活跃的作者维护的SKILL.md会随着工具版本更新而调整。而那些装完就没人管的 Skill用着用着就可能因为 Claude Code 版本升级而失效。我的做法是每隔一个月检查一下留下来的 Skill 有没有更新。如果有就npx skills update一下如果发现某个 Skill 已经半年没更新了而且用起来开始出问题就考虑替换或删除。4.4 可组合能跟其他 Skill 配合使用留下来的 Skill 还有一个特点它们之间可以组合。比如我先用code-reviewer审查代码发现问题后用test-runner跑测试验证最后用commit-writer提交。这三个 Skill 形成了一个完整的工作流互相之间的输出可以作为对方的输入。这种组合能力是单个 Skill 不具备的。当你有一组能配合的 Skill 时它们产生的价值是 112 的。而那些孤立的、跟其他 Skill 没有交集的往往就是最先被删掉的。5. 实操如何给你的 Skill 做一次彻底“瘦身”5.1 第一步盘点现状列出所有 Skill先看看你现在装了多少# 查看全局 Skill ls ~/.claude/skills/ # 查看项目级 Skill ls .claude/skills/ # 如果用 npx skills 管理 npx skills list把所有的 Skill 名称和描述列到一个表格里。这一步的目的是可视化——当你看到四十多个 Skill 排在一起的时候那种“太多了”的感觉会非常直观。5.2 第二步按使用频率分类接下来做一件事回顾过去一个月的使用记录。Claude Code 本身不提供调用统计但你可以手动记录一周。每次调用 Skill 的时候在笔记里记一笔。一周下来你就能清楚地看到哪些 Skill 被用过哪些一次都没出现。根据我的经验一周的记录就足够做出判断了。那些一周都没被调用过的 Skill大概率一个月也不会被调用。5.3 第三步合并重叠删除低频分类之后按以下规则处理功能重叠的只留一个选描述最精准、覆盖最广的一周没用过的直接删需要时再装描述模糊的要么重写描述要么删掉质量差的果断删不要犹豫跟当前项目无关的移到项目级目录或者删掉我自己的清理过程花了大约一个小时从四十多个删到七个。删完之后重启 Claude Code明显感觉到响应速度变快了Skill 调用的准确率也上来了。5.4 第四步优化 settings.json 配置清理完 Skill 之后顺便检查一下settings.json的配置。这个文件控制着 Claude Code 的各种行为包括 Skill 的加载路径、权限设置等。一个典型的配置是这样的{ skills: { paths: [ ~/.claude/skills, .claude/skills ], autoLoad: true }, permissions: { allowFileWrite: true, allowTerminalCommand: true } }重点检查paths里有没有多余的路径以及autoLoad是否开启。如果你像我一样按项目配置 Skill可以把全局路径里的项目相关 Skill 清理掉只留通用的。提示修改settings.json之后需要重启 Claude Code 才能生效。建议修改前先备份一份万一出问题可以快速回滚。6. 写一个“能活下来”的 Skill从描述到测试6.1 描述怎么写才精准如果你要自己写 Skill描述部分是最关键的。我的经验是遵循“三要素”原则什么时候用明确触发场景比如“当用户要求生成 API 文档时”支持什么明确能力范围比如“支持 OpenAPI 3.0 和 Swagger 2.0”怎么用明确输入输出比如“输入路由文件路径输出 Markdown 格式文档”把这三要素写进description字段Claude 的匹配准确率会高很多。6.2 正文指令的写法与避坑正文部分是指令的具体内容。我踩过的坑包括指令太笼统“读取文件并处理”——处理什么怎么处理缺少错误处理“如果文件不存在就报错”——报什么错怎么报示例代码跑不通写示例的时候一定要实际跑一遍一个好的正文应该像一份操作手册第一步做什么、第二步做什么、遇到什么情况怎么处理全部写清楚。6.3 测试 Skill 是否被正确调用写完 Skill 之后一定要测试。测试方法是用不同的表达方式触发它看看是不是每次都能被正确调用。比如你写了一个“生成 commit message”的 Skill测试的时候不要只说“帮我写 commit”还要试试“提交代码”“生成提交信息”“写个 commit message”等各种说法。如果某些说法触发不了说明描述里的触发词覆盖不够需要补充。我自己的测试清单通常包括直接说功能名称“用 commit-writer”描述需求“帮我写个提交信息”间接表达“代码改完了准备提交”混合其他任务“先跑个测试然后帮我提交”四种方式都能正确触发才算通过测试。7. 常见问题与排查技巧实录7.1 Skill 不触发怎么办这是最常见的问题。排查顺序如下检查文件位置SKILL.md是否在正确的目录下全局是~/.claude/skills/name/SKILL.md项目级是.claude/skills/name/SKILL.md检查文件格式元信息部分的 YAML 格式是否正确---分隔符有没有写对检查描述质量描述是否足够具体触发词是否覆盖了你的表达方式检查冲突是否有其他 Skill 的描述跟它相似导致匹配被抢走我遇到过一次Skill 死活不触发排查了半天发现是SKILL.md的 YAML 里description字段前面多了一个空格导致解析失败。这种细节问题最容易忽略。7.2 Skill 触发太频繁怎么办反过来有些 Skill 触发太频繁不该用的时候也跳出来。解决办法是收窄描述。比如把“处理代码相关任务”改成“当用户明确要求重构指定函数时使用”触发频率立刻降下来。7.3 多个 Skill 冲突怎么处理当两个 Skill 的描述高度相似时Claude 可能会随机选一个或者两个都不选。处理方法是合并把两个 Skill 的功能整合到一个里面用一个更全面的描述覆盖两个场景。如果确实无法合并比如两个 Skill 来自不同作者功能有细微差别那就删掉一个。留着的那个不一定是“更好”的但一定是你更常用的。7.4 如何判断一个 Skill 该不该删我总结了一个简单的判断流程判断条件处理方式一周内用过保留一周内没用但描述精准且无重叠观察一周再决定一周内没用且有功能重叠删掉重叠的留一个描述模糊无法判断触发场景重写描述或删掉质量差用的时候出过错直接删跟当前项目无关移到项目级或删掉这个流程走一遍基本就能做出决定了。7.5 删错了怎么恢复删之前先备份# 备份整个 skills 目录 cp -r ~/.claude/skills ~/.claude/skills-backup # 或者只备份要删的 mv ~/.claude/skills/name ~/.claude/skills-backup/这样万一删错了直接从备份目录移回来就行。我自己的习惯是先移到备份目录观察一周确认真的不需要了再彻底删除。8. 一些关于 Skill 管理的个人体会三个月从四十多个删到七个最大的感受是Skill 的价值不在于数量而在于匹配精度。一个精准的 Skill比十个模糊的 Skill 有用得多。我现在每个月会花十分钟做一次“Skill 审查”看看有没有新的需求需要装 Skill看看现有的 Skill 有没有更新看看有没有哪个 Skill 这个月一次都没用过。这个习惯让我的 Skill 列表始终保持在一个精简、高效的状态。另外一点体会是不要为了“以后可能用”而装 Skill。我删掉的那些里面至少有一半是当初觉得“以后可能会用到”才装的结果三个月一次都没碰过。真正需要的时候再装完全来得及。最后分享一个我最近在用的技巧给 Skill 加版本号。在SKILL.md的元信息里加一个version字段每次修改都递增。这样当 Claude Code 升级导致某些 Skill 失效时你能快速定位到是哪个版本出的问题回滚也方便。--- name: commit-writer version: 1.3.0 description: ... ---这个习惯看起来不起眼但在排查问题的时候能省不少时间。尤其是当你同时维护多个项目、每个项目有不同 Skill 配置的时候版本号能帮你快速理清哪个是哪个。