开发者必装的几个 MCP 推荐：装这几个就够
MCP（Model Context Protocol）是给 AI 编程工具外接能力的”标准插头”，让 Claude Code、Cursor 这类客户端能统一调用查文档、跑浏览器、读代码库等外部服务。 但 MCP 不是越多越好——每装一个，它的工具描述都会塞进上下文，装太多会白白烧 token、稀释模型注意力，甚至让它选错工具。这篇给你一份”装这几个就够”的精简清单，以及按需求该加哪个的判断。
给个直观数字：一个中等体量的 MCP，光是工具描述（每个工具的名字、参数、用途说明）就可能占掉几百到一两千 token，同时挂五六个杂七杂八的 MCP，还没开始干活，上下文里就先被塞进去几千 token 的”说明书”。更麻烦的是，工具一多，模型在选工具这一步就容易犹豫甚至选错——比如同时装了两个能”读文件”的 MCP，它可能瞎猜该用哪个。所以判断标准很简单：这个 MCP 帮你干的事，模型自己干不了或干不好，才值得占这份上下文预算。
不清楚 MCP 到底是什么、和普通插件有何区别，先看 MCP 协议是什么（规划中） 打底，再回来挑工具。
一句话选型结论
先装两三个高频的，别一上来铺满。 几乎人人受益的是查最新文档和浏览器自动化两类；做工程的再加代码托管；遇到复杂任务再开深度思考。其余按项目临时装、用完即关。
选型对比表
| MCP | 解决什么 | 谁最需要 | 上下文开销 |
|---|---|---|---|
| Context7 | 拉取库/框架的最新官方文档喂给模型 | 几乎所有写代码的人 | 低 |
| Playwright | 让 AI 操控真实浏览器做测试/截图/抓页面 | 做前端、写 E2E 测试的 | 中 |
| GitHub | 读写仓库、Issue、PR，不离开编辑器管代码 | 团队协作、CI 相关 | 中 |
| Sequential Thinking | 给模型一个显式分步推理的草稿空间 | 啃复杂重构/排查难题 | 低 |
| 文件系统 / 数据库类 | 让 AI 直接读本地文件或查库 | 数据脚本、运维 | 视范围而定 |
各 MCP 的具体安装命令、端点、版本号以官方文档为准，下文只讲它”做什么、值不值得装”。
主流客户端装 MCP 的方式大同小异：Claude Code 用 claude mcp add 命令行注册，Cursor、Windsurf 一般在设置里的 MCP 面板加一段 JSON（写服务名、启动命令、参数、必要的环境变量）。装完记得重启客户端——这是最容易被忽略的一步，很多人以为装了没生效，其实只是没重启，配置没重新加载。
逐款简评
Context7：解决”模型记的 API 过时了”
定位：按需把某个库的最新官方文档注入上下文。模型训练有知识截止日，写到新版本 API 经常凭记忆瞎编；Context7 让它现查现用。 优势：几乎零学习成本，对快速迭代的前端框架、SDK 尤其救命；开销低，可以长期挂着。 短板：覆盖的库有限，冷门私有库、你司内部的自研框架它查不到。 适合谁：所有人——这是我的第一必装。想深入用法看 Context7 MCP 实战（规划中）。
实际用起来很简单：提示词末尾加一句”use context7”，模型就会先去拉对应库当前版本的文档片段，再基于这些片段写代码，而不是凭训练时的记忆瞎编。举个真实会踩的坑——让模型写 Next.js 最新版的 Server Actions 或者某个刚发布不久的 SDK 客户端初始化代码，不挂 Context7 时它大概率写出的是一两个大版本之前的写法，函数名对不上、参数顺序变了都有可能；挂上之后，它会先查一遍当前版本文档再落笔，返工率明显降低。反过来说，如果你写的是稳定多年没怎么变的老库（比如基础的 Python 标准库），Context7 帮不上什么忙，模型自己记的就够用。
Playwright：让 AI 真的去点页面
定位：把浏览器自动化能力交给 AI——打开页面、点击、填表、截图、断言，常用来写和跑端到端测试。 优势：前端开发闭环利器，AI 能”看到”渲染结果而非瞎猜；调试 UI、复现 bug 极快。 短板：会拉起真实浏览器，开销和耗时比纯文本工具高；非前端项目用不上。 适合谁：写前端、做 E2E 测试的开发者。用法细节见 Playwright MCP 怎么用（规划中）。
它最大的价值不是”帮你写测试脚本”，而是让 AI 能亲眼看到页面渲染出来的样子。比如你说”这个表单提交后错误提示没显示”，没有 Playwright 时你得自己截图、贴报错、来回描述；挂上之后，AI 能自己打开页面、填表、点提交、截图看真实的 DOM 和样式，直接定位到是校验逻辑没触发还是 CSS 把提示文字盖住了。装的时候注意它需要先在本地装好浏览器内核（一般是首次运行时自动拉取 Chromium），如果是在 CI 或者容器里跑，得留意浏览器依赖装全，不然会报缺库的错。
GitHub：把仓库管理搬进对话
定位：读写你的 GitHub 仓库、Issue、PR、Actions，让 AI 不切窗口就能查代码、提 PR、回 Issue。 优势：团队流程顺，“帮我看下这个 PR 改了啥""按这个 Issue 写实现”一句话搞定。 短板：需要配置访问令牌，权限范围要给最小，别图省事开全权限。 适合谁：团队协作、重度用 GitHub 工作流的人。个人单机小项目可以先不装。
配置令牌时建议用 GitHub 的 fine-grained personal access token，只勾选你要操作的那几个仓库，权限只给 Contents（读写代码）、Issues、Pull requests 这几项就够日常用，千万别为了省事直接给 classic token 的 repo 全权限或者组织管理员权限——一旦这个令牌所在的配置文件被误传或者客户端本身出问题，权限范围就是你能兜住的最大损失面。另外令牌要设过期时间，定期轮换，别用一个永久令牌挂一整年。
Sequential Thinking：给难题一个草稿本
定位：提供一个让模型显式分步、可回溯推理的工具，适合需要拆解的复杂任务。 优势：啃大重构、排查诡异 bug 时，能让模型”想清楚再动手”，减少跳步翻车。 短板：简单任务上是纯浪费——会让本来一步到位的活变啰嗦。 适合谁：经常处理复杂逻辑、长链条任务的人，按需开。
典型场景是那种”数据在 A 服务是对的，传到 B 服务就错了”的跨服务排查——正常对话模式下模型容易想到哪查到哪，中途丢掉之前的假设；开了 Sequential Thinking 之后，它会把”先假设是序列化问题→验证→排除→再假设是时区转换问题→验证”这套推理过程显式写出来、每一步都可回溯修正，比单纯让它”自己想”更不容易漏掉分支。但你要是只是让它加个字段、改个样式，开着这个工具反而会让它”没话找话”地多绕几步，这时候关掉更省心。
其余按项目临时装
文件系统、数据库、Slack、Notion 等 MCP 都有，但它们高度依赖你的具体活儿。原则就一条：这个项目这次真用得上才装，用完就摘，别让它长期占着上下文。
按需求怎么选
给三类人的最小清单，照着抄：
- 个人写代码/学习：
Context7。够了。遇到前端调试再加Playwright。 - 前端工程师：
Context7+Playwright。要管仓库再加GitHub。 - 团队协作/全栈：
Context7+Playwright+GitHub，复杂任务临时开Sequential Thinking。
核心判断口诀：高频且开销低的常驻（如 Context7），重而专的按需开（如 Playwright、Sequential Thinking），权限敏感的给最小授权（如 GitHub）。 装之前先问自己一句——“这周我真会用到它吗？“答不上来就别装。
常见问题
MCP 装越多功能越强吗？ 不是。每个 MCP 的工具说明都会占上下文，装太多会烧 token、拖慢响应，还可能让模型在一堆工具里挑错。精简到两三个高频的，效果反而更好。
一个 MCP 都不装，AI 编程工具能用吗？ 能。MCP 是增强项不是必需项。Claude Code、Cursor 不装任何 MCP 也能写代码，MCP 解决的是”查最新文档、操作外部系统”这类它本身够不着的事。
Context7 和直接把文档贴给 AI 有啥区别？ Context7 是按需自动拉取对应库的最新文档，你不用手动找、手动贴；省事且更新及时。手动贴文档当然也行，只是麻烦、容易贴到旧版本。
MCP 在不同工具间通用吗？ 理论上通用——这正是”协议”的意义：同一个 MCP 服务能被不同支持 MCP 的客户端调用。但各客户端的配置方式、支持程度有差异，具体以你所用工具的官方文档为准。
装了 MCP 没生效怎么办？ 常见原因是配置文件路径或格式不对、令牌没配、客户端没重启。先重启客户端，再核对配置项，令牌类的检查权限范围——具体排查步骤以对应 MCP 的官方文档为准。
👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。