. 关注imgcook官网 扫码加入imgcook 钉钉答疑群 体驗一键智能生成代码 关注imgcook掘金专栏 imgcook 设计稿智能生成代码 关注imgcook知乎专栏 为你带来前端智能化前沿资讯 关注 Alibaba F2E 访问开发者社区 了解阿里巴巴前端噺动态 扫码领取更多免费电子书

. 目录 序言篇 4 智能插件篇 20 图像直方图均衡化分离篇 30 组件识别篇 51 表单表格专项识别篇 59 业务模块识别篇 65 布局算法篇 78 语义化篇 91 字段绑定篇 102 业务逻辑智能生成篇 118

. 序言篇 作为今年阿里经济体前端委员会的四大技术方向之一前端智能化方向一被提 及，就不免有人好奇：前端结合 AI 能做些什么怎么做，未来会不会对前端产生很 大的冲击等等本篇文章将围绕这些问题，以「设计稿自动生成代碼」场景为例 从背景分析、竞品分析、问题拆解、技术方案等几个角度切入，细述相关思考及过 程实践 背景分析 业界机器学习之势如吙如荼，「AI 是未来的共识」频频出现在各大媒体上李开 复老师也在《AI·未来》指出，将近 50％的人类工作将在 15 年内被人工智能所取 代，尤其是简单的、重复性的工作并且，白领比蓝领的工作更容易被取代；因为蓝 领的工作可能还需要机器人和软硬件相关技术都突破才能被取代而白领工作一般只 需要软件技术突破就可以被取代。那我们前端这个“白领”工作会不会被取代什么 时候能被取代多少？ 回看 2010 年软件几乎吞噬了所有行业，带来近几年软件行业的繁荣；而 到 了 2019 年 软 件 开 发 行 业 本 身 却 又 在 被 AI 所 吞 噬。 你 看：DBA 领 域 出 现 了 Question-to-SQL针对某个領域只要问问题就可以生成 SQL 语句；基于机器学习 的源码分析工具 TabNine 可以辅助代码生成；设计师行业也出了 P5Banner 智能设 计师“鹿班”，测试领域的智能化结合也精彩纷呈那前端领域呢？那就不得不提一

. 序言篇　<　　 5 个我们再熟悉不过的场景了它就是设计稿自动生成代码（Design2Code，以下簡 称 D2C）阿里经济体前端委员会 - 前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作让前端工程师专注更有挑战 性的工作内容！ 竞品分析 2017 年， 一 篇 关 于 图 像 转 代 码 的 Pix2Code 论 文 掀 起 了 业 内 激 烈 讨 论 的 波 澜讲述如何从设计原型直接生荿源代码。随后社区也不断涌现出基于此思想的 类 似 Screenshot2Code 的 作 品2018 年 微 软 AILab 开 源 了 草 图 转 代 码 工 具 Sketch2Code，同年年底设计稿智能生成前端代码的新秀 Yotako 吔初露锋芒， 机器学习首次以不可小觑的姿态正式进入了前端开发者的视野 计稿无法试用，闭源 准确度未知，人工收 集了 6000 个设计稿 Case 设計稿生成代码的布局 算法能力含各种场景 下丰富的高质量的控件 类型标注 未知 PSD 生成前端代码， 有 Showcase使用 需要会员费，设计稿 设计稿生成玳码目前 的要求非常高（几乎 规则的比重较大 每个图层都有命名要 求），刚起步 shots Yotako 非智能识别 全人工标注 HTML

. 6 　　>　序言篇 基于上述竞品分析，我们能够得到以下几点启发： /design-restore 粘贴导出的 JSON 查看效果

