企业官网建设流程全解析

每当我把设计稿还原得七七八八，设计师就会走过来问一句：“还原了吗？”这一问，几乎成了前端开发的“催命符”。直到我把 Cursor 接到了蓝湖上，这个局面才彻底改观，不是靠截图、不是来回传文件，而是让 AI 编程助手直接“看见”设计稿里的真实数据——字号、间距、颜色、切图，统统变成它写代码时可以引用的上下文。

这篇文章不是讲概念，是我自己从零到一部署蓝湖 MCP 服务、把它接进 Cursor、并且让这套流程真正跑在项目里的完整记录。适合正在被“还原度”折磨的前端开发者，也适合想搞清楚 MCP 到底能干什么、但不想只停留在“听说过”这个层面的人。你会看到我怎么选型、怎么配置、踩了哪些坑，以及最终这套工作流帮我省掉了多少来回确认的功夫。

1. 先搞明白这件事的本质：还原度问题的根子在哪

1.1 “还原了吗”为什么是句恐怖提问

做过前端的都懂，这句话背后是一整套信息损耗链路。设计师在蓝湖上传设计稿，标了注、切了图，前端拿到的是一个静态页面，真正要写代码的时候，有几个信息是必须反复核对的：这个按钮的圆角是 8px 还是 6px？主色到底是#1B6BFF还是#1A6BFF？间距是 16px 还是 20px？标注图上写得明明白白，但人眼扫过去，十个里有九个会看错或者记错。

更麻烦的是沟通成本。设计更新了某个模块，不会有人专门跑来告诉你“第三屏的卡片间距改了”，你只能靠设计师追问“还原了吗”的时候，才发现自己按老数据写了两天。传统流程里，解决这个问题靠的是“细心”，但人不可能一直保持 100% 细心，尤其是在连续切十几个页面的时候。

我当时的处境就是这样：蓝湖上躺着整套设计稿，我这边对着 Cursor 写代码，每次写到一个新组件，就得切出去打开蓝湖看标注，再切回来继续写。来回切窗口的时间加起来比写代码还多，还容易看漏参数。所谓“还原”，本质上不是技术难，是信息搬运的效率太低。

1.2 MCP 在这里扮演的是“翻译官”角色

MCP 的全称是 Model Context Protocol，翻译过来就是模型上下文协议。你不需要背这个概念，只要理解一句话：它让 AI 工具能够调用外部数据源的工具接口，相当于给 Cursor 装了一只可以伸进蓝湖数据库的手。

类比一下：以前的 AI 编程助手像是坐在你旁边听你描述需求的程序员，你说“按钮用蓝色”，它就猜一个蓝色；现在通过 MCP，它自己就能打开设计标注文件，看到真正的色值是#2B5AF7，间距是 24px，然后直接按这个数据生成代码。从“听你说”变成“自己看”，这就是质的区别。

蓝湖本身有开放 API，MCP Server 就是中间那层胶水，把蓝湖的接口包装成 Cursor 能理解的工具列表。部署好之后，你在 Cursor 对话框里可以直接说“读取当前项目的设计稿信息”，它就能返回真实的样式数据。设计师再问“还原了吗”，你只需要回一句“让 Cursor 自己对照设计稿检查过了”。

2. 蓝湖 MCP 服务怎么部署：从零开始的操作记录

2.1 前置条件与工具准备

动手之前，先把需要准备的清单列齐，免得部署到一半发现少东西。我用的是 macOS 环境，Windows/Linux 操作大同小异，命令略有区别，我会在对应位置标注。

• 一个蓝湖账号，并且要有对应项目的访问权限。团队版或企业版通常才有开放 API 的权限，个人免费版能拿到的数据有限，这个要提前跟管理员确认
• 蓝湖开放平台的密钥，一般是 Access Key 和 Secret Key 的组合，有的版本叫 Token，具体以官方控制台为准
• Docker（推荐用容器跑，省去本地环境依赖的麻烦），或者 Node.js 18+ 的环境
• Cursor 版本建议 0.80 以上，旧版本对 MCP 的支持不完整，容易出现“服务配置了但工具列表为空”的怪问题
• 能访问蓝湖的网络环境，这个听起来像废话，但公司内网限制 API 域名的情况我见过不止一次

务必先确认最后一条：在终端里ping一下蓝湖的 API 域名，能通再往下走。很多人在部署环节卡了一晚上，最后发现是内网把域名拦了，服务起不来，Cursor 端自然一片红。

