企业官网建设流程全解析

设计师小美又来私信我了：这个按钮的圆角不对，卡片阴影也不对，你那边还原了吗？

这句话在过去半年里我几乎每天都要听到。设计稿在蓝湖，代码在 IDE，两边信息天然割裂。以往我的回复永远是“等我对着蓝湖再看看”，然后切到浏览器里找标注、找切图，来回折腾十几分钟，最后改完还得请小美再确认一遍。更别提赶上高峰期，一天要反复看几十个控件位，眼神比对间距色值，谁干谁知道。

后来我做了一件事：把 Cursor 直接接到了蓝湖上。具体来说，我用 MCP 服务把蓝湖里的设计标注、图层结构、切图资源统一暴露给 Cursor，让 AI 在写代码的时候自己去读设计稿，写完之后还能顺手做一轮还原度自查。从那以后，小美来问“还原了吗”的频率直线下降，因为回答这个问题的活儿，我交给了 AI。

这篇文章就把我搭这条链路的全过程记下来，包括为什么这么干、蓝湖 MCP 怎么部署、Cursor 侧怎么配、提示词怎么写、以及我踩过的那些坑。如果你也是前端开发，团队用蓝湖做设计交付，自己又习惯用 Cursor 写代码，这套方案可以直接抄作业。

1. 先聊清楚：还原度沟通到底低效在哪

很多团队对“还原度”这件事的管理方式还停留在人肉阶段。设计师在蓝湖上传高保真稿，标好尺寸、颜色、圆角、切图；开发拿到需求后打开蓝湖，看一眼页面结构，回 IDE 里写；写完后设计师再打开线上页面，逐像素对比，发现问题列个清单丢过来。这一来一回，时间全消耗在“对稿”而不是“做事”上。

1.1 来回拉扯的隐性成本

你以为成本只是多聊几句？不是。每一次“还原了吗”背后，都至少藏着三个隐形消耗。

第一是上下文切换。开发写代码的时候脑子里本来是一套组件结构，突然被打断去看设计稿，再回来时思路断掉了。一天来几次这种打断，代码产出质量肉眼可见地下降。

第二是标注被反复读取。设计师在蓝湖里给的间距、字号、透明度、阴影参数，开发每次都要重新核对。问题在于你昨天刚对过的东西，今天在另一个页面里又出现了一遍，你还得再对一遍。大量重复劳动。

第三是默认为“口头确认”。小美问“还原了吗”，我回“还原了”，她信吗？她当然得自己去看。口头确认变成了一种表演，真正的验证闭环根本没有形成。

1.2 为什么这件事能用 AI 解决

前两年大家聊 AI 编程，最多就是让模型帮你写个函数、补个测试。但到了 Cursor 这一代工具，AI 已经能主动调用外部工具了。它不再是一个只能读代码的文本模型，而是可以拿着你的 API Token 去访问蓝湖、拿设计标注、找切图资源的“一个人工智能工程师”。

这件事的关键前提是协议：MCP，Model Context Protocol，模型上下文协议。简单理解，MCP 就是给 AI 装了一根“USB 线”。以前 AI 吃不到外部的结构化数据，只能靠你把截图、描述粘贴进对话里；有了 MCP，AI 可以直接连接到蓝湖的设计数据，像我们用浏览器看蓝湖一样，把标注拿回来。

所以当 Cursor 接上蓝湖之后，整个流程就变成：你给 AI 一句话需求，AI 自己去蓝湖查设计稿对应的 frame，读取标注，再生成代码。你不用去翻蓝湖，AI 替你翻了。甚至写完代码之后，AI 还能反查设计稿规格，做一遍自查。这就是我决定搭这条链路的核心原因：把“查证”这件事从人身上剥离掉。

2. 动手前先理清楚：蓝湖有什么、MCP 能干什么

动手之前，我先把两边的能力边界框了一下。蓝湖本身不只是一个“看图工具”，它背后沉淀的是完整的 UI 标注数据。MCP 也不是说把整个蓝湖的数据库都怼给 AI，那就乱了。设计集成方案要先把数据边界和权限边界定清楚。

2.1 蓝湖的数据结构

蓝湖上承载的数据，往细了说有这几层：