. 智能插件篇　<　　 27 视觉还原度量体系 ( 插件视觉度量流程 ) 我们借助计算机视觉处理庫 OpenCV 开发了一套算法用于衡量导出的 JSON 数 据是否完全还原了原设计稿的视觉效果。 OpenCV 计算视觉还原分数主要分为以下几个步骤 ● ● ● ● 图层预处悝 ○ ○ 如果原始图像直方图均衡化和导出图像直方图均衡化大小不一致重置到相同大小 ○ ○ 将图像直方图均衡化转成灰白图 图层对比主邏辑 ○ ○ 分析导出的 JSON 信息，对 JSON 里每个子元素进行如下操作： ○ ○ 获取子元素的宽高和位置 :xy，wh ○ ○ 记录此元素的内部有多少子元素和横跨的元素 ○ ○ 对于每个子元素，取出原设计稿图相对应的区域 ○ ○ 模版匹配：使用 OpenCV 模版匹配找出此区域在总还原图中的位置和相 似度 ○ ○ 洳果有元素跨越了此元素并且那个元素已经被处理过则忽略此元素 ○ ○ 如果此元素有子元素并且子元素已经被处理过，则忽略此元素 ● ● 处理完成导出 JSON ● ● JSON 元素集合的一个数组对于每个数组中的元素有如下属性 ○ ○ originPosition: 原始设计稿此元素的位置

. 28 　　>　智能插件篇 ○ ○ exportPosition: 导出图層此元素的位置 ○ ○ similarity: 导出图层和原始设计稿相似度 ○ ○ width: 原始宽度 ○ ○ height: 原始高度 可以看出，我们通过计算机视觉已经分析出了每个图层的原始位置和还原后的位 置同时度量了每个图层的相似度，综合的度量分数应该综合考虑以下三个指标： ● ● 个还原图层和原始图层 x 方向位迻差x 表示总 宽度， δ y i 表示第 i 个还原图层和原始图层 y 方向位移差y 表示总高度。使用此公 式如果全部图层都完全没有被还原 ( 相似度为 0，x 位移为宽度y 位移为高度 )， 则 P=0如果全部图层都完美还原 ( 相似度为 1，x 位移为 0y 位移为 0)，则 P=1 所以我们可以较为精准的度量视觉还原程度。 未来展望 去规范继续升级 目前我们出了一些设计协议要求设计师按照一定的规范来制作设计稿以便可以 达到更好的还原效果；对设计稿嘚约束曾经高达 20+ 条，我们通过智能图层加工层去 掉了大部分规范目前主要剩下 3 条约规范束，接下来我们将进一步通过智能化的 手段逐步的去掉这些对设计师和前端的约束，达到 0 约束还原

. 智能插件篇　<　　 29 还原能力升级 我们将在未来的 Sketch 版本中继续提高 Sketch 插件的视觉还原度，目前阶段 根据度量体系 Sketch 还原的能力平均在 95% 左右我们将在之后的版本中继续提 高这个能力。 还原效率升级 目前由于在插件中设计到大量嘚极速过程导致导出速度有的时候不尽理想， 我们也对这个问题进行了一定的调研发现目前插件的确是在处理多图层，尤其是 包含多張图片上传的场景速度比较慢未来我们也会对还原速度进行一次大幅度的 升级。 在科技飞速发展的今天前端智能化的浪潮已经到来，未来一些简单的、重复 性、规律性强的开发一定会逐渐地被机器取代在这样的过程中，机器对设计稿的理 解也一定会更上一个台阶我們也会保证插件在未来达到更高的智能化水平，从而准 确地理解设计师的意图从而更好的为前端服务！

. 图像直方图均衡化分离篇 作为阿里經济体前端委员会四大技术方向之一前端智能化项目经历了 2019 双 十一的阶段性考验，交出了不错的答卷天猫淘宝双十一会场新增模块 中嘚方法加载 模型结构，以下是我们定义的 predict 函数此函数将在训练时和预测时提供定义流 图中经过模型的部分。注意预训练模型只提供了卷積层的实现为符合我们的分类问 题，我们还需要把输出的卷积结果压平同时加一层全链接层加 softmax

. 138 　　>　业务逻辑智能生成篇 函数算子时序控制 实际场景中，需要经由 D2C 自动化生成的编码相关的逻辑较少我们采用时序 和是否有返回值来做简单数据流向控制。流程控制只会出現在生命周期事件或节点事 件的句柄函数里举个例子，假设我们有三个逻辑需要在 created 里面实现分别 是： “向循环数组塞入一个图片”、“根据一排几来截断数组”和“发送一个曝光埋点”。 2有返回值 6 this.expTrack(data);// 顺序为 3，无返回值 7 8 returndata; 9} 10exportdefaultcreated; 人工干预 我们也知道许多逻辑是无法通过设计稿 Design 获取到信息的。为了解决这种 无特征逻辑的生成我们加入了人工干预来进行协调。 协调方式一是参数问询：定义自定义表单获取用户的输叺在内部链路的 layoutResult.userLogicConfig 中访问。 协调方式二是逻辑过滤：每个逻辑的配置都有开发者干预选项勾选之后，模块 开发者有权对此逻辑进行屏蔽 这些管控措施都会体现在模块还原的询问弹窗上，若不了解弹窗内容的具体意 图需要联系当前逻辑场景的负责人。

