阿里巴巴高级前端技术专家甄子带来“《前端智能化实践》——逻辑代码生成”为题的演讲。前端智能领域到底该如何落地人工智能技术呢？本文从UICode到LogicCode有多远开始谈起，接着从页面结构和数据结构的视角分析，进而讲述了开发者赋予的自定义能力，最后对前端智能化的未来进行了展望。
到了机器学习时代，我们能做的事情非常多，业务压力也非常大，那么，如何提效把我们从日常重复性劳动中释放出来，让我们有机会尝试更多新技术，并用新技术改变业务？我们的初衷是想要通过机器学习提效，通过机器视觉+机器学习来理解设计稿，将设计稿转成代码，避免做一些人工的事情。我们希望能够替代UI开发，能够替代部分动效和逻辑开发。
我们到底做的怎么样呢？
当我们真正涉及业务中如何识别设计稿，正确识别设计稿中UI元素并保证很高的还原度，尤其是后期如何在日常工作中做到工业级可用的技术水平。我们主要将模型精度及工程链路上工程工具的成熟度做了大幅度的提升，借助在阿里的天然优势，每年在618、99大促、双十一、双十二等节日都有技术大考，如何在大规模的业务诉求上，使用我们的技术真正做到提效？
UICode到LogicCode有多远？
如何做逻辑代码生成？这源于BERT模型，它特别像翻译的过程，比如我们基于技术对各种各样的语言进行语义化的分析和理解，最后通过语义关系的抽象形成的模式可以把任何一种语言翻译成目标语言，那么，这个过程是如何做到的？
语言都是由词、句、段、节、章、文、书组成，整个过程相当于把复杂的事情变得简单化，把里面存在的元信息抽取出来，然后对这些元数据信息，如果机器学习是一个皇冠，NLP就是皇冠上的宝石，NLP从搜索开始就对互联网产生非常大的价值，但是用户真正在keyword中输入的词并不一定是他们真实想要表达的诉求，后来的搜索引擎、问答系统、个人助理都会用到自然语言技术，比如空间上比较典型的W2V，我们会把抽出来的元信息看作一个个vector，vector之间有很多的算法（如余弦相似度），可以探索用户真实诉求；还有语义化，我们定义的控件是一个link，这个link可以代表一个点击跳转的链接地址，但真正在日常工程中实现的是基于URL路由的trigger作用，这时我们就要对link标签在上下文中的语义做理解，才能对link对当前DSL语义做准确判断；以及时间维度，比如当下语境说的事情和另外一个语境说的事情在语言表达上可能没有区别，但是因为所处语境不同，表达含义也可能不同。
我们首先要对控件进行语义化，控件到底是怎样组成基础组件的？在基础组件里，控件本身的语义以及控件所处的组件中context上下文语境是什么，紧接着是通过基础组件之间的关系怎么满足业务诉求将它们组合在一起，然后是将业务组件以模块化页面形式组合在一起，其中包括将元信息根据上下文信息以它本身语义做理解，在理解的前提下，我们才能知道应该如何去表达。
那么，这个过程就会变成通过设计稿、交互稿、线框图、需求文档的描述进行理解，再到生成逻辑代码的过程，它与以往的搭建和低代码开发是两个概念，以往的搭建和低代码开发是预先设定好能够实现的能力或功能是什么，然后以组件或控件模块形式组装好，让业务人员使用这些组件或者模块，但其中会有很多问题，比如业务人员是否具备程序员的软件工程思想，如果不具备，那么理解的成本会很高。我们希望未来可以变成相互之间解耦的事情，在需求理解方面可以独立做需求理解，当输入设计稿、需求文档、线框图、交互稿后，只需要知道产品或业务真实诉求是什么，在生成代码时，参考功能，从软件工程角度做过往的前端代码语义分析，最后知道怎么组织API和数据，用javascript等语言特性将它们组织在一起，然后生成这些功能和逻辑代码。
我们现在做的从识别到表达的解决方案整个过程如图所示，在识别部分，UI及UI上的文本、后续对需求的结构化收集和线框图、交互稿的信息收集进行识别，识别之后需要有一个理解的过程，这个理解就像将一个语言翻译成另外一个语言一样，我们识别出背后的模式，模式可以在任何语言中进行复用，未来的表达就是解耦生成的过程，只要用语言的特性去组织代码即可。
如图即是我们权益表达的一个模块，以软件工程视角看待此模块时，最开始为最上面左边第一个模块的样子，repeat两次变成视觉稿展示的形式，最后实现模块代码时，就不会把该模块写三遍，而是写一遍并在布局时repeat两次。紧接着可以看到，在一个模块中包含权益，即到底可以从优惠券的交互操作上得到什么，背后代表一些限制条件和发放规则，加购的文案背后代表的是要实现一个加购的逻辑，我们希望有一些品牌的透出，所以要展示一些品牌的logo，我们不会把这个logo写死，但是当一个产品或业务去思考这个问题时，他们一般不会考虑将logo写成动态去取的过程。还有进店，店名不仅仅是一个文案显示一个店名，更多的业务和产品的诉求希望能够通过优惠券产生一个进店的引导。将模块内部的元素全部都梳理出来之后，我们就能抽象出来整个逻辑，包括店名/进店、品牌/进品牌号、权益/条件、文案/加购、主视觉/主色调、背景/氛围，这些都会映射到表达的过程中，可能变成子业务数据、业务数据、权益组件、基础样式、业务样式等。
页面结构和数据结构的视角
大家可以看到，左边是一排N的模块，中间是横向&纵向循环，我们怎样识别出哪些是row哪些是column，通过对设计稿和需求的语义化理解后就会知道哪些控件适配于哪些组件的，比如几个人在场景中转，到底哪些像素属于头，哪些像素属于身体，哪些像素属于胳膊，这就是语义化的分割，怎么能够将相同语义的元素聚合到一起，通过聚合到一起的元素找出哪些是非重复的元数据。
通过元数据再到以往生成的scheme，找出到底组件上的数据scheme是什么，再把scheme上的数据绑定到类名、图片字段、文本字段上去，这其中涉及到如何做数据节点的识别、数据类型规则、文案检验和节点类型修正，通过准确的语义化，加上过往的scheme和UI控件属性之间的关系，能够做到自动进行数据字段的绑定。
如图是我们抽象出来的一些逻辑点，当我们做到数据字段的绑定后，会发现日常整个的开发工作里还有大量的重复代码工作，比如上报一些数据、处理页面初始化时配置的读取、配置的下发以及当节点销毁后，页面元素发生变化后需要做的一些事情，这些事情确实会有一些个性化的地方，但是个性化往往来源于对于输入参数的生成及对于输出数据如何去应用，这部分代码一般来说都是抽象的，都可以以一种模式提取出来，我们给它取名为逻辑点，对页面上的很多代码能够抽象成同一种模式或统一代码块的称为逻辑点，在这些逻辑点上把输入输出做语义化识别后得到字段属性，通过测量知道输入参数是什么，这样，我们就可以做到把平时常用且需要大量人工参与的开发变成通过识别到表达的方式，通过逻辑布局和属性的识别等，调用相应的逻辑点进行表达，这样的代码都是通过imgcook平台的语义识别和自然语言理解自动生成的。
因为我们背后的表达能力，我们生成依据的必要输入包括通用的语义流程、布局样式权重、图片分类、iconfont模型、w3c语义分类、文本分类、业务模型分类、配置策略等，我们发现，当我们去实现后续的逻辑字段绑定、代码生成的过程时，我们能够梳理出到底语义化给我们理解到什么程度，需要从设计稿、交互稿、需求文档中收集的信息和缺失的信息到底是什么，收集的信息和缺失的信息尽量用机器学习和自然语言理解的方式把它做自动化补全，但这个过程一定是有精度的损耗，这也是为什么到现在为止零研发只能覆盖到80%的日常模块开发中。
最后，我们回过头看前面这张图，左边是逻辑识别的协议，这个协议是将理解生成代码和后面流程串联在一起的交互界面，右边是逻辑表达协议，通过这个过程生成代码未来怎样才能复用更多的不同架构中去。
在整个过程中，我们使用到的机器学习能力包括迁移学习、卷积神经网络、Resnet、tensorflow等，现在机器学习在图像识别和自然语言理解领域已经非常成熟，都有非常general的模型可以解决业务中常见的80%～90%的问题，但是大家对这些能力的理解是欠缺的。因此，我们与tensorflow.js合作，未来希望能够降低大家使用技术的成本，便于大家快速进入到其中，快速了解技术能力的优缺点，以给自己做技术选型时候做支撑，还有使用技术时的流程是怎样的，和现有前端链路怎样做深度结合，来保证未来使用技术时成本更低、体验更好。
赋予开发者自定义的能力
如何能够更好的使用tensorflow和机器学习的能力？我们有很多环节已经被过往的先驱屏蔽了，比如对于创建模型来说，将这个模型实例化就可以调用了；添加分类和样本，前端代码从源码分析到生成，整个技术生态非常完备，因此我们可以自动化产生标注数据，而不像传统机器学习很痛苦，需要请一堆人员做样本数据，我们现在的样本大部分可以通过调用框架、读取gitlab上业务代码，通过headless技术用poptear渲染出来，渲染之前就会写清楚是什么模块什么组件，将来绑定数据是什么，整个技术体系非常完备。未来我们想训练自己的模型时，我们的优势是可以生成大量优质的标注数据来帮助我们描述定义的问题的重要特征。在训练模型部分，我们有auto-machine-learning技术，部署模型也有各种各样的工具，尤其是有了tensorflowdistribution的一些工具后，再加上现在可以在云端很多容器里做部署，都是很简单的。
所以，我们与tensorflow.js技术团队一起合作，希望能够降低前端学习机器学习的成本，我们发明了Escher框架，Escher想让前端开发人员零成本进入前端智能化领域去用机器学习能力解决业务上的问题，我们要保证未来大家在使用技术时能够跟现有的前端技术生态可以无缝连接在一起，比如现有技术生态已经有日志收集工具，这个日志收集工具收集的日志可以直接被Escher使用做数据清洗、数据增强到模型中进行训练等。
在此非常激动的告诉大家，我们已经走完了pipcook的开源流程，欢迎大家加入到我们的开源项目中来，初期，我们只提供了为数不多的几条pipeline，在pipeline中大家可以很低成本实现数据收集、模型训练到发布的全流程，未来我们希望能够通过数据和模型统一的标准，让大家可以在统一的技术生态里做技术促进。开源网址如下：
GitHub：
https://github.com/alibaba/pipcook前端智能化的未来
最后，我们对designtocode的规划如图所示，需求的结构化收集是我们后面比较重要的一点，在本身的imgcook链路里，体验相对来说不是特别好，要求大家安装sketch或者Photoshop，还要再装插件，这些问题我们都在一点点解决，我们在下个月会release一个版本，用户不再需要安装sketch和插件了，只需要上传设计师给你的源文件，或提供一个URL，我们就可以自动分析源文件，帮你生成代码，也不存在复杂粘贴的过程。只有当你认为代码在你的工程链路中无法满足你的需求时，需要自己二次编辑时，才有必要打开web编辑器。未来我们希望通过需求结构化收集进一步提升生成逻辑代码的准确度以及我们可以覆盖的业务场景，最后我们希望通过开源的方式把imgcook内部的模型能力和生成代码的质量进一步打磨好，争取在明年年底开源出来。
我们希望从以前单设计稿页面，变成更详细的收集需求，把我们生成逻辑代码能力覆盖到多页面的复杂交互场景中。
最终，我们希望可以完全替代动效的开发和逻辑开发，把这部分精力释放出来做更多有意义的事情。
我们希望当下做的很多事情，未来可以找到更多的业务场景。