企业官网建设流程全解析

做前端这几年，我最怕听到的不是“线上有 Bug”，而是从聊天窗口里弹出来的一句“这个页面还原了吗”。说实话，这句话背后站着设计师一整下午的盯着像素的眼睛，也站着前端这边说不清的“我觉得差不多了”。后来我把 Cursor 接到了蓝湖上，让 AI 自己去设计稿里读尺寸、读颜色、读间距、读切图参数，再直接生成一版尽可能接近标注的页面代码，设计师再也不用追着我问“还原了吗”，因为还原到什么程度，对话记录里写得清清楚楚。

这个方案并不复杂，核心就三样东西：Cursor 作为 AI 编程 IDE，蓝湖作为设计稿数据源，中间用 MCP（Model Context Protocol）搭一座桥。整个过程从部署到跑通，我踩了不少坑，也总结出一套可以在本地稳定复现的做法。这篇文章就把完整链路拆开讲清楚：为什么这么做、MCP 服务怎么部署、Cursor 里怎么配置、真实还原对话长什么样、以及那些文档里不会写的问题和排查办法。如果你是前端、全栈、或者正在带设计协作团队的人，这篇内容应该能帮你省下不少沟通成本。

1. 为什么要做这件事：还原度沟通的困局与破局思路

1.1 “还原了吗”背后的沟通成本

先还原一个很典型的日常：设计师在蓝湖上传了新版首页设计稿，然后 IM 上问“还原了吗”。前端打开蓝湖，对照设计稿开始一处处检查——标题字号对不对、按钮 hover 色号是否一致、栅格间距是不是 8 的倍数、图标切图有没有漏。查完之后回复“基本还原了”，设计师不信，自己又截了张图，标出三处差异发过来，前端再改，改了再回复，一版一版循环下去。

这个循环的问题不在于谁不认真，而在于信息传递一直在“失真”。设计稿里的精确数据是客观存在的：font-size: 28px、color: #1A1A1A、margin: 16px 24px、切图 URL、智能标注的间距与占比。但经过人眼看图、人脑比对、打字描述之后，这些数据就变成了“差不多”“略大”“大概对齐”。一次还原沟通要来回三到五轮，改一个间距重新截图又要等半天，这些小摩擦累积起来，就是项目里最隐形的时间黑洞。

我自己统计过，一个中等复杂度的活动页，纯人工对照设计稿做首轮还原检查，最快也要 40 分钟；如果算上返工和来回确认，往往要拖到半天。后来我换了思路：既然设计稿的数据都在蓝湖里躺着，AI 编程工具又越来越聪明，为什么不直接让 AI “看”设计稿数据？

1.2 Cursor + 蓝湖 + MCP 的组合逻辑

先解释一下 MCP。MCP 全称 Model Context Protocol，是一套开放协议，目的是让 AI 应用（比如 Cursor、Claude Desktop、Codex CLI 这类工具）通过统一的标准方式接入外部数据源和工具。你可以把它理解成一个 USB-C 接口：以前每个设备都要专门拉一根线，现在大家都按同一个标准做接口，插上就能用。MCP 就是大模型工具世界里的 USB-C，它让 AI 不再只靠训练时的知识回答问题，而是能实时去调用外部服务拿数据。

在这个场景里，数据源就是蓝湖。蓝湖本身有开放 API，可以获取设计稿信息、标注数据、切图资源等；中间需要一个 MCP Server，把 AI 发出的工具调用请求翻译成蓝湖 API 请求，再把拿回的数据整理成 AI 能直接用的结构化内容。Cursor 是客户端，MCP Server 是快递员，蓝湖是仓库。快递员从仓库取货，按统一包装送到 Cursor 手上，AI 打开包裹就能用里面的设计数据写代码。