2.2 Docker 方式部署（推荐路线）

我推荐 Docker 部署，因为蓝湖 MCP 服务依赖一些 Python 包和 Node 模块，直接用本地环境跑容易因为版本冲突搞得一团糟。容器化之后，镜像里什么都有，起一个容器就完事。

先说镜像。不同的 MCP 提供方可能发布不同名称的镜像，以你实际使用的版本为准，我这里用一个通用的占位名来说明整个流程：

# 拉取镜像 docker pull lanhu-mcp-server:latest # 启动容器 docker run -d \ --name lanhu-mcp \ -p 8231:8231 \ -e LANHU_ACCESS_KEY="你的AccessKey" \ -e LANHU_SECRET_KEY="你的SecretKey" \ -e LANHU_API_BASE="https://api.lanhuapp.com" \ lanhu-mcp-server:latest

解释几个关键参数。-p 8231:8231是端口映射，宿主机 8231 端口映射到容器内 8231，Cursor 连的是宿主机的这个端口。LANHU_ACCESS_KEY和LANHU_SECRET_KEY是鉴权凭证，相当于你打开蓝湖数据柜的钥匙，一定不要泄露，更不要提交到 git 仓库里。

启动之后，用docker logs lanhu-mcp看日志，如果出现类似MCP server listening on 8231或者SSE endpoint ready的字样，说明服务已经起来了。这里要特别提醒：MCP 服务有两种主流协议形态，一种是 JSON-RPC over HTTP，一种是 SSE（Server-Sent Events），Cursor 对这两种的配置方式略有区别，后面我会详细说明。

还有一点很多人会忽略：Docker 容器的时间默认是 UTC，如果后面你排查问题发现时间对不上，记得在启动命令里加-e TZ=Asia/Shanghai。

2.3 Node.js 本地部署方式（备选方案）

如果你不想用 Docker，或者公司服务器不让你跑容器，也可以直接用 Node.js 裸跑。先把项目克隆到本地：

git clone https://github.com/your-lanhu-mcp/lanhu-mcp-server.git cd lanhu-mcp-server npm install

安装依赖之后，需要创建一个.env文件，内容如下：

LANHU_ACCESS_KEY=你的AccessKey LANHU_SECRET_KEY=你的SecretKey LANHU_API_BASE=https://api.lanhuapp.com PORT=8231

注意.env文件默认被 gitignore 忽略，这是好事，千万别为了省事给它改名，不然下次提交代码可能把密钥带出去。然后执行：

npm run start

如果一切正常，你会看到类似MCP Server running at http://localhost:8231的输出。裸跑的优点是方便调试，改代码热重载；缺点是本地 Node 环境依赖容易踩坑，比如 OpenSSL 版本不对导致启动失败，我就遇到过一次，报错信息像天书一样，后来升级 Node 到 20 LTS 才解决。

2.4 验证服务是否真的可用

服务起来之后，不要急着配 Cursor，先用浏览器或者命令行验证一下接口是否正常。在浏览器里打开http://localhost:8231/mcp，如果能看到一个 JSON 响应或者一个可用的 HTTP 端点说明，至少证明服务进程是活的。

严谨一点的做法是用 curl 请求工具列表接口：

curl -X POST http://localhost:8231/mcp \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 你的Token" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

如果返回里包含tools数组，里面列了类似get_design_info、list_projects、get_component_styles这样的工具名，说明 MCP 服务已经正确接上了蓝湖的 API。这一步很关键，因为很多时候推进展不了不是 Cursor 的错，是服务本身就没起来，你却在那边折腾半天 Cursor 配置。

3. 在 Cursor 里把蓝湖 MCP 配起来

3.1 Cursor 的 MCP 配置入口和方式

Cursor 的 MCP 功能藏得不算深，点击左下角设置图标，找到MCP标签页，就能看到服务管理界面。这里有两种配置路径：一种是内置的傻瓜式添加，另一种是手动写配置。

傻瓜式添加适用于有现成服务市场或者一键安装源的情况，可能是输入一条安装命令让 Cursor 自动拉起本地服务。手动配置则适用于你已经像上面那样自己部署好了服务，需要把它注册进 Cursor。

手动配置时，需要打开配置文件，不同版本位置略有不同，一般是点击 MCP 页面里的Configure MCP Servers按钮，会打开一个 JSON 配置文件。在这里添加一段：

