智能生成前端代码的信息输入思考

文 / 波本

背景 & 趋势

随着近几年人工智能的发展，AI 已经在各行各业初露头角。在互联网 Web 研发设计这块，近几年也能看到相似像 Rico（移动端应用程序标注数据集）这样的公开数据集涌现出来，供业界研究人员能更好地在移动应用程序（App）这个场景下作一些学术研究，智能生成前端代码就是其中一个不错的方向。

除开一些用作学术研究的数据集外，也有一些互联网产品直接尝试作智能生成代码的服务，旨在提供生成代码服务的同时，经过搜集服务生成代码的质量评测，能更进一步的去不断优化自身生成代码的服务能力。

• imgcook：擅长设计稿生成代码服务
• fronty：擅长图像生成网站首页
• Yotako：擅长 PSD 生成代码服务

以上三款生成代码的产品，输入信息的渠道大都来源于设计师的结构化设计稿或者图像，同时，这份输入的解析也决定了最终输出自动生成代码的质量，那么如何去衡量这里面代码生成的质量呢？咱们先来看看一般状况下咱们的前端代码构成是怎样的。

代码的结构化构成

一般咱们的前端代码结构上可大体分为这两块：静态 GUI 代码和动态逻辑代码。

静态 GUI 代码

静态 GUI 代码通常由超文本标记语言（HTML）和层叠样式表（CSS） 组成。代码在视觉样式上的描述可以对照设计阶段中各图层节点的填充样式，但在层级结构上的描述一般是前端代码独有的，不在设计阶段里能体现。

动态逻辑代码

前端的逻辑代码（Javascript）一般是交互逻辑代码，每每是赋予静态 GUI 代码一些动态的交互逻辑行为，也是编程实现需求中最繁琐的一部分，但此类交互逻辑行为一般在设计阶段不太能直接体现（静态设计工具中）这里面的意图。

在当下 Serverless 的火热趋势下，前端即将面对的另外一块编程代码即服务端 FaaS（Function as a Server）研发，这里面包含了前端对需求中服务端数据的获取以及处理过程，更贴近程序背后数据流的编码处理。

上面这三部分的代码占据了咱们前端现在大部分编程内容，要实现这些代码的智能化生成，咱们须要这两方面的准备：

• 将这些代码的描述结构化，经过数据描述进行转换
• 从相关的素材中提取出关键的信息进行结构化的数据描述

本文重点讲第二部分信息数据获取的思考，下面咱们来看看获取生成代码的信息渠道来源都包含哪几部分。

信息的输入来源

在实际业务需求场景中，咱们在研发前能接触到的信息包含以下几块：产品经理的需求稿、交互设计师的交互稿、视觉设计师的视觉稿以及定稿后的页面图像。
若是把咱们的网页（程序）信息流通的过程对比到著名数学家克劳德·香农提出的信息论中（信息源-编码器-信道-译码器）：

• 信息源对应需求稿即对网页（程序）的策划需求
• 编码器对应交互稿即设计师对获得的需求进行交互以及页面总体设计形态的安排
• 信道对应设计稿即设计师在设计中使用图像、色彩、文本、音响等做为信息传输信道
• 译码器则对应这些信道最终展示在用户面前去翻译成自身理解的信息过程，好比理解图像中某个具体的功能组件

从上能够看出，用户对一个应用程序的完整信息获取及理解来源于信息在各个阶段的流动，只看单一的渠道咱们势必会丢失其余部分重要的信息内容，这对于研发态信息的获取也同样，就比如你只看视觉稿不看需求稿去作研发，显然交付的代码所实现的需求每每是不合格的。

需求稿（PRD）

需求稿每每含括了前台和服务端数据的需求功能点，也是用户信息得到的最原始的起点。但基本上需求稿的内容是无法结构化描述的，也意味着咱们只能人为主观地消化理解这里面的信息，若是咱们把产品经历的需求稿交付作约束让其结构化地表达呢？

	前台数据展示	前台交互逻辑	后台数据逻辑
模块 A	展示字段 A、字段 B 等	字段 A 没有时隐藏；模块点击时发送埋点	字段 A 从 xx 渠道获取，并作 xxx 处理

