设计师在群里问出那句“还原了吗”的时候，我正把设计稿放到 200% 放大，数两段文案之间的间距到底是不是 12px。老实说，数到第十遍的时候我已经不太确定了，但为了不显得太业余，我还是硬着头皮回了一句：“我再核对一下。”
这种场景熟悉到让人想叹气。做前端的兄弟应该都有体感：蓝湖上的设计稿明明就在那里，可每一次“还原”都像一场手工抄写大赛。尺寸靠量，颜色靠吸，状态靠猜，切图还得一张张导出，最后产出的代码还免不了被设计师反手截图圈出几个“这里差了 2px”的标注。
后来我做了一件事，解决了这个持续了很久的拉扯——我把 Cursor 这个 AI 编程编辑器直接接到了蓝湖的 MCP 服务上。现在设计师确实不怎么追着问我“还原了吗”了，因为 AI 拿到的是设计稿的结构化信息，而不是一张需要人眼去猜的 PNG。这篇文章就聊聊我当时的完整思路、部署过程、踩过的坑，以及接入之后真实的工作流变化，希望能给同样在前端和设计之间来回拉扯的朋友们一点参考。
1. “还原了吗”——一句话背后是协作断层，不只是代码问题
1.1 设计师和前端之间，到底断了哪几环？
先说个很常见的场景：一个登录页要开发，设计师在蓝湖上传了高保真稿，标注了颜色、字号、间距、圆角，图层命名也还算规范。按理说信息都在了，可真正开发的时候你会发现，事情远没有那么顺利。
首先，蓝湖的标注不是给代码看的，是给人看的。你得自己对着标注一个个读，读完之后在编辑器里手动转成 CSS、SCSS 或者 Tailwind 类，这个“读数—记忆—转换”的过程非常容易出错。10 组间距里记错了两组很正常，而且你当时根本察觉不到，要等视觉走查的时候设计师拿着稿子圈出来你才发现。
其次，设计稿不是静态的。设计师今天上午传了一版，下午又调了主色和按钮圆角。你照着上午的稿子写完，下午设计师问“还原了吗”的时候，你甚至不知道设计稿已经变了。这种“你改了我不知道”的信息断层，比单纯的像素误差更致命，它消耗的是两个角色之间的信任。
最后就是切图。以前的流程里，前端需要在蓝湖上一张张切图、下载，放错目录、命名不统一都是常态。现在虽然是很多工具能自动切图，但流程依然繁琐：你要先把资源拉到本地，再手动整理到项目里，万一设计稿更新，你还得重新导一遍。
所以你看，问题根本不是“前端认不认真”，而是整个链路里人要去当那个翻译官。蓝湖的信息是结构化的，但我们前端用的时候却是非结构化的——靠眼睛、靠截图、靠手动复制。这才是“还原了吗”被反复问起的根本原因。
1.2 为什么“多看一眼设计稿”解决不了这个事
有人可能会说，那你多打开蓝湖几次，仔细比对不就得了？听起来有道理，但实际上并不成立。
一张复杂的设计稿有成百上千个属性：间距、圆角、阴影、渐变、字重、透明度、状态切换……你不可能每次都肉眼核对一遍。人是会疲劳的，尤其当你在写业务代码的过程中频繁切换到蓝湖去看标注，注意力很容易断掉。我看过太多同行，开发到后面基本就是“看着差不多”就收工了，然后靠 QA 和设计师去当最后一道防线。
还有一个被低估的问题：视觉感知和代码表达不是一回事。设计稿里一个 16px 的字距，在浏览器里受字体渲染、行高、缩放的影响，看起来可能就不是那回事。人是靠感觉去“校正”的，这个校正过程就需要大量的来回沟通。换句话说，就算你多看一眼，你看到的还是那个静态图，没法直接变成代码里可靠的参数。
我当时的想法很简单：能不能让 AI 直接去读蓝湖的设计数据，而不是我手抄？如果 Cursor 能拿到设计稿的图层结构、颜色、间距、切图资源，它生成的代码就是“基于事实”的而不是“基于猜测”的。与其把精力花在反复比对上，不如把这个能力直接交给工具。
这个想法，最终是通过 MCP 落地的。
2. Cursor 接入蓝湖前，我先把 MCP 这件事吃透了
2.1 MCP 的本质：给 AI 装一个能“读数据”的外接口
MCP 的全称是 Model Context Protocol，通俗点说，它是一套统一的“工具箱协议”，让 AI 应用能通过标准化接口去调用外部数据和服务。以前 AI 编程工具只能读你本地项目里的代码，现在有了 MCP，它还能去访问设计稿、数据库、文档库、API 服务这些外部资源。
我习惯把 MCP 理解成“手机上的 USB-C 接口”——以前各种设备充电口五花八门，你出门得带一堆线；现在统一了接口，一根线就能通。Cursor 通过 MCP 连接蓝湖，就相当于在这个接口上插了一根“设计数据线”，AI 可以直接看到蓝湖里设计稿的结构化信息。
这跟单纯给 AI 一张截图是完全不一样的。截图是像素，AI 得靠视觉模型去猜；而 MCP 给的是数据——某个图层的宽度是多少、颜色值是多少、文本字号是多少、切图资源的 URL 是哪条，这些是精确的、文本化的信息。AI 拿到这些，生成的代码才有依据。
2.2 蓝湖的 MCP 服务，解决的是“设计交付”那一环
蓝湖本身是设计师和前端之间的交付平台，它手里握着整个项目最权威的设计数据。而蓝湖布设的 MCP 服务，就是把这些数据开放给 AI 工具的通道。
我当时理解它的能力边界是这样的：
- 读取设计稿的图层列表、画板信息，AI 能知道当前设计稿里有哪些页面、哪些组件；
- 读取具体图层的样式属性，包括颜色、字体、字号、行高、圆角、描边、阴影、不透明度等；
- 读取间距和布局相关信息，帮助 AI 理解元素之间的相对位置和排列方式；
- 获取切图资源的下载信息，前端需要资源的时候可以直接引用，不用手工导出。
注意，这些能力不是一次全给你，而是以“工具”的形式暴露给 AI。MCP 服务把一系列工具摆在那里，Cursor 里的 AI 会在需要的时候自己决定调用哪个。比如你让它“照着设计稿实现扫码登录区块”，它自己就会去翻蓝湖的设计稿，提取这一部分的样式信息，然后结合你项目里的技术栈生成代码。
我一开始也犹豫过，这玩意儿是不是又是一个需要复杂配置的“半成品”？但实际做下来，配置量比我想象的小得多，真正花时间的是理解它的工作方式和后续在团队里推广的规范。
3. 环境准备：Cursor 和蓝湖两侧的权限细节，一个都不能漏
3.1 先把 Cursor 环境整理利索
连接蓝湖之前，得先保证 Cursor 本身是能正常工作的。这里我把自己整理环境时碰到的一些细节也说一下，很多人卡在半路其实问题出在前期。
Cursor 的下载和安装不复杂，去官网拿对应系统的安装包就行。装完之后第一件事，我建议先把界面语言调成自己顺手的。Cursor 默认是英文界面，它在设置里提供了语言选项，如果你对英文界面不敏感，可以开中文模式，减少操作时的理解成本。设置路径一般在 Settings 的 Appearance 或者 Language 相关区域，选择中文之后重启就生效了。不过我得说句实在话，如果后续要用 MCP、读官方文档，最好还是保留英文，因为很多新增功能的中文翻译还没跟上，反而容易看不懂。
账号这块有个值得注意的坑：同一个 Cursor 账号登录的设备数量是有限制的，如果你短时间内换电脑太多，会出现“too many computers used within the last 24 hours for the same cursor account”的提示。我第一次遇到的时候挺懵的，后来才知道是短时间内登录设备过多触发了风控。解决办法就是别在太多机器上轮着登同一个号，要么等 24 小时冷却期过了再试，要么去账号设置里管理已登录设备，把不用的清理掉。
Cursor 模型相关的权限也要注意。MCP 调用本质上是让 AI 代表你去访问外部服务，所以你得确保当前使用的模型和会话模式支持工具调用。一般默认的 Cursor 模型都能用，但我习惯在开始工作前先建一个干净的项目目录，避免它把无关代码上下文混进来。
3.2 蓝湖侧的准备：权限比技术更关键
蓝湖这边，重点不是技术，是权限。
你需要一个能访问目标设计稿的蓝湖账号，而且这个账号必须对那个设计稿所在的“空间”有查看/编辑权限。如果设计稿是团队内部共享的，你还得确认你登录用的账号有没有被邀请进那个团队。
另外，设计稿的“链接权限”也很重要。蓝湖里每个设计稿都可以设置分享范围，如果设计师只设置了指定成员可见，那你就算拿到了 MCP 配置，AI 也读不到内容。最好在开始之前就跟设计师确认：这个设计稿团队内可见，或者至少对你访问的账号开放。
我当时就是没注意这一点，MCP 服务配好后怎么调都读不到设计稿，后来才发现是权限没开。这个后面讲踩坑的时候细说。
最后就是 MCP 服务入口的获取。蓝湖在它的账号设置或者团队设置里提供了 MCP 服务的相关入口，一般会生成一个访问令牌（Token）和服务端点地址，这两样是配置 Cursor 的核心文件。铂金的，整个接入过程的核心其实就这三个东西：蓝湖的访问令牌、蓝湖的 MCP 服务地址、Cursor 里新建的 MCP 配置项。
4. 把蓝湖 MCP 配置进 Cursor 的完整实操
4.1 从蓝湖获取 MCP 服务地址和访问令牌
在蓝湖网页端或者桌面端进入账号设置区域，找到“MCP 服务”入口（不同版本位置可能略有差异，但通常在个人设置或团队设置里）。进去之后，按照引导创建访问密钥，系统会生成一个 Token。
还有服务地址，一般是类似https://mcp.lanhuapp.com/mcp这种格式的统一入口。创建之后把 Token 复制保存好，这个 Token 只在创建时完整显示一次，丢了就得重新生成。
这个环节要注意的是：Token 不要泄露到代码仓库里，更不要直接写进项目文件提交到 GitHub。这个 Token 相当于你蓝湖账号的一把钥匙，谁拿到谁就能读取你有权限的设计稿。如果误传了，第一时间回蓝湖后台把旧 Token 删掉重新生成。
4.2 在 Cursor 里添加 MCP 服务器配置
接下来到 Cursor 侧。打开 Cursor，按下快捷键（一般是Cmd+Shift+P或Ctrl+Shift+P）唤起命令面板，输入 MCP 找到 MCP 配置入口。新版 Cursor 在 Settings 里也直接有 MCP 面板，两者都可以操作。
在 MCP 面板里选择“Add New MCP Server”，然后要选服务器类型。蓝湖这种远程服务一般选择 HTTP/SSE 类型，意思是你的 MCP 服务部署在云端，Cursor 通过网络协议去访问它。如果你的蓝湖 MCP 提供了本地 CLI 的部署方式，也可以选 stdio 类型，但大多数情况下直接选 HTTP 更省事。
接着填写三样东西：
- 服务器名称，比如填
lanhu-design； - 服务器地址，就是刚才复制的 MCP 服务地址；
- 请求头或认证信息，在 Authorization 里填
Bearer 你的Token。
菜单式操作如果不方便，也可以直接编辑 Cursor 的 MCP 配置文件，本质上是一样的。配置内容大致长这样：
{ "mcpServers": { "lanhu-design": { "url": "https://mcp.lanhuapp.com/mcp", "headers": { "Authorization": "Bearer YOUR_LANHU_MCP_TOKEN" } } } }如果你是 CLI 型服务器，配置会稍微不同，一般是command字段加args数组的形式。具体用哪种，以蓝湖 MCP 服务文档提供的接入方式为准，别拘泥于我这里的示例。
填完保存之后，回到 MCP 面板，看到lanhu-design状态变成“已连接”或者类似字样，就说明网络层通了。
4.3 验证连接：让 AI 自己翻一翻设计稿
连接上不代表能用，关键要看工具能不能真正读到数据。
我在验证阶段的做法很简单：新建一个空白项目，然后在 Cursor 的对话框里直接问它：“查看我在蓝湖上可见的设计稿，列出最近的项目列表。”如果 MCP 连接正常，它会自己去调用蓝湖的 MCP 工具，返回一串项目或者设计稿条目。
你可能会看到 AI 在回复之前出现“调用工具”的过程提示，这是它在向 MCP 服务器发起请求，属于正常现象。如果 MCP 配置有问题，AI 会回复它无法访问蓝湖，或者直接告诉你 MCP 工具调用失败。
这一步验证非常关键，别跳过。我见过不少人配完连接状态显示正常，但一问设计稿就报错，排查半天发现是服务器地址写错了，或者是 Token 复制的时候多了一个空格。真就一个空格，够你折腾半小时。
5. 真实还原工作流：AI 读稿、出码、人工兜底
5.1 场景设定：让 AI 读设计稿，而不是看截图
接入之后，我把团队里一个登录页面的还原任务实际跑了一遍。
第一步是把任务描述清楚。我打开 Cursor 的对话面板，先跟它说明项目背景：这是一个 Vue 3 + TypeScript 的项目，UI 库用的是 Element Plus，我要实现蓝湖上“登录页面”的设计稿。
然后我告诉它：去蓝湖读取名为“登录页 v2”的设计稿，提取所有可见图层的样式信息，特别是背景色、卡片圆角、输入框高度、按钮的主色和 hover 色、底部文案的字号与颜色。
注意这里的关键词是“读取设计稿”，而不是“看截图”。我没有上传任何图片，但 AI 通过 MCP 调用了蓝湖的工具，拿到了画板和图层的数据。
5.2 生成过程：AI 怎么把设计数据变成代码
接下来 AI 做的事情，大概分为这么几步：
首先是定位设计稿，在蓝湖中找到“登录页 v2”这个画板；其次是遍历画板下的图层树，找出标题、输入框、按钮、分割线、底部链接这些元素；然后是提取每一类元素的样式属性——不仅仅是颜色和字号，还包括边距、对齐方式、边框、投影这些容易被遗漏的细节；最后是结合项目里已有的组件规范，把这些属性转化成 Vue 模板、SCSS 样式或者内联 API 调用。
这个过程耗时大概一两分钟。期间我不用自己打开蓝湖，也不用对着标注逐条抄，AI 生成出来的代码里用的色值、字号、间距参数，都是直接来自设计稿数据的。
比如它输出了一个这样的按钮样式：
.login-button { width: 100%; height: 44px; background: #2f54eb; border-radius: 8px; color: #ffffff; font-size: 15px; font-weight: 500; }关键不是这段代码本身有多惊艳，而是背景色、圆角、高度这些数值，它没有靠猜，而是从蓝湖的图层数据里读出来的。这才是 MCP 接入之后最大的变化——AI 的输入源从“模糊图片”变成了“精确数据”。
5.3 人工兜底：AI 还原七八成，剩下的靠人校对
必须诚实地说，AI 读稿出码不是银弹。它在页面结构骨架、配色、基础间距上表现很好，但在某些细节上还是需要人盯着。
比如布局里多个元素之间的相对偏移，AI 有时候会根据框架自动用 flex 或者 Grid 去拟合，可能视觉看起来是那么回事，但因为忽略了某个父容器的内边距，实际渲染出来会差几个像素。这就是为什么我说“人工兜底”不能省，只不过人工兜底的工作量从“逐条对标注”变成了“抽查关键数值”。
我自己的流程是：AI 生成第一版代码后，我不急着提交，先打开蓝湖对比几个关键节点，比如主视觉图的尺寸、卡片的最大宽度、按钮的交互状态。确认这几个大头没问题，其余小细节再交给视觉走查。
当时这个登录页从出码到走查通过，大概比以往少了三分之一的时间，最主要的是，设计师不再需要追着我问“还原了吗”了，因为我的底稿数据来源和她的设计稿是同一个，天然就能对齐。减少了来回确认的次数，这件事本身就值回票价。
6. 接入后的避坑记录与团队协作建议
6.1 我踩过的几个坑：权限、Token，以及 AI 的“自信”
实操下来，有一说一，坑还是有的。我把遇到过的几个典型问题摆出来，方便后来者对照排查。
第一个坑是权限。MCP 配置成功了，但 AI 怎么调都说“无法获取设计稿”。排查到最后发现，我的账号能访问蓝湖，但访问的是个人空间，而设计稿在团队空间里，我压根没被邀请进去。后来被邀进去之后，一切正常。所以再次提醒：先确认账号在设计稿所属的团队空间里有权限，这是前置条件。
第二个坑是 Token 泄露。有一次我用 Cursor 写代码，顺手把一个测试 Token 写进了项目环境配置文件，结果一定时间后它失效了，排查半天才发现是因为环境配置文件进了版本控制，被平台检测到后自动吊销。教训是：Token 必须放在本地环境变量里，而不是硬编码进项目。
第三个坑是 AI 太“自信”。MCP 连接正常，它也拿到了部分设计稿数据，但有一次生成代码时，它自己“脑补”了一个按钮 hover 色，设计稿里根本没有这个状态的数据。它为什么会补？因为我在 prompt 里说了“实现 hover 效果”，但没说数据从哪来，它就基于常见的蓝色按钮 hover 模式自己加了个变暗效果。
这个问题的对应解法不是不用 AI，而是把 prompt 写得更有约束力。我后来会明确告诉它：“所有颜色、间距、字号都必须来自蓝湖设计稿数据，如果某个状态在稿子里没有对应数据，请直接说明缺失，不要推测。”
6.2 团队协作上的几个建议：让设计师也参与进来
接入 MCP 之后，受益最大的其实不只是前端，设计师那边也能省不少事。但前提是团队协作方式要跟着微调一下。
我会建议设计师在做稿子的时候注意图层命名规范。MCP 读到的数据是结构化的，图层树上的名字直接决定了 AI 能不能识别出“这个是主按钮”“这个是输入框”“这是分割线”。如果图层全叫“矩形 1”“矩形 2”，AI 读起来会很吃力，甚至会误判。所以我会跟设计师商量，关键组件尽量用语义化的命名，这对 AI 识别有非常大的帮助。
还有就是设计稿的版本管理。以前设计师更新稿子，前端可能不知道，现在有了 MCP，AI 读到的是最新版，反而前端可能还在用旧版的代码认知。所以我们团队约定：涉及大版本改版时，前端在开发前先让 AI 同步一次蓝湖设计稿的最新结构，再动手改代码，避免新旧信息混在一起。
最后建议团队里维护一份“设计资源和 MCP”的说明文档，把 Token 的获取方式、服务地址、谁有权限、失效了找谁这几个信息写清楚。因为这类配置往往只有一个人会弄，一旦那个人离职或者休假，其他人就抓瞎。文档化这个东西，成本很低，收益很高。
6.3 从工具到习惯：MCP 不是终点，是工作方式的拐点
MCP 把蓝湖和 Cursor 连接起来之后，我最大的感受不是“AI 好厉害”，而是“以后我可以把精力放在更值得的地方了”。没接入之前，大量的时间消耗在信息搬运上——把设计稿上的数字搬运到代码里，把切图资源搬运到项目里，把设计师的口头反馈搬运成代码修改。
现在这个搬运过程交给了机器，我只需要在关键节点上做判断和取舍。比如组件怎么抽象、状态怎么管理、交互怎么实现，这些才是前端工程师真正该操心的。至于“这个按钮是 8px 圆角还是 10px 圆角”，让 AI 去读数据吧，它的记性比我好，也不会有看花眼的时候。
后来我还把同样的 MCP 服务接进了其他支持 MCP 的 AI 客户端，因为这东西是个标准协议，不是一个编辑器私有的功能。一次配置，多处复用，这大概也是 MCP 这股风潮能吹起来的原因。
如果你现在还在被“还原了吗”反复纠缠，我建议你试一下这条路。不用一开始就搞得很复杂，先拿一个简单页面跑通流程，感受一下“AI 读设计数据”和“AI 看截图猜设计”之间的差距。跑通之后，你会发现真正需要你动手的，已经不再是那些一眼望不到头的像素对齐了。