我之前也考虑过其他方案。比如让 Cursor 直接读蓝湖网页，但设计稿大量数据是动态渲染和 js 交互产生的，AI 抓不到结构化信息；再比如让 AI 对着设计稿截图人工描述，实际上又回到了“看图猜数”的老路。MCP 是最直接的路径：AI 需要某个设计稿的标注，就主动调用工具去拿数据，拿到的是字段明确的 JSON，而不是一张需要人再去翻译的图。

2. 开工前的准备：Cursor 安装、账号与语言设置

2.1 安装、注册与账号使用的几个关键点

如果还没装 Cursor，直接去官网下载对应系统的安装包，Windows 和 macOS 都有。装完打开就是注册登录流程，可以用邮箱注册，也可以直接用已有的账号体系登录。我个人建议用邮箱注册一个独立账号，因为后面涉及 Pro 订阅、多设备管理，独立账号比第三方快捷登录更好排查问题。

账号使用有几个容易踩坑的点。第一是登录设备数量限制，Cursor 官方策略是同一个账号在 24 小时内如果被过多不同电脑登录，会触发安全保护，报错文案大致是 “too many computers used within the last 24 hours for the same cursor account”。这个不是封号，是风控机制，等 24 小时窗口过去，或者在不用的设备上退出登录，基本就能恢复。团队内部流动性大、一台机器多人轮着用的场景要多注意。

第二是订阅额度问题。Pro 套餐包含一定量的快速请求额度，也就是响应比较快的 Agent 调用次数，用完以后不是不能用，而是自动降级为慢速额度，速度慢一些但功能不受限。如果你在高峰期赶工，可以在设置里开启按需用量（on-demand usage），按实际消耗额外购买快速请求包，适合偶尔冲刺的场景。

第三是订阅复购的生效时间。很多人以为续费是从扣款当天重新计一个新周期，实际上 Cursor 的订阅是按原周期顺延的，也就是你当前周期还没结束就续费，新周期会在当前周期结束后的下一天开始，而不是立刻重新计算。我要急着用额度，结果续费后额度没变，去查才明白是顺延规则。这一点建议大家在官方账单页面确认清楚，别到赶工时才发现额度没刷新。

2.2 把 Cursor 调整成顺手的中文环境

Cursor 默认界面是英文，对英文不敏感的同事来说，设置友好度很重要。新版 Cursor 在 Settings 里可以搜索 Language / 语言相关选项，部分版本支持直接切换界面语言到中文，切换后重启生效。如果你的版本里没有这个选项，也不用急着找什么汉化包去改安装文件，一个更稳妥的办法是：把界面语言保持英文，但通过 Rules 让 AI 始终用中文回复。

Rules 设置路径在 Settings 里的 Rules for AI 区域。我会在里面固定写一条：Always respond in Chinese (Simplified)。这样无论我怎么提问，AI 的回复基本都是中文。如果你连界面也想要中文，可以再找一个社区维护的语言设置方案，但我不太建议去修改安装目录里的文件，一是升级会被覆盖，二是改了之后某些功能显示容易异常。

还有一个和中文环境相关的体验：Cursor 对中文注释和中文需求描述的理解已经相当好。实际测试下来，我用中文描述“把导航栏改成 sticky 定位，背景白色半透明，毛玻璃效果”，它能直接输出对应的 Tailwind 或 CSS 代码，比我自己敲还快。所以不用担心 AI 编程工具对中文不友好，重点是把它的回复语言规则先定好。

2.3 基础权限配置：自动 Run 和 Allow

Cursor 的 Agent 模式在生成代码后，执行命令或修改文件时通常需要授权。默认是每次询问，如果你在做一个连贯的还原任务，每一步都等弹窗确认会非常打断节奏。在 Settings 里有一个 Auto Run 和 Auto Allow 相关配置，打开之后，AI 在指定范围内执行命令、修改文件时就不再逐条询问。

我自己的习惯是：项目刚开始接入时保持手动确认模式，先观察 AI 的行为是否可控；确认这个项目的上下文足够安全、改动范围不会乱跑之后，再打开自动 Allow。这里提醒一句，自动权限适合你熟悉且已经跑通的场景，比如已经建立好的组件库项目；如果是全新项目，或者 AI 要访问系统级命令，我建议还是保守一点，保持确认模式。

