1. 从“还原了吗”这句追问说起做前端的人对这句话应该都不陌生。设计稿刚交付群里就弹出一条消息“这个按钮的圆角是不是不对”“间距怎么看着比设计稿大”“字体是不是粗了一点”——然后你就得打开蓝湖放大到 200%拿取色器吸一下颜色量一下间距截图对比回复一句“我改一下”。一天下来代码没写几行全在跟设计稿“对答案”。这个项目要解决的就是这件事把 Cursor 和蓝湖接起来让 AI 直接读到设计稿的结构化数据在写代码的时候就把颜色、间距、字号、圆角这些值对齐而不是等页面跑起来之后靠肉眼比对。核心用到的是MCPModel 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 ServerCursor 这边是 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 langscss三段式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 语法没问题数值也对但页面效果就是不对。原因通常不在样式本身而在布局上下文。举个例子设计稿里两个元素间距 16pxAI 给第二个元素加了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 不用再去翻设计稿看说明就能判断改动是否合理。这个小习惯把沟通成本又降了一截。
