1. 从能跑就行到越用越顺手我为什么开始折腾Skill刚上手Claude Code那阵子我的用法特别朴素——打开终端敲一句需求等它吐代码复制粘贴收工。能用吗能用。但用了一个多月之后我越来越觉得不对劲每次开新会话它都像失忆一样项目背景要重讲一遍代码规范要重新强调一遍连我们团队不用分号结尾这种小事都得反复叮嘱。这就像你雇了个技术很强的新人但他每天早上来上班都会把昨天学的东西全忘光。后来我才意识到问题不在模型本身而在于我从来没给它建立过工作环境。Claude Code真正的威力不在于单次对话有多聪明而在于你能不能把重复性的上下文、规范、流程固化下来让它每次启动就自动加载。这就是Skill存在的意义。我前后花了大概三周时间陆续给自己的工作流装上了40个左右的Skill覆盖代码审查、文档生成、测试编写、数据库操作、前端组件生成、日志分析等场景。装完之后回头看之前那些裸用的日子确实有点浪费——不是模型不行是我没把它的能力组织好。这篇内容适合两类人看一类是刚接触Claude Code、还在一问一答阶段的新手另一类是已经用了一段时间、但总觉得效率没质变的老用户。我会从Skill到底是什么、怎么组织、怎么和CLAUDE.md以及MCP配合、装多了之后怎么管理这几个角度把我踩过的坑和总结出来的方法完整讲一遍。提示Skill不是插件市场里下载即用的东西它的本质是一份结构化的指令文件告诉Claude在特定场景下应该怎么做。理解这一点后面的所有操作都会顺很多。2. Skill、CLAUDE.md、MCP到底各管什么先把概念理清楚2.1 Skill不是插件是场景化的行为说明书很多人第一次听到Skill会下意识把它理解成VS Code插件那种东西——装上就多一个功能按钮。实际上完全不是。Skill就是一份Markdown格式的指令文档里面写清楚了当遇到某类任务时你应该按照什么步骤、什么规范、什么输出格式来处理。举个例子我写了一个叫code-review的Skill内容大概是这样当用户要求审查代码时先检查命名规范再检查是否有未处理的异常再检查是否有硬编码的配置项最后按照问题等级文件位置修改建议的格式输出。这份文档放在特定目录下Claude在需要的时候会自动读取并遵循。所以Skill的核心价值是把隐性的经验变成显性的指令。你脑子里那些代码应该这样写的直觉写成Skill之后Claude每次都会照着执行不用你反复说。2.2 CLAUDE.md是项目宪法Skill是专项法规这两个东西经常被搞混。我的理解是这样的CLAUDE.md是项目级别的全局配置每次会话启动时都会加载里面放的是最基础、最通用的信息——项目是做什么的、技术栈是什么、目录结构长什么样、有哪些全局约定。它相当于公司的员工手册。Skill则是针对特定任务的详细指引只在相关场景下才被调用。比如你有一个专门处理数据库迁移的Skill那只有在涉及数据库操作时它才会起作用。它相当于某个部门的操作手册。两者是互补关系。CLAUDE.md告诉Claude我们是谁Skill告诉Claude这件事具体怎么做。我见过有人把所有东西都塞进CLAUDE.md结果文件长到几千行每次会话都加载一遍既浪费上下文窗口又让Claude抓不住重点。正确的做法是CLAUDE.md保持精简控制在100行以内只放最核心的信息具体的操作细节全部拆到各个Skill里去。2.3 MCP解决的是连接外部世界的问题MCP是另一条线。如果说Skill是教Claude怎么做事那MCP就是给Claude打开通往外部工具的门。通过MCP协议Claude可以连接到数据库、浏览器、设计工具、API服务等外部系统直接读取数据或执行操作。我目前常用的几个MCP包括Playwright MCP用来做端到端测试和页面抓取Figma MCP用来读取设计稿的组件信息还有一个自建的数据库MCP用来直接查询开发环境的表结构。这些MCP让Claude不再只是一个写代码的而是能真正参与到完整工作流里的角色。三者关系可以用一个简单的表格说清楚组件作用范围加载时机典型内容CLAUDE.md整个项目每次会话启动项目背景、技术栈、全局规范Skill特定任务场景按需触发操作步骤、输出格式、检查清单MCP外部系统连接配置后常驻数据库、浏览器、设计工具等接口理清这三者的分工之后你才能知道什么东西该放在哪里不会出现所有东西堆在一起、互相打架的情况。3. 40个Skill是怎么分类的我的实际组织方案3.1 按开发阶段划分的四层结构装了40个Skill之后最大的问题不是不够用而是找不到。所以我后来做了一次彻底的重组按照开发流程分成四层第一层输入与理解类。这类Skill负责帮Claude理解需求和技术背景。比如requirement-parser会把产品经理写的模糊需求拆解成具体的功能点api-doc-reader会读取接口文档并提取关键参数。这一层大概有6个Skill。第二层编码与生成类。这是数量最多的一层覆盖各种代码生成场景。包括react-component按团队规范生成React组件、sql-query-builder根据表结构生成查询语句、test-writer生成单元测试、migration-generator生成数据库迁移脚本等。这一层有15个左右。第三层审查与校验类。代码写完之后的检查环节。包括code-review、security-check、performance-audit、type-checker等。这一层有8个。第四层输出与交付类。负责把结果整理成可交付的形式。包括changelog-writer、pr-description、commit-message、release-note等。这一层有7个左右。剩下的几个是跨阶段的通用工具类Skill比如debug-helper、log-analyzer、error-explainer不归属于特定阶段。3.2 命名规范让Skill自己说明自己我踩过的一个坑是早期命名太随意什么helper1、my-skill、test2过了一周自己都不知道哪个是哪个。后来我定了一套命名规则全部用小写字母加连字符动词开头说明做什么比如generate-、review-、parse-、convert-如果针对特定技术栈加上前缀比如react-、sql-、python-这样命名之后我在终端里敲ls看一眼目录就能快速定位到需要的Skill。而且Claude在匹配任务时也更容易找到对应的Skill因为名字本身就包含了语义信息。3.3 每个Skill的文档结构模板为了保证40个Skill的质量一致我定了一个统一的文档结构。每个Skill文件都包含以下几个部分# Skill名称 ## 触发条件 什么情况下应该使用这个Skill ## 前置要求 使用前需要确认哪些信息已经具备 ## 执行步骤 1. 第一步做什么 2. 第二步做什么 ... ## 输出格式 最终结果应该长什么样 ## 注意事项 容易出错的地方和边界情况这个模板看起来简单但实际写的时候你会发现触发条件和注意事项这两部分最考验功力。触发条件写得太宽泛Skill会在不该触发的时候乱触发写得太窄又经常匹配不到。注意事项则是你踩过的坑的沉淀这部分越详细Skill的实用价值越高。注意不要一开始就追求写40个完美的Skill。我的做法是先写5个最常用的用两周时间打磨到稳定然后再批量扩展。质量比数量重要得多。4. 几个真正改变效率的Skill实例拆解4.1 code-review把代码审查标准固化下来这个Skill是我用得最频繁的一个。在没有它之前我让Claude审查代码每次得到的反馈风格都不一样——有时候关注命名有时候关注性能有时候只挑语法错误。有了这个Skill之后审查维度固定下来了。它的核心逻辑是分四轮检查第一轮看命名和注释第二轮看错误处理和边界条件第三轮看性能和资源使用第四轮看是否符合项目的架构约定。每一轮都有具体的检查清单最后按照统一的格式输出。实际用下来最大的感受是审查结果变得可预期了。以前Claude可能会漏掉某些维度现在每次都会完整覆盖。而且因为输出格式固定我可以直接把结果贴到PR评论里不用再手动整理。4.2 test-writer从懒得写测试到顺手就写了说实话我以前写测试的动力很低因为写测试的时间有时候比写功能代码还长。装了这个Skill之后情况变了——我只需要告诉它给这个函数写测试它就会按照项目使用的测试框架Jest、Pytest、Vitest等生成完整的测试用例包括正常路径、边界条件、异常情况。这个Skill里我特别加了一条规则每个测试用例必须有明确的断言不允许出现只调用不断言的假测试。这是我之前踩过的坑——有些自动生成的测试看起来跑通了但实际上什么都没验证。另外我还加了一个约定测试文件的命名和目录结构必须和源文件保持对应关系。比如src/utils/format.ts对应的测试文件必须是src/utils/format.test.ts。这样找起来方便CI配置也简单。4.3 debug-helper把排查思路结构化这个Skill解决的是遇到报错不知道从哪下手的问题。它的工作方式是先让Claude读取错误信息和相关代码然后按照定位错误类型→缩小范围→提出假设→验证假设→给出修复方案的流程走一遍。我印象最深的一次是一个异步竞态问题报错信息很模糊只说是undefined is not a function。用这个Skill跑了一遍之后Claude按照流程逐步排查最后定位到是一个Promise在resolve之前就被调用了.then()。整个过程大概花了三分钟如果我自己查可能要半小时。这个Skill的关键在于把排查过程显性化。它不会直接给你答案而是带着你走一遍逻辑链路这样即使它没找到根因你也能顺着它的思路继续查。4.4 commit-message规范提交信息的最后一块拼图这个Skill看起来最简单但实际收益很高。它的逻辑是读取当前暂存区的diff按照Conventional Commits规范生成提交信息格式是type(scope): description。我给它加了几条项目特定的规则type只允许用feat、fix、refactor、docs、test、chore这六种scope必须是项目里已有的模块名description用中文写不超过50个字。这样一来团队里所有人的提交信息风格就统一了生成changelog的时候也方便按type分类。5. Skill和MCP配合使用的实战场景5.1 Playwright MCP 页面测试Skill端到端测试自动化单独用Playwright MCPClaude可以打开浏览器、点击元素、截图。但如果没有Skill指引它每次的操作方式都不一样有时候用CSS选择器有时候用XPath有时候用文本匹配。后来我写了一个e2e-testSkill规定了选择器优先级优先用>