另外建议在项目里维护一份AGENTS.md或.cursorrules文件，把项目的技术栈、目录结构、编码规范写进去。AI 在生成和修改代码时会优先参考这些规则，减少了“AI 写得挺好但不符合组内规范”的返工。我把这当成一种“虚拟新人手册”，每个项目进来先读一遍。

3. 蓝湖 MCP 服务怎么部署：一台本地小服务的搭建全过程

3.1 先理解 MCP 到底是什么，以及它凭什么打通 Cursor 和蓝湖

前面说了，MCP 是一套协议，但具体到实现层面，它描述的是三类能力：Tools（工具）、Resources（资源）、Prompts（提示词模板）。在 Cursor 里接 MCP，本质就是让 AI 在对话过程中能调用你提供的这些工具，把外部数据拉进来，再基于数据进行代码生成。

以蓝湖场景举例，我的 MCP Server 可以提供这样几个工具：

• get_project_files(project_id): 获取项目下的设计稿文件列表
• get_frame_specs(frame_id): 获取某个画板的标注数据，包括宽高、坐标、背景色
• get_layer_styles(frame_id): 获取图层样式，包括字号、字重、行高、颜色、圆角
• get_assets(frame_id): 获取切图资源下载链接
• search_by_keyword(keyword): 通过关键词搜索相关设计稿

AI 在对话中想实现“把这个页面的 Header 区域按设计稿还原”时，它会自己去调用get_frame_specs和get_layer_styles，拿到 JSON 数据后再写出代码。整个过程不需要我把尺寸抄进对话里，AI 问数据、拿数据、写代码，一气呵成。

3.2 搭建一个轻量的蓝湖 MCP Server（Node/TS 参考实现）

这里我给出一套我自己在本地跑通的参考实现。先说清楚：蓝湖的接口鉴权和使用方式以你拿到的开放平台文档为准，我这里用环境变量注入 token，避免把敏感信息硬编码在代码里。

环境准备：Node.js 18+，npm 或 pnpm 都行。核心依赖是@modelcontextprotocol/sdk，这个包里封装了 Server、工具注册、stdio 通信等基础能力。

npm init -y npm install @modelcontextprotocol/sdk

接下来创建一个server.ts。核心逻辑分三步：初始化 MCP Server、注册工具处理器、启动通信。伪代码大概长这样：

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; const server = new McpServer({ name: "lanhu-mcp", version: "1.0.0" }); // 获取设计稿文件列表 server.tool( "get_project_files", { project_id: z.string() }, async ({ project_id }) => { const data = await fetchLanhuAPI(`/projects/${project_id}/files`); return { content: [{ type: "text", text: JSON.stringify(data) }] }; } ); // 获取画板标注 server.tool( "get_frame_specs", { frame_id: z.string() }, async ({ frame_id }) => { const data = await fetchLanhuAPI(`/frames/${frame_id}/specs`); return { content: [{ type: "text", text: JSON.stringify(data) }] }; } ); async function fetchLanhuAPI(path: string) { const url = `https://api.example.com/v1${path}`; const res = await fetch(url, { headers: { Authorization: `Bearer ${process.env.LANHU_TOKEN}` }, }); return res.json(); } const transport = new StdioServerTransport(); await server.connect(transport);

这段逻辑的核心理解在于：AI 并不知道你背后调用了什么接口，它只按 MCP 协议发出“工具名 + 参数”的请求，你的 Server 负责把请求翻译成蓝湖 API，并把结果以纯文本 JSON 的形式返回给 AI。返回格式固定是{ content: [{ type: "text", text: "..." }] }，这是 MCP 协议要求的。

建议把 Server 放在一个独立的目录里，比如lanhu-mcp/，不要和前端业务代码混在一起。部署形态上我用的是本地 stdio 模式，也就是由 Cursor 进程直接拉起这个 Node 服务；如果你有多人协作需求，也可以部署成远程 HTTP 模式（streamable HTTP），但本地起步建议先用 stdio，排错最简单。