{ "mcpServers": { "lanhu": { "command": "docker", "args": ["run", "--rm", "-i", "-p", "8231:8231", "lanhu-mcp-server:latest"], "env": { "LANHU_ACCESS_KEY": "你的AccessKey", "LANHU_SECRET_KEY": "你的SecretKey" } } } }

这段配置的意思是：让 Cursor 直接拉起一个 Docker 容器来跑 MCP 服务，这种方式的好处是 Cursor 启动时自动起服务，不用你手动 docker run。但前提是你的 Docker 环境配置好了，否则 Cursor 这边会一直显示连接失败。

3.2 用远程端点方式配置（如果服务已经在远端运行）

如果你的 MCP 服务不是跑在本机，而是放在一台内网服务器或者云主机上，那就要换一种配置方式，直接用 HTTP 端点连接。格式一般是：

{ "mcpServers": { "lanhu": { "type": "http", "url": "http://192.168.1.100:8231/mcp", "headers": { "Authorization": "Bearer 你的Token" } } } }

这里要说明一下，不同时期 Cursor 对 MCP 的配置 schema 不一样，有的版本用type: "sse"，有的用url直接识别。最稳妥的办法是打开 MCP 配置页面，看界面提供的表单字段有哪些，按着填总不会错。如果界面里就是简单的Name、URL、Headers，那就直接填就好。

配完之后，最重要的一步：点击Enable开关或者刷新按钮，让 Cursor 真正加载这个服务。加载完成后，服务名旁边会显示绿灯和工具数量。如果显示红色或者Error，把鼠标悬停上去看具体报错，不要凭感觉乱改。

3.3 验证 Cursor 里能不能读到设计数据

服务显示连接成功只是第一步，验证它能不能真的拿到数据，最直接的方法是在 Cursor 对话框里输入一句自然语言指令：“读取项目 XX 的设计稿信息，列出首页头部区域的背景色、标题字号和按钮圆角。”

如果配置正确，Cursor 会像有了超能力一样，直接返回实际设计参数，而不再是它凭空猜测的“我建议用 #333”。我第一次看到它准确说出#1868F4和border-radius: 10px的时候，说实话有点头皮发麻，因为我知道这远远超出了常规 AI 助手的知识能力——它不是猜的，是读了蓝湖上的真实标注。

如果返回的是“抱歉，我无法访问设计稿数据”之类的回答，不要慌，大概率是鉴权问题或者工具调用权限没开。检查一下蓝湖开放平台的权限设置里，是否有开启对应应用的 API 访问范围，以及 Token 是否有效。还有一个常见原因是：Cursor 的 Agent 模式没有把 MCP 工具纳入自动调用范围，需要手动指定使用某个工具。

4. 接好之后的真实工作流：从“猜着写”到“对着写”

4.1 用自然语言直接读取设计数据

接好蓝湖 MCP 之后，最爽的改变是我可以丢掉“切出去看标注”这个动作，完全在 Cursor 里完成信息获取。比如我正在写一个卡片组件，直接在对话框里输入：

“从蓝湖读取‘会员中心-卡片列表’的设计稿，提取卡片的背景色、圆角、内边距、阴影参数，并生成对应的 Tailwind 类。”

以往这种需求，我得去蓝湖手动翻图层，找到对应样式面板，逐项抄下来。现在 Cursor 自己去调接口，把参数返回给我，我只需要看着它生成的代码，确认是否符合需求。整个体验更像是在“审查”而不是“打样”。

这里有个细节技巧：指令里要说清楚“读取设计稿”，而不是“帮我设计一个卡片”。因为 MCP 工具是偏工具调用的，你得给 AI 一个明确的动作指令，它才会去调用那个工具。含糊的说法容易让它觉得自己该“发挥创意”，那就跟整个初衷背道而驰了。

4.2 自动校验组件与设计稿的差异

比生成代码更香的是反向校验。以前写完组件，靠肉眼对照设计稿，哪里有偏差只能凭感觉。现在你可以直接对 Cursor 说：

“检查当前这个 button 组件的样式，和蓝湖设计稿里的 button 组件是否一致，列出所有差异。”

效果相当于有个自动化的“还原度巡检员”。背景色差了 1 个色值、字体大小差了 2px、圆角从 8px 变成了 10px，它都能给你精确列出来。我实际测试下来，它能发现非常细小的差异，有些是我肉眼根本看不出来的，比如#1A6BFF和#1B6BFF的区别，写代码时很容易带过去，它却能抓出来。

