企业官网建设流程全解析

上一篇讲MCP在Cursor里的接入方式时，我还专门整理了好几套手动配置模板，从项目根目录写到全局配置，连环境变量怎么塞都标了出来。结果没过多久，我自己就得回来把这篇文章标记成“废弃”。原因不是MCP这个概念出了什么问题，而是Cursor对MCP的支持方式整个换了一套思路：以前那套“自己写配置文件、靠本地脚本起服务、再让AI去连”的玩法，已经被编辑器内置的原生管理面板替代。不光入口变了，排查方式也不一样了，我再拿旧文章对照新版本，只会把读者带进沟里。所以这篇算是一次集中“翻案”：旧方法长什么样、为什么会被弃用、现在在Cursor里到底应该怎么接MCP，以及我迁移过程中实际踩过的几个坑，一并说清楚。

1. 废弃的不是MCP，而是那套手动接线的方式

先说结论：MCP（Model Context Protocol）本身没有过时，它依然是让AI助手连接外部工具和数据源的主流协议。这篇标题里说的“废弃”，指的是我以前教的那套接入手法——在Cursor还只能靠“手动配置文件+命令行启动”的时代，这套手法是唯一解；而现在有了原生支持，这套手法就成了绕远路走窄门，理应淘汰。

1.1 早期在Cursor里接入MCP的几种土办法

在Cursor官方还没把MCP管理面板做完善之前，大家想把AI接到外部工具上，基本只有三种路线。

第一种是项目级配置：在项目根目录建一个.cursor/mcp.json，里面按照MCP服务器的格式写好“启动命令”和“参数”。AI会按这个配置去拉起一个本地子进程，然后通过标准输入输出和这个子进程通信。这种做法的好处是配置跟项目走，团队成员拉下代码就能用；坏处是一旦命令路径不对、npx缓存出问题，或者服务器启动慢于AI的检测时间，就会出现“配置没问题但工具死活看不见”的诡异情况。

第二种是全局配置：把同样的内容写到用户目录下的全局配置文件里，让所有项目共享。好处是一次配置到处用，适合个人常用工具；坏处是项目多了以后很容易互相污染，尤其两个项目用同一个server名字、不同参数时，经常不知道自己连的到底是哪份配置。

第三种是借助第三方启动器：用一些外部的MCP管理器或脚本，把多个server统一拉起，然后给Cursor填一个入口地址。这种方案看上去优雅，但实际维护成本很高，因为第三方启动器的日志和Cursor的设置面板互相看不见，出了问题就是两头摸黑。

这三种方法在当时的背景下的确能用，我也都写过案例。但它们有一个共同的毛病：配置过程和运行状态完全脱节。你是把配置写好了，可Cursor到底有没有成功连上server？工具到底暴露了哪些？调用失败时报的什么错？在旧版本里基本没有可视化反馈，全靠猜。

1.2 这些土办法为什么被官方路径取代

后来Cursor版本迭代，设置里出现了原生的MCP管理入口。你可以在设置面板里直接新增服务器，填一个URL，或者填一条带参数的本地命令；状态列会实时显示“已连接/连接中/失败”；点开还能看到日志输出。与此同时，配置文件的格式也被官方定了型，面板和JSON文件之间可以双向同步。

这一下就把旧方案的痛点全部盖过去了：不再需要你手动确认进程有没有起来，编辑器替你盯着；不再需要你猜服务器有没有注册上，面板直接告诉你状态；启动失败还能看到标准错误输出，排查效率高了一个量级。

我给一个很直白的类比：旧方式相当于你想在手机和电脑之间传文件，自己搭了一个FTP服务器，然后每次传都得先启动服务、记IP、输账号密码。现在系统自带文件共享功能，你点几下就能传，那原来那套自建FTP的操作手册当然就该标“废弃”。不是说FTP不能用了，而是对有原生方案的大多数用户来说，继续折腾它属于重复造轮子。

所以，这篇标题里的“废弃”，精准一点讲，是废弃旧的手动配置、废弃绕路的接入方案。理解这一点很重要，因为网上不少讨论还在拿旧写法教新人，碰到新版Cursor反而让新手一头雾水。我写这篇就是为了把这个版本差填上。

2. 现在的正确操作：原生MCP面板和配置文件

带着“旧方案已淘汰”的认知，下面直接讲新版Cursor里接入MCP的完整操作。我按照当前主流版本的实际界面来描述，如果你的版本跟我不一样，界面文字略有出入，但逻辑都是同一套。

2.1 入口与基本操作流程

MCP的管理入口在设置里的MCP标签页。打开之后你会看到一个服务列表，右侧是“新增”按钮。点击新增时，系统会让你选两种服务器类型。

