lanhu-to-code

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 ): 平台 :已确认稿子是 H5 还是 PC,并走了对应分支(H5 做了真机跳过+适配 / PC 跳过这两项) 可滚动 :长列表/长内容容器没有被写死高度而裁切,该滚的区域 overflow 处理正确(或走自然文档流) 可交互 :可点/可聚焦/可切换的元素用的是真正的 button / a /表单控件并绑了事件,有按下/hover/disabled 等状态;在区分服务端/客户端的框架里,带交互的组件放在了客户端组件(如标 "use client" ) 切图 :切图来自 MCP、命名语义化;能用 CSS 实现的(渐变/圆角/阴影)没多切图 组件 :重复区块抽成了组件,页面文件只做组装;静态常量(constants)与页面配置(config)已按需分离(动态数据不必强抽) UI 框架 :若确定使用 UI 框架,已优先用其现成组件(按钮/弹窗/Tab 等),没有重复手写平行实现 项目级选型 :项目原本没有样式方案或 UI 框架时,已停下来问过用户,而不是自己默认了一个