前端代码是怎样智能生成的

imgcook 是以各种设计稿图像（ Sketch/PSD/静态图片）为原材料烹饪的匠心大厨，通过智能化手段将各种原始设计稿一键生成可维护的 UI 视图代码和逻辑代码。
逻辑开发是前端开发的需求动线图中最后，也是耗时最多的一步。从整个前端的开发过程上看，除了初始的静态视图编写，所有的 数据映射、添加动效、函数编写、事件流、埋点日志等代码本质上都是对静态视图信息的一种补充。
下图中，需求的产出是 产品、交互设计师、视觉设计师 共同协作的结果，而需求落地全由程序员实现。如果说 “视觉稿 结合 PRD 交互文档”等于最终可交付开发的需求文档，那么 “静态视图 + 逻辑”就等于一个前端页面的最终代码。
（需求动线图）

探索历程
前端开发工作属于 GUI（Graphic User Interface） 编程的一种，从命令行时代进入图形用户界面时代之后直到现在，对 便捷的进行界面开发 的探索就没有停歇过。在年头尚浅的前端领域，也有 MVC 和 MVVM 的设计思想落地 和 jquery、Backbone.js、Angular、vue、react 这些优秀框架类库的涌现。
关注点分离（Separation of concerns）是 GUI 开发领域的指导思想，通过将 View 视图 和 Model 数据 分离来简化软件内部结构。事实上大部分界面开发领域设计思想和框架都是遵循此基础思路实现的，html + css + js 的 web 技术也是此思想的一种体现。
集团推崇的 react 的思想比较接近这个最初的核心理念，仅提供 V 和 M，以及一个两者关联的渲染过程。简单来说就是 Ui = render(Data)，我们认同并作为依据之一开展了基于视觉稿视图还原代码的 D2C 项目。
我们本文所要探索的业务逻辑是项目代码中除了 View视图 以外的内容。如果说 D2C 是一个视觉稿到代码的过程，那么距最终可上线页面代码的缺失部分就要交给本文的业务逻辑层来实现。

所在分层
业务逻辑层处于 D2C 核心能力的最下游，所有服务化的智能化能力都需要在逻辑层实现最终的落地。
(D2C 技术能力分层)

挑战和难点

现状分析
在 D2C 的体系里，大部分技术体系都是基于设计稿视觉稿维度出发的，目标是解决布局结构、字段类名、内联组件识别的准确性和合理性。而业务逻辑需要补全 D2C 欠缺的能力，技术方案上和整个项目都不太一致。
同时，业务逻辑层作为承上启下的关键层，负责承接D2C智能化能力，输出到可视化编排平台。智能化结果的是一个概率，是一个有几率不准确的值，而下游的可视化编排 IDE 却是一个需要有确定性协议的程式，这样才能保证输出的代码可最终上线。业务逻辑能否实现智能化的稳定落地是我们一个极大的挑战。
在现有的 D2C 链路图里，业务逻辑层的输入信息除了布局算法转换后的 UI 结构，还有以下输入项：

语义化推测出的类名
字段绑定猜测出的可绑定字段（含图片分类和 NLP 分类）
组件物料识别出的小组件
…

业务逻辑层的产出结果是一份携带逻辑的可视化编排协议。这份协议的字段通过最终实现的功能来看又可划分成如下几种：

视图模型
字段绑定
函数逻辑
自定义组件转换
…

目标链路
传统开发链路中，UI 编码和逻辑需要人工编码。在当前的 D2C 链路中，基于 D2C 视觉还原能力，我们可以将 UI 编码实现自动化开发，基本省略 UI 的开发时间。而 D2C 业务逻辑层的目标，就是实现逻辑编码的自动化。我们希望将 D2C 能力进行全面升级，实现视觉 + 逻辑的统一还原，达到前端编码的零投入。
(传统编码链路、 D2C 链路 与 目标链路 )
上图中，蓝色的部分实现了自动化开发，红色的部分是 D2C 能力介入的位置。在我们期望的链路里，D2C 将还原并实现前端全部代码，而设计稿作为唯一的输入必然存在一些需求的缺失，为此我们在还原步骤之前增加逻辑预配置阶段，实现对缺失的需求进行补充。