远程服务器（Remote）：只需要填一个URL，格式通常是HTTP地址，协议可以是配置好的MCP端点类型。适合连接部署在远程的公共服务，比如团队内部已经搭好的知识库检索服务、在线文档工具、数据查询网关等。填完URL，点连接，面板会尝试握手并拉取工具列表。

本地服务器（Local）：需要填“启动命令”和“参数”。比如很多用Node写的工具，命令就是npx，参数就是-y 某个包名。填写区域通常还有“启动方式”的选项，把“自动启动”勾上之后，只要这个server在项目里被用到，Cursor就会自动拉起子进程，不用你每次手动去点启动。

两种方式添加完成之后，列表里每一行会显示状态：connected表示成功，connecting表示正在握手，failed表示启动或连接出错了。状态旁边一般还有一个按钮可以展开日志，这个日志非常关键，后面讲排查时会反复用到。

2.2 mcp.json的字段到底该怎么写

虽然现在有了可视化面板，但配置文件依然存在，而且它才是真正的“事实来源”。面板上做的事情，本质上是在帮你生成和修改这些JSON文件。

常规的配置文件格式长这样：

{ "mcpServers": { "my-local-tools": { "command": "npx", "args": ["-y", "some-mcp-server-package"], "env": { "API_TOKEN": "abc123" } } } }

这份配置要放在哪，取决于你想让它在哪个范围生效：

• 放在项目根目录的.cursor/mcp.json：只对这个项目生效。适合团队共享的服务，比如项目专属文档查询、专用数据库连接等。
• 放在用户目录下的~/.cursor/mcp.json：对所有用这个配置文件的个人项目生效。适合你自己的通用工具，比如浏览器控制、文件转换、代码分析这一类。

里面每个字段的作用，我拆开说明一下：

• mcpServers：最外层容器，表示下面包含一组服务器定义，这个键名是固定的。
• 下一层每个键（比如上面的my-local-tools）就是服务器名称。这个名字会直接出现在AI对话里的工具列表里，所以最好起一眼能认出用途的名字，比如docs-index、db-query。
• command：启动服务器要执行的程序。可以是绝对路径，也可以是像npx、uvx、python这类带扩展命令的程序。
• args：传给启动程序的参数数组。注意是数组，不是字符串，每一项单独一个元素，不要自己拼成一个带空格的字符串，否则参数解析会出问题。
• env：额外传递给子进程的环境变量。比如数据库密码、API密钥等。请不要把这些敏感信息直接写进命令参数里，因为命令会在日志中显示。

我当时第一次在面板上配置完，还以为系统帮我单独存了一份配置文件，后来一查，它改的就是项目里的.cursor/mcp.json。所以你也可以反过来操作：手动写好JSON，回到面板里刷新，系统会按JSON自动生成服务器条目。两条路互通，没有谁比谁更“标准”的说法，只看你用哪种顺手。

2.3 配置完之后的使用入口

服务器连接成功后，工具并不会自动出现在聊天里。你需要让AI主动调用它们。具体机制是这样的：在你跟AI对话时，系统会把已连接的MCP工具描述注入到上下文中，AI判断当前任务需要外部能力时，会自动请求调用。有的界面里，对话框旁边或下方会有一个“工具”列表，展开后可以看到当前可用的MCP工具，也能直接点选，让某个工具始终处于“待命”状态。

这里提醒一句：工具描述写得清不清楚，直接决定AI会不会用它。如果一个工具的描述只是“查询工具”，AI可能完全不知道什么时候该调用；如果描述写成“查询项目源码索引，输入关键词返回文件路径列表”，AI理解起来就精准得多。这个问题不依赖Cursor或MCP本身，而是依赖你选择的MCP服务器有没有给出好的工具描述，属于选择服务器时就需要留意的事。

3. 三种我用下来的真实场景与配置模板

原理讲完，我拿几个自己实际在用的场景举例。这三个场景覆盖了“本地文档”“外部接口”“浏览器操作”三个典型方向，配置模板可以直接抄走微调。

3.1 场景一：让AI直接检索项目内的文档

项目里如果积累了大量Markdown技术文档、需求文档、接口说明，AI默认只会按聊天上下文里的内容来回答，没法主动翻你硬盘上的全部文件。这时接入一个“本地文档检索”类型的MCP服务器，就能让AI以工具调用的方式搜索并阅读项目资料。

配置参考：

{ "mcpServers": { "docs-searcher": { "command": "npx", "args": ["-y", "local-docs-mcp"], "env": { "DOCS_ROOT": "./docs" } } } }