3.3 在 Cursor 里接入 MCP 并完成连通性验证

MCP Server 准备好之后，在 Cursor 里打开 Settings，找到 MCP 相关配置入口，选择添加 MCP Server，配置方式选 stdio，然后填入启动命令：

{ "mcpServers": { "lanhu": { "command": "node", "args": ["/absolute/path/to/lanhu-mcp/dist/server.js"], "env": { "LANHU_TOKEN": "your-token-here" } } } }

如果 Cursor 项目根目录有.cursor/mcp.json，也可以把配置写在这个文件里，Cursor 启动项目时自动加载。填完之后在 MCP 面板里能看到连接状态，如果显示✓ Connected，说明服务起来了。为了保险，我会做一次连通性验证：在对话里直接问 AI “调用 lanhu 的 get_project_files 工具，看看项目 ID 为 xxx 里有哪些文件”。如果 AI 能返回真实的文件列表，整条链路就算通了。

这里要特别注意一个细节：AI 未必会在你第一次提问时就主动调用工具。有时它认为仅凭上下文就能回答，就直接写了代码。我的经验是在需求描述里明确要求“调用 lanhu 工具查询设计稿标注后再写代码”。你可以把这句要求固化在 Rules 里：When working on UI implementation, always check design specs via lanhu MCP tools first。这样 AI 就会形成条件反射，先查数据再动手。

4. 实战实录：一场“设计稿直接变页面”的完整还原对话

4.1 让 AI 自己去看设计稿，而不是你替它描述

最理想的工作方式，不是你在对话里描述“按钮是蓝色、圆角的、右边距 16px”，而是你只给 AI 一个画板 ID，让它自己去拿数据。我实际跑通的对话长这样：

我：用 lanhu 的 get_frame_specs 工具，查询画板 IDframe_4820的标注数据。这个画板是首页 Hero 区域，请把它的尺寸、背景色、前景元素位置和间距都列出来。

AI：已调用 get_frame_specs，结果为：画板宽 1440px，高 720px，背景色#F5F2F0。标题图层hero-title：字号 56px，字重 700，颜色#1A1A1A，左边距 80px，顶部 180px。按钮cta-primary：宽 180px，高 56px，圆角 12px，背景色#0A66C2，文字颜色#FFFFFF……

我：基于这些数据，用 Tailwind CSS 实现 Hero 区域，图片资源先放占位。

AI 随后生成的代码，尺寸、颜色、间距基本都是对着标注数据来的。注意，它不靠“看图”猜，而是拿 JSON 字段直接映射，准确率高非常多。

这里有一个值得说的细节：我会提前在项目里维护一张“画板 ID 到页面路径”的映射表，比如frame_4820 => src/pages/home.tsx。对话开始时把映射关系告诉我 AI“先查表，再动手改文件”，这样它就知道该改哪个文件，不会出现“代码写了对但写进了错误组件”的问题。

4.2 从设计数据到可提交的页面代码

拿到设计数据后，AI 不只是生成静态 HTML，它还会自行处理响应式逻辑。比如 Hero 区域，桌面端是 1440px 的左右分布，我会追问一句：“这个画板是桌面端设计稿，请同时提供 768px 和 375px 断点下的合理布局。” AI 会根据 Tailwind 的md:和sm:前缀生成响应式类，不需要你额外写一整套媒体查询。

实际测试里，AI 生成出来的代码在小屏布局上并不是百分百和设计稿一致，因为设计稿通常只做一版或两版断点。我的做法是让它先生成，我再把设计稿的移动端画板 ID 给 AI，让它在移动端画板数据的基础上做一轮自适应修正。这样等于有两个画板的标注数据做参照，AI 写出来的响应式代码明显更贴近设计意图。

