三个月前我第一次打开 Claude Code 的 Skill 目录时心态和第一次逛创意市集差不多什么都新鲜什么都想搬回家。那段时间社区里铺天盖地都是我的 AI 助手装了哪些 Skill的分享有人晒书转 Skill有人晒去 AI 味还有人晒名字更唬人的全家福套件。我抱着宁可备而不用不可用而不备的心态一路装到四十多个。三个月后的今天我删掉了其中八成全局加项目只剩不到十个。这篇文章不是来劝退 Skill 的而是把这段经历完整复盘一遍Skill 到底解决了什么问题、为什么装多了反而难用、我保留的这些到底凭什么活着。先给没接触过的朋友说清楚两个概念。Claude Code 是 Anthropic 出的命令行编程智能体可以把它理解成一个能在终端里干活、能读项目代码、能执行命令、能自己迭代任务的 AI 程序员。Skill 是它加入的自定义能力包在一个目录里放上指令、模板、脚本和参考文档告诉 Claude遇到这类任务就这么办。这篇文章适合已经开始用 Claude Code、手头堆了不少 Skill 却总觉得不对劲的人也适合正准备大装特装的新手——我踩过的坑你大概率也会踩一遍能少走一段弯路。1. 三个月的真实心路从狂热到拆家1.1 第一波安装与其说是需要不如说是焦虑我第一次装 Skill 的原因说出来有点丢人不是因为卡在某个具体任务上而是因为社区氛围太热闹了。到处都是装上这个效率直接起飞的标题配合各种晒配置的帖子很难不动心。于是第一波我就装了十几个主力是两类一类是全栈工程师专家算法大师这种纯人设型正文看起来很专业实际上就是一段自我吹嘘加几条正确的废话另一类是知识灌输型比如把整本书转成 Skill 的 book to skill当初我天真地以为把《代码大全》喂进去Claude 写代码就能自动对齐大师思路。这个阶段的心态非常典型我不是遇到了问题才去装 Skill而是觉得这个东西好像能让我变得更厉害。装完一个 Skill 并不会立刻带来任何反馈但看着目录一点点变厚那种收藏就是学会的错觉特别上头。它和收藏一堆教程视频不看本质上没有区别。等到真正要写项目时我才发现多装的那几十个 Skill 没有一个在关键时刻帮上忙反而让我连自己装了什么都快记不清了。1.2 第二波安装拿新 Skill 去治旧 Skill 的病第一波安装没解决任何实际问题等我在真实项目里遇到代码评审意见太敷衍、文档写得像流水账这类痛点时我的第一反应依然是装 Skill。评审意见不好就装一个评审专家文档像流水账就再装一个文档大师。这种头痛医头、脚痛医脚的做法本质上是军备竞赛用更多的 Skill 去修补前一个 Skill 带来的问题而不是回头反思问题本身。装到二十多个的时候我注意到几个异常。首先同样一个问题回复速度明显变慢多等好几秒是常态其次偶尔会出现串味比如我明明在做后端接口重构它却突然用某一个写作 Skill 的口吻输出仿佛换了个人格。真正让我警惕的是一次代码审查它把某个数据清洗 Skill 的流程套在了我的业务代码上输出了一堆毫无意义的建议。那时候我才慢慢意识到Skill 不是免费的摆设——每多装一个模型做决策时就要多扫一份描述也就多一分被误导的可能。1.3 审计日把每个 Skill 都摊开来看一遍转折点发生在第二个月末。那天我推掉了所有任务专门花了一晚上给 Skill 做审计。方法老土但有效把全局和项目里的所有 Skill 列成一个清单逐个回忆上次真正触发它是什么时候它有没有实际改善过输出拿不准的就在真实任务里试一次。结果非常难看——四十多个 Skill 里能明确说出最近两周被有效使用过的不超过八个剩下的大多数我甚至想不起来它们具体是干什么的。审计之后我定了两条硬规则第一删掉所有最近一个月没有成功触发过的 Skill删完不影响任何现有工作流那就证明它本来就没价值第二对于功能重叠的只保留输出最稳定、维护成本最低的那个。那次大扫除一共删掉了三十多个像卸掉一身负重。删完再跑同样的任务回复速度和输出一致性肉眼可见地变好了这个对比让我下定决心以后绝不重蹈覆辙。2. Skill 没那么神秘本质是一套打包好的指令2.1 拆开一个 Skill 看看里面是什么理解 Skill 到底由什么组成是学会管理它的第一步。以我现在使用的版本为例一个 Skill 本质上就是一个文件夹核心文件是SKILL.md。这个文件开头是 YAML 元信息必备字段有两个name是名字description是给模型看的触发条件说明后面是 Markdown 正文用来写操作步骤、检查清单、输出模板甚至引用同目录下的脚本和参考文档。--- name: code-review description: 当准备提交代码评审PR/MR时按照团队规范检查变更范围、 结构合理性、风险点和测试覆盖输出结构化评审意见。 --- # 代码评审流程 1. 读取本次变更的 diff先判断改动范围是否超出任务描述 2. 按 [团队代码规范](./standards.md) 逐项检查 3. 重点关注错误处理、边界条件、依赖变更、测试覆盖 4. 输出格式问题列表 / 风险等级 / 修改建议 三段式放的位置也很有讲究。全局 Skill 放在用户目录下的~/.claude/skills里对所有项目生效项目级 Skill 放在当前项目的.claude/skills目录下只有当前项目能用。我后来的习惯是通用工作流放全局凡是跟某个项目的目录结构、命名规范、团队约定绑定的一律放项目级避免不同项目的规则互相串门。2.2 Skill 和 CLAUDE.md、MCP 到底怎么分工这个问题我见太多人搞混了值得单独说清楚。CLAUDE.md 是常驻上下文只要你在这个项目里每次对话都会读所以适合放项目背景、技术栈、目录结构这些任何时候都得知道的信息。Skill 是按需加载平时只有一行描述参与模型的决策模型判断这次任务需要用到时才会去读正文。MCP 又是另一回事它给模型提供的是外部工具调用能力比如查数据库、调 API、访问业务系统解决的是手够不到的问题。机制加载方式典型用途类比CLAUDE.md始终在上下文中项目背景、技术栈、约定工位墙上贴的操作规程Skill按需触发特定任务的流程与方法工具箱里的专用扳手MCP按需调用外部工具数据库、API、系统交互伸到仓库外的机械臂如果把三者混为一谈最常见的后果就是滥用 CLAUDE.md把所有东西都塞进常驻上下文把模型逼成一个什么都记着的话痨或者反过来把本该用 CLAUDE.md 固定的项目背景塞进 Skill导致它时灵时不灵。分清楚这三层你才能判断一个新东西该装在哪一层。2.3 判断好 Skill 的四条标准三个月的经验浓缩下来就是下面四条标准我现在看到任何 Skill 都用它们过一遍。第一description 是否足够具体。好的描述会精确说明什么场景、用什么方式、做什么事让模型知道什么时候该用坏描述是这是一个强大的 X能帮你提升 Y除了让模型在不相关的任务里也跃跃欲试没有任何信息量。第二正文是否可执行。有没有分步骤的操作、检查清单、输出样例还是一直在讲原理和道理执行细节才是 Skill 的价值讲道理是模型本来就擅长的事。第三是否自包含。依赖外部命令、需要联网调用 API、或者要求特定目录结构的 Skill维护成本极高环境一变就废。第四不用它行不行。如果一个 Skill 的存在感和默认能力差别不大那它就没有存在的必要——这条看起来简单实际上能砍掉大半装的时候激动、用的时候无感的 Skill。提示判断描述是否合格就看它能不能回答两个问题什么时候该用它用它后输出会有什么不同两个都答不上来的直接不要装。3. 删掉 80% 之后留下来的和滚蛋的3.1 活下来的那 20%凭什么活下来我现在全局大概有六个 Skill项目里有两三个。活下来的那些几乎都满足同一个公式每周高频使用、默认能力做不好、有不可替代的执行细节。举几个例子Skill在做什么我为什么留它代码评审提交 PR 前按团队规范检查检查清单来自团队踩过的真实事故是沉淀不是玩梗Commit message 生成统一提交信息的格式和分类每天用规则明确输出稳定项目脚手架生成新模块按团队目录规范初始化把命名、结构、样板代码全固化省去重复操作接口文档编写生成符合团队模板的 API 文档模板和示例的边际价值很大少说一堆重复话重构安全手册大规模重构时按步骤执行并留回滚预案有真实操作序列执行起来有章法有个细节很有意思项目里那个代码评审 Skill我已经两个月没动过它了但这恰恰说明它活着——它已经完全贴合团队的协作节奏变成了流程的一部分不是靠运气偶尔被触发。这样的 Skill才是工具被人用而不是人伺候工具。3.2 滚蛋的 80%都长什么样回头看我删掉的那三十多个基本可以归成几类。第一类是人设型什么全栈专家算法大师正文就是一段自我吹嘘加几句正确的废话对实际任务零增量。第二类是知识灌输型典型的做法是把一本书或者一摞网文转成 Skill 塞进去看起来信息量巨大实际上模型根本不会主动去翻这些参考输出质量和直接提问没有本质区别。第三类是创意写作型比如去 AI 味、打斗动作提示词这类单看可能有用但跟代码场景无关装在全局里只会让每次决策都多扫一遍无关描述。还有一类更隐蔽全家桶型。有些 Skill 一装就是几十个打包在一起标题响亮得不行内容却互相重叠装完你根本不知道它们各自的分工。外加那些垂直领域的比如备课、CAD 建模、外语学习类的 Skill对特定人群也许很有价值但对一个日常写代码的人来说它们就是纯粹的噪音。这类 Skill 的共同结局都是同一个躺在目录里吃灰直到做审计时被我发现然后一键删除。4. 为什么 Skill 越多反而越难用4.1 上下文开销不是玄学是实打实的成本最常见的误解是Skill 按需加载所以不占资源。事实是模型每次做任务决策时都要先扫一遍所有可用 Skill 的描述来决定要不要用、用哪一个。装三五个的时候没感觉装到三四十个光是扫这些描述就要消耗不少 token响应变慢、成本上升都是必然的。更要命的是干扰。description 写得越模糊模型在不相关任务里误触发的概率就越高。我遇到过最离谱的一次是在重构一个业务模块时Claude 突然按某个数据清洗 Skill 的流程输出。那种感觉就像你叫了个厨师来炒菜结果他自带了一本汽车维修手册。从那以后我建立了一个自觉每删掉一个描述模糊的 Skill模型在关键任务上的专注度就高一点——这不是心理作用是决策空间变小之后的必然结果。4.2 两个 Skill 抢一份工作输出就会人格分裂当两个 Skill 的职责边界重叠惨案就来了。我有一段时间同时装了两个都声称做代码评审的 Skill一个偏安全性审查一个偏代码风格。结果模型在一次评审里先是接了一套安全流程又中途切到风格审查的模板两份逻辑混合在一起别说参考价值连正常阅读都费劲。处理这类问题的原则很简单同一类型只留一个。判断留下哪个不是看哪一个名气大而是看哪一个的描述更贴合你的真实工作流、输出更稳定、依赖更少。而且两个 Skill 抢活这事儿靠调 description 基本治不好——最有效的方案就是减量把弱的那个删掉别想着万一用得上。注意同类 Skill 只留一个。别指望两个互相补充模型在二选一时最擅长的不是互补而是左右互搏。4.3 Skill 是有寿命的没人维护就会变成债务最后也是最现实的一点Skill 不是装好就能一劳永逸的。Claude Code 本身更新速度很快Skill 的语法、触发机制、支持的特性都可能随着版本变化而调整Skill 依赖的外部工具、API、甚至底层的模型能力也会悄悄变动。装四五十个的时候谁有精力跟着一个一个维护大部分 Skill 在某次版本更新之后就静默失效了但你并不知道直到某一天它被误触发输出一堆驴唇不对马嘴的话。还有人喜欢把 Claude Code 接到本地模型服务或者内网模型平台上体验这本身不算错但会让 Skill 的稳定性雪上加霜——不同模型对 Skill 描述的遵循程度差异很大同一个 Skill换个模型可能完全不被触发。Skill 越依赖特定环境就越脆弱。我做过一次统计那四十多个 Skill 里有相当一部分几个月没被成功触发过。它们就像代码里的死代码不影响主流程但始终占着空间、增加认知负担。定期做 Skill 审计把失效的、没人用的全部清掉本质上就是在治理技术债——越早处理越轻松越拖越不知道哪些还有用。5. 我现在管理 Skill 的完整流程5.1 安装之前先过三道过滤题现在不管谁的博客、视频推荐一个 Skill我都先问三个问题。第一这个任务我平均每周会不会遇到至少一次如果只是偶尔一顿的活儿用一次性提示词就够了不值得占一个常驻位。第二不用它和用它的差别明不明显如果差别只是措辞更漂亮一点不值得如果是帮我省掉二十分钟的机械化整理才值得。第三它依赖什么我能不能维护需要外部密钥、特定软件、或者维护者已经跑路不更新的直接扣分。这三道题过滤掉了绝大多数网红 Skill。我回忆过那些被我删掉的东西几乎没有哪个能同时通过三关。这条标准值得做成一份准入清单贴在触手可及的地方——它最大的作用是拦住你手贱的那一刻。5.2 新装的 Skill先进观察名单就算过了三道关我也不会让一个新 Skill 立刻转正。我会给它设一个两周观察期期间用真实任务专门试它。观察三个点第一它会不会在正确的场景自动触发第二它的输出是否明显优于不用它的基准线第三在多任务混合场景下它有没有产生干扰。两周之后如果它在真实工作中一次都没被用到或者用起来和不用一模一样就删不留情面。这里有个实用小技巧装新 Skill 之前先把当前 skills 目录整体备份一份。Skill 本质上是文件删除和恢复都极其廉价真正贵的是信息过载的决策环境——多个几十个文件的成本远低于多几十个干扰源。5.3 动手写自己的 Skill从痛点出发不要从模板出发如果某类重复任务总是让你头疼最好的 Skill 其实是自己写的。只有你知道团队规范是什么、踩过哪些坑、验收标准长什么样。我写得最顺手的那个部署检查 Skill就是从一次线上事故的复盘里提炼出来的。写的时候记住三件事。第一description 只写触发条件不要写效果吹嘘比如用于代码评审在提交 PR/MR 时检查变更范围、风险点和测试覆盖这就够了。第二正文宁可写检查清单、示例输出也不要写长篇大论的方法论模型不差道理差的是你沉淀下来的操作细节。第三材料尽量内联能直接用 Markdown 写进 SKILL.md 就不要外链能不用脚本就不用脚本依赖越少寿命越长。我自己把这些 Skill 都放在一个 git 仓库里维护每次改动都有记录团队里其他人想用直接拉取遇到问题还能提 issue。自己动手写过一两个 Skill 之后你再看社区里的各种 Skill 眼光会立刻变挑剔——因为你能分清哪些细节是真正有价值的沉淀哪些只是一层漂亮的包装。6. 给正在折腾 Skill 的人几句实在话6.1 新手最容易犯的错还没会用就开始装修如果你刚接触 Claude Code我最直白的建议是先别急着装 Skill把默认能力用透。很多问题靠把任务描述写清楚、把项目的 CLAUDE.md 配好、把任务拆得更细就能解决得很好。Skill 是锦上添花不是雪中送炭默认能力和基础工作流都没理顺的时候装再多 Skill 也只是给一个摇摇晃晃的架子上继续堆东西。另一个常见误区是把 Skill 的数量当成效率指标。我在最狂热的那阵子也晒过自己的 Skill 清单现在回头看那份清单与其说是能力的证明不如说是焦虑的展览。真正的工作成果是你把项目做成什么样而不是你的环境配置得多花哨。这个道理放在任何工具上都成立。6.2 我的优先级和一条土办法到目前为止我坚持的优先级是默认能力优先CLAUDE.md 次之Skill 最后。遇到一个新的重复性痛点先用一次性提示词解决同一个问题重复出现三次以上再考虑固化成 Skill。原因很简单每多一层自定义就多一层维护成本而 AI 工具本身的变化速度又很快自定义越深版本升级时翻车的概率越大。最后送你一条我用了三个月的土办法每次想装新 Skill 之前问自己一句——如果三个月后这个 Skill 会自动消失我还会不会愿意为了它多操作一次大多数时候答案是不会那我就知道它不值得装。少装、精装、勤清理是我删掉 80% 之后最深的体会。留几个真正扛事的工具比摆一桌子好看但没人用的工具能让你在写代码时专注得多。