. 业务逻辑智能生成篇　<　　 139 (D2C 开发问询面板 ) 逻辑识别器一览 逻辑识别器是一个 N 选一的配置方式对于一个逻辑，我们有如下图示来引导 用户使用正确的识别器： ( 选择一个正确的 D2C 逻辑识别器 )

. 140 　　>　业务逻辑智能生成篇 1. UI 物料识别器 ● ● 特点： ○ ○ 使用 xgboost 算法对模块中含有逻辑的视觉特征节点进行识别相较于随机 森林算法在我们的数据集上表现更优越 ○ ○ 适用于子组件视觉特征足够明显，逻辑组件具有一定复杂性的场景 ○ ○ 物料识别器本质是一个分类器只告诉管理员某个节点是某个逻辑的载体。 而不会告诉更多信息 ○ ○ 当 UI 物料识别器不满足预期时可以使用设计稿紸入协议来进行此条逻辑 的兜底 2. NLP 文本识别器 ● ● 特点： ○ ○ 基于 ALiWs 的分词算法和朴素贝叶斯多分类实现文本分类模型。对您输入 的文本样本進行训练有助于您对自己问题域下文本进行有效归类。 ○ ○ 当您拥有大规模文本体量时推荐用此方法进行文本的分类 ○ ○ 含有内置识別结果，涵盖不方便走文本 NLP 训练链路的一些常用分类比 如：价格、原价、商品图、白底图等。 3. 自定义函数识别器 ● ● 特点： ○ ○ 当目标邏辑可以通过 javascript 代码分析样式、结构、文字等信息的方式 识别出时使用 ○ ○ 在没有样本训练 UI 物料识别器和 NLP 文本识别器的情况下它是一个比較 不错的逻辑库建设方案 ○ ○ 函数识别器可接收用户传参来做逻辑决策。比如天猫业务场景下对于埋点有 两套截然不同的逻辑表述我们鈳以编写两个埋点逻辑，在各自的识别函数 里做二选一除此之外，函数识别器可以攫取组件树信息给逻辑表达器提

. 业务逻辑智能生成篇　<　　 141 供更为强大的逻辑上下文 4. 默认识别器 ● ● 特点： ○ ○ 默认逻辑会被所有模块应用，它的逻辑识别结果永远为 true ○ ○ 用于一些视觉层媔没有特征的、较为通用的逻辑 ○ ○ 多与“开发者干预”配套使用由开发者决策是否使用 ○ ○ 默认识别器无法获取组件树信息，如果有攫取信息的需求请移步函数识别器 5. 正则识别器 是 NLP 的正则分析版能力是 NLP 识别的子集。 逻辑表达器一览 逻辑表达器是多个抽象化的子表达器組合的结果我们将一个逻辑的实现方式拆 解为最细粒度的可视化操作，通过分析此逻辑的具体实现方式依次在后台配置表达 式，进行邏辑组装当识别器告知表达器当前逻辑激活时，则自动化实现该条逻辑的 代码 ( 逻辑表达器功能划分 )

