作为阿里经济体前端委员会今年四大技术方向之一，提到前端智能化方向，难免有人好奇：前端能和AI结合什么？做，怎么做，以后前端会不会受到影响。大震撼等等。本文将围绕这些问题，以“设计稿自动生成代码”场景为例，从背景分析、竞品分析、问题拆解、技术解决方案等多个角度，阐述相关思考和过程实践。背景分析业界机器学习的趋势如火如荼，“AI是未来的共识”频频出现在各大媒体。简单、重复的任务更有可能受到人工智能的影响。此外，白领工作比蓝领工作更容易受到影响；因为蓝领工作可能需要在机器人技术和软硬件相关技术上有所突破才能实现，而白领工作一般只需要在软件技术上有所突破即可实现。那么AI会对前端“白领”工作产生什么样的影响呢？回首2010年，软件几乎“吞噬”了所有行业，为软件行业带来了近几年的繁荣；而到了2019年，软件开发行业本身又在被AI“吞噬”。你看：DBA领域出现了Question-to-SQL，针对某个领域提问可以生成SQL语句；基于机器学习的源码分析工具TabNine，辅助代码生成；P5Banner智能设计师也出现在设计师界“鲁班”，智能化在测试领域的结合同样精彩纷呈。前端领域呢？那我就不得不提一个大家再熟悉不过的场景。是从设计稿自动生成代码（Design2Code，以下简称D2C）。让AI帮助前端的职能角色提升效率和升级，淘汰简单重复的工作，让前端工程师专注于更具挑战性的工作内容！相关产品分析2017年，一篇Pix2Code关于图像转换的论文在业界Waves引发热议，关于如何直接从设计原型生成源代码。随后，社区中不断涌现基于这种思路的类似于Screenshot2Code的作品。2018年，微软AILab开源了草图转换工具Sketch2Code。同年年底，根据设计稿智能生成前端代码的新人洋太子也首次亮相。机器学习第一次不容小觑。手势正式进入了前端开发者的视野。基于以上分析，我们可以得到以下启示：目前深度学习在图片中的目标检测能力适用于大粒度的可复用素材识别（模块识别、基础组件识别、业务组件识别）。直接从图像生成代码的完整端到端模型非常复杂，生成代码的可用性不高。要实现生成代码的工业级可用性，需要更详细的分层拆解和多级子网络模型协调。D2C系统的构建可以通过设计稿生成代码来完成。当模型的识别能力达不到预期的准确率时，可以使用设计稿的人工规则约定；一方面，人工规则约定可以帮助用户进行干预以获得想要的结果，另一方面，这些人工规则约定实际上是高质量的样本标注，可以作为训练样本来优化识别精度该模型。问题分解设计稿生成代码的目的是让AI帮助前端功能角色提升效率和升级，剔除简单重复的工作内容。那么我们先来分析一下。“常规”前端，特别是面向C端业务的同学，大致的工作流程和日常工作内容大致如下：“常规”前端一般的开发工作量主要集中在视图代码上，逻辑代码和数据。联调（连数据接口开发，Serveless产品化开发都可以期待），接下来我们逐块拆解分析。查看代码查看代码开发，一般是根据可视化草稿编写HTML和CSS代码。如何提高效率，当面对UI视图开发的重复性工作时，很自然地想到包装和可复用材料的组件化、模块化等解决方案。基于这个解决方案，会沉淀出各种UI库，甚至可视化组装构建更高层次的产品包装，但可复用素材并不能解决所有的场景问题。个性化服务、个性化观点遍地开花。面对问题本身，直接生成可用的HTML和CSS代码是否可行？这是业界一直在不断尝试的命题。通过设计工具的开发插件可以导出图层的基本信息，但是这里的主要难点是对设计稿的要求高，生成的代码可维护性差。这就是核心问题了，我们继续拆解。★对设计稿要求高对设计稿要求高会增加设计师的成本，意味着前端的工作量转移给设计师，推广难度大。一种可行的方法是使用CV（ComputerVision，计算机视觉）结合导出图层信息的方式来去除设计稿的约束。当然，对设计稿的要求最好是直接导出一张图片，这样对设计师没有任何影响。需求也是我们梦想的解决方案。我们一直在尝试从静态图片中分离出合适的图层，但是目前在生产环境中的可用性不是很高（小目标识别精度问题，复杂的背景提取等问题正在解决中。），因为毕竟设计稿附带的元信息比图片提取和处理的元信息更加准确。★可维护性问题生成的代码结构普遍面临可维护性挑战：布局嵌套合理：包括绝对定位到相对定位、冗余节点删除、合理分组、循环判断等；元素适配：元素本身的可扩展性、元素之间的对齐关系、元素最大宽高容错；Semantics：Classname的多级语义；风格CSS表达：背景色、圆角、线条等可以通过CV等方法分析提取，尽量使用CSS表达风格代替图片的使用；……拆解这些问题后，它们将按类别和类别解决。解决办法看似无穷无尽，但幸运的是，目前发现的主要问题基本都解决了。很多人质疑，这部分能力的实现好像和智能没有什么关系，顶多是布局算法相关的专家规则测量系统。没错，这部分更适合现阶段的规则体系。对于用户来说，布局算法需要接近100%可用。另外，这里涉及的问题大多是无数属性值的组合。目前，使用规则更可控。如果你必须使用模型，那么这可以定义为一个多分类问题。同时，任何深度学习模型的应用都需要一个明确的问题定义过程，明确定义问题规则是一个必要的过程。但是，在规则求解起来比较麻烦的情况下，可以使用模型来辅助求解。比如合理分组（如下图）和循环项的判断。在实践中，我们发现各种情况下误判不断发生，算法规则难以枚举。这里需要跨元素的上下文语义识别，这就是接下来要用到的。该模型解决的关键问题。逻辑代码合理分组逻辑代码开发主要包括数据绑定、动态效果、业务逻辑代码编写。能提高效率的部分，一般在于动态效果和业务逻辑代码的复用，可以沉淀基础组件、业务组件等。接口字段绑定：从可行性分析，还是很高的。可以根据视觉稿的文字或者图片判断属于哪个候选字段，但是性价比不高，因为接口数据字段绑定太商业化，不通用。动效：这部分开发的输入是交互式草稿，一般动效的传递形式多种多样，有的是动画gif演示，有的是文字说明，有的是听写；动效代码的生成更适合以可视化的形式生成，直接智能生成没有参考依据，短期内不考虑投入产出比。业务逻辑：这部分开发的基础主要是PRD，甚至是PD口授的逻辑；如果要智能生成这部分逻辑代码，缺失的输入太多，需要看智能在这个子领域能解决什么问题。★关于逻辑代码生成的思考理想的解决方案当然是能够像诗歌、绘画、音乐等其他艺术领域一样学习历史数据。根据PRD文本输入，可以直接生成新的逻辑代码，但是生成的代码能不能直接运行不报错呢？?虽然目前人工智能发展迅速，但它能解决的问题还是有限的，需要把问题定义为它擅长解决的问题类型。强化学习擅长策略优化问题。深度学习目前擅长解决计算机视觉中的分类问题和目标检测问题。擅长文本方面的NLP（NaturalLanguageProcessing，自然语言处理）。关于业务逻辑代码，首先想到的是利用LSTM（LongShort-TermMemory，长短期记忆网络）和NLP对历史源码的功能块进行上下文分析，所以对于获取代码功能块的语义，VSCode智能代码提醒和TabNine是类似的思路。另外，在分析问题中（如下图所示），我们还发现在业务逻辑领域，智能还可以辅助识别逻辑点在视图中的位置（时序），猜测逻辑语义基于视图。综上所述，我们总结一下对现阶段智能化有帮助的几点：从历史源码分析来猜测频繁出现的功能块（逻辑块）的语义，实际得到的是组件库或基础的语义功能块，可以在代码中找到编辑时进行代码块推荐的能力。从视觉稿中猜出一些可复用的逻辑点，比如这里的字段绑定逻辑，这里可以根据文本语义NLP猜出字段，还有一些图片元素在限定范围内根据图片进行分类，猜出对应的图片字段（如下例中，氛围修饰图片仍然是Logo图片）；同时，它还可以识别可重用的业务逻辑组件，比如这里的优惠券收集逻辑。所以在这个阶段的业务逻辑生成中，能够解决的问题比较有限，尤其是出现新的业务逻辑点，新的逻辑编排时，这些参考都在PD的PRD或者脑子里。因此，对于业务逻辑生成方案，目前的策略主要有：字段绑定：智能识别设计稿中文字和图片的语义分类，尤其是文字部分。可复用的业务逻辑点：基于视图的智能识别，视图驱动的自由组装，包括小而美的逻辑点（一行表达，或者几行代码一般不足以封装成组件）、基础组件和业务组件。无法复用的新业务逻辑：结构化（可视化）收集PRD需求，难度较大，还在尝试中。总结目前智??能化自动生成HTML+CSS+部分JS+部分DATA的主要分析如上，是DesigntoCode的主要流程。内部项目名称称为D2C。该缩写将在后续系列文章中使用。团内外的落地产品名称为imgcook。随着近年来主流设计工具（Sketch、PS、XD等）的三方插件开发能力的逐渐成熟，深度学习的迅猛发展甚至有超越人类认知的趋势。这些都是D2C诞生和不断进化的坚强后盾。目标检测的2014-2019论文技术计划是基于上述对前端智能发展的总体分析。我们对现有D2C智能技术体系的能力做了一个概述，主要分为以下三个部分：识别能力：即识别识别能力。智能分析设计稿中包含的层、基础组件、业务组件、布局、语义、数据字段、业务逻辑等多维信息。如果智能识别不准确，则通过视觉人工干预进行补充和纠正。一方面是为低成本的视觉干预生成高可用的代码。另一方面，这些干预后的数据被标记为样本，反馈并提高智能识别的准确性。表达能力：主要针对项目部分的数据输出和访问。通过DSL适配，可以将标准的结构化描述作为Schema2Code使用。通过IDE插件能力，项目接入算法工程：为了更好的支持D2C所需的智能化能力，高频能力的高服务化，主要包括数据生成和处理，模型服务部分样本生成：主要处理样本数据来自各种渠道并生成样本模型服务：主要提供模型API封装服务和数据回流前端智能D2C能力汇总分层在整个解决方案中，我们使用同一套数据协议规范（D2CSchema）来连接能力每一层保证标识可以映射到对应的字段，在表达阶段通过编码引擎等方案可以正确生成代码。在整个D2C项目中，智能识别技术分层是上述识别能力中机器智能识别部分的核心。该层的具体细分如下。后续系列文章将围绕这些细分层展开内部实现原理。素材识别层：主要通过图像识别能力（模块识别、原子模块识别、基础组件识别、业务组件识别）识别图像中的素材。图层处理图层：主要对设计稿或图像中的图层进行分离处理，结合上一层的识别结果，组织图层元素信息。LayerReprocessinglayer：进一步归一化layerprocessinglayer的图层数据。布局算法层：将2D中的绝对定位层布局转换为相对定位和弹性布局。语义层：利用层的多维特征，在生成代码端对层进行语义表达。字段绑定层：将层中的静态数据与数据接口结合起来，做接口动态数据字段绑定映射。业务逻辑层：通过业务逻辑标识和表达，为配置好的业务逻辑生成业务逻辑代码协议。代码输出引擎层：最后输出经过每一层智能处理后的代码协议，通过表达能力（protocol-to-codeengine）输出各种DSL代码。D2C识别技术痛点分层技术当然，识别不全、识别准确率低一直是D2C中的老生常谈，也是我们的核心技术痛点。我们尝试从这几个角度来分析造成这个问题的因素：识别问题定义不准确：问题定义不准确是影响模型识别不准确的首要因素。很多人认为样本和模型是主要因素，但在此之前，一开始的问题定义可能有问题。我们需要判断我们的身份申诉模型是否合适，如果合适，如何定义清楚其中的规则。缺乏高质量的数据集样本：我们在识别层的每台机器的智能识别能力需要依赖不同的样本，那么我们的样本能覆盖多少前端开发场景，每个场景的样本数据质量如何，数据标准是否统一，特点工程过程是否统一，样本是否存在歧义，互操作性如何，这些都是我们现在面临的问题。模型召回率和误判率低：我们往往会积累很多不同场景下不同类型的样本作为训练样本，期望用一个模型来解决所有的识别问题，但这往往会导致模型的部分分类召回率低，会出现误判对于一些模棱两可的分类。★问题定义深度学习中的计算机视觉模型目前比较适合解决分类问题和目标检测问题。我们判断一个识别问题是否应该使用深度模型的前提是我们是否能够判断和理解自己。是否存在歧义等等，如果人们不能准确判断，那么这个识别问题可能就不合适了。如果判断适合深度学习的分类，那么还需要继续明确所有的分类。这些分类需要严格、排他且完全可枚举。比如在做图像语义的命题时，一般图像的ClassName有哪些常用的、约定俗成的名称？例如，分析过程如下：第一步：尽可能多地找到相关的设计稿，并一一列举里面的图片类型。第二步：图像类型的合理归纳和分类。这是争议最大的地方。定义不佳和歧义会导致大多数模型精度问题。Step3：分析每一类图片的特征，这些特征是否典型，是否是核心特征点，因为这关系到后续模型的推理泛化能力。第四步：每类图片是否有数据样本源，如果没有，能否自动创建；如果没有数据样本，那么不适合使用模型，可以使用算法规则，而不是先看效果。在D2C项目中，这样的问题很多。问题本身的定义需要非常精确，需要有科学依据。这本身就很难，因为没有先例可以借鉴，只能用已知的经验去尝试。是测试出现问题后需要不断迭代、不断改进的痛点。★样本质量对于样本问题，我们需要建立这部分数据集的标准和规范，构建不同场景下的多维数据集，对收集到的数据进行统一处理和提供，期望建立一个标准化的数据系统。在本系统中，我们使用统一的样本数据存储格式，针对不同的问题（分类、目标检测）提供统一的样本评估工具，对每个数据集的质量进行评估。对于一些特定的模型，可以采用更好的结果。采用特征工程（归一化、边缘放大等）来处理，类似问题的样本也有望在后续的不同模型中流通，用于对比评估不同模型的准确率和效率。数据样本工程系统★模型针对模型的召回和误判问题，我们尝试对场景进行收敛，以提高准确率。不同场景下的样本往往在特征上存在一些相似性或者影响分类的一些局部关键特征点，导致误判和召回率低。我们期望能够通过场景融合来做模式识别，提高模型的准确率。我们将场景汇聚为以下三个场景：无线C端营销渠道场景、小程序场景、PC中后台场景。这里几个场景的设计模式各有特色。为每个场景设计垂直识别模型，可以有效提高单个场景的识别准确率。D2C场景流程思考由于使用了深度模型，一个更现实的问题是模型的泛化能力不够，识别准确率不能100%满足用户，只能对批量无法识别的进行处理后续不断补充。除了样本数据，在这之前我们还能做些什么呢？在D2C的整个还原环节中，对于识别模型，我们也遵循一个方法论，即设计一套协议或规则，以其他方式覆盖深度模型的识别效果。保证用户在模型识别不准确的情况下仍然可以完成请求：人工约定>规则策略>机器学习>深度模型。比如需要在设计稿中识别一个循环体：前期我们可以在设计稿中手动约定循环体的协议，实现一些基于层上下文信息的规则判断，判断循环体是否使用了机器学习的层特征，可以尝试优化规则策略的上游策略，生成一些循环体的正负样本，通过深度模型进行学习。人工约定的设计稿协议在解析时优先级最高，也能保证后续流程不被堵塞，不被误判。商务落地2019双十一落地在今年的双十一场景中，我们的D2C涵盖了天猫淘宝会场的新模块，包括主会场、行业会场、营销赛会场、榜单会场等，包括查看码和自动一些逻辑代码的生成，D2C代码生成在统计范围内占了很大比例。目前手动修改代码的主要原因有：新增业务逻辑、动画、字段绑定猜错（字段标准化不好）、循环猜错、样式自适应修改等，这些问题也需要逐步解决以后改进。D2C代码生成及用户变更整体实现我们的外部产品imgcook，截至2019.11.09，相关使用数据如下：模块数量12681个，每周新增约540个；用户数4315人，每周新增约150人；DSL：共109个；目前可提供的服务能力如下：设计稿全链路还原：通过Sketch、PhotoShop插件一键导出设计稿图层，生成自定义DSL代码。图片链接还原：支持用户自定义上传图片、文件或填写图片链接，直接还原生成自定义DSL代码。后续计划将继续降低设计稿要求，力争设计稿0协议，其中智能识别分组和流转的准确率将得到提升，视觉稿协议的人工干预成本将降低减少。组件识别准确率提升，目前准确率仅为72%，业务应用可用性低。页面级和项目级恢复能力可用性的提升依赖于页面切分能力准确性的提升。提升了小程序、中后台等领域的页面级还原能力，包括复杂表格、表格、图表的整体还原能力。静态图片生成代码链接的易用性得到提升，真正可以在生产环境中使用。算法工程产品完备，样本生成渠道更加多样，样本集更加丰富。D2C功能是开源的。未来，我们希望通过前端智能D2C项目，让前端智能技术解决方案具有包容性，积累更多有竞争力的样本和模型，提供更高准确率和可用性的代码智能生成服务；有效提升前端研发效率，减少简单重复性工作，不加班少加班，一起专注于更具挑战性的工作！
