企业官网建设流程全解析

最近后台私信被同一个问题刷屏了：Cursor 接了 MCP 之后，到底怎么才能不白配？老实说，我前后折腾了大概一周，把远程 MCP、本地 MCP、常见 server 全试了一遍。今天干脆把从配置到真正好用的完整路径写出来，包含每一步的踩坑记录。这篇文章会讲清楚 MCP 是什么、在 Cursor 里怎么配置、配完怎么调教，以及我遇到过的几个典型问题。适合刚接触 Cursor 的新手，也适合配好了但觉得 AI 帮不上忙的人。

先说结论：配置 MCP 可能只要十分钟，但让它真正“好用”取决于你对它的定位和约束。如果你只是觉得“接上 MCP 就万事大吉”，那大概率会失望。下面我按自己的实际操作顺序来拆解。

1. 先搞明白：MCP 到底是什么，以及它解决什么问题

1.1 MCP 协议的设计初衷与核心逻辑

MCP 全称 Model Context Protocol，也就是“模型上下文协议”。它是 Anthropic 在 2024 年底提出的一种开放协议，目标是要做成 AI 应用连接外部工具和数据源的“标准插口”。你可以把它想象成 AI 世界的 USB-C：以前每个外设都要自己的线，现在大家统一一个接口，插上就能用。

MCP 的架构其实很简单，三个角色：

• MCP Host：也就是 Cursor 这类客户端，负责和用户交互、调用工具。
• MCP Client：内嵌在 Host 里的连接组件，负责和 Server 通信。
• MCP Server：外部工具或数据服务的适配层，把数据库、浏览器、测试工具等能力暴露给 AI。

Server 会暴露三类东西：工具（Tools）、资源（Resources）和提示词（Prompts）。Cursor 里最常用的是 Tools，它让你的 AI 不只能“说”，还能“做”。比如让它真的去查数据库、真的去打开浏览器看看页面、真的去调用接口。

传输方式也不一样。本地 server 通常用 stdio，也就是标准输入输出，Cursor 帮你把进程拉起来，两边通过管道通信。远程 server 则走 http、sse 或者 wss 这类网络协议，适合部署在服务器上的服务。

1.2 Cursor 接入 MCP 能解决哪些实际问题

没有接 MCP 的时候，Cursor 里的 AI 是个只能写代码的“顾问”。你让它“检查一下这个接口返回为什么不对”，它只能靠读代码猜，或者让你把日志贴给它。接上 MCP 之后，它可以自己请求接口、自己查数据库、自己打开页面验证，再基于真实结果给你结论。

我实际用下来，觉得这些场景最值得接：

• 数据库操作：AI 直接查询表结构、执行 SQL、分析慢查询。
• 浏览器自动化：AI 打开本地页面，点击、截图、读控制台报错。
• 接口调试：AI 直接发起 HTTP 请求，帮你验证参数和返回。
• 安全分析：授权范围内，AI 辅助梳理请求链路、生成测试用例。
• 文件与代码仓操作：AI 直接读写文件、处理 Git 状态。

当然也要泼一盆冷水：MCP 解决的是“能力边界”问题，不是“理解能力”问题。工具接得再多，如果你不会给 AI 设定清晰的任务和上下文，它一样会跑偏。所以这篇文章后半部分，我会重点讲怎么设计使用方式，而不是一味堆配置。

2. 配置前的准备：版本、入口与本地环境

2.1 确认 Cursor 版本与 MCP 配置入口

Cursor 的 MCP 配置入口在不同版本里位置略有差异。目前主流的配置方式有三种：

• 项目级配置：在项目根目录创建.cursor/mcp.json，这个文件里的 server 只有打开这个项目时才会加载。
• 全局配置：在 Cursor 设置面板中进入 MCP 页面，添加的 server 对所有项目生效。
• 命令行管理：新版 Cursor 支持通过终端执行cursor mcp add、cursor mcp list等命令来管理。

我推荐的方式是：通用工具用全局配置，项目相关工具用项目级配置。比如 Playwright 这种测试工具，我会放在项目级，因为不同项目需要的浏览器行为不一样。而像数据库这种基础服务，我通常放到全局配置里，省得每次新建项目都要重新填。

