人机协同时代，AI助力90.4%双11前端模块自动生成

背景介绍

2017 年，一篇论文 pix2code: Generating Code from a Graphical User Interface Screenshot 引发业界关注，论文讲述了使用深度学习技术实现从一张 UI 截图识别生成 UI 结构描述，而后将 UI 结构描述转成 HTML 代码。有人认为这种从 UI 截图直接生成代码的意义不大，AI 和 Sketch 软件原本就是用数据结构保存设计文件的结构描述，不须要经过机器学习来获取，并且生成的代码不肯定性很大。也有一部分人对这个思路给予确定，提出让深度学习模型学习 UI 界面特征，还能够作 UI 智能设计。

随后基于 pix2code 开发的 Screenshot2Code 项目进入 Github 排行榜第一名，该工具可以自动将 UI 截图转成 HTML 代码，该项目做者号称 3 年后人工智能会完全改变前端开发，对此也有很多用户表示质疑，认为前端技术复杂框架各异，仅 HTML 代码没法知足需求。

2018 年，微软 AI Lab 开源了草图转代码工具 Sketch2Code**，**一些人认为生成代码效果不理想不适用于生产环境，但也有人认为代码自动生成还处于初级阶段，将来发展值得想象。

2019 年，阿里巴巴对外开放智能生成代码平台 imgcook，能够经过识别设计稿（Sketch/PSD/图片）智能生成 React、Vue、Flutter、小程序等不一样种类的代码，并在同年双 11 大促中自动生成了 79.34% 的前端代码，智能生成代码再也不只是一个线下实验产品，而是真正产生了价值。

每当这些新的自动生成代码产品发布，网络上总会出现“人工智能会不会取代前端”“一大批前端程序员要失业了”这些讨论。

那人工智能到底会不会取代前端？人工智能在将来很长的一段时间内不会取代前端，可是会改变前端。一是会改变在前端智能化方向的前端领域探索者，他们除了能够成为 Nodejs 服务端工程师，还能够成为机器学习工程师，为前端智能化领域创造更多的价值和成果；二是会改变享受前端智能化成果的前端开发者，改变他们的研发方式，例如代码智能生成、代码智能推荐、代码智能纠错、UI 自动化测试等能够帮助他们完成大量简单重复的工做，能够把更多的时间放在更有价值的事情上。

本篇文章将给你们分享做为前端智能化领域的探索者，咱们是如何看待人工智能在前端领域的将来发展方向，如何推动智能化能力在智能生成代码平台 imgcook 上的应用落地和迭代升级助力今年双 11 会场 90.4% 新模块的代码智能生成，编码效率提高 68% 的。

阶段性成果

imgcook（www.imgcook.com）官网首页平均每个月 PV 6519， 平均每个月 UV 3059。相比于 2019 年， 2020 年月平均 PV 和 UV 均是 2019 年的 2.5 倍。

imgcook 用户共有 18305 个，其中社区用户占比 77%，阿里集团内用户占比 23%。imgcook 模块共有 56406 个，其中外部模块占比 68%，内部模块占比 32%。相比 2019 年以前总量，2020 年用户增加 2.7 倍，模块增加 2.1 倍。

社区覆盖公司至少 150 家，集团内部覆盖 BU 10 个以上，双 11 会场新增模块覆盖度 90.4%，无人工辅助状况下智能生成的代码被保留发布上线的占比 79.26%，编码效率（模块复杂度和研发耗时比值）提高 68%。

与 2019 年相比，用户感官提效提高 14%；和彻底不使用 D2C 相比，固定人力单位时间模块需求吞吐量提高约 1.5 倍。与传统研发模式相比，使用 imgcook 研发链路编码效率可提高约 68%。

（Imgcook 研发效能数据概览）

技术产品体系升级

技术原理简介

咱们先来了解下 imgcook 智能生成代码的原理， imgcook 可以自动生成代码主要是作了两件事:  从视觉稿中识别信息，而后将这些信息表达成代码。

本质是经过设计工具插件从设计稿中提取 JSON 描述信息，经过规则系统、计算机视觉和机器学习等智能还原技术对 JSON 进行处理和转换，最终获得一个符合代码结构和代码语义的 JSON，再用一个 DSL 转换器，转换为前端代码。DSL 转换器就是一个 JS 函数，输入是一个JSON，输出就是咱们须要的代码。例如 React DSL 的输出就是符合 React 开发规范的 React 代码。

（D2C 智能生成代码使用动线）

