1. 先说结论八十多个 Skill 用三个月我砍到只剩十一个三月初我把 Claude Code 配好的那个周末.claude/skills/目录里躺了二十七个 Skill。三天后变成四十多个。再往后两周我彻底陷入了社区里那种“又出新 Skill 了快装上试试”的状态最多的时候目录里超过八十个。三个月后的昨天我一口气全清了只留下十一个。写这篇不是为了劝退谁。Skill 本身是有价值的我删到只剩十一个恰恰说明它在某些场景里是真的好用。问题出在“装”这个动作上——我当初把“装了多少 Skill”当成了生产力指标结果被数量反噬。那种感觉就像买书书架上的书越多越觉得自己有文化可真读过的、能内化成能力的永远是少数。我的“技能囤积病”大致经历了三个阶段。第一个阶段装上就是赚到。看到任何一个 agent skill、工作流技巧、第三方 superpowers 套装下意识就是 clone 到本地往 skills 目录一扔感觉 Claude Code 的能力上限又高了一截。那段时间我几乎不挑食不管是代码审查、写作润色、数据分析还是所谓的“狗头军师”式头脑风暴 skill全都照单全收。甚至有人把一整本书转成一个 skill美其名曰让 AI 掌握作者的思维模型我也装了结果一次都没派上用场。第二个阶段功能开始互相打架。大概是第五周左右我发现两个 skill 都声称接管“web 搜索”场景同一个任务里不知道按谁的规则执行有一回跑代码审查跳到一半被另一个 skill 的上下文干扰输出风格完全变了。我意识到skill 不是叠加态它是提示词层面的“行为宪法”同时生效的规则越多行为就越不可预测。第三个阶段是转折点。某个周末我翻日志发现八十多个 skill 里被真实触发过的不到三分之一剩下那三分之二是彻头彻尾的“占位符”——它们安静地躺在目录里既不出力也不出错只是持续吞噬掉一部分上下文预算。从那一刻起我开始认真怀疑“装越多越强”这个公式也才有了后面那次大规模清理。所以这篇我重点讲三件事Skill 的运行机制到底怎么影响使用、什么样的 Skill 值得留下、以及如何用一套可复用的方法把不再产生价值的 skill 清理掉。如果你也处在大量安装 skill 的阶段下面的踩坑记录应该能帮你省下至少几个月的试错时间。2. Skill 到底是个什么东西值得你这么上头2.1 Skill 不是插件是一份“行为说明书”先消除一个误区很多人把 Skill 类比成 VS Code 插件、浏览器扩展这种理解其实是被市场话术带偏了。我一开始也以为是装上就多一个新功能实测下来Skill 更像是一份“行为说明书”。每个 Skill 本质上是 skills 目录下挂着的一个文件夹里面必须有SKILL.md文件。文件头部用 frontmatter 写 name、description 等元信息正文则是给模型看的一整套行为指令。Claude Code 在处理任务时会先根据当前任务和各个 skill 的 description 做匹配匹配上了才把正文加载出来让模型按照这里面写的流程行动。举个例子我的保留清单里有个review-checklist。它并不会在界面上多出一个“代码审查”按钮它的作用是当我说“帮我 review 一下这个 PR”时模型会按 SKILL.md 里写好的顺序——先读改动文件列表、再按依赖方向逐层看代码、最后按 checklist 输出问题清单——而不是随手给一段泛泛的点评。换句话说skill 不注册新工具它改变的是模型使用已有工具的方式。这一点太重要了。很多人觉得“我装了 50 个 skillClaude Code 应该上天了”实际上它只是多读了 50 份行为约束。约束越多模型每一次决策的路径就越长出现偏差的几率也越高。真正高质量的 skill 应该是“小而准”的行为模板而不是一份包罗万象的万能提示词。2.2 用户级、项目级与第三方套装三处我踩过的安装位置Claude Code 的 skill 可以放在两个层级用户级目录对所有项目生效项目级目录只对当前项目生效。以 macOS/Linux 为例用户级是~/.claude/skills/项目级是你的项目/.claude/skills/。Windows 上则是%USERPROFILE%\.claude\skills\和项目目录下的.claude\skills\。这两个位置我一开始傻傻分不清。有段时间我把一套个人偏好很强的 skill 放进了项目级目录结果换一个仓库就整个失效我还以为是 Claude Code 出 bug 了。后来才反应过来项目级目录的加载范围由当前工作目录决定脱离项目就自然找不到。这一点在 VS Code 里跑 Claude Code 时尤其容易踩——你从不同文件夹打开会话加载的 skill 集合可能完全不一样。第三个容易踩坑的地方是克隆第三方仓库。很多 agent skill 套装、superpowers 这类社区项目通常是一个聚合仓库里面塞着几十个 skill。我用一条git clone把仓库拉到本地再从里面拷贝几个看起来不错的目录结果经常不小心把别人整个.claude/skills目录都带进来。最离谱的一次我项目里多了十几个我根本不知道从哪冒出来的 skill每个的 description 都在抢占“代码审查”“web 搜索”这类热门场景。另外如果你是通过 cc-switch 之类的工具把 Claude Code 接到底层其他模型比如 DeepSeek、Qwen、GLM 这些skill 的表现和官方模型会差很多。原因后面说但这算是第三方集成里很容易被忽略的一个点。2.3 为什么“装上就能用”是错觉加载机制与上下文成本很多人以为 skill 和插件一样用到才加载不用就闲置。真实机制恰恰是每次会话启动Claude Code 会把可见范围内的所有 skill 的 name 和 description 放进上下文作为一个候选列表。模型拿到任务后去匹配匹配到的 skill 才会把完整正文加载起来。这意味着三件事。第一skill 描述列表本身就是上下文成本。装 80 个 skill哪怕一个都不触发每次对话也有 80 份 description 在占 token。描述写得越长占得越狠。我清理之前光是 skill 描述这部分就能吃掉一大块上下文预算留给真正任务的空间自然就少了这也直接导致后来的“首 token 延迟变高”“复杂任务中途丢细节”等问题。第二description 写得太宽泛会诱发误匹配。比如某 skill 描述里写“帮助用户分析代码”那用户随口一句“看看这段代码有没有问题”就可能把它触发。模型按这个 skill 的流程跑一套完整分析而你其实只想快速确认一个字段写没写错。误触发不仅浪费 token还会让本来简洁的对话变得拖沓。第三很多第三方 skill 的正文里写了“调用 xxx 工具”但你根本没装对应的 MCP 服务或当前模型不支持那个工具格式。我装过好几个号称“自动联网检索”的 skill结果 SKILL.md 里要求调用的工具我在环境里压根没有执行到一半就开始瞎编。这类情况靠“装上再说”根本发现不了必须真跑一遍才知道有没有效。3. 三个月实测真正被高频使用的 Skill 只有三类3.1 检索与溯源类先说留下了哪些。第一类是检索与溯源代表是web-research。它的作用不是教模型“去搜索”而是规定搜索之后必须做什么先记录来源 URL、区分事实与推测、最后给引用标记。这比模型原生搜索行为靠谱太多尤其是遇到技术方案对比、版本兼容性问题时输出里带来源我就能快速判断哪些能信、哪些还要再验证。这类 skill 之所以经得住三个月是因为它的收益“可感知”——没有它搜索结果经常夹带没有依据的结论有它结论是否成立一眼就能看出来。而且它的 description 我写得很窄只在用户要求“调研、对比、查最新信息”的时候触发平时写代码根本不会跑出来捣乱。3.2 任务规划与工程结构类第二类是任务规划与工程结构。留存名单里有project-map、refactor-plan、test-case这几个。project-map的规则很简单接到开发任务后先读目录结构、列出受影响的文件清单再动手改代码。听起来平平无奇但正是这个流程让我少踩了很多“改到一半发现漏了关联模块”的坑。refactor-plan的工作方式更彻底重构前必须先产出计划包括现状、目标、改动范围、风险点和回滚方案得到我确认后才开始改。说白了它就是强制让模型先想清楚再动手。对于我这种习惯让 AI 快速产出、结果经常返工的人来说这个约束很有价值。test-case则用于生成测试用例它要求先按行为而非实现来列出用例场景再补边界条件和异常路径。这三个 skill 的共同点是它们都不追求“更多能力”而是给模型施加了“先做什么、后做什么”的流程约束让输出变得更稳定。3.3 上下文治理类第三类可能出乎很多人意料上下文治理。代表是context-save和self-review。context-save做的事情非常朴素——在长会话快要结束时把当前进度、已完成事项、遗留问题整理成一份交接文档方便下次claude --resume接着干。这个 skill 一开始是我最不看好的因为它的指令太简单感觉“不就是让它写个总结吗”。结果用下来发现没有它的时候长会话经常聊着聊着就散掉下次要么重新描述背景要么翻聊天记录有它之后我养成了收尾前自动存档的习惯跨会话工作流的体验提升了一个档次。self-review则是在输出前强制自检检查断言是否有依据、代码是否有明显风格问题、文档是否有遗漏章节。它不是万能的但对于生成代码和长文档这类场景能挡掉不少低级错误。它的 description 同样写得很窄只在任务比较重、生成内容超过一定规模时才触发。3.4 那些看着炫但最终被删的类型有留就有删。我最先清掉的是三类花架子。第一类万能助手型。SKILL.md 正文写得洋洋洒洒几千字从“你是资深架构师”一路写到“你还要检查安全漏洞、性能瓶颈、可维护性”看起来无所不能实际在任何具体场景都没法提供有效约束模型最后只是把抽象指令复述一遍。删。第二类写作包装型比如各种“去 AI 味”“文案润色”skill。我试过不止一个问题在于它们把模型的语言风格焊死了每句话都要口语化、都要有金句、都要短句结果在技术文档、周报、方案评审这些场景里全都水土不服。风格上的事儿留一两个足够多了只会互相打架。第三类依赖特定版本行为型。有些 skill 的正文里写死了“调用某某新功能”或者某个工具的特定参数格式Claude Code 一升级这套行为就失效了。我手里有好几个 skill 是社区早期版本作者早就不再维护留着除了占上下文没有别的用处。4. 我的删减标准与清理实操4.1 四个评估维度触发率、收益、维护成本、冲突风险清理不是凭感觉删我给自己定了一套评估标准遇到一个 skill 就问四个问题。第一个是触发率过去两周它有没有被真实触发过注意是“触发”不是“装上”。那些从装进来到删掉一次都没被拉起来的 skill直接进入待删名单。第二个是收益可感知没有它输出质量会不会明显下降如果答案是“好像也没差”那它就是在空耗上下文。第三个是维护成本它还兼容当前版本的 Claude Code 吗底层模型换过之后还好用吗维护成本高的我会优先删或者合并。第四个是冲突风险它有没有和其他 skill 抢同一个场景比如两个都管 web 搜索、两个都管代码审查那就必须二选一。| 评估维度 | 判断标准 | 我当时怎么处理 | | 触发率 | 近两周是否真实触发 | 没触发过的先禁用观察一周 | | 收益可感知 | 没有它输出是否明显变差 | 感受不到差异的直接删 | | 维护成本 | 是否兼容当前版本和模型 | 不兼容且没人修的删 | | 冲突风险 | 是否与其他 skill 抢占同一场景 | 保留主用场景删除重复 |这套标准看起来很简单但真到执行时最难的是对第二项诚实。很多 skill 我明明只触发过一两次却总觉得“以后会用上”舍不得删。后来我给自己的心理暗示是“以后要用的时候再装也行反正装回来也就一分钟。”这句话治好了我 90% 的收藏癖。4.2 用日志和测试任务判断“真用还是假用”判断一次 skill 有没有被真实触发不能凭体感要看日志。Claude Code 会把会话记录存在本地一般位于用户目录下的.claude/projects/文件夹里按项目分目录存成 JSONL 文件。你可以用下面的命令快速扫一遍出现过哪些 skill 的加载记录grep -o skill_id:[^]* ~/.claude/projects/**/*.jsonl | sort | uniq -c | sort -rn如果实际字段名不带 skill_id也可以直接搜SKILL.md的目录名或者 skill 名称。思路是一样的看“加载记录”而不是“目录里是否有这个文件夹”。还有一种更简单的探测方法同一个任务分别在有 skill 和没 skill 的会话里跑一遍对比输出差异。比如把那个 skill 临时挪出目录跑一个典型任务记下输出再挪回来跑同样的任务看行为有没有变化。这个方法尤其适合判断“写作润色”“代码风格”这类效果比较主观的 skill。如果你发现挪不挪没啥区别那它就是纯摆设。当时我清理前把八十多个 skill 分成三类明确留下、明确删除、需要观察。需要观察的先挪到备份目录mkdir -p /tmp/skills-backup mv ~/.claude/skills/needs-check /tmp/skills-backup/跑了一周之后只有两个“需要观察”的 skill 因为真实用到被恢复了其余全部确认删除。这种“软删除”比直接rm -rf稳得多也避免了一时手快删错。4.3 从 80 到 11 的处理记录我的八十多个 skill 大致来自六个方向。项目地图、重构计划、测试用例这些工程流程类的有 18 个最后只留 3 个检索辅助类有 12 个留 2 个上下文治理类 8 个留 2 个代码生成与重构类 16 个留 2 个写作与表达类 14 个只留 1 个数据分析处理类 9 个留 1 个剩下的是各种体验、杂项目录和过期副本约 9 个全删。| 类别 | 清理前数量 | 保留数量 | 处理方式 | | 工程流程类 | 18 | 3 | 按使用率合并同类项 | | 检索辅助类 | 12 | 2 | 删掉重复的搜索规则 | | 代码生成与重构类 | 16 | 2 | 仅保留流程约束型 | | 写作与表达类 | 14 | 1 | 只留兼容性最好的 | | 上下文治理类 | 8 | 2 | 全部保留并长期维护 | | 数据分析处理类 | 9 | 1 | 删掉依赖特定库的 | | 杂项目录与过期副本 | 9 | 0 | 直接清理 |别纠结数字准不准重点是分布趋势凡是“依赖某个具体工具、某个特定提示风格、某种讲法”的 skill最后基本都被删了留下来的是那些“定义流程和边界”的 skill。这也印证了我对 Skill 本质的判断——它是行为说明书不是功能扩展包。4.4 删除后的配置优化删完之后不能扭头就走还要把配置顺手理顺。我的做法是重新划分用户级和项目级通用性强的、跨项目都要用的 skill放到~/.claude/skills/只服务于当前仓库开发流程的放到项目目录的.claude/skills/。这样每个会话加载的 skill 数量都是可控的不再一上来就背着一百个描述。另外我把一部分原本写在 skill 里的内容改成了CLAUDE.md里的项目约定。比如提交信息格式、代码风格偏好、文档目录结构这些更像“项目规则”而不是“临时技能”放在项目说明文件里反而更贴切。Skill 则留给那些需要显式触发或需要按步骤执行的重型流程。如果你想进一步减少常驻上下文开销还可以把某些长期不用的 skill 从用户级挪到单独的备份目录或者通过配置仅在本项目启用。总的思路就一句话让上下文里只留那些大概率用得上的行为约束。删掉那批僵尸 skill 之后我明显感觉复杂任务的执行更连贯了中途丢上下文的情况也少了很多。5. Skill 管理避坑实录五个高频问题与排查方法5.1 启动变慢、首 token 延迟变高现象装了大量 skill 之后新会话启动明显变慢首条回复要等很久。原因我在前面说过——所有 skill 的 name 和 description 都常驻在上下文里数量越多初始提示越长模型要处理的内容也就越多。排查先把用户级和项目级 skill 数量全部统计出来再用 4.2 节里说的日志方法看看实际加载了多少条描述。如果描述列表占了很大篇幅基本就是它导致的。解决删除低价值 skill、压缩 description 的写法、把低频 skill 挪出当前生效目录。我清理完八十多个 skill 之后启动速度体感恢复了七八成。5.2 Skill 被“误触发”抢走主模型行为现象你只想让模型快速改一行配置结果它莫名其妙按某个 skill 的完整流程跑了一遍输出一大堆不相干的分析。这通常是 description 写得太宽泛导致的。我改过的一个典型例子是把code-review的 description 从“分析代码并给出改进意见”改成了“仅当用户明确要求执行 PR 审查或代码评审且涉及多个文件改动时使用”。改完才发现模糊描述和精确描述给模型带来的行为差异有多大。修复方式就是回到每个 skill 的 SKILL.md把 description 的触发边界改窄宁可不触发也不能乱触发。5.3 同名工具与描述冲突现象两个 skill 的正文里都写了“用户要求搜索信息时按以下步骤执行”但具体步骤不一样。模型无法同时遵守两套规则行为就会出现摇摆一会儿用 A 的格式一会儿用 B 的格式。排查把生效目录里的 skill 描述列表列出来找出关键词重复的。解决保留你更认可的那一个给另一个加限定词比如“仅处理 X 类场景不负责通用检索”。如果只是为了某个开源项目里的自定义流程而装那完全可以把范围缩到项目级眼不见心不烦。5.4 项目级与用户级位置放错Skill 静默失效现象某个 skill 在某次会话里表现正常换个目录、换台电脑就完全不被加载而且没有任何报错。这是最隐蔽的问题因为 Claude Code 不会告诉你“这个 skill 因为位置不对没加载”。排查确认 skill 到底放在~/.claude/skills/还是项目的.claude/skills/回忆一下最近是不是打开了不同文件夹的 VS Code 窗口。很多人以为自己在用同一个项目其实打开的是父目录加载范围完全不同。解决把通用 skill 统一放用户级项目专属流程单独放项目级。位置一旦定下来不要再随手挪动。5.5 第三方 Skill 与版本兼容性问题现象社区下载的 skill某天开始完全失效提示里新增了它不认识的字段或者它写死的工具调用方式已经不存在。原因Claude Code 更新后工具调用、MCP 协议、上下文注入方式都可能变化第三方 skill 若没有跟上就会变成废纸。排查每个季度扫一遍第三方来源的 skill看看仓库有没有更新没有更新就按“维护成本高”处理优先删除或自己接管维护。我自己后来就不再从外部批量拷贝整套 skill 了重要的流程都自己用几十分钟手写一遍效果反而稳定得多。6. 如果重来一次我会这样用 Skill6.1 先跑通流程再把它固化成 Skill我最大的教训是顺序搞反了先装 skill后想用途。重来的话我会先用普通对话反复做同一件重复性的事直到步骤稳定下来、自己也确认这套流程真能提升效率再花时间把它写成 SKILL.md。具体做法是在连续几次会话里重复同一个任务记录下模型“表现好”的那几次具体步骤把这些步骤抽出来去重、排序、补上边界条件再写成行为指令最后用一个典型任务测试看看加了 skill 的输出是不是真的比不加稳定。这样产出的 skill 大概率是留得住的因为它本来就从你的真实工作流里长出来。6.2 写 description 的三个标准description 是 skill 的“入口”写得好不好直接决定了技能会被命中还是误触发。我的标准有三条第一触发场景要具体不写大词直接写“当用户要求……时使用”第二边界要清楚写明“不负责”的场景比如某个 skill 只做方案设计不做代码实现第三字数要克制description 本身就是常驻上下文的一部分原则上不要超过两三行能说清场景就好。写好的一个示范是“仅当用户要求制定重构方案时使用。负责读目录结构、列出改动文件、评估风险并输出计划不负责直接修改代码。”这句话谁看了都知道什么时候该触发什么时候别来凑热闹。6.3 留下清单的共同特征把 11 个留下来的 skill 摆在一起看特征非常统一。第一它们都定义了“流程”而不是定义了“风格”——风格相关的一律删了流程相关的都留下了。第二它们的触发场景都能用一句话说清从来没有描述模糊导致误触发的情况。第三它们的正文都很短一般几十行以内不搞长篇大论。第四它们不依赖任何第三方服务或特定模型换一个环境、换一种接入方式基本还能跑。如果你也在审视自己的 skill 列表不妨拿这四条当筛子。中了三条以上的 skill 留下中不了三条的直接挪到备份目录先跑两周看看。我个人体会是好的 skill 数量根本不需要多十个左右足够覆盖日常所有高频重复流程。真正让 Claude Code 变强的不是收藏夹里躺着多少 skill而是你手里有哪几个经过了真实工作的反复捶打。删掉那 80% 之后我的体感反而更轻了。启动速度快了误触发少了真正用到的时候剩下的十一个 skill 每一个我都能说出它会在哪个环节介入、把模型行为改成什么样。这比收藏一百个所谓神级 skill 踏实得多。如果你现在也在为 skill 的数量沾沾自喜我唯一想说的是暂停一下先算算它被真实触发过几次。数字不会骗人。还有一点我觉得值得提醒清理 skill 不是一次性的动作它应该跟着你的工作流一起演进。每过一两个月我都会花十分钟把最近没用的 skill 再过一遍该删就删该合并就合并。这个习惯能帮你避免今天这种“一次性删掉百分之八十”的极端情况——如果早点这样做前面三个月大概能少走一半弯路。