我最早用 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 个 MCP，Claude 每轮都要"看到"这 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 省 token
CC 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 Actions，Claude 默认写出来的模式在最新版里已经不能用了。我启动 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，它会在对话过程中发现需要记住的信息时，自动写入记忆节点，下次会话直接读取。
这其实就是"让大模型拥有长期记忆"的低成本实现。我个人的经验是，不要指望它自动判断什么该记，你可以在项目起步时主动跟它说"记住以下三条项目规范：xxx，xxx，xxx"，它会存得又快又准。前期手动播种，后期自动收获，效果很稳定。
至于为什么不用官方团队后来出的更复杂的记忆方案，我的理由是：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_pass@localhost: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 生态里最大的体会。
 可见性路径中出现了非模块)