使用中我最大的感受是：这类工具的价值不在“搜索”本身，而在于它可以帮AI一次读取多份文档再归纳答案。以前你要复制粘贴多份文档内容进对话框，现在直接让AI自己去找。但要注意，如果你项目里的文档量很大，搜索工具的返回结果可能只是个文件列表，AI还得靠一个“读文件”的工具去拉具体内容。所以选服务器时，最好选那种同时提供搜索和读取两个方法的，缺一个都会让AI“看得到找不到”。

3.2 场景二：连接数据库或内部API

这是MCP最让我觉得值回票价的使用方式。把数据库查询能力暴露给AI，它就能直接帮你执行查询、分析结果，甚至根据对话上下文自动生成下一步查询。我配过一个读接口，用来查询业务库里的订单摘要，配置大致如下：

{ "mcpServers": { "readonly-db": { "command": "npx", "args": ["-y", "db-reader-mcp"], "env": { "DATABASE_URL": "postgresql://user:pass@host:5432/mydb" } } } }

这里有两点一定要强调：

第一，权限控制是重中之重。MCP本身只是一个通道，工具所属的服务器才是执行方。如果你把一个数据库连接暴露给MCP工具，那这个工具理论上能执行的SQL范围，完全取决于你给它配的数据库账号权限。我强烈建议专门创建一个只读账号，只给SELECT权限，不要直接把生产库的管理员账号或者开发库的写权限账号塞进配置里。AI再聪明也可能构造出你没预料到的查询，别拿生产数据去验证这个边界。

第二，环境变量方式优于硬编码。把数据库连接串写在JSON的env里，比直接写在命令参数里安全，也不容易在日志中被完整打印。但这个JSON文件本身仍然是明文，所以要注意别把它推送到公开仓库。如果项目仓库需要共享配置，聪明的做法是环境变量引用外部配置源，而不是直接在JSON里写明文密码。

3.3 场景三：浏览器自动化与网页信息抓取

这个场景需求往往来自“让AI帮我打开网页看数据”的诉求。接上浏览器控制类的MCP服务器后，AI可以调用打开网页、点击元素、读取页面内容等操作。

配置参考：

{ "mcpServers": { "browser-bot": { "command": "npx", "args": ["-y", "playwright-mcp"], "env": { "HEADLESS": "1" } } } }

这类服务器对命令路径很敏感，npx能不能找到、有没有额外依赖的浏览器运行时，都会影响启动。我第一次配置的时候，其他场景都一遍通过，唯独这个在failed状态卡了很久。后面排查发现是启动路径里用了全局npm目录，但当前运行环境的PATH没包含它，导致进程起不来。后来我改成用环境变量比如BROWSER_PATH显式指定浏览器位置，或者直接在配置里把command写成可执行文件绝对路径，问题才解决。

使用场景上有一个预期管理要做：浏览器自动化不等于AI替你操作一切。它适合结构化页面、有稳定CSS选择器的网站；遇到验证码、复杂拖拽、单页密集动态渲染的网站，成功率会明显下降。当作辅助验证工具可以，别指望它变成一个万能爬虫。

4. 从旧方案迁移时，我踩过的四个坑

从旧的手动配置迁到新面板，理论上只是“复制JSON—粘贴—启动”而已。但实际迁移过程中，我连续踩了好几次坑。这里把排查过程写出来，比直接给“正确配置”更有价值。

4.1 环境变量丢失：旧方案把它藏在了shell里

旧方案里，我习惯把比如DATABASE_URL、API_KEY这类变量直接export在当前终端环境里，然后运行启动命令时，这些变量会自然被子进程继承。当时一切正常。

换了面板的“自动启动”功能之后，问题来了：面板拉起的子进程不是从我的终端继承环境，而是从编辑器进程继承环境。编辑器是图形界面启动的，跟我的终端各有一套环境变量，我在终端里export的东西它根本看不到。结果就是服务器启动成功，但连接数据库时一直报缺配置。

排查思路是这样的：先去看面板里的日志，发现启动命令本身没问题，再想原因。最后我意识到是环境变量继承上下文变了，于是把变量写进mcp.json的env字段，问题立刻解决。

这个坑提醒大家：从旧方案迁到新方案，第一件事就是把所有环境变量从“启动前export”迁移到JSON的env块里。否则你用面板启动时会非常痛苦。

4.2 工具名冲突：同名server让AI“精神分裂”

我同时保留了一个旧的全局配置和新的项目配置，两个配置文件里都定义了同一个名字的server，比如都叫dev-tools。面板列表里看起来有两个同名条目，一个连上了，一个失败了。更麻烦的是，AI在对话里调用工具时，系统可能把两个服务器的同名工具都列举出来，导致AI调用时拿不准到底用哪一个，偶尔还会出现“工具返回格式不对”的报错。