问题分析

步骤一：思考真实的逻辑开发过程
我们在实现逻辑智能自动化之前，要分析一个逻辑代码是如何编写出来的。
假设我们已经开发好了静态视图，接下来需要为页面增加的逻辑代码需要一个输入的过程，这个输入源可以是我们的视觉稿、过往开发经验、框架下的特殊规则、PD 的需求文档等，从需求的输入源里我们获取需求相关的信息并具象为一个个逻辑点。
比如：视觉稿中有一个写着搜索的按钮，我们观察的同时检索脑海中过往经验，这个搜索大概率是一个点击触发一个网络请求的逻辑，借助需求文档和与相关接口人沟通，我们知晓了这个网络请求的方式和返回内容。据此，一个需求的形态就具象成了一个逻辑点，下一步就是逻辑编码并提测。
(前端需求编码操作动线)
为了实现逻辑的智能生成，以上操作动线必须实现全自动。我们观察需求编码动线，可以明显的发现：以需求具象为分割线，逻辑编码过程可拆分为前后两个大阶段。前一阶段实现需求的收集，后一阶段实现需求的实现，中间具象化的一个个需求点就是我们开发中要编码解决的工作。
在我们期望的链路中，业务逻辑层将为 D2C 能力提供逻辑预配置和逻辑还原两个增量能力。这两个增量能力对应到需求动线上就是需求的收集与需求的实现。在 D2C 体系里，我们称其为 逻辑识别 与 **逻辑表达，**并分别融入到链路下述两个位置上。
(D2C 逻辑链路)

步骤二：如何识别逻辑？
D2C 体系里，逻辑识别是一个预先配置的过程。不同的逻辑点可提前配置好不同的预案，用户使用 D2C 时命中了哪一项配置就认为此处存在哪个逻辑。
在 D2C 首先落地的 淘系营销场景 里，我们尝试分析逻辑智能化生成面临的最大问题。

思考一：“如何判别模块所含有的逻辑点？”
(如何观察模块含有的逻辑点)

扫一眼上述模块的布局模式，是一个 1排2 模块，需要一个循环逻辑。

“扫一眼”这个动作，通过分析布局算法给出的页面结构可以识别。

分析下各个文字，“跨店满减，错过等明年”是一个利益点类型文案.

人“分析文字”是对文字提取特征的过程，不同的目的下通常要提取不同的特征。此处文字中“跨店”、“满减”等利益点相关的词高频出现，我们基于 ALiWs 的分词算法和朴素贝叶斯多分类可以有效区分。

“已售1000件”看起来需要绑定到月销字段上；

此处也是个分析文字的过程，用正则可以准确区分。

左下方的券在含有一定显著的视觉特征，对于这种小区块通常抽象为一个业务组件；

左下方的券是一个业务组件，其样式，文字，节点数目存在数据特征，我们可以运用传统机器学习进行分析。

商品的图片是一张白底图，大概率绑定到白底图字段上；

商品图是一类特征明显的图，基于图像分类算法可较为轻松的识别。

立即购买按钮可能需要一个跳转到详情页的事件，也有不跳转，转而交给模块外层来跳转。

这个逻辑只能通过领域经验来识别。

思考二：“是否可以覆盖我们的场景？”
类似的分析过程还有很多，我们暂不赘述。为了能解决命题，我们迫切的需要知道实际场景中上述逻辑点的构成情况，为此我们分析淘系营销大促相关模块，得到如下逻辑点分布柱状图：
(营销模块逻辑分析柱状图)
其中数据绑定类逻辑数量占比 50% 以上，其次是埋点相关逻辑，循环相关逻辑，处理业务的函数相关逻辑，组件逻辑等。总的来说，淘系营销场景的模块开发逻辑是一套有规矩可循、有规范可依，可枚举、可复用、模式化、体系化的程式。经过多年双11验证，基本可以确定当下的规范可以满足业务需求，不会在短时间内有大规模的未知需求涌入。
(淘系营销模块开发规范)