先检查一下版本：打开 Cursor 的 Settings，在 About 里确认是否支持 MCP 管理界面。如果你当前版本太老，可以直接去官网下载最新版，装好重启一遍。

2.2 本地工具链准备：Node.js、Git 与依赖安装

大部分本地 MCP server 都是用 npm 包发布的，运行时依赖 Node.js。所以第一步检查基础环境：

Windows 下打开命令行，macOS 和 Linux 打开终端，依次执行下面三条命令：

node -v npm -v git --version

如果没有 Node.js，去官网下载 LTS 版本安装。安装完成后重新打开终端再验证一次。Git 同理，没有的话直接下载安装包，装完把全局 user.name 和 user.email 配好，否则后面有些依赖 Git 操作的 MCP server 会报错：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

npm 在国内网络环境下经常遇到安装超时，建议先把 registry 切到国内镜像源，这一步能省掉很多折腾：

npm config set registry https://registry.npmmirror.com

切完之后再装依赖，速度会明显提升。另外，本地 MCP server 启动时会调用 npx，而 npx 属于 Node.js 自带工具，所以 Node 版本别太老，建议至少 18 以上。

3. 手把手配置：远程 MCP 与本地 MCP 实战

3.1 远程 MCP Server 配置：以标准 URL 方式接入

远程 MCP server 适合那些已经部署在服务器上的服务，你只需要拿到一个地址和凭证就能接入。常见的地址形式有两种：一种是以https://开头的标准 HTTP 接口，另一种是以wss://开头的 WebSocket 接口。

以wss为例，这类地址长这样：

wss://api.example.com/mcp/?token=你的访问令牌

在 Cursor 里的配置步骤如下：

1. 打开 Settings，进入 MCP 页面，点击添加。
2. 选择一个标识名，比如my-server。
3. 输入类型选remote，填入上面的 URL。
4. 如果服务要求鉴权，在 Header 里加上Authorization或者token，具体看服务文档。
5. 保存后点击刷新，如果状态变成绿色就说明连接成功。

对应的mcp.json文件内容是这样：

{ "mcpServers": { "my-server": { "url": "wss://api.example.com/mcp/?token=你的访问令牌" } } }

需要带 Header 的话，写成这样：

{ "mcpServers": { "my-server": { "url": "https://api.example.com/mcp", "headers": { "Authorization": "Bearer 你的令牌" } } } }

这里有几个容易踩的坑。首先是 URL 里的 token，如果你用的是?token=这种形式，Cursor 连接时会把完整 URL 当连接地址，有些服务端解析 query 参数时会对特殊字符敏感，最好确认一下服务方给的示例格式。其次是wss和https的区别，wss是长连接，适合需要服务端主动推送的场景，而https是短连接，适合请求-响应模式。配置之前先搞清楚服务用的是哪一种，填错了会一直连接失败。

远程 MCP 的 token 一定要保管好。这类 token 通常代表了某个账号的访问权限，一旦泄露，别人就可以调用你的服务资源。我之前吃过一次亏，把 token 带 URL 直接贴在了测试文件里，后来忘了删，差点被提交到仓库。现在我的习惯是：所有 token 一律放在环境变量或者 Cursor 的全局配置里，项目配置文件中只写引用名称。

3.2 本地 MCP Server 配置：以 Playwright MCP 为例

本地 MCP server 是另一个大头。它的特点是不需要网络，直接由 Cursor 拉起进程来运行。最常见的方式是通过 npx 启动 npm 包。

我拿 Playwright MCP 举例，这是微软官方的浏览器自动化工具，AI 能通过它打开浏览器、操作页面、截图、提取 DOM 信息。对于前端调试和端到端测试来说非常实用。

配置方式，在.cursor/mcp.json里加上：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

保存后回到 Cursor 的 MCP 面板，点击刷新。如果列表里出现了playwright且状态为绿色，说明进程已经拉起来了。

第一次运行的时候，npx 会自动下载包，时间长短看网速。如果卡住，多半是网络问题，把 registry 切到镜像源再试。另外，npx 启动的进程默认没有浏览器驱动，如果后面 AI 报“无法启动浏览器”，需要在终端里先执行一次：

