企业官网建设流程全解析

直接贴一段背景：我是那种每天都要被设计师在群聊里@的前端。早上九点半刚到工位，一张设计稿截图丢过来，配一句“还原了吗”；下午三点又补一句“这个页面的间距和设计稿对一下”。说实话，这问题不是不能答，而是答起来要花很多时间，先打开蓝湖、再切到代码、比对一遍标注、最后回复一句“还在调”。来回几次之后，我决定换个思路——能不能让 Cursor 自己去看蓝湖上的设计稿，直接按标注写代码，把“还原了吗”这个问题的上下文一次性喂给 AI。于是就有了这次把 Cursor 接到蓝湖上的实践。

这篇文章不是什么官方集成教程，更像是我自己从一个“被追问的前端”变成“让 Cursor 替我看图”的真实记录。里面包含我为什么选 MCP 这条路、蓝湖侧怎么部署、Cursor 侧怎么配，以及跑通之后我才发现的好用用法和坑。给同样被设计稿和还原度折磨的开发者参考。不敢说终极方案，但对我这个工作习惯来说，现在设计师真的很少再追着问“还原了吗”了。

1. “还原了吗”背后，其实是一连串信息断点

1.1 每次被问“还原了吗”，我在心里跑完的排查流程

先说结论：这句话翻译成开发语言，不是一句问候，而是一个需求——“请把设计稿的视觉细节、间距、字号、圆角、阴影，和当前代码的落地情况做一次对比，并且告诉我结论”。在没有工具支撑的情况下，我得手动打开蓝湖网页版，找到对应项目，定位到页面，看一遍左侧的标注信息。间距、行高、字号、渐变色、圆角、图片裁切，每一条都要单独看。

这个过程有两个痛点。第一个是慢，每看一眼标注就要切一次窗口，几十个标注看下来，半小时没了。第二个是容易遗漏，标注面板里的数值一多，眼睛一花就跳过了。然后等我改完代码，通常已经过去了两个小时，设计师再过来看，发现版本更新了，标注也跟着变了，等于又白看一遍。

真正让关系紧张的不是技术难度，而是这些断点没人愿意承担。设计师觉得标注都放在蓝湖上了，你怎么不看；我觉得蓝湖上的信息没法直接进编辑器，看一遍和没看差不多。问题不是谁对谁错，而是缺少一座桥，把蓝湖的标注数据送进 Cursor 这个写代码的上下文里。

1.2 蓝湖在还原链路里到底承担了什么角色

蓝湖在不少团队里是设计与研发之间的约定中转站。设计稿传上去之后，程序员拿到的不再是 Photoshop 源文件，而是一组带标注、带切图、带版本记录的在线画板。设计师把红线标好、间距注明，前端只需要按着标注“抄作业”。

但“抄作业”的前提是作业抄得到。蓝湖的网页端信息很全，切图可以下载，标注可以逐项查看，可问题是这些数据没有主动流到开发工具里。浏览器里的一个个标注，和 IDE 里的一个个样式属性，听起来是一回事，实际却是两个体系。我平时要么手动抄，要么截图给 AI 看，AI 看到的是像素，不是数据。

我要的是那种“数据到数据”的通道：让 Cursor 直接读取蓝湖上的标注结构、颜色 token、字体信息、切图地址，而不是我作为中间人把看板上的信息翻译成提示词。这个想法刚冒出来的时候，我知道常规做法很难满足，于是开始查蓝湖的开放在线能力，也顺便搜了一圈别人怎么接。顺着热搜词“蓝湖 mcp 服务怎么部署”这类关键词翻下来，发现 MCP 正是这个通道的正确打开方式。

2. 方案选型：为什么最终选了 MCP 这条路

2.1 先摆上我能想到的三条替代路线

在决定做 MCP 之前，我认真的列过三个看上去更省事的方案，这里展开说说，也帮你避开我走过的弯路。

第一个方案：直接把蓝湖截图拖进 Cursor 的多模态窗口里，让 AI 看着图写代码。说实话，这个方案我用了小半个月，效果不稳定。截图能看懂布局，但看不透精确数值，AI 只能“估”，比如它猜圆角是 12 像素，实际设计稿是 16 像素，视觉上差别不大，但还原度就是不合格。而且一次对话只能丢几张图，一个完整页面十几张截图塞进去，Prompt 全都炸了。