思考三：“我们的识别手段有哪些？”
D2C 体系本身具有许多底层智能化手段，辅助以专家经验，可以对上述逻辑进行全面检索识别。举例如下：
随机森林算法：随机森林是一个包含多个决策树的分类器， 并且其输出的类别是由个别树输出的类别的众数而定。既可以用于回归也可以用于分类任务，并且很容易查看模型的输入特征的相对重要性。
xgboost 多分类：XGBoost全名叫（eXtreme Gradient Boosting）极端梯度提升，经常被用在一些比赛中，其效果显著。它是大规模并行boosted tree的工具，它是目前最快最好的开源boosted tree工具包。
文本 NLP 分类：基于阿里 PAI 平台提供的 ALiWs 的分词算法和朴素贝叶斯多分类进行文本分析。AliWS 的主要主要功能包括：歧义切分，多粒度切分，命名实体识别，词性标注，语义标注，支持用户自己维护用户词典，支持用户干预或纠正分词错误。
图片分类：对业务场景中的图片进行分类，使用 CNN 网络，在 ResNet 的基础上进行迁移训练。同样部署于 PAI 平台之上，和文本 NLP 分类产品化链路完全一致。
语义化服务：D2C 基于移动场景定制的类名语义服务。内部运用专家系统制定策略树，在具体判别过程中运用 Alinlp 语义实体、词法分析、翻译等二方服务，并自建 iconFont 服务实现了小图标的鉴别。
布局算法：D2C 基于自创的行列扫描策略发展出的绝对定位转 flex 布局的规则算法，同时提供了循环检测、局部成组等关键性功能。等等。
除此之外，我们有一些业务域下独有的逻辑是没有特征的，这部分逻辑使用人工干预手段来实现。
最终，我们决定选用多种识别手段，从 布局视觉、文本语义、图像特征、经验规则 的层面实现逻辑的判别，并补充必要的额外信息供逻辑表达使用。这些对模块逻辑进行识别的程式我们命名为 逻辑识别器。
每一个识别器都会基于自身擅长的领域给出鉴别结果，通过全方位的检索视觉稿，达到近似人工思考的目的。

步骤三：如何表达逻辑？
逻辑表达依赖于两个要素：逻辑的表达形式和逻辑的具体内容。

思考一：“逻辑以何种形式表达？”
为了明确逻辑的表达形式，我们 D2C 需要一个可承载智能化成果的场景，具体到实现上就是 一套承载智能化成果的协议 和 一个智能化干预平台。
imgcook （D2C 能力落地应用）结合 react、vue 等优秀的前端框架，参考各种竞品，实现了一套简版的基于数据驱动（Ui = render(Data) ）的生命周期，并希望用户能基于此规范进行组件的开发和编写。
(imgcook 自定义生命周期)
阿里淘系营销于 2019 年将营销模块规范升级到了基于 hooks 的 rax1.0 体系，imgcook 针对新的组件规范，实现了 mobile 和 PC 各一套的代码生成服务。这样开发者在 hooks 下也有生命周期可以使用，对开发者来说，不需要关心模块是 hooks 还是其他技术方案，只需要认准 imgcook 规定的模块开发方式就可以。
(imgcook 天马模块项目结构组织图)
约束了用户的编码规范之后，imgcook 提供了可视化的操作来实现代码。imgcook IDE 目前可实现大部分静态模块的可视化编写，下面是模块逻辑可视化高频操作的面板：
(imgcook 可视化面板【内部版】)
以淘系营销中的典型需求举例，在 imgcook 的可视化编辑器内，我们通常会这样实现（假定模块当前数据是一个单循环一排二商品模块，循环迭代对象 item）