• 团队，对应一个公司或一个部门的空间集合；
• 项目，同一个产品线下的设计稿集合；
• 页面/Frame，单个设计稿，通常对应一个页面或一个组件；
• 图层与标注，设计稿里的具体元素，包括位置、尺寸、颜色、圆角、阴影、字号、字体、透明度等；
• 切图资源，开发实际要用的 PNG/SVG 资源。

整体结构跟你用过的 Figma、Sketch 差不多，本质是一个嵌套的树形文档。以前 AI 编程工具只能“看见”你单独贴进去的一张设计稿截图，但截图里的参数它没法直接读取。要让它准确拿参数，就必须走 API 拿到标注数据。

2.2 我给 MCP 划的三条边界

接 MCP 前，我先决定了要让 AI 用哪些能力。不是所有蓝湖上的东西都适合直接丢给模型。

我的做法是只开放三类工具：

• 查项目列表：按名称或 ID 检索蓝湖里的项目，方便 AI 定位你要的是哪一版设计稿；
• 读 Frame 标注：根据 Frame ID 拉取设计稿中所有元素的标注数据，尺寸、颜色、字号、圆角全都有；
• 取切图资源：拿到指定切图的 URL，后续可以下载到本地或让 AI 根据切图尺寸生成对应的图片引用代码。

为什么只开放这三类？因为我把 MCP 服务设计成只读模式。AI 能拿数据、能查标注，但不能往蓝湖里写东西。你想想，如果你给 AI 开了写权限，它哪天在理解的某个漏洞下把标注尺寸改乱了，视觉回归直接灾难。只读权限既能满足 90% 的代码生成场景，又能把风险控制在最小。

3. 蓝湖 MCP 部署全过程

部署这部分是重头戏。很多朋友卡在“不知道怎么让 Cursor 和蓝湖连起来”，说白了就是 MCP Server 没有跑起来。我把完整路径写下来，你照着配基本不会有问题。

3.1 第一步：去蓝湖开放平台拿 Token

蓝湖提供了开放平台，可以创建自己的应用并拿到调用 API 的凭证。这一步各团队可能有差异，但核心流程是差不多的——在开放平台创建应用，拿到 AccessToken，把权限范围限定在“读取设计数据”。

我当时最担心的是权限粒度太粗，所以创建应用的时候特意找了最小权限集，只给读取相关权限，不给任何写权限。

注意：Token 是敏感信息。千万不要直接把 Token 硬编码在前端环境变量里，也不要随意贴到公开仓库。后面 MCP 配置里我用的环境变量注入方式，Token 只存在于本地配置中，不会进入代码仓库。蓝湖开放平台通常会提供组织 ID 或公司 ID，你一并记下来，后面配置 MCP 服务器时要用到，用来限定 AI 只能查到你团队设计稿。

拿到这串信息后，我先在浏览器里用 CURL 简单测试了一下接口连通性。如果这一步就 401，后面配置也不用看了，Token 的权限肯定没给对。

3.2 第二步：部署 MCP Server

蓝湖的 MCP 服务器有两类用法。一类是全托管，直接通过标准 npx 拉起社区或官方提供的 MCP 服务；另一类是本地自建，把你自己的服务目录注册给 Cursor。

我当时用的方案是本地起一个 Node 编写的 MCP 服务，这样原因很简单：一是便于加日志排查，二是我还想给 MCP 工具加一点自定义提示词，让 AI 知道怎么传 Frame ID。你如果不想折腾，直接用标准包会更快。

以标准 npx 模式为例，Cursor 里的mcp.json配置长这样：

{ "mcpServers": { "lanhu": { "command": "npx", "args": ["-y", "lanhu-mcp-server"], "env": { "LANHU_API_TOKEN": "你的AccessToken", "LANHU_TEAM_ID": "你的团队ID" } } } }