npx playwright install chromium

这个步骤会下载 Chromium 内核，差不多几百 MB，耐心等它跑完。

本地 MCP 有个特性需要注意：进程生命周期由 Cursor 管理。如果 Cursor 重启，或者你把配置改动后重新加载，旧的连接会断掉，AI 上下文里的工具状态也会丢失。所以改动配置后，建议新开一个对话再继续，否则 AI 可能还拿旧状态跟你说话，产生幻觉。

3.3 顺手优化基础环境：中文界面、Git 与 Node 版本

既然聊到了配置，顺便把几个高频问题一起解决掉。

第一个是中文设置。Cursor 的界面语言默认跟随系统，如果想手动改成中文，在 Settings 里搜索 language 或者 locale，把界面语言切换到中文（简体）。如果你想要的是让 AI“用中文回复”，那跟界面语言是两回事，需要在全局规则里写明“始终使用中文回答”，或者直接在当前对话里说清楚。

第二个是 Node 版本管理。不同 MCP server 对 Node 版本要求不同，长期用下来最容易出现的状况就是：某个 server 在 Node 20 上运行正常，在 Node 22 上报错。我建议安装 nvm 这类版本管理工具，按项目切换版本。本地开发目录里放一个.nvmrc文件，写上推荐的版本号，切目录时顺手执行nvm use就完事。

第三个是 Git 配置。很多 MCP server 有操作 Git 仓库的能力，比如自动提交、查看 diff、管理分支。这些功能依赖 Git 的全局配置。没配 user.name 和 user.email 也别指望这些 server 正常干活。

4. 从“能连上”到“好用”：场景化配置实战

4.1 数据库操作场景：让 AI 直接查询表结构和执行 SQL

数据库接入是我用下来收益最高的场景之一。以往排查问题，要先打开数据库客户端、手动敲查询、再对着结果对比代码。现在 AI 可以直接查询，我只需要描述问题就行。

常见的 MySQL MCP server，配置大致如下：

{ "mcpServers": { "mysql": { "command": "npx", "args": ["-y", "@benborla/mcp-server-mysql"], "env": { "MYSQL_HOST": "127.0.0.1", "MYSQL_PORT": "3306", "MYSQL_USER": "root", "MYSQL_PASSWORD": "你的密码", "MYSQL_DATABASE": "你的库名" } } } }

配置里通过env字段传入数据库连接信息，server 启动时会自动读取环境变量。保存刷新后，AI 就获得了访问这个库的能力。

在对话里，你可以直接说：“查看 users 表的结构，找出最近一周注册人数最多的省份”。AI 会自己生成 SQL、执行、返回结果给你。我可以负责任地说，这一步的体验非常震撼，相当于把一个只会写代码的助手变成了会查数、能分析的数据分析师。

但这背后有一个非常关键的隐患：权限控制。MCP server 连接数据库时，用的是你配置里的账号。如果这个账号有写权限，AI 就可能执行 DELETE 或者 UPDATE 操作。AI 严格按照你的指令行事，但它对“代价”没有概念。我强烈建议给 MCP 专用的数据库账号开只读权限，或者至少限定只允许访问特定库和特定表。开发环境可以放开，生产环境打死也别用高权限账号接入。

另外一个问题是敏感配置的存放。数据库密码写在 mcp.json 里，跟源码放在一起，如果仓库是公开的，等于把自己的数据库裸奔。我的做法是把mcp.json加入.gitignore，然后在本地用一个不被提交的文件去维护真实配置。具体到 Cursor，我还会借助它的环境变量加载能力，从系统的.env文件里读取数据库连接参数，避免明文出现在项目文件里。

4.2 浏览器自动化与网页测试：Playwright MCP 的进阶用法

接上 Playwright MCP 之后，AI 就不再是“纸上谈兵”了。它可以打开浏览器，模拟用户点击，填写表单，读取页面报错。我经常用它来做本地页面的冒烟测试：改完前端代码，直接让 AI 打开页面操作一遍，把控制台报错带回来。

进阶用法有几个：

