企业官网建设流程全解析

1. 项目背景与核心思路拆解

前端圈子里有一句很真实的话：不怕写代码，怕改设计稿；不怕改设计稿，怕设计师追着问"还原了吗"。我做前端这几年，最耗精力的从来不是技术难点，而是和设计稿之间的"对齐拉锯战"。直到最近我把 Cursor 接到了蓝湖上，用MCP协议打通了设计数据这条链路，情况才真正开始转变。

坦白说，这不算什么高深的技术项目，但它确实解决了一个很实际的协作痛点。下面我会把整个项目的背景、部署过程、实操细节、踩坑记录都展开说一下，希望能帮到同样被"还原度"折磨的朋友。

1.1 这个项目到底解决了什么问题

传统的前端协作流程是这样的：设计师在蓝湖上传设计稿，添加标注，开发人员打开蓝湖，逐个图层查看尺寸、颜色、间距、切图资源，然后回到编辑器里手写代码。写完后再回到蓝湖里对照，看哪个间距差了2像素，哪个字的字重不对。

这个流程本身没什么问题，问题出在它极其消耗注意力。痛点拆开来看有这几层：

• 开发要频繁在IDE和浏览器/蓝湖之间切换，标注信息全靠肉眼识别，一个16px间距看漏了就是失误。
• 设计师也不轻松，既要确认还原度，又要花时间描述"这里再往上一点""那个按钮字号小了"，沟通成本非常高。
• 等到反馈回来，改完又要重新对一遍，循环往复，没有人喜欢这种重复劳动。

把Cursor接到蓝湖上，本质上就是让AI编程助手能直接"读"蓝湖的设计数据。AI不再是只知道代码不知道设计的工具，而是能主动去查设计稿的标注、颜色、字号、切图资源。开发只需要告诉Cursor"帮我把这个页面按蓝湖设计稿还原"，剩下的标注读取、样式生成、资源下载都可以由AI代劳，省掉的是从一堆图层里翻找某个像素值的时间。

1.2 核心关键词拆解：Cursor、蓝湖、还原

这个项目涉及三个关键角色，我把它们拆开讲一下。

Cursor：基于VS Code内核的AI代码编辑器，核心卖点是Agent式编程，能自己规划任务、调用工具、读写代码。它的MCP支持相当成熟，可以方便地接入外部数据源。

蓝湖：设计师和开发之间的协作平台，承载设计稿在线评审、尺寸标注、切图下载、版本管理。设计数据高度结构化，图层树、样式属性、标注信息都有清晰的API可以访问。

还原：指前端实现与设计稿的视觉一致性，包括布局、间距、色彩、字号、图标、切图等。还原度是前端质量的直接体现，也是设计开发协作中沟通最频繁的话题。

这三者连起来，就形成了一条过去必须靠人肉搬运的链路：蓝湖里保存的设计决策，通过MCP协议变成Cursor上下文里可查询的数据，AI据此生成贴近设计稿的代码。我们做的其实就是把"人肉看标注"这一步自动化了。

1.3 为什么选MCP而不是"截图给AI看"

可能有人会说：我直接把蓝湖设计稿截图发给Cursor不就行了？我试过，效果非常不稳定。截图方案的问题在于：

• 像素级标注无法精确读取，AI要从图片上"猜"尺寸，误差很大。
• 多图层重叠时图片根本无法表达图层关系。
• 切图资源仍然需要手动处理。
• 设计稿一更新，截图又要重新生成一遍。

而MCP（Model Context Protocol）是一个标准化的协议，相当于给AI装上了一个"插座"。蓝湖侧把设计数据通过MCP服务暴露出来，Cursor作为客户端去查询。AI拿到的是结构化的JSON数据：图层树、样式属性、标注信息、资源地址。这比任何截图都可靠，也省去了中间人的转述损耗。

1.4 方案选型的另一条暗线：降低AI生成代码的幻觉率

这一点我自己深有体会。Cursor写业务逻辑很强，但写还原度高的小组件时经常翻车，因为AI默认会用自己记忆里的UI库套路来写，导致实际结果和设计稿差距很大。

接入蓝湖数据后，AI能拿到精确的设计Token——颜色是#1890FF还是#1677FF，圆角是8px还是12px，都能直接查证，幻觉空间被大幅压缩。这也是我把这个项目称为"用数据喂AI"而不是"用提示词调教AI"的原因。数据对了，AI生成的东西自然就稳。