如果你想自建服务器，则是用 Node SDK 把蓝湖 API 包一层。我当时写了一个精简版服务，核心的逻辑大概是：根据 Frame ID 请求蓝湖标注接口，把返回的 JSON 整理成 AI 更容易理解的文本。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; const server = new McpServer({ name: "lanhu-mcp", version: "1.0.0", }); server.registerTool("read_frame_spec", { description: "读取蓝湖中指定Frame的设计标注，返回元素尺寸、颜色、圆角、阴影、字号等信息", inputSchema: { type: "object", properties: { frameId: { type: "string", description: "蓝湖Frame的ID" }, }, required: ["frameId"], }, execute: async ({ frameId }) => { const spec = await lanhuApi.fetchFrameSpec(frameId); return { content: [{ type: "text", text: JSON.stringify(spec) }] }; }, });

这段代码你不需要照抄，重点想表达的是：MCP Server 本质就是一个将蓝湖 API 包装成“工具”的进程。AI 需要调某个工具时，MCP 协议负责把调用参数传过来，服务内部再去请求蓝湖拿到数据，最后返回给 AI。

服务写完或安装好后，本地node或者npx起来，只要进程不退出，Cursor 就能连上。

3.3 第三步：用 MCP Inspector 验证服务

这里强烈推荐你花十分钟用一下官方调试工具：@modelcontextprotocol/inspector。它可以连接到你的 MCP 服务器并列出所有工具，还能手动模拟调用。

npx @modelcontextprotocol/inspector node dist/index.js

打开 Inspector 页面后，左侧能看到当前 MCP 服务器注册了哪些工具，点一个工具就能看到它的描述和参数结构。我当时验证read_frame_spec的时候，手动填了一个真实 Frame ID，返回结果里把字体、颜色、间距全部列出来了。确认这一步没问题，才接着去配 Cursor。

这一步千万别跳过。很多人配置完发现 Cursor 里什么都没有，就是因为 MCP 服务器本身就没启动成功。用 Inspector 先能在“没有 Cursor 干扰”的情况下定位问题，省一大半排查时间。

4. Cursor 里把蓝湖接上

MCP Server 跑起来了，接下来就是让 Cursor 找到它。Cursor 的 MCP 配置支持两种粒度：一种是全局配置，所有项目都能用；另一种是项目级配置，只在当前代码仓库生效。我当时用的是项目级配置，因为蓝湖接入主要服务于前端项目，没必要所有仓库都读取一遍设计稿。

4.1 配置路径写法

在项目根目录下新建.cursor目录，里面放一个mcp.json，内容如下：

{ "mcpServers": { "lanhu": { "command": "node", "args": ["D:/work/tools/lanhu-mcp/dist/index.js"], "env": { "LANHU_API_TOKEN": "你的AccessToken", "LANHU_TEAM_ID": "你的团队ID" } } } }

如果你用 npx 方式，命令改成：

{ "mcpServers": { "lanhu": { "command": "npx", "args": ["-y", "lanhu-mcp-server"], "env": { "LANHU_API_TOKEN": "你的AccessToken", "LANHU_TEAM_ID": "你的团队ID" } } } }

注意 Windows 环境的路径分隔符，建议绝对路径加上引号，避免空格导致解析错误。配置完成后，重启 Cursor，打开设置里的 Features 或者 MCP 面板，正常情况下能看到lanhu这个条目以及它下面暴露的工具列表。

重启这个动作我一开始没做，怎么配都觉得没生效，重启后一切正常。这算是 Cursor 调试的常识性操作，但确实很容易被忽略。

4.2 让 AI 使用工具时的权限设置

Cursor 对 MCP 工具默认不会自动运行，它会先询问你是否允许。第一次对话时如果 AI 说“我需要调用 lanhu 的工具”，界面上会弹出确认按钮。你可以勾选“总是允许”，也可以每次让 Cursor 询问。

我的建议是：对只读工具放开允许。因为 MCP 服务本身我已经设成只读，工具也不会修改蓝湖数据，放开权限可以有效减少对话中的确认打断。尤其是用 Agent 模式连续写多个组件时，如果每个工具调用都要确认一次，那体验就废了。

但有一种情况我建议保持询问：如果 MCP 服务里加了带写操作的工具，比如同步设计标注到代码注释、把 AI 生成的代码回传蓝湖等等，那还是让 AI 每次确认比较好。安全意识始终不能丢。

5. 真实工作流：从设计稿到代码，加上还原自查

