企业官网建设流程全解析

1. 为什么要把 Cursor 接到蓝湖上

1.1 先还原一下真实的工作场景

做前端的朋友应该都经历过这个画面：你正埋头写着组件，设计那边突然弹出一条消息——“页面还原得怎么样了？”你赶紧打开线上预览，拿肉眼对着设计稿一顿扫，间距差了两个像素、颜色深了一点、字体大小对不上……于是你默默打开浏览器开发者工具，逐项去改。改完一次，设计师又发来一张新稿，你又得重来一遍。

这个“还原了吗”的追问，本质上是设计稿和代码之间缺少一种自动化的对照方式。设计稿是静态图片加标注，代码是抽象的逻辑实现，两者之间没有一条贯通的通道。每次核对都靠人工肉眼去盯，盯一次五分钟十分钟，一个页面十几个组件，一天下来光是“还原度检查”就能吃掉你半个下午。

我把 Cursor 通过 MCP 接到蓝湖之后，这个流程变成了这样：我只需要让 AI 去蓝湖上读取设计稿的节点参数，再去项目代码里读取对应组件的实现参数，两边的数据直接算出来比对，一份带差异项的还原度报告自动生成。设计师再问我“还原了吗”，我直接把报告甩过去，哪些对齐了、哪些偏离了多少，一目了然。坦白说，这个体验一旦用过，就回不去了。

1.2 MCP 到底是什么

MCP 全称是 Model Context Protocol，中文一般叫“模型上下文协议”。你可以把它理解成 AI 世界的 USB 接口：以前每个 AI 工具要接外部数据源，都得单独开发一套对接方式，相互之间还不能复用；现在统一成一种标准协议，Cursor 作为客户端，蓝湖作为服务端，双方都按这个协议来对话，连接就变得特别简单。

更直白一点说，AI 是大脑，MCP 是给它装上的手脚。没有 MCP 的时候，Cursor 再怎么聪明，也只能在你给它看的代码文件里打转，想获取蓝湖上的设计参数，你只能手动复制粘贴到对话框里。有了 MCP，Cursor 可以直接调用蓝湖暴露出来的工具函数，比如“获取某个设计图的宽高和边距”“读取某个节点的颜色和圆角”，拿到的数据直接参与推理和分析。

我刚开始接触 MCP 的时候也觉得这个名字唬人，但当你真正在 Cursor 的配置面板里添加一个 Server、看到工具列表里冒出一个个可调用的函数时，你会立刻明白它解决的是什么问题——AI 不再是一个孤立的聊天窗口，而是能主动触达你工作流里各种系统的智能体。

1.3 为什么是蓝湖，而不是 Figma、即时设计

蓝湖在国内设计交付链路里的地位，不用我多讲。设计团队用它上传设计图、做标注、出切图、走评审，前端同事在拿到设计稿的同时，也能直接看到每个元素的精确参数。社区里关于 Figma 接 Cursor 的教程也很多，但放到国内团队的实际场景里，蓝湖往往才是那个所有人在用的“公共设施”。

选蓝湖还有几个很实际的理由：第一，蓝湖的标注信息完整度很高，尺寸、间距、颜色、字体、圆角这些都结构化存着，AI 读取起来比从截图里“猜”靠谱得多；第二，国内团队的设计评审和交付流程基本都沉淀在蓝湖上，版本更新、评论记录都在同一个地方，把检查能力接到这里，整个链路是闭环的；第三，蓝湖开放平台的 API 为开发者提供了取数据的入口，MCP Server 本质上是把这套 API 再包装成 AI 能直接调用的工具集，技术路径清晰顺畅。

当然，这个思路绝不局限于蓝湖。Figma 有 Figma 的 MCP 方案，即时设计也有对应的开放能力，原理都是同一个：把设计数据通过标准协议喂给 AI。只不过如果你和我一样，日常就在蓝湖上跟设计师对接，那把它先接通就是性价比最高的一件事。

2. 接线前要准备什么

2.1 Cursor 侧的三件小事

第一件事，把 Cursor 升级到支持 MCP 的版本。MCP 功能从 0.4x 开始逐步开放，现在新版本里已经内置得比较成熟了。如果你是老版本，直接在设置里检查更新，装到最新版再开始。

第二件事，确认你的账号状态。MCP 本身不消耗额外的 API 额度，但整个还原度检查流程要反复读设计稿数据、读代码文件，会占用对话上下文和快速请求额度。免费版也能用，但如果你打算每天都跑这种检查，Pro 版的体验会从容很多。具体额度以你当前套餐的说明为准，不用迷信网上的数字，官方后台写得最清楚。

