Claude Code + MCP 深度实战：6个“外挂“让AI从只会聊天变成真正干活，附完整配置与避坑指南

Claude Code + MCP 深度实战：6个"外挂"让AI从只会聊天变成真正干活，附完整配置与避坑指南

摘要： MCP协议火了，但90%的文章都在教你"怎么装"，装完之后AI还是只会聊天。本文实测了6个MCP Server（filesystem、github、playwright、postgres、puppeteer、memory）在真实开发场景中的表现，每个场景都记录了问题现象、根因分析、解决方案与反思。读完这篇，你将知道哪些MCP真能让AI干活、哪些是摆设、以及踩过的每一个坑。

📖 目录

• 一、MCP的现状困境
  • 1.1 为什么装了MCP，AI还是只会说话？
  • 1.2 MCP的正确理解：不是插件，是插座
• 二、MCP配置清单与安装指南
  • 2.1 六个MCP Server选型对比
  • 2.2 完整配置文件
  • 2.3 安全提示：Token与密码管理
• 三、场景1：filesystem——让AI读写项目文件
  • 3.1 问题现象：没有MCP时AI只能"建议"
  • 3.2 有MCP后的效果
  • 3.3 避坑1：目录权限配置不当
  • 3.4 避坑2：AI会顺手改不该改的文件
  • 3.5 效果评分
• 四、场景2：github——让AI管理仓库Issue与PR
  • 4.1 问题现象：没有MCP时AI只能给链接
  • 4.2 有MCP后的效果
  • 4.3 避坑1：Token权限过大
  • 4.4 避坑2：PR审查的假深度
  • 4.5 效果评分
• 五、场景3：playwright——让AI做浏览器自动化
  • 5.1 问题现象：没有MCP时AI只能输出代码
  • 5.2 有MCP后的效果
  • 5.3 避坑1：首次启动浏览器很慢
  • 5.4 避坑2：动态页面元素识别不稳定
  • 5.5 效果评分
• 六、场景4：postgres——让AI直接操作数据库
  • 6.1 问题现象：传统方式查数据有多繁琐
  • 6.2 有MCP后的效果
  • 6.3 避坑1：最危险的MCP——AI可能删库
  • 6.4 避坑2：AI生成的SQL不一定最优
  • 6.5 效果评分
• 七、场景5：puppeteer——网页抓取与性能分析
  • 7.1 问题现象：手动抓数据的低效循环
  • 7.2 有MCP后的效果
  • 7.3 避坑1：puppeteer和playwright功能重叠
  • 7.4 避坑2：反爬机制导致抓取失败
  • 7.5 效果评分
• 八、场景6：memory——让AI记住你说过的话
  • 8.1 问题现象：AI的"失忆"折磨
  • 8.2 有MCP后的效果
  • 8.3 避坑1：知识库会膨胀与冲突
  • 8.4 避坑2：本地JSON存储不够健壮
  • 8.5 效果评分
• 九、6个MCP Server综合对比
• 十、终极避坑清单：7条铁律
• 十一、MCP的真实定位与展望
  • 11.1 MCP不能做的
  • 11.2 MCP真正擅长的
  • 11.3 MCP的下一步

一、MCP的现状困境

1.1 为什么装了MCP，AI还是只会说话？

问题现象

2026年6月，MCP（Model Context Protocol）协议已经成为CSDN热搜榜上的常客。Anthropic把它叫做"AI的USB-C"——听起来很酷，但大部分人装完之后的体验是这样的：

你：帮我查一下数据库里最近7天的订单数据

Claude Code：好的，我需要先连接数据库……
（然后开始输出一堆"建议你使用SQL查询"的文字）

你：你不是装了MCP吗？直接查啊！

Claude Code：抱歉，我无法直接执行操作……

装了工具，但AI不会用——这是90%开发者的真实困境。

根因分析

