我要投稿

淘宝交易前端AI生码技术的创新实践

发布日期：2025-08-08 17:46:14 浏览次数： 1511

作者：大淘宝技术

微信搜一搜，关注“大淘宝技术”

本文介绍了交易前端AI生码技术的创新实践，聚焦于 D2C（Design to Code） 与 MCP（Model Context Protocol） 的结合应用。文章首先分析了现有D2C工具在处理复杂设计稿时面临的布局依赖、单位不统一、流程繁琐等问题。为解决这些痛点，作者提出了一套基于MCP协议的新方案：

利用WeaveFox 的视觉布局能力 生成IR中间码，避免对设计稿图层结构的强依赖；
引入设计规范与DSL召回机制，提升颜色、字号、字重等样式的准确性；
开发专属D2C插件，直接从设计稿获取750px标准尺寸图像，确保尺寸精准；
通过MCP工具链统一管理流程，实现“一键生成，多场景适配，拓展性强”的高效开发体验。

最终目标是打造一个更智能、更轻量、更贴近研发实际需求的AI生码流程，显著提升前端开发效率。

序言

D2C

Design to Code 是一种通过设计稿（Done、PSD、Master GO、Sketch等）生成代码（html、css）的技术，理想的状态下，前端工程师可以靠它从繁杂的设计稿UI实现中解放出来，更多精力可以投入到其它对业务更重要项目中。

MCP

MCP 是一个开放协议，它为应用程序向 LLM 提供上下文的方式进行了标准化。你可以将 MCP 想象成 AI 应用程序的 USB 接口。就像 USB 为设备连接各种外设和配件提供了标准化的方式一样，MCP 为 AI 模型连接各种数据源和工具提供了标准化的接口。

业界现状

集团内已经有许多的优秀的D2C工具：达拉然、OneDay、imgCook、ImageCook、WeaveFox等。我们直接上难度，拿出交易业务中较为复杂的一张实战设计稿来让他们做一个对比。

在对比中，我们统一选择容器 2084作为标准，这个容器可以同时包括顶部换一换模块与下面商品模块：

为什么说这个设计稿复杂，我们将第二个编组6隐藏后，图层底部还是有一部分污染信息的，可以通过视频查看：

这就是研发同学日常面对的设计稿现状，可以看到，在整个容器范围内，其实是有两个按钮和价格图层的，如果去约束设计老师这种行为，是几乎不可行的，就像推动所有的研发开发规范格式一样，每个人多多少少会有自己的风格。因此，这种设计稿会给下面的优秀的D2C工具带来很大挑战：

	生成结果	CSS	节点	流程
达拉然		1. 依赖positon布局 2. 依赖align-self布局，影响前端开发布局效率	1.可以区分出大致组件	1. 设计稿选中图层生成代码 2. 跳转到了新网页，在新网页对话修正、预览（链路长） 3. 需要手动复制每一个生成的文件代码到前端项目中（耗时）
OneDay		1. 生成单位为px，不是手淘自适应缩放单位rpx 2. 生成了两个重复内容 3. 生成代码依赖z-index，生码后难以维护	1. 节点文案数据未提前预置成变量，后续开发还是需要每个节点去修改	1. 设计稿选中图层生成代码 2. 跳转到了新网页，预览（链路长） 3. 需要手动复制每一个生成的文件代码到前端项目中（耗时）
imgCook		1. 依赖positon布局 2. 依赖align- self布局，影响前端开发布局效率 3. 不是手淘自适应缩放单位rpx	1. 无法过滤设计稿无效图层，导致节点重复	1. 设计稿选中图层生成代码 2. 跳转到了新网页，预览（链路长） 3. 需要手动复制每一个生成的文件代码到前端项目中（耗时）
WeaveFox		1. css样式布局全靠视觉，但又无法十分精确，且颜色错误 2. 字体加粗无法识别 3. 元素宽度不正确（按钮、图） 4. 设计稿截图，导致整个图片容器宽度不固定 5. 不是手淘自适应缩放单位rpx	1. 节点组件排布较为合理	1. 设计稿截图 2. 到wave平台上传 3. 平台切组件 4. 需要手动复制每一个生成的文件代码到前端项目中（耗时）

在整个对比过程中，对于复杂设计稿和整个流程，主要问题可以总结为以下几点：

