现在 H5 页面已经基本可以实现直接把设计稿喂给 LLM，毕竟这种小活动页面都是用完就扔，没有后期成本诸如代码维护之类。而且小 H5 还有个特点就是逻辑简单，总共下来就那么几个接口，稍微复杂高端一些的可能要来个列表、加个筛选什么的，其余基本都是 UI 级别的逻辑，复杂度都是在常数上做文章，拿 AI 搞非常合适。
而且 LLM 读完设计稿非常喜欢用 rem 这种单位，对移动端那些网页而言再合适不过。
关于 MCP
不久前我在公司内部 Wiki 里面做过一期关于 MCP 的案例分享，说实话我个人觉得 MCP 来个读设计稿的，再来个读接口文档的，基本 H5 这块业务全流程就能跑起来了；至于页面和端之间打通的这部分逻辑直接照抄老代码即可。H5 活动频繁的都是几天一个，换汤不换药，逢年过节更是量产，这种情况下再加上 LLM 抄作业能力极强，所以很多桥接代码很可能自己都没察觉到，就被 AI 偷摸拿过来抄作业复用了。到头来其实都是大家你抄我我抄他，屎山越堆越高的同时也没人有异议，毕竟这玩意谁写谁知道，真的有种大脑平滑的美，超级爽。
年前这段时间抽空研究了下 MCP，这个东西相对 Skills 和 Rules 而言总算是有点用了，后面两个看两眼就觉得扯淡。而且作为一名伟大的前端，我很高兴地发现主流 MCP 服务竟然都是前端技术实现，果然传说中的前端入侵地球计划是真实存在的，宇宙就是个巨大的前端！！！
设计稿还原
目前来看有一些可以帮助咱们快速还原设计稿的 MCP，本质都是从 Figma 那里拿数据过来。
现在主流 MCP 市场里这方面热度比较高的有俩，一个是 Framelink 开发的，另一个是个叫做 Cursor Talk To Figma MCP。其实后面这个用起来简直吊打前面好几条街，但奈何它名字里带个 Cursor，导致给人一种只能在 Cursor 里面用的错觉。Framelink 是本地直接通过 Figma 侧的个人 Token 去向官方 API 请求设计稿数据，比较慢而且有速率限制，但 Talk To Figma 就没有这个顾虑，因为它是直接在本地起一个 WebSocket 服务当中间人，左手从本地 Figma 拿数据，然后右手递给 MCP 客户端，数据完全走本地。
维度 | Framelink Figma | Talk To Figma |
|---|---|---|
MCP 类型 | stdio | stdio |
包管理器 | npm | bun |
工作方式 | 通过 Figma API 向 Figma 服务器请求设计稿代码 | 通过本地 Websocket 服务器与本地 Figma 应用内插件配合获取本地设计稿代码 |
本地准备 | ① 将 Figma API 令牌复制到 mcp.json ② 使用 IDE 启动 MCP 服务器 | ① 手动下载 Websocket 服务端 ② 本地执行 bun socket 启动服务端 ③ 在 Figma 应用中使用插件加入 Channel ④ 使用 IDE 启动 MCP 服务器 |
远程准备 | 在 Figma 个人设置中生成令牌 | 无 |
响应速度 | 一般 | 快速 |
请求限制 | 受 Figma API 个人调用速率限制 | 无 |
支持的方法 | download-figma-images（下载 Figma 设计稿内部图片） get-figma-data（获取设计稿源代码） | 好多 |
资源下载 | 支持（经常超时） | 不支持 |
反向操作 | 不支持 | 支持 |
指定选区 | 不支持 | 支持 |
总结 | 功能较少 限制较多 运行方便 | 部署复杂 功能全面 响应快速 |
项目地址 |
而且很多人在尝试让 AI 还原需求的时候其实都有个问题，就是一次性让 LLM 完成太多任务。
实际上将需求拆解为代码层面的各个工作环节是 VibeCoding 的一个重要部分。对于前端而言，通常来讲可大致分为下面几个环节：
| 环节 | 描述 | 类型 | 上下文 | 进度 |
|---|---|---|---|---|
| 拆分页面 | 确定本次需求涉及的所有页面及其层次结构，同时大致确定是否要用到组件。 | 人工 | 项目级 | |
| 设计稿获取 | 抽取目标页面设计稿至一个独立 Team 的独立页面。 独立 Team 是因为研发人员可能没有 Figma Dev 权限，所以无法 Figma 插件——这个很重要； 独立页面是因为在此页面中可以解锁当前设计稿的所有复杂功能，且减少加载时间。 | 人工 | 样式级 | |
| 物料下载 | 因为现有 MCP 不支持直接从设计稿源文件获取其中的图片等资源，故需要手动在 Figma 中将其导出为相关格式，并保存至项目的资源文件夹中。 | 人工 | 样式级 | |
| 页面生成 | 运行 MCP 服务，通过长 Prompt 或预设的 Command 执行设计稿 MCP 能力，获取设计稿并初步铺设页面，并绘制页面样式。 注意：该阶段不应实现交互逻辑。 | AI | 新建 | 样式级 |
| 路由添加 | 将生成的页面及其路径注册到项目现有的路由表文件中。 | AI | 保持 | 样式级 |
| 冒烟构建 | 启动项目本地开发服务器，检查页面效果，包括 ： ① 路由能否正常进入 ② 页面骨架能否正常显示 ③ 页面布局是否初步正常渲染 ④ 页面主要元素位置是否正常。 | 人工 | 样式级 | |
| 一轮反馈 | 将构建检查中发现的问题在同一个上下文中反馈给模型，并有序、分点地为之列出修改建议。 | 人工 | 保持 | 样式级 |
| 循环优化 | 重复执行构建并找出问题，然后给出反馈，并适当分离出新的上下文，避免上下文过长导致模型降智。 | AI | 新建 | 样式级 |
| 逻辑引入 | 根据当前页面需求，为 AI 提出引入交互逻辑的任务，包括点击事件、元素显隐、数据校验等，将这些任务以列表形式告知 AI。 | 人工 | 新建 | 交互级 |
| 循环优化 | 重复执行构建并找出问题，然后给出反馈，并适当分离出新的上下文，避免上下文过长导致模型降智。 | AI | 保持 | 交互级 |
| 接口引入 | 读取接口文档，为 AI 下达创建接口请求方法的任务，在项目接口代码文件中生成相关内容。 | AI | 新建 | 项目级 |
| 接口逻辑 | 分别单独为每个页面下达与接口逻辑相关的任务。每个页面的上下文都应当独立。 | AI | 新建 | 接口级 |
| 最终优化 | 综合串联所有之前创建的页面，执行构建并查找细致问题，反馈给 AI 并令其修复，直至项目代码能够彻底满足需求。 | AI | 新建 | 项目级 |
设计原则
我个人感觉活动 H5 这种页面底下的代码是最糙的，毕竟都是赶工作品。
对于布局而言，通常来讲由于都是移动端尺寸，所以所有页面的容器元素直接设一个固定 14 ~ 16 rem 这种高度即可，然后直接给 relative，这样里面所有元素都无脑用 rem 做绝对定位，产出效率极高。如果不是老手的话，也可以用常规定位挨个往下排队铺，但说实话这种傻 der H5 千万不要太过重视或者认真，绝对定位熟练用起来真的乱杀。
另外就是移动端两个 OS 兼容性这方面，安卓拉起输入法可能页面不会往上弹，iOS 就不会，还有图片长按保存的一些逻辑也有区别，但有端侧 JS 做桥接的话，这些应该都做好封装了。
然后就是优化方面，尽量别整什么 SVG，有条件全都 PNG；尺寸除了背景图等一些明确有清晰度要求的物料，其它都压缩到 480 以内。图片预载不用吭哧吭哧去写代码，直接在上一个页面放下一个页面的大图然后做 srOnly 即可。页间沟通还是老一套 SessionStorage。调试的话全局搞个环境判断，测试环境初始化个 vConsole 就差不多了。