根本原因是：你只装了MCP Server，但没有教会AI怎么用它。 大部分CSDN文章只教"安装配置"，不教"如何让AI真正调用"。装完MCP Server后，AI需要理解每个Server暴露的工具（Tool）及其参数，才能正确调用。如果你只是在对话中说"帮我查数据库"，而没有明确指定"用postgres MCP的query工具"，AI可能仍然用老方式——输出建议文字而不是执行操作。

1.2 MCP的正确理解：不是插件，是插座

核心认知

MCP不是"装上就能跑"的插件，它更像是一个插座——你得插上正确的电器，还得教AI怎么"按下开关"。

这篇文章，我就把"插座+电器+开关"的完整链路全部拆开，用6个真实开发场景实测，告诉你：

• ✅ 哪些MCP Server确实能让AI"干活"
• ❌ 哪些是看起来很炫但实际鸡肋
• ⚠️ 每个场景踩过的坑和解决方案

二、MCP配置清单与安装指南

2.1 六个MCP Server选型对比

先上选型，后面逐个场景实测：

2.2 完整配置文件

在项目根目录创建 .mcp.json 文件（Claude Code会自动读取）：

{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"./src",
"./docs"
],
"env": {}
},
"github": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-github"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
}
},
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
],
"env": {}
},
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres"
],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:password@localhost:5432/mydb"
}
},
"puppeteer": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-puppeteer"
],
"env": {}
},
"memory": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-memory"
],
"env": {}
}
}
}

2.3 安全提示：Token与密码管理

问题

直接把GitHub Token和数据库密码写进 .mcp.json，一旦提交到Git就暴露了。

解决方案

永远不要把Token和密码直接写进配置文件！使用环境变量引用或 .env 文件：

{
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}

并确保 .env 和 .mcp.json 都加入了 .gitignore：

# .gitignore
.env
.mcp.json

三、场景1：filesystem——让AI读写项目文件

3.1 问题现象：没有MCP时AI只能"建议"

你有一批老项目的配置文件需要批量修改（比如把所有 .env 文件里的 API_VERSION=v1 改成 API_VERSION=v2）。

没有filesystem MCP时，Claude Code只能输出建议命令：

# Claude Code建议你手动执行的命令
sed -i 's/API_VERSION=v1/API_VERSION=v2/g' **/.env

AI只能"建议"，你得手动复制到终端执行。

3.2 有MCP后的效果

有了filesystem MCP后，Claude Code可以直接操作文件：

你：修改所有.env文件中的API_VERSION，从v1改为v2

Claude Code：
✅ 读取了 5 个 .env 文件
✅ 在 3 个文件中找到 API_VERSION=v1
✅ 已将值修改为 API_VERSION=v2
✅ 修改后的文件：
– src/config/.env
– src/modules/auth/.env
– tests/.env

AI直接完成了操作，不需要你动手。

3.3 避坑1：目录权限配置不当

问题现象

filesystem MCP默认允许AI访问配置中指定的所有目录。如果把根目录 / 也开放了，AI可以读取和修改系统中的任何文件。

错误配置 vs 正确配置

// ❌ 错误配置——允许访问整个根目录，风险极高
{
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/"
]
}

// ✅ 正确配置——只允许访问项目相关目录
{
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"./src",
"./docs",
"./config"
]
}

反思

权限边界是MCP安全的第一道防线。filesystem MCP没有细粒度的读写分离（只能整体授权），所以目录范围越窄越安全。

3.4 避坑2：AI会顺手改不该改的文件

问题现象

filesystem给了AI读写权限，但它不会自动区分"该改的"和"不该改的"。有一次让它整理代码，结果它把 .gitignore 也改了——把 node_modules 从忽略列表里删掉了！

解决方案

在指令中明确约束操作范围：

你：修改所有.env文件中的API_VERSION，从v1改为v2。
⚠️ 只修改 .env 文件，不要修改任何其他文件类型。

反思

