删掉80%的Skill后，我的Claude Code工作流反而更高效了

1. 从堆满 Skill 到删掉八成我到底经历了什么去年年底我开始重度使用 Claude Code那会儿刚摸清SKILL.md的写法整个人处于一种“万物皆可 Skill”的亢奋状态。看到有人分享一个自动整理会议纪要的 Skill装刷到一个能生成周报的 Skill装听说某个 Skill 可以帮我写 SQL 注释也装。三个月下来.claude/skills目录里塞了四十多个文件夹settings.json里的配置项越堆越长每次启动 Claude Code 都要等它扫描一遍所有 Skill 的元数据。结果呢真正高频使用的不到八个。剩下的要么是功能重叠要么是触发条件太窄根本想不起来用要么是维护成本高到每次改完还要同步更新文档。最离谱的是有几个 Skill 之间还会互相干扰——比如两个都监听“帮我写”这个触发词Claude 有时候会选错输出一堆莫名其妙的东西。所以上个月我做了一次彻底清理删掉了大约 80% 的 Skill只留下真正经得起日常考验的那几个。这篇文章不是教你“怎么装 Skill”而是想聊聊怎么判断一个 Skill 值不值得留以及我在这个过程中总结出的一套筛选逻辑。如果你也在用 Claude Code或者正在折腾npx skills那一套工具链这篇应该能帮你少走点弯路。2. 先搞清楚 Skill 到底解决了什么问题2.1 Skill 的本质是“预置上下文 触发规则”很多人把 Skill 当成插件来理解其实不太准确。Claude Code 的 Skill 机制核心就两件事一是通过SKILL.md给模型注入一段预设的指令和知识二是通过触发词或文件匹配规则决定什么时候加载这段上下文。它不执行代码不调用外部 API本质上是在改变模型在特定场景下的行为模式。举个例子我写过一个“代码审查”SkillSKILL.md里规定了审查时要检查命名规范、错误处理、边界条件、性能隐患这几个维度并且要求输出格式统一为“问题描述 严重程度 修改建议”。这样每次我让 Claude 审查代码时它就会按照这个框架来而不是泛泛地说“这段代码看起来不错”。理解这一点很关键因为它决定了你判断一个 Skill 是否值得保留的标准它是否在某个高频场景下稳定地提升了输出质量或减少了你的沟通成本。如果答案是否定的那这个 Skill 就是负担。2.2 为什么我们会忍不住装一堆 Skill我复盘了一下自己当初疯狂装 Skill 的心理大概有这么几种FOMO错失恐惧看到别人分享一个看起来很厉害的 Skill觉得不装就亏了。过度设计为一个可能一个月才用一次的场景专门写个 Skill美其名曰“自动化”。功能重叠不自知装了三个都能生成 commit message 的 Skill其实用哪个都一样。收藏癖把 Skill 当成书签觉得“先存着以后肯定用得上”。这些心理导致的直接后果就是.claude/skills目录越来越臃肿启动变慢触发冲突变多维护成本飙升。更隐蔽的问题是当 Skill 太多时你会逐渐失去对模型行为的掌控感——你不再清楚它为什么在这个场景下选择了那个 Skill输出不符合预期时也不知道该从哪里排查。2.3 删掉 80% 之后我留下了什么目前我保留的 Skill 大概有七个覆盖了以下几类场景类别保留数量典型用途代码质量2代码审查、重构建议文档写作1技术文档结构化输出数据处理1SQL 生成与优化项目管理1任务拆解与优先级排序日常效率2会议纪要整理、邮件草稿这些 Skill 的共同特点是每周至少用三次以上触发条件明确输出格式稳定维护成本低。剩下的那些要么被合并进了这几个要么直接删掉用普通 prompt 替代。3. 我是怎么筛选和清理 Skill 的3.1 第一步统计真实使用频率别靠感觉靠数据。Claude Code 本身不提供 Skill 使用统计但你可以通过几个间接方式来判断翻聊天记录搜索每个 Skill 的触发词看过去一个月出现了多少次。检查.claude/skills下每个文件夹的SKILL.md最后修改时间超过两个月没动过的基本可以标记为“待观察”。回忆最近两周的工作流哪些环节你主动想到“这里该用那个 Skill”。我当时的做法是拉了一个表格把每个 Skill 的名称、触发词、最后使用日期、使用频率高/中/低/几乎不用列出来。结果很直观四十多个 Skill 里高频的只有六个中频的四个剩下的全是低频或几乎不用。注意有些 Skill 是“季节性”的比如季度总结模板可能三个月才用一次。这类不要急着删先标记为“保留观察”等下一个周期到了再看。3.2 第二步识别功能重叠和触发冲突功能重叠很好理解就是两个 Skill 干的事差不多。比如我有三个 Skill 都能生成 commit message区别只是格式略有不同。这种直接保留最好的那个其余删掉。触发冲突更隐蔽也更危险。Claude Code 在匹配 Skill 时如果多个 Skill 的触发条件都满足它会选择一个来加载但选择逻辑并不总是符合你的预期。我遇到过最典型的情况是一个“代码解释”Skill 和一个“代码审查”Skill 都监听“看看这段代码”结果我想审查的时候它给我解释了一遍我想解释的时候它给我挑了一堆毛病。排查方法很简单把所有 Skill 的触发词列出来看看有没有重复或高度相似的。如果有要么合并要么把触发词改得更精确。3.3 第三步评估维护成本一个 Skill 的维护成本包括SKILL.md的内容是否需要随项目变化而更新是否依赖特定的文件结构或配置是否与其他 Skill 或settings.json中的配置有耦合出问题时排查难度有多大我删掉的一个典型例子是一个“自动生成 API 文档”的 Skill。它需要我维护一个额外的 YAML 配置文件来描述接口结构每次接口变了都要同步更新。用了两次之后我就发现直接让 Claude 读代码生成文档反而更快而且不需要维护额外文件。这种就是典型的“维护成本高于收益”。3.4 第四步合并与重构有些 Skill 不是没用而是粒度太细。比如我原来有“生成函数注释”“生成类注释”“生成模块注释”三个 Skill后来合并成一个“代码注释生成”Skill通过参数区分场景。这样既减少了数量又降低了触发冲突的概率。合并的原则是同一类任务、同一套输出规范、同一组触发场景的 Skill尽量合并。合并后SKILL.md会变长但维护点从三个变成一个总体成本是下降的。4. 留下来的 Skill 长什么样4.1 一个合格 Skill 的SKILL.md结构我现在的SKILL.md模板大概长这样--- name: code-review description: 对代码进行结构化审查输出问题清单和修改建议 trigger: 审查代码、review、检查这段代码 --- ## 审查维度 1. 命名规范变量、函数、类名是否清晰且符合项目约定 2. 错误处理是否覆盖了边界条件和异常路径 3. 性能隐患是否有不必要的循环、重复计算、内存泄漏风险 4. 可读性逻辑是否清晰注释是否到位 ## 输出格式 按严重程度分组每条包含 - 问题描述 - 所在位置 - 修改建议 - 严重程度高/中/低 ## 注意事项 - 不要泛泛而谈每条建议必须具体到代码行 - 如果代码整体质量较高也要指出可以进一步优化的点这个结构的关键在于触发词精确、审查维度明确、输出格式固定、注意事项清晰。这样每次触发时Claude 的行为都是可预期的。4.2 触发词的设计技巧触发词太宽泛会导致误触发太窄又会导致想用的时候触发不了。我的经验是用动词 对象的组合比如“审查代码”“整理纪要”“生成 SQL”而不是单独一个“审查”或“整理”。避免使用日常对话中高频出现的词比如“帮我”“看看”“写一下”。如果有多个 Skill 可能被同一句话触发给每个 Skill 加上独特的限定词。我现在的做法是每个 Skill 的触发词都经过实际测试在 Claude Code 里输入各种可能的表达方式看它是否稳定触发目标 Skill。测试通过后才正式启用。4.3 用settings.json控制加载行为settings.json里可以配置 Skill 的加载策略。我目前用的是按需加载模式只有触发词匹配时才加载对应的SKILL.md而不是启动时全部加载。这样启动速度明显变快而且减少了 Skill 之间的干扰。具体配置项因版本而异但核心思路是不要让所有 Skill 都处于常驻状态。把低频 Skill 设为按需加载高频 Skill 可以设为常驻但总数控制在十个以内。5. 那些被我删掉的 Skill问题出在哪5.1 场景太窄一个月用不了一次我删掉过一个“生成数据库迁移脚本”的 Skill。当时觉得这个场景很专业值得单独做一个。但实际上我一个月可能就写一两次迁移脚本而且每次的表结构都不一样Skill 里预置的模板反而限制了灵活性。后来直接用普通 prompt 描述需求效果一样好。这类 Skill 的问题是为了一个低频场景增加了长期的维护负担。除非这个场景极其复杂且重复性极高否则不值得做成 Skill。5.2 输出格式太死反而不好用有一个“周报生成”Skill我给它规定了固定的模板本周完成、下周计划、风险与阻塞、需要支持。结果用了两次就发现有些周报需要突出数据有些需要详细描述技术方案固定模板反而让我每次都要额外调整。后来改成用一个简单的 prompt 框架让 Claude 根据内容自动选择结构灵活多了。5.3 与其他 Skill 冲突排查成本高前面提到的“代码解释”和“代码审查”冲突就是典型例子。两个 Skill 单独用都没问题但同时存在时就会互相干扰。我当时的排查过程是先禁用其中一个测试另一个是否正常然后反过来最后确认是触发词重叠导致的。这个过程花了将近一个小时而这两个 Skill 的价值加起来也不值得这个排查成本。5.4 依赖外部文件同步麻烦有一个“API 文档生成”Skill 需要读取一个单独的api-schema.yaml文件。每次接口变更我都要先更新这个 YAML再让 Claude 生成文档。后来发现直接让 Claude 读代码里的类型定义和注释生成的文档质量差不多还省去了维护 YAML 的步骤。这种依赖外部文件的 Skill除非外部文件本身有独立价值否则不如不做。6. 清理之后的工作流变化6.1 启动更快干扰更少删掉 80% 的 Skill 之后最直观的变化是 Claude Code 启动速度明显提升。之前启动时要扫描四十多个 Skill 的元数据现在只有七个几乎秒开。更重要的是触发冲突几乎消失了Claude 的行为变得可预测很多。6.2 从“找 Skill”变成“写 Prompt”以前遇到一个任务我会先想“有没有对应的 Skill”。现在我会先想“这个任务需要什么上下文和输出格式”然后直接写 prompt。很多时候一个精心设计的 prompt 比一个 Skill 更灵活、更高效。Skill 只在那些高频、格式固定、需要长期保持一致的场景下才有优势。6.3 维护清单从四十项变成七项我现在每个月会花十分钟检查一下保留的 SkillSKILL.md是否需要更新、触发词是否仍然准确、输出格式是否还符合当前需求。七项检查起来很快四十项就是灾难。7. 常见问题与排查技巧7.1 Skill 不触发怎么办先检查触发词是否精确。在 Claude Code 里输入你期望触发的那句话看它实际加载了哪个 Skill。如果没加载目标 Skill可能是触发词不匹配或者被其他 Skill 抢先匹配了。解决办法是调整触发词或者临时禁用其他 Skill 来排查。7.2 Skill 触发了但输出不对检查SKILL.md里的指令是否清晰。常见问题是指令太模糊比如“输出格式要清晰”这种话等于没说。要具体到“按以下格式输出第一行是标题第二行是摘要第三行开始是正文”。另外检查是否有其他 Skill 的上下文混进来了。7.3 多个 Skill 冲突怎么排查用二分法先禁用一半 Skill测试问题是否复现然后逐步缩小范围。找到冲突的两个 Skill 后要么合并要么修改触发词让它们互斥。如果两个 Skill 功能高度重叠直接删掉一个。7.4 怎么判断一个 Skill 该不该删问自己三个问题过去一个月我用了几次如果删掉它我用普通 prompt 能不能达到类似效果维护它需要我额外做什么如果第一个问题答案是“少于三次”第二个答案是“能”第三个答案是“需要额外维护文件或配置”那就删。7.5npx skills安装的 Skill 怎么管理npx skills是个方便的工具可以快速安装社区分享的 Skill。但装完之后一定要检查SKILL.md的内容看看触发词是否与现有 Skill 冲突输出格式是否符合你的习惯。不要装完就用更不要装完就忘。我现在的做法是装完一个新 Skill先放在“试用区”观察两周两周内用不到三次就删。8. 给还在堆 Skill 的人几句实在话Skill 不是越多越好这跟代码库不是越大越好是一个道理。每一个 Skill 都是一个需要维护的资产它的价值等于“使用频率 × 单次收益 - 维护成本”。当这个值为负时它就是在拖后腿。我现在保留的七个 Skill每一个都经过了至少两个月的实际使用检验。它们覆盖了我日常工作中最高频、最需要保持一致性的场景。剩下的需求我用 prompt 解决灵活且没有维护负担。如果你现在.claude/skills目录里也塞了一堆东西不妨花半个小时做一次清理。统计使用频率、识别功能重叠、评估维护成本然后果断删掉那些“看起来有用”但实际很少碰的 Skill。删完之后你会发现Claude Code 用起来反而更顺手了。最后分享一个小技巧每次想装新 Skill 之前先问自己“这个需求我用 prompt 能不能解决”。如果能就别装。如果确实不能再考虑做成 Skill并且从第一天起就记录它的使用情况。三个月后回头看你会感谢当时克制的自己。