为节点的价格绑定数据：点击 节点属性 -> 数据 -> 新增一个数据绑定，值为 item.itemActPrice。
模块不足一行的时候进行截断：点击 快速设置 -> 代码编写 -> 新增一个方法 -> 编写截断代码，将 items 的长度不被 2 整除的数据去除。
埋点逻辑：普通埋点需要 点击节点属性 -> 类型切换为 埋点链接，点击新增一个数据绑定，增加 data-track-type、exp-type等属性，并为其增加数据绑定；主会场实时埋点在做节点类型转换和数据绑定之余，还需要在循环节点里新增一个用于实时曝光的节点，其曝光类型需要设定为实时曝光。
加载更多：下滑式加载更多需要为模块增加曝光事件，事件句柄里编写加载更多代码。点击加载更多需要为模块增加点击事件，事件句柄里编写加载更多代码
…

对各个逻辑的操作步骤进行抽象化梳理，得出了如下逻辑实现步骤：
(逻辑实现步骤抽象梳理)
表格里每一个列都是 imgcook IDE 一类抽象化的能力，可见大部分逻辑都可以通过配置的形式来实现。由于大规模业务逻辑的营销模块较少，所以我们决定基于复用而不是基于推测来生成函数算子，仅使用执行顺序和是否有返回值来控制流程，更为细粒度的算数、逻辑操作符和流程控制语句暂不在我们的考虑范围内。