第二个方案：人工把蓝湖标注复制到提示词里。只适合局部组件，比如 “按钮背景色 #1677FF，高度 32px，圆角 6px”，AI 能准确理解。但一个完整页面动辄几十条标注，全手动复制就变成纯体力活，而且蓝湖标注一更新，你又得重新复制一遍，等同于没有接入。

第三个方案：通过蓝湖开放平台写一个脚本，定时拉取标注，生成一份 JSON 文件放到项目目录里，然后让 Cursor 读这个文件。我差点选了这条，因为听起来最可控。但它有个结构性问题：每次设计稿更新，脚本拉取时机不对，代码里读到的就是旧数据；想用的时候没刷新，不想用的时候它刷了，非常尴尬。你可以说“那我做实时监听”，可就为一个标注写一套轮询服务，维护成本已经接近正经对接。

2.2 MCP 的定位：让 Cursor 在执行任务时主动找数据

MCP 的全称是 Model Context Protocol，中文叫模型上下文协议。你可以把它理解成一个“USB 接口标准”：AI 应用统一按照这个协议去连接外部数据和工具，任何提供方的能力只要实现了这个协议，就能被接入到 Cursor 这类客户端里用。

用在我这个场景里理解更直观。以前我问 Cursor “帮我把这个页面对齐设计稿”，Cursor 只能等我给它素材，然后空对空写代码。现在我把蓝湖侧的数据封装成了 MCP 服务提供的能力，Cursor 在写代码的过程中会自动调用对应的工具，去蓝湖那里拉取某个页面的标注、获取设计稿版本、下载切图地址。整个过程不是“我手动找了半天再贴给它”，而是“Cursor 在执行时自己去找”。

选 MCP 还有一个更长远的原因：它不绑定 Cursor 一个工具。今天我用 Cursor，明天我想用其他支持 MCP 的编码智能体，同样的配置和服务直接复用，不需要为每个工具重新造一个私人插件。这一点对个人试用和团队推广都友好。

2.3 整个链路的数据流动路径

连接之后的完整链路是这样的：蓝湖开放平台提供设计数据和标注查询能力，我这边部署一个轻量 MCP 服务，内部调用蓝湖的开放接口拿到数据，再按 MCP 协议把这些数据暴露成“设计稿标注查询工具”。Cursor 这边配置好 MCP 服务地址之后，AI 在执行任务时就能把对应的工具调用进来，最终控制台返回的是结构化的 JSON 文本，而不是一堆截图。

链路可以归纳为三句话：蓝湖有的数据，我通过开放 API 拿；拿到之后按 MCP 格式包装成工具接口；Cursor 把工具接口用起来，把标准数据转成代码里可重用的样式变量。这样设计稿标长什么样，AI 读到的就是什么样，不存在“猜”和“估”，自然也不用我一遍遍对着截图做人工翻译。

3. 蓝湖侧 MCP 服务部署：从零到能通

3.1 部署前要有的前置条件和权限准备

如果要复现我这边的操作，先把前置条件列清楚。

• 一个蓝湖团队账号，并且你在这个团队里有管理员或至少可见设计项目的权限。
• 一个用于调用蓝湖 OpenAPI 的应用凭证，通常是团队控制台里创建的，获取后会得到一组类似 appId 和 appSecret 的信息。
• 本机已经安装了 Node.js 18 以上，因为 MCP 服务我用 Node 生态做最顺手。
• 一个本地目录用来放 MCP 服务的源码，我建议单独建一个文件夹，不要塞进业务工程里，否则后面别人 clone 项目时会一脸懵。

凭证这一步最容易卡住。很多人卡在“我明明有账号，但控制台里看不到应用创建入口”，那是因为团队权限没开。你需要让团队管理员把你的角色调成项目管理员或者开通接口权限，才能在开放平台里创建应用。拿到凭证之后我的习惯是立即限制它的可用范围，只勾选“设计稿读取”这类相关权限，不给账号管理权限，防止后续模型调用时碰到底层管理接口。