组件级还原也是一大收获。我会让 AI 把重复出现的设计模式抽象成组件，比如按钮、卡片、表单控件。因为蓝湖标注数据在多个页面之间是结构化的，AI 可以从中识别出“哪些是同一套组件体系”，然后统一维护在一个组件文件里。后续设计师改了一个按钮的颜色，前端只需在组件里改一个变量，全站联动更新。

4.3 Agent、Canvas、Highlighter 在还原场景下的组合用法

Cursor 的 Agent 模式在还原场景里非常好用。你可以在一个对话里交给它一个完整任务，比如“把首页设计稿还原任务拆成 Header、Banner、功能列表、Footer 四块，逐个调用蓝湖工具获取标注，然后按顺序实现”。Agent 会自主规划、逐个执行，遇到缺失数据还会反过来向蓝湖工具追问。这个能力意味着你不再需要盯着一行行代码写，而是像带实习生一样，把大任务拆好，然后在关键节点抽查。

Canvas 功能适合多文件联动修改。还原一个页面往往同时涉及page.tsx、components/Header.tsx、styles/tokens.css几个文件。Cursor 的 Canvas 可以把这些相关文件平铺在一个画布空间里，AI 在修改某个组件时，能同时看到其他文件的上下文，减少“改了组件但其他文件没同步”的低级错误。我习惯在开始大块还原前，先把涉及的文件在 Canvas 里铺好，AI 改起来更连贯。

Highlighter 则是我用来做精确检查的工具。AI 生成完后，我如果对某个区块不太确定，会在代码里高亮那一段，再附加一句“检查这段代码的间距和颜色是否符合蓝湖标注”。Cursor 会基于高亮区域精准定位，而不是把整个文件重新读一遍，效率和准确度都高很多。这三样工具叠加下来，我主导的一场还原对话，基本可以达到“设计师不再追着问还原了吗”的状态，因为每一处关键样式都有数据依据可查。

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

5.1 MCP 服务连不上、超时、鉴权失败怎么办

MCP 连接失败是最高频的问题。如果你在 Cursor 的 MCP 面板看到Error或timeout，先按这个顺序排查：

先确认服务本身能跑。在终端手动执行启动命令，看有没有报错。Node 服务最常见的低级错误是路径不对，args里写的绝对路径和实际编译输出路径不一致。再看端口或 stdio 通道是否被占用；我用 stdio 模式时偶尔会发现上一个 node 进程没退出，导致新连接挂不上，杀掉旧进程就恢复了。

接着看鉴权。蓝湖 API 的 token 如果过期，AI 调用工具时会收到 401 错误。这时 MCP 配置里的LANHU_TOKEN需要更新。我建议把 token 放到环境变量而不是直接写进mcp.json，避免随着项目文件被提交到仓库里，造成泄露。

再看超时。蓝湖接口偶尔响应慢，如果 AI 调用工具后长时间没反馈，可以把 MCP 客户端的超时时间适当调大，或者在 Server 里加一层简单的缓存：把最近一次获取的 frame spec 存下来，AI 重复查询同一个画板时直接读缓存，响应会快很多。

5.2 Cursor 账号登录、额度与安全提示

登录不了是最常见的账号问题。可以先检查网络环境是不是企业内网拦截了连接，然后在官方网站确认当前服务状态。如果提示邮箱密码不正确，用官方“忘记密码”流程重置即可。还有一个容易忽略的点：如果你是通过第三方快捷登录注册的账号，后来想改用邮箱密码登录，需要先在账号设置里绑定邮箱，否则会提示账号不存在。

额度相关的坑我在前面提过，这里再补充一个高频疑问“复购时为何不是从当前日期生效”。因为订阅是顺延制，续费购买只是延长截止日期，不会立刻刷新快速额度。如果你已经处于取消订阅状态再重新购买，则会从购买日开启新周期。官方设置页里能看到当前周期的到期时间和剩余额度，团队采购前建议截图存档。