代码生成

依赖position、align-self、z-index布局，所生成的代码，对前端布局难以维护
无法支持手淘rpx单位（达拉然除外）
对于设计稿图层极度依赖，对无效图层信息无法排除（WeaveFox除外）

流程

都需要到另外一个平台预览代码，整体链路加长
想要把代码迁移到原工程，就需要一个个文件手动复制，并且生成过程中无法识别工程内容

本文目标

在交易研发周期的编码环节，交易前端D2C工具作为交易前端MCP流程的最基础最核心的重要部分，致力于减少研发操作路径，让更多人愿意使用AI提效，以更轻松的方式生成更准确的代码。

原理概述

▐ 1.架构大图

交易前端MCP的D2C流程，主要包含D2C插件和交易终端MCP工具两个区域的操作：

1.1 交易D2C插件

用户选择图层后，即可生成IR中间码（后续会提到），用户可以选择生成的组件类型，组件名称、组件生成位置等，一键复制该组件生成信息：

1.2 交易终端MCP

来到Aone IDE的交易终端MCP中，直接粘贴，回车发送，喝杯茶，组件就生成好了！

▐ 2.IR中间码

从上面集团中的D2C工具的对比中可以发现，WeaveFox具有良好的布局能力，其不依赖图层的优势，可以规避掉很多由于图层信息导致生码的准确性下降的问题：

前端大模型 IR 标准能够完备渲染任意平台 UI，是基于认知理解的最小单元。实现能够直接向下兼容或通过组合方式兼容 AntD/AntV/小程序/蚂蚁Cube/WebComponent 等流行技术栈和组件。它描述了组件的父子结构、属性以及样式。

但是，其由于视觉检测的特性，对于一些组件的宽度无法精确切割出来，如这个image切割的大小，明显是多切了白边的，这个问题会在后面的核心难点上会讲到：

▐ 3.组件生成模版

组件生成模版是在交易MCP中设置的一种Resource资源，用于指导Agent生成什么样的组件规范，基于此规范我们可以约束大模型在生成组件时，与我们日常开发组件保持一致，并且且易于调试：

▐ 4.设计规范优化

我们发现，WeaveFox是依赖视觉检测的，它无法识别精确的颜色、字重、字号等信息，导致WeaveFox的IR中，颜色基本都是错的，需要人工再去修改，但是我们又不得不依赖WeaveFox的优秀布局去生码。

基于上述问题，我们开创性的想到可以引入设计规范去解决这个问题，将设计规范提供给大模型，让大模型进行纠正，此外，我们同时将常见边距、字重、字号、圆角等信息都提供给了大模型：

规范前	规范后

可以看到，在规范后，常见边距、字号、圆角都有了极大的改善，再也不用担心颜色错误了。

▐ 5.设计稿DSL召回修复

即使通过上述方式，我们也是无法保障一些元素的宽高、字重和字号与设计稿真实信息完全一模一样，设计规范的引入只是帮助AI进行邻近匹配，但是对于本来就错误很严重的字重信息和难以了解原设计稿的宽高信息，矫正能力还差些意思。

我们在流程设计上，选择获取设计稿的原始信息，来进行召回修复，提取设计稿的元信息，在这个基础上进行样式修复：

这样，可以保障在召回修复后，拥有更正确元素的样式（间距待优化）：

原图	无召回	有召回

第二次	第三次	第四次

可以看到，这种形式对于字重的修复和元素宽高的修复，是有显著效果的。

▐ 6.MCP工具统一流程

上述粘贴之后的流程，由交易MCP工具统一管理，严格按照步骤生成组件：

核心难点

▐ 1.上传图片来源，怎么样才能准确750px？

750px在单位由大模型转为rpx后，即可变为手淘规范750rpx，所以我们可以拿750px的图片去生成IR信息。WeaveFox上传的IR信息，是和上传的图片像素1:1生成的，如果我们想要生成750px宽度容器的图片，就必须将上传的图片就精准限制在750px。

最简单的方式是用户手动截屏，让用户手动截屏的方式，心智负担也比较重，几px的偏差就会导致最后生成代码中，元素的宽度高度不准确，最终导致用户需要重新调整代码。

1.1 镜师妹

