企业官网建设流程全解析

"MCP（Model Context Protocol，模型上下文协议）大概是这两年 AI 编辑器圈子里最让我觉得"早该有了"的东西。它解决的问题非常直接：你的 AI 编辑器再聪明，默认也只能看到你喂给它的文本，看不到你的 Figma 设计稿、查不到你的数据库，更没法自己去浏览器里点两下按钮。MCP 就是把外部这些工具变成 AI 的"外设"，相当于给编辑器接上了手和眼睛——用标题里的话说，叫"外挂"也不算夸张。

这篇文章不打算讲纯理论，而是把我实际跑通的方案完整分享出来：Figma MCP 怎么接、数据库 MCP 怎么玩、浏览器 MCP 怎么控，以及我在这个过程中踩过的坑和排查思路。如果你在用 Claude Code、Cursor、VS Code Copilot 这类 AI 编辑器，又想让它们不只是"聊天机器"，而是真正能参与设计走查、数据排查和端到端调试，那这篇就是为你准备的。

1. MCP 协议拆解：为什么 AI 编辑器需要一个"万能插座"

1.1 从"聊文本"到"用工具"，MCP 补齐的关键能力

先想一个问题：为什么没有 MCP 之前，AI 编辑器总差点意思？本质原因是模型的输入输出都是文本，它没有"感知"外部世界的能力。你给它看一段 HTML，它能分析；但你想让它"打开本地项目跑一下测试""看看线上页面某个按钮的实际渲染结果"，它就无能为力了——因为它没法执行命令、没法调用接口、没法打开浏览器。

早期大家靠什么解决？插件。GitHub Copilot 有插件，Cursor 也能执行终端命令，但每个功能都要单独做一套集成，而且 AI 需要的是结构化上下文，不是简简单单把数据塞进聊天框。MCP 的出现给了标准答案：把工具能力暴露成一个 AI 可理解和调用的"函数"列表，编辑器作为宿主统一管理这些工具。

说白了，MCP 做的事跟 USB-C 接口有点像——以前每个设备都要自己的充电线，现在统一接口，谁都能插。MCP 就是把 Tool Calling、资源读取、指令模板这些能力统一成一套协议，谁家 AI 都能接。

1.2 三个核心角色：Host、Server、Client

要上手 MCP，脑子里得有这张最简单的地图：MCP Host（宿主）、MCP Server（服务端）、MCP Client（客户端）。Host 就是你的 AI 编辑器，它负责收集用户意图，决定调用哪个工具；Server 是能力的提供方，比如 Figma Server 提供读取设计稿文件的工具、数据库 Server 提供执行 SQL 的工具；Client 则是编辑器内部负责跟 Server 通信的组件，形式上可以是内部集成的 SDK，也可以是命令行包装的传输层。

传输方式最常见的有两种。本地开发默认用 stdio：编辑器起一个子进程，通过标准输入输出跟 MCP Server 通信，简单稳定，不占端口。需要远程共享或者多人协作时用 HTTP/SSE 或 Streamable HTTP：Server 跑在一台机器上，编辑器通过网络调用。我的建议很朴素：自己本机玩，一律 stdio；团队共享再考虑远程部署。

MCP 的能力模型有三个维度：Tools（工具）、Resources（资源）、Prompts（提示模板）。Tools 是最常用的，比如 get_design_tokens 这种函数，AI 看到名字和参数说明就知道怎么调。Resources 可以理解成 Server 暴露的"可读取文件"，比如一个设计稿的 JSON 描述。Prompts 则是预定义的指令模板，相当于官方帮你写好的一段"怎么用我这个 Server"的提示词。理解这三者的区别，排错时会少走很多弯路。

2. 场景规划与工具选型：Figma、数据库、浏览器该接哪个

2.1 三个场景分别解决什么问题

很多人一听说 MCP 很火，就恨不得把所有 Server 全塞进编辑器，结果上下文一长，AI 反而不知道该用哪个工具。我自己的原则是：先想清楚"痛不痛"，再决定"接不接"。

Figma MCP 解决的是设计到代码的鸿沟。以前前端拿到设计稿，纯靠眼睛量间距、猜字号、抠颜色，一个页面下来大半天没了。有了 Figma MCP，AI 可以直接读取图层树、取色、拿布局参数，甚至整节点导出 CSS 变量，相当于把"看图说话"变成"读数据生成代码"。

数据库 MCP 解决的是 AI 对业务数据的"幻觉"问题。你让 AI 写一个订单统计 SQL，它可能一本正经地编一个不存在的字段名。但如果让它先通过 MCP 连接数据库，查看表结构、采样数据，再写 SQL，准确性立刻不一样。更进阶的玩法是让 AI 直接查生产库做排查，比如线上用户反馈某个订单状态不对，你让 AI 自己去库里查这个订单详情的完整流转记录，效率比人肉开 Navicat 高太多。