给AI指令就像写法律文书——你遗漏的约束，就是AI越界的空间。 每次涉及文件操作，都要明确声明"只做什么"和"不做什么"。

3.5 效果评分

四、场景2：github——让AI管理仓库Issue与PR

4.1 问题现象：没有MCP时AI只能给链接

你有一个开源项目，积压了30+个Issue和5个待审PR，手动处理太耗时。

没有github MCP时：

你：帮我看看仓库有哪些未解决的Issue

Claude Code：建议你访问 https://github.com/your-repo/issues 查看。
或者使用 gh issue list 命令查询。

又是"建议"，不是"执行"。

4.2 有MCP后的效果

有了github MCP后，Claude Code可以直接调用GitHub API：

你：分析所有未解决的Issue，按优先级分类，并给出处理建议

Claude Code：
✅ 查询到 32 个未解决Issue
✅ 分类结果：
– 🔴 高优先级（Bug）: 8个
→ #127: 登录接口返回500 — 建议优先修复
→ #98: 数据导出格式错误 — 用户反馈最多的Bug
– 🟡 中优先级（Feature）: 15个
– 🟢 低优先级（Docs）: 9个
✅ 已为前3个高优先级Issue添加了标签和分配建议

AI不只是查了Issue，还自动做了分类、标注、分配建议。

4.3 避坑1：Token权限过大

问题现象

使用了Admin级别的GitHub Token后，Claude Code直接删除了一个仓库标签——它觉得"这个标签多余"。

解决方案

改用只读+Issue管理权限的Token，AI只能读取和修改Issue，无法删除仓库资源。GitHub Token权限配置建议：

所需最小权限：
– issues:read+write （读写Issue）
– pull_requests:read （只读PR）
– ❌ 不要给 delete 权限
– ❌ 不要给 repo:admin 权限

反思

MCP给AI的能力越强，权限控制的门槛就必须越高。 github MCP的权限管理依赖GitHub Token本身的能力范围——Token权限就是AI权限的边界。

4.4 避坑2：PR审查的假深度

问题现象

Claude Code通过github MCP审查PR时，能读取diff内容，但审查结果偏向代码风格和安全性，对业务逻辑的审查很弱：

Claude Code审查PR #42的输出：
✅ 无明显安全风险
✅ 代码风格符合项目规范
⚠️ 建议：变量名 `d` 可改为更具描述性的名称

实际遗漏的问题：
❌ 这个PR的排序逻辑有Bug——在大数据量下会丢失最后10条记录
❌ 缺少对空数组的边界处理

反思

github MCP适合做Issue管理和基础PR审查，但绝不能替代人类对业务逻辑的审查。 AI看代码就像实习生看代码——语法问题能发现，但业务意图的理解远不如人类。

4.5 效果评分

五、场景3：playwright——让AI做浏览器自动化

5.1 问题现象：没有MCP时AI只能输出代码

你需要对一个Web应用做E2E测试——登录、填写表单、提交、验证结果。

没有playwright MCP时，Claude Code只能输出一段测试代码：

import { test, expect } from '@playwright/test';

test('登录测试', async ({ page }) => {
await page.goto('http://localhost:3000/login');
await page.fill('#username', 'admin');
await page.fill('#password', '123456');
await page.click('.btn-login');
await expect(page).toHaveURL('/dashboard');
});

看起来不错，但你得自己安装依赖、自己跑命令、自己看结果。

5.2 有MCP后的效果

有了playwright MCP后，Claude Code直接打开浏览器执行操作：

你：测试登录功能——输入用户名admin、密码123456，提交后验证是否跳转到仪表盘页面

Claude Code：
✅ 打开浏览器，导航到 http://localhost:3000/login
✅ 在用户名输入框填入 "admin"
✅ 在密码输入框填入 "123456"
✅ 点击"登录"按钮
✅ 等待页面跳转……
✅ 验证结果：成功跳转到 /dashboard
✅ 当前URL：http://localhost:3000/dashboard
✅ 页面标题包含"仪表盘"
📸 已截图保存到 ./test-results/login-success.png