其中核心部分在于 JSON to JSON 这部分。设计稿中只有图像、文本这些元信息，位置信息是绝对坐标，而且设计稿中的样式与 Web 页面中的样式表现存在差别，例如 sketch 中透明度 opacity 属性不会影响子节点，但在网页中 opacity 会影响子节点，而人工编写的代码具备各类布局类型、DOM 结构须要合理可维护、代码须要语义化、组件化、循环等信息。

如何能智能生成像人工编写这样的代码，这是智能还原这部分要解决的事情。咱们把 D2C 智能还原部分作了能力分层，每一层的输入和输出都是 JSON，智能还原部分的本质是一层一层的作 JSON 转换，这就是整个智能还原的流程。若是须要对生成的 JSON 作修改，能够经过 imgcook 编辑器可视化干预，最终经过 DSL 开放层将获得的符合代码结构和语义的 JSON 转换为代码。

（D2C 智能还原技术分层）

智能还原的核心链路构成了 D2C 的核心技术体系，并经过度量体系来衡量核心还原能力和研发提效效果。下层依托算法工程体系提供核心技术体系中智能化能力的底层服务，包括样本制造、算法工程服务、前端算法工程框架，上层经过 D2C 研发体系承接智能还原的后置链路，经过提供可视化干预能力知足用户二次迭代的需求，并经过将工程链路内置到 imgcook 平台实现一站式开发、调试、预览和发布来提高总体的工程效率。再加上支持自定义 DSL、自定义开发物料等扩展性很强的自定义能力造成的开放体系一块儿构成了整个 D2C 架构，服务于阿里内部 C 端、小程序、中后台等以及外部社区各类不一样的业务场景。

（D2C 技术架构图）

今年在前端智能化大背景下，对 D2C 技术体系全链路进行了智能化能力升级，并为前端同窗带来了让前端工程师能成为机器学习工程师的前端算法工程框架 Pipcook 和解决样本收集问题的样本制造机 Samplecook。同时带来了营销模块研发链路产品化升级，助力全链路研发提效。

智能化能力升级

智能化能力分层定义

《汽车驾驶自动化分级标准》基于驾驶自动化系统可以执行动态驾驶任务的程度，根据在执行动态驾驶任务中的角色分配以及有无设计运行条件限制，将驾驶自动化分红 0 至 5 级。在高级别的自动驾驶中，驾驶员的角色向乘客转变。这种明确的标准有助于各种企业更有针对性展开研发和技术部署的工做。

（自动驾驶分级标准）

参考自动驾驶分级标准，基于 D2C 系统可以自动生成代码的程度，根据编码的角色以及是否须要再人工干预和验证，咱们定义了一个 D2C 系统交付的分级标准，用来帮助咱们认识 D2C 系统当前所处的级别以及下一阶段的发展方向。 (D2C 系统交付分级参考标准)

目前 imgcook 的能力处于 D2C 的 L3 级别，智能生成的代码还须要可视化干预或人工兜底开发后验证上线。将来指望达到 L4 级别，咱们须要对 UI 信息架构进行拆解，对从 UI 信息自动生成代码的智能化能力进行细分。

（UI 信息架构拆解）

一个应用由多个页面组成，每一个页面中按 UI 颗粒度划分能够分为模块/区块、原子模块/区块、组件（业务组件、基础组件）、元件。每个颗粒度的 UI 咱们都须要识别到它的布局结构和语义，才能生成像人工编写同样模块化、组件化、语义化的可维护性较高的代码。

根据对 UI 信息架构的拆解，咱们结合 imgcook 生成代码的技术体系从不一样颗粒度对智能化能力进行分级 I0-I5（I 是 Intelligent 的首字母）。

（D2C 智能化能力分级）

其中涂色部分是目前已具有的能力，从这个维度来看 imgcook 的智能化能力目前处在 I3 和 I4 级别，并与 I2 级别的能力协同运做于生产环境。 I3 级别的智能化能力须要不断优化和迭代模型，当线上真实场景准确率达到 75% 以上或模型具有自我迭代能力则进入 I4 级别。若是达到了 I5 级别的智能化能力，根据 D2C 系统交付分级参考标准，D2C 系统交付分级能够从 L3 进入 L4， 生成的代码将不须要人工干预和验证便可直接上线。

固然咱们可能会长期处于 L4 级别这我的机协同编程的阶段，这种分级的定义是为了促进智能化落地的进程，能够指导 咱们提高 D2C 智能化能力，对 D2C 智能化有个更清晰的认识。

咱们以生成代码的可用度做为整体技术指标，并根据代码生成链路的技术分层给出各阶段的技术指标以及对代码可用率影响的权重，其中生成代码的理论准确度 = (各个环节准确度 * 权重)之和，而真实的代码可用率 = imgcook 生成的代码在最终上线的代码中留存的占比。 （各分层技术指标与权重定义）