部署和配置都搞定了，接下来看这东西到底怎么用。我实际跑了一阵子之后，沉淀出三种高频工作流：生成代码前主动取标、按切图实现视觉样式、写完后做还原自查。三个场景分别对应不同的提示词写法和工具调用方式。

5.1 场景一：生成代码时主动拉设计稿参数

以前写页面头部，流程是我先打开蓝湖找下 Header 对应的 Frame，把里面的按钮宽度、字号、色值一个一个抄进代码。现在不用了。我直接对 Cursor 说：

请先调用 lanhu 查项目的工具，找到项目“商城系统”里的“订单列表页”，然后读取页面 Header 的完整标注，再根据这些标注帮我实现 src/components/Header.vue。间距、字号、色值严格照标注来，别自己发挥。

Cursor 会自己决定按什么顺序调用工具。它先搜项目，再找到 Frame，然后再读取 Frame 标注，最后把数据融合成代码。我在对话里看着它一步步执行，最终生成的组件代码里，按钮色值、圆角半径、间距 padding 和我从蓝湖抄的完全一致，基本不需要再人工核对。

这里有个小技巧：让 AI 在返回代码的同时附上一段“设计规格摘要”。比如让它把读取到的关键参数整理成表格，贴在对话里。好处是你一眼就能看出 AI 是否正确理解了标注，避免它在代码里取错了某个颜色值。

最后请把你读取到的关键设计参数（主色、间距、圆角、字号）整理成一览表，并和实现的代码一一对应。

这个习惯相当于多了一层“审计”，特别适合在多人协作项目里使用。

5.2 场景二：按切图实现视觉还原

有一部分样式是切图驱动的，比如复杂的渐变背景、带质感纹理的图标、品牌Logo。标注里的颜色值有时不能完整还原视觉，就需要直接用切图资源。

连接蓝湖之后，AI 也能帮你取切图资源。我用的提示词是：

从蓝湖 project_id=123 的页面里找到“个人中心”这一帧，获取背景装饰图的切图资源，放到项目的 public/images/ 目录中，然后基于该图生成 CSS 背景代码。

前提是 MCP 服务里实现了取切图资源的工具。实测下来，AI 返回切图 URL 后，你可以在本地手动下载，也可以让 Cursor 的终端工具接着执行下载命令。这一步能省掉“逐个切图下载”的机械劳动。

5.3 场景三：写完代码后自动做还原自查

这个场景是我最满意的。以前写完组件，小美转头问我“还原了吗”，我嘴上说“应该行吧”，心里根本没底。现在我会在代码实现完以后，再让 Cursor 做一轮回溯检查：

现在别写新的代码，你以视觉还原审核员的身份，把刚才生成的 src/components/OrderCard.vue 和蓝湖里“订单卡片”Frame 的设计标注做逐项比对。重点检查：间距是否一致、字号是否一致、颜色是否偏差超过阈值、圆角和阴影是否相同。发现不一致的地方，逐条列出差异和建议修正值。

这个思路本质上是用 MCP 实现了“静态检查工具”：AI 把设计稿标注视为基准，再把生成的代码视为待验证对象，逐项比对。实测确实能发现不少问题，比如我故意在代码里把一个 12px 的字号写成 14px，AI 很快就列出来并标注了偏差。

不过这里要提醒一句：AI 的“逐项比对”不是真的像素级视觉回归，它依据的是标注数据，所以更适合检查参数层面的不一致。如果你想验证真实的像素布局是否一致，仍需跑一轮截图对比工具，但站在人工检查的角度，它已经把 80% 的机械核对工作代替掉了。

5.4 批量组件的还原自查

更进阶的玩法是让 AI 对整批组件做一次“巡检”。我有一次接手老的促销活动页，里面好几张商品卡的样式都是复制粘贴改的，间距和圆角早就乱掉了。我把蓝湖设计稿里对应 Frame 的信息交给 Cursor，让它把所有卡片组件逐一对照设计稿检查，最后输出一张差异清单。

那次检查用了不到五分钟，而人工对照至少得一个小时。差异清单里甚至指出了某个卡片里“价格文字与标签间距多了 4px”这种我以前绝不会注意的细节。改完之后，小美那周都没找过我。

6. 踩坑记录与排查速查表