浏览器 MCP 解决的是端到端的验证问题。AI 改完前端代码，能不能让它自己打开页面、点按钮、填表单、看 console 报错？Playwright MCP 就是干这个的。它把浏览器自动化能力封装成工具，AI 可以驱动真实浏览器，截图、点击、输入、读取 DOM。调试交互问题的时候，这个能力几乎不可替代。

2.2 常用 MCP Server 清单与选型

先说 Figma 这边，最常用的是官方 Figma MCP（Dev Mode 相关）和社区流行的 figma-developer-mcp。前者适合有 Dev 版权限的团队，后者通用性更好，支持通过 API 读取文件节点、获取图片资源。国内团队常用的蓝湖也有 MCP 方案，如果你项目协作主要靠蓝湖而不是 Figma，可以直接用蓝湖 MCP，思路一样。

数据库这块选择很多。我的推荐排序是：本地开发首选 SQLite MCP（比如 mcp-server-sqlite，零依赖、起个文件就能玩）；生产环境用 Postgres 官方出的 mcp-postgres，支持只读模式，很稳；MySQL 生态里也有不少社区实现，选的时候重点看两件事——支不支持只读连接、能不能限流。数据库这个东西，接错了后果很严重，后面我会单独拿一节讲安全。

浏览器这边我实测下来最好用的是 Playwright MCP（@playwright/mcp）。它封装了 Browser 相关工具，AI 能控制浏览器执行点击、输入、导航、截图等操作，还支持读快照（snapshot）来感知当前页面结构。BurpSuite MCP 之类的属于安全测试方向的延展，普通开发暂时用不上。Blender MCP 这类创意工具的 Server 也很多，说明 MCP 生态正在向各领域扩散，但核心逻辑是一样的：一个 Server 暴露一组工具给 AI 调用。

2.3 我建议的起步架构

如果你是第一次接触 MCP，我建议别贪多，踏踏实实先做三件事。第一，用 Claude Code 或 VS Code Copilot 里已经支持的 MCP 客户端，配置一个 Figma Server，跑通"AI 读取设计稿"这一个场景；第二，加一个本地 SQLite Server，让 AI 查一个小型业务库，观察它怎么拆解问题、怎么调用工具；第三，启动 Playwright MCP，让 AI 打开你自己的本地开发页面，做个简单的冒烟验证。

这三个跑通之后，你会对"AI 与工具协作"的节奏有体感，再决定要不要接更多 Server。我见过不少人上来就配了八个 MCP，结果每次对话光看工具列表就要十几秒，AI 还经常选错工具。MCP 不是多多益善，而是少而精。

3. Figma MCP 接入手记：设计稿到代码骨架的实用流程

3.1 准备工作：API Token 与文件定位

Figma MCP 的接入，本质是让 AI 通过你的 Figma 账号读取设计文件。第一步是在 Figma 的 Account Settings 里生成 Personal Access Token，权限一定要选"Read only"，只读就好，不要让这个 Token 有写权限，免得被误调用。生成之后存进环境变量 FIGMA_API_KEY。

接下来要拿到设计文件的 file key。打开 Figma 文件，看浏览器地址栏，比如 figma.com/file/abc123xyz/项目名 中间那段 abc123xyz 就是 file key。MCP 的很多工具都要求输入 file key 才能定位文件。

3.2 接入配置全过程

我目前在 Claude Code 里用 figma-developer-mcp，配置很简单。在项目根目录的 .mcp.json 里加一段：

{ "mcpServers": { "figma": { "command": "npx", "args": ["-y", "figma-developer-mcp", "--stdio"], "env": { "FIGMA_API_KEY": "你的只读Token" } } } }

保存后重启编辑器，用 MCP 客户端列表检查连接状态，正常的话会看到一组以 figma_ 开头的工具名，比如 get_figma_file、get_figma_node、get_figma_image。这一步如果失败，八成是环境变量没读到，或者 Node 版本太低，figma-developer-mcp 要求 Node 16 以上，这个我踩过。

另外，很多人在配置时会提到 Figma 汉化插件或者安装字体的问题——这跟 MCP 没直接关系，但我的经验是，开发机上的 Figma 客户端不用汉化，因为 MCP 走的是 API，跟界面语言无关；字体问题则会真实影响截图效果，如果 MCP 导出的渲染图缺字体，建议先在 Figma 里把字体装上再调试。

3.3 实际使用：从设计稿到组件代码

配置完成后的标准流程是这样：我会给 AI 一段指令，比如"读取文件 xxx 中第一个 Frame 的全部图层结构和样式，生成 React 组件代码"。AI 会依次调用 get_figma_file 拿整体结构，再用 get_figma_node 定位到目标 Frame，拿到嵌套矢量、文字节点、填充色、圆角、间距这些原始数据。