3.2 用 MCP SDK 搭一个极简的标注入桥服务

我用的不是蓝湖官方提供的现成插件——因为我对它到底封装了什么心里没底，索性自己写一个透明的桥接服务。这么说吧，我用到了@modelcontextprotocol/sdk，这个 Node 包是 MCP 官方提供的开发套件，可以快速把一段能力包装为 MCP 服务。

核心代码长这样，只是一个骨架示例，具体接口地址请换成你实际账号对应的：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod"; const server = new McpServer({ name: "lanhu-mcp-bridge", version: "1.0.0", }); server.tool( "get_design_spec", "读取蓝湖指定页面的标注数据，包含尺寸、间距、字号、颜色等关键信息", { pageId: z.string().describe("蓝湖设计稿页面的唯一标识"), version: z.string().optional().describe("设计稿版本号，默认取最近版本"), }, async ({ pageId, version }) => { // 这里的 fetchLanhu 就是我们自己封装的蓝湖开放接口调用函数 const spec = await fetchLanhu(pageId, version); return { content: [ { type: "text", text: JSON.stringify(spec, null, 2), }, ], }; } ); const transport = new StdioServerTransport(); await server.connect(transport);

这段代码的原理很直接：定义了一个叫get_design_spec的工具，Cursor 在对话里按需调它。传给它 pageId，它就回给你一段标准化的 JSON。你不需要把这个 JSON 贴到对话里喂给 AI，Cursor 会把返回值自动放进对话上下文，相当于 AI “自己看了一眼设计稿”。

如果“蓝湖 mcp 服务怎么部署”是你主要搜索的问题，那就是三步：装 SDK、按上面的壳子写一个标准化工具函数、把 fetchLanhu 内部实现换成正规的蓝湖开放接口请求方式。我这边就是按这个思路做的。只要你后续要暴露多个能力，比如“订阅设计稿版本更新”“下载切图”，就多注册几个server.tool就好。

3.3 本地验证：不先测通，不进 Cursor

写完服务代码之后，我最重的一个习惯是先不碰 Cursor，直接在命令行把服务跑起来，手动调用一次工具，看看返回的 JSON 是否包含预期的标注信息。

用npx tsx启动一个测试脚本，模拟一次 MCP 工具调用，做法是在代码里接一个内存传输层直接调用get_design_spec。如果这一层能拿到数据，那说明问题全部集中在输出格式上，否则先查蓝湖接口返回。我再强调一遍：不要直接进 Cursor 再调试，Cursor 对 MCP 报错很收敛，有时候只是提示连不上，你根本分不清是网络问题、凭证问题还是返回格式问题。本地先把每个环节调结实，再一键进 Cursor。

4. Cursor 侧接入配置：让模型认识蓝湖这个“外设”

4.1 Cursor 管理 MCP 的两个入口

把蓝湖侧服务跑起来后，接下来就是告诉 Cursor“你现在多了一个外设”。Cursor 里管理 MCP 常见的入口有两个：

• 项目级配置：在项目根目录放一个.cursor/mcp.json文件，内容是一个 mcpServers 字典，它只对当前项目生效。
• 全局配置：在 Cursor 的设置界面找到 MCP 面板，添加服务器，这样所有项目都能使用同一个蓝湖连接。

我建议日常开发用项目级配置，把蓝湖 MCP 单独放进正在重构的 Web 项目里，避免其他项目也读取到蓝湖数据，干净。你需要在.cursor/mcp.json里写的内容长这样：

{ "mcpServers": { "lanhu": { "command": "node", "args": ["/absolute/path/to/lanhu-mcp-server/index.js"], "env": { "LANHU_BASE_URL": "https://your-openapi-host", "LANHU_APP_ID": "your_app_id", "LANHU_APP_SECRET": "your_app_secret", "LANHU_TEAM_ID": "your_team_id" } } } }

这里要解释两个细节。第一，command和args必须完整写到能启动服务的程度，不能只写个命令名就直接完事，Cursor 是通过子进程方式拉起这个服务的，路径错了它会直接提示无此进程。第二，env里的凭证信息不要提交到 git，建议在.gitignore里加一条.cursor/mcp.json或者单独用环境变量引用，避免团队仓库里暴露密钥。

