微软开源了一个会画前端的AI

最新推荐文章于 2024-08-15 09:38:28 发布

KAMI说

最新推荐文章于 2024-08-15 09:38:28 发布

阅读量1.3k

点赞数

分类专栏：行业资讯文章标签：机器学习人工智能前端淘汰失业

本文链接：https://blog.csdn.net/ekansrm3/article/details/85223891

版权

行业资讯专栏收录该内容

1 篇文章 0 订阅

订阅专栏

摘要：机械重复的劳动一定会被自动化替代。新技术和新工具会给行业带来量变甚至质变的发展和机遇，只是从业门槛却会随之提高，有人得意有人出局。不过，人始终是一切价值的创造者和承载者，人类永不失业。

会画前端的Sketch2Code

先给大家讲个旧闻。8月29日。微软的AI实验室开源了一个AI辅助工具Sketch2Code，可以将手绘的UI草图转化为可用的HTML代码，能在浏览器上直接展示。

这里简单介绍一下前端开发的分工和流程。前端又称前台，指的是用户可见的可操作的可交互的部分。例如，浏览器上的页面，移动端应用，都属于大前端的范畴。

前端开发的流程和分工，粗浅可以分为用户界面设计和交互逻辑实现两部分。用户界面（User Interface, UI）设计主要包括页面元素样式和布局，例如按钮、输入框、图文框的数量，大小，位置等。交互逻辑实现则可以理解为实现页面元素的“反应”和“动作”，例如指针停留在某个标题需要弹出悬浮窗，点击登录按钮需要和调用后端接口进行登录，等等。

在用户界面设计阶段, 设计师和工程师会通过草稿展示自己的想法并讨论，当在某个设计上达成一致后，便需要通过手工编码把草稿实现为可以呈现为浏览器页面的HTML代码。

用户界面设计过程涉及创作，讨论，修改的反复迭代。将草稿通过手工coding转化为HTML代码这一过程较为机械和枯燥，但又需要耗费很多时间和精力，通常是设计过程的一大瓶颈。

微软AI实验室着眼这一痛点，和 Kabel、Spike Techniques 合作开发，推出了Sketch2Code解决方案，可将手绘草稿直接生成对应的HTML代码，让设计立即呈现在浏览器上。

按照他们的设想，在设计头脑风暴结束时，人们就可以拥有一个已经由设计师、开发人员甚至客户验证过的现成原型，可为前端设计和开发带来很大的便利。

Sketch2Code简介

sketch2code官网给出的动态Demo如下，可见识别和生成效果还不错，可以对付简单的页面设计。

从手绘草图到HTML 代码，Sketch2Code的工作过程如下：
· 用户将图片上传到网站上。
· 自定义视觉模型预测在图像中出现的 HTML 元素和其位置和边框。
· 手写文本识别服务读取预测元素中的文本。
· 布局算法根据预测元素的边框空间信息生成网格结构。
· HTML 生成引擎使用上述信息来生成 HTML 代码。

按照开发人员介绍，Sketch2Code 使用了以下组件：
· 微软自定义视觉模型（Custom Vision）：这个模型是基于不同的手绘稿的图像训练得出的，并标记了与常见 HTML 元素（如文本框、按钮、图像等）相关的信息。
· 微软计算机视觉服务：用于识别设计元素中的文本。
· Azure Blob Storage：保存与 HTML 生成过程的每个步骤相关的信息，包括原始图像、预测结果、布局和分组信息等。
· Azure Function：它作为后端入口点，通过与其他服务发生交互以协调生成过程。
· Azure Website：用户界面前端，用户可以在这里上载设计图，并查看生成的 HTML。

如果有兴趣了解更多细节，可前往sketch2code项目的官方网站和详细介绍（可能需要翻墙）。sketch2code已经开源至github, 想折腾的童鞋也可以去clone 下来，试着跑一下。

Sketch2Code亮点

在技术上，Sketch2Code的亮点是把转写过程分解成 “页面元素识别+文字识别->布局算法->代码生成”, 而不是试图设计或套用某种端对端模型。

如果走端对端模型的路，期待着把手绘草稿从一端塞进去，HTML代码就从另一端出来，估计把全球互联网上的网页和对应的设计草稿组成训练集，也训练不出这个模型。

这是因为，我们期待的输出，即HTML代码，实际上是语法规则约束下的解。相比于整个可能的解空间，受约束的解区间大大缩小，极可能都不同势。目前能用于生产的机器学习和深度学习技术，本质上是拟合出一个映射进行。在这种情况下，需要巨量样本才能让映射收敛到解空间。

转写过程分解后，页面元素识别和文字识别可用机器学习解决，目前都能找到可用于生产环境的成熟组件。同时，布局算法和代码生成本身早已有成熟解决方案，这让Sketch2Code的实现成为可能。

Sketch2Code会带来什么？

“切图仔”