• 截图对比：让 AI 截取页面关键区域，对比改版前后的视觉变化。
• 控制台日志收集：页面运行时报错时，AI 可以读取 Console 面板，帮你定位是哪个请求、哪个脚本出的问题。
• 表单自动化：让 AI 往测试表单里填一批数据，验证前端校验逻辑是否生效。
• 配合流程测试：写一个简单的测试剧本，让 AI 按步骤执行，相当于自动化的 E2E。

需要注意，Playwright MCP 默认会打开有头浏览器，也就是你会看到浏览器窗口弹出来。在无图形界面的服务器上，需要在 args 里加上--headless，启动无头模式。参数示例：

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--headless"] } } }

还有一点值得提：AI 操作浏览器的过程中，浏览器窗口如果被最小化或者遮挡，某些点击操作可能不稳定。我一般会让浏览器窗口保持在前台，或者干脆用无头模式，让 AI 自己跑。跑完之后让它把结果总结成结构化输出，比如操作步骤、失败点、截图路径，方便后续跟进。

4.3 安全测试工具接入：Burp Suite MCP 与授权边界

如果你做 Web 安全测试，Burp Suite 的 MCP 接入应该是近期热度最高的话题之一。思路很简单：把 Burp 的流量、请求、扫描结果暴露给 AI，再由 AI 辅助分析漏洞链路、生成测试用例。

常见做法是在本地起一个 Burp MCP 服务，然后在 Cursor 里以本地 server 的方式接入。启动后，AI 可以获取代理抓到的请求包，分析参数变化，甚至生成绕过测试的 payload 模板，整个工作效率比手动翻 Burp 的界面高很多。

不过这里必须把边界说清楚：这些操作只适用于你自己拥有授权、或者属于授权测试范围的系统。安全测试工具本身没有善恶之分，但使用场景必须守住合规底线。没有授权就测试任何系统都是越界行为，这个没有任何讨论的余地。我在团队里也一直强调，MCP 接入安全工具之后，AI 只是帮你提高分析效率，判断责任始终在人这边。

这类 MCP server 配置方式和前面一样，按照工具文档把 command 和 args 填好就行。过程中如果遇到启动失败，先确认本机是否已经安装 Burp Suite 并打开了相关代理端口，再去检查 MCP 配置里的端口号是否对得上。

5. 踩坑实录：配置反复失败的排查清单

5.1 连不上、没反应：网络与地址问题排查

配置完 MCP 后，最常遇到的状况就是状态一直灰的，或者刷新之后毫无反应。我给自己总结了一套排查顺序：

检查地址本身能否访问。远程 MCP 可以直接在浏览器里打开 URL，如果返回 JSON、或者出现 MCP 相关的协议信息，说明地址基本可用。如果打不开，问题多半不在 Cursor，而在服务端或者网络。

检查协议是否匹配。wss的 server 你硬填https，大概率握手失败。看一下服务端文档，确认它支持的是 WebSocket 还是 HTTP 流。

查看 Cursor 日志。在 Settings 的 MCP 面板里，点击对应 server 的日志按钮，会看到连接过程的详细输出。我遇到过一种情况：连接请求已经发出去了，但服务端一直没回，最后发现是服务端的鉴权中间件在查 token 时把请求卡住了。日志里一般会留下状态码，跟着状态码去查就行。

本地 MCP 连不上，先手动在终端里跑一遍命令。比如配置里的 command 是npx -y @some/mcp-server，那你就在终端里执行一遍同样的命令，看是不是正常启动。如果终端都跑不起来，回到环境问题，补装依赖或者换 Node 版本。

5.2 配置了但工具列表为空：协议版本与工具暴露问题

连接状态是绿色的，但对话里 AI 说“我没有可用工具”，这种情况也遇到过。原因通常是 server 虽然连上了，但它没有暴露任何工具，或者 Cursor 无法识别服务器暴露的工具列表。

排查思路分两步看：

第一步确认 server 是否正常返回工具列表。可以用调试脚本直接请求 MCP 接口，查看响应里的tools数组是不是空的。这一步能定位问题是在服务端还是客户端。

第二步检查 Cursor 的 MCP 版本兼容性。Cursor 对 MCP 协议的支持是逐步完善的，旧版本可能不支持某些字段，导致工具列表读不出来。把 Cursor 升级到最新版，同时确认 server 用的是标准协议实现，一般都能解决。