4.2 配置完成后主动观察工具是否处于可用状态

配置完别急着写业务代码，回头看一眼 Cursor 的 MCP 面板。正常情况下，你会在已发现的服务列表里看到刚才注册的几个工具名称，比如get_design_spec，状态是 enabled。如果状态是 disabled 或者工具列表是空的，十有八九是服务启动报错，或者 stdio 传输的输出被你写了一些日志干扰了。

对，这是一个隐蔽的坑。MCP 基于 Stdio 传输的进程通信方式比较严格，服务端调试日志一旦打到标准输出里，Cursor 在解析协议时就会懵，立刻判定服务不可用。所以我服务端的所有日志统一走process.stderr，或者直接写到日志文件里，不要用console.log调试，口诀就是：协议帧全走 stdout，日志全走 stderr。

面板确认工具可用之后，我的做法是在 Cursor 对话里直接问一次“你有哪些 MCP 工具可以调用”，看它能否准确列出蓝湖相关的工具函数及描述。能列出来，就说明 Cursor 已经理解了蓝湖是一个“可读取的数据源”，接下来才能谈工作流。

4.3 用 Rules 固化使用习惯，不让每次对话都重复解释

Cursor 接入后，我在项目里写了一段规则，作用是让模型默认先查询蓝湖标注再动手改样式。规则文件放在rules/design-workflow.mdc，大意是：影响视觉效果的任务开始前，应当先调用蓝湖设计稿查询工具获取当前页面的标准值，包括颜色、间距、字号、圆角、阴影；如果没有明确设计依据，不要臆造样式数值；所有从蓝湖同步到的 token 要写入design-guide.md供后续参考。

这条规则的收益比你预想得大。它本质上是给模型做了一个“条件反射训练”，让它看一眼布局需求就先做一次拉取，而不是凭空生成rounded-lg这种笼统类名。设计师那边看到的效果是：我提交的页面样式和蓝湖上的数值对得上，连小到 2 像素的间距都对得齐。

如果你团队里不止一个人用 Cursor，建议把同样规则放到团队公共仓库的 rules 里，大家保持同一种工作方式，还原度从个人行为变成团队基线。

5. 实际跑出来的三个用法，设计师从“追着问”变成“被反馈”

5.1 新页面开发：从“看着图写”到“按数据写”

接完后的第一个场景我选了一个全新的营销页。以前的做法是自己手动看标注，把色值、字号、间距一个个抄下来再写 CSS。这次我直接对 Cursor 说：

先调用 get_design_spec 读取当前活动版本的首页设计稿标注，把颜色值、字体字号、间距组合提取成 design tokens，放到项目的 tokens.css 文件里，然后再按这个 tokens 生成页面结构和样式类。

Cursor 收到指令后，先通过 MCP 工具把蓝湖数据拉回来，我能在后台看到它输出一段结构化 JSON，里面所有标注数值都和网页版蓝湖一一对应。它接下来生成的代码里，间距用的是--space-16、颜色用的是--brand-color-primary，再不是原来的瞎写。表面上看，我只是换了一种提问方式，实际数据化之后，我顺带把整个页面的样式体系从具体数值抽成了可复用的变量，后面改版维护也轻松很多。

5.2 设计稿改版后让 Cursor 自己看版本差异

这个场景是后来最常用的。设计师改了个按钮的圆角和阴影，没有口头通知，只是在蓝湖上更新了版本。按旧流程我得发现“页面看着不对”，然后去蓝湖新版本里找改动点，再反过来改代码。现在我在 Cursor 里说：读取当前蓝湖页面的最新版本，和上一版本做关键样式对比，把差异整理成 change log，并同步更新代码中对应的样式变量。

有标注数据的版本差对比是真实可落地的，因为每个关键样式都有对应数值记录，Cursor 拿新旧版本 JSON 一比，差异非常直观：button radius 从 6 变成 12，shadow opacity 从 0.1 变为 0.16。它顺手会改掉对应样式，并且把改动点列出来放到 commit message 里。设计师后来看到提交记录里的 change log，直接回了一句“好了，看到了，不用再去对稿了”。

5.3 还原度自检：每天下班前让模型跑一次对照检查

