设计稿智能生成代码实践总结

自我介绍

大家好，我是来自阿里淘系技术部的妙净，2010 年毕业加入淘宝前端，曾负责过淘宝前端无线基础库、淘宝无线性能优化体系、淘宝营销搭建体系，现负责淘宝导购和天猫品牌营销前端团队，负责前端智能生成代码平台 imgcook，今天给大家介绍下 imgcook。

imgcook 对外是开放使用的，访问 imgcook.com 即可。

今天关于智能生成代码的分享大纲如下：

imgcook 背景

起源

先看一下 imgcook 的背景起源，我们是阿里电商的主战场，前台产品形态各种各样，据不完全统计，光搭建类模块的年新增量 1w 以上，年页面增量 100w 以上（这里包含大量的营销活动）。能复用的尽量走搭建复用，大量因业务性质特殊难复用，这 1w 多个模块和各种 C 端强心智产品页面还是需要前端开发。

发展历程

巨大的业务压力下，2017 年从当时的淘宝前端团队诞生出通过设计稿直接生成可维护的前端代码工具达芬奇（ imgcook），后来逐步优化，为了减少对设计稿的约束规范，逐步引入 CV、NLP 解决图层识别问题和语义化问题，后来 2019 年 1 月正式对外开放 imgcook。

之后继续优化还原效果，并扩展到生成逻辑代码，同时增强平台扩展能力，发展成 imgcook 2.0；目前正在进行 imgcook 3.0 的规划和实现，主要是解决基于 NLP 对 PRD (需求文档的理解)增强生成， 辅助业务逻辑代码和部分服务端业务逻辑代码的生成。生成的产物从视图代码、数据字段绑定、也扩展到业务逻辑代码。目前从平台上记录的模块开发耗费时间降低约 40% 左右，同时结合内外用户调研加权平均之后，整体前端研发提效约 40% 左右。

前端行业提效分析

前端研发提效，这是一个老生常谈同时又是一个历久弥新的话题，前端框架、前端工程化、可视化搭建等领域解决都是各种维度提效的问题。

从最开始的 proCode、LowCode、noCode、到 hpaPaas (高生产力应用程序平台) 平台，一方面通过复用物料、可视化配置、全链路在线研发部署等手段、综合提升研发效率问题，另一方面通过赋能其他角色（运营、PD ）转移生产关系来释放前端人力。

对于 imgcook 定义的 AUTOCODE 来说，它是基于设计稿或未来的 PRD 直接生成代码，但由于设计稿识别等准确度问题，所以也融合了 lowcode 的可视化能力来进行干预，可视化修改成本比较低，同时修改后的结果可以用于模型的自迭代；但由于一些复杂的业务逻辑，有些可视化强制搭建出来比写代码的成本还要搞，这也是 lowcode 不强制 nocode 的原因，所以我们也融合了 procode 的优势，将生成的可维护代码可以进行二次迭代，最终可以应用到不同复杂度场景的业务中。这里我们主要的提效策略是 AUTOCODE 一键生成代码，极致提效，可视化搭建在链路中更多为了做准确度干预修正和模型迭代。

智能化相关行业提效分析

这里智能化一键生成代码带来的前端研发效率提升是最直接的，智能化对其他行业的影响也是非常大。

比如近几年提出的以智能化为背景的工业 4.0，工业 4.0 的核心策略抓手大概有制造过程智能化、可视化、标准化管理协作、跨领域上下有集成整合，以达到高效生产；类比到前端行业一样，依赖的底层设施正在云化并逐步标准化（数据标准化、服务标准化等）、前端工程化成熟、跨 PD /设计师/服务端的协作研发一体化、业务个性化定制生产可视化智能化，这些策略在前端行业也都存在。

再来看智能化带来的成果，其领头羊项目厦门远海全自动化智能码头，一线人员减少 70%，效率提升 20%；
被誉为行业之母的金融行业，其典型的智能银行网点，其操作类柜台人员占比下降 15%；操作类柜台人员转型后的复合型人才提升至 90%；新增 超级柜台机、自助购汇机、虚拟柜员机 之后，减网点面积、减柜员 进一步减少成本。

总的汇总来看，各个行业智能化之后，会提效降本，某类人员会减少，某类人员会转型升级，并带来质量的提升或业务增量。

所以类比到前端行业智能化几年之后，整体会大大提效，一部分简单重复性工作会被智能化所取代，也可能会诞生一些新的职位，如业务逻辑配置师（和代码生成机器人协作）之类的，前端升级做更有挑战性的工作内容。

imgcook 介绍

接下来给大家介绍下 imgcook

目标

imgcook 的目标是从（设计稿、原型稿、PRD、APIHub、CodeHub 等资源）通过智能化的手段直接生成代码。