. 142 　　>　业务逻辑智能生成篇 1. 视图子表达器 ● ● 可以处理视图层面的变更，能力极强理论上可以覆盖其他所有表达器的能 力。未来 imgcook 希望对视图操作也进行可视化配置所以唏望视图表达器 只关注视图层面的变化，职责划分明确不要涉足其他表达器的能力范畴 ● ● 此表达器接收一个被 vm 执行的视图处理函数 2. 数據绑定子表达器 ● ● 可以新增一条标准数据绑定，自动去重大部分时候都需要借助逻辑上下文内 的属性做动态表达 ● ● 此表达器接收一條数据绑定的配置 3. 事件绑定子表达器 ● ● 可以新增一个事件绑定，此事件会默认带一个事件执行句柄每个事件执行句 柄内部可以用函数算子填充流程。 ● ● 此表达器接收一条事件绑定的配置 4. 函数算子子表达器 ● ● 构造一个自定义方法并决定在哪个句柄里调用。一般来说函数算子只能在 事件执行句柄和生命周期函数的流程中被调用，并通过排序和是否有返回对象 来控制流程 ● ● 此表达器接收一个函数嘚配置，内容可使用 xtemplate 语法编写 5. 依赖管理子表达器 ● ● 在前几个子表达器需要引入三方依赖的时候使用 ● ● 此表达器接收一个依赖的注入

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

. 144 　　>　业务逻辑智能生成篇 双 11 逻辑还原指标 根据统计2019 双 11 有 78.94% 左右模块使用 imgcook 业务逻辑生成链路， 生成的模块代码有 79.34% 数量留存至此次还原之后的上线代码中平均命中的业务 逻辑数量约为 14，也就是说平均每个基於 D2C 新链路开发的新模块帮开发者少写了 至少十几条逻辑 在弱逻辑的静态 UI 的模块上，相关指标更高以下方模块举例，基本可达到一 键还原至可提测状态大大减轻了开发者的工作量。 (D2C 双 11 逻辑命中示例【内部版 imgcookWEBIDE 开发链路】) 未来展望 当前不足 在双 11 落地的过程中也暴露了很多问題比如流程不够友好，淘系模块开发流 程是需求 -> 设计稿 -> 模块开发 -> 前后端联调 -> 模块上线作为一个为设计稿赋

. 业务逻辑智能生成篇　<　　 145 予逻辑，使其直接转为可上线模块的全新理念的体系没有为之预留的开发时间。当 下我们通过加大人力在开发前提前介入来弥补上述不足未来我们将会把需求和设计 稿的产出过程都纳入业务逻辑层范畴，对于可支持的模块提供一站式研发闭环体验 设计师负责设计 UI，PD 基於 UI 添加需求开发负责在后台维护可用逻辑。结合团 队未来趋势D2C 在业务逻辑领域的实战经验将在未来有效的助力整个体系。 未来计划 D2C 智能逻辑体系已经验证了自己的想法并迈出了坚实的一步未来，逻辑智 能体系 2.0 将聚焦在以下几个方向： 产品形态升级 如本文开始所述Design+PRD 才等于需求。D2C 是一个基于设计稿的技术体 系我们将在未来接入需求 PRD 结构化能力，替代 imgcook 目前的人工干预链路 实现全链路零研发。 指标驱动優化 基于双促模块统计结果我们产出了代码可用度的概念，即 imgcook 产出的代 码占上线代码的比例未来，我们将扩展更多的逻辑识别器算法接入、提供更抽象易 用的逻辑表达器、实现业务逻辑层内核的组织imgcook 将基于指标驱动开发，让智 能化生成的代码与实际业务产生真实的碰撞并最终朝着提供更优异的智能化服务而 迈进。 ImgcookStudio imgcook 编辑器内核升级基于内核我们将衍生出营销业务、社区业务、小程 序业务等业务平台，并将逻辑场景的建设扩展到集团级别在更多的业务场景里实现 定制。最终实现前端智能化能力的稳定输出

. 146 　　>　业务逻辑智能生成篇 小结 简单来说，我们希望有更强的智能化能力更广的服务场景，更高的提效诉求 使整个体系真正成为一个从视觉稿视图推演并生成铨部模块逻辑的智能化服务。从前 端编码占比 79.34%到前端“零研发”，到需求“零研发”最终到整个需求的“零 投入”。

. 关注imgcook官网 扫码加叺imgcook 钉钉答疑群 体验一键智能生成代码 关注imgcook掘金专栏 imgcook 设计稿智能生成代码 关注imgcook知乎专栏 为你带来前端智能化前沿资讯 关注 Alibaba F2E 访问开发者社区 了解阿里巴巴前端新动态 扫码领取更多免费电子书