但这个功能对设计稿数据的完整性有要求：如果你的设计稿在蓝湖上没有规范标注，很多样式值缺失，那它就无从比对。所以，为了让它当好巡检员，前期的规范标注功夫要做足。

4.3 设计更新后的同步效率提升

设计稿不是一成不变的，产品经理和设计师隔三差五会改需求。传统模式下，一个模块的样式变了，前端要等设计师口述或者看更新后的标注，然后手动去改代码。现在我可以直接对 Cursor 说：

“蓝湖上‘首页金刚区’的设计已更新，读取最新设计稿参数，对比旧版列出变化点。”

它能把前后差异列成清单：图标尺寸从 44px 变成 48px，背景色从浅灰改成浅蓝，间距从 12px 调整为 16px。我照着清单改代码，几分钟搞定。这种效率提升，对高频迭代的项目来说是质变——你再也不用担心“我不知道设计改了”这种事了，MCP 就是你派驻在蓝湖上的观察哨。

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

5.1 高频问题速查表

把自己部署和用别人经验收集到的问题整理成表，按出现频率排个序，方便你直接对号入座：

5.2 三个极容易踩的隐蔽坑

第一个隐藏坑是 Token 权限范围。蓝湖开放平台的密钥通常区分“只读”和“读写”权限，MCP 服务只需要只读权限就够了。我第一次图省事申请了读写权限，结果安全审核不通过，同事也提醒这存在数据泄露风险。后来改成只读密钥，服务照常跑，安全上也踏实。建议申请密钥时按最小权限原则。

第二个坑是 Cursor 的 MCP 服务状态看起来是绿的，但实际请求全超时。我遇到过几次，排查下来是 Cursor 的 Agent 模式为了控制上下文长度，不会总是自动调用外部工具，尤其是设计稿数据量大的时候，它可能选择“忽略工具”直接开写。解决办法是在提示词里强调“必须使用蓝湖设计稿数据作为唯一参照”，或者先手动调用一次工具，让返回的数据进入对话上下文，后续再生成代码。

第三个坑是版本兼容。Cursor 更新频率极高，每次大版本更新都可能微调 MCP 的配置 schema。有一次我配置的type字段在更新后失效了，服务直接不加载。这种问题没有特别好的办法，只能养成习惯：Cursor 更新后,先到 MCP 页面看一眼工具列表是否还在,不在就重新保存一遍配置，通常就能恢复。

5.3 排查思路：遇到问题先别急着改配置

我自己的排查顺序是“服务本身 → 网络 → 配置 → 权限 → 版本”。先用 curl 确认 MCP 服务能不能访问，这能排除一半问题；然后看 Cursor 连接的是不是同一个端口，这一步又能排除四分之一；最后才折腾权限和版本兼容。

最忌讳的就是打开 Cursor 看到红点，立刻凭感觉乱改 JSON 配置，改完还不对，又开始怀疑 Token 问题，来回折腾一小时。先分层次排查，大部分问题 5 分钟内能找到根源。

6. 把“还原度”变成一次对话：个人实践后的真心话

我现在的工作流基本变成了这样：设计更新了 → 让 Cursor 读一遍蓝湖数据 → 照着生成代码或对比差异 → 提交前再让 Cursor 自查一遍。设计师的“还原了吗”几乎不会再出现了，因为我在交付前已经把 AI 变成了一道质检工序。

说说我的真实感受。这套东西的意义，不是帮你写代码更快——Cursor 写代码本来就快——而是把“信息对齐”这个最消耗心力的环节自动化了。以前你和设计稿之间隔着一个人眼读标注的过程，现在变成了 AI 直接读数据，中间损耗基本为零。我有很多次写组件写到一半，拿不准某个间距参数，直接在 Cursor 里问一句“这个间距是多少”，它回答 24px，我继续写，整个过程不用离开编辑器。

如果你也想搭这么一套，我的建议是先小范围试点，找一个信息标注最完整的项目跑通，不要一上来就追求全量接入。蓝湖 MCP 服务部署本身不难，花一小时跑通基本流程，真正花时间的是让团队把设计标注习惯规范化，以及让你自己习惯“用对话驱动信息获取”的方式。

最后分享一个小技巧：在 Cursor 的项目规则文件（比如.cursorrules）里固定写一句“涉及样式生成时，必须从蓝湖设计稿获取数据并引用来源”,这样每次新开会话,AI 也会自动遵循这个规则,不用你反复叮嘱。这个小设置帮我在团队里推广这套工作流时省了很多口舌,值得一试。