2. 环境准备与部署方案设计

接入之前需要把环境准备好。这个项目的软环境要求不算高，但要保证每一步都不出岔子，建议按照下面的清单逐项确认。

2.1 需要准备的软环境

实际落地需要准备这些：

这些看起来多，实际配置十分钟能搞定。最花时间的反而是"项目里到底哪个画板叫登录页"这种问题，建议提前和设计师对一下画板命名规范。

2.2 MCP里三个角色的关系

MCP把一次数据交互拆成三部分：

1. MCP Client：运行在Cursor里，负责发起查询、接收结果。
2. MCP Server：运行在蓝湖数据侧或本地，负责把蓝湖的数据翻译成AI能理解的结构化格式。
3. 协议本身：定义"工具如何调用、资源如何暴露"。比如AI调用一个"获取画板图层树"的工具，MCP Server就去蓝湖API拉数据并返回结构化结果。

这个结构用类比来说，MCP Server就像是给蓝湖装了个"点餐窗口"，Cursor是顾客，MCP协议是菜单和账单规则。没有窗口，顾客再饿也没法直接去厨房拿菜——对应到我们的场景，没有MCP，AI再强也读不到蓝湖内部数据。

2.3 stdio和SSE/HTTP怎么选

部署MCP服务有两种主流方式：

• 本地方式（stdio）：MCP Server作为本地进程启动，由Cursor拉起。适合个人开发、局域网内使用，数据不出本机，配置简单。缺点是每台电脑都要装一次，不适合团队统一维护。
• 远程方式（SSE/HTTP）：MCP Server部署在一台服务器上，多人共用一个服务。适合团队使用，但需要处理鉴权、证书、Token安全等问题。

我的建议是：先本地跑通，再考虑团队。前期调试时本地模式日志好排查，出了问题看得明白。团队化部署时再上远程，并给每个成员的Token做最小权限分配。

3. 实操全过程：安装与配置

接下来是整套方案里最关键的部分，一步一步说清楚。我会尽量把命令和配置都贴完整，但具体包名和路径可能因为版本迭代有调整，以你实际使用的蓝湖MCP实现为准。

3.1 拿到蓝湖的访问凭证

先到蓝湖团队的"开放平台"或"开发者中心"创建应用。这个入口在不同版本里位置略有差异，但逻辑是一样的：创建一个应用后，系统会给你一串API Token，这个Token代表你对蓝湖项目的读取权限。

创建Token时注意两点：

1. 权限尽量最小化，只勾选"读取"权限。MCP场景下我们只需要读取设计稿数据，不需要写操作。
2. Token安全：不要提交到Git仓库，写入本地配置文件或者环境变量。我见过有人直接把Token贴到配置里然后同步到公开仓库，没过多久就被爬虫扫到了，这个真的不能犯。

拿到Token后，还需要记录团队ID（TeamID）和设计稿ID。设计稿ID通常在蓝湖分享链接里：链接的一串数字就是设计稿ID。团队ID在团队设置页面可以看到。

3.2 部署蓝湖MCP服务

社区里已经有蓝湖MCP的Node或Python版本，部署思路是统一的：启动一个MCP Server进程，把蓝湖API的Token和团队信息传进去。

# 示例：使用 npx 启动蓝湖MCP服务（具体包名以你选择的实现为准） npx lanhu-mcp-server --token 你的蓝湖API_Token --teamID 团队ID

启动后如果控制台没有报错，说明服务已经就绪。此时可以先用命令行测一下，确认能拉到设计稿列表，再接入Cursor。如果找不到合适的包，也可以照着MCP SDK自己写一个简单Server，核心就是调蓝湖Open API，把返回的图层树、标注组装成MCP协议里的资源。做这件事本身不难，难的是处理好分页和大画板的数据量。

注意：启动MCP服务时，尽量用配置文件保存Token，不要直接写在命令行参数里。命令行历史中会留下记录，存在泄露风险。

3.3 在Cursor中注册MCP服务

打开Cursor，进入设置，找到MCP配置。Cursor支持界面添加和配置文件两种方式，社区里比较通用的是配置文件方式：

{ "mcpServers": { "lanhu": { "command": "npx", "args": [ "lanhu-mcp-server", "--token", "你的蓝湖API_Token", "--teamID", "你的团队ID" ], "env": {} } } }