第三件事，是很多人忽略的 Cursor 中文设置。网上搜“cursor怎么设置中文”的教程一大堆，其实就在 Settings 界面里找到 Appearance 相关的语言选项，切换后重启就好。不过我个人建议不急着改中文界面，因为代码、终端、配置文件里归根到底还是英文环境，早点适应英文界面，后续跟着社区英文教程走反而更顺畅。你可以在界面语言上用中文，但别指望它帮你解决代码命名问题。

2.2 蓝湖侧要拿到的三样东西

蓝湖这边，你需要准备三样东西：一个你有权限的团队/项目空间、一个能访问设计稿的账号凭证、以及一份带有标注信息的设计稿。

账号凭证这一点我要多说一句。正常的人工查看只需要登录蓝湖网页，但程序化访问需要走开放平台的认证机制。你需要在蓝湖开放平台创建一个应用，获取对应的访问凭证（一般是 AppSecret 或 Token 之类的形式），然后把凭证配置给 MCP Server 使用。这一步是很多人卡住的地方，一看到“开放平台”“API”就头大，其实流程就是注册、创建应用、拿到密钥，十分钟之内能搞定。

设计稿这边建议你先建一个专门的“还原度检查测试画板”，把你要接线的那个页面放进去，确认标注信息都已经生成。很多设计稿刚上传时标注数据需要几秒生成，没有标注数据的节点，后面 AI 拿去比对时就会缺参数。拿一份干净完整的稿子起步，能避免你在调试时被各种边界情况干扰。

2.3 官方 MCP 与自建包装器怎么选

先回答一个很多同学搜过的问题：蓝湖 MCP 服务怎么部署？目前市面上有两种走法，一种是直接接入蓝湖官方或开放平台提供的现成 MCP Server 地址，填进 Cursor 就能用；另一种是自己写一个本地 MCP Server，把蓝湖开放 API 包一层 MCP 协议，跑在自己电脑上。

这两种方式各有利弊。官方现成方案的优势是零维护、开箱即用，适合团队统一部署；缺点是目前开放的覆盖范围、工具函数的丰富程度你可能不一定能自定义。自建方案的优点是灵活，你想让 AI 能查到哪个项目的什么数据，全由你自己定义；代价是要装 Python 环境、维护代码，对非技术背景的设计师来说有一定门槛。

以我自己的经验，如果你是个人开发者或者小团队，自建一个轻量本地 Server 是性价比最高的选择。Cursor 跟本地进程通信很顺畅，而且你完全掌控工具函数的边界，不会出现“AI 想读的项目不在 MCP 权限范围”这种尴尬事。后面我会把自建这条路线的完整实操写出来，跟着走就能跑通。

3. 把 Cursor 和蓝湖接起来的完整实操

3.1 方式一：直接接入现成的 MCP Server

如果你在蓝湖开放平台后台看到了 MCP 服务的入口，或者从官方文档里拿到了现成的 Server 地址，那配置过程其实非常简单，本质上就是在 Cursor 里新增一条 MCP 记录。

打开 Cursor 的 MCP 配置面板（命令面板里搜 MCP，或者走 Settings → MCP），点击 Add MCP Server，填入名称和地址。这里最关键的是搞清楚你拿到的地址是哪种连接类型：sse 类型的地址以 /sse 结尾，走的是 Server-Sent Events；streamable-http 类型则是普通的 HTTP 地址。填错类型会导致连接不上。配置完成后，点刷新按钮，如果工具列表里出现了蓝湖相关的函数，就说明接线成功。

注意：拿到官方地址后第一件事不是急着填入 Cursor，而是先确认你的蓝湖访问凭证已经拿到手。很多 MCP Server 的鉴权是在请求里带上 Token 的，你要么把它拼到地址参数里，要么通过环境变量传给 Server，具体要看官方给出的接入文档。凭证都没准备好就去配地址，工具列表大概率是空的。

这一方式的优点是真的省事，适合团队里负责搭环境的人一次性配好，其他人直接复用；但也有个现实问题——目前蓝湖官方 MCP 服务的开放程度每个阶段都在变化，有些功能可能还没铺开。所以我把下面这种“自建包装器”当作主力方案详细讲，因为它不依赖官方 MCP 是否开放，只要蓝湖 API 还开着，你就能自己接。

3.2 方式二：用 Python 自建一个蓝湖 MCP Server

