……
将这些问题拆解后，分门别类专项解决，解决起来看似没完没了，但好在目前发现的大类问题基本已解决。很多人质疑道，这部分的能力的实现看起来和智能化没有什么关系，顶多算个布局算法相关的专家规则测量系统。没错，现阶段这部分比较适合规则系统，对用户而言布局算法需要接近 100% 的可用度，另外这里涉及的大部分是无数属性值组合问题，当前用规则更可控。如果非要使用模型，那这个可被定义为多分类问题。同时，任何深度学习模型的应用都是需要先有清晰的问题定义过程，把问题规则定义清楚本就是必备过程。
但在规则解决起来麻烦的情况下，可以使用模型来辅助解决。比如 合理分组(如下图) 和 循环项 的判断，实践中我们发现，在各种情况下还是误判不断，算法规则难以枚举，这里需要跨元素间的上下文语义识别，这也是接下来正在用模型解决的重点问题。
合理分组示意
逻辑代码
逻辑代码开发主要包括数据绑定、动效、业务逻辑代码编写。可提效的部分，一般在于复用的动效和业务逻辑代码可沉淀基础组件、业务组件等。
★ 逻辑代码生成思考
理想方案当然是能像其他诗歌、绘画、音乐等艺术领域一样，学习历史数据，根据 PRD 文本输入，新逻辑代码能直接生成，但这样生成的代码能直接运行没有任何报错吗?
目前人工智能虽说发展迅速，但其能解决的问题还是有限，需要将问题定义成其擅长解决的问题类型。强化学习擅长策略优化问题，深度学习目前在计算机视觉方面擅长解决的是分类问题、目标检测问题，文本方面擅长 NLP( , 自然语言处理) 等。
关于业务逻辑代码，首先想到的是对历史源代码的函数块利用 LSTM(Long Short-Term , 长短期记忆网络)和 NLP 等进行上下文分析，能得到代码函数块的语义，VS Code 智能代码提醒 和 都是类似的思路。
另外，在分析问题中(如下图)我们还发现，智能化在业务逻辑领域还可以协助识别逻辑点在视图出现的位置(时机)，并根据视图猜测出的逻辑语义。
综上，我们总结一下智能化现阶段的可助力点：
所以，现阶段在业务逻辑生成中，可以解决的问题比较有限，尤其是新的业务逻辑点以新的逻辑编排出现时，这些参考依据都在 PD 的 PRD 或脑海中。所以针对业务逻辑的生成方案，现阶段的策略主要如下：
小结
目前用智能化的方式自动生成 HTML + CSS + 部分 JS + 部分 DATA 的主要分析如上，是 to Code 的主要过程 ，内部项目名称叫做 D2C ，后续系列文章会使用此简称，集团内外的落地产品名称为 。随着近几年主流设计工具(、PS、XD 等)的三方插件开发能力逐渐成熟，飞速发展的深度学习那甚至超过人类识别效果的趋势，这些都是 D2C 诞生和持续演进的强大后盾。
目标检测 2014-2019 年 paper
技术方案
基于上述前端智能化发展概括分析，我们对现有的 D2C 智能化技术体系做了能力概述分层，主要分为以下三部分：
识别能力：即对设计稿的识别能力。智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息。如果智能识别不准，就可视化人工干预补充纠正，一方面是为了可视化低成本干预生成高可用代码，另一方面这些干预后的数据就是标注样本，反哺提升智能识别的准确率。
表达能力：主要做数据输出以及对工程部分接入
通过 DSL 适配将标准的结构化描述做
通过 IDE 插件能力做工程接入
算法工程：为了更好的支撑 D2C 需要的智能化能力，将高频能力服务化，主要包含数据生成处理、模型服务部分
样本生成：主要处理各渠道来源样本数据并生成样本
模型服务：主要提供模型 API 封装服务以及数据回流
前端智能化 D2C 能力概要分层
在整个方案里，我们用同一套 数据协议规范(D2C )来连接各层的能力，确保其中的识别能够映射到具体对应的字段上，在表达阶段也能正确地通过出码引擎等方案生成代码。
智能识别技术分层
在整个 D2C 项目中，最核心的是上述识别能力部分的 机器智能识别 部分，这层的具体再分解如下，后续系列文章会围绕这些细分的分层展开内部实现原理。
D2C 识别能力技术分层
技术痛点
当然，这其中的 识别不全面、识别准确度不高 一直是 D2C 老生常谈的话题，也是我们的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素：
识别问题定义不准确：问题定义不准确是影响模型识别不准的首要因素，很多人认为样本和模型是主要因素，但在这之前，可能一开始的对问题的定义就出现了问题，我们需要判断我们的识别诉求模型是否合适做，如果合适那该怎么定义清楚这里面的规则等。高质量的数据集样本缺乏：我们在识别层的各个机器智能识别能力需要依赖不同的样本，那我们的样本能覆盖多少前端开发场景，各个场景的样本数据质量怎么样，数据标准是否统一，特征工程处理是否统一，样本是否存在二义性，互通性如何，这是我们当下所面临的问题。模型召回低、存在误判：我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练，期望通过一个模型来解决所有的识别问题，但这却往往会让模型的部分分类召回率低，对于一些有二义性的分类也会存在误判。
★ 问题定义
深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题，我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解，这类问题是否有二义性等，如果人也无法准确地判断，那么这个识别问题可能就不太合适。
假如判断适合用深度学习的分类来做，那就需要继续定义清楚所有的分类，这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候，一般图片的 通用常规命名有哪些，举个例子，其分析过程如下：
D2C 项目中很多这样的问题，问题本身的定义需要非常精准，并且需要有科学的参考依据，这一点本身就比较难，因为没有可借鉴的先例，只能先用已知的经验先试用，用户测试有问题后再修正，这是一个需要持续迭代持续完善的痛点。
★ 样本质量
针对 样本 问题，我们需要对这部分数据集建立标准规范，分场景构建多维度的数据集，将收集的数据做统一的处理和提供，并以此期望能建立一套规范的数据体系。
在这套体系中，我们使用统一的样本数据存储格式，提供统一的针对不同问题(分类、目标检测)的样本评估工具来评估各项数据集的质量，针对部分特定模型可采取效果较好的特征工程(归一化、边缘放大等)来处理，同类问题的样本也期望能在后续不同的模型里能够流通作比较，来评估不同模型的准确度和效率。
数据样本工程体系
★ 模型
针对模型的召回和误判问题，我们尝试 收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点，导致产生误判、召回低，我们期望能够通过收敛场景来做模式化的识别，提高模型准确度。我们把场景收敛到如下三个场景：无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色，针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。
D2C 场景
过程思考
既然使用了深度模型，有一个比较现实的问题是，模型的泛化能力不够，识别的准确率必然不能 100% 让用户满意，除了能够在后续不断地补充这批识别不到的样本数据外，在这之前我们能做什么?
在 D2C 的整个还原链路里，对于识别模型，我们还遵守一个方法论，即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果，保障在模型识别不准确的情况下用户仍可完成诉求：手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体：
其中手动约定的设计稿协议解析优先级最高，这样也能确保后续的流程不受阻塞和错误识别的干扰。
业务落地
2019 双十一落地
在今年的双十一场景中，我们的 D2C 覆盖了天猫淘宝会场的新增模块，包括主会场、行业会场、营销玩法会场、榜单会场等，包含了视图代码和部分逻辑代码的自动生成，在可统计范围内，D2C 代码生成占据了大比例。目前代码的人工改动的主要原因有：全新业务逻辑、动画、字段绑定猜测错误(字段标准化情况不佳)、循环猜测错误、样式自适应修改等，这些问题也都是接下来需要逐步完善的。
D2C 代码生成用户更改情况
整体落地情况
我们对外的产品 ，截止 2019.11.09 日，相关的使用数据情况如下：
目前可提供的服务能力如下：
后续规划
继续降低设计稿要求，争取设计稿 0 协议，其中分组、循环的智能识别准确度提升，减少视觉稿协议的人工干预成本。
组件识别准确度提升，目前只有 72% 的准确度，业务应用可用率低。
页面级和项目级还原能力可用率提升，依赖页面分割能力的准确度提升。
小程序、中后台等领域的页面级还原能力提升，含复杂表单、表格、图表的整体还原能力。
静态图片生成代码链路可用度提升，真正可用于生产环境。
算法工程产品完善，样本生成渠道更多元，样本集更丰富。
D2C 能力开源。
未来我们希望能通过前端智能化 D2C 项目，让前端智能化技术方案普惠化，沉淀更具竞争力的样本和模型，提供准确度更高、可用度更高的代码智能生成服务;切实提高前端研发效率，减少简单的重复性工作，不加班少加班，一起专注更有挑战性的工作内容!
人工智能的定义可以分为两部分，即“人工”和“智能”。“人工”比较好理解，争议性也不大。有时我们会要考虑什么是人力所能及制造的，或者人自身的智能程度有没有高到可以创造人工智能的地步，等等。但总的来说，“人工系统”就是通常意义下的人工系统。
相关文章
