| name | lanhu-to-code |
| description | 从蓝湖(Lanhu)设计稿还原前端页面的完整工作流,覆盖**移动端 H5** 与 **PC / 桌面端**两类设计稿。当用户 提到蓝湖、设计稿、还原/实现设计稿、切图、设计还原,或直接贴出蓝湖设计链接、意图把一份设计变成前端页面时, 优先使用此 skill——即使用户没有明确说"还原"二字也应触发。流程会先判断设计稿是 H5 还是 PC,再走对应分支 (H5 需识别真机外壳并做移动端适配,PC 跳过这两项)。覆盖:通过 MCP 连接蓝湖并处理登录凭证失效、平台判断 与分支处理、以可交互为核心的还原方式、切图资源规范、组件拆分与样式及 UI 框架选择。 |
蓝湖设计稿还原前端(H5 / PC)
把一份蓝湖设计稿变成真实可用的前端页面。核心心态:设计稿是页面某个瞬间的静态快照,你要交付的是一个活的、能在真实环境里正常工作的页面,而不是像素级复刻一张图片。
本 skill 同时支持两类设计稿,大部分流程是共用的,只有两处按平台分支(是否识别真机、是否做移动端适配):
- 移动端 H5:竖屏、单列为主,细节见
references/mobile-h5.md
- PC / 桌面端:宽屏、多列/栅格,细节见
references/pc.md
整体流程
- 拿到蓝湖设计链接 → 用 MCP 解析设计稿(见「连接蓝湖」)
- 判断设计稿是 H5 还是 PC,决定后面走哪条分支(见「判断平台」)
- 确认样式方案、UI 框架与项目规范;项目里没有相应方案时,先停下来问用户,别自己默认(见「样式方案」「UI 框架方案」)
- 拆分组件、下载切图、编写页面,围绕可交互目标;H5 分支还要做可适配
- 回读自己写的代码做一遍静态自检(见「自检清单」+ 对应平台分支的追加项)
连接蓝湖
用 lanhu-context-mcp 的 get_design_context 工具解析设计稿。它接收一个蓝湖设计详情页 URL(URL 里带 tid、pid/project_id、image_id),返回 HTML+CSS 设计规格、图片下载映射、设计 token 和一张预览截图。
如果用户还没给链接,先问用户要蓝湖设计详情页的完整 URL。
凭证处理:调用过程中如果返回 400、418 等状态码,几乎都是蓝湖登录凭证过期或失效导致的。这时不要反复重试或猜别的原因,直接提示用户更新蓝湖登录凭证(重新登录蓝湖 / 更新本地保存的登录态),等用户处理好再重试。因为没有有效凭证时任何还原动作都无从谈起,继续往下做只是浪费时间。
判断平台
解析完设计稿后,先确定它是移动端 H5 还是 PC / 桌面端——这决定后面两处分支怎么走。从 MCP 返回的画布宽度和布局特征通常能判断:
- 移动端 H5:竖屏、单列为主,画布宽度约 375 或 750。→ 走 H5 分支,必读
references/mobile-h5.md(识别真机外壳 + 移动端适配)。
- PC / 桌面端:宽屏、多列/栅格布局、依赖鼠标悬浮,画布宽度常见 1280 / 1440 / 1920。→ 走 PC 分支,必读
references/pc.md(不识别真机、不做移动适配,按设计布局还原)。
拿不准时,把你的判断依据讲给用户确认,别默默定。
样式方案
在动手写页面前先定下样式方案。先探明项目已经在用什么,复用现有规范,不要自作主张引入新体系:
-
看项目里已有的样式写法(现有组件、全局样式文件)。
-
看 package.json 的依赖(如 tailwindcss、sass、styled-components、css-modules、px-to-viewport 等)。
-
如果前两步都没找到任何可循的方案(既没有现成样式代码,package.json 里也没有样式相关依赖)——停下来问用户想用哪种,把预置方案列给他选(见 references/styling-presets.md),拿到答复再继续。不要自己默认挑一个就开写。
为什么这里必须停:样式方案是项目级的基础技术选型,一旦铺开就渗透进每个组件,后期几乎无法平滑更换。它不是"随便选一个都行"的小事,而是该由用户拍板的决定。为了赶进度替用户默默定了,看似高效,其实是把一个高代价的返工埋给了后面。这跟本 skill 其他地方"能自己判断就别打扰用户"的基调不冲突——恰恰因为这个决定代价高、不可逆,才值得为它停一次。
UI 框架方案
和样式方案一样,这是动手前要先定的项目级选型。指的是 UI 组件框架(移动端常见 Vant、NutUI、antd-mobile 等;PC 端常见 Ant Design、Element Plus、Arco 等):
- 先看项目是否已经在用某个 UI 框架:查
package.json 依赖,以及现有组件里的 import 和用法。
- 已经在用 → 就用它来还原。能用框架现成组件(按钮、弹窗、Tab、表单等)搭的就用,和项目其余部分保持一致,别自己从零手写一套平行的实现。
- 没有在用 → 停下来问用户:这个页面要不要用 UI 框架来还原? 如果要,还得让用户指明用哪个框架(不要自己替他选定);如果用户明确不用,就用原生元素 + 选定的样式方案手写。拿到答复再继续。
为什么这里也要停:引入 UI 框架是项目级决定——它带来一个长期依赖、影响包体积、并规定了组件的写法和视觉基调;反过来,项目本该用框架你却全手写,又会和团队预期脱节。用不用、用哪个,都该由用户拍板,理由同「样式方案」。
还原目标与平台分支
可交互(H5 / PC 通用)
不要把设计稿上的每个元素都当成静态图硬摆上去。设计稿只画了一个状态,真实页面是会被用户操作的。还原时主动思考:
- 列表、长内容 → 应该能滚动,而不是被裁切或撑破布局
- 按钮、链接、卡片 → 可点击,并有合理的按下 / hover / disabled 状态
- 输入框、搜索框 → 可聚焦、可输入
- Tab / 开关 / 折叠面板 / 下拉 → 可切换、可展开
- 设计稿里那些明显是"选中态""展开态"的元素 → 想清楚它的另一面(未选中/收起)长什么样
在区分服务端/客户端组件的框架里(如 Next.js App Router),带交互(事件、状态、副作用)的组件记得放在客户端组件里(如标注 "use client"),否则交互不会生效。
一句话:交付能用的组件,不是能看的图。
平台专属
- H5 → 见
references/mobile-h5.md:识别并跳过真机外壳(状态栏 / home indicator / 边框圆弧),并按 750 基准做移动端等比适配(Tailwind rem 根字号 / 其他走 px-to-viewport)。
- PC → 见
references/pc.md:不识别真机、不做移动端适配,按设计稿布局还原;注意内容区宽度策略(定宽居中 + 局部弹性)与真实鼠标 hover 交互。
图片资源与切图规范
用 MCP 返回的 image download mappings 来获取切图,把切图下载到项目的资源目录。不要自己截图裁剪,切图来源以设计稿导出为准。
命名按语义自己起,让名字贴合这张图在页面里的用途,而不是照搬导出的乱码/序号文件名。比如一个搜索图标叫 search-icon.png、一张 banner 底图叫 home-banner-bg.png、一个已完成状态的图标叫 tab-done.png。好的命名能让代码里的引用一眼看懂这是什么,后续维护和替换都方便。
装饰性、纯色块、简单形状能用 CSS 实现的,优先用 CSS(渐变、圆角、阴影等),不必都切图,能减小体积也更好维护。
组件设计规范
按前端组件设计原则拆分,别把整页(数据、子组件、样式)全塞进一个大文件:
- 单一职责:一个组件只做一件事(一个卡片、一个列表项、一个导航栏)。
- 高内聚低耦合:组件内部相关逻辑聚在一起,组件之间通过清晰的 props 通信,别相互伸手改对方状态。
- 高复用与可扩展:设计稿里重复出现的区块(列表项、标签、按钮样式)抽成可复用组件,通过 props 支持变体,方便后续扩展。
页面文件只负责"组装"(取数据、搭骨架、引用子组件),组件、静态数据、类型分文件存放,并沿用项目现有的目录与命名习惯。具体的拆分粒度、就近/共享目录约定和单页面结构示例见 references/component-structure.md。
自检清单
交付前回读一遍自己写的代码,按下面的信号逐条排查——这是代码级静态审查(找出会出问题的写法),不是运行时观察。下面是 H5 / PC 通用项,再按平台补上对应分支文档末尾的追加项(H5 见 references/mobile-h5.md,PC 见 references/pc.md):