思考二：“逻辑以何种内容填充？”
可视化和真实代码之间的媒介就是 imgcook 的协议，接下来我们就需要实现协议的自动化生成。
自动化的协议生成的核心是 内容。节点将执行何种操作不是关键，要绑定到哪个节点、生成的代码里面内容 才是关键。为此，我们逻辑识别器执行时会将当前处理过程涉及到的节点信息、全局变量、人工配置等内容进行传递，在逻辑表达的运行时里执行注入，这些当前逻辑要表达清晰准确所必需的数据在 D2C 业务逻辑层里被命名为 逻辑上下文。
下面来看一些真实的 逻辑上下文：
逻辑一：为节点绑定活动价
// “逻辑上下文”
const recognizeResult = {
element: “Text_0”, // 哪个节点需要绑定数据
meta: {
expression: “item.itemActPrice” // 绑定具体表达式是什么
}
}
复制代码// 最终翻译到 imgcook 协议里的示例协议（imgcook 私有协议里将数据绑定都提到了最外层节点统一管理）
const layoutJson = {
id: “root节点”,
children: […], // 节点树🌲
dataBindStore: [
{
belongId: “Text_0”, // {{element}}
value: {
isStatic: false,
expression: “item.itemActPrice” // {{meta.expression}}
}
}
]
…
}
复制代码逻辑二：不足一行截断渲染数组**此逻辑函数内容是一个可复用的 xtpl 模板，可以直接访问 recognizeResult 作为渲染上下文。
// “逻辑上下文”：scope 是逻辑层核心分析页面布局的处理结果之一，每个逻辑上下文都可访问
const recognizeResult = {
“element”: null, // 此逻辑没有挂载节点
“meta”: {}, // 此逻辑也不需要额外参数
“scope”: {
“gSize”: 2, // 当前模块是一个 1排2 模块，不满足 2 个的行将被删除
“loop”: “items”, // 当前模块以 data.items 这个数组属性做循环
“loopArgs”: “item”, // 循环内部迭代对象名为 item
}
}
复制代码// 最终翻译到 imgcook 私有协议里的函数里的示例协议
const layoutJson = {
id: “root节点”,
children: […], // 节点树🌲
scirptStore: [
{
content: ... {{~#if (ctx.userLogicConfig.sliceFloor)}} // 掉坑处理，根据用户是否使用 sliceFloor 来使用 const count = Math.floor(data.{{scope.loop}}.length / gSize) * gSize; {{scope.loop}} = data.{{scope.loop}}.slice(0, count); {{~/if}} ...,
name: “getModuleRows”, // 截断逻辑写在拆行函数里
type: “custom”
}
]
…
}
复制代码使用渲染上下文可以在最终要增加的协议中“占坑”，实现协议的准确表述。
通过冗长的分析，我们业务逻辑智能生成的命题已经细化到了 如何运用智能化能力识别逻辑并产出上下文 和 基于上下文实现逻辑自动化表达 两点上了。这两点确认可行后，我们开始进行正式设计。

智能逻辑层设计

方案概述
根据对命题完整的推导，我们已经有了业务逻辑层能力的完整轮廓。
逻辑识别 + 逻辑表达 = 逻辑意图逻辑识别器需要您根据实际场景决定使用何种方式来执行识别。此阶段接收视觉稿和人工规则，输出为识别结果。类比人的思考过程，D2C 此时已经 “确认了模块的需求”。
逻辑表达器是 imgcook 可视化操作的预置版，将识别结果进行翻译，将此条逻辑带来的影响直接表现在最终的模块上。类比人的思考过程，D2C 此时已经 “写完了这个需求”。
(D2C 业务逻辑层能力)

功能划分
基于上述推导过程和职责界定，我们将业务逻辑层划分为 逻辑识别、逻辑表达、逻辑核心 等模块。

逻辑识别 提供智能化能力统一接入，确保业务逻辑可以被指定识别器准确识别 并 产出统一逻辑上下文。
逻辑表达 负责对逻辑进行可视化协议的配置，能自动应用逻辑上下文，在逻辑被识别出来之后自动表现到模块上。
逻辑层核心部分 提供两者的串联整合和扩展能力，比如 执行时序控制、布局模式支持、兜底 VO（View Object） 生成、逻辑上下文注入、人工干预等。从全局把控整个静态设计稿逻辑化的过程。
Libs 提供基础能力，一部分供核心调用，一部分可在逻辑上下文中供识别函数调用。

(D2C 业务逻辑层结构图)
前文也说过，D2C 试点的是阿里内部淘系营销领域，为了方便以后接入集团其他业务场景，我们有了附着于团队的 逻辑场景 概念。逻辑场景是解决一个业务域的逻辑合集，只要某个业务域下的业务逻辑可枚举、可规范、可定制，就可以构建自己的逻辑场景，方便自己的团队的其他同学进行模块开发。

逻辑核心功能拆解

布局模式识别
D2C 支持对 一排N 类型模块，横向纵向循环 和 任意层级的循环嵌套这些布局的识别，覆盖营销域下大部分的静态模块布局。值得注意的是，D2C 对设计稿的规范程度要求较高，在双11这种级别的活动里对模块布局还原准确度的要求必须是 100%，这就要求智能化必须有规则化做兜底。为此我们升级了 D2C 设计稿协议，您可以在设计稿上用标注的形式规整设计稿，确保布局还原结构准确、循环检测正常。
(D2C 已支持的布局模式)

视图模型推演
智能化的前提是标准化。D2C 识别出的视图需要和 数据模型（schema）映射上才可以正常表达逻辑。对模块视图布局识别的过程中 D2C 会同步检索 schema，确保循环层级和每一层的字段能对应上。然而现阶段开发者不能保证模块具有成型的 schema，为此 imgcook 实现了视图模型推演，在没有 schema 时能自动推测出模型，确保仅从视觉稿视角出发的 D2C 也是一个完备的体系。
推演是一个构建数据模型树的过程，在布局结构的过程中，我们将循环布局视作枝干，将每个触发绑定数据绑定的节点视作枝干的叶子，叶子的具体内容从淘系过往模块数据聚合结果中获取。

渲染上下文注入
函数识别器和视图表达器是逻辑层两个基于 node VM 执行函数的地方，从接口定义上可以看来他们之间的联系。函数识别器
// 函数识别器入参
export interface LayoutJson {
children: LayoutJson[];
style: any;
}
export interface LayoutResult {
ctx: Ctx, // 开发上下文。略
scope: Scope, // 全局变量。略
UserLogicConfig: UserLogicConfig, // 用户输入。略
}
export interface Options {
utils: Utils, // 工具方法。略
_: any, // lodash // https://www.lodashjs.com/docs/latest
}
// 函数识别器出参（仅在有识别结果时输出）
export interface RecognizeResult {
order: number; // 当本次逻辑需要表达顺序控制的时候，将按照 order 自小到大排列
element: number; // 本次逻辑挂载的节点 id
meta?: any; // 其他识别结果
}
复制代码视图表达器
// 视图表达器入参
export interface LayoutJson {
// 同 识别器入参一
}
export interface RecognizeResult {
// 识别器的出参
}
export interface Options {
// 同 识别器的入参三
}
// 视图表达器出参
export interface ViewResult {
layout: LayoutJson // 处理后的布局 json
}
复制代码
函数算子时序控制
实际场景中，需要经由 D2C 自动化生成的编码相关的逻辑较少。我们采用时序和是否有返回值来做简单数据流向控制。流程控制只会出现在生命周期事件或节点事件的句柄函数里，举个例子，假设我们有三个逻辑需要在 created 里面实现，分别是：“向循环数组塞入一个图片”、“根据一排几来截断数组” 和“发送一个曝光埋点”。那么通过配置顺序和是否有返回值，我们可以得到这样的 created 函数。
function created() {
let data = this.get();
// created-flow // created 流程开始
data = this.addImage(data); // 顺序为 1，有返回值
data = this.sliceArray(data); // 顺序为 2，有返回值
this.expTrack(data); // 顺序为 3，无返回值

return data;

}
export default created;
复制代码
人工干预
我们也知道，许多逻辑是无法通过 设计稿Design 获取到信息的。为了解决这种无特征逻辑的生成，我们加入了人工干预来进行协调。协调方式一是 参数问询：定义自定义表单获取用户的输入，在内部链路的 layoutResult.userLogicConfig 中访问。协调方式二是 逻辑过滤：每个逻辑的配置都有 开发者干预 选项，勾选之后，模块开发者有权对此逻辑进行屏蔽。这些管控措施都会体现在模块还原的询问弹窗上，若不了解弹窗内容的具体意图，需要联系当前逻辑场景的负责人。
(D2C 开发问询面板)

逻辑识别器一览
逻辑识别器是一个 N 选一的配置方式，对于一个逻辑，我们有如下图示来引导用户使用正确的识别器：(选择一个正确的 D2C 逻辑识别器)

1. UI 物料识别器

特点：

使用 xgboost 算法对模块中含有逻辑的视觉特征节点进行识别，相较于随机森林算法在我们的数据集上表现更优越
适用于子组件视觉特征足够明显，逻辑组件具有一定复杂性的场景
物料识别器本质是一个分类器，只告诉管理员某个节点是某个逻辑的载体。而不会告诉更多信息
当 UI 物料识别器不满足预期时，可以使用 设计稿注入协议 来进行此条逻辑的兜底

2. NLP 文本识别器

特点：

基于ALiWs 的分词算法和朴素贝叶斯多分类实现文本分类模型。对您输入的文本样本进行训练，有助于您对自己问题域下文本进行有效归类。
当您拥有大规模文本体量时，推荐用此方法进行文本的分类
含有 内置识别结果，涵盖不方便走文本NLP训练链路的一些常用分类。比如：价格、原价、商品图、白底图等。

3. 自定义函数识别器

特点：

当目标逻辑可以通过 javascript 代码 分析样式、结构、文字等信息的方式识别出时使用
在没有样本训练 UI物料识别器 和 NLP文本识别器 的情况下，它是一个比较不错的逻辑库建设方案
函数识别器可接收用户传参来做逻辑决策。比如 天猫 业务场景下对于埋点有两套截然不同的逻辑表述，我们可以编写两个埋点逻辑，在各自的识别函数里做二选一。除此之外，函数识别器可以攫取组件树信息，给逻辑表达器提供更为强大的逻辑上下文

4. 默认识别器：

特点：

默认逻辑会被所有模块应用，它的逻辑识别结果永远为 true
用于一些视觉层面没有特征的、较为通用的逻辑
多与 “开发者干预” 配套使用，由开发者决策是否使用
默认识别器无法获取组件树信息，如果有攫取信息的需求请移步 函数识别器

5. 正则识别器
   是 NLP 的正则分析版，能力是 NLP 识别的子集。

逻辑表达器一览
逻辑表达器是多个抽象化的子表达器组合的结果。我们将一个逻辑的实现方式拆解为最细粒度的可视化操作，通过分析此逻辑的具体实现方式，依次在后台配置表达式，进行逻辑组装。当识别器告知表达器当前逻辑激活时，则自动化实现该条逻辑的代码。(逻辑表达器功能划分)

1. 视图子表达器

可以处理视图层面的变更，能力极强，理论上可以覆盖其他所有表达器的能力。未来 imgcook 希望对视图操作也进行可视化配置，所以希望视图表达器只关注视图层面的变化，职责划分明确，不要涉足其他表达器的能力范畴
此表达器接收一个被 vm 执行的视图处理函数

2. 数据绑定子表达器

可以新增一条标准数据绑定，自动去重。大部分时候都需要借助逻辑上下文内的属性做动态表达
此表达器接收一条数据绑定的配置

3. 事件绑定子表达器

可以新增一个事件绑定，此事件会默认带一个事件执行句柄，每个事件执行句柄内部可以用函数算子填充流程。
此表达器接收一条事件绑定的配置

4. 函数算子子表达器

构造一个自定义方法，并决定在哪个句柄里调用。一般来说，函数算子只能在事件执行句柄和生命周期函数的流程中被调用，并通过排序和是否有返回对象来控制流程。
此表达器接收一个函数的配置，内容可使用 xtemplate 语法编写

5. 依赖管理子表达器

在前几个子表达器需要引入三方依赖的时候使用
此表达器接收一个依赖的注入

落地成效

双11逻辑场景建设
本次双11模块的开发中，基于本文提及的智能逻辑链路，imgcook 构建出了一套淘系营销活动独有的业务逻辑场景。内置了基于 淘系营销视觉规范的边距设置逻辑、基于淘系营销埋点规范的埋点逻辑、基于 rax-hooks solution 的模块渲染拆行逻辑等 默认逻辑。除此之外，结合文本NLP、UI 物料分类算法等识别器提供的智能化能力，配置了大量的数据绑定、组件识别的逻辑，当开发者视觉稿中含有此类特征时会自动将逻辑代码运用到结果上。
(D2C 双11逻辑场景【内部版】)

双11逻辑还原指标
根据统计，2019 双11有 78.94% 左右模块使用 imgcook 业务逻辑生成链路，生成的模块代码有 79.34% 数量留存至此次还原之后的上线代码中，平均命中的业务逻辑数量约为 14，也就是说平均每个基于 D2C 新链路开发的新模块帮开发者少写了至少十几条逻辑。在弱逻辑的静态 UI 的模块上，相关指标更高。以下方模块举例，基本可达到一键还原至可提测状态，大大减轻了开发者的工作量。
(D2C 双11逻辑命中示例【内部版 imgcook WEBIDE 开发链路】)

未来展望

当前不足
在双11 落地的过程中也暴露了很多问题，比如流程不够友好，淘系模块开发流程是 需求->设计稿->模块开发->前后端联调->模块上线。作为一个为设计稿赋予逻辑，使其直接转为可上线模块的全新理念的体系，没有为之预留的开发时间。当下我们通过加大人力在开发前提前介入来弥补上述不足，未来我们将会把需求和设计稿的产出过程都纳入业务逻辑层范畴，对于可支持的模块提供一站式研发闭环体验。设计师负责设计UI，PD基于UI添加需求，开发负责在后台维护可用逻辑。结合团队未来趋势，D2C 在业务逻辑领域的实战经验将在未来有效的助力整个体系。