阿里前端也切图?不,人工智能帮你做

javascript/jquery

浏览数:35

2020-5-28

AD:资源代下载服务

关注我的公众号:一颗小树,一起交流,共同成长。

作为负责阿里云大官网和营销中台团队中的一员,我们的日常工作是横向支撑各类运营同学的需求,建设线上运营场和营销能力,帮助他们实现用户和收入的增长。在以前我们常常会听到这样的声音:

  • “今天我们有一个紧急的需求,可以帮忙支持一下吗?”
  • “这个页面很简单的,但是我们没有自己的前端同学,能帮忙支持一下吗?”
  • “我的需求提交很久了,什么时候才能排期呢?”

过去的协作完全基于人工支持,大家疲于奔命,但前端往往还是成为瓶颈,难以抽出时间来进行深度的思考和能力建设,长此以往会陷入一个恶性循环,同时外包和计件服务的也在逐渐减退,开发提效迫在眉睫。大家很容易能够想到,针对常见的业务场景和模式进行组件化的沉淀,没错,我们成功和设计同学改变协作模式,组成统一战线,实现了核心营销玩法和通用组件的沉淀,实现大部分日常场景的运营自主搭建。
但与此同时,我们发现组件化并不能解决所有的问题,同时组件化的开发本身也是具有不小的开发成本的,是否能通过集团沉淀的能力和经验,为我们带来一些新的思路呢?这时我们盯上了集团智能化方向,在帮助我们进一步提效开发的同时,也为我们智能化能力的演进打下了基础。

集团造风,我们乘风

对我来说,智能化是集团前端四大方向中最神秘的一隅。经过研读智能化小组的分享以及和小组成员的交流,梳理出了我们的场景和集团智能化方向场景的异同。

集团(淘系为主) 阿里云大官网
场景 营销导购 营销导购
客户端 无线场景为主 PC + H5
场景特点 复杂度相对较低,展示型为主 复杂度相对较高,存在复杂的交互和状态切换
需求特点 业务模式和视觉规范更成熟 玩法和营销模式长期处于探索期,业务需求变动比较频繁
数据模型 有成熟的业务数据模型,搭投一体输出数据 数据模型结构化程度还不够,多需要运营人工完成录入
提效思路 在认为基础组件和业务组件复用难度高的前提下,通过 D2C 能力和可视化编辑,降低二次开发的成本 组件化沉淀约束设计规范和复杂玩法;
简单模块零开发,不需要前端参与;
服务人群 前端开发 运营 + 设计师 + 前端开发

淘系是在场景、数据模型甚至需求标准化的前提下,利用智能化实现开发提效。我们是在各个层面的标准化暂未成熟的前提下,期望通过智能化能力,降低日常需求的投入,用技术为开发提效,为运营赋能。
当前集团智能化方向的核心能力是 D2C(Design to Code)能力,其中 UI、数据、逻辑的识别和表达,是基于「智能化的前提是标准化」这一前提进行的模型构建和训练,最终以 imgcook 作为产品载体输出。在集团的其它 多个 BU 中,多为利用 imgcook 的能力,配合可视化编排引擎,落地低代码开发,提高开发效率。
这证明智能化能力在开发提效的路径是走得通的,这时候需要结合我们的场景,思考更多的可能性。由于我们会有大量的日常/临时需求,纯粹靠人工或外包的模式始终是成本很高,对业务的体感也较差。
最终我们确定进一步优化 D2C 能力,通过工具自动完成数据坑位的提取,转换生成模块 DSL,直接从视觉稿输出可渲染的模块,最终让前端以外的角色能自己玩起来。与此同时,我们的设计(稿)规范、数据模型、业务需求,还不具备成熟的标准,因此,我们需要根据差异点,梳理解法并设计对应的技术方案。

站在巨人的肩膀上,构建适合我们的智能化能力

最终经过和团队小伙伴的共同努力,上线了两种能够助力我们提效的智能化方案。

Design to Component – 组件设计器落地零开发

实现了视觉稿直接生成模块,自动挖取数据坑位的能力。对于普通展示类型的页面,可以在小时级完成配置并上线。

Design to Code – 借力 imgcook 提效二次开发