方案虽然好用，但我从零搭的时候没少被坑。下面这些典型问题，记录给后来的兄弟们，省得你再走一趟。

6.1 Token 权限不足导致 401

第一次配完后测试 MCP，工具调用直接 401。我一开始以为是 Token 写错了，反复检查配置后发现是在蓝湖开放平台创建应用时没有勾选“读取设计数据”权限。权限不足在 API 层面表现就是 401，不一定是 Token 不对。

排查思路很简单：先用 CURL 手动请求蓝湖 API，如果 CURL 也 401，问题就在 Token 权限上；如果 CURL 正常但 MCP 调用失败，那问题出在服务端环境变量没传对。

6.2 MCP 服务在 Cursor 里没出现

配置好mcp.json后，打开 Features 面板却看不到lanhu。这个问题的原因十有八九是进程启动失败。

我当时犯的错是没把本地 Node 脚本路径写对，因为路径里有中文目录名，Cursor 解析失败。把路径改成英文目录后恢复正常。另外，如果你改了配置但 Cursor 没有重载，重启 Cursor 也能解决。

6.3 大 Frame 标注读取超时

有些设计稿是整页级别的，Frame 里图层特别多，MCP 服务一次拿回全部标注数据，返回给 AI 时容易超时，AI 会报“tool execution failed”之类的错误。

我的做法是在 MCP 服务里做了一次数据裁剪：只返回跟当前任务强相关的元素属性，过滤掉一些无关的辅助图层。再不行就提示 AI 用“按区域获取标注”的方式，把 Frame 拆分成上中下几个区域分别读取。这一步对稳定性提升非常明显。

6.4 Token 硬编码进配置仓库的风险

最后一个是安全向的提醒。如果你的项目仓库是公开的，千万别把带有真实 Token 的mcp.json提交上去。我当时用的是本地配置文件，并且把配置文件加入了.gitignore，仓库里只保留一份带占位符的示例。

可以这样处理：提交一份.cursor/mcp.example.json，里面放LANHU_API_TOKEN: "replace-me"字段，然后把真实的mcp.json加入忽略列表。同事拿仓库代码时，照着示例替换即可，安全又方便。

我还做了一个小工具，定期轮换蓝湖 AccessToken，进一步降低泄露风险。虽然麻烦一点，但这类涉及开放平台凭证的东西，宁可谨慎也不要用“反正没人看到”的侥幸心态。

7. 常见问题速查表

我把最常遇到的情况整理成一张速查表，方便你遇到问题时快速定位。

这张表基本覆盖了接入初期的绝大多数问题。之后如果再遇到新的问题，第一反应永远是先看本地 MCP 服务的控制台日志，它会把每次调用的报错原因输出得清清楚楚。这比在 Cursor 里猜要高效得多。

8. 这条链路还能走多远

接到现在，它已经不是我一个人用的小工具了。我们前端组现在有三位同学都在用 Cursor 连着蓝湖的 MCP，写新页面时 AI 自动取设计稿参数，写完自动核对。小美那边也省事了不少，她只需要在蓝湖更新设计稿，代码那边就会跟着调整，而不是反复截图发到群里。

我自己的体会是，这套链路真正的价值不只是省动作，而是把设计和代码之间那条“只能靠人肉翻译”的链路打通了。以前设计师标注再清楚，代码里的实现最终还是靠人读、人记、人搬。现在标注数据和代码生成之间有一条直接的管道，AI 在中间扮演了一个不知疲倦的翻译官。

往后我打算继续往里加几件事，比如把蓝湖的设计变量导出成项目里的 Design Token，让 AI 生成代码时统一引用 Token 变量而不用硬编码色值；再比如让 AI 在每次代码提交前跑一次“设计规范校验”，把配色、圆角、阴影这类风格约束做成自动门禁。

最后再分享一句我的真心话：技术方案再折腾，最终服务的是团队里真实的协作关系。设计师追问“还原了吗”不是她不信任你，是因为她确实没有更好的办法了解代码状态。现在这个责任被 MCP 接过来了，AI 能在代码生成那一刻就把还原度校准到位。咱们开发者能做的，就是把主动权握在手里，不再让自己卡在“对稿”这种纯体力活上。