1. 从“还原了吗”这句追问说起
做前端的人对这句话应该都不陌生。设计稿刚交付，群里就弹出一条消息：“这个按钮的圆角是不是不对？”“间距怎么看着比设计稿大？”“字体是不是粗了一点？”——然后你就得打开蓝湖，放大到 200%，拿取色器吸一下颜色，量一下间距，截图对比，回复一句“我改一下”。一天下来，代码没写几行，全在跟设计稿“对答案”。
这个项目要解决的就是这件事：把 Cursor 和蓝湖接起来，让 AI 直接读到设计稿的结构化数据，在写代码的时候就把颜色、间距、字号、圆角这些值对齐，而不是等页面跑起来之后靠肉眼比对。核心用到的是MCP（Model Context Protocol）这套协议，配合Vue 3 + SCSS的技术栈，把设计稿的标注信息变成 AI 能直接消费的上下文。
先说清楚适合谁看。如果你满足下面任意一条，这篇内容对你有用：
- 日常用 Cursor 写前端，但每次都要手动翻设计稿抄数值；
- 团队用蓝湖做设计交付，想减少“还原度”来回沟通的成本；
- 听说过 MCP 但没搞明白它到底能干什么，想找个真实场景落地；
- 用 Vue 3 + SCSS 做项目，想把这套流程固化下来。
不适合谁：指望接上之后 AI 一键生成完美页面、完全不用人看的人。设计稿数据是“原料”，AI 是“厨师”，原料再准，菜还是得有人尝。这个工具的价值是把重复的“抄数值”环节自动化，不是替代判断。
我自己的场景是一个中后台项目，二十多个页面，设计稿迭代频繁，团队三个人轮流改样式。接上之后最直观的变化是：以前改一个卡片样式要来回问三次，现在 AI 直接读标注，我只需要确认布局逻辑对不对。下面把整套东西拆开讲，包括为什么这么选、怎么落地、踩了哪些坑。
2. 整体方案设计与技术选型拆解
2.1 为什么是 MCP，而不是写个脚本抓数据
最朴素的想法是：蓝湖有网页版，我写个爬虫把标注数据抓下来存成 JSON，再让 Cursor 读这个 JSON 不就行了？我一开始确实这么试过，结论是能跑，但维护成本高得离谱。
问题出在三个地方。第一，蓝湖的标注数据是动态渲染的，DOM 结构会变，今天写的选择器下周可能就失效。第二，登录态、权限、不同项目的链接格式都要单独处理，脚本越写越像一个小型爬虫工程。第三，也是最关键的——数据抓下来是“死”的，AI 每次要用都得我手动触发一次抓取，没法在对话里实时查询。
MCP 解决的正是这个“实时、结构化、可被 AI 主动调用”的问题。你可以把它理解成给 AI 装了一个“外挂工具箱”：AI 在需要的时候，自己决定调用哪个工具、传什么参数，工具返回结果，AI 再基于结果继续推理。这跟“我提前把数据塞进 prompt”是两种完全不同的模式。
提示：MCP 是协议，不是某个具体软件。它规定了“AI 客户端”和“工具服务端”之间怎么通信。蓝湖这边提供的是一个 MCP Server，Cursor 这边是 MCP Client，两者通过协议对话。
2.2 蓝湖 MCP 服务到底提供了什么能力
蓝湖的 MCP 服务本质上是把设计稿的标注信息封装成了几个可调用的工具。根据我实际用下来的观察，核心能力集中在几类查询上：
| 能力类型 | 作用 | 典型调用场景 |
|---|---|---|
| 项目/画板列表查询 | 列出当前账号可见的项目和画板 | 先定位到目标设计稿 |
| 图层结构查询 | 返回某个画板的图层树 | 理解页面由哪些元素组成 |
| 样式标注查询 | 返回指定图层的颜色、字号、间距、圆角等 | 写 SCSS 变量和样式 |
| 切图资源查询 | 返回图层的导出资源信息 | 处理图标、图片 |
这里要强调一点：MCP 返回的是结构化数据，不是截图。也就是说 AI 拿到的是“这个按钮背景色 #1677FF，圆角 6px，内边距 16px 24px”这样的文本，而不是一张图让它去猜。这是它能准确写样式的前提。
2.3 为什么技术栈锁定 Vue 3 + SCSS
标题里带了 Vue 3 和 SCSS，这不是随便选的。MCP 返回的样式数据要落地成代码，落地方式直接决定了这套流程顺不顺。
如果项目用的是原子化 CSS 框架，AI 拿到padding: 16px 24px之后还得去查对应的类名，中间多一层映射，容易出错。而 SCSS 的好处是：它本身就是写具体数值的，AI 拿到标注值可以直接写进去，甚至可以顺手抽成变量。Vue 3 的单文件组件结构又很规整，<template>、<script setup>、<style scoped lang="scss">三段式，AI 很容易定位该往哪里写。
我实测下来，Vue 3 + SCSS 这套组合跟 MCP 的配合度是最高的，因为“设计稿数值 → SCSS 声明”几乎是直译，中间不需要太多转换逻辑。如果你用的是 React + styled-components，也能做，但 AI 需要多理解一层组件的样式组织方式，稳定性会略差一点。
2.4 整体数据流长什么样
把上面的东西串起来，整个链路是这样的：
- 我在 Cursor 里描述需求，比如“把 UserCard 组件的样式对齐设计稿”；
- Cursor 的 Agent 判断需要设计稿数据，调用蓝湖 MCP Server 的查询工具；
- MCP Server 返回该画板的图层结构和样式标注；
- Cursor 拿到数据，结合当前代码文件，生成或修改 SCSS；
- 我 review 改动，确认布局逻辑，提交。
关键在第 2 步：是 AI 主动去调，不是我手动喂。这意味着我可以在一次对话里让它查多个画板、对比多个状态，全程不用我复制粘贴任何数值。这个体验上的差别，用过就回不去了。
3. 环境搭建与 MCP 服务接入实操
3.1 Cursor 侧的基础准备
先把 Cursor 本身弄利索。下载安装这些不用多说，重点说几个影响后续使用的设置。
第一是语言。Cursor 默认界面是英文，如果你习惯中文，在设置里搜 “language” 或者直接改locale相关配置就能切换。不过我要提醒一句：界面语言和 AI 回复语言是两回事。界面切成中文，不代表 AI 就用中文回你。想让 AI 稳定用中文回复，最靠谱的办法是在项目根目录放一个规则文件（比如.cursorrules或者项目级的 rules），里面明确写“始终使用中文回复”。我试过只在对话里说“用中文”，多轮之后它偶尔会飘回英文，写进规则文件就稳了。
第二是权限。Cursor 的 Agent 模式在调用外部工具、执行命令时会请求授权。如果你每次都手动点确认，接 MCP 之后会非常烦，因为一次样式对齐可能触发好几次工具调用。我的做法是：在可信的项目里，把常用工具的权限放开，但保留文件写入的确认。这样 AI 可以自由查询设计稿，但改我代码之前我还能看一眼。
第三是模型选择。不同模型对工具调用的支持程度不一样。我实测下来，支持 function calling 比较扎实的模型，在 MCP 场景下表现明显更稳，不容易出现“该调工具的时候不调，或者参数传错”的情况。这个可以自己多试几个，选一个在你项目里最顺手的。
3.2 蓝湖 MCP 服务的获取与配置
蓝湖的 MCP 服务需要在蓝湖侧开通或获取接入信息。具体入口会随版本变化，我不写死某个菜单路径，说下通用的判断方法：你要拿到的是一个服务地址和鉴权凭证（通常是一个 token）。这两样东西是配置的核心。
拿到之后，在 Cursor 的 MCP 配置里添加一个 Server。配置文件的典型结构是这样的（不同版本字段名可能略有差异，以你实际看到的为准）：
{ "mcpServers": { "lanhu": { "url": "你的蓝湖MCP服务地址", "headers": { "Authorization": "Bearer 你的token" } } } }这里有几个坑要提前说。
注意：token 是有有效期的，也可能跟账号绑定。如果你发现昨天还能用今天突然查不到数据了，第一件事就是检查 token 是不是过期，而不是去怀疑配置写错了。
注意：服务地址如果是 https 的，注意别写成 http，协议不对会直接连不上，而且报错信息往往很含糊，容易误导排查方向。
配置保存之后，Cursor 一般会尝试连接。连接成功的标志是：在对话里问它“你能看到哪些 MCP 工具”，它能列出蓝湖相关的工具名。如果列不出来，说明连接没成功，先解决连接问题，别急着往下走。
3.3 验证连接是否真的通了
很多人配完看到没报错就以为成了，其实不一定。我建议做一次最小验证：找一个你确定有权限访问的蓝湖项目，让 Cursor 去查它的画板列表。
如果它能返回画板名称，说明鉴权和网络都通了。如果返回空列表，可能是账号权限问题——你登录蓝湖用的账号，和 token 对应的账号，得是同一个，或者至少有对应项目的访问权。这个坑我踩过：用 A 账号拿的 token，去查 B 账号的项目，结果一直是空，排查了半天才发现是账号不对。
再进一步，让它查某个具体画板的图层结构。这一步能返回数据，说明 MCP 服务的能力是完整的，可以进入实际使用了。
4. 把设计稿数据变成 SCSS 的完整流程
4.1 先建立“设计稿到代码”的映射约定
在让 AI 干活之前，我强烈建议先跟团队定一套映射约定。原因很简单：设计稿里的数值是“绝对”的，但代码里的写法是“相对”的。如果不约定，AI 每次生成的风格可能都不一样。
我们团队定的几条规则，供参考：
- 颜色统一抽成 SCSS 变量，命名用语义化的，比如
$color-primary、$color-text-secondary，而不是$blue-500； - 间距用 4 的倍数做基准，设计稿里如果是 15px，就近取 16px，并在注释里说明；
- 字号、行高、字重三个值绑定成一个 mixin，避免散落；
- 圆角、阴影这类复用度高的，也抽成变量。
这套约定写进项目的规则文件之后，AI 生成 SCSS 的时候会主动遵守，省去大量返工。这一步看起来是“额外工作”，但它决定了后面自动化能不能真正省时间。没有约定，AI 每次给你写一套新风格，你还得手动统一，反而更累。
4.2 单组件样式对齐的实操演示
拿一个具体的卡片组件举例。假设设计稿里有个用户信息卡片，我在 Cursor 里这样说：
“参考蓝湖上 XX 项目的用户卡片画板，把UserCard.vue的样式对齐设计稿，颜色和间距抽成变量。”
接下来会发生什么：
- Cursor 调用蓝湖 MCP，查询该画板的图层结构；
- 定位到卡片容器、头像、姓名、描述文字这几个图层；
- 分别查询它们的样式标注；
- 读取当前
UserCard.vue的内容； - 生成修改后的
<style>部分。
它返回的 SCSS 大概长这样：
.user-card { display: flex; align-items: center; padding: $spacing-md $spacing-lg; background: $color-bg-container; border-radius: $radius-md; box-shadow: $shadow-sm; &__avatar { width: 48px; height: 48px; border-radius: 50%; margin-right: $spacing-md; } &__name { font-size: $font-size-lg; font-weight: 600; color: $color-text-primary; line-height: 1.4; } &__desc { font-size: $font-size-sm; color: $color-text-secondary; margin-top: $spacing-xs; } }注意它用的是变量而不是硬编码数值。这就是前面约定起作用的地方。如果没约定，它很可能直接写padding: 16px 24px，虽然也能用，但后续维护就散了。
4.3 处理设计稿和现有代码的冲突
实际项目里，设计稿和现有代码经常对不上。可能是设计稿更新了代码没跟上，也可能是代码里有历史包袱。这时候 AI 会怎么处理？
我的经验是：它会以设计稿为准去改代码。这符合预期，但你要留意它改动的范围。有一次设计稿只是调了个颜色，结果 AI 顺手把整个组件的间距也“对齐”了，导致其他页面受影响。原因是那个组件的样式被多个页面复用，而设计稿只反映了其中一个场景。
所以我的做法是：让 AI 改之前，先问它“这个组件被哪些地方引用了”。如果复用度高，就只改设计稿明确变化的部分，其他保持不动。这个判断 AI 做不了，得人来把关。
提示：涉及公共组件的样式改动，永远先查引用范围。MCP 给的是设计稿视角，代码的复用关系它看不到，这块必须人工介入。
4.4 批量页面的处理策略
单组件对齐跑通之后，自然会想批量处理。我的建议是不要一次性让 AI 改十几个页面。原因有两个：一是上下文太长，AI 容易丢细节；二是改动太多，你 review 不过来，出了问题不好定位。
更稳的做法是按模块分批。比如先处理“列表页”相关的三个组件，确认没问题，再处理“详情页”。每批处理完，跑一次页面看效果，确认无误再继续。这样即使某批出了问题，影响范围也可控。
另外，批量处理时我会让 AI 先输出一份“改动清单”，列出它打算改哪些文件、每个文件改什么。我看过清单确认没问题，再让它实际执行。这一步能挡掉大部分“改错地方”的情况。
5. 常见问题与排查技巧实录
5.1 连接类问题速查
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 工具列表为空 | 配置未生效或服务地址错误 | 检查配置文件语法、地址协议 |
| 查询返回空数据 | token 过期或账号无权限 | 重新获取 token，确认账号一致 |
| 时好时坏 | 网络波动或服务限流 | 重试，观察是否集中在高峰期 |
| 报鉴权失败 | token 格式错误 | 确认 Bearer 前缀和空格 |
连接类问题占了新手踩坑的一大半。我的经验是：先确认 token 和账号，再确认地址，最后才怀疑配置格式。因为前两个出问题的概率远高于格式写错。
5.2 数据不准的几种情况
有时候 MCP 返回的数据和你在蓝湖网页上看到的不一致。常见原因：
- 画板选错了。一个项目里可能有多个版本的画板，名字很像，选错就全错。
- 图层被隐藏或锁定。隐藏的图层可能不返回数据，或者返回的是旧值。
- 设计稿有多个状态。比如按钮有默认、hover、disabled 三个状态，你查的是默认态，但代码里需要的是全部。
遇到数据不准，第一反应应该是回蓝湖网页核对，而不是怀疑 MCP。我遇到过的绝大多数“数据不对”，最后都是我自己选错了画板或图层。
5.3 AI 生成的样式“看着对但跑起来不对”
这是最隐蔽的一类问题。AI 生成的 SCSS 语法没问题，数值也对，但页面效果就是不对。原因通常不在样式本身，而在布局上下文。
举个例子：设计稿里两个元素间距 16px，AI 给第二个元素加了margin-top: 16px。但如果这两个元素在代码里是 flex 布局且用了gap，再加 margin 就会变成 32px。AI 看到的是设计稿的“视觉结果”，不一定理解你代码里的布局机制。
解决办法是：在规则文件里说明项目的布局约定，比如“优先使用 flex gap 控制间距，避免用 margin 叠加”。有了这条，AI 生成时就会避开这个坑。
5.4 几个我踩过的坑
第一个坑是过度信任。刚接上的时候觉得太爽了，AI 改完直接提交，结果有个页面的字号全小了一号。后来发现是设计稿那个画板本身用的是旧版规范。从那以后我养成了习惯：AI 改完，至少打开页面扫一眼，重点看字号、颜色、间距这三样。
第二个坑是token 硬编码。一开始图省事把 token 直接写在配置文件里，后来 token 过期要换，发现配置文件被 git 跟踪了，换一次要提交一次。正确做法是把 token 放到环境变量或者本地不提交的配置里。
第三个坑是忽略设计稿的响应式标注。蓝湖里有些画板标了多端尺寸，AI 可能只读了其中一个。如果项目需要响应式，得明确告诉它“参考 PC 端标注”或者“参考移动端标注”，否则它可能给你混着用。
6. 让这套流程真正省时间的几个心得
6.1 规则文件是投入产出比最高的一件事
花半小时写一份项目规则文件，能省下后面无数次的返工。规则文件里我建议至少包含这几块：技术栈说明、样式约定（变量命名、间距基准、布局方式）、AI 回复语言、以及“改公共组件前先查引用”这类硬性要求。
这份文件不用一次写完美，用着用着发现 AI 哪里做得不对，就补一条进去。它本质上是你和 AI 之间的“团队规范”，越用越顺手。
6.2 把“查设计稿”和“写代码”分开
我一开始喜欢一句话让 AI 干完所有事：“查设计稿并把组件改好”。后来发现分开更稳：先让它查，把关键数值列出来给我看，我确认没问题，再让它改代码。
这样做的好处是，如果设计稿数据有问题，在“查”这一步就能发现，不会等到代码改完才发现。多一步确认，少一轮返工，算下来是划算的。
6.3 不是所有页面都值得接
这套流程对“样式密集、迭代频繁”的页面收益最大，比如列表、表单、卡片这类。但有些页面，比如纯逻辑的、样式极简的，接进来反而增加复杂度。我的判断标准是：如果一个页面的样式改动频率高于逻辑改动频率，就值得接；反之就不必。
6.4 关于“还原度”这件事的重新理解
接上这套东西之后，我对“还原度”有了新的看法。以前觉得还原度是“像素级一致”，现在觉得更重要的是“设计意图一致”。设计稿里的 16px 间距，在代码里可能因为布局机制变成 15px 或 17px，但只要视觉节奏对，用户是感知不到的。
AI 能帮你把数值对齐，但“这个间距在这里是不是合适”“这个颜色在这个场景下会不会太跳”，这些判断还是得人来做。工具解决的是重复劳动，不是审美判断。想清楚这一点，就不会对它有超出实际的期待，用起来反而更顺。
最后分享一个我最近在用的技巧：让 AI 在改完样式后，顺手生成一份“改动说明”，列出每个文件改了什么、依据是设计稿的哪个图层。这份说明在 code review 的时候特别好用，reviewer 不用再去翻设计稿，看说明就能判断改动是否合理。这个小习惯，把沟通成本又降了一截。
