双 11 模块 79.34% 的代码是怎样智能生成的？（一）-InfoQ

导读：作为今年阿里经济体前端委员会的四大技术方向之一，前端智能化方向一被提及，就不免有人好奇：前端结合 AI 能做些什么，怎么做，未来会不会对前端产生很大的冲击等等。本篇文章将围绕这些问题，以「设计稿自动生成代码」场景为例，从背景分析、竞品分析、问题拆解、技术方案等几个角度切入，细述相关思考及过程实践。

背景分析

业界机器学习之势如火如荼，「AI 是未来的共识」频频出现在各大媒体上。李开复老师也在《AI·未来》指出，将近 50％的人类工作将在 15 年内被人工智能所取代，尤其是简单的、重复性的工作。并且，白领比蓝领的工作更容易被取代；因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被取代，而白领工作一般只需要软件技术突破就可以被取代。那我们前端这个“白领”工作会不会被取代，什么时候能被取代多少？

回看 2010 年，软件几乎吞噬了所有行业，带来近几年软件行业的繁荣；而到了 2019 年，软件开发行业本身却又在被 AI 所吞噬。你看：DBA 领域出现了 Question-to-SQL，针对某个领域只要问问题就可以生成 SQL 语句；基于机器学习的源码分析工具 TabNine 可以辅助代码生成；设计师行业也出了 P5 Banner 智能设计师“鹿班”，测试领域的智能化结合也精彩纷呈。那前端领域呢？

那就不得不提一个我们再熟悉不过的场景了，它就是设计稿自动生成代码（Design2Code，以下简称 D2C），阿里经济体前端委员会-前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作，让前端工程师专注更有挑战性的工作内容！

竞品分析

2017 年，一篇关于图像转代码的 Pix2Code 论文掀起了业内激烈讨论的波澜，讲述如何从设计原型直接生成源代码。随后社区也不断涌现出基于此思想的类似 Screenshot2Code 的作品，2018 年微软 AI Lab 开源了草图转代码工具 Sketch2Code，同年年底，设计稿智能生成前端代码的新秀 Yotako 也初露锋芒，机器学习首次以不可小觑的姿态正式进入了前端开发者的视野。

基于上述竞品分析，我们能够得到以下几点启发：

1.深度学习目前在图片方面的目标检测能力适合较大颗粒度的可复用的物料识别（模块识别、基础组件识别、业务组件识别）。

2.完整的直接由图片生成代码的端到端模型复杂度高，生成的代码可用度不高，要达到所生成代码工业级可用，需要更细的分层拆解和多级子网络模型协同，短期可通过设计稿生成代码来做 D2C 体系建设。

3.当模型的识别能力无法达到预期准确度时，可以借助设计稿人工的打底规则协议；一方面人工规则协议可以帮助用户强干预得到想要的结果，另一方面这些人工规则协议其实也是高质量的样本标注，可以当成训练样本优化模型识别准确度。

问题分解

设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作内容。那我们先来分析下，“常规”前端尤其是面向 C 端业务的同学，一般的工作流程日常工作内容大致如下：

“常规”前端一般的开发工作量，主要集中在视图代码、逻辑代码和数据联调（甚至是数据接口开发，研发 Serveless 产品化时可期）这几大块，接下来，我们逐块拆解分析。

视图代码

视图代码研发，一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效，当面对 UI 视图开发重复性的工作时，自然想到组件化、模块化等封装复用物料的解决方案，基于此解决方案会有各种 UI 库的沉淀，甚至是可视化拼装搭建的更 High Level 的产品化封装，但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花，直面问题本身，直接生成可用的 HTML 和 CSS 代码是否可行？

这是业界一直在不断尝试的命题，通过设计工具的开发插件可以导出图层的基本信息，但这里的主要难点还是对设计稿的要求高、生成代码可维护性差，这是核心问题，我们来继续拆解。

▐ 设计稿要求高问题

对设计稿的要求高，会导致设计师的成本加大，相当于前端的工作量转嫁给了设计师，导致推广难度会非常大。一种可行的办法是采用 CV（ComputerVision, 计算机视觉）结合导出图层信息的方式，以去除设计稿的约束，当然对设计稿的要求最好是直接导出一张图片，那样对设计师没有任何要求，也是我们梦寐以求的方案，我们也一直在尝试从静态图片中分离出各个适合的图层，但目前在生产环境可用度不够（小目标识别精准度问题、复杂背景提取问题仍待解决），毕竟设计稿自带的元信息，比一张图片提取处理的元信息要更多更精准。

▐ 可维护性问题

生成的代码结构一般都会面临可维护性方面的挑战：

合理布局嵌套：包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面；
元素自适应：元素本身扩展性、元素间对齐关系、元素最大宽高容错性；
语义化：Classname 的多级语义化；
样式 CSS 表达：背景色、圆角、线条等能用 CV 等方式分析提取样式，尽可能用 CSS 表达样式代替使用图片；
……