在镜师妹（一种D2C方案，其主要包含D2Code、D2Component和自动对焦3个部分，开发者可以视自身情况选择图生源码或图生低代码组件的方案）中，也提到了这个问题，在不同的电脑上截屏，最后生成的图片大小也是不一样的。

镜师妹选择让用户进行缩放比例的方式去解决这个问题，但是如果让用户去手动缩放，用户的心智负担也会比较重，并且镜师妹针对的业务是在低代码平台做的，和我们交易业务非低代码场景不适用。

1.2 从设计稿复制

设计稿的复制功能，再去钉钉粘贴下载，最后去OneDay图片缩放插件进行缩放，这样获得的图片可以解决手动截图导致的边框问题，但是还是需要我们进行缩放，整体链路太长。

1.3 缩放移动到MCP工具中

在MCP工作流中，大模型会计算缩放的比例，将所有样式按照750rpx的比例进行缩放：

让大模型帮忙进行缩放是一个不错的选择，但是无法规避AI具有的幻觉：

1.4 交易D2C插件

为了彻底解决这个问题，我们想从设计稿拿到750px的图片，直接进行上传，这是我们选择开发一个设计稿插件的原因之一。在我们开发的插件中通过插件API获取的图层，刚好就是设计同学提供的尺寸，不存在图片缩放问题。

整个过程用户只有两步操作：1. 选择图层 2. 点击生成IR，在插件内部做的事情如下图，至此，我们对上传至WeaveFox链路的问题彻底解决：

▐ 2.设计稿DSL大小的优化

我们前面提到，WeaveFox优秀的布局识别能力，在生成的组件布局上整体没有什么问题，但是具体的样式，我们需要优化，我们提到的引入设计规范和设计稿DSL召回的解决方案中，设计稿的DSL体积太大，直接超过最大tokens了，直接阻塞了MCP的运行，所以立即决定对设计稿信息进行压缩。

这是本文测试图片的原始DSL：

2.1 DSL压缩器：从冗余到精简的数据转换示例

2.1.1 冗余信息多：包含大量的矩阵变换、定位信息、样式类等

原始DSL中的冗余信息示例：

