一份围绕通用技能 lanhu-design-to-html 的完整介绍——它可在各种智能体中通用，并非某平台内置；并从定位、架构、数据获取方式、切图处理、协作能力等维度，与第三方开源的 lanhu-mcp 进行系统对比，帮助你在"还原设计稿为 HTML"场景下做出合理选型。
两者都能"读取蓝湖设计稿"，但出发点和工作方式截然不同。
把蓝湖设计稿还原成 HTML，目前有两条主流路线。一条是 通用的 lanhu-design-to-html Skill——它是一份写给 Agent 的"操作手册"，可在各种智能体中通用（非某平台内置），指导 Agent 用 playwright-cli 打开蓝湖网页、抓取 Sketch JSON、解析图层、下载切图到本地，最终产出可直接部署的 HTML 页面。另一条是 第三方开源的 lanhu-mcp（MCP Server）——它是一个常驻服务进程，通过蓝湖开放 API 把"设计稿/切图/需求文档/团队协作"封装成一组 MCP 工具，供 Cursor、Claude Code、Trae 等任意支持 MCP 的 AI 客户端调用[1][2]。
Skill 是"一份让 Agent 自己动手抓取并还原 HTML 的指南"；MCP 是"一个把蓝湖能力标准化成工具、供 AI 随时调用的服务"。前者重产出、自包含；后者重连接、重协作。
一份面向 Agent 的、从蓝湖链接直达可部署 HTML 的操作指南。
lanhu-design-to-html 是一项可在各种智能体中通用的 Skill（非某平台内置），定位是"从蓝湖设计稿链接获取设计信息并还原为 HTML 页面"。当用户提供 lanhuapp.com 链接、或要求分析/还原蓝湖设计稿时被触发。它本身不是常驻进程，而是一套由 SKILL.md 主文档加三份参考文档（工作流、数据解析、HTML 实现）和两个 Node 脚本（解析、下载切图）组成的"操作手册"，指引 Agent 用 playwright-cli 完成全流程。
整体链路为：蓝湖链接 → 打开浏览器 → 获取 Sketch JSON → 解析图层/样式 → 下载切图到本地 → 分析结构 → 生成 HTML → 验证效果。共七个步骤：
--persistent 持久化模式打开浏览器导航到设计稿，等待 3-5 秒后检测登录状态；未登录则切 --headed 让用户手动登录，登录态会被保存，下次自动保持。playwright-cli requests 找到含 SketchJSON / alipic.lanhuapp.com 的请求，再 response-body 拿到完整的图层/样式/切图数据。parse-design.js 解析，输出 design-analysis.txt（人类可读报告）与 design-layers.json（结构化数据）。download-images.js 按 SVG > PNG > DDS 优先级下载到 assets/images/，并生成 image-map.json（URL → 本地路径映射）。⭐ 切图可用 标注。<img> 还原，无切图元素才用 CSS 文字/形状实现。凡设计稿提供了切图的元素，直接用 <img> 实现，不要用 CSS 还原。切图能 100% 还原视觉效果（含特殊字体、复合边框、阴影、渐变叠加），CSS 还原常有偏差。
适用于所有图层类型：文本图层有切图→用切图（解决特殊字体不可用）；形状图层有切图→用切图；分组图层有切图→用整组一张图，不要拆分实现。
所有切图必须下载到本地 assets/images/，HTML 中只引用本地相对路径，严禁使用蓝湖 CDN 链接（如 lanhu.oss-cn-beijing.aliyuncs.com、alipic.lanhuapp.com）。原因是 CDN 链接可能因权限/防盗链/失效而无法显示，本地化后页面可离线运行、便于部署、加载更稳定。
image-map.json 供 HTML 替换。playwright-cli 已安装（用于浏览器自动化与抓包）。fromEditor=true 参数才能进入标注视图、拿到 Sketch JSON。第三方开源 MCP Server，让任意支持 MCP 的 AI 客户端都能读取蓝湖。
lanhu-mcp（项目地址 github.com/dsphper/lanhu-mcp）是一个基于 Model Context Protocol (MCP) 协议的第三方开源服务器，专为蓝湖设计协作平台打造。它通过蓝湖开放 API 把"设计稿/切图/需求文档/团队协作"封装成一组标准化工具，供 Cursor、Windsurf、Claude Code、Trae、通义灵码、Cline 等任意支持 MCP 的 AI 客户端调用[1][2]。
| 工具名称 | 类别 | 功能 |
|---|---|---|
lanhu_resolve_invite_link | 项目协作 | 解析邀请链接并加入项目 |
lanhu_get_pages | 设计获取 | 获取原型页面列表 |
lanhu_get_ai_analyze_page_result | AI 分析 | 分析原型页面内容、提取需求 |
lanhu_get_designs | 设计获取 | 获取 UI 设计图列表 |
lanhu_get_ai_analyze_design_result | AI 分析 | 分析 UI 设计图、返回设计参数 + HTML/CSS |
lanhu_get_design_slices | 资源获取 | 获取设计切图信息 |
lanhu_say | 评论协作 | 发布留言、@提醒 |
lanhu_say_list / _detail / _edit / _delete | 评论协作 | 查看 / 详情 / 编辑 / 删除留言 |
lanhu_get_members | 团队管理 | 查看团队成员 |
需注意：lanhu-mcp 需 Python 3.10+、需手动配置蓝湖 Cookie，且明确要求使用支持视觉功能的 AI 模型（Claude / GPT / Gemini / Kimi / Qwen / DeepSeek 等），不支持纯文本模型[1]。
从定位、架构、数据获取、切图处理、协作能力等维度逐项对比。
下图直观呈现两种方案从"蓝湖链接"到"HTML"的数据通路差异：
flowchart LR
subgraph SK["lanhu-design-to-html (Skill)"]
direction TB
A1["蓝湖链接"] --> A2["playwright-cli
打开浏览器抓包"]
A2 --> A3["取 Sketch JSON
(完整图层/样式)"]
A3 --> A4["parse-design.js
解析图层树"]
A4 --> A5["download-images.js
切图下载到本地"]
A5 --> A6["Agent 直接生成
可部署 HTML"]
end
subgraph MCP["lanhu-mcp (MCP Server)"]
direction TB
B1["蓝湖链接"] --> B2["MCP 工具调用
(开放 API)"]
B2 --> B3["get_designs /
analyze_design"]
B3 --> B4["返回设计参数
+ HTML/CSS 参考"]
B4 --> B5["AI 参考实现
(非直出)"]
end
SK -. 同为蓝湖设计稿 .-> MCP
| 对比维度 | lanhu-design-to-html Skill | lanhu-mcp MCP |
|---|---|---|
| 产品定位 | 本地操作手册：指导 Agent 抓取并直出 HTML | 常驻服务：把蓝湖能力标准化为 MCP 工具 |
| 数据获取方式 | 浏览器自动化抓包（playwright-cli 取 Sketch JSON） | 蓝湖开放 API（经 Cookie 鉴权的 HTTP 接口） |
| 是否需常驻进程 | 否，按需触发，无服务端 | 是，需启动 Server（Docker/源码/stdio） |
| 是否需额外账号/Cookie | 仅需蓝湖账号登录态（首次登录持久化） | 需手动从浏览器复制蓝湖 Cookie 配置 |
| 切图本地化 | 强制，脚本批量下载 + image-map.json 映射，禁用 CDN | 可选，提供切图工具，命名由 AI 决定 |
| 切图优先策略 | 内置硬性规则，有切图必用 <img>，禁 CSS 还原 | 无此约束，交由 AI 自行判断 |
| HTML 产出形态 | Agent 直出可部署 HTML（含本地 assets） | 返回设计参数 + HTML/CSS 参考，AI 再据此实现 |
| 设计参数精度 | 完整 Sketch JSON（图层/字体/颜色/圆角/阴影/渐变全字段） | 组件尺寸/间距/颜色/字体等参数 + 转换后代码 |
| 需求文档分析 | 不支持，专注设计稿还原 | 支持，Axure 三模式分析、交付物 |
| 团队协作 / 留言板 | 无 | 核心特性，跨 IDE 共享知识库、@飞书提醒 |
| 多端单位切换 | 支持 iOS/Android/Web/小程序(pt/dp/px/rpx) | 主要面向设计参数 + HTML/CSS |
| 客户端兼容性 | 通用，任意支持 Skill 的智能体（需 playwright-cli + Node） | 广泛，任意支持 MCP 协议的 AI 工具 |
| 部署/维护成本 | 低，零服务端，随 Skill 即用 | 中，需维护服务、Cookie、Python 环境 |
| 离线可用 | 是（切图下载后） | 否，依赖在线 API |
| Token 消耗 | 低，重活交给本地脚本，上下文只留文本摘要 | 高，含多模态图片预览 + 多轮工具调用累积 |
两者在"切图"这件事上的处理力度差异最大，这直接决定了 HTML 还原度：
⭐ 切图可用，明确建议用 <img>lanhu_get_design_slices 可获取切图信息两者在"把设计稿数据喂给 AI"的方式上差异，直接决定了单次任务的 token 消耗量级。下图以"还原一个中等复杂度的蓝湖画板（约 30-50 个图层）"为基准，估算上下文中各部分的 token 占比：
parse-design.js 在本地解析，Agent 只读摘要报告（几 KB）get_designs → analyze → get_slices → say 每次返回都进上下文Skill 的设计哲学是"让本地脚本干重活，上下文只留必要的文本摘要"，因此 token 消耗低且稳定；MCP 的设计哲学是"把设计稿结果（含图片）直接交给 AI"，多模态内容天然占用更多 token，且随工具调用轮次与知识库规模增长。在按 token 计费的场景下，单次还原任务的 token 成本 Skill 通常低一个数量级。
两者并非互斥，而是互补——按"目标产出"选择。
两者可并用：用 lanhu-mcp 快速获取设计稿/切图信息与需求文档，再交给 lanhu-design-to-html Skill 按"切图优先 + 本地化"的硬性规范完成 HTML 还原与验证。前者解决"连接与获取"，后者解决"规范与产出"。
从"还原设计稿为 HTML"这一核心目标看，lanhu-design-to-html Skill 在产出规范、切图本地化、还原度保障上更强，它是"为还原 HTML 而生"的；而 lanhu-mcp 在跨客户端连通、需求分析、团队协作上更全面，是"为蓝湖与 AI 协同而生"的。理解这条边界，就能在不同任务中各取所长。