实测下来，MCP 返回的数据非常结构化，AI 不需要"看图猜字"，直接就能用。生成 React + Tailwind 组件时，颜色、字号、内外边距都能从数据里精确拿到。对我来说，最实用的场景是生成设计变量表：让 AI 扫描整个设计文件的颜色和字体，自动产出一份 tailwind.config 的扩展内容，以前人工整理要一两个小时，现在几分钟搞定。

3.4 踩坑提示与注意事项

这个方案有几个明显的边界，先说明白免得你走弯路。第一，Figma MCP 的目的是"拿数据"，不是"完美切图"。虽然它能获取节点图片资源，但如果你想要批量的切图导出，直接用 Figma 的"Export"功能更高效，MCP 更适合拿结构和样式生成代码骨架。

第二，嵌套组件的解析复杂性。设计稿里到处都是"原子组件套容器再套最终组件"的情况，MCP 返回的 JSON 会很长。如果 AI 一次性读整个页面，很容易上下文爆炸。我的做法是分步：先读文件大纲，锁定目标 Frame 的 id，再单独读那一个 Frame。这个"先定位再深挖"的策略非常重要。

第三，节点命名规范会直接影响产出质量。如果设计师全用"Frame 238"这种默认名，AI 生成的代码语义就差很多。能推动团队给关键 Frame 起名字的，强烈建议规范化命名，这是花小钱办大事。

4. 数据库 MCP 实战：让 AI 直接查库、分析、写 SQL

4.1 选一个顺手的数据库 MCP Server

数据库 MCP 的选型，我的建议是按项目复杂度来分档。玩具项目、本地调试，用 mcp-server-sqlite 就够了，一个文件搞定；正式项目的 Postgres，直接用官方 mcp-postgres，它支持 read_only 模式；MySQL 场景我试过社区的开源实现，基本能满足查询和 schema 读取，但稳定性和权限控制水平参差，选之前先看看最近一个月的 commit 记录。

4.2 连接配置与最小权限原则

用 mcp-server-postgres 的配置示例如下：

{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "mcp-server-postgres", "postgresql://user:pass@localhost:5432/business_db"] } } }

注意，这个连接串里的用户绝不能是超级管理员。我强烈建议专门创建一个只读账号，只授予 SELECT 权限，生产环境更是如此。这不是技术洁癖，而是逻辑必然：AI 生成 SQL 是有概率出错的，哪怕错误率只有 5%，一旦它有 DELETE 权限，一条烂 SQL 就能把表清空。只读账号让风险从"灾难"降级为"最多查得慢"。

如果业务需要 AI 写变更语句，那就让 AI 生成迁移脚本，人工审核后再执行，不要直接把写权限交给 AI。这也是我在团队里反复强调的底线。

4.3 实战：让 AI 分析业务数据并生成报表代码

我曾经用这套方案做过一次真实的订单数据排查。反馈说某个区域订单价格异常，我在 AI 编辑器里给出一条指令："连接本地的 orders 表，分析最近 7 天成交均价异常的区域。"

AI 的调用链大致是：先列出数据库中的表和字段（list_tables、get_schema），然后写一条聚合 SQL 按区域分组统计，发现异常区域后，再写一条针对该区域的明细查询。整个过程我几乎没动手写 SQL，AI 自己完成 schema 感知、SQL 生成、执行和结果解读。

更有意思的是它还能接着生成可视化代码：查询结果没问题，我让它用 Python 的 pandas 和 matplotlib 生成一个区域成交对比图，它直接就把绘图脚本写出来了。本质上是因为 MCP 给它提供了"真实数据"，它基于真实数据做分析和编码，不再是凭空想象。

4.4 数据库安全注意事项

除了最小权限，还有几个细节值得留意。一是连接池问题：MCP Server 每次工具调用都可能新建连接，高并发场景下要关注数据库连接数上限，必要时让 Server 复用连接池，避免连接风暴。二是超时控制，AI 生成的 SQL 一旦缺乏条件，可能全表扫描好几亿行，我的做法是给工具设置执行超时，比如单条 SQL 最多 5 秒，超时直接终止。三是数据脱敏，涉及用户手机号、身份证这类敏感字段，要么在视图层做脱敏，要么干脆不让 MCP 账号看到这些列。

5. 浏览器 MCP 实战：用 Playwright 让 AI 自己操作网页

5.1 Playwright MCP 是什么

Playwright 大家都不陌生，是一个强大的浏览器自动化框架，支持 Chromium、Firefox、WebKit。Playwright MCP 就是把它封装成了 MCP Server，AI 编辑器可以通过工具调用，操作一个真实浏览器，比如打开页面、点击按钮、输入文本、滚动、截图、读取页面快照。