之前还在阿里巴巴工作时，我也要负责些前端开发。阿里是个很神奇的地方，连DBA都会写前端。说白了是因为阿里的业务比较强势，业务推技术。需求急的时候，等前端工程师排期开发的话来不及，这个时候就只能自己上了。
不过，我们这些兼职前端大都只是用jQuery和React开发一些交互逻辑，最多会对页面样式和布局做些小调整。如果要大修改或者要开个新页面，那就得拜托组里的前端工程师大神了。这是因为，尽管HTML和CSS本身并不复杂，然而如果平时写得不多不熟练的话，开发时要不停查资料和文档，效率很低。
对于组里的前端工程师来说，这种的设计转代码的工作更多是个负担，他们更愿意花时间在用户界面设计和交互逻辑实现，这些更有创造性和技术含量。
组里前端工程师需要包揽前端开发的全部工作。不过在专门做前端开发的组，例如事业群的UED，分工会更细致些。除了专门画稿的设计大佬和写交互逻辑的工程师，还有人专门负责照着设计草稿用HTML和CSS写页面，他们经常戏称自己为“切图仔”。

显然，Sketch2Code做的就是“切图仔”的工作。客观来说，Sketch2Code能力还是较为简单，目前还不能处理太复杂的设计，对于PC端和移动端的兼容性等这些老需求，恐怕还是无能为力，离生产是有些距离的。如同很多人评论，许多切图软件的效果和功能比这个好多了，只是差一个手绘草稿识别而已。

玩具？噱头？

目前，Skech2Code这类带机器学习和深度学习概念自动化工具也许还是玩具和噱头，的确无须拔高，制造失业潮来临这种耸人听闻的消息。但是，更不建议轻视这类工具的发展。机械重复劳动早晚一定会被自动化所取代，这是工业革命以来验证无数次的铁律。将来，即使不是sketch2code，也会由其他工具实现。

前端要凉？

Sketch2Code这类工具若大规模走向生成应用，前端开发这个行业，不仅不凉，还会在效率和产量上大有发展，甚至进而在设计理念和用户体验上带来革新。有意思的是，前端的从业门槛不仅不会因此降低，反而可能会进一步提高。
就以Sketch2Code为例。若它能全面走向生产，对于要包揽所有工作的前端工程师来说是利好。因为他们可以从机械重复的切图工作解脱出来，将更多时间和精力花在更有价值的工作上。
对于专职UI设计或者交互逻辑实现的开发者来说也是好消息，减少了切图这个环节，开发流效率和产量更高，甚至可以从量变到质变。
然而，对于专职切图的开发者，这肯定是一个坏消息。“切图仔” 这个岗位，肯定是凉凉。如果没能转型，即使不是一夜失业，也只能像躲避洪水一般四处转移，生存和发展空间不断被挤压，越来越窘迫和潦倒。
在这个过程，门槛最低的切图被机器取代，前端的从业门槛自然就提高了。

#### 机器代人，有人欢喜有人愁

其他领域也是同样的道理。自动化和智能化的应用，一定会给行业带来新的发展和机遇。然而细化到具体分工岗位上，有人欢喜有人愁。
一些从事行业中低门槛岗位的从业者被替代，只能转型或失业。一些从事高门槛岗位的从业者却可以得到解放，得到更好的效率和产出，甚至因为行业成本降低，能分到更多蛋糕。

谁留下？

在当下这个机器智能大放异彩的时代，其实有两类工作还是很难被取代的。一种是低阶的体力劳动和服务业，例如助理、快递、外卖、保洁等。一种是高阶的、创造性和技术性较强的脑力工作，如设计师，艺术家，架构师，律师以及各种带“高级”两字的岗位。
前者入列可能出人意料。这类工作看似简单，然而，要完成一个工作任务，需要自然语言处理、自然语言理解、小样本流式学习、硬件自适应控制等等多种能力的配合。它们对标通用型人工智能，目前功能和目标单一的机器学习和深度学习模型无法胜任。
后者入列便理所当然。这些工作涉及到抽象和具象，逻辑和推断，创造和探索。目前连定义和量化这类工作的目标和成果都几乎做不到，更别说用机器去取代。

谁出局？

那么，相比之下，容易被现有的自动化技术取代的工作，一般有这些特征：

工作所属行业本身存在门槛，但在行业内的相对很低
工作目标单一、可量化，手段和操作机械重复
工作性质为“翻译”、“转写”和“映射”，而且规则明显、可描述
工作本身不需要创造和推断
工作过程中不需要互动和输入，不直接和需求方接触
前端开发行业中的“切图仔”，可以说是完全满足了以上特征，特别是第一条：“切图仔”有从业门槛，起码得懂开发，懂HTML和CSS，薪酬一般高于人均收入。若有成熟的自动化工具面世，出于人力成本的考虑，“切图仔”会被迅速汰换。

相似的工作还有靠套用模板的低级美工、小额贷款的信审、普通文书，等等。其实，里面有一个岗位，在几年前因为机器学习的成功应用，已经被全面淘汰和取代了。
如果你的工作满足上述大部分特征，尽早开始规划转型或提升，一定没有坏处。