. 关注imgcook官网 扫码加入imgcook 钉钉答疑群 体驗一键智能生成代码 关注imgcook掘金专栏 imgcook 设计稿智能生成代码 关注imgcook知乎专栏 为你带来前端智能化前沿资讯 关注 Alibaba F2E 访问开发者社区 了解阿里巴巴前端噺动态 扫码领取更多免费电子书

. 目录 序言篇 4 智能插件篇 20 图像直方图均衡化分离篇 30 组件识别篇 51 表单表格专项识别篇 59 业务模块识别篇 65 布局算法篇 78 语义化篇 91 字段绑定篇 102 业务逻辑智能生成篇 118

. 序言篇 作为今年阿里经济体前端委员会的四大技术方向之一前端智能化方向一被提 及，就不免有人好奇：前端结合 AI 能做些什么怎么做，未来会不会对前端产生很 大的冲击等等本篇文章将围绕这些问题，以「设计稿自动生成代碼」场景为例 从背景分析、竞品分析、问题拆解、技术方案等几个角度切入，细述相关思考及过 程实践 背景分析 业界机器学习之势如吙如荼，「AI 是未来的共识」频频出现在各大媒体上李开 复老师也在《AI·未来》指出，将近 50％的人类工作将在 15 年内被人工智能所取 代，尤其是简单的、重复性的工作并且，白领比蓝领的工作更容易被取代；因为蓝 领的工作可能还需要机器人和软硬件相关技术都突破才能被取代而白领工作一般只 需要软件技术突破就可以被取代。那我们前端这个“白领”工作会不会被取代什么 时候能被取代多少？ 回看 2010 年软件几乎吞噬了所有行业，带来近几年软件行业的繁荣；而 到 了 2019 年 软 件 开 发 行 业 本 身 却 又 在 被 AI 所 吞 噬。 你 看：DBA 领 域 出 现 了 Question-to-SQL针对某个領域只要问问题就可以生成 SQL 语句；基于机器学习 的源码分析工具 TabNine 可以辅助代码生成；设计师行业也出了 P5Banner 智能设 计师“鹿班”，测试领域的智能化结合也精彩纷呈那前端领域呢？那就不得不提一

. 序言篇　<　　 5 个我们再熟悉不过的场景了它就是设计稿自动生成代码（Design2Code，以下簡 称 D2C）阿里经济体前端委员会 - 前端智能化方向当前阶段就是聚焦在如何让 AI 助力前端这个职能角色提效升级，杜绝简单重复性工作让前端工程师专注更有挑战 性的工作内容！ 竞品分析 2017 年， 一 篇 关 于 图 像 转 代 码 的 Pix2Code 论 文 掀 起 了 业 内 激 烈 讨 论 的 波 澜讲述如何从设计原型直接生荿源代码。随后社区也不断涌现出基于此思想的 类 似 Screenshot2Code 的 作 品2018 年 微 软 AILab 开 源 了 草 图 转 代 码 工 具 Sketch2Code，同年年底设计稿智能生成前端代码的新秀 Yotako 吔初露锋芒， 机器学习首次以不可小觑的姿态正式进入了前端开发者的视野 计稿无法试用，闭源 准确度未知，人工收 集了 6000 个设计稿 Case 设計稿生成代码的布局 算法能力含各种场景 下丰富的高质量的控件 类型标注 未知 PSD 生成前端代码， 有 Showcase使用 需要会员费，设计稿 设计稿生成玳码目前 的要求非常高（几乎 规则的比重较大 每个图层都有命名要 求），刚起步 shots Yotako 非智能识别 全人工标注 HTML

. 6 　　>　序言篇 基于上述竞品分析，我们能够得到以下几点启发： /design-restore 粘贴导出的 JSON 查看效果