别看描述简单，这个能力对前端开发的意义很大。以往 AI 改完代码，你要么自己手动刷新页面验证，要么写一堆 E2E 测试脚本。现在让 AI 直接"看"页面实际渲染效果，读取 console 报错，甚至自己点一遍主流程，相当于 AI 有了"眼睛"和"手"。

5.2 启动与配置

启动这个 Server 很简单。前提是你本机已经装了 Node.js 和浏览器（Chrome 或 Edge 都行）。项目目录下执行：

npx @playwright/mcp@latest

默认会以 stdio 模式运行，编辑器接入后就能看到浏览器相关工具。也可以带参数启动：加 --headless 让浏览器无头运行，适合跑自动化任务；加 --browser chrome 指定用哪个浏览器内核。首次运行可能需要安装 Playwright 的浏览器内核，直接执行 npx playwright install chromium 就行。

注意一点，MCP 控制的是"它自己的浏览器实例"，不是跟你日常用的浏览器共用会话。所以登着淘宝的 Cookie 它读不到，需要登录的站点得让 AI 自己走一遍登录流程，或者通过 --profile 指定一个 Chrome 用户目录，复用你的本地登录态。

5.3 三个实战场景：E2E 验证、页面提取、表单调试

先说最常用的场景：本地开发冒烟测试。项目起在 localhost:3000，让 AI"打开首页，截图给我看，然后点击登录按钮，看看有没有报错"。AI 会依次调用 browser_navigate、browser_snapshot、browser_click。我对这个场景最满意的点是，AI 能看到真实渲染结果，不再是盲人摸象。

第二个场景是表单调试。有一次用户反馈注册页面某个校验规则不生效，我让 AI 打开页面、输入不合规的邮箱、点提交，再读取页面上出现的错误提示文本。AI 完整走了一遍，最后定位到是前端正则和接口校验不一致。整个排查过程十分钟不到，以前我得人肉操作，还要反复切换浏览器和控制台。

第三个场景是页面结构化提取。比如把某个页面的表格数据按指定格式导出来。AI 通过 snapshot 拿到页面结构，再调用 JS 执行工具提取数据。这种场景要特别注意目标和边界：只操作你有权限的页面，不做任何越权的数据获取。

5.4 操作细节与限制

Playwright MCP 的几个限制，提前知道能省不少事。第一，AI 在没有"看到"页面快照的情况下，点击操作经常不准，所以要让 AI 养成习惯：每次导航后先 browser_snapshot 获取页面结构，再决定下一步操作。第二，页面加载有延迟，要给 AI 足够的时间等待，必要时明确告诉它"等待 3 秒后再读取结构"。第三，它对 iframe 内的元素操作有一定复杂性，碰到嵌套 iframe 的页面，AI 偶尔会摸不着头脑，这时需要你手动提示一下框架层级。

还有人会问浏览器 MCP 能不能做登录态的自动化入库测试。答案是可以，但务必当心：让 AI 在无人值守的浏览器里跑 SQL 和表单操作，等于把生产库和业务操作都托付给模型判断，风险极大。我的建议是这类场景只用来做测试环境验证，生产环境永远留给人来点按钮。

6. 高频问题排查与三个提效技巧

6.1 问题速查表

我把自己和周围同事踩过的坑汇总了一下，按出现频率排序：

排查的时候有个最笨但最有效的方法：打开 MCP Server 的调试日志。Claude Code 里可以用 --debug 日志模式观察工具调用的输入输出，大多数"AI 为什么这么做"的问题，看日志就明白了。

6.2 三个让效率翻倍的小技巧

第一个技巧是给 MCP 写一份"使用说明"。在项目目录放一个 MCP_CAPABILITY.md，用自然语言写明"这个项目接入了哪些 MCP Server，分别擅长做什么，调用顺序是什么"。AI 每次启动会把这个文件作为上下文，它就不容易乱用工具。这招比反复在对话里解释高效太多。

第二个技巧是让 AI 按顺序调用工具，不要一把抓。比如查数据时，先 get_schema 再 query，不要让它跳步。这本质上是引导模型建立"先感知、再行动、后验证"的工作习惯。

第三个技巧是把常用指令模板化。比如"读取 Figma 文件核心 Frame 并生成组件代码"这种操作，整理成一段标准 prompt 存成编辑器片段，以后一键唤起。MCP 本身的确强大，但真正让它物尽其用的，是你对使用场景的设计和打磨。

最后说一个心态上的建议：MCP 不是银弹，它只是把"AI 能用工具"这件事标准化了。我刚上手那阵子巴不得给所有工具都包一层 MCP，结果效率反而下降。后来收敛到 Figma、数据库、浏览器这三个高频场景，把每个都玩透，才真正感受到"AI 从助手变成协作者"的分水岭。你也不妨从一个小场景开始，先跑通，再扩展，这条路走起来远比想象中快。