自建 MCP Server 并没有你想象中那么难。核心原理一句话：把你需要蓝湖提供的数据，封装成一个个工具函数，让 Cursor 能像调用本地函数一样调用它们。微软和社区已经提供了成熟的 Python SDK，把复杂度降得很低。

我自己用的是 fastmcp 这个库，它比原生的 MCP SDK 更简洁，几分钟就能写一个能跑的 Server。下面给你一个可以直接参考的骨架，你按自己项目的情况调整函数名和参数就行。需要注意的是，具体的 API 域名和端点路径要以蓝湖开放平台最新文档为准，我代码里用变量代替了，避免你照抄一个过期地址。

# lanhu_mcp_server.py # 依赖安装：pip install fastmcp requests import os import requests from fastmcp import FastMCP mcp = FastMCP("lanhu-bridge") LANHU_API_BASE = os.getenv("LANHU_API_BASE", "https://你的蓝湖API域名") LANHU_TOKEN = os.getenv("LANHU_TOKEN", "你申请的访问凭证") HEADERS = { "Authorization": f"Bearer {LANHU_TOKEN}", "Content-Type": "application/json", } def _request(path: str, params: dict | None = None) -> dict: url = f"{LANHU_API_BASE}{path}" resp = requests.get(url, headers=HEADERS, params=params, timeout=15) resp.raise_for_status() return resp.json() @mcp.tool() def get_project_id(project_name: str) -> dict: """根据项目名称查找蓝湖项目 ID""" projects = _request("/projects", {"name": project_name}) return projects @mcp.tool() def get_design_meta(node_id: str) -> dict: """获取设计稿节点的宽高、背景色、圆角等元信息""" return _request(f"/design/nodes/{node_id}") @mcp.tool() def get_node_spec(node_id: str) -> dict: """获取设计稿节点的标注：间距、字体、字号、行高等""" return _request(f"/design/nodes/{node_id}/spec") if __name__ == "__main__": mcp.run()

这个骨架做了三件事：查项目 ID、拿节点元信息、拿节点标注信息。你会发现每个工具函数都有清晰的 docstring，这一点很重要——Cursor 里的 AI 是会读这些描述来决定什么时候调用哪个函数的，描述写得越具体，AI 判断越准确。比如你在代码里写着get_node_spec(node_id)，AI 看到“获取设计稿节点的标注：间距、字体、字号、行高”，就知道当它需要核对文字样式时该调它。

实际调试时，建议你先在本地跑一遍 Python 脚本，确认能用同样的 Token 和 API 地址从蓝湖取到数据，再启动 MCP Server，这样可以避免把“API 本身调不通”和“MCP 配置有问题”混在一起排查。我第一次接线就是没做这步，配了半天 Cursor，结果发现是 Token 少了一位。

3.3 在 Cursor 里添加并验证 MCP Server

自建 Server 写完之后，启动方式要看你使用的连接类型。最省事的做法是走标准输入输出通道（stdio），也就是让 Cursor 直接拉起你的 Python 脚本，通过命令行和它通信。这样不用管端口和网络，是个人单机使用的首选。

在 Cursor 的 MCP 面板里，Add MCP Server 时选择 command 类型，填入启动命令。如果你用 uv 管理 Python 环境，可以写成uv run python lanhu_mcp_server.py；如果用系统 Python，就用python /绝对路径/lanhu_mcp_server.py。这里我强烈建议填绝对路径，不要用相对路径，否则 Cursor 的工作目录一变，就找不到你的脚本了。

填好之后，参考一下这个类型对比表，看看自己该选哪种连接方式：

提示：配置完成后，如果工具列表一直是空白的，可以先看 Cursor 右下角的 Server 状态是不是显示为“已连接”。如果显示连接成功但工具列表为空，多半是 Server 那边的工具函数没注册成功，回终端看启动日志，一般会直接抛出异常信息，比你在 Cursor 里瞎猜要快得多。

验证成功的标准是：在对话框里直接问 AI“你现在能调用蓝湖的工具吗”，它能准确说出有几个工具、分别干什么。也可以让它直接试调一次get_project_id，看返回结果正不正常。我每次新配完 MCP 都会先做这个冒烟测试，确定通讯是完全通的，再进入业务层面的调试。

3.4 好用的还原度检查 Prompt 模板

接通 MCP 之后，真正决定体验的不是接线本身，而是你怎么跟 AI 描述任务。AI 虽然能调用工具，但你如果不说清楚检查标准，它就会自由发挥，给你输出一大段“整体风格一致”之类的废话。