还有第三个用法是我建议大家都试的。每天下班前，打开 Cursor，运行一段固定指令：请获取当前蓝湖首页设计稿的标准样式清单，然后检查本项目入口页的样式代码，逐项对照颜色、间隙、字号、圆角是否一致，输出未对齐项清单及原因分析。

过去，我这属于“肉眼找茬”；现在它成为“自动质检”。Cursor 会把蓝湖数据和代码样式列表拉到一个上下文里做对照，输出类似“间距错误：页面头部 margin-top 应为 24px，当前为 28px”的清单。我拿到清单后直接改，既不用设计师来翻旧账，也不用自己眼睛去对着两个窗口反复比对。这套流程跑下来之后，群里“还原了吗”的追问基本绝迹，因为我先于问题完成了自查。

6. 接入过程中踩过的坑，和我不建议你跳过的一些边界

6.1 连接失败时，先按这个顺序排查

接入后大概率遇到的第一个坑，就是 Cursor 面板提示 MCP 服务连接超时或进程退出。我以前遇过几次，后来总结出一套排查顺序，按顺序能解决大部分问题。

• 第一步，在终端手动运行node /absolute/path/to/index.js，看进程能否长驻不退出。如果启动即退，大概率是代码抛错，看 stderr 日志。
• 第二步，确认.cursor/mcp.json里的执行路径是绝对路径，不要用波浪号，Cursor 的子进程启动器对路径解析不一定处理得跟 shell 一样。
• 第三步，检查蓝湖 OpenAPI 的调用是否成功，单独跑一个 fetchLanhu 函数看返回，如果接口本身返回 401，那就不是 MCP 的问题，是凭证失效。
• 第四步，确认服务端日志没有打到 stdout。一旦协议流被日志污染，Cursor 会直接认为协议解析失败，立刻报不可用。

这四条里，我踩得最深的是第四条，曾经调了大半天，前三条全正常，最后发现是启动文件里加了一行console.log("server starting")，这行日志把 stdout 搞乱了。排查链路可信度很高，照着来基本半小时内能定位问题。

6.2 权限和依赖的最小化设计

我在设计蓝湖 MCP 服务时坚持了一个原则：不把整棵蓝湖账号树都开放给模型。这个服务的环境变量里只放必要的团队标识、应用凭证，并且在代码内部写死可查询的范围，比如只允许查询项目列表和指定页面标注，不允许调用任何管理接口、成员接口。这个最小权限原则救了我不少次，有一次我测试时不小心把提示词写得特别宽，如果凭证权限过大，可能导致模型意外触发不当操作。收缩权限后，再宽泛的提示词也只能接触到设计标注，风险面小很多。

对团队内部，我也提醒了其他人：MCP 服务的能力边界要写成使用文档，让”模型能干什么”透明化。不能让同事以为接上蓝湖就等于拿到了无限读权限，使用时要正视它是无形资产数据管线的存在。

6.3 哪些场景其实没必要上这个方案

最后说点实在的，不是所有团队都值得上这套配置。如果你只是做静态落地页、规模很小的个人项目，截图给 Cursor 看也够了。或者设计稿本身还没有定稿、每个版本之间差异巨大，那每一轮的标注价值都很短暂，强行接入反而增加维护负担。

同样，如果团队里设计师和前端之间主要靠口头沟通，标注工作流本身就没建立起来，那 MCP 接得再好也拉不到有效数据。你要先保证团队本身在蓝湖上有规范交付行为，再谈技术接入，不然工具层次再高也顶不住业务习惯的分歧。我从个人实践看，这套方案适合的是处于“开发者用 AI 写代码 + 设计协作规范化”这两个条件都成立的中小型前端团队。

蓝湖和 Cursor 的这几个连接跑顺之后，我觉得最有价值的反而不是工具代码本事，而是工作流：设计师发布标注，Cursor 读取标注，开发者直改代码，环环相接后，问句“还原了吗”就从日常消失。如果你也正被同款追问烦着，完全可以照着拆一个最小版先跑通。前提是别贪多，先支持一个页面查询能力就够了。跑通后你会明白，这不是什么重工程，设计师惊叹的只是“他居然直接知道设计稿数据是什么”。