保存后回到Cursor界面，应该能看到MCP服务状态变成Ready。点开MCP列表，里面会列出当前可用的工具，比如"获取画板列表""获取标注信息""获取切图地址"之类的名称。看到这些工具，就说明蓝湖的数据已经打通到Cursor了。

3.4 顺手把Cursor环境调顺手

很多人都在搜"cursor中文怎么设置"，这里一起说了：

• 界面中文：Cursor新版在 Settings > Appearance > Language 里可以切中文，也可以直接装官方中文语言包扩展。
• 回复语言：在项目根目录建一个规则文件（比如.cursorrules），写一行"回答一律使用中文"。这样AI生成的注释和说明就都是中文。
• 规则文件里还可以补一条"涉及样式实现时优先参考MCP中蓝湖的标注数据"，这能确保AI在新会话里也自动去查蓝湖，而不是凭记忆写。

这三个小设置能让整个协作体验顺很多，不用每次开场白都重复交代一遍语言和风格偏好。

4. 实战复盘：从一份登录页设计稿到前端代码

理论和配置都齐了，接下来走一遍真实场景。我拿一个移动端登录页来完整演示这个流程，过程中会把提示词和结果都展示出来。

4.1 选一个真实的页面来测试

设计师在蓝湖里已经把页面分好了组：背景图、Logo、输入框、登录按钮、第三方登录入口。这些图层在蓝湖里都有清晰的名称和样式标注。

传统做法是：我打开蓝湖，看标注，记一下按钮宽多少、高多少、圆角多少，然后回编辑器手写。信息一多难免遗漏，改版三次之后标注就跟实际版本对不上了。

现在过程变成了：我给Cursor一句话，让它"去蓝湖找到项目里的登录页设计稿，读取登录按钮和输入框的完整标注，然后生成对应的React组件"。

4.2 让Cursor拉取标注数据

我实际用的提示词大致是这样：

"请通过MCP工具连接蓝湖，找到项目XXX中名为'登录页V3'的画板。我需要以下信息：整个页面的背景色值、页面元素的布局间距、登录按钮的尺寸、圆角、字号、字重、按钮内文本颜色，以及输入框的边框、placeholder样式。请以结构化的方式整理后，作为编写React组件时的设计依据。"

Cursor这时会调用MCP工具，后台去蓝湖拉数据。我观察到它先请求画板列表，找到目标画板后再请求图层树，然后逐层读取标注。整个过程在网络正常时大概几十秒。

返回的数据里会包含类似这样的信息：

• 登录按钮：宽度300px，高度48px，边框半径8px，背景色#3478F6，文字颜色#FFFFFF，字体大小16px，字重500
• 输入框：高度48px，边框1px solid #E5E6EB，圆角8px，placeholder颜色#999999

这些数据不是AI猜的，是蓝湖标注文件里真实存在的值。拿到之后，生成的样式自然就准确。

4.3 生成组件并迭代

基于返回的标注，Cursor生成的第一版组件已经能实现大约80%的视觉还原。剩余20%主要体现在细节：图标和字体的间距、阴影的模糊度、状态的切换效果。

这部分我会继续追问，比如"输入框聚焦时的边框颜色在蓝湖里有定义吗""登录按钮的hover状态是否有设计"，Cursor会再去蓝湖查对应状态或补充说明。如果设计稿里没有定义hover状态，它会如实告诉你，而不是自己编一个颜色。这点很重要，因为AI编出来的样式会污染后续的设计一致性。

4.4 切图资源的自动化处理

还原页面绕不开图片资源。蓝湖MCP还可以返回切图资源的下载地址，AI拿到地址后可以直接下载到项目assets目录，再在代码里引用。这样整个资源获取过程也从"打开蓝湖手动下载"变成了"AI自动拉取"。

实际操作时这里有个坑：蓝湖切图的导出选项有多种（Web、iOS、Android），默认返回的可能是Web 2x图，尺寸和普通Web 1x不一致。所以给Cursor的指令里最好写清楚"导出为Web 1x和2x"，避免后面还要手动调整。

5. 常见问题与排查技巧实录

接入过程中肯定会遇到各种问题，这块我把实际踩过的坑整理成一个表格，方便你遇到问题时快速对照。

5.1 高频问题速查表