将这些问题拆解后，分门别类专项解决，解决起来看似没完没了，但好在目前发现的大类问题基本解决。很多人质疑道，这部分的能力的实现看起来和智能化一点关系都没有，顶多算个布局算法相关的专家规则测量系统。没错，现阶段这部分比较适合规则系统，对用户而言布局算法需要接近 100% 的可用度，另外这里涉及的大部分是无数属性值组合问题，当前用规则更可控。如果非要使用模型，那这个可被定义为多分类问题。同时，任何深度学习模型的应用都是需要先有清晰的问题定义过程，把问题规则定义清楚本就是必备过程。

但在规则解决起来麻烦的情况下，可以使用模型来辅助解决。比如合理分组（如下图）和循环项的判断，实践中我们发现，在各种情况下还是误判不断，算法规则难以枚举，这里需要跨元素间的上下文语义识别，这也是接下来正在用模型解决的重点问题。

逻辑代码

逻辑代码开发主要包括数据绑定、动效、业务逻辑代码编写。可提效的部分，一般在于复用的动效和业务逻辑代码可沉淀基础组件、业务组件等。

接口字段绑定：从可行性上分析还是高的，根据视觉稿的文本或图片判断所属哪个候选字段，可以做，但性价比不高，因为接口数据字段绑定太业务，通用性不强。
动效：这部分的开发输入是交互稿，而且一般动效的交付形式各种各样参差不齐，有的是动画 gif 演示，有的是文字描述，有的是口述；动效代码的生成更适合用可视化的形式生成，直接智能生成没有参考依据，考虑投入产出比不在短期范围内。
业务逻辑：这部分开发的依据来源主要是 PRD，甚至是 PD 口述的逻辑；想要智能生成这部分逻辑代码，欠缺的输入太多，具体得看看智能化在这个子领域能解决什么问题。

▐ 逻辑代码生成思考

理想方案当然是能像其他诗歌、绘画、音乐等艺术领域一样，学习历史数据，根据 PRD 文本输入，新逻辑代码能直接生成，但这样生成的代码能直接运行没有任何报错吗？

目前人工智能虽说发展迅速，但其能解决的问题还是有限，需要将问题定义成其擅长解决的问题类型。强化学习擅长策略优化问题，深度学习目前在计算机视觉方面擅长解决的是分类问题、目标检测问题，文本方面擅长 NLP（Natural Language Processing, 自然语言处理）等。

关于业务逻辑代码，首先想到的是对历史源代码的函数块利用 LSTM（Long Short-Term Memory, 长短期记忆网络）和 NLP 等进行上下文分析，能得到代码函数块的语义，VS Code 智能代码提醒和 TabNine 都是类似的思路。

另外，在分析问题中（如下图）我们还发现，智能化在业务逻辑领域还可以协助识别逻辑点在视图出现的位置（时机），并根据视图猜测出的逻辑语义。

综上，我们总结一下智能化现阶段的可助力点：

由历史源代码分析猜测高频出现的函数块（逻辑块）的语义，实际得到的就是组件库或者基础函数块的语义，可在代码编辑时做代码块推荐等能力。

由视觉稿猜测部分可复用的逻辑点，如这里的字段绑定逻辑，可根据这里文本语义 NLP 猜测所属字段，部分图片元素根据有限范围内的图片分类，猜测所属对应的图片字段（如下图示例中的，氛围修饰图片还是 Logo 图片）；同时还可以识别可复用的业务逻辑组件，比如这里的领取优惠券逻辑。

所以，现阶段在业务逻辑生成中，可以解决的问题比较有限，尤其是新的业务逻辑点以新的逻辑编排出现时，这些参考依据都在 PD 的 PRD 或脑海中。所以针对业务逻辑的生成方案，现阶段的策略主要如下：

字段绑定：智能识别设计稿中的文本和图片语义分类，特别是文字部分。

可复用的业务逻辑点：根据视图智能识别，并由视图驱动自由组装，含小而美的逻辑点（一行表达式、或一般不足以封装成组件的数行代码）、基础组件、业务组件。

无法复用的新业务逻辑：PRD 需求结构化（可视化）收集，这是一个高难度任务，还在尝试中。

小结

目前用智能化的方式自动生成 HTML + CSS + 部分 JS + 部分 DATA 的主要分析如上，是 Design to Code 的主要过程，内部项目名称叫做 D2C ，后续系列文章会使用此简称，集团内外的落地产品名称为 imgcook。随着近几年主流设计工具（Sketch、PS、XD 等）的三方插件开发能力逐渐成熟，飞速发展的深度学习那甚至超过人类识别效果的趋势，这些都是 D2C 诞生和持续演进的强大后盾。