D2C 的智能化能力分布在还原链路的各个阶段，咱们以提高代码可用率为目标，对全链路进行智能化能力升级，将技术方案细化到如何让各阶段模型识别准确率提高以及如何能将识别结果最终应用到智能还原链路生成代码，如何作到从样本收集、模型训练、模型部署到模型应用到工程链路整个流程可以自动化、自我迭代优化，不断优化和迭代模型能力。

智能化能力的应用还须要工程链路的支撑，例如模型识别结果的应用、线上用户行为召回、前端开发组件对 UI 组件识别结果的承接等，总体的 D2C 技术体系也须要同步升级。

（D2C 技术体系升级大图）

各阶段智能化能力升级

图层解析阶段

imgcook 经过解析设计稿图层信息，并经过规则系统、智能化技术等识别和生成代码，但因为设计域与研发域的表达方式、结构和规范等差别，设计稿的图层结构对生成代码的合理性影响较大，一些设计不规范的设计稿须要用 imgcook 的“成组”和“图片合并”协议对设计稿进行调整。

开发同窗在开发代码时也常常会有写多余的 console.log、没有注释、变量重复声明等代码不规范的问题，为了解决这些问题，提供了 ESLint、JSLint 等工具来保障代码规范的统一。

在设计域，咱们也一样能够开发一套设计稿规范智能检查工具来保障设计规范，智能审查设计稿的规范性，提示错误并辅助调整。咱们把这套工具称为 Design Lint（DLint），具体的实现方案能够关注后续的设计稿生成代码 imgcook 3.0 系列设计稿规范智能检查篇。

（设计规范检查）

物料识别阶段

UI 物料能够分为模块/区块、组件和元件，从 Sketch/PSD 中直接提取的信息只有文本、图片和位置信息，直接生成的代码都是由 div、img、span 组成，实际开发中组件化、代码语义化必不可少，如何从设计稿中提取组件和语义信息，这是 NLP、深度学习等智能化技术很是适合解决的问题。

去年咱们在组件识别、图片识别、文本识别这几个方向都有探索和实践，识别的结果最终用于语义化和字段绑定，但使用的技术方案对识别的效果限制较大，今年咱们作了以下改进：

组件识别 本来使用目标检测的方案来识别 UI 组件，但这种方案既须要识别出正确的组件类别还须要识别出正确的位置，以整个视觉图片做为输入，复杂的图片背景很容易被误识别，而且因为识别出的位置误差致使很难挂载到正确的节点上，模型识别结果在线上的应用准确率较低。

基于这些缘由，以及 imgcook 可以从视觉稿中获取每一个图层位置信息的优点，咱们将方案转换成了图片分类，并能将识别结果然正的应用到线上，这其中依托一套组件可配置、可识别、可渲染、可干预、可出码的智能物料体系。具体实现方案能够关注后续的设计稿生成代码 imgcook 3.0 系列组件识别篇。

（组件识别应用全链路）

如下是组件识别应用到线上的演示，识别视觉稿中的视频信息，并用 rax-video 前端组件承接生成组件粒度的代码，须要配置自定义的组件(组件库设置)、组件识别模型服务(模型服务设置)、支持渲染 video 组件的画布资源（编辑器配置-画布资源）以及应用组件识别结果的业务逻辑点（业务逻辑库配置）。

（组件识别全链路演示）

Icon 识别 Icon 识别实际上是一个图片分类的问题，依然沿用图片分类的方案，但为了可以让模型的泛化能力能自我加强，咱们设计了一个 Icon 自动收集、处理数据、自动训练模型、自动发布模型的模型闭环链路，让模型可以自我迭代优化。 （Icon 识别模型闭环链路）

自上线以来，新增训练集总数达到了 2729 个，平均每个月回捞有效数据 909 个, 模型通过几回自我迭代测试集的准确度从 80% 提高到了 83%。具体实现方案能够查看 物料识别篇之 Icon 识别模型闭环链路搭建。

图片/文本语义识别 在 imgcook 智能化系统中有一个很关键的部分，就是如何对 UI 界面内的元素绑定语义化信息，以前解决方法是基于图片和文本分类模型识别，该方法有很大的局限性：仅对文本进行分类，没有考虑与整个 UI 界面内的上下文语义，致使模型效果很差。

举个例子：$200，这个字段文本分类是没办法对其进行语义识别的，由于它放到不一样的场景中有着不一样的意思，如：活动价、原价、优惠劵...，正确的作法是考虑该字段与在 UI 界面的联系（即独特的样式）来对它进行语义分析。