AI自己打开了浏览器，自己执行了操作，自己验证了结果。 你什么都不用做。

这个场景是实测中体验最震撼的——AI真的在浏览器里"干活"了。

5.3 避坑1：首次启动浏览器很慢

问题现象

首次启动时，Playwright需要下载浏览器内核，耗时约2-3分钟。如果在Claude Code对话中首次使用，AI会"等不及"而报错。

解决方案

提前安装浏览器内核：

npx playwright install chromium

反思

MCP Server的依赖安装应该在对话开始前完成，而不是等AI自己装。 AI没有耐心等3分钟的安装过程——它会超时报错。

5.4 避坑2：动态页面元素识别不稳定

问题现象

对于使用了大量动态渲染（React/Vue）的页面，AI有时找不到元素，因为DOM结构在渲染前后变化很大。Playwright MCP返回：“找不到指定的元素”。

解决方案

在指令中给出更明确的定位信息：

你：测试登录功能
页面URL：http://localhost:3000/login
用户名输入框：id="username"
密码输入框：id="password"
登录按钮：class="btn-login"

反思

动态页面的元素定位必须依赖稳定的属性（id、data-testid），而不是易变的class名或DOM结构。 这是Playwright测试的最佳实践，对MCP同样适用。

5.5 效果评分

六、场景4：postgres——让AI直接操作数据库

6.1 问题现象：传统方式查数据有多繁琐

你需要分析数据库中的慢查询、优化表结构、检查数据一致性。传统流程：打开数据库客户端 → 写SQL → 执行 → 复制结果 → 分析 → 再写SQL……至少5步手动操作。

6.2 有MCP后的效果

有了postgres MCP后，一次对话直接拿到结果：

你：查一下过去7天的订单总量，按日分组

Claude Code：
✅ 执行SQL查询
✅ 结果如下：

SELECT DATE(created_at) AS day, COUNT(*) AS total
FROM orders
WHERE created_at >= NOW() – INTERVAL '7 days'
GROUP BY DATE(created_at)
ORDER BY day;

AI直接查询了数据库并返回了结果。 不需要你写SQL，不需要你登录数据库客户端。

6.3 避坑1：最危险的MCP——AI可能删库

问题现象

postgres MCP给了AI直接执行SQL的能力。如果没有权限控制，AI可以执行破坏性操作：

DROP TABLE orders; — 删表
UPDATE orders SET status = 0 WHERE 1=1; — 全表覆盖
INSERT INTO orders VALUES (...); — 注入虚假数据

解决方案

必须配置只读模式——AI只能查询，不能修改：

{
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres"
],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://readonly_user:pass@localhost:5432/mydb",
"ALLOWED_OPERATIONS": "SELECT,EXPLAIN"
}
}
}

关键措施：

反思

postgres MCP是6个Server中最危险的。 数据库操作不可逆，删库比删代码严重100倍。权限控制必须在两个层面同时做：MCP配置层面（ALLOWED_OPERATIONS）+数据库层面（用户权限）。

6.4 避坑2：AI生成的SQL不一定最优

问题现象

Claude Code通过postgres MCP执行SQL时，生成的查询语句语法正确，但不一定性能最优：

— ❌ Claude Code生成的查询（全字段+无限制，大表直接OOM）
SELECT * FROM orders WHERE user_id = 123;

— ✅ 更优的写法（指定字段+加LIMIT）
SELECT id, amount, status FROM orders
WHERE user_id = 123
LIMIT 100;

对于大表（百万级以上），AI的"SELECT *"会导致严重的性能问题。

解决方案

在指令中明确约束SQL行为：

你：查询用户123的订单数据
⚠️ 只返回id、amount、status三个字段
⚠️ 最多返回100条记录
⚠️ 不要使用 SELECT *

反思

