Claude Code 这工具我从 2025 年年初就把它放进主力开发流程里了前后装过的插件、技能包、MCP 服务加起来少说二十多个。装的时候看哪个都像刚需真正写代码的时候翻来覆去用的其实就九款。今天不搞什么标题党式的“必装清单”只把这套折腾完以后真正留下来的东西挨个拆开讲清楚每款都尽量说透它解决什么问题、适合哪类人、怎么装、用的时候有哪些坑。如果你也想把 Claude Code 从“偶尔拿来问两句”的玩具升级成“每天都在用”的主力编码环境这篇应该能帮你少走不少弯路。1. 先搞清楚Claude Code 的插件到底分几种1.1 别被名词绕晕Skills、MCP、第三方工具Claude Code 的生态在 2025 年火起来之后大家习惯把所有东西都叫“插件”但这个叫法其实非常模糊。我见过不少朋友一上来就往 GitHub 上搜“claude code plugin”装了一堆提示词脚本结果发现没一个真正好用。原因很简单Claude Code 生态里能增加能力的工具本质上是三种完全不同的东西装错了位置、理解错了原理自然用不好。第一种是官方推出的 Skills也就是技能包。它的核心是一个SKILL.md文件里面描述了某个技能的使用场景、工作流程和输出规范。Claude 在对话中会读取这些技能然后按照技能里写的步骤去执行任务。你可以把 Skills 理解成给 AI 写的一本岗位手册不涉及任何外部程序调用纯靠“说明书”让 AI 的表现更专业。第二种是 MCP ServerModel Context Protocol 的缩写。这类工具不是提示词而是一个真正跑起来的服务进程把外部数据源、工具能力通过标准化接口暴露给 Claude Code。比如 GitHub 上的 Issue、数据库里的表结构、浏览器里的页面内容都可以通过 MCP 让 AI 直接读写。你可以把 MCP Server 理解成 AI 的手和眼睛——Skills 教它怎么想MCP 让它能动手。第三种才是大家传统认知里的“插件”也就是社区开发者写的小工具、命令行增强脚本、配置管理面板。它们通常不直接改 AI 的行为而是帮你管理 Claude Code 的环境比如切换不同模型来源、管理多个账号配置、生成项目模板等等。形态本质作用方式举例Skills提示词资产 流程规范被 AI 读取并执行代码审查技能、项目初始化技能MCP Server独立服务进程通过协议调用外部能力GitHub MCP、数据库 MCP、Playwright MCP第三方工具命令行/桌面小工具管理和增强 Claude Code 环境CC Switch、Ollama 接入脚本1.2 什么样的插件才值得装把三个概念分清之后你自然就有了判断标准一个工具能不能留下不是看它功能多不多而是看它是不是高频、稳定、可复用。我淘汰掉的那些插件绝大多数都输在这三件事上——要么装的场景太冷门一年用不上两次要么依赖一堆被墙掉的资源装完就跑不起来要么就是跟某个项目绑得太死换个项目就完全失效。我自己的筛选标准就三条。第一它必须能嵌入日常开发的核心链路比如“从 Issue 到 PR”这条主路径或者“写代码—查数据—验证页面”这个循环而不是某个边缘场景的花活。第二它必须值得让团队成员都能配置如果一个工具只有我自己会用那它再厉害也成不了项目资产。第三它得有明确的退出成本哪天不想要了删掉配置之后不会污染项目环境。下面这九款都是经过这三条标准筛选之后留下来的。2. 我真正留下这 9 款逐个说清楚好在哪2.1 CC Switch切换账号和模型来源的一把钥匙日常开发里最容易被低估的一个需求是“在不同模型来源之间切换”。大多数人不只有一个 Claude Code 使用场景白天在公司可能用的是企业工作区的订阅晚上个人项目走的是按量付费的 API Key偶尔还要接 AWS Bedrock 或者 Google Vertex AI 上部署的模型做对比。如果你靠手工改环境变量来切一天切三次早晚会切出问题。CC Switch 这类配置管理工具解决的就是这个痛点。它把多套模型来源的配置——包括认证信息、模型名、接口地址——用一套配置文件管理起来需要切换的时候执行一条命令或者点一下面板就行不用再去翻.bashrc、.zshrc里那堆 export。我实际用了几个月之后最大的感受是“再也不怕切错环境了”。以前手工切配置最担心的是公司项目里不小心用错账号给私人项目产生费用现在每个项目根目录下的.claude/settings.json里写清楚默认配置工具会自动按项目加载基本杜绝了串号。安装这类工具一般走 npm装完之后把要切换的配置填进去验证一次能跑通再切换到下一个。团队协作时有一条红线必须守住任何形式的 API Key 都不要提交到 Git 仓库里哪怕仓库是私有的。CC Switch 只负责切换不负责保密密钥管理还是得靠自己。2.2 Ollama 本地模型接入敏感代码不出本机第二条主线是接本地模型。很多做金融、医疗、内部系统的团队代码是不能出本机的但 Claude Code 默认得走云端模型这是个硬冲突。解决办法是把 Ollama 接入进来让 Claude Code 的接口请求落到本地跑的开源模型上。Ollama 是本地大模型运行工具支持 Qwen、DeepSeek-R1、Llama 之类的主流开源模型。社区里有一批桥接脚本做的事情比较简单在 Claude Code 和后端模型之间加一层代理把请求转发到http://127.0.0.1:11434上跑本地模型。配置好之后Claude Code 界面还是那个界面但底层推理完全在本机进行。说句实在话本地模型和 Claude 官方模型的能力差距还是实打实的复杂架构设计和多步重构这类任务本地模型经常做得不够好。所以我的建议不是用本地模型替代云端而是做分流敏感数据审计、脱敏检查、正则生成、格式转换、简单注释补全这些低风险任务丢给本地模型真正涉及系统设计和核心逻辑的仍然走云端旗舰模型。这样做 Token 成本也能降下来不少。机器配置方面16G 内存跑 7B 量化模型是底线14B 和 32B 模型体验会好一截就是内存得 24G 起步。别指望一把老笔记本能流畅跑大参数模型。2.3 官方 Skills把团队规范变成 AI 的肌肉记忆如果说前两款工具是帮你管环境那 Skills 就是真正提升 AI 产出质量的核心机制。我之前写过一篇分享说我团队里两个开发用同一个 Claude Code写出来的代码风格差很多——后来发现不是模型的问题是两个人喂的提示词不一样。Skills 把这个问题彻底解决了。创建 Skills 很简单在项目根目录建一个.claude/skills/目录每个技能放一个子目录里面必须有SKILL.md文件。这个文件用 Markdown 格式写清楚技能的“使用场景”“工作流程”“输入输出规范”。Claude 在会话开始时会自动加载这些技能描述当对话内容跟某个技能匹配时它就会按技能里写的步骤去执行。我这里强烈建议所有团队把“代码审查规范”做成一个技能。传统做法是把规范写进文档让 AI 每次参考但文档一长 AI 就容易忽略。做成技能之后只要说“帮我审查这个文件”AI 就会自动按技能里定义的步骤干活。这一个改动让我们的 Code Review 效率至少提升了一倍而且 AI 审出来的低级错误——命名不规范、异常没处理、日志打错级别——比人眼还稳。技能描述里一定要写清楚“什么时候不该用”不然 AI 会在不合适的地方频繁激活反而添乱。2.4 GitHub MCP让 AI 自己读 Issue、建 PR接下来是 MCP 阵营里我最常用的三个。先说 GitHub MCP它把仓库、Issue、PR、Actions 这些数据暴露给 Claude CodeAI 就能直接读取 Issue 详情、查看 CI 状态、创建 PR 和分支。在过去这些操作要么手动去网页端做要么复制粘贴到对话框里喂给 AI链路长且容易漏信息。接入 MCP 的方法在 Claude Code 里是通过claude mcp add命令完成的也可以在项目根目录写.mcp.json配置文件把需要的 MCP Server 声明进去。GitHub 官方和社区都提供了封装好的 Server按 README 配置认证方式即可。认证信息建议用 GitHub App 或者权限粒度最小的 Personal Access Token不要图省事直接塞一个超管 token否则一旦泄露整个组织仓库都遭殃。实际使用场景我举个例子。同事在 Issue 里报了一个“列表页在移动端样式错乱”的 bug我直接让 Claude Code 去读这个 Issue它会把问题描述、环境信息、附件截图都拉出来然后结合相关代码定位到问题源文件。我让它给出修复方案并改完代码之后它还能生成一份像样的 PR 描述把改动内容和自测结果都列出来我审核一遍点提交就行。这条链路真的能省出大量手动操作时间。2.5 数据库 MCP排查线上问题不用来回开客户端第二个 MCP 是数据库连接器。以前查数据库得自己开一个客户端工具连上再敲 SQL查完把结果贴给 AI 分析。装了数据库 MCP 之后Claude Code 可以直接查询数据库、读取表结构、分析数据分布。排查线上问题的时候效率提升非常明显。让我印象特别深的一次一个订单状态异常的问题我让 Claude Code 先通过 GitHub MCP 读 Issue再让它查订单表里对应订单的状态流转记录。它自己写了 SQL、执行查询、分析出状态卡在了某个中间节点然后顺藤摸瓜定位到代码里对应的状态机逻辑最后还手写了修复建议。整个过程我只给了它一句话剩下的几乎都是它自己完成的那个感觉很上头。当然数据库 MCP 是危险系数最高的接入项安全配置必须最严格。我强烈建议只连测试库或只读副本配置里强制 readonly连接字符串用最小权限账号。敏感字段再配一层脱敏规则让 AI 看到的数据已经是半脱敏的。生产库永远只保留查询权限写操作一律走人工。这条红线一旦失守后悔药是没有的。2.6 Playwright MCP网页验证和抓取交给浏览器自动化第三个 MCP 是浏览器自动化我用的是 Playwright 的 MCP Server通过协议让 Claude Code 能调度一个真实浏览器页面。它可以打开网页、点击按钮、填写表单、截图、读取页面内容。这个能力对两类场景帮助最大一类是前端改完之后的自测另一类是网页数据抓取。以前让 Claude Code 写一个前端页面写完我只能让它从代码层面分析页面有没有渲染出来、交互有没有生效它其实不知道。接了 Playwright MCP 之后写完代码可以直接让它打开本地开发服务器访问页面模拟点击再截图回来给我看。有几次它甚至自己发现了控制台报错然后回头修代码那种“自己写、自己测、自己修”的闭环真的节省了大量来回沟通成本。网页抓取也是我很常用的场景以前写爬虫脚本要手动分析页面结构现在直接描述需求它自己用 Playwright 去操作页面拿数据。这里有个安全提示抓取前务必确认目标网站的服务条款和数据使用规范别把抓取能力用在不当地方。2.7 项目模板加速器新项目三分钟跑起来第七款其实不能算严格意义上的“插件”更像是一套模板资产但它的生产力价值非常高。我发现自己每次在 Claude Code 里开新项目都要跟它反复讲一遍项目背景、技术栈、目录结构、命名规范。讲多了我就想着把这些沉淀成模板让 AI 一开始就自带这些信息省掉一长串解释。实操上其实非常简单把团队常用的技术栈预置成模板目录比如前端 Next.js 模板、后端 FastAPI 模板、内部工具 Python 模板每个模板里放好标准的目录结构、基础配置、环境变量示例。然后写一个 Skill描述“创建新项目时优先读取模板列表按模板初始化项目”。这样每次新项目从空目录到能跑起来基本三分钟搞定。模板的意义不只是“省得敲初始化命令”而是把团队积累的约定固化成了资产。新成员入职clone 下来就能用同样一套流程。需要注意一个问题模板里的依赖版本一定要跟上时代定期更新。我有次用模板开了个新项目发现里面某个框架版本落后了整整一个年度光升级依赖就折腾了半天反而比从零初始化更慢。模板是拿来提效的不是拿来当陈列馆的得常维护。2.8 联网搜索技能补上知识截止日期的短板Claude 有知识截止日期这对开发工作影响挺大。新框架、新版本 API、新发布的库它可能不知道。以前我得自己去搜一遍再把搜索结果塞回对话里现在给它接了联网搜索能力它自己先去搜再基于搜索到的结果回答问题。配置方式看版本现在不少版本已经内置了 web_search / web_fetch 能力直接在对话里触发就行或者在配置里允许相关 API。如果你的版本还没开放也可以接一个搜索类的 MCP Server 补上。我一般是让它在两种情况下主动开搜一是已知问题发生在某个我没听过的库上二是需要确认某个框架的最新版本和最佳实践。用下来有个经验一定要让 AI 把搜索结果的来源 URL 附上方便核对。AI 联网之后跟 AI 不联网一样会有“幻觉”只不过幻觉发生的环节从“编造知识”变成了“编造搜索结果”。你如果不加这个约束它可能会给你一本正经地引用一篇根本不存在的文章。另外涉及公司内部代码或隐私信息的问题不要走联网搜索这个风险不用我多说了。2.9 上下文压缩与省 Token 组合长会话不爆炸第九款严格来说不是单独一个插件而是一整套配置组合但我觉得它才是所有工具里性价比最高的。用长会话用得多的朋友一定遇到过这种场景聊了两个小时忽然 Claude 开始答非所问一看上下文已经快满了Token 费用也在肉眼可见地涨。这个问题的根源是“上下文里塞了太多历史垃圾信息”。Claude Code 内置了/compact命令能把当前会话的历史内容压缩成摘要释放上下文空间。我自己基本每次长任务处理到一半都会用一次。除此之外还有几个细节是搭配使用的把项目的结构、规范写进CLAUDE.md全局文件里AI 不用每次都扫描一堆文件才理解项目大文件先让脚本提取摘要再喂进上下文而不是直接整文件塞进去简单任务切成子会话执行不要把所有事都在一个会话里聊完。我调过一个大项目上下文从入门就开始规划养成习惯之后每周的 Token 消耗直接降了三成多。省 Token 的最高境界不是抠单个请求的长度而是从工作流设计上减少无效信息进入上下文。这项能力带来的收益比很多花里胡哨的插件都实在。3. 照着做就行从安装到串联的完整实操3.1 环境准备装对版本少踩一半坑先交代环境。Claude Code 本质是一个跑在终端里的 Node.js 应用安装环境上踩的坑一大半都出在 Node 版本不对。建议用 18 以上版本我自己用的是长期支持版。装好 Node 之后全局安装一条命令npm install -g anthropic-ai/claude-code装完直接敲claude启动首次运行会引导登录用订阅账号或者 API Key 都行。这里最常见的错误是 Windows 上 PowerShell 报“无法加载文件因为在此系统上禁止运行脚本”这是 PowerShell 执行策略拦住了脚本不是 Claude Code 本身的问题。解决办法是在管理员 PowerShell 里执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned然后再试一次claude。另一个常见问题是命令行提示“claude 不是内部或外部命令”这通常是 npm 全局目录没在 PATH 里。用npm config get prefix看全局目录在哪把它加到系统环境变量的 PATH 里即可。3.2 CC Switch Ollama 完整配置演示我日常用得最顺的组合是 CC Switch 加 Ollama这里给一套完整流程。第一步本地装 Ollama拉一个模型。我日常用的是一款 14B 的代码模型拉取命令大概是ollama pull qwen2.5-coder:14b第二步用 npm 安装 CC Switch 这类配置管理工具社区版本比较多命令以你装到的那版 README 为准。第三步在 CC Switch 里新增两条配置一条指向 Anthropic 官方用于日常复杂任务一条指向本地服务地址填http://127.0.0.1:11434模型名填刚才拉下来的那个。第四步切到本地配置启动 Claude Code随便问一个简单问题比如“把这段 JSON 格式化成可读形式”观察响应速度。如果明显感觉响应非常快但思考深度不如云端模型那基本上就是已经走本地推理了。配置完成之后我的建议是每做一个新项目就在项目级配置里显式指定默认模型来源。这样做的好处是不同项目之间不会串环境公司项目里的敏感数据永远不会跑到本地模型之外的任何地方。我在.claude/settings.json里会写清楚项目名称、默认模型来源、是否允许联网、是否允许 MCP 访问等信息。这样即使换台电脑拉下来项目环境也能通过一个配置文件快速恢复。3.3 手写一个 Skill代码审查技能实例讲一个大家都能直接用的实例写一个代码审查技能。在项目根目录创建.claude/skills/code-review/SKILL.md内容如下--- name: code-review description: 对指定代码文件做代码审查检查规范、安全和潜在bug。 --- ## 使用场景 当用户希望在做代码合并前进行一次快速审查时激活。 ## 工作流程 1. 读取目标文件的完整内容必要时读取相关联的文件。 2. 按以下维度检查 - 命名是否清晰准确 - 是否缺少错误处理 - 是否存在性能隐患 - 是否存在安全风险 - 是否遵循项目现有风格 3. 输出审查结果按严重程度排序。 4. 对每个问题给出具体修改建议尽量带代码示例。 ## 输出格式 - 严重问题 / 一般问题 / 建议三个分类 - 每条问题包含文件位置、问题描述、修改建议 - 不超过 20 条只列真问题不凑数保存之后新开一个 Claude Code 会话让它读一个文件并做审查。你会看到它输出结果的结构完全按照技能定义走。想让团队全员共享这套技能把.claude/skills/目录提交进 Git 仓库就行大家拉到同一个版本AI 审查风格自然就统一了。这也是我上面说的“团队资产”的核心含义。3.4 真实场景串一遍从 Issue 到 PR 的完整链路最后把上面几款工具串成一整条工作流还原一个真实场景。假设项目里收到一个线上 Bug 的 Issue我打开 Claude Code让它读取这个 Issue。它通过 GitHub MCP 把 Issue 描述和相关上下文拉出来然后我让它查一下数据库里对应的异常记录它通过数据库 MCP 执行一次只读查询发现某个订单状态流转的记录存在异常中间态。接着它基于这些信息分析代码定位到状态机更新逻辑里的一个问题我确认后让它直接用 Playwright 打开本地复现页面模拟一次用户操作果然复现了问题。它修完代码之后又在浏览器里跑了一遍回归确认修复生效。最后生成 PR 描述把问题根因、修复方案、自测记录都写清楚通过 GitHub MCP 直接建了 PR我人只需要做一次代码 review。这套链路用到的其实就是 GitHub MCP、数据库 MCP、Playwright MCP加上项目里的 Skills 和 CLAUDE.md 项目说明。整个过程中我真正的操作只有“说清楚需求”和“做最终确认”剩下的脏活累活都交给了 Claude Code。这不只是省时间更是把人的精力释放到真正需要判断力的事情上。4. 问题排查实录装插件路上踩过的坑4.1 安装阶段的高频报错速查表报错信息原因解决办法“claude” 不是内部或外部命令npm 全局目录不在 PATHnpm config get prefix查目录加入 PATH无法加载文件因为在此系统上禁止运行脚本PowerShell 执行策略限制Set-ExecutionPolicy -Scope CurrentUser RemoteSignedNode 版本不支持环境太老用 nvm 安装 18 以上 LTS 版本MCP 服务连接失败端口冲突或服务未启动检查对应服务进程和端口占用模型名选择错误配置里写错了模型标识到本地模型服务或 API 文档里核对准确模型名这些坑本身不难难就难在很多人一出错就先怀疑工具坏了然后疯狂重装最后一查发现是 PATH 这种三分钟能解决的问题。我自己的习惯是遇到报错先把完整的日志读一遍尤其看前二十行绝大多数问题的线索都在里面。4.2 登录与账号权限报错怎么破账号类的报错是另一大雷区。很多人第一次启动 Claude Code 就卡在登录环节浏览器弹窗被各种原因拦截、二次验证老是收不到等问题都有可能出现。最稳妥的做法是确保浏览器登录窗口完整弹出并完成授权流程不要强制中断。还有一类很典型的报错启动时提示你的组织已经禁用了 Claude Code 的订阅访问权限。这说明你当前登录的账号属于某个企业组织而组织管理员没有给成员开放 Claude Code 的使用权限。解决办法不是自己去折腾什么配置直接找组织管理员在管理后台把对应开关打开如果你想个人使用就切换到自己的个人账号或独立的 API Key。这里要记住一个原则企业订阅的开关永远在管理员手里别跟它硬刚。4.3 把 Token 烧在刀刃上的几个细节省 Token 这个事我再多分享几个细节。第一CLAUDE.md里别写废话写项目结构、技术栈、命令规范这些能让 AI 少猜的东西它会显著减少 AI 盲目探索文件系统的次数。第二大文件别整份往里塞。我有一次让 AI 分析一个 3000 行的核心服务文件直接上下文就干掉了四分之一后来改成让它先看函数列表和关键段落再决定深入哪段省了将近一半的上下文效果也没打折。第三子会话是好东西。一个任务聊完了就开新会话别把所有历史都背在背上。很多人有强迫症恨不得一个会话把所有需求聊完结果越到后面 AI 越笨。第四把简单任务丢给本地模型或者轻量模型跑复杂的再上旗舰模型。这就好比你不会用卡车去快递一封信工具选择本身就是最直接的省钱方式。4.4 关于插件的三个独门心得最后讲三条别处不太会写到的经验。第一条装插件前先问自己一个问题下周我还会用它吗不会就不装。Claude Code 的插件生态更新极快今天看起来新奇的工具下个月可能就断更了没必要为一个注定被淘汰的东西支付学习成本。第二条尽量别在同一台机器上同时跑太多配置切换类工具。我刚开始折腾的时候CC Switch、其他模型配置脚本、环境变量脚本堆了一堆结果有一次某个工具悄悄覆盖了另一个工具的配置文件导致所有请求跑到了一个错误的环境排查了大半天。现在我只留 CC Switch 一个入口其他全部移除。工具的职责边界越清晰你越不容易翻车。第三条定期给设备和配置做减法。我几乎每个月会做一次清理把自己装的插件、技能、MCP Server 列个清单看哪些是这个月真正用过的。没用到超过两次的直接卸掉或者停用。生态越拥挤你越需要清爽。我最后留下来的这九款就是在这条规则下跑过一年筛选出的胜出者。我自己实际操作下来的体会是好工具不是让你装完之后膜拜的而是让你用完之后心无波澜的——它就该在那里不打扰你却随时在你需要的时候出现。如果你刚开始接触 Claude Code先从 CC Switch 和 GitHub MCP 装起就行这两个足够覆盖一天 70% 的日常场景剩下的等你真正遇到瓶颈了自然会知道该加什么。别急着把自己的环境堆成杂货铺好的工作流是长出来的不是堆出来的。