所以，咱们引入了一种能结合 UI 中上下文语义的方案来进行语义识别，采用图片元素决策+文本分类两步走的方案解决界面元素语义化问题，具体流程是：先基于强化学习对界面元素按样式“过滤”一遍，识别出有样式的非纯文本字段，再对纯文本的字段进行文本分类。具体框架以下。

（强化学习 + 文本分类）

如下是模型算法训练结果，具体的探索和实践方案能够查看 物料识别篇之基于UI上下文语义的文本分析。 （基于上下文的语义分析）

布局还原阶段

布局便是代码中每一个节点与节点之间的关系，是父子关系仍是兄弟关系。从颗粒度大小上划分，能够分为页面间模块/区块以前的关系、模块/区块内原子模块/区块之间的关系以及原子模块/区块内组件、元件之间的关系。

目前 imgcook 已具有了循环识别与多态识别的能力，识别设计稿中的循环体生成循环代码，识别同一个节点有多种 UI 状态时生成多状态的 UI 代码，并定义了布局可维护度衡量方式来衡量还原阶段的准确度。具体技术方案能够关注后续的设计稿生成代码 imgcook 3.0 系列布局还原篇。 （布局还原阶段识别能力升级）

逻辑生成阶段

在业务逻辑生成阶段优化原有的配置链路，将业务逻辑库与算法工程链路解耦，并承接全部识别结果的应用和表达。物料识别阶段只关心 UI 中有什么物料，不关心识别的结果如何用于生成代码，布局还原阶段的循环识别和多态识别同理。这样作的好处是咱们能够自定义识别结果的表达，而且可让用户感知智能识别的结果并选择是否使用。

除了从业务逻辑库生成逻辑代码也能够从需求稿生成部分逻辑，或者来源于代码片断推荐，或者来源于代码智能推荐（ Code to Code，C2C）。关于业务逻辑生成阶段的实践和思考请关注后续的设计稿生成代码 imgcook 3.0 系列 业务逻辑生成篇。

（通用业务逻辑库配置）

算法工程体系升级

样本制造机

算法工程服务提供了 UI 特征识别的模型训练产品，为全部想使用业务组件识别的小伙伴打造一个玩弄机器学习的链路。为了解决使用算法工程服务的关键痛点，因此有了新的衍生产品：样本制造机，为前端 UI 识别的模型提供样本制造捷径。具体请关注后续的设计稿生成代码 imgcook 3.0 系列算法工程篇之样本制造机 Samplecook

前端算法工程框架

有不少同窗会以为，让前端同窗用机器学习技术去解决前端领域的问题，会不会难度很大。为了下降前端工程师使用机器学习的门槛，咱们开发了前端算法工程框架 Pipcook。前端工程师能够用熟悉的 JavaScript 来完成机器学习任务。

咱们能够这样理解 Pipcook， Node.js 的出现可让前端工程师成为一位服务端工程师，作服务端同窗能作的事情， Pipcook 的出现可让前端工程师成为一位机器学习工程师，能够作机器学习工程师作的事情。

关于 Pipcook 是如何用 Node.js 桥接机器学习生态以及目前 Pipcook 的应用状况请关注后续的设计稿生成代码 imgcook 3.0 系列算法工程篇以前端算法工程 Pipcook。

(前端与机器学习)

研发链路升级

模块研发链路

淘系营销以模块开发为主，模块开发的完整链路是从模块管理平台建立模块 ⇥ 进入 imgcook 平台智能生成代码&可视化研发 ⇥ 开发完成后进入 IDE 调试预览 ⇥ 测试完成后进入工程平台发布。整个研发流程须要切换多个平台，开发链路体验和工程效率都有待提高。

建立模块后进入 imgcook 平台智能生成代码&可视化研发，若是可以直接在 imgcook 平台开发、调试、预览和发布，一站式的 D2C 研发模式是提高总体研发效率和研发体验的一个不错的选择。

因此咱们自定义了具备可视化模式和源码模式的营销版本 imgcook 可视化编辑器，在可视化模式智能生成代码和可视化研发，并将生成的代码一键同步到源码模式的 WebIDE，在 WebIDE 中支持界面化的调试、预览、发布。

(淘系模块 imgcook 可视化研发动线)

咱们经过计算使用传统研发模式开发的模块与使用 imgcook 可视化研发模式开发的模块的效率值（复杂度与研发耗时比值）看到，使用 imgcook 可视化研发链路开发的模块编码效率提高 68%。

智能 UI 研发链路