AI不懂你的数据规模。 它生成SQL时不会考虑百万级大表的性能问题，除非你明确告知。指令中的约束条件，就是AI的性能边界。

6.5 效果评分

七、场景5：puppeteer——网页抓取与性能分析

7.1 问题现象：手动抓数据的低效循环

你需要抓取一个第三方网站的数据（比如竞品的价格信息），并分析页面加载性能。传统流程：打开浏览器 → 手动复制数据 → 整理成表格 → 写进文件……至少4步手动操作，而且数据容易出错。

7.2 有MCP后的效果

有了puppeteer MCP后，一次对话完成抓取：

你：打开 https://competitor-site.com/products，抓取前10个商品的名称和价格

Claude Code：
✅ 打开Chrome浏览器
✅ 导航到目标页面
✅ 等待页面加载完成（2.3秒）
✅ 提取商品数据
✅ 数据已保存到 ./data/competitor-prices.json

保存的JSON数据格式：

[
{
"name": "Wireless Earbuds",
"price": "¥299"
},
{
"name": "Smart Watch Pro",
"price": "¥1,599"
}
]

7.3 避坑1：puppeteer和playwright功能重叠

问题现象

两个浏览器MCP功能高度重叠，同时安装时Claude Code会混淆调用——有时用playwright，有时用puppeteer，行为不一致。

对比分析

解决方案

日常E2E测试用playwright，需要Chrome DevTools性能分析时用puppeteer。不要同时装两个。

如果确实需要两者功能，可以在不同项目中分别配置，而不是在同一个 .mcp.json 里同时启用。

反思

工具重叠是MCP生态的现阶段问题——同一个领域有多个Server，但AI没有能力自动选择最优方案。开发者必须做取舍，不能贪多。

7.4 避坑2：反爬机制导致抓取失败

问题现象

对于有反爬措施的网站（验证码、登录墙、IP限制），puppeteer MCP直接访问会被拦截，返回空数据或验证码页面。

解决方案

在指令中提供已登录的Cookie或使用代理：

你：抓取商品数据
⚠️ 页面需要登录，请在浏览器中先手动登录
Cookie：session_id=abc123

如果需要更复杂的反爬绕过，可以结合playwright MCP编写自定义脚本：

// 使用playwright MCP执行带Cookie的抓取
const browser = await chromium.launch();
const context = await browser.newContext({
extraHTTPHeaders: { 'Cookie': 'session_id=abc123' }
});
const page = await context.newPage();
await page.goto('https://competitor-site.com/products');
const products = await page.$$eval('.product-item', (items) => {
return items.map(item => ({
name: item.querySelector('.name').textContent,
price: item.querySelector('.price').textContent
}));
});

反思

MCP无法自动绕过安全机制——这既是限制，也是保护。 如果AI能自动破解验证码和登录墙，那安全风险远大于便利。

7.5 效果评分

八、场景6：memory——让AI记住你说过的话

8.1 问题现象：AI的"失忆"折磨

你在和Claude Code的长对话中反复提到项目规范（比如"我们用React+TypeScript，组件命名用PascalCase"），但每次新对话AI都忘得一干二净。每次新对话，你都得重新告诉AI：

• 项目技术栈
• 代码风格规范
• 目录结构约定
• 常用命令

8.2 有MCP后的效果

有了memory MCP后，可以持久保存项目规范：

你：记住以下项目规范：
1. 技术栈：React + TypeScript + Express
2. 组件命名：PascalCase
3. API路径：/api/v1/{module}/{action}
4. 数据库：PostgreSQL，ORM用Prisma

Claude Code：
✅ 已保存到知识库：
– 项目技术栈：React + TypeScript + Express
– 组件命名规范：PascalCase
– API路径规范：/api/v1/{module}/{action}
– 数据库配置：PostgreSQL + Prisma

下次对话时，AI会自动遵循记忆的规范生成代码：

