1. 从能跑就行到跑得漂亮我为什么开始折腾Skill刚上手Claude Code那阵子我的用法特别朴素——打开终端敲一句需求等它吐代码复制粘贴收工。能用吗能用。但用久了总觉得哪里不对劲每次都要重新交代项目背景每次都要提醒它这个项目用pnpm不用npm每次生成的代码风格都像换了个人写的。直到我把40个Skill陆续装进去、跑通、调优之后才真正意识到——之前那些用法本质上是在把一个配置齐全的专业工具当计算器使。这篇文章不讲虚的就聊三件事Skill到底是什么、它和MCP/Agent/CLAUDE.md这些概念怎么区分、以及我踩过的那些坑。如果你正在用Claude Code或者刚听说Skill这个词但还没搞明白它跟插件有什么区别那这篇应该能帮你少走至少两周弯路。先说结论Skill不是插件不是MCP也不是Agent。它是给Claude Code注入领域知识操作流程的一种轻量机制。你可以把它理解成给一个新员工发的《岗位操作手册》——手册本身不干活但有了它员工干活的准确率和一致性会完全不同。我最初装Skill的动机很功利项目里有一堆重复性的规范检查每次都要手动提醒。后来发现与其每次在prompt里写一大段请遵循以下规范……不如把这些规范固化成一个Skill让它在该触发的时候自动触发。这个思路转变是我用Claude Code的第一个分水岭。2. Skill、MCP、Agent、CLAUDE.md四个概念的真实边界2.1 用一个类比把四者串起来很多人搞不清这几个词包括我一开始也是。后来我用一个开餐厅的类比把它们串起来了CLAUDE.md是餐厅的《员工守则》贴在墙上所有员工每天上班都要看一遍。它是全局的、静态的、始终生效的。Skill是《某道菜的标准做法》只在做那道菜的时候才翻出来看。它是按需触发的、有明确适用场景的。MCP是厨房里的外部设备接口——比如那台能连供应商系统的订货终端。它解决的是Claude Code怎么跟外部世界对话的问题。Agent是能自己决定今天先备菜还是先熬汤的厨师长。它解决的是多步骤任务怎么自主编排的问题。这四个东西不是替代关系是协作关系。CLAUDE.md定基调Skill补细节MCP通外部Agent管调度。2.2 为什么Skill比CLAUDE.md更适合领域知识CLAUDE.md的问题在于它是全局常驻的。你写进去的每一行都会占用上下文而且不管当前任务相不相关它都在那儿。项目小的时候无所谓项目一大CLAUDE.md动辄几百行光读它就吃掉不少token。Skill的聪明之处在于按需加载。它有一个描述descriptionClaude Code会根据当前任务判断要不要把这个Skill的完整内容读进来。不相关的时候它就是一个名字几乎不占资源相关的时候它才展开成完整的操作指南。我实测下来把原来CLAUDE.md里那些特定场景才用得上的规范挪到Skill里之后日常对话的响应速度明显更稳而且Claude Code在相关任务上的表现反而更好了——因为它读到的不是一堆混杂的全局规则而是针对当前任务的精准指引。2.3 MCP解决的是够得着Skill解决的是做得对这两个最容易混。MCPModel Context Protocol本质是一个协议让Claude Code能连接到外部工具或数据源——比如连上Figma读设计稿、连上Playwright操作浏览器、连上数据库查数据。它解决的是能力边界问题原来够不着的东西现在够得着了。Skill解决的是质量一致性问题够得着之后怎么做得符合你的要求。举个例子你通过MCP连上了Figma能读到设计稿了但读出来之后怎么转成代码、用什么组件库、间距怎么换算这些是Skill该管的事。我见过有人把这两者对立起来说有了MCP还要Skill干嘛。这就像问有了手还要菜谱干嘛——手让你能切菜菜谱让你切得对。2.4 Agent是编排层不是替代层Agent这个词被用得太泛了。在Claude Code的语境里Agent更多指的是能自主规划多步骤任务的能力。比如你说帮我把这个功能从设计稿做到上线Agent会自己拆解成读设计稿→生成组件→写测试→跑测试→修bug→提交。Skill在这个链条里扮演的是每个环节的操作规范。Agent决定做什么、按什么顺序做Skill决定每一步具体怎么做。两者是正交的不是竞争关系。3. 40个Skill的选型逻辑我到底装了些什么3.1 不是越多越好而是触发边界越清晰越好先说一个反直觉的结论装40个Skill不代表比装10个强。Skill的价值不在于数量而在于每个Skill的触发边界是否清晰。如果一个Skill的描述写得含糊它要么该触发的时候不触发要么不该触发的时候乱触发反而添乱。我装到第40个的时候做了一次大清理砍掉了大概8个描述模糊、功能重叠的。剩下的这40个基本覆盖了我日常工作的几个大类。下面这张表是我实际在用的分类类别数量典型场景触发方式代码规范类9提交前检查、命名约定、目录结构文件类型操作类型框架专属类7React/Vue/Node特定写法依赖检测关键词文档写作类6README、API文档、变更日志文件路径任务描述调试排查类5报错分析、日志解读、性能定位错误信息上下文工具集成类6Git操作、包管理、CI配置命令关键词领域知识类4特定业务逻辑、算法实现业务关键词元Skill类3创建Skill、优化Skill、审查Skill显式调用3.2 代码规范类把口头禅变成肌肉记忆这类Skill是我最早装的也是收益最直接的。以前我总在prompt里写记得用const不用var记得加错误处理记得写JSDoc写多了自己都烦。现在这些全部固化进SkillClaude Code在写JS/TS的时候会自动带上。关键心得规范类Skill的描述要写得窄。比如JavaScript代码规范这种描述就太宽了会导致它在任何JS相关任务上都触发。我后来改成当创建或修改.js/.ts文件且涉及函数定义时触发精准多了。3.3 框架专属类让Claude Code入乡随俗每个框架都有自己的方言。React有hooks规则Vue有组合式API的写法Node有流处理的惯例。这些细节如果不在Skill里写清楚Claude Code会用它自己的通用最佳实践结果就是代码能跑但不符合项目习惯。我装了一个React Skill里面写清楚了这个项目用的是函数组件TypeScript自定义hooks抽离逻辑不用class组件不用默认导出。装完之后生成的组件风格立刻统一了。3.4 调试排查类把经验变成流程这类Skill是我觉得最被低估的。调试这件事老手和新手的差距不在知识在排查顺序。老手知道先看什么、后看什么、什么情况下跳过什么。这些隐性知识完全可以写成Skill。我写了一个前端报错排查Skill里面固化了我的排查链路先看错误类型→再看堆栈最内层→再看是不是异步问题→再看是不是状态问题→最后才怀疑依赖版本。装了这个之后Claude Code帮我分析报错的时候思路明显更有条理不会一上来就让我检查依赖版本。3.5 元Skill类用Skill管理Skill这是我觉得最妙的一类。我装了三个元Skill一个负责根据我的描述生成新Skill的骨架一个负责审查现有Skill的描述是否够精准一个负责在Skill数量过多时建议合并或删除。用Skill来管理Skill听起来有点绕但实际用起来非常顺。尤其是审查Skill描述这个它会指出哪些描述太宽泛、哪些触发条件有歧义帮我省了大量手动调优的时间。4. 一个Skill从零到能用的完整过程4.1 先想清楚触发时机再动手写内容我见过太多人包括早期的我一上来就写Skill的内容写完发现要么不触发要么乱触发。正确的顺序是先定义触发条件再写执行内容。触发条件要回答三个问题什么时候该用什么时候不该用怎么判断当前任务属于该用的情况这三个问题的答案就是Skill描述的核心。4.2 Skill文件的基本结构一个Skill通常包含几个部分名称、描述触发条件、适用场景、具体指令、示例、注意事项。下面是我一个实际在用的Skill的简化结构--- name: api-error-handling description: 当编写或修改涉及HTTP请求的代码时触发特别是fetch/axios调用、错误捕获、重试逻辑 --- ## 适用场景 - 新增API调用函数 - 修改现有请求的错误处理 - 添加重试或降级逻辑 ## 具体指令 1. 所有请求必须包裹try-catch或.catch 2. 错误对象必须包含status、message、原始error 3. 网络错误和业务错误分开处理 4. 重试最多3次指数退避 ## 示例 此处放一个符合规范的代码示例 ## 注意事项 - 不要吞掉错误至少console.error - 用户可见的错误信息不要暴露技术细节4.3 描述写得好不好直接决定Skill的命中率这是最关键的细节。描述要同时包含正向触发词和负向排除词。比如好的描述当创建新的React函数组件时触发不适用于修改现有组件或编写测试差的描述React相关任务前者告诉Claude Code什么时候用、什么时候不用后者等于没说全靠它猜。我实测下来描述里带上具体的文件扩展名、操作动词创建/修改/删除、技术栈关键词命中率能提升一大截。4.4 装完之后必须做的三件事第一故意触发一次。找一个明显该用这个Skill的任务看它有没有被加载。第二故意不触发一次。找一个不该用的任务看它有没有乱入。第三看输出质量。前两步过了再看它生成的代码/文档是否符合预期。这三步我称之为Skill的三次体检缺一不可。很多人装完就用结果Skill要么没生效要么在不该生效的地方生效自己还不知道。5. 踩过的坑那些让我想砸键盘的瞬间5.1 坑一描述太宽Skill变成万能胶我最早写的一个Skill叫代码质量检查描述就一句话当需要检查代码质量时触发。结果呢几乎每个任务它都想插一脚因为它觉得写代码就等于需要检查质量。后来我把描述改成当用户明确要求代码审查或提交前执行lint时触发世界立刻清净了。教训描述里的触发条件必须是可判定的不能是感觉上的。5.2 坑二Skill之间互相打架有两个Skill一个说函数要短小精悍超过20行就拆分另一个说相关逻辑要内聚不要为了短而拆。结果Claude Code在两个Skill同时触发的时候行为变得很拧巴一会儿拆一会儿合。教训装Skill之前先做一次冲突审查把互相矛盾的规则合并或明确优先级。5.3 坑三把知识和流程混在一个Skill里我有个Skill既写了这个项目的数据库表结构又写了查询时要注意什么。结果这个Skill变得又大又杂触发的时候加载一堆不相关的内容。教训知识类内容和流程类内容要分开。知识类可以做成参考型Skill流程类做成操作型Skill。5.4 坑四忘了Skill也会过期项目重构之后有些Skill里写的规范已经过时了但我忘了更新。结果Claude Code还在按老规范生成代码我还纳闷怎么风格不对。后来我养成了一个习惯每次项目结构大改就过一遍所有Skill该更新的更新该删的删。教训Skill是活的需要定期维护。建议每个月做一次Skill体检。5.5 坑五以为装了Skill就万事大吉这是最大的坑。Skill只是操作手册它不会自动帮你干活。你还是得给出清晰的任务描述还是得审查输出。Skill提升的是下限和一致性不是上限。指望装了Skill就躺平那是不现实的。6. 让Skill真正发挥作用的几个关键习惯6.1 任务描述要喂给Skill足够的上下文Skill触发之后它需要知道当前任务的具体情况才能给出精准指引。所以你在描述任务的时候要带上足够的上下文改的是哪个文件、什么框架、什么业务场景。上下文越足Skill发挥得越好。6.2 定期回顾哪些Skill从没触发过如果一个Skill装了三个月一次都没触发要么是描述有问题要么是这个场景你根本用不上。前者改描述后者直接删。别舍不得Skill列表越干净整体表现越稳。6.3 把重复三次以上的提醒都变成Skill这是我判断要不要新建Skill的标准如果同一个提醒我在prompt里写了三次以上那就说明它值得固化。这个标准简单粗暴但非常有效帮我筛掉了大量看起来有用但实际用不上的Skill。6.4 用版本管理管SkillSkill文件也是代码应该纳入版本管理。我所有的Skill都放在项目的.claude/skills/目录下跟代码一起提交。这样团队里其他人也能用同一套Skill风格自然就统一了。6.5 别怕删Skill的价值在精不在多我现在维持在40个左右但跟一开始的40个已经完全不是同一批了。删掉的比留下的多。每次删Skill都是一次对我到底需要什么的重新思考这个过程本身就有价值。7. 关于Skill和Agent配合的一点实战体会最后聊一个我最近才想明白的事。Skill和Agent不是二选一而是Agent负责串Skill负责精。举个例子我让Claude Code做一个从需求到提交的完整任务。Agent会把它拆成理解需求→找相关文件→改代码→写测试→跑测试→提交。这个链条是Agent在编排。但每一步具体怎么做——改代码时遵循什么规范、写测试时用什么风格、提交信息怎么写——这些是Skill在管。我实测下来AgentSkill的组合比单纯用Agent或者单纯堆Skill效果都要好。Agent解决了多步骤自主执行的问题Skill解决了每一步质量一致的问题。两者配合才是我理想中能干活且干得漂亮的状态。如果你现在还在纠结到底该用Agent还是Skill我的建议是先把你最常重复的那些规范写成Skill跑顺了再考虑用Agent把它们串起来。顺序反了容易两头不讨好。装Skill这件事说到底是一个把自己的经验显性化的过程。你写得越清楚Claude Code就越像你。这大概就是为什么我装到第40个的时候会有那种之前都白用了的感觉——不是工具变了是我终于开始认真对待怎么把我会的东西教给它这件事了。