我最常用的一套还原度检查 Prompt 分四步走：第一步指定设计稿来源，第二步指定代码文件范围，第三步明确比对维度，第四步规定输出格式。下面这个模板可以直接抄走，只需要把里面的项目名、文件路径替换成你自己的：

你是一名设计还原度检查工程师。请执行以下任务： 1. 调用 lanhu-bridge 的 get_project_id 工具，找到名为「商城首页改版」的项目； 2. 获取该项目首页画板的节点列表，找出头部 Banner 区域对应的节点，调用 get_design_meta 和 get_node_spec 拿到该区域的尺寸、背景色、间距和文字样式； 3. 读取项目代码中 src/views/Home/Header.vue 文件，提取 Header 组件的实际实现参数； 4. 逐项对比以下维度： - 尺寸：宽度、高度是否一致 - 间距：内边距、外边距数值 - 颜色：背景色、文字色是否一致（注意十六进制大小写） - 字体：字号、字重、行高 5. 输出一张 Markdown 差异表，每行一个对比维度，列为：维度、设计稿值、代码实际值、状态（一致/偏离/缺失）、备注。

这套 Prompt 的核心是把检查过程“结构化”了。AI 拿到指令后不会漫无目的地乱翻，而是带着具体的工具路径去执行。我试过用一句“帮我看看这个页面还原得怎么样”去问，AI 确实也会做，但输出非常飘，一会儿讲布局一会儿讲交互，根本没法交付给设计师。一旦换成上面这种结构化指令，输出的报告维度就清晰得多了。

还有一个细节：如果你的项目里放一个 .cursorrules 文件，把检查流程、输出格式、常用项目路径都写进去，Cursor 在每次对话时都会自动加载这些规则，你就不需要每次重复粘贴一大段 Prompt 了。这个文件我在团队里用了一个多月，新同事接手时看一遍规则文件，基本就能独立跑还原度检查。

3.5 让检查流程固化成团队习惯

工具链打通之后，接下来要考虑的是怎么让它真正进入日常工作流程，而不是偶尔玩一下。我自己定了一个简单节奏：每完成一个页面的编码，当天就自动生成一份还原度报告，然后在给设计师的回复里直接附上报告链接。这样设计师不用再挨个开口问，打开报告就能看到所有差异点。

更进一步，你可以让 AI 根据差异报告直接生成“修复清单”，按影响程度排序。比如背景色偏离、间距多出 8 像素这种小问题排前面，交互逻辑缺失这种排后面。开发的时候对着清单一项项过，比对着设计稿来回切窗口高效很多。

再分享一个工作流上的小技巧：可以把报告里“状态为偏离或缺失”的行，作为代码评审的检查点。评审时不再泛泛地说“请完善样式”，而是直接引用具体差异数据。这个流程一旦跑顺，设计、开发、评审三方的信息同步就完全基于同一份数据，争议自然就少了。

4. 常见问题与排查实录

4.1 MCP 工具列表加载不出来

这是我在配置过程中遇到最多的一个问题，也很容易让人误以为是自己代码写错了。现象是 MCP Server 状态显示已连接，但工具列表就是空的，AI 总说“我没有找到相关工具可以调用”。

排查时先看终端日志。如果你是在 command 类型下启动的 Server，所有日志会输出到 Cursor 自带的后台，里面有明显的报错堆栈。我遇到过一种情况是 fastmcp 版本太低，工具函数注册时 API 格式变了，升级库就解决了。还有一种情况是函数 docstring 里带了特殊字符，导致注册失败，把描述改成纯英文标点后恢复正常。

如果你用的是 sse 类型，工具列表加载不出来通常是地址后面缺了路径。之前市面上很多 Server 是/sse结尾，但新版协议改成了/events之类的路径，你必须按 Server 实际实现来填。这个没法硬猜，直接翻 Server 源码或者启动日志里的路由列表最靠谱。

4.2 Token 失效、权限不足导致读取失败

API 连接成功但读取数据时返回 401 或 403，这种问题在配置阶段出现的概率特别高。第一次排查永远先确认请求里是否真的带上了 token。我见过同事把 token 配在环境变量里，但 Server 启动时没收到，请求头里只有一对空的引号，API 自然就拒绝了。

权限不足的另一种表现是，你确实能调用工具，但对某个具体项目的数据返回为空。这种情况通常是蓝湖开放平台上的应用权限范围没勾选对应项目。去开放平台后台把应用的项目授权补上，重新请求一次就好。

