我最早用 Claude Code 的时候也是一个不折不扣的插件仓鼠。看到推荐就装MCP server 塞了十几个Skills 目录里堆了一堆不知道干什么用的文件夹结果呢启动慢、上下文被垃圾工具说明占满、权限弹窗弹到怀疑人生最离谱的一次是写 Python 的时候 Claude 非要调用某个跟项目毫无关系的搜索工具去查List 的用法。2026 年了Claude Code 的生态经过两年爆发式增长早就过了装得多就是强的阶段。真正能留下来的一定是能直接解决高频痛点、维护活跃、不会反过来拖累你的工具。这篇我就按自己实际用了大半年、反复卸载又装回来的真实体验整理了 9 款我认为才是真正生产力的 Claude Code 扩展。注意我这里说的插件是泛指包括 MCP server、官方 Skills、以及像 CC Switch 这种配套配置工具。不管你是刚装好 Claude Code 想少走弯路的新手还是已经被插件列表拖累的重度用户这篇应该都能帮你砍掉一多半没用的东西。1. 先搞清楚 2026 年 Claude Code 的扩展机制再谈安装很多人在装插件之前根本没弄明白 Claude Code 的扩展到底分几类结果就是三种东西混着装互相打架。我给身边同事排障的时候十次有八次是这个问题。1.1 插件、MCP、Skills 三者的真实边界先说结论到了 2026 年Claude Code 的扩展生态主要由三块组成职责完全不同。第一类是 MCP server全称 Model Context Protocol它解决的是给 Claude 接外部数据源和工具的问题。你想让 Claude 读数据库、查网页、操作浏览器、读写本地文件都走 MCP。每个 MCP server 就是一个独立进程通过 stdio 或者 HTTP 跟 Claude Code 通信。它的特点是功能强、权限大但也是上下文消耗的大头因为每个 server 带的工具描述和 schema 都会被打进 prompt 里。你装 10 个 MCPClaude 每轮都要看到这 10 个 server 的工具清单。这就是上下文被吃掉的元凶之一。第二类是 Skills也就是技能包。它是给 Claude 预置的做事方法论本质上是一组带指令的文件夹里面通常包含一个 SKILL.md 描述文件和一些参考脚本。例如你写一个代码审查技能里面写好审查流程、注意点、输出格式Claude 遇到相关任务时会自动调用。它不是外部工具而是行为模板几乎不额外消耗上下文只在被触发时加载这是它比 MCP 轻量的核心原因。第三类是独立配置工具像 CC Switch 这种它的作用是管理 Claude Code 本身的配置比如切换不同的模型供应商、端点和 API Key不参与对话推理但能大幅改善日常使用体验。搞清楚这个边界之后很多问题就通了你不需要一个翻译 MCP再配一个翻译 Skill那俩解决的是完全不同层面的问题装重了要么上下文翻倍要么行为冲突。1.2 我筛选插件的四条硬标准经历了装-卡-卸-再装的循环之后我给自己定了几条规矩2026 年筛选任何 Claude Code 扩展都拿这四条过一遍是否解决每周都会遇到的高频问题而不是偶尔用一下的新鲜功能维护是否活跃社区 star 数量、最近 commit 时间至少要能查到否则模型升级一个版本它可能就废了是否尊重上下文预算工具描述冗长、强制注入大量说明的 MCP 直接淘汰是否有不可替代性如果原生功能、官方 Skills 或一段 Prompt 就能覆盖那就坚决不装。下面这 9 款就是按这个标准筛出来的。2. 九款工具上半场写代码、改代码和管代码的底座写代码是 Claude Code 的核心场景所以前四款都是围绕让编码流程更顺这件事展开的。它们解决的是配置切换、技能沉淀、代码托管和文件操作这几个基础问题。2.1 CC Switch多配置无缝切换还能接 Ollama 省 tokenCC Switch 目前是我电脑上装了就不会想卸载的工具没有之一。它解决的是 Claude Code 配置管理的地基问题尤其是你手上有多个 API 来源、多个项目、多个供应商的时候。默认情况下Claude Code 的配置散落在~/.claude/settings.json和项目级.claude/settings.json里环境变量 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 一多来回改文件非常容易出错。CC Switch 做的事情就是把这些配置做成Profile在界面上点一下就能切换。我实际的使用场景是这样的日常主力写代码用 Anthropic 官方 API但做一些纯文本整理、格式转换、批量改文件名这类琐事时我会切到 Ollama 的本地模型比如 qwen3 或者 llama 系列的中小尺寸版本反正这种任务不需要顶级推理能力本地模型响应快、不花钱也不用担心 API 额度。注意这里不是让 Ollama 替代 Claude而是做任务分流。这就是热词里claude code cc switch ollama能火起来的原因——它不是魔法是合理的资源调度。安装和配置不用写代码下载 CC Switch 之后在界面里添加 Profile填上模型供应商、API 地址和 Key然后在 Claude Code 里执行claude --settings确认读到了就行。我踩过的一个坑是切换 Profile 之后已经打开的 Claude Code 会话不会自动生效必须退出重进。很多人以为配置坏了其实只是没重启会话。2.2 anthropics/skills 官方技能包别写重复 Prompt 了很多人的插件目录里塞满了自己东抄西抄的 Prompt 模板其实 2026 年最该装的 Skills 是 Anthropic 官方仓库 anthropics/skills 里那一套。这不算第三方插件但效果比绝大多数野路子技能好。这个仓库里有一些经过官方验证的技能比如项目初始化、文档生成、代码库分析之类的。每个技能的结构都差不多一个 SKILL.md 写清楚什么场景触发、执行步骤是什么、输出格式是什么还可能带一些辅助脚本。你把仓库 clone 下来把对应技能目录放到~/.claude/skills/或者项目根目录的.claude/skills/下Claude 就能自动识别。举个例子我经常用它的代码分析技能来做技术债盘点。以前我要写一大段 Prompt 告诉 Claude你是个资深架构师请分析这个模块的耦合度、重复代码、潜在 bug按 XXX 格式输出。现在不需要了只要说用 codebase-analysis 技能看一下 src/ 目录它就会按技能里约定的流程走而且输出的结构化程度非常稳定。等于把最佳实践的 Prompt固化成了可复用资产还不用占对话上下文。我特别建议刚接触 Skills 的人从官方仓库开始不要一上来就自己写。先看看官方是怎么设计触发条件和执行步骤的模仿着写比自己瞎写有效得多。2.3 GitHub MCP把 Issue、PR、Review 从浏览器搬回终端GitHub 官方出的 github-mcp-server 是写代码场景里我最离不开的 MCP 之一。它让 Claude Code 能直接操作 GitHub API包括看 Issue、列 PR、读 review 评论、创建分支、提交 PR 等。这里的关键是工作流不被打断。以前我在 Claude Code 里改完代码要切到浏览器看 CI 报错、去 GitHub 看 review 意见再把意见贴回终端。装上这个 MCP 之后我可以直接让 Claude看一下这个 PR 的 review 意见或者把 main 分支上最新的三个 issue 列出来它自动把问题拉回来再结合代码上下文直接修。尤其是 Review 的场景Claude 读代码的能力本来就强让它把 review 意见逐条对应到代码位置效率比人肉切换高太多了。安装方式很简单按官方 README 配置一个 token 就行。但我提醒两点第一token 权限别给太大默认只读权限够用就先只读只有确实需要自动建 PR 的时候再放开写权限第二这个 MCP 工具数量多、描述也长如果你平时只用它的两三个功能可以在配置里通过-e环境变量控制加载范围或者只在做 GitHub 相关任务时临时打开它别全局常驻能省不少上下文。2.4 Filesystem MCP让 Claude 安全操作本地工程Filesystem server 属于基础但必须的那类扩展。Claude Code 原生能读写工作目录里的文件但如果你想让它访问范围外的目录或者按白名单精确控制它能触碰哪些路径就需要 filesystem MCP。我用它主要解决两件事。一是跨项目复用脚本比如我有个公共的 shell 脚本目录放在~/scripts默认情况下 Claude Code 在项目 A 里是看不到的配上 filesystem MCP 把那个目录加进白名单之后它就能引用和执行这些通用脚本了。二是做带边界感的文件操作比如只允许它读取某个数据目录、不允许碰配置文件通过参数把允许访问的路径写死比默认的全工作区可写要安全得多。配置方式不复杂在 Claude Code 里执行claude mcp add filesystem -- npx -y modelcontextprotocol/server-filesystem /你的/目录就行也可以直接改 JSON 配置文件。很多人问为什么明明能原生读写文件还要装这个我的回答是MCP 的价值不在于能不能而在于边界和控制。特别是你在跑一些半自动脚本的时候你不想让 Claude 顺手改到.env或者部署脚本用 filesystem MCP 把白名单收窄是成本最低的防护。3. 九款工具下半场检索、浏览器、数据库和记忆如果说前四款是编码流程的底座那么接下来这五款就是让 Claude Code 从能写代码变成能干活的关键。它们分别覆盖最新资料检索、网页交互、文档查询、数据库操作和记忆持久化。3.1 Exa Search MCP给 Claude 装上最新资料入口Claude 的训练数据有截止时间这是所有用 AI 编程的人都会遇到的问题。你问它某个库 2026 年的新 API 怎么用如果它没学过要么瞎编要么让你自己去查。Exa Search MCP 解决的就是这个联网获取最新信息的问题。Exa 本质上是一个面向 AI 场景优化的搜索引擎跟传统的搜索引擎比它返回的不是一堆链接而是语义相关的网页内容摘要甚至可以直接返回内容正文。在 Claude Code 里我遇到不确定的 API 用法时不跟模型硬刚直接说帮我用 Exa 搜索一下 xxx 的最新文档它去查完回来再回答准确率提升非常明显。我最常用的场景有两个一是框架新版本发布后接口改了旧写法失效了让 Claude 去搜官方 changelog二是写一些冷门库的集成代码先让它搜索用法再写避免编造不存在的参数。有个细节Exa 的搜索质量很大程度上取决于你给的 query 是否精准教 Claude 先提取关键词再构造 site: 限定能让结果好很多。你可以在配置里给它加一条使用偏好每次搜索前自动优化查询条件。3.2 Playwright MCP调试网页和写 E2E 的实用帮手Playwright MCP 是微软官方出的它让 Claude Code 能启动浏览器、打开页面、点击元素、读取 console 日志、截图甚至可以帮你跑 E2E 测试。对做前端或者全栈的人来说这个 MCP 的价值是让 Claude 自己看自己的产出。以前写了一个网页功能我得手动打开浏览器操作一遍再把结果反馈给 Claude 让它修 bug。现在让 Claude 自己用 Playwright 打开本地开发服务器点击按钮把 console 的报错抓回来分析修复再跑一遍验证。一个循环完全在终端里完成。我遇到的一个实用性案例是某页面在移动端布局错乱类名冲突。我让 Claude 用 Playwright 分别用桌面和移动视口打开页面截图对比再结合代码找到是哪个媒体查询导致的前后十分钟就修完了。以前这活至少要折腾半小时以上。但要注意Playwright MCP 是个重量级选手启动浏览器进程、加载一堆工具描述对上下文消耗不小。我的建议是只在做前端调试或 E2E 任务时临时加载它可以用claude mcp add时加--scope限定到项目或会话不要全局常驻。3.3 Context7 MCP查 SDK 文档不再靠复制粘贴Context7 是我在 2026 年发现的一个解决项目文档碎片化的 MCP。它的逻辑很简单你告诉它你在用什么技术栈比如React 19 Next.js 15 Prisma它就帮你拉取这些框架的最新文档到上下文里让 Claude 用最新知识回答。它解决的是文档太多、模型记不住最新变更的终极痛点。我印象很深刻的一次是写 Next.js 的 Server ActionsClaude 默认写出来的模式在最新版里已经不能用了。我启动 Context7 加载 Next.js 文档后它按照新版本的写法给了一份带正确参数和缓存策略的代码直接跑通。官方对这种工具的说法是让模型永远用最新文档编程虽然有点夸张但确实能省去大量搜索—读文档—试错的时间。配置也很轻注册 token 后claude mcp add context7 -- npx -y upstash/context7-mcp就完事。美中不足的是它需要联网而且偶尔拉到的文档版本跟项目实际版本不完全匹配建议加载的时候明确指定版本号。3.4 PostgreSQL MCP在对话里直接看数据结构和跑查询数据库是很多开发者的日常战场PostgreSQL MCP 让 Claude Code 直接连接数据库读取 schema、执行查询、分析慢 SQL。我之所以把它放进值得装的前九是因为让 AI 看数据库结构再写代码比让 AI 猜数据库结构强太多了。以前 Claude 生成一段数据查询代码经常因为字段名、表关系跟实际库不一致而报错。接了 PostgreSQL MCP 之后它会先通过工具读取相关的表结构再基于真实 schema 写代码正确率是质的飞跃。甚至你可以直接让它查一下最近 7 天订单量表 trend按天分组它自己连库、跑查询、返回结果再把结果整理成表格给你。当然这是权限敏感型工具我强烈建议只连本地开发库或测试库生产库永远不要配到 MCP 里。就算要连生产库也一定用只读账号而且只能开放必要库的权限。安全原则必须前置不然哪天 Claude 被 prompt injection 诱导执行 DELETE 就麻烦了。3.5 Memory MCP让 Claude 记住你的项目偏好Memory server 是官方 MCP servers 里我非常喜欢的一个。它是一个轻量级的知识图谱记忆可以把一些长期不变的事实存下来比如项目里不用 localStorage统一用 zustand 持久化、代码风格遵循 eslint-config-airbnb、发布流程是先打 tag 再发 PR。为什么需要它因为 Claude Code 每次会话都是一次全新的开始默认不会记住上个会话的约定。你连续几周让它改同一个项目如果每轮都要重新交代项目约定不仅烦还容易漏。有了 Memory MCP它会在对话过程中发现需要记住的信息时自动写入记忆节点下次会话直接读取。这其实就是让大模型拥有长期记忆的低成本实现。我个人的经验是不要指望它自动判断什么该记你可以在项目起步时主动跟它说记住以下三条项目规范xxxxxxxxx它会存得又快又准。前期手动播种后期自动收获效果很稳定。至于为什么不用官方团队后来出的更复杂的记忆方案我的理由是Memory MCP 足够轻、足够透明记忆文件就是本地 JSON随时可以查看和修改出了问题也容易排查。复杂的记忆系统在团队协作场景可能更强但个人日常使用完全没必要。4. 真实工程里的组合方案和踩坑记录工具列完了接下来是更重要的部分——这些工具在实际工程里怎么组合、我踩过哪些坑、以及怎么用它们实现真正的省 token。4.1 我当前的主力配置可直接参考以我目前手头一个 Next.js PostgreSQL 的中型项目为例我的~/.claude/settings.json里 MCP 部分长这样做了脱敏简化{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /Users/me/scripts, /Users/me/projects ] }, github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_TOKEN: 你的只读token } }, postgres-dev: { command: npx, args: [-y, modelcontextprotocol/server-postgres], env: { DATABASE_URL: postgres://dev_user:dev_passlocalhost:5432/dev_db } }, context7: { command: npx, args: [-y, upstash/context7-mcp] } } }exa 和 playwright 我没有全局配置而是在需要的时候用claude mcp add --scope project临时加到当前项目用完再claude mcp remove。这样日常会话的上下文压力小得多。Skills 方面我把 anthropics/skills 里的代码分析、文档生成技能放在了~/.claude/skills/项目级的特殊规范放在.claude/skills/下供团队共享。4.2 四个我踩过且你大概率会踩的坑第一个坑是不同 MCP 之间工具名冲突这是 2026 年 MCP 生态变繁荣之后的新问题。比如两个 server 都提供了search工具Claude 调用时可能混淆。解决方式是配置里给 server 起语义化的名称比如github-search、exa-search而不是都叫search。这能让模型在选择工具时减少歧义。第二个坑是权限配置过大。很多人第一次配 GitHub MCP 直接给了全部权限结果有次 Claude 把我一个个人仓库的 issue 给 close 了。倒不是它故意使坏而是它的 action 确实有这个权限只是我这个任务是批量处理 issue判断失误关错了。后来我把 token 权限收紧到只读处理有写操作的任务时再临时换高权限 token从此再没出过这种事。第三个坑是 MCP 进程崩溃导致整个对话变慢。有的 server 启动时要下载一堆依赖网络不稳时直接卡死Claude 甚至会反复重试同一个挂掉的工具拖累整轮对话。我现在的做法是重要的 server 用npx -y固定版本在包名后加版本号不追最新避免昨天还好的今天崩了的灵异事件。第四个坑是关于 Skills 的触发条件。我一开始以为技能装了就生效后来发现 Claude Code 并不会每次会话都读取全部技能它有一套触发匹配机制只有任务和技能描述相关时才会加载。如果你的技能一直没被触发先检查 SKILL.md 里的 description 是否包含足够多的触发词别问为什么我都装了它就是不主动用。4.3 省 token 不是靠插件而是靠任务分流思路热词里有人问claude code 如何用省 token我用了大半年后的体会是真正省 token 靠的不是某个神奇的压缩插件而是一套任务分流策略插件只是在某个环节里提供支持。具体来说我的策略有三条。第一条是琐碎任务走本地模型。格式转换、日志整理、简单文本替换这些不需要强推理的任务我会在 CC Switch 里切到 Ollama 本地模型处理处理完再切回 Anthropic 模型。本地模型跑这些又快又稳还完全不占 API 额度。第二条是用 Context7 这类文档检索工具减少猜 API—试错—报错—再猜的 token 浪费。一次精准的文档查询很可能省掉三轮无效的失败尝试而失败尝试的 token 消耗是最大的。第三条是合理利用 Memory 和 Skills 固化项目规范和流程避免每轮会话重新解释一遍。经常有人以为上下文窗口大了就不怕装插件这是误解。上下文窗口再大模型在超大上下文里的信息召回和注意力分配也会变差工具描述太多会稀释真正重要的代码信息。所以我在一个会话里通常保持 2 到 4 个 MCP 常驻其余全部按需加载。这比任何智能压缩插件都实在。5. 说点大实话2026 年插件生态的下一步以及我的个人选择写到最后我想聊几句不那么方法论的东西。2026 年的 Claude Code 插件生态已经到了一个标志性阶段马太效应很强少数优质扩展占据了绝大多数使用场景大量同质化工具在快速消失。这个阶段再去追求把所有插件都试一遍成本已经远大于收益了。我个人的选择是日常开发固定用 CC Switch、官方 Skills、GitHub MCP、Filesystem MCP 这四件套做底座需要时按任务加载 Context7、Exa、Playwright、Postgres MCP 和 Memory MCP。装之前先问自己三个问题我最近一周真的会遇到这个场景吗它解决的问题有没有更轻的替代方案如果它坏了我的工作流会被打断多少三个问题想清楚插件的数量自然就下来了。最后再分享一个小技巧每个季度我会做一次插件清理日。把~/.claude/下面所有 MCP 配置和 Skills 目录列出来关掉那些超过 30 天没被调用过的扩展再看官方仓库有哪些新的高质量 Skill 值得跟进。这个习惯帮我淘汰掉了至少一半的当时觉得有用的插件也让每次 Claude Code 会话的响应速度和上下文质量都保持在一个很舒服的状态。少装一点反而跑得更远这是我在 Claude Code 生态里最大的体会。