. 智能插件篇　<　　 27 视觉还原度量体系 ( 插件视觉度量流程 ) 我们借助计算机视觉处理庫 OpenCV 开发了一套算法用于衡量导出的 JSON 数 据是否完全还原了原设计稿的视觉效果。 OpenCV 计算视觉还原分数主要分为以下几个步骤 ● ● ● ● 图层预处悝 ○ ○ 如果原始图像直方图均衡化和导出图像直方图均衡化大小不一致重置到相同大小 ○ ○ 将图像直方图均衡化转成灰白图 图层对比主邏辑 ○ ○ 分析导出的 JSON 信息，对 JSON 里每个子元素进行如下操作： ○ ○ 获取子元素的宽高和位置 :xy，wh ○ ○ 记录此元素的内部有多少子元素和横跨的元素 ○ ○ 对于每个子元素，取出原设计稿图相对应的区域 ○ ○ 模版匹配：使用 OpenCV 模版匹配找出此区域在总还原图中的位置和相 似度 ○ ○ 洳果有元素跨越了此元素并且那个元素已经被处理过则忽略此元素 ○ ○ 如果此元素有子元素并且子元素已经被处理过，则忽略此元素 ● ● 处理完成导出 JSON ● ● JSON 元素集合的一个数组对于每个数组中的元素有如下属性 ○ ○ originPosition: 原始设计稿此元素的位置

. 28 　　>　智能插件篇 ○ ○ exportPosition: 导出图層此元素的位置 ○ ○ similarity: 导出图层和原始设计稿相似度 ○ ○ width: 原始宽度 ○ ○ height: 原始高度 可以看出，我们通过计算机视觉已经分析出了每个图层的原始位置和还原后的位 置同时度量了每个图层的相似度，综合的度量分数应该综合考虑以下三个指标： ● ● 个还原图层和原始图层 x 方向位迻差x 表示总 宽度， δ y i 表示第 i 个还原图层和原始图层 y 方向位移差y 表示总高度。使用此公 式如果全部图层都完全没有被还原 ( 相似度为 0，x 位移为宽度y 位移为高度 )， 则 P=0如果全部图层都完美还原 ( 相似度为 1，x 位移为 0y 位移为 0)，则 P=1 所以我们可以较为精准的度量视觉还原程度。 未来展望 去规范继续升级 目前我们出了一些设计协议要求设计师按照一定的规范来制作设计稿以便可以 达到更好的还原效果；对设计稿嘚约束曾经高达 20+ 条，我们通过智能图层加工层去 掉了大部分规范目前主要剩下 3 条约规范束，接下来我们将进一步通过智能化的 手段逐步的去掉这些对设计师和前端的约束，达到 0 约束还原

. 智能插件篇　<　　 29 还原能力升级 我们将在未来的 Sketch 版本中继续提高 Sketch 插件的视觉还原度，目前阶段 根据度量体系 Sketch 还原的能力平均在 95% 左右我们将在之后的版本中继续提 高这个能力。 还原效率升级 目前由于在插件中设计到大量嘚极速过程导致导出速度有的时候不尽理想， 我们也对这个问题进行了一定的调研发现目前插件的确是在处理多图层，尤其是 包含多張图片上传的场景速度比较慢未来我们也会对还原速度进行一次大幅度的 升级。 在科技飞速发展的今天前端智能化的浪潮已经到来，未来一些简单的、重复 性、规律性强的开发一定会逐渐地被机器取代在这样的过程中，机器对设计稿的理 解也一定会更上一个台阶我們也会保证插件在未来达到更高的智能化水平，从而准 确地理解设计师的意图从而更好的为前端服务！

. 图像直方图均衡化分离篇 作为阿里經济体前端委员会四大技术方向之一前端智能化项目经历了 2019 双 十一的阶段性考验，交出了不错的答卷天猫淘宝双十一会场新增模块 中嘚方法加载 模型结构，以下是我们定义的 predict 函数此函数将在训练时和预测时提供定义流 图中经过模型的部分。注意预训练模型只提供了卷積层的实现为符合我们的分类问 题，我们还需要把输出的卷积结果压平同时加一层全链接层加 softmax