目前持续优化设计稿到代码的准确度，能生成所有视图代码（html+css）、数据字段的猜测绑定、以及智能识别部分高复用的逻辑点；剩下无法覆盖的是大量个性化业务逻辑，目前在通过结构化 PRD 文档 来补充业务逻辑代码的生成，包括生成服务端业务逻辑代码，所以目前依赖的资源从设计稿前置到 PRD。我们的终极目标就是从（设计稿、原型稿、PRD、APIHub、CodeHub 等资源）智能生成更多的更准确的代码，成为 codeRobot。

核心功能

imgcook 的 目前对外的核心功能是 从设计稿 通过 CV/NLP 等深度学习、传统机器学习、专家规则系统、算法工程 等综合手段直接生成代码。

产品使用动线

具体来看看目前的产品使用动线，导入设计稿后可以一键生成代码，可以所见所得地在可视化编辑器中进行干预编辑，然后可以生成各种 DSL（React/Vue/Rax/小程序DSL等） 的代码，然后代码可以通过 VS Code 插件、imgcook-cli 等直接引入到自己的项目工程中，每个团队项目可能有自己的工程目录规范，通过 Plugin 扩展也支持自定义，imgcook 的团队高级自定义能力支持各个维度的自定义能力，以满足不同场景的生成代码需求。

步骤一：导入设计稿

步骤二：可视化干预

步骤三：查看生成代码（可选）

步骤四：进工程链路（vs code 插件直接导入）

可选步骤：团队高级自定义

高频定制功能：

总结下，目前的产品能力大图是这样的：

目前的使用情况如下：

• 可用率 = 通过 imgcook 直接生成的代码被 gitlab 最后发上线最后被保留的代码 / 发上线的所有代码。

技术架构

imgcook 的技术架构如下：

从下到上分别是基于算法工程框架和产品，基于视觉稿 CV 分析 和 NLP 分析，多维度识别要生成代码的要素，识别后可视化呈现出来，如果识别出错就进行可视化干预，并可视化补充额外逻辑，然后应用集成到各自的工程链路（VSCode 插件、WebIDE插件、imgcook-cli）中。生成的代码也支持自定义，最常用的是 DSL（React/vue/小程序 DSL…）和 Plugin（不同的团队有不同的目录规范等）自定义。同时整个技术体系我们最关注的的是技术方面的度量指标，如代码真实可用率、模型准确度和提效数据等。

核心技术难点

接下来我们来看看这张技术大图里面，实现复杂度比较高的部分：

智能识别表达拆解

首先是这里智能识别表达的拆解问题，直接端到端目前的业界的可用解决方案目前还没有，业界也有类似 pix2code screenshot2code 的方案，一个是颗粒度太大，适合解决组件识别的问题，一个是可用度不高，尤其对于 C 端的视觉稿还原度，C 端设计师是不接受像素级偏差的。

具体我们来看看怎么拆解成可解的问题，从直观上分析，为了生成表达所需要代码，需要多维度的信息输入和提取，需要各种详尽的元信息（图像、文本、样式、属性等），同时需要提取出不同颗粒度的可复用的单元（物料），以及抽取背后的动态逻辑（动态字段、循环、交互逻辑等）。

那技术上面具体怎么分层实现，首先从上到下，先将设计稿中输入，进行图层信息处理，各层具体如下：

• 图层处理层：主要将设计稿或者图像中图层进行分离处理，并结合上一层的识别结果，整理好图层元信息。
• 物料识别层：主要通过图像识别能力识别图像中的物料（模块识别、原子模块识别、基础组件识别、业务组件识别）。
• 图层再加工层：对图层处理层的图层数据做进一步的规范化处理。
• 布局算法层：转换二维中的绝对定位图层布局为相对定位和 Flex 布局。
• 语义化层：通过图层的多维特征对图层在生成代码端做语义化表达。
• 字段绑定层：对图层里的静态数据结合数据接口做接口动态数据字段绑定映射。
• 业务逻辑层：对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议。
• 可视化编排：最后输出经过各层智能化处理好的代码协议，用可视化引擎所见所得呈现处理，可以进行可视化干预和补充。
• 出码引擎层：最后经过人工干预后的更准确的协议内部，经过表达能力（协议转代码的引擎）输出各种 DSL 代码。
• 工程链路层： 最后通过 vs code 插件、webIDE 插件， 输出各个工程项目环境中。

UI信息架构识别

上述中最复杂的是 物料识别层，涉及到 UI 的整体信息架构，按照前端传统处理方式，一般直观经验也是 应用项目 包含 多个页面，页面分为多个区块，区块内部再拆分成原子区块，区块中可能包含业务组件，也可能包含可复用的基础组件，组件也是由不可再拆分的元件组成。这些对于有前端行业背景的大脑直观上是非常容易处理的，但对于机器来讲理解这些不太容易，直接端到端推测得到结果目前复杂度比较高，而且尤其对对于业务组件每个业务域的定义完全不一样。所以目前我们的策略是从整个项目从大到小、由外到内一层层拆分；多模型进行协作，单模型负责识别某一类特征；这里的业务组件模型是开放出来的，由各个业务域定义自己的业务组件识别能力。