5.2 权限与安全边界

这个方案里最容易翻车的是安全。蓝湖Token一旦泄露，等于把公司设计资产暴露给别人。我的做法是：本地开发时Token写进系统环境变量，不进Git；团队使用远程MCP时，在网关层做IP白名单和用户身份透传，每个成员用自己的身份凭证，便于审计。

另外，设计稿的读取权限和团队权限是两个维度。即便MCP服务正常，某个成员没有某个项目的权限，也会读取失败。所以调试时遇到"权限不足"类错误，先查账号在蓝湖里的角色，再查MCP配置。

5.3 提示词层面的一些经验

复盘几次实操，我对提示词的总结是：给Cursor限定信息来源，而不是让它发散。

无效示范："帮我写一个登录页，风格简约一点。"——AI会按自己的理解生成一个"看起来还行"的页面。

有效示范："用蓝湖标注数据还原登录页，不要自己发挥配色和布局；所有色值、间距、字号都从标注里取；如果标注里没有的字段，列出来让我确认。"

这里的关键词是"不要让AI自由发挥设计决策"。AI可以做还原执行者，但不要让它在未获授权的情况下做设计决策者。否则你会发现它用一个你觉得好看但和设计稿完全不同的布局回复了你。

5.4 会话与性能管理

接入MCP之后，每次对话都会携带不少上下文数据，Token消耗会明显上升，尤其是画板图层多的时候。我的做法是：

• 一个会话专注处理一个页面，完成后开新会话，避免上下文越滚越大。
• 做完一阶段就清理MCP服务状态，避免后台一直挂着连接。
• 如果只是要看某个按钮的色值，让Cursor查具体图层，不要说"把整个画板的数据给我"。

这样既能拿到结果，又不会让对话串太长导致费用和响应时间增加。实测下来，同样的登录页，分块查询比整树抓取省大概三成Token。

6. 工作流复盘与扩展想法

技术层面已经跑通了，最后聊聊这套方案对整个工作流的影响，以及我接下来打算往哪些方向继续做。

6.1 改造前后的流程对比

这轮改造下来，最大的变化不是"少敲几行代码"，而是消除了重复的信息搬运。以前每个像素级的细节都要经过人眼扫描、记忆、转写三道工序，现在这些工序集中到一段可控的提示词里，改版也只是换个画板ID的事。

6.2 哪些团队适合这套方案

据我这段时间的体感，这套方案最适合下面几种情况：

• 设计稿规范度高、图层命名清晰的团队。图层命名混乱时，AI查数据的效率会被严重拖累。
• 组件库不够强、经常要从头写样式的项目。
• 设计师和开发不在同一办公区的远程协作团队，沟通成本高的场景。
• 多端适配项目，一套设计稿要还原到Web、小程序、App，单位换算靠人工很容易出错。

反之，如果你们已经有一套成熟的设计系统，组件库覆盖了90%的页面还原，开发几乎不用看标注，那这套方案的价值就弱一些，接入的意义更多在于"查漏补缺"而非"流程再造"。

6.3 往上还能长成什么样

我下一步打算做的事情包括：

• 把MCP返回的标注数据固化成一个"设计Token JSON"，让组件库动态读取，实现设计稿更新后样式变量自动同步。
• 给团队搭一个远程MCP服务，把蓝湖数据接入到CI流程里，让还原度检查在合并请求阶段自动跑一遍，做可视化的diff报告。
• 把切图资源接入CDN上传流程，AI拿到地址后直接完成上传和引用，整个资源链路彻底无人化。

这几件事都还是基于同一个MCP连接做的延伸，核心基础设施就是这次搭建的这条"Cursor-蓝湖"链路。

关于这套方案，我最真实的感想是：技术难度并不高，MCP的接入本身没有太多魔法，真正有价值的是它改变了前端拿到设计信息的途径。以前我们靠眼睛、靠记忆、靠来回追问，现在可以靠协议、靠数据、靠AI自动查询。最后再分享一个小细节：每次让Cursor从蓝湖拉取数据前，我都会在提示词里加一句"请确认你读取的是最近版本，如果画板有多个版本，以标注为V3或最新日期的为准"，就因为这一句，少了很多改版后对错版本的返工。也希望你们接入之后，设计师跑来问你的那句话，从"还原了吗"变成"你是怎么做到这么快的"。