前端智能化有哪些作用？
作为负责 Aliyun 大官网和营销中台团队中的一员，我们的日常工作是横向支撑各类运营同学的需求，建设线上运营场和营销能力，帮助他们实现用户和收入的增长。在以前我们常常会听到这样的声音：
- “今天我们有一个紧急的需求，可以帮忙支持一下吗？”
- “这个页面很简单的，但是我们没有自己的前端同学，能帮忙支持一下吗？”
- “我的需求提交很久了，什么时候才能排期呢？”
过去的协作完全基于人工支持，大家疲于奔命，但前端往往还是成为瓶颈，难以抽出时间来进行深度的思考和能力建设，长此以往会陷入一个恶性循环，同时外包和计件服务的也在逐渐减退，开发提效迫在眉睫。大家很容易能够想到，针对常见的业务场景和模式进行组件化的沉淀，没错，我们成功和设计同学改变协作模式，组成统一战线，实现了核心营销玩法和通用组件的沉淀，实现大部分日常场景的运营自主搭建。 但与此同时，我们发现组件化并不能解决所有的问题，同时组件化的开发本身也是具有不小的开发成本的，是否能通过集团沉淀的能力和经验，为我们带来一些新的思路呢？这时我们盯上了集团智能化方向，在帮助我们进一步提效开发的同时，也为我们智能化能力的演进打下了基础。
集团造风，我们乘风
对我来说，智能化是集团前端四大方向中最神秘的一隅。经过研读智能化小组的分享以及和小组成员的交流，梳理出了我们的场景和集团智能化方向场景的异同。
| 集团（淘系为主） | Aliyun 大官网 | |
|---|---|---|
| 场景 | 营销导购 | 营销导购 |
| 客户端 | 无线场景为主 | 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 适配
- 持续接入其它智能化能力，如智能配色、智能合图
- 以智能化为契机，探索业务赋能方向，如：
- 改变业务支撑模式，提高业务支撑效率
- 串联数据体系，提供业务效果优化建议，辅助业务决策
- 接入标准模型，内容智能匹配，减少人工配置
- 模块结构分析，智能匹配已有组件，提高搭建效率
结语
目前不可避免地还存在一些问题，比如需要对视觉稿做标准化的处理，短时间内还难以避免前端同学零投入。但智能化能力还是给我们带来了前所未有的强大能力，帮助前端解放生产力，投入到更有价值的领域中去。