还有一个经常被忽略的点：本地 server 如果启动了但没有正常注册工具，可能是因为缺少必要的环境变量。比如数据库 MCP，你配置里没给DATABASE_URL，server 会启动成功但什么都不暴露。去看 server 自身的文档，把必填环境变量补全。

5.3 令牌、密钥泄露与提示词泄露风险

聊到安全，必须多说两句。MCP 配置里埋着两类敏感信息：一类是服务访问令牌，比如远程 MCP 的 token；另一类是数据库口令、API Key 这类密钥。

有段时间“cursor 提示词泄露”是个热门话题。本质上是有人把包含系统提示词、敏感规则、密钥信息的文件传到公开仓库，或者截图发到论坛，结果被搜到。MCP 配置文件也有同样的风险。为了不重蹈覆辙，我给自己定了几条规矩：

• .cursor/mcp.json永远加入.gitignore，不随仓库提交。
• 配置里不写真实密钥，一律通过env引用环境变量。
• 远程 MCP 的 token 定期轮换，发现疑似泄露立刻重新生成。
• 提示词和规则文件里不写任何私密信息。
• 涉及安全测试的配置，只放在专用机器上，不带到日常工作环境。

密钥这种东西，没有后悔的机会。泄露之后哪怕你说“只是为了测试”，数据也已经暴露了。所以宁可配置时多花两分钟，也别事后花两天补救。

5.4 多项目之间配置冲突的处理

用久了之后，你可能会在全局和项目两个层面配很多 server。这时有个新坑：全局配置了一个测试工具，项目里又配了一个同名的，结果 Cursor 加载时出现冲突，工具要么重复，要么互相覆盖。

我的处理习惯是：

• 全局只放通用工具，比如数据库、文件系统、Git 操作。
• 项目级放跟当前项目强相关的工具，比如 Playwright、特定框架的调试 server。
• 尽量避免同名配置。不同层级的同名配置，最终以项目级优先，但为了省心还不如换个名字。
• 清理不用的配置。MCP 进程会占用资源，挂着一堆没用到的 server，又慢又容易干扰 AI 的工具选择。

5.5 环境变量与路径问题

最后一个容易被忽略的坑：本地 MCP server 的启动环境。Cursor 启动子进程时，环境变量继承自 Cursor 自己。如果你在终端里配好的PATH、NODE_ENV在 Cursor 里没生效，就会遇到“终端能跑、Cursor 里跑不起来”的情况。

解决办法是在mcp.json里显式指定 env：

{ "mcpServers": { "some-server": { "command": "npx", "args": ["-y", "@someone/mcp-server"], "env": { "PATH": "/usr/local/bin:/usr/bin:/bin", "NODE_ENV": "development" } } } }

如果你装了 nvm 管理的 Node，还要确保 PATH 里指向 nvm 的实际安装目录。或者更省事一点，在配置里用command直接写 npx 的完整路径，彻底避开 PATH 解析问题。

6. 最后分享几点我的使用体会

MCP 配置本身说难不难，说简单也不简单。如果你只跟着文档走，十分钟就能把 server 加上。但“加上”和“好用”之间，距离其实不小。我自己的体会是，真正决定 MCP 价值的是你对 AI 工作流的规划：哪些事情希望它动手做，哪些事情只能让它看，哪些数据能给它，哪些数据必须隔离，这些想清楚之后，MCP 才不是摆设。

我个人建议刚开始接触的朋友不要一次配太多。选一个跟你日常工作贴合的工具，比如数据库或者浏览器自动化，把它用到顺手了，再继续加新的。配置堆得越多，AI 的工具选择就越容易混乱，排查问题也更麻烦。先小范围验证，再逐步扩大，这条路我走下来是最稳的。

最后分享一个小技巧：在 Cursor 的规则文件里，把常用的 MCP 工具用法写清楚，比如“查数据库之前先看表结构，再写 SQL”“浏览器操作失败时先截图再继续”。AI 有这些约束之后，配合 MCP 干活的质量会明显提升，减少很多来回纠正的废话。毕竟接上 MCP，本质上是给 AI 装上手和眼睛，但让它怎么干活，还是你自己说了算。