{  "type": "LAYER",  "isRoot": false,  "id": "227:23720",  "children": ["227:23721", "227:23722"],  "layerType": "GROUP",  "isMask": false,  "isVisible": true,  "name": "组 2099",  "componentName": "Group29",  "layout": {    "matrix": [      [1, 0, 32],    // 复杂的矩阵变换信息      [0, 1, 40]    ],    "overflow": "VISIBLE",    // 溢出处理信息    "relatedLayout": {      "type": "ABSOLUTE",      "bound": {        "left": {"type": "PIXEL", "value": 32},        "top": {"type": "PIXEL", "value": 40}      },      "renderBound": {    // 渲染边界信息（重复）        "left": {"type": "PIXEL", "value": 196},        "top": {"type": "PIXEL", "value": 100}      }    },    "width": {"type": "PIXEL", "value": 164},    "renderWidth": {"type": "PIXEL", "value": 164},  // 重复的宽度信息    "height": {"type": "PIXEL", "value": 60},    "renderHeight": {"type": "PIXEL", "value": 60}   // 重复的高度信息  },  "style": {    "id": "style-class-227:23720",    // 样式ID    "type": "VIEW",    "classList": [],                   // 样式类列表（通常为空）    "attributes": {},                  // 属性（通常为空）    "tag": "DIV",                     // HTML标签信息    "styleTokenAlias": {},            // Token别名（空对象）    "value": {},                      // 样式值（空对象）    "layoutStyles": {      "position": "absolute",      "top": "40px",      "left": "32px",      "width": "164px",      "height": "60px"    },    "subSelectors": [],              // 子选择器（通常为空）    "name": "group-29"  },  "relatedFile": "file-539:39271"    // 关联文件信息}

压缩后的精简信息：

{  "id": "227:23720",  "name": "组 2099",  "type": "VIEW",  "styles": {    "width": "164px",      // 只保留核心尺寸    "height": "60px"  },  "isContainer": true,     // 标记为容器  "children": ["227:23721", "227:23722"]  // 保留子节点引用}

压缩效果：从50+行复杂信息压缩到10行核心信息

2.1.2 嵌套复杂：layout、style、relatedLayout等多层嵌套结构

原始DSL的复杂嵌套示例：

{  "layout": {    "width": {      "type": "PIXEL",      "value": 164    },    "renderWidth": {      "type": "PIXEL",       "value": 164    },    "height": {      "type": "PIXEL",      "value": 60    },    "renderHeight": {      "type": "PIXEL",      "value": 60    },    "relatedLayout": {      "type": "ABSOLUTE",      "bound": {        "left": {          "type": "PIXEL",          "value": 32        },        "top": {          "type": "PIXEL",           "value": 40        }      },      "renderBound": {        "left": {          "type": "PIXEL",          "value": 196        },        "top": {          "type": "PIXEL",          "value": 100        }      }    }  },  "style": {    "layoutStyles": {      "position": "absolute",      "top": "40px",      "left": "32px",       "width": "164px",      "height": "60px"    },    "value": {      "border-radius": "8px",      "background": "var(--token-color-9)"    },    "styleTokenAlias": {      "backgroundTokenId": "8:04977"    }  }}

压缩后的扁平化结构：

{  "styles": {    "width": "164px",     // 直接提取最终值    "height": "60px"      // 无需多层嵌套  }}

简化效果：

消除了 layout.width.type 和 layout.width.value 的嵌套
消除了 relatedLayout.bound.left.type 和 relatedLayout.bound.left.value 的深层嵌套
直接输出最终可用的CSS值

2.1.3 Token引用：使用styleTokenAlias引用颜色token

原始DSL中的Token引用示例：

{  "style": {    "styleTokenAlias": {      "backgroundTokenId": "8:04977"    // Token ID引用    },    "value": {      "background": "var(--token-color-9)"  // CSS变量引用    }  }}

配合Token定义表：

{  "localStyleMap": {    "8:04977": {      "type": "color",      "name": "--token-color-9",       "value": "rgba(255, 98, 0, 1)"   // 实际颜色值    }  }}

压缩器的Token解析处理：

{  "styles": {    "backgroundColor": "var(--token-color-9)"  // 保留变量引用  },  "resolvedColors": {    "backgroundColor": "rgba(255, 98, 0, 1)"   // 同时提供解析后的实际值  }}

Token处理的好处：

保留了设计系统的Token引用（利于维护&溯源）
同时提供了解析后的实际颜色值（利于代码生成）
避免了复杂的ID映射查找过程

2.1.4 图片布局依赖：IMAGE节点存在CALC类型的尺寸依赖父级容器

原始DSL中的CALC布局依赖示例：

{  "nodeMap": {    "49:19696": {      "id": "49:19696",      "name": "位图",      "layerType": "FRAME",      "children": ["49:22439"],      "style": {        "type": "VIEW"      },      "layout": {        "width": {          "type": "PIXEL",          "value": 200        },        "height": {          "type": "PIXEL",          "value": 200        }      }    },    "49:22439": {      "id": "49:22439",      "name": "图片",      "layerType": "RECTANGLE",      "style": {        "type": "IMAGE",        "attributes": {          "src": {            "value": "https://example.com/image.png"          }        }      },      "layout": {        "width": {          "type": "CALC",          "value": "100% - -7.5% - 0%"        },        "height": {          "type": "CALC",          "value": "100% - -2% - -5.5%"        }      }    }  },  "localStyleMap": {}}

压缩器的解析处理：

{    "id": "49:22439",    "name": "图片",    "type": "IMAGE",    "styles": {        "width": "200px",        "height": "200px",        "borderRadius": "8px"    },    "imageSrc": "https://mgdone.alibaba-inc.com/mastergo-default/132212543935111/156944519558876/861bd52bbe206fa807b5a4819537b5e6.png"}

CALC布局简化的解析处理流程：

父级查找：在已创建的容器节点中查找父级
简化解析：如果父级存在且有具体尺寸，直接使用父级尺寸

压缩优势：

消除计算复杂性：从复杂的百分比公式转换为简单的像素值，直接使用
减少依赖链：避免了运行时的父级尺寸查找和计算
提升AI理解：直接的像素值比CALC公式更容易被AI模型理解

2.2 压缩效果

原始大小: 174363 字符, 压缩后: 9740 字符, 压缩率: 94.4%。

压缩后的DSL：（675行）

这样，我们就可以顺利在MCP工具中，将IR信息+DSL信息同步输入给大模型，而不被tokens限制！

应用效果

下面是在交易各业务的近期需求中生成的效果：

	设计稿	生成后
SKU
Newbuy
支付成功
订单
订单搜索
购物车
逆向

优缺点分析

本文的生成链路已能够完成从代码生成到修复的完整流程。在整个过程中，存在诸多优点和不足之处：

▐ 优点

用户操作链路最为简化

通过对集团内各种D2C工具的体验对比，本文所述链路是目前实现从设计稿到IDE工程代码转换中，用户操作最为简单的一条路径。
实现WeaveFox链路的精准切图

充分利用设计稿中切图的优势，有效避免了WeaveFox链路中截图上传像素不准确的风险。
基于MCP工具的可扩展

后续可接入埋点、JS tracker、TMQ真机测试截屏返回等功能。在交易MCP工具的整体规划中，这是串联全链路流程的重要组成部分，前置的技术方案输入、后置的埋点平台、JS tracker、TMQ真机验证等，都可作为插件在MCP工作流中灵活使用。
有效规避设计稿脏数据图层

针对前文提到的设计稿脏数据问题（更贴近实战场景），本文的D2C流程充分利用WeaveFox的视觉优势，能够构建更准确的DOM布局信息。
设计稿DSL压缩优化，提取前端关键信息

从设计稿中可提取丰富信息，对于矫正链路而言，图片和文字的样式信息恰好补齐了WeaveFox相关识别的能力缺失，形成良好互补。
具有普适性

所有业务场景均可接入（DX、Weex、H5），不存在单业务环境类型强绑定。

▐ 缺点

边距识别准确性有待提升

基于WeaveFox的布局与设计稿精确布局仍存在差异。在实际测试过程中，设计稿DSL的布局特征可信度有限，而WeaveFox通过视觉完成的边距与真实设计稿总会存在部分偏差，导致目前尚未找到完美解决布局问题的有效方案。
图片产出不稳定

WeaveFox有时候没有检测到图片，导致无法生成图片对应节点，后续DSL召回链路无法感知补充图片。
AI生成效果的稳定性需要改进

MCP工具涉及的文档和流程较为复杂，AI有时会产生幻觉。幻觉的出现可能导致某些流程检测点失效，进而影响生成代码的质量。

总结

本文围绕交易业务中设计稿代码生成的复杂问题，提出了一套完整的解决方案。核心思路可以分为三个部分：

技术整合与优化

将WeaveFox的视觉布局能力与设计规范结合，解决了传统工具依赖position、z-index、align-self布局导致的代码不可维护问题。通过设计系统校准颜色、字重等细节，弥补了AI视觉识别的不足。
针对设计稿图层污染的问题，开发了DSL召回修复机制，确保最终生成的代码能准确还原设计意图。

流程简化与效率提升

通过设计稿插件与MCP工具的集成，将原本需要跨平台操作、手动复制代码的流程，压缩为“选图层-生成IR-粘贴到IDE”三步操作。
使用DSL压缩技术，将设计稿数据体积减少约90%，有效规避大模型输入限制，提升了生成效率和稳定性。

多端适配与扩展性

生成的代码符合手淘rpx自适应规范，兼容DX、Weex、H5等多种业务场景。
配合MCP工具流链预留了埋点、真机测试等扩展接口，为后续设计稿-开发-测试的全流程自动化提供了基础。

虽然当前在边距精度和AI稳定性上仍有改进空间，但该方案已显著降低了开发对设计稿的处理成本。未来通过优化DSL修复能力、支持业务定制组件能力，有望进一步缩短从设计到代码的交付周期。

团队介绍

本文作者喜语，来自淘天集团-交易终端技术团队。本团队负责手淘 App 交易链路业务研发与基础能力建设。面向亿级 DAU 核心业务，我们以稳定、性能与体验为第一原则，深耕原生 Native、跨端渲染引擎与前端 Web 技术，结合「新奥创」端到端方案，驱动业务高效迭代与快速交付。团队自研 JSTracker 数据监控平台，打造可观测、可优化的交易基础设施；同时前瞻布局 AI，探索 AI Native 应用与 AI 编码实践，将智能融入研发全流程，为用户提供极致、可靠的购物体验。2026 秋季校园招聘火热进行中，前端&客户端简历投递：LF101548@alibaba-inc.com。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法