排查到最后，发现不是工具坏了，而是名字撞了。我把旧配置里的server名改成legacy-dev-tools，新配置保留dev-tools，并在面板里禁用旧的，世界立刻清净。

建议：升级到新方式后，旧文件里的server名能不用就别沿用。要么整体删除旧配置，要么重命名避让，别让新旧两代配置并排跑同一个名字。

4.3 启动失败：看面板日志比瞎猜快一百倍

有个server我配置后状态一直显示failed。旧方案的排查套路是：先手动在终端运行一遍命令，看有没有报错；再检查端口是否被占用；再不行就重启编辑器。这套流程在旧方案里是必须的，但放到新方案里，明显绕了。

新版面板已经带了日志查看入口，点开就能看到子进程的stdout和stderr。有一次我手动在终端跑命令是正常的，但面板里一直失败，一查日志才发现是“在非交互模式下，npm脚本需要确认”这一类的提示，不是命令错误，而是环境差异。顺着日志找到了原因，几分钟就解决了，整个过程完全不需要摸到终端。

所以第一个排查动作永远是：点开日志看报错。不要先手动跑命令，那样反而会引入更多变量。

4.4 残留的旧配置文件：删不干净比没配置更麻烦

从旧版本升级上来，最容易忽略的是旧配置文件还在项目根目录甚至上一层目录里存着。新版面板在“自动启动”模式下会尝试加载这些旧文件，于是你可能会看到面板里突然冒出来一串自动识别的server，它们有的能用，有的已经失效。

我的处理方法是：打开每个server的详情，找到它对应的配置文件路径，然后统一把旧格式的文件备份后移走，只留下新版面板生成的配置。这一步做完，面板列表清爽多了，也不会再出现“神秘server自动复活”的问题。

5. 为什么我建议你仍然理解旧机制

看到这里你可能会问：既然新方案这么好，旧方案也被标记废弃了，那为什么还要花功夫去了解那些已经被替换掉的东西？我的答案是：理解旧机制不是为了继续用旧机制，而是为了理解MCP这层协议真正的运行逻辑。

5.1 配置文件本质就是一份协议描述

无论你在面板里点出来的配置，还是手写的JSON，服务器端拿到的其实都是同一份东西：进程怎么启动、参数是什么、环境变量有哪些。所谓可视化配置，只是帮你把这份描述生成出来的工具而已。

MCP协议本身，简单来说就是一套基于JSON-RPC 2.0的远程调用约定。客户端（Cursor）与服务器子进程之间通过标准输入输出来传递请求和响应。请求里写“调用这个工具，参数是这些”，响应里写“结果如下”。所有的工具列表、工具描述、工具返回值，都在这套约定里流转。

当你理解了这一层，就会明白：无论界面怎么变，服务器端始终在等你用正确的方式把“启动进程”这件事描述出来。界面上遇到的bug，本质上是描述生成得不完整或字段不兼容。

5.2 高级调试离不开底层认知

新版面板能帮你解决90%的日常配置问题，但剩下10%的怪问题，最终还是要靠协议层知识来兜底。比如：

• 工具返回格式不规范，AI读不懂结果，这时你需要看工具本身实现的输出结构；
• 工具超时，可能不是网络慢，而是服务器没有实现增量返回，导致请求超过客户端设定的时限；
• 工具描述太笼统，AI不会触发调用，这时候调整的是服务器里的“工具描述”字段，而不是Cursor的配置。

这些都是配置无法解决的。MCP真正的工作单元是“工具”，每个工具相当于一个函数，函数名、入参、出参都得设计得好，AI才用得好。这跟编辑器版本无关，跟你手动还是面板配置也无关。

5.3 换UI是常态，懂协议才不慌

我自己的习惯是：能用原生面板解决的就用原生，不再花时间折腾那些绕路方案。但每当遇到奇怪报错、新版界面大变、或者官方文档突然改了术语，我还是会回到协议层面去想问题：我的模型上下文里注入的是谁？服务器进程起来没有？工具返回符合JSON-RPC规范吗？只要这几个问题有答案，换个UI完全不慌。

所以这篇把“废弃”标出来，并不是让大家都去学“已经被淘汰的手艺”，而是让大家在跑通新方案的同时，知道这底层的道理其实没变过。淘汰的是路径，留下来的是协议思维。

最后一个小提示：如果你身边也有人还在用旧博客、旧帖子里那套手动配置方法配置MCP，可以把这篇转给他看。方案淘汰了，思路还在，但工具已经换代，与其在旧方法里反复试错，不如直接切换去用官方那条路。