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