安全方面要特别提一下“提示词泄露”。Cursor 的 Rules、.cursorrules、AGENTS.md都是文本文件，如果你参与开源项目，或者项目仓库有外部协作者，别把敏感规则或私密 token 写进去。另外，来路不明的第三方 Skill 或插件可能包含恶意提示词，安装前要检查其内容。我的原则是：能用官方能力满足的需求，不引入来路不明的扩展。

5.3 避坑速查表

我把这段时间踩过的坑整理成一个速查表，方便对照处理。

6. 同一条路，还能接到更多工具上

6.1 Codex CLI / Claude Code 同样可以接蓝湖

MCP 是开放协议，不是 Cursor 专属。所以当我在 Codex CLI 里也想读设计稿数据时，直接把同一个 MCP Server 的配置指过去就行。Codex CLI 的 MCP 配置格式和 Cursor 高度相似，都是声明mcpServers，然后指定 command 和 env。Claude Code 也支持 MCP，配置路径稍有不同，整体思路完全一致。

这意味着你的 MCP Server 是一份可以被多个 AI 工具复用的资产。团队里有人习惯 Cursor，有人习惯 Codex，有人用 Claude Code，共享同一个蓝湖 MCP 服务，至少在设计稿数据读取上体验是统一的。我个人的建议是：先把一套打通，跑稳之后再做另一个客户端的适配，别同时铺太多线。

6.2 接 Dify 知识库、CodeGraph 与 Skill 生态

顺着 MCP 这条路往外扩展，我还在 Cursor 里接了 Dify 知识库。方式同样是配置一个 MCP Server，让 AI 在需要时查询组织内部的规范文档。比如设计规范、组件库使用约定、项目目录规范这些内容，AI 通过 Dify 工具检索到之后，生成的代码会明显更贴合团队既有体系，而不是每次都要在对话里重新交代一遍。

CodeGraph 这类代码图谱工具也可以集成进来。它通过分析代码库，生成函数、组件、模块之间的依赖关系图，MCP 接口把依赖查询暴露给 AI 之后，AI 在修改某个组件前会先查看它被哪些地方引用，降低了“改了这里、炸了那里”的风险。这个能力在还原大规模页面时特别有用，因为一个设计改动可能影响多个业务页面。

再说说 Skill 生态。Cursor 目前支持用户编写和加载一些“技能包”，本质上是把一组提示词和操作流程固化下来。我猜不少人搜过“Cursor 有哪些 Skill 推荐”，我的建议是别急着下第三方打包好的。自己写两三个针对当前项目的 Skill，比如“蓝湖还原”“组件规范检查”“响应式适配检查”，比装一堆通用包管用。自己写的 Skill 完全理解你的业务流程、目录结构和规范，AI 执行起来更贴合实际。第三方 Skill 你无法判断它的隐式指令是否安全，至少先用两三天观察它在对话中产生的行为。

最后再分享一个我在实际使用中的体会

整个方案跑通之后，我最大的感受不是“前端终于可以不干活了”，而是“沟通终于可以基于数据而不是基于感觉了”。以前设计师问“为什么按钮颜色不对”，我要解释半天色值哪里不一致；现在 AI 是照着蓝湖标注写的代码，如果不对，大概率是标注本身需要更新，直接拿着工具返回的数据回去对齐就行。

如果你也想做这件事，我的建议是先把范围缩小。不要一上来就想把整个项目所有页面都交给 AI 还原，先挑一个活动页或一个独立组件试跑，把 MCP 服务的稳定性、AI 生成代码的准确率都摸清，再逐步扩大。另外一定要记得在 Rules 里固化“先查标注，再写代码”的约束，这一步是还原精度的生命线。踩过几次坑之后，我现在的流程已经稳定成：设计师传稿，我来写映射表，AI 自动查数据、出代码，我做抽查和微调，最后把标注比对结果贴回去。设计师看到的是还原过程有据可循，我看到的是群里少了几十轮“还原了吗”。这就是我理解的 AI 编程工具的真正的价值：不是把前端变成质检员，而是让人从来回拉扯的沟通里解脱出来，把精力放回真正需要判断的事情上。