阿里前端也切图？不，人工智能帮你做

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

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

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

过去的协作完全基于人工支持，大家疲于奔命，但前端往往还是成为瓶颈，难以抽出时间来进行深度的思考和能力建设，长此以往会陷入一个恶性循环，同时外包和计件服务的也在逐渐减退，开发提效迫在眉睫。大家很容易能够想到，针对常见的业务场景和模式进行组件化的沉淀，没错，我们成功和设计同学改变协作模式，组成统一战线，实现了核心营销玩法和通用组件的沉淀，实现大部分日常场景的运营自主搭建。

但与此同时，我们发现组件化并不能解决所有的问题，同时组件化的开发本身也是具有不小的开发成本的，是否能通过集团沉淀的能力和经验，为我们带来一些新的思路呢？这时我们盯上了集团智能化方向，在帮助我们进一步提效开发的同时，也为我们智能化能力的演进打下了基础。

集团造风，我们乘风

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

集团（淘系为主） 阿里云大官网 场景 营销导购 营销导购 客户端 无线场景为主 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 的线上体系，做点不一样的事儿。长期接收任意姿势的社招同学，邮箱 [email protected]，欢迎交流。