import { useEffect, useState } from 'react';
import { User } from '@prisma/client'; // Prisma生成的类型

export default function UserList() {
const [users, setUsers] = useState<User[]>([]);

useEffect(() => {
// API路径遵循规范：/api/v1/{module}/{action}
fetch('/api/v1/users/list')
.then(res => res.json())
.then(data => setUsers(data));
}, []);

return (
<div>
{users.map(user => (
<div key={user.id}>{user.name}</div>
))}
</div>
);
}

AI真的"记住"了你的规范，并在后续代码中自动遵循。 组件命名用了PascalCase（UserList），API路径用了 /api/v1/users/list，数据类型用了Prisma生成的 User。

8.3 避坑1：知识库会膨胀与冲突

问题现象

如果不断往memory里塞信息，AI的检索会越来越慢，而且旧信息和新信息可能冲突：

知识库内容（第1天写入）：
组件命名用 camelCase

知识库内容（第5天写入）：
组件命名用 PascalCase

AI调用时：不确定应该用哪个规范……

解决方案

定期清理，只保留关键规范：

你：清理知识库，只保留以下核心规范：
1. 技术栈
2. 命名规范（以最新版本为准，删除旧版本）
3. API规范
删除所有其他已过时的条目。

反思

知识库和代码库一样需要维护。 不清理的知识库比没有知识库更危险——因为AI会基于过时信息做出错误决策。

8.4 避坑2：本地JSON存储不够健壮

问题现象

memory MCP的存储是本地JSON文件，这意味着：

• 重启后会丢失（除非文件路径固定）
• 不支持复杂查询
• 存储上限约100KB

对于大型项目的规范管理，memory MCP不够用。

解决方案

配合filesystem MCP，把规范写成 .md 文件持久存储：

<!– project-rules.md –>

## 项目规范

### 技术栈
– React + TypeScript + Express
– PostgreSQL + Prisma ORM

### 命名规范
– 组件：PascalCase
– 函数：camelCase
– 常量：UPPER_SNAKE_CASE

### API规范
– 路径格式：/api/v1/{module}/{action}
– 响应格式：{ code: number, data: T, message: string }

反思

memory MCP适合存"轻量且频繁变更"的短期信息，不适合存"重量且长期有效"的规范。 长期规范应该用文件持久化（filesystem MCP），短期记忆用memory MCP——两者互补而非替代。

8.5 效果评分

九、6个MCP Server综合对比

一张表看清谁真干活：

十、终极避坑清单：7条铁律

十一、MCP的真实定位与展望

11.1 MCP不能做的

• ❌ 替代人类对业务逻辑的判断（AI审查PR还是浮于表面）
• ❌ 自动绕过安全机制（反爬、权限墙）
• ❌ 处理非结构化的复杂决策（比如"这个架构方案选A还是B")

11.2 MCP真正擅长的

• ✅ 高频重复操作的自动化——文件批量修改、Issue分类、数据查询
• ✅ 跨工具链的串联——一次对话中同时操作文件、数据库、浏览器、GitHub
• ✅ 解放开发者注意力——让你从"执行"层面抽身，专注于"决策"

11.3 MCP的下一步

2026年6月的MCP生态还很早期——可用的Server不多，稳定性参差不齐，安全机制粗糙。但它的方向是对的：

AI不应该只会"说话"，它应该会"做事"。

MCP就是让AI从"对话"走向"行动"的桥梁。这座桥现在还很窄、很险，但每一天都在变宽。

2026年的开发者，不应该只是"和AI聊天的人"，而应该成为"指挥AI干活的人"。

MCP给了你这个可能性。剩下的，看你怎么用。

写在最后：这篇文章不是MCP的安装教程（那种文章CSDN已经够多了），而是实测报告。6个场景、6个MCP Server、6组避坑记录——希望帮你在"装完MCP之后"真正用起来，而不是装完就搁着。工具的价值从来不在安装，而在使用。