我最早用 Claude Code 时做得最蠢的一件事就是把网上能搜到的插件、扩展、技能包全部装了一遍。结果真正要写代码的时候模型还没开始思考光在几十个工具里挑来挑去就耗掉一大截上下文。后面我把配置全部清空只留下一批真正高频的扩展生产效率和稳定性反而都上来了。到 2026 年Claude Code 的生态和刚出来那阵子已经完全是两个世界了。社区里能把人带偏的“装机指南”越来越多什么插件都敢往配置里塞。我这两年一直在用 Claude Code 做日常开发和自动化任务期间反复装过、删过几十个扩展最后固定下来的正常使用的其实就那么 9 款。这篇文章就从实际使用的角度把这些扩展按照场景整理出来顺带把安装、配置、省 token 的实操方法和踩过的坑一起写清楚。如果你已经装了十几二十个插件建议你先看完这文章再决定删哪些。1. 装插件前先弄清楚 Claude Code 的“插件”到底指什么我看到很多新手一上来就问“Claude Code 插件怎么装”但不同人说的“插件”根本不是同一个东西。有人指的是给 Claude Code 加外部能力的 MCP Server有人指的是官方出的 Agent Skills还有人其实是在问怎么换模型接入。这三个东西混在一起配置自然就容易乱。1.1 MCP、Skill、辅助配置三类扩展完全不是一回事这里先花点篇幅把概念理顺。MCP 是 Model Context Protocol 的缩写简单理解就是给 Claude Code 接外部工具的标准协议。装上 MCP Server 以后Claude Code 在对话里才有了操作 GitHub、查数据库、开浏览器的能力。这一类才是大家平时说的“Claude Code 插件”的大头。Agent Skills 是另一套东西它不是外部工具而是预先写好的流程说明本质上是给 Agent 看的“操作手册”。举例子你写了一份“代码审查规范”的 Skill之后每次让 Claude 审查代码时它会自动先翻这个手册再按手册里的流程去执行。相比直接把规则写进 CLAUDE.mdSkill 更适合封装一整套有固定步骤的复杂工作流。还有一类是配置类的辅助工具典型代表就是 cc-switch 这类命令行小工具用来在多套 API 配置之间切换也常被大家叫成“插件”。另外Claude Code 里面的 Hook 机制也经常被当成扩展用比如每次提交前自动跑测试。严格说它是原生功能不是插件但实际应用场景和插件一样都是扩展能力。所以当你看到别人的配置分享先别急着复制先判断一下推荐的是 MCP、Skill 还是配置工具。接起来的方式有很大差别出问题时的排查方向也完全不同。1.2 为什么我强烈建议别盲目堆插件很多人的心理是“插件越多AI 能力越强”。实际上在 Claude Code 的机制里装插件是有成本的而且不低。每增加一个 MCP ServerClaude 对话里能用到的工具清单就会变长。工具清单越长模型在做计划时需要考虑的选项就越多不仅响应变慢还更容易出现误调用。我亲身踩过的一个场景项目里同时开着 GitHub、Jira、Sentry 三个 MCP只是想让它修个小 Bug结果模型看完工具列表后自作主张去把 GitHub Issue 状态改了还去查了 Sentry 的报错。看起来是能干活但试过几次就知道每次它多跨一个系统调用就要多花一轮工具结果往返这些消耗全部要算进 token 里。修一个小问题结果烧掉几千个 token折腾几次就肉疼。装插件应该遵循一个原则叫“高频兜底低频按需”。只要你确定某个能力每周都会用才把它常驻到配置里。偶尔用一次的场景用到时再临时启动用完就移除。一个项目同时保留 5 到 8 个 MCP Server基本是社区里比较健康的配置水平。超过这个数收益会明显递减。2. 这一年多实测留下来的 9 款生产力扩展下面说的 9 款是我自己在实际场景里反复用、并且现在仍然留在配置里的。每一款我都按“解决什么问题、什么场景用、为什么不建议替代”这三个角度来讲。各位不需要一次性全装根据自己手头的事情筛选就好。2.1 GitHub MCP让 Agent 真正参与仓库协作GitHub 相关的能力算是我使用频率最高的扩展。它的价值不是让 AI 读代码库——Claude Code 本身就能直接读取本地仓库GitHub MCP 真正解决的是“操作远程仓库”这件事。日常的 Issue 维护、拉取 PR 列表、查看 Review 评论、创建分支、推送分支甚至批量给 Issue 打标签这些操作都可以直接通过对话来完成。我现在的日常是每天早上打开 Claude Code第一句就是让它“把仓库里需要我处理的 Issue 列出来按紧急程度排个序”它通过 GitHub MCP 把数据拉回来以后我会直接在里面挑一两个让它开始改代码。整个流程不需要打开浏览器也不需要在 IDE 和网页间来回切。改完代码以后还可以让它在本地跑测试跑完以后帮你提交并创建 PR一气呵成。配置 GitHub MCP 时最需要注意的就是权限控制。网上很多教程让你用 Personal Access Token 并且把权限全部勾上我自己吃过亏有次 Agent 把不该关闭的 Issue 关掉了。建议单独创建一个只用于 AI 的 GitHub Token只给需要的仓库权限操作范围也尽量收窄。个人项目权限大点问题不大公司项目一定要用最小权限原则。2.2 Context7让 AI 不再靠记忆猜第三方库文档Claude Code 在写代码时有一个明显的短板就是大规模模型的知识截止日期再新也不可能覆盖所有第三方库的最新 API。尤其是最近更新频繁的前端组件库、云厂商 SDK、AI 框架模型经常给出一个看起来合理、其实早就废弃的用法。Context7 这款 MCP 就是专门解决这个问题的。它的机制也不复杂当模型在代码里发现某个第三方库时可以通过 Context7 主动去拉取该库最新的官方文档片段再基于真实文档来写代码。用了以后最大的感受就是代码里“幻觉 API”明显变少。以前一些库的接口变动我往往要等编译时报错才能发现现在模型写代码之前就会先把文档拉过来看一眼。这个东西我建议在做新项目、引入新依赖时一定要开。它不参与代码生成逻辑只是在需要时提供准确的文档背景几乎不会干扰模型的正常发挥。使用频率不低但每次消耗的上下文都有限性价比非常划算。2.3 Filesystem MCP跨目录操作和批量重构的利器Claude Code 默认能读写当前工作区里的文件遇到简单的单仓库开发不装文件系统类插件其实也够用。但只要你的工作涉及多个仓库、多套资源目录或者要做规模比较大的文件迁移默认能力就显得有些局限了。Filesystem MCP 就是把文件系统调用权限显式交给 Agent让它能访问你指定范围内的目录。我遇到的一个典型场景是业务仓库需要把一套公共组件从 A 仓库迁移到 B 仓库里面牵扯到 20 多个文件的复制、引用路径调整和旧文件清理。如果纯手工干起码要折腾半小时而且容易漏文件。让 Claude 通过 Filesystem MCP 操作它会按照你自己确认的迁移清单逐个文件处理每步都能被你看到出问题也能随时中断回滚。这里要强调一下不要贪方便把整个磁盘根目录都授权给它。我见过有同事把根目录共享给 Filesystem MCPAgent 在重构的时候把备份文件删除得很干净后来想找回已经来不及了。给它划分明确的目录范围比如只允许访问工作区和某个共享资料目录这是最基本的保险措施。2.4 Fetch/Web 采集类 MCP让 Agent 自己查网页信息写代码时经常需要在网页上查东西比如某个接口的返回示例、官方文档的某段说明、某个配置项的最新含义。传统做法是自己开浏览器搜索再把内容复制粘贴到对话里。让 Claude 自己通过 Fetch MCP 去抓取网页内容再把关键信息提炼出来这个流程会顺很多。我做集成开发时对方经常只给一个网页版的接口文档既不提供 OpenAPI 文件内容又散落在好几个页面。以前我只能一个个复制粘贴费时费力还容易因为漏了一段参数说明导致联调失败。现在我会把文档的入口地址给 Claude让它自己顺着页面里的链接去抓取关键页面整理出一份结构化的调用说明。它甚至能发现网页里不同章节互相矛盾的地方这种阅读耐心比人好很多。不过这类插件有一个必须注意的安全点网页内容是外部不可信信息模型根据抓取到的内容自动执行操作时存在被恶意诱导的风险。建议配置时明确一个使用原则抓取网页只能用于信息分析不能依据网页里的指令去执行敏感操作比如删除文件、推送代码、修改权限等。给 Agent 划清楚这个边界以后这类工具会变得安全很多。2.5 Playwright MCP让 Agent 自己打开浏览器验证前端前端开发里每天都有这种需求改完一个交互效果想看看界面有没有问题。传统做法是启动本地开发服务器自己打开浏览器手动点一遍。Playwright MCP 解决的事情就是让 Claude Code 真的去操作一个浏览器打开页面、点击按钮、输入文字、检查 DOM 状态再把看到的结果反馈给你。以前让 Claude 改一个表单校验逻辑它改完代码我只能说“逻辑上没问题”但心里没底。接了 Playwright MCP 以后可以让它改完以后自己启动项目在浏览器里打开页面跑一遍正常提交和异常提交两条路径再把截图或者运行结果给我确认。这套流程下来前端改动质量明显上一个台阶因为模型在提交前已经做过一遍真实环境验证了。不过这类插件资源消耗很大。启动浏览器、渲染页面、截图传回每一步都有 token 和时间的开销。我不会让它常驻在配置里通常只在需要验证前端功能时临时启动验证完马上移除。记住这个使用节奏能让你的日常开销小很多。2.6 数据库直查类 MCP把数据能力交给 Agent做后端开发或者数据分析类任务时经常需要让 Claude 理解数据库里的真实数据才能给出贴合的方案。比如排查线上问题你看日志只能看到现象需要查库才能确认根因。Database MCP 让模型具备了直接执行 SQL 查询的能力它查完数据以后可以直接基于查询结果做问题判断。拿 SQLite MCP 或者 PostgreSQL 这类比较成熟的 MCP Server 来说安装好以后只需要把数据库连接串作为参数传进去Agent 就能在对话过程中执行 SELECT、查看表结构、分析数据分布。我日常排查数据问题时不需要再另外打开数据库客户端直接在 Claude Code 里让它查库让它根据结果给我结论。对于这种能操作数据库的工具我的经验是哪怕内部开发环境也尽量用只读账号接入。你可以让 Agent 查数据但不应该让它随便 UPDATE 或者 DELETE。真的需要写操作时由你手动执行或者临时切换高权限账号。这个习惯能挡住绝大多数因为 Agent 误解需求导致的数据事故。2.7 模型与 Provider 路由工具省 token 的入口很多频繁使用 Claude Code 的人真正关心的其实不是某个插件能不能用而是每个月的 token 账单能不能扛得住。我自己经历了很长一段时间的大额账单以后总结出来的经验是换一个便宜模型往往比任何“省 token 技巧”都有效。这就是 cc-switch 这类工具存在的意义。Claude Code 本身支持通过环境变量指定 API 地址和模型名称。如果厂商提供了 Anthropic 兼容的接口你可以通过配置不同的环境变量组来切换官方模型、第三方模型或者本地模型。cc-switch 做的事情就是把多套环境变量配置预先保存起来需要时执行一个命令或者按一下快捷键就能切换。比如日常的代码补全和简单问答完全没有必要每次都上最贵的旗舰模型切换到性价比更高的模型就够了。只有做复杂架构设计、长链路重构时再把旗舰模型切回来。特别重的机械性任务甚至可以切到本地模型跑。省下来的不是一点点是一个量级的成本差距。这一款不一定算传统插件但它对日常体验的改善远大于装十个花哨工具。2.8 Agent Skills把重复工作流程固化成规范前面几款都是给 Claude Code 接外部世界的能力Skills 则更像给 Agent 定制的“操作习惯”。因为工作里存在大量重复性任务每个任务都有固定的步骤和容易被忽略的细节。如果每次都要在对话里复述一遍流程助理人员非常容易遗漏让模型从对话里猜操作规范效果也不稳定。把规范封装成 Skill是更优雅的做法。我给自己做了一个“代码提交流程”的 Skill里面规定了提交前必须检查哪几类问题、commit message 怎么写、允许推到哪个分支。以前每次要提醒很啰嗦现在一句“按流程提交代码”模型就会自动走完整套检查。这个体验就像带了一个完全熟悉你做事风格的新同事不需要每次都交代背景。要做一个自己的 Skill 其实没有那么复杂在项目里创建一个.claude/skills/目录下面给每个技能建一个子目录放入一个标准的 SKILL.md 文件就行。文件里写清楚这个技能是干嘛的、什么场景下触发、有什么执行步骤格式本身不复杂。难的地方在于把流程想得足够清楚并且写下来。越是反复出现、越是踩过坑的流程越值得固化成 Skill。2.9 Memory 类 MCP给 Agent 加一份跨会话的记忆Claude Code 本身有上下文能力但每次新会话开始后它对项目历史和你的偏好了解是有限的。反复向它交代“这个项目用 pnpm、代码风格是 xxx、部署通过 xxx 执行”这类信息很浪费时间和 token。Memory 类的 MCP Server 解决的就是这个跨会话记忆问题。这类工具的运行逻辑比较直观它会提供一个持久化的知识库文件Agent 在对话过程中可以把关键信息写入其中。下次新开会话时Agent 可以主动读取这些记忆从而知道你的技术栈偏好、常犯的错误、项目的特殊约定。使用时间越长积累的记忆越多后面每一次协作都丝般顺滑。我强烈建议把平时的项目约定、命名规范、常见依赖版本等都交给记忆工具来管理。只要记住了一个原则写进记忆的信息要是稳定的、长期有效的不要把某个临时任务的中间状态写进去。否则记忆库里全是过期噪音反而会干扰判断。3. 实操环节从 MCP 接入到 token 控制的完整配置就我自己观察90% 的“插件装不上”“插件不生效”问题都是因为在错误的层级安装或者安装完以后没有让配置生效。这里把标准流程和容易踩坑的点完整讲一遍。3.1 MCP 安装的标准姿势与全局/项目区分安装 MCP Server 最快捷的方式是让 Claude Code 自己管理。一般流程是先用包管理器把对应的 Server 运行起来或者通过 npx 直接拉起然后把连接信息告诉 Claude Code。不同 Server 的启动命令会有差异但整体操作思路是统一的。# 查看当前已有的 MCP 列表 claude mcp list # 接一个 Context7用 npx 直接启动 claude mcp add context7 -- npx -y upstash/context7-mcp # 接一个 Playwright适合前端验证场景 claude mcp add playwright -- npx -y playwright/mcplatest # 接一个 Memory保存跨会话的项目偏好 claude mcp add memory -- npx -y modelcontextprotocol/server-memory装完以后记得用claude mcp list看一眼确认状态是正常的。如果列表里有但对话里模型说找不到对应工具先试试重启一下 Claude Code。很多 MCP 是在会话启动时加载的装完不重启确实会不生效这个操作最容易被忽略。全局级还是项目级这个要养成习惯。整个人的通用知识库、常用的代码检查工具建议配成用户级别这样打开任何项目都能用。跟某个具体项目强绑定的一些服务比如该项目特有的数据库、内部文档服务建议只在项目级别里配置。项目级配置可以跟随项目走其他人 clone 项目以后不需要再从头装配直接用就好。3.2 用 CLAUDE.md 把“什么时候该用哪个插件”写清楚插件装好以后怎么让模型在正确的时候调用正确的插件而不是每件事都把所有工具翻一遍这是提升效率和稳定性的关键。答案就是用好 CLAUDE.md 文件。它本身就是让 Claude 在项目根目录下时刻参考的行为规范说明。项目根目录下放一个 CLAUDE.md里面除了项目说明之外我还会专门写一段“工具使用约定”。例如# 工具使用约定 - GitHub 相关操作统一通过 GitHub MCP 完成提交前必须跑一遍测试。 - 查询第三方库 API 时先使用 context7 获取最新文档不要凭记忆写。 - 数据库查询默认走只读账号任何写操作必须向用户确认。 - 前端功能改完后用 playwright 打开本地开发地址验证交互验证完关闭浏览器。 - 不要同时调用超过 3 个外部工具如果场景不需要保持最小调用。这些约定不需要多冗长但一定要写得足够具体让模型拿到以后能直接执行。比如“数据库写操作必须确认”比“注意安全”有用得多。工具的使用边界越清楚模型越不容易乱来实际 token 消耗也会下降。因为模型不再需要思考要不要查这个工具或者错误地调用以后又回滚省下来的都是反复试错的钱。还需要提一眼的是项目级 CLAUDE.md 和用户级 CLAUDE.md 的区别。用户级的放个人全局偏好项目级的放这个仓库特有的约定。项目级的文件建议跟随仓库一起提交这样团队成员都能共享同一套 Agent 使用规范减少沟通成本。3.3 我的省 token 实操经验几个硬手段token 成本控制不是靠某一个设置完成的它是多管齐下的结果。我实测下来最有效的手段按优先级排下来大概有这么几条。第一条是分离任务把复杂任务切小。不要在一个超长对话里既写新功能又查历史问题又做重构每切换一次上下文历史信息都要重新参与计算。把任务拆成独立会话每个会话短小精干总成本反而低。第二条是按需求分配合适的模型。我的做法是用环境变量或者辅助工具快速切换模型。当一个任务只是写个简单脚本、改个命名、看一段报错时我会切到轻量便宜的模型只有做架构设计和代码审查才换高端模型。Claude Code 在对话中通过启动命令的 model 参数可以指定具体模型配合设置环境变量把主模型和快速模型分别指向不同规格体验会比较平衡。第三条是管理好上下文输入。给模型塞大量无关代码、过长的日志或大段网页内容是烧 token 最快的方式。我一般要求 Agent 先给出结论确实需要细节时再让它读取对应文件或查找对应内容。能引用文件的场景不要让模型把整个文件内容复述在对话里。还有一条定期审视你配置的 MCP 列表。长期保留不用的 MCP不仅工具选择会变慢而且每一个 Server 的描述信息都会占用系统提示的上下文空间。删掉那些一个月都没用到的工具你会发现同样的任务响应速度和 token 消耗都会改善。4. 常见问题与排查笔记插件装多了以后基本都会遇到各种稀奇古怪的现象。这里把我踩过的、还有从社区里看到的典型问题整理一份速查方便大家照着排查。4.1 MCP 装了却在对话里不生效这种情况 90% 是因为配置作用域选错了。很多人把项目相关的 MCP 配置成了用户级然后换到另一个项目时发现在原来的项目能用新项目里怎么都不生效。排查的第一步是看claude mcp list里看到的配置列表确认该配置是属于当前项目的。第二种可能是某些 MCP Server 启动时依赖 npx而当前环境里 PATH 没有指向对应的 Node 版本。最典型的是 nvm 用户切换 Node 版本后原来能用的 MCP 突然全部报启动失败。这种情况检查启动日志就能看到错误一般是找不到 npx 或者找不到模块。解决办法是在 MCP 的启动命令中写全路径或者在启动 Claude Code 前先把 PATH 重新 export 一遍。还有一类问题出在 Server 本身需要“初始化握手”。如果 Server 进程启动得很慢而 Claude Code 等待超时会直接判定启动失败。遇到这种情况先单独在终端里跑一遍那个 Server 的启动命令确认它能正常起来再接回 Claude Code这样就比较容易定位是 Server 的问题还是配置问题。4.2 模型名不匹配的报错要怎么处理自己接第三方模型或本地模型时很容易遇到模型报错的提示字面意思通常是当前指定的模型名不被这个版本的 Claude Code 认识。不是模型本身不可用而是代码内部有模型白名单的校验。但线上服务商那边可能只认特定字符串两边名字一不对齐就报这个错。我在实际配置时会把几个关键环境变量显式指定到服务商提供的准确模型名上。在控制台或者 profile 文件里设置好以后再启动 Claude Code一般就不会再提示模型不认识了。不同版本支持的环境变量名会有细微差别动手前先看一眼版本的帮助信息确定要配置哪几个不要把网上看的旧变量名直接照抄。需要提醒的是如果你没有用兼容接口只是想调整对话模型的规格那就不需要动模型名环境变量只要在命令行传 model 参数就行。不要把两件事混在一起很容易越改越乱。4.3 九款扩展的选型速查表工具/类型核心场景常驻还是按需风险提示GitHub MCPIssue、PR、仓库协作建议常驻用最小权限 Token别给全部仓库写权限Context7获取第三方库最新文档建议常驻或高频使用注意它访问的是外部文档别当成绝对正确Filesystem MCP多目录访问、批量重构建议常驻但限定目录只授权必要目录别开放全盘Fetch 网页采集抓取网页文档和资料按需启用慎防网页内容诱导执行敏感操作Playwright MCP前端交互验证强烈建议按需消耗大用完就移除数据库直查 MCP查看真实数据进行问题诊断按项目常驻用只读账号写操作必须人工确认Provider 路由工具切换多套模型配置、控制成本常驻确保切换后配置正确再做关键任务Agent Skills沉淀团队和个人的重复流程项目级常驻技能描述要清晰避免同质化互相干扰Memory 类工具保存长期偏好与项目约定常驻定期清理过期信息别什么都往里存这张表只是一个参考。核心判断标准是你的项目是偏后端、偏全栈还是偏数据分析每个领域真正该常驻的工具组合是很不一样的。对纯后端项目来说Playwright 可能一个月都用不上一次完全没必要常驻。反而数据库直查能力可能要天天用。4.4 装了太多扩展后的典型症状如果你发现 Claude Code 最近变得又慢又爱出错先别急着怀疑是模型变笨了。回到对话里看它每次工具调用前的决策过程你会发现它经常在犹豫选哪个工具。一个项目挂了十几个 MCP Server每次模型都需要在这些工具里选最优解选择一多出错概率自然上去。我给过好几个朋友的建议都是先“断舍离”一回。把配置里的扩展全部去掉保留最基本的 CLAUDE.md跑一周记录自己真正高频操作的场景再把对应的 MCP 逐个加回来。经过这轮精简一般能留下三分之一到一半的扩展就足够了。后续每次想加新插件时问自己一个问题这个工具这周我真的会用超过三次吗答案不确定的时候先别加。这套方法糙是糙了点但效果非常直接。插件生态再繁荣真正属于你自己工作流的永远只有很少的几个。5. 直接抄作业我当前的工作流配置最后分享一套我自己目前在用的精简配置适合中等规模的全栈项目可以直接作为底子去改。项目里有四款 MCP 是常驻的GitHub MCP 管理代码协作Context7 保证模型写第三方库代码时用到的 API 不太旧Filesystem MCP 做跨目录文件操作Memory 记项目偏好。配置大致如下# 全局用户级保存通用偏好和个人习惯 claude mcp add memory -- npx -y modelcontextprotocol/server-memory # 项目级和当前仓库绑定的协作与文档能力 claude mcp add github -- docker run -i --rm \ -e GITHUB_PERSONAL_ACCESS_TOKEN你的token \ ghcr.io/github/github-mcp-server --transport stdio claude mcp add context7 -- npx -y upstash/context7-mcp claude mcp add fs -- npx -y modelcontextprotocol/server-filesystem ./src ./docs数据库类 MCP 和网页采集类工具我只在需要时临时启用Playwright 更是只在涉及前端改动时才会接进来。模型切换工具则一直常驻让我可以在日常任务和重负载任务之间灵活切换。项目根目录的 CLAUDE.md 我写得比较详细包含项目技术栈、启动命令、测试命令、代码风格约定以及每个 MCP 的使用边界。这样每次新开一个会话Agent 打开就能快速进入状态不用我反复解释一遍背景。这套配置最直观的效果就是从打开终端到进入高效编码状态时间大幅缩短每个月的 token 用量也在可控范围之内。插件数量的精简反而是次要的真正有价值的是每一次工具调用都有明确目的。如果你现在正被一堆插件拖得又慢又贵不妨参考这个思路把 Claude Code 的配置做一次减法。