能够看到，对于结构化表达的需求稿，咱们能更容易地提取出具体模块在上述三部分前端代码中所对应的信息，经过天然语言处理（NLP）等能力结合具体领域存量数据模型便可分析并结构化地描述出咱们所须要的重要逻辑代码。

视觉稿设计

设计稿的内容描述相对就比较简单了，目前设计师使用的一些设计工具好比 Sketch、Photoshop、XD 等软件，自己都是带有必定的结构化描述，咱们只须要经过设计工具附带的开发者能力将视觉稿中的这部分结构化信息提取出来，转换成咱们自身所须要的结构化描述便可填充到咱们的静态 GUI 视觉代码中。

交互稿（动效）设计

这里主要讲述能偏动效以及响应的交互稿，不一样于视觉稿对图层节点静态信息的描述，交互稿一般表达的是节点状态间的响应，在一些常见的能制做交互响应的设计工具中（好比 AE、Principle），若是咱们能提取出设计工具里对设计师制做的交互结构化描述，那么咱们也能够去将其转换为咱们编程中所对应的交互行为，将这部分做为前端前台交互逻辑代码实现部分。

模型信息学习

除开上述直接的从信息载体获取数据外，咱们还能基于咱们的经验经过模型训练学习的方式让咱们所提取到的数据更加丰富，好比设计稿中描述不了常见 Web 组件，咱们能够经过目标检测的模型去提取到这部分的信息；好比对于业务域中文本内容对应的字段，咱们也能够经过分类学习的方式将设计稿中静态的文本内容自动映射到动态的字段上。

图像

不一样于上述的信息携带载体，图像中是不含有结构化的信息数据的，咱们只能直观地获取图像中的像素点阵信息。不过借助目前的深度学习的能力，咱们能够提取图像里基本的设计元素的内容（文本、图像、Shape）以及样式属性。

除此外，咱们还能够经过训练模型来达到识别一张图像中存在的目标（组件）的信息内容描述。

文本

对于设计稿中一些静态的文本内容，若是存在跟接口下发的动态字段映射的关系，咱们也可分析设计师常描绘的文本内容，结合具体业务该内容可能对应的数据字段去作结合，好比 xxx 旗舰店，咱们可能猜想其为业务数据 店铺 数据源中的 店铺标题 字段，从而能在生成代码的时候跟接口中的字段作自动的映射。

结构描述

结构描述指的是从上述设计稿中提取的产物（JSON 数据描述），咱们在使用 GUI 静态代码描述页面或应用程序时，除了基本的样式信息，每每还会带有一部分的语义结构，即结构布局分组。实际上视觉稿中是不包含结构语义这层信息的，所以咱们每每须要使用咱们过往的布局结构语义经验去经过模型来训练获得这部分的结果，以使 GUI 的布局结构描述更具语义化。

信息的深度链接

智能生成代码的信息来源渠道有许多，每一个渠道都多多少少跟最终生成的代码息息相关，若是不能所有消化使用这些信息，那么生成的代码必然是不完整的，于是将这些来源于不一样维度的信息点如何汇集到一条线上也是很是关键的。

如下是咱们将不一样渠道的信息去作关联分析的一个尝试，能够看到，各渠道的输入咱们可使用模块的维度去作关联，即一个模块对应了 GUI 静态代码、前台逻辑代码、服务端数据逻辑代码以及对模块内潜在的模型组件识别的结果。经过这些信息的链接，咱们生成的模块代码里除了最先阶段单单从视觉稿中还原获得的静态 UI 代码之外，还能结合其余逻辑、语义信息将其中静态的部分自动转换为动态，从而达到完整代码的目的（字段绑定、模块物料识别、渲染逻辑等）。

总结

imgcook 经历了两年的磨练，论证了当下从设计稿中提取信息去自动生成部分 GUI 代码的方案是可行的，那么下一步如何能从其余信息渠道去获取到更多的信息，在一个平面上将这些信息点去作关联分析，创建成一个完整的图谱，以达到覆盖生成更多的准确的代码，将是咱们持续去探索的方向。