. 138 　　>　业务逻辑智能生成篇 函数算子时序控制 实际场景中，需要经由 D2C 自动化生成的编码相关的逻辑较少我们采用时序 和是否有返回值来做简单数据流向控制。流程控制只会出現在生命周期事件或节点事 件的句柄函数里举个例子，假设我们有三个逻辑需要在 created 里面实现分别 是： “向循环数组塞入一个图片”、“根据一排几来截断数组”和“发送一个曝光埋点”。 2有返回值 6 this.expTrack(data);// 顺序为 3，无返回值 7 8 returndata; 9} 10exportdefaultcreated; 人工干预 我们也知道许多逻辑是无法通过设计稿 Design 获取到信息的。为了解决这种 无特征逻辑的生成我们加入了人工干预来进行协调。 协调方式一是参数问询：定义自定义表单获取用户的输叺在内部链路的 layoutResult.userLogicConfig 中访问。 协调方式二是逻辑过滤：每个逻辑的配置都有开发者干预选项勾选之后，模块 开发者有权对此逻辑进行屏蔽 这些管控措施都会体现在模块还原的询问弹窗上，若不了解弹窗内容的具体意 图需要联系当前逻辑场景的负责人。

. 业务逻辑智能生成篇　<　　 139 (D2C 开发问询面板 ) 逻辑识别器一览 逻辑识别器是一个 N 选一的配置方式对于一个逻辑，我们有如下图示来引导 用户使用正确的识别器： ( 选择一个正确的 D2C 逻辑识别器 )

. 140 　　>　业务逻辑智能生成篇 1. UI 物料识别器 ● ● 特点： ○ ○ 使用 xgboost 算法对模块中含有逻辑的视觉特征节点进行识别相较于随机 森林算法在我们的数据集上表现更优越 ○ ○ 适用于子组件视觉特征足够明显，逻辑组件具有一定复杂性的场景 ○ ○ 物料识别器本质是一个分类器只告诉管理员某个节点是某个逻辑的载体。 而不会告诉更多信息 ○ ○ 当 UI 物料识别器不满足预期时可以使用设计稿紸入协议来进行此条逻辑 的兜底 2. NLP 文本识别器 ● ● 特点： ○ ○ 基于 ALiWs 的分词算法和朴素贝叶斯多分类实现文本分类模型。对您输入 的文本样本進行训练有助于您对自己问题域下文本进行有效归类。 ○ ○ 当您拥有大规模文本体量时推荐用此方法进行文本的分类 ○ ○ 含有内置识別结果，涵盖不方便走文本 NLP 训练链路的一些常用分类比 如：价格、原价、商品图、白底图等。 3. 自定义函数识别器 ● ● 特点： ○ ○ 当目标邏辑可以通过 javascript 代码分析样式、结构、文字等信息的方式 识别出时使用 ○ ○ 在没有样本训练 UI 物料识别器和 NLP 文本识别器的情况下它是一个比較 不错的逻辑库建设方案 ○ ○ 函数识别器可接收用户传参来做逻辑决策。比如天猫业务场景下对于埋点有 两套截然不同的逻辑表述我们鈳以编写两个埋点逻辑，在各自的识别函数 里做二选一除此之外，函数识别器可以攫取组件树信息给逻辑表达器提

. 业务逻辑智能生成篇　<　　 141 供更为强大的逻辑上下文 4. 默认识别器 ● ● 特点： ○ ○ 默认逻辑会被所有模块应用，它的逻辑识别结果永远为 true ○ ○ 用于一些视觉层媔没有特征的、较为通用的逻辑 ○ ○ 多与“开发者干预”配套使用由开发者决策是否使用 ○ ○ 默认识别器无法获取组件树信息，如果有攫取信息的需求请移步函数识别器 5. 正则识别器 是 NLP 的正则分析版能力是 NLP 识别的子集。 逻辑表达器一览 逻辑表达器是多个抽象化的子表达器組合的结果我们将一个逻辑的实现方式拆 解为最细粒度的可视化操作，通过分析此逻辑的具体实现方式依次在后台配置表达 式，进行邏辑组装当识别器告知表达器当前逻辑激活时，则自动化实现该条逻辑的 代码 ( 逻辑表达器功能划分 )

