Cursor接入蓝湖MCP，AI自动检查设计稿还原度

“还原了吗”这三个字过去半年里是设计师在群里问我最多的一句话。每次版本要提测我跟设计师都得把蓝湖上的设计稿、线上页面拉到一起左一张截图右一张截图挨个核对字号、间距、颜色。眼睛看花不说还经常漏掉一两处等设计师验收时又被打回来。后来我换了个思路把 Cursor 直接接到蓝湖上通过 MCP 让 AI 读设计稿标注自己对比本地代码最后自动生成一份还原度差异清单。设计师点开清单就能看到哪里差了不用再追着问我“还原了吗”。这篇文章是我完整踩完一遍之后的记录包括 MCP 原理、部署步骤、权限配置和常见问题一次说清楚适合正在被设计还原和沟通成本折磨的开发者参考。1. 还原度核对为什么是个真问题1.1 人肉比对浪费的不只是时间很多人觉得“还原度”是个很虚的词差不多就行了。但真正到了上线前设计师和开发之间频繁出现的对话通常长这样设计师问“还原了吗”开发说“差不多了”设计师再问“那间距呢按钮 hover 呢空状态呢”开发开始翻代码。这种沟通本质上是在做一件特别机械的事——把设计稿上的标注和代码里的样式逐个比对。如果项目不大还好碰到一个页面几十个组件、多个断点、一堆状态光核对这件事就能消耗掉大半天。我算过一笔账一次常规迭代光“确认还原”至少经历四轮。开发对着蓝湖抄参数、写完自测肉眼过一遍、设计师登录线上环境核对截图、发现问题截图发群里然后开发再改、再确认。一轮下来半小时起步复杂组件来回三四轮很正常。一个月下来几十个小时就没了。这些时间几乎不产生任何沉淀纯属信息在两边之间倒来倒去。更难受的是人肉比对的结果不可追溯。这轮改完了设计师说“OK”但没人记录到底哪里对齐了下轮需求一改之前对齐过的细节又悄悄跑偏。等到问题暴露往往已经上线修复成本翻倍。所以“还原度核对”不是礼仪问题是工程问题它是可以被打磨的流程短板。1.2 问题的本质设计稿和代码之间缺一座桥对开发来说蓝湖上每一个画板背后都有一组精确的数据某个按钮宽度是多少、圆角是多少、字体字号、行高、间距、颜色色值。对 AI 编程工具来说它读代码很容易但读不到蓝湖上的设计数据。于是人和 AI 都被困在同一个断层里设计稿是这个系统代码是另一个系统中间靠人肉搬运。MCPModel Context Protocol模型上下文协议补的正是这座桥。你可以把 MCP 理解成一个“万能插座”AI 不需要自己连接数据库、不需要写代码调每个 API而是通过统一的 MCP Server 暴露一组工具AI 按需调用。对 Cursor 来说蓝湖 MCP Server 就相当于给它装了一套“读设计稿”的能力比如列出文档、读取画板节点、提取标注信息。Agent 在回答“这个按钮到底对不对”之前会先主动调函数把蓝湖上的真实设计数据拉回来再和本地代码逐项比较。这个转变有个关键点以前是“把数据拿到人眼前人肉看”现在是“把数据交给 AIAI 直接输出差异结论”。人只需要审结果不需要参与搬运。搬运越少出错概率越低沟通成本也随之降下来。1.3 这套方案适合谁又不适合谁先说适合的场景。第一团队设计稿统一在蓝湖上开发习惯直接从蓝湖抄标注这是最基本的前提第二你日常用 Cursor 写代码愿意接受 Agent 帮你做多步操作第三你手头有成体系的页面、组件库要做还原度审计而不是只有一两个临时页面。满足这三点这套方案带来的收益最明显。不适合的情况也有。比如团队设计流程还在用纯 PDF 截图传需求没有结构化的设计数据MCP 读不到可解析的标注方案就无从谈起再比如你只是偶尔用 Cursor 写写脚本并不做前端页面那蓝湖接入对你的意义也不大。另外要泼一盆冷水这套方案解决的是“可量化规格”的核对解决不了“这个设计好不好看”的审美分歧。审美判断依然要设计师拍板AI 只是个会读数字的校对员。2. 方案选型为什么是蓝湖 Cursor MCP2.1 设计稿的“事实源”放在蓝湖蓝湖在国内团队里使用率很高尤其是需要多人协作的设计交付环节。设计稿从 Sketch、Figma 同步上来之后标注、切图、版本记录都在一个地方开发只要打开蓝湖就能拿到需要的尺寸、颜色和切图资源。我选择蓝湖作为“事实源”还有一个重要原因它有开放 API数据可以被程序读取。这是整个方案的地基。设计数据如果不能被代码访问那 AI 再聪明也只能“看图说话”一旦遇到具体参数就会含糊。蓝湖开放平台天然提供了程序化读取设计稿数据的能力再通过 MCP Server 包装给 AI就变成了一个可靠的结构化输入源。如果你团队用的是其他设计协作工具也不用急着照搬配置。判断标准很简单它有没有开放 API、有没有官方或社区提供的 MCP Server。有就能用同样的思路打通没有你得先自己写一个包装层跨过“读取数据”这一步。2.2 Cursor 的 Agent 为什么适合当“读稿人”现在市面上能跑 AI 的编辑器不少我没选别人主要因为 Cursor 的 Agent 模式太适合这类“多步取证”的活儿。它不是一个只会改光标的补全工具而是能自己规划任务、一步步执行的东西。还原度检查这个场景天然就是多步任务先找设计稿节点、再提取标注、然后读代码、最后生成对比报告。如果让普通 AI 补全来做每一步都得人手动喂信息等于把搬运成本转移到对话里并没有省时间。Cursor 对 MCP 的原生支持也是一个加分项。它能直接注册 MCP Server在对话中自动调用相应的工具并且把工具返回结果当成上下文来推理。我可以直接跟它说“对比一下蓝湖里 Hero 区域的设计稿和前端的组件实现”它会自己去调蓝湖 MCP、去读本地代码、去写报告。这比在纯聊天工具里来回贴代码高效得多。另外Cursor 本质是 VS Code 的分支它对本地工程的上下文理解很强能识别出哪个文件对应哪个组件能跳到精确的代码行给出修改建议。这对后续的还原修正很有用AI 指出问题后能顺手给到改法而不是扔给你一句“你自己查查”。2.3 MCP 接入方式的权衡stdio 还是 SSE接 MCP 的方式通常有两种本地 stdio 和远端 SSE。stdio 模式是在你的电脑上启动一个本地进程Cursor 与它通过标准输入输出通信SSE 模式则是连接一个远程服务地址通信走 HTTP。对我个人以及多数团队来说首选 stdio。理由很直接第一本地启动意味着凭证在本地环境变量里不外发安全性可控第二不需要单独部署维护一个远程服务少一层故障点第三调试方便终端里就能看到日志出问题好排查。SSE 适合的场景是一个团队共享同一个 MCP 服务比如由后端同学在服务端部署好蓝湖 MCP 网关前端同学在 Cursor 里填一个地址就能用。这样省去了每个人都去申请凭证的麻烦但代价是要维护服务稳定性和鉴权。小团队我建议别折腾本地 stdio 足够。3. 蓝湖 MCP 部署全流程3.1 准备工作清单动手之前先确认几样东西。一是蓝湖账号最好是有项目权限的账号能用个人身份访问到设计稿二是 Cursor 版本不要太老新版本对 MCP 的配置界面更友好三是本机有 Node.js 环境因为 MCP Server 通常基于 Node 运行建议用 LTS 版本版本太低会导致很多新包跑不起来。还有一个容易被忽略的准备和设计团队确认哪些画板是当前迭代的“定稿”不要把还在改动的设计稿源头接进来。AI 每次拿到的都该是确定的数据否则你这边检查得越勤快另一边设计师改一版结果全作废。我经历过一次检查报告刚发给设计师设计师说“哦那个改了”整份报告作废非常浪费时间。3.2 蓝湖侧申请凭证与确认权限登录蓝湖开放平台创建一个应用。不同时期的界面入口不太一样但流程大致相同填应用名称、选择需要的 API 权限范围、提交后得到一组 Client ID 和 Client Secret或者一个长期有效的 Access Token。具体以蓝湖开放平台当前文档为准关键点是让这份凭证至少包含“读取设计稿数据”的权限而不是只有管理类权限。拿到凭证后先从蓝湖文档里核对一下当前推荐的 MCP Server 包名和启动命令。这一步很关键因为 MCP Server 的包名如果写错后续配置全部白搭。我的建议是先在终端里手动方式验证一次能启动再进 Cursor 配置这样能区分是 MCP Server 本身的问题还是 Cursor 配置的问题。顺带提一句凭证一定要当成密码对待。Client Secret 一旦泄露别人拿到就能读你团队设计稿里的全部标注。别把它写死在代码里更别贴到公开仓库。我见过有人图省事直接写进环境变量文件后一股脑 commit 到 git后果就是全组人都在找那个 token 是谁泄露的。3.3 启动本地 MCP Server在终端里先跑一次。假设蓝湖文档给的包名是lanhu/mcp-server实际包名以官方文档为准命令大致长这样export LANHU_CLIENT_ID你的ClientID export LANHU_CLIENT_SECRET你的ClientSecret npx -y lanhu/mcp-server首次执行时 npx 会联网拉包可能有十几秒等待。如果终端正常输出类似MCP server running...的日志说明服务能起来。如果提示ENOENT或command not found多半是 Node 环境或 PATH 没配好建议先用node -v确认版本再考虑升级或切换到 LTS。这一步我不建议跳过因为很多 Cursor 里显示 “Failure” 的问题根源都在 MCP Server 压根没能在本地跑起来。先把它单独跑通后面配置就顺了。3.4 在 Cursor 里注册 MCP Server在 Cursor 的 Settings 里找到 MCP 配置入口选择新增。配置类型选 stdioCommand 填npx -y lanhu/mcp-serverEnvironment 里按照 keyvalue 的格式填好蓝湖凭证例如LANHU_CLIENT_ID你的ClientID LANHU_CLIENT_SECRET你的ClientSecret保存后 Cursor 会尝试连接状态变成绿色 Connected 就代表成功。如果是红色 Failure先回 3.3 排除 Server 本身的问题再检查 env 变量名和值。如果你的团队是多人协作我更推荐项目级配置。在项目根目录建一个.cursor/mcp.json结构类似{ mcpServers: { lanhu: { command: npx, args: [-y, lanhu/mcp-server], env: { LANHU_CLIENT_ID: 你的ClientID, LANHU_CLIENT_SECRET: 你的ClientSecret } } } }这个文件可以被版本管理收录团队成员 clone 项目后就有了同样的 MCP 配置只需各自把 env 里的凭证换成自己的。注意.cursor/mcp.json如果包含真实凭据别提交到 git可以参考.cursor/mcp.example.json放模板真实文件用.gitignore排除。3.5 权限授权与自动允许MCP Server 注册好之后Agent 并不会一上来就乱调工具。它每次想调用某个 MCP 工具时Cursor 会弹出权限请求你可以选择允许一次也可以勾选允许始终。对于“读设计稿标注”这类只读操作我建议直接允许始终避免每轮对话都弹窗打断思路。但如果后续你在蓝湖 MCP 上扩展了有写操作的工具比如评论、修改标注、上传资源那就得谨慎了。凡是会改变外部系统状态的工具保持“每次询问”更安全。我自己的原则是读的全放行写的一律逐次确认。这样既保证效率也避免 AI 在对话里自作主张把不该动的东西改了。4. 实战让 Cursor 自动做还原度体检4.1 先把检查指令模板化MCP 配置好不代表 AI 会自动帮你检查还原度你得给它一个清晰的任务。很多人输 prompt 太随意给一句“帮我检查一下这个页面还原度”AI 一脸懵只能给你输出一段正确的废话。正确做法是把检查范围、数据源、输出格式都写清楚。我整理了一个可复用的模板请对 src/pages/home.tsx 做设计还原度检查。 1) 用蓝湖 MCP 读取设计稿「首页-新版」画板下「Hero区按钮组」节点的标注 2) 提取该节点的尺寸、圆角、颜色、字号、内边距和外边距 3) 打开本地对应组件文件逐项对比并列出差异 4) 按 Markdown 表格输出项目 | 设计稿 | 代码现状 | 差异类型 | 建议修改。这里的关键是“输出格式”。如果你不指定表格AI 很可能给你一坨长篇大论信息都在里面但可读性很差。一旦指定了表格它就会老老实实逐项列出来后续贴给设计师看也方便。4.2 一次还原度检查的全过程回放我拿一个真实场景给你演示一下。假设设计稿里有个卡片组件蓝湖标注是宽度 320圆角 16背景色#FFFFFF标题字号 20标题到正文间距 16整体外边距 24。我把这个任务交给 Cursor它做了几件事第一调用蓝湖 MCP 里的工具读取「卡片组件」对应的节点拿到结构化的标注数据第二自动定位到本地src/components/Card.tsx第三逐项和代码对比第四生成一张差异表。实际输出的表大概是这样的项目设计稿代码现状差异类型建议修改宽度320px100%尺寸冲突改为固定 320px 或 max-width圆角16px8px参数偏差调整为 16px背景色#FFFFFF#F7F7F7色值偏差改为 #FFFFFF标题字号20px18px参数偏差改为 20px外边距24px32px间距偏差改为 24px整个过程我只给了那一句模板剩下全是 Agent 自己跑的。你要说它神奇吧其实逻辑很简单但就是这层简单逻辑省下了我以往至少半小时的截图和对照功夫。4.3 别把“像素级还原”当成目标接完 MCP 之后我发现一个误区很多人期望 AI 能拍胸脯保证“像素级还原”这是不现实的。设计稿是静态图代码运行在真实浏览器里两者之间天然有差异。响应式断点、rem/em 换算、不同系统的字体渲染、浏览器默认样式都会让实际效果和设计稿不完全一致。所以我把还原度检查的定位改成了“可量化规格的差异扫描”。它适合抓尺寸、间距、颜色、字号这类能精确对照的指标但不适合判断“这个阴影是不是太硬”“这个渐变层次对不对”这种视觉感受。后者的校验还是要靠设计师眼睛。我把话说得直白一点AI 是个靠谱的度量员但不是审美的裁判。想清楚这一层你对它的期望就不会落空。4.4 把检查结果变成设计师能看的页面还原度检查报告如果只躺在 Cursor 对话框里设计师还是看不到那就成了一场自嗨。更好的做法是让 AI 把结果输出成一份 Markdown 或 HTML 文件比如放到docs/design-check/2025-06-01.md然后把链接发到群里。设计师打开文件就能看到差异表哪里不行一目了然不用登录 Cursor。更进一步如果团队 CI 玩得转你可以把 MCP 检查脚本化在合并请求触发时自动跑一轮还原度扫描把结果作为评论发回去。如此“还原了吗”就不再是反复追问的口头禅而是一个每次合代码前都会自动产出答案的门禁。这个方向我们已经在部分项目里试了效果比预期好至少设计师和开发的来回对话少了很多。5. 高频问题与避坑速查5.1 蓝湖 MCP 部署踩过的坑第一个常见坑是 npx 首次启动失败。解决方式是把 Node 切到 LTS 版本很多时候是版本太低导致新包不兼容。改了版本之后如果还失败试着清一下 npx 缓存npm cache clean --force第二个坑是 Cursor 面板显示 “Failure”。先回终端手测 MCP Server 是否能启动再检查 env 变量名。我踩过一次蓝湖文档里的变量名是小写下划线我在 Cursor 里填成了大写结果服务一直起不来。这事别指望 AI 帮你查它虽然会看文档但对环境变量名的大小写敏感度完全取决于文档是否写得清。第三个坑是权限范围。MCP 能读到的设计稿范围取决于凭证对应的蓝湖账号权限。如果你在开放平台创建的凭证没有关联到对应项目就会遇到“连接正常但查不到节点”的情况。这时候不要怀疑 MCP 配置先去确认凭证权限。5.2 Cursor 账号登录与额度的坑Cursor 用久了多少会碰到一些账号相关的报错。最经典的是弹窗提示 “too many computers used within the last 24 hours for the same Cursor account”。这个意思是在过去 24 小时里同一个账号在多台设备上登录过Cursor 的风控拦住了你。解决办法不复杂等 24 小时后再登录或者去 Cursor 官网清理不常用的设备会话。我的经验是别频繁在电脑、备用机、虚拟机之间切换同一个账号除非你真的需要否则很容易触发这个提醒。额度方面Cursor 分为免费、Pro、Ultra 等档位具体额度以官网当前说明为准。我提醒一点Pro 计划里有快速请求额度和慢速请求额度的区分日常写代码够用但如果你开启了按量计费模式超出时会额外扣费突然多一笔账单别意外。如果只是偶尔检查一下还原度把这类耗时长但频率低的任务放在慢速请求模式就足够了没必要每次都开着按量计费。5.3 中文设置、Skills 和常用技巧很多中文用户问 Cursor 怎么设置中文。说实话Cursor 目前没有官方简体中文界面第三方汉化包又容易被版本更新搞失效我不太推荐折腾界面汉化。更实际的做法是让 Agent 用中文回复你在项目根目录写一个.cursorrules文件第一行写上“请始终用中文回复”或者把同样的话放进 Cursor 的配置里。这样界面虽然是英文但对话内容、报告输出全是中文一点都不影响干活。另外如果你的 Cursor 版本支持 Skills强烈建议把 4.1 那段检查模板固化成一条自定义 Skill。以后在对话里输入检查还原度再加一句“首页 Hero 区”Agent 就自动按模板执行比每次手动贴 prompt 省心很多。MCP 是给 AI 接数据的能力Skills 是给 AI 定流程的能力两者配合起来还原度检查才能真正做到一键触发。5.4 提示词边界与数据安全最后说点安全相关的事。Cursor 这类云端 AI 工具在处理代码时会把相关上下文发送给模型服务商。如果你公司有严格的数据合规要求涉及核心商业逻辑、金融交易、未公开产品策略的代码建议谨慎使用。你可以在 Cursor 的隐私设置里关闭“训练数据共享”类选项具体名称以当前版本界面为准关掉之后能减少一部分数据被用于模型训练的风险。还有一个特别容易踩的雷有人在对话提示词里贴 API Key、数据库连接串、或者蓝湖的 Client Secret。“AI 能帮我查一下这个 key 能不能用”这种想法偶尔会有但代价是敏感信息进入模型服务商的日志。我的原则是所有密钥只放在环境变量或本地配置里绝不贴进对话框。MCP 的初衷就是让 AI 通过安全接口读数据而不是让你把凭证喂给它。守住这条边界工具才是工具。最后分享一点个人体会。把 Cursor 接到蓝湖上技术难度其实不高真正的价值在协作方式的改变以前设计师问“还原了吗”我回答“差不多”现在 AI 能拿出具体的差异清单设计师在自己方便的页面里就能看到结果双方聊的是事实而不是感觉。我更惊喜的是这堆配置跑通之后“还原度”从一个临时沟通话题变成了一条可重复执行的工程检查链路。建议你先拿一个小画板跑通全流程再慢慢扩展到核心页面。跑通之后你大概率会发现这句“还原了吗”真的能从聊天记录里消失。