这部分依托 imgcook 的标准开发链路,拓展自定义 DSL,降低 70% 以上视觉还原的成本。

以智能化为主线,沉淀通用技术能力


首先需要解决 DSL 可维护性和可拓展性的问题,比如多种模块 DSL 的组装和输出,因此建设了 DSL 转换引擎。另一方面,零开发需要实现数据自动挖坑和绑定的能力,就要求我们从视觉稿中获取更多信息,具备识别模块结构的能力,即合理的分组和节点的识别,因此建设了结构化引擎。
在整个过程中,对团队需要的智能化能力进行了一轮梳理,技术设计上,也增加了更多灵活的设计,应对未来的可能性。
最终为我们的开发实现了不同程度的提效。

下面为大家详细介绍实现 D2C 能力的技术方案。

DSL 转换引擎:配置化输出可运行的 DSL

这一步是将相对定位的模块描述数据转化为前端直接可用的代码。自定义 DSL 的原理不在此赘述,我们的诉求是DSL 转换能力可以支持在 Node、Web 等多端可用,同时由于我们未来需要支持多种 DSL 规范,这些规范有可复用的部分,也需要有灵活拓展的能力。

因此我们将其中的能力分为核心层(Core)和处理器(Processor),每一个处理器是一个独立的功能单元,分别负责最终代码需要的模板、样式、数据和 Schema 生成等功能。核心层负责标准化输入输出,完成处理器流程的串联,补充拓展性。最终完成配置化 DSL 转换引擎的输出。

结构化引擎:掌握模块结构,解析定义元素

结构化的基础思考是当前 imgcook 能力需要对视觉稿进行简单的规划化整理,我们期望尽可能少的对视觉稿进行干预,降低其他角色的使用成本,那就有必要对模块进行标准化的描述。同时 imgcook 的官网推荐链路中可视化的二次编辑尤为重要,在这里会补充视觉稿不太方便直接描述的信息,比如数据字段的绑定、循环的处理、事件的声明等等逻辑。
如果我们期望实现零开发的链路,就必须要自动补全部分这类信息。针对数据字段的绑定,需要了解当前模块中有哪些节点、每个节点需要开放哪些配置,即需要具备 UI 模型的识别和解析能力。针对组件结构的识别,借鉴了集团的布局算法方案,实现了一版基于我们场景下较简单的分组算法。
最终结构化引擎输出的设计如下,其中元素模型负责对模块中元素的识别和解析,抽象基类处理通用逻辑,不同元素可输出不同能力,实现精细化识别;结构转换的基础是标准的分组结构,未来辅助精细化的元素模型,实现更智能的结构识别,如循环等。

结构化引擎在底层设计做了更多通用化的考量,未来可以作为通用的模块结构解析能力,不局限在 D2C 生成的模块中,标准结构化信息可以覆盖所有的搭建平台模块,拓展更多的业务场景。

乘风破浪,持续探索智能化建设方向

目前初步实现了 D2C 能力的最小闭环,已经在部分业务场景中使用,期待能在提效上带来的成果,未来还有很多可以想象的空间:

  • 以智能化为基础,充实提效能力,重点是结构化引擎优化,充实识别能力。如:

    • 标准组件匹配率提升,补充配置化能力
    • 循环结构自动识别,数据循环配置自动输出
    • 推进视觉规范,利用 PC 自动完成 H5 适配
    • 持续接入其它智能化能力,如智能配色、智能合图
  • 以智能化为契机,探索业务赋能方向,如:

    • 改变业务支撑模式,提高业务支撑效率
    • 串联数据体系,提供业务效果优化建议,辅助业务决策
    • 接入标准模型,内容智能匹配,减少人工配置
    • 模块结构分析,智能匹配已有组件,提高搭建效率

结语

目前不可避免地还存在一些问题,比如需要对视觉稿做标准化的处理,短时间内还难以避免前端同学零投入。但智能化能力还是给我们带来了前所未有的强大能力,帮助前端解放生产力,投入到更有价值的领域中去。

最后的最后,欢迎一起来建设阿里云 ToB 的线上体系,做点不一样的事儿。长期接收任意姿势的社招同学,邮箱 yeshu.lrt@alibaba-inc.com,欢迎交流。

作者:_Icarus