下面以落地的 聚划算 页面为例，先用页面分割模型将页面拆分成从上到下多个区块（Block），中间第二个 Block 比较复杂，继续用分组模型进行拆分，识别成可循环的单元；然后继续识别区块中是否有业务组件和基础组件，比如第一个是 Slider ，第三个是 Tabbar , 第四个是 BottomBar。

基础组件识别-目标检测模型

Tabbar 在 C 端业务中是非常常见的基础组件，下面就以此为例，介绍一下基础组件识别的模型是怎么做的。

• 问题定义：问题的定义是最关键的一步，首先基础组件识别是一个目标检测问题，然后需要定义清楚要检测的目标有哪些，哪些是核心特征，这样才能为后面正样本负样本的制作提供依据。
• 样本生成：前端域相关定向造样本的成本还是比较低，有各种截图 mock 等方式可以生成，但容易造成样本不够丰富和均衡，需要结合模型效果不断调整。必要时候需要收集更多真实场景的样本进行标注，目前我们样本存储格式统一为 Pascal VOC。
• 建模：业界做目标检测的模型很多，SSD YoLo 等，但大部分模型都是真对实物特征的检测，如检测 花、猫、狗等，前端的组件识别更多侧重轮廓特征的检测，经过各种模型的测试，最终 Detectron2 的效果是其中目前最好的，mAp 75% 左右，目前持续优化中。
• 训练预测：Detectron2 是比较大的模型，目前是独立在 GPU 服务器上进行训练并预测的。

以下是实际在 imgcook 识别后的效果：

逻辑点问题分析

接下来讲一讲逻辑点智能识别和生成的问题，首先从拿到一个设计稿最直观的来分析这背后可能隐藏的业务逻辑是什么，依次可以看出有循环逻辑、图片白底图逻辑、大概率是什么字段逻辑、还可以看出可能有优惠券领取逻辑……说明很多逻辑可能是可以识别出来，并且这些小的逻辑点是业务域的领域背景经验息息相关的。

上面的业务逻辑是从感官上分析，这么多的逻辑怎么来统一梳理呢，接下来从技术上来进行分析，深入前端的业务逻辑分析，先引入有限状态机的理念来建模分析，一般包含几个要素，页面 什么条件时机（事件时机）下、做什么动作（动作）、从什么状态（现态）变为另外一种状态（次态）。对应到数据驱动的前端领域可以映射为，现态和次态都可以用数据 state 来表达，数据变化驱动 UI 的变化，触发事件（生命周期、事件、定时任务等）产生动作（Action、OP/operation）进一步又改变数据，数据驱动 UI 变化。这样整个所有前端的业务逻辑都可以囊括进来，这里核心就三个要素：一个是触发时机，一个是触发动作，一个是数据绑定，这里把数据绑定当成一种特殊的 OP。

所以归纳完后，我们用这 2 个要素就可以表达所有的业务逻辑了，深度学习这里在识别领域是非常擅长的，这里的一个个逻辑点就可以用不同的识别手段来进行了，毕竟模型的准确度没法保证 100%，在真实的业务落地中，还引入了更多的规则识别器来辅助识别，比如正则和自定义函数识别器，这样业务中的整个逻辑点的识别和表达通过逻辑点智能组装了。其相对传统的业务组件的封装拥有更细颗粒度、同时根据业务需求智能组装。

最后这套逻辑点的识别表达能力，我们沉淀为一套产品化的能力，每个业务都可以自定义自己逻辑库，然后自动应用到自己业务开发中。整个链路从新建逻辑分类、样本生产、模型训练、到上线部署都是产品化可直接完成的，不需要有深度学习门槛背景。由于模型训练部署服务器资源开销比较大，目前仅对内提供相应的服务。

总结

imgcook 会继续聚焦在前端智能研发域，我们期望 AI 进一步赋能前端研发提效，目前我们除了设计稿生产代码（Design2Code），目前正在做的是 PRD2Code 、和针对服务端数据服务的 Service 理解做 Service2Code, 以进一步生成覆盖更多的前端代码和部分服务端逻辑代码的智能生成。

同时前端智能化大背景下，我们在前端端智能域 也会进一步尝试，目前在图像感知和用户实时意图推测的应用比较多。同时为了前端智能化的更好的普及，让更多的前端参与进来，我们和 google tfjs 团队合作开源了前端算法工程框架 pipcook ，为前端提供机器学习相关的 qiangzhi 弹药，也让前端进入机器学习领域更低门槛，同时逐步完善打通 javascript 生态和机器学习生态，目前国内外有机器学习背景的前端比较少，但有机器学习背景会 javascript 的还是有的，期望更多的前端同学关注前端智能化方向，一起加入进来~~

前端智能化是阿里经济体委员会的四大方向之一，我们是一个虚拟 team，淘系 D2C 智能团队是核心团队之一，我们是一支用诗人的浪漫和科学家的严谨打造最懂 AI 的 smart and international 的前端团队，欢迎加入我们，一起定义并创造新的未来。