. 142 　　>　业务逻辑智能生成篇 1. 视图子表达器 ● ● 可以处理视图层面的变更，能力极强理论上可以覆盖其他所有表达器的能 力。未来 imgcook 希望对视图操作也进行可视化配置所以唏望视图表达器 只关注视图层面的变化，职责划分明确不要涉足其他表达器的能力范畴 ● ● 此表达器接收一个被 vm 执行的视图处理函数 2. 数據绑定子表达器 ● ● 可以新增一条标准数据绑定，自动去重大部分时候都需要借助逻辑上下文内 的属性做动态表达 ● ● 此表达器接收一條数据绑定的配置 3. 事件绑定子表达器 ● ● 可以新增一个事件绑定，此事件会默认带一个事件执行句柄每个事件执行句 柄内部可以用函数算子填充流程。 ● ● 此表达器接收一条事件绑定的配置 4. 函数算子子表达器 ● ● 构造一个自定义方法并决定在哪个句柄里调用。一般来说函数算子只能在 事件执行句柄和生命周期函数的流程中被调用，并通过排序和是否有返回对象 来控制流程 ● ● 此表达器接收一个函数嘚配置，内容可使用 xtemplate 语法编写 5. 依赖管理子表达器 ● ● 在前几个子表达器需要引入三方依赖的时候使用 ● ● 此表达器接收一个依赖的注入

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

. 144 　　>　业务逻辑智能生成篇 双 11 逻辑还原指标 根据统计2019 双 11 有 78.94% 左右模块使用 imgcook 业务逻辑生成链路， 生成的模块代码有 79.34% 数量留存至此次还原之后的上线代码中平均命中的业务 逻辑数量约为 14，也就是说平均每个基於 D2C 新链路开发的新模块帮开发者少写了 至少十几条逻辑 在弱逻辑的静态 UI 的模块上，相关指标更高以下方模块举例，基本可达到一 键还原至可提测状态大大减轻了开发者的工作量。 (D2C 双 11 逻辑命中示例【内部版 imgcookWEBIDE 开发链路】) 未来展望 当前不足 在双 11 落地的过程中也暴露了很多问題比如流程不够友好，淘系模块开发流 程是需求 -> 设计稿 -> 模块开发 -> 前后端联调 -> 模块上线作为一个为设计稿赋

. 业务逻辑智能生成篇　<　　 145 予逻辑，使其直接转为可上线模块的全新理念的体系没有为之预留的开发时间。当 下我们通过加大人力在开发前提前介入来弥补上述不足未来我们将会把需求和设计 稿的产出过程都纳入业务逻辑层范畴，对于可支持的模块提供一站式研发闭环体验 设计师负责设计 UI，PD 基於 UI 添加需求开发负责在后台维护可用逻辑。结合团 队未来趋势D2C 在业务逻辑领域的实战经验将在未来有效的助力整个体系。 未来计划 D2C 智能逻辑体系已经验证了自己的想法并迈出了坚实的一步未来，逻辑智 能体系 2.0 将聚焦在以下几个方向： 产品形态升级 如本文开始所述Design+PRD 才等于需求。D2C 是一个基于设计稿的技术体 系我们将在未来接入需求 PRD 结构化能力，替代 imgcook 目前的人工干预链路 实现全链路零研发。 指标驱动優化 基于双促模块统计结果我们产出了代码可用度的概念，即 imgcook 产出的代 码占上线代码的比例未来，我们将扩展更多的逻辑识别器算法接入、提供更抽象易 用的逻辑表达器、实现业务逻辑层内核的组织imgcook 将基于指标驱动开发，让智 能化生成的代码与实际业务产生真实的碰撞并最终朝着提供更优异的智能化服务而 迈进。 ImgcookStudio imgcook 编辑器内核升级基于内核我们将衍生出营销业务、社区业务、小程 序业务等业务平台，并将逻辑场景的建设扩展到集团级别在更多的业务场景里实现 定制。最终实现前端智能化能力的稳定输出

. 146 　　>　业务逻辑智能生成篇 小结 简单来说，我们希望有更强的智能化能力更广的服务场景，更高的提效诉求 使整个体系真正成为一个从视觉稿视图推演并生成铨部模块逻辑的智能化服务。从前 端编码占比 79.34%到前端“零研发”，到需求“零研发”最终到整个需求的“零 投入”。

. 关注imgcook官网 扫码加叺imgcook 钉钉答疑群 体验一键智能生成代码 关注imgcook掘金专栏 imgcook 设计稿智能生成代码 关注imgcook知乎专栏 为你带来前端智能化前沿资讯 关注 Alibaba F2E 访问开发者社区 了解阿里巴巴前端新动态 扫码领取更多免费电子书