注意：Token 千万不要硬编码在代码里直接提交到 Git 仓库。我第一次自建 Server 就是图方便写在文件里，后来仓库推到了远端，吓得赶紧去开放平台重置了凭证。正确做法是用环境变量管理，在启动命令里加载本机的 .env 文件，这样既方便切换环境，也避免泄露。

4.3 AI 拿到的数据与设计稿不一致

这个问题的表现是：MCP 明明调通了，但 AI 比对后给出的差异报告里，某些颜色的值跟设计稿差得很远。多数情况不是 AI 幻觉，而是你取错了节点。蓝湖画板上的节点层级很深，同一个视觉区块可能存在多个嵌套节点，取到父级节点时拿的是组合后的宽高，颜色却是空的。

解决方式是在 Prompt 里要求 AI 先取节点列表，人工确认一下目标节点再取明细。你可以这样引导：“调用工具获取项目画板的节点树，找到标题为‘活动楼层’的 Frame，只取这个 Frame 下的第一层子节点明细。” 让 AI 有目的地查找，而不是直接拿一个不确定的节点 ID 去取数据，准确率会高很多。

另外，建议在设计稿源头做规范化：让设计师给关键区块起好语义化的图层名称，比如“价格标签”“加入购物车按钮”。图层名一旦规范，AI 按名字去定位节点就特别可靠，还原度检查的置信度也会大幅提升。这不是技术问题，但实际使用中改善最明显。

4.4 几个和 Cursor 账号相关的坑

接线过程中我顺手整理了几个 Cursor 账号层面的高频问题，虽然跟 MCP 没有直接关系，但都是社区热搜词里大家普遍卡住的地方，放在一起给你做个参考：

这些账号坑的共同点是：不要同时开会员多设备分发登录，也别频繁切号。MCP 流程依赖稳定的会话环境，账号一旦触发风控，配置再漂亮也白搭。我的做法是主力开发机固定登录一个账号，其他设备用临时会话而非长期挂机，一直很稳。

5. 心得与可以继续延伸的方向

5.1 我用到现在的真实体会

这个接线方案我用了几周，最大的感触不是“自动化减轻了工作量”，而是“沟通语境被改变了”。以前设计师问“还原了吗”，回答方式是人肉保证；现在我可以把报告链接贴出来，哪个维度一致、哪个偏了、偏差多少，全都有数据支撑。设计师不再需要追着催，我也不需要背着心理负担去应付一次次抽查，双方都把精力集中在真正需要调整的那几处差异上。

从开发效率上看，原本一次还原度检查大约 10 到 15 分钟，现在 AI 跑一遍只需要几十秒，而且检查标准是完全一致的，不会出现今天看颜色、明天看间距这种随机抽查。项目进入多轮迭代后，这个差异报告还能沉淀成一份历史记录，哪次改动引入了回归，翻一翻报告对比就能定位。

还有一个隐性好处是，这套能力对新人的价值特别大。团队里新同学接手一个既有页面时，不再需要老师傅逐一指点“这个字体偏大、那个间距不对”，直接把 AI 生成的还原度报告作为自测清单，照着改就行。这个工具链本质上把团队的“隐性经验”变成了可复制的“显性流程”。

5.2 这个方案还能怎么扩展

如果你跑通了 Cursor 接蓝湖，不妨继续往三个方向延伸一下。

第一个方向是接入更多设计数据源。我这套方案用的是蓝湖，但同样的包装器思路可以扩展到 Figma、即时设计、墨刀，每个平台都拉一个 MCP Server，让 Cursor 统一调度。团队如果同时用多套工具，这个扩展就能一劳永逸。

第二个方向是结合自动化和 CI。还原度检查不一定要在你本地对话里跑，你也可以写一个脚本，定时拉取蓝湖最新设计稿和线上代码，自动生成差异报告并推送到工作群或任务系统。这一步等于把“人肉走查”变成“定时巡检”，适合对还原质量要求比较严格的项目。

第三个方向是把检查结果反向同步到设计稿。比如 AI 分析出某个组件的实现值与设计稿有偏差时，自动在蓝湖对应节点下评论，或者把差异报告作为附件回传到项目空间。这样一来，设计、开发双方看到的都是同一份“问题数据”，在线对线的扯皮也会少很多。

我个人的建议是，不要贪多，先把“能还原度检查”做到位，再逐步叠加扩展。工具链这种东西，跑通了是杠杆，跑不通是负担。既然你已经看到了把 Cursor 和蓝湖接起来的可能性，花半天时间照着上面的步骤走一遍，大概率比你下周手动核对十张设计稿更值得。