智能 UI 是一种经过分析用户特征为用户提供个性化 UI 的方案，所以须要开发大量的 UI 界面，在淘系智能 UI 平台鲸幂中开发智能 UI 的原始链路是在上传视觉稿解析物料以后会批量建立 imgcook 模块，但每种物料都须要进入对应的 imgcook 可视化界面单独开发、建立仓库、单独发布，而且看不到智能 UI 总体的视觉效果。这样致使智能 UI 所须要的大量物料的开发成本很大，业务接入智能 UI 的成本比较大。

(智能 UI imgcook 可视化研发动线)

此次升级了智能 UI 的研发链路， D2C 可视化研发链路承接了智能 UI 的批量化生产。在上传设计稿解析出 UI 物料以后，建立 imgcook 模块，批量生成物料 UI 代码，同时建立代码仓库与 imgcook 模块关联，并支持将已建立的物料批量导入 imgcook，批量生成 UI 方案（不一样类型的 UI），在生成的 UI 方案中集中式对物料进行开发，最后还将支持物料的批量发布，整个链路集中高效了不少。

落地结果

今年前端智能化助力前端研发模式升级，数个 BU 共建前端设计稿识别算法模型和数据集，并于双 11 会场大规模应用落地。

设计稿生成代码技术体系全面升级（如对 UI 多态、直播视频组件、循环的智能识别加强等）带来了营销模块研发链路产品化升级：双十一会场有 90.4% （高于去年）新模块的代码智能生成。升级设计稿智能检查能力，在可统计范围内，无人工辅助的状况下智能生成的代码被保留发布上线的占比 79.26%。

相比传统模块开发模式，使用设计稿生成代码技术后编码效率（模块复杂度和研发耗时比值）提高68%，固定人力单位时间模块需求吞吐量增长约 1.5 倍。

目前还须要人工改动代码的主要缘由有：循环未被识别、条件展现逻辑代码未自动生成、字段绑定猜想错误（字段标准化状况不佳）、业务特性必须的图片合并问题等，这些问题也都是接下来须要逐步完善的。 （D2C 代码生成用户更改状况）

同时，imgcook 支撑了天猫淘宝的主会场和行业会场智能 UI 的批量化生产，极大的提高了智能 UI 的生产效率。 （智能 UI 批量化生产结果）

将来展望

智能化方式不管是使用计算机视觉仍是深度学习技术，都会有准确率的问题，准确率低在线上环境可能没法被接受。须要创建一套与线上用户使用数据造成闭环的算法工程链路，实现样本自动化收集、算法工程链路的闭环才能让模型线上识别准确率不断提高。目前在 imgcook 的系统中，Icon 识别从样本收集到模型识别结果的最终应用已经造成了完整的链路闭环，开发同窗不须要花太多精力用于模型的优化。对于其余的模型，后续也会用一样的思路让模型具备自我迭代的能力。

另外一个 D2C 智能化的难点是模型识别的结果最终如何用于生成代码，例如组件识别模型能识别组件的类别，但最终生成代码使用哪一个组件库的组件、如何识别 UI 中的组件属性值这些问题，imgcook 的平台能力与智能还原技术分层架构具有解决这些问题的能力，将来会有更多的智能化方案用于生产环境。

后续咱们会继续根据对 imgcook 的 D2C 智能化能力拆解，探索更多智能化解决方案，优化现有模型能力，创建算法工程闭环机制实现每个模型的自我迭代，不断提升模型的泛化能力和线上识别准确度，辅助生成可维护性更高语义更强的前端代码。

欢迎加入钉钉群与咱们一块儿交流，社区同窗 请钉钉扫码加入 社区群，阿里内部同窗 请加入 内部群。

系列文章预告

设计稿智能生成代码 掘金帐号

• 设计稿生成代码 Imgcook 3.0 系列-开篇
• 设计稿生成代码 Imgcook 3.0 系列-设计稿规范智能检查篇
• 设计稿生成代码 Imgcook 3.0 系列-组件识别篇
• 设计稿生成代码 Imgcook 3.0 系列-Icon识别篇
• 设计稿生成代码 Imgcook 3.0 系列-布局还原篇
• 设计稿生成代码 Imgcook 3.0 系列-字段语义分析篇
• 设计稿生成代码 Imgcook 3.0 系列-业务逻辑生成篇
• 设计稿生成代码 Imgcook 3.0 系列-算法工程篇（前端智能化与 Pipcook）
• 设计稿生成代码 Imgcook 3.0 系列-算法工程篇（样本制造机 Samplecook）
• 设计稿生成代码 Imgcook 3.0 系列-双11落地篇
• 设计稿生成代码 Imgcook 3.0 系列-双11落地篇之智能UI