2024前端智能化发展现状与未来展望

智能设计生成

智能 UI 设计模板

▐  沉淀智能化技术和产品能力，赋能业务智能化到智能业务化，释放技术及组织红利，驱动业务增长。

一些客户和业务方经常会问一个非常哲学的问题——什么叫“业务智能化”以及什么叫“智能业务化”。针对这个问题事实胜于雄辩，要基于场景去解释、去获得体感。简言之，这个任务的目的是希望通过一系列的产品矩阵和技术的矩阵，能够把这些产品和技术融到业务的体系里面去，而不是单纯从技术视角去定义一些技术产品。

智能 UI 业务定制

智能 UI 应用

方法论+工具+组织——构建基本理念和落地公式

▐  方法论：业务指标驱动的产品定义、技术生成、运营使用的业务研发模式

就像做开发一样，任何一套框架背后还是有一套基本的思想，思想背后有一套完善的理论体系，没有理论体系指导，我们无法在未来的复杂场景或者是在一些多变的场景中去抽象和裁剪。前端智能化技术&业务体系也一定有一套理论来支撑它：业务指标驱动（BizCook）、产品定义（BizCook & 鲸幂）、技术生成（P2C、D2C、S2C）、运营使用（小二工作台）四个部分组成。

首先，什么是业务指标驱动（BizCook）？今天阿里有淘宝、天猫、聚划算等很多业务，业务指标定义也很多样，即使指标是统一的，但是如果大家的业务场景都不一样，对用户活跃的定义理解也会不同，比如天猫 U 先的活跃要求用户领样品，而淘宝逛逛业务的活跃要求用户浏览内容和关注等。因此，业务指标的定义需要在各自业务场景中。而驱动则不然，可统一用聚焦（定义）、透明（传递）、迭代（执行）的模式。只有目标场景化、驱动统一了才能真正实现有效的业务研发模式升级，产生化学反应裂变或者衍生出更多的商业可能性。

其次，产品定义 (BizCook & 鲸幂)。产品定义是针对核心产品要素：UI 智能化资产，把各个场景里面，大家对该要素的各定义和理解抽象到一个共识的公约数：能够让每个场景中既有标准性，又能够兼顾灵活性，体验一致性上提供个性化。UI 智能化资产是数字化商业很重要的产品基础设施。就消费而言，一个产品可能会有超过二十个场景，一个场景会有数十个生活时空维度，一个维度会对应数百个圈层的用户，只有借助 UI 智能化资产，才能把产品定义好，让用户在自己兴趣偏好和习惯之下，体验到数字化商业的价值。由此，技术人员就能够和设计人员一起持续的用算法、数据资产进行融合，最终去还原我们对消费者的理解。当然，这是在安全隐私合规的前提下进行的，并且在前端智能化的端智能领域，将其规范化到统一的产品设计和定义领域去，保护用户隐私下传递抽象用户特征和场景特征的向量数据。

第三个是技术生成（P2C、D2C、S2C）。算法和数据在一起打造 UI 智能化资产，是为了 Service 。不提供服务的技术，就只有成本，也感觉不到技术的价值。UI 智能化资产的供给由服务驱动，再借助各业务的技术团队场景化、定制化落地，从而产生 UI 智能化资产的上层消费和底层供给之间的咬合。同时，从消费侧收集和回流数据，用指标驱动技术生成体系有目标且高效的迭代和成熟。

最后，是运营使用（小二工作台）。在业务指标驱动下，产品（产品力）、设计（设计力）和技术（业务力）共同协作，交付的只是产品的定义。这就像面向对象编程里，我们定义一个杯子：

• 交付产品定义：

class 杯子 {

init(材质、高度、直径……『运营使用的路径在这里』){

材质处理(『运营使用的结果在这里！』）

}

func 材质处理(材质){

if(材质==水晶){

1、检查水晶库存

2、测算水晶成本

3、……

……

}

}

}

• 运营使用：

『运营选品动作为例』

new 杯子（水晶、10cm、5cm……）『运营使用的起点在这里』

运营将产品、设计、技术围绕业务指标共同交付的产品定义：产品的可能性，例如材质可能是玻璃、也可能是水晶，运营再根据业务指标和库存、成本等状况决定，这次运营动作的具体参数是什么？

▐  工具：产品及解决方案

有了理论之后，第二步是建立一套工具承接理论。理论很多公司都能讲，如果没有一套好的工具，去把这个理论承接，能让这个理论延续、演进和演化，这个理论是无法落地的，所以方法论背后必须有一套工具。

组织换了、业务变了、人员离职转岗了……，只有工具和技术能力的产品化，才能让我们这个体系不断地站在前人的肩膀上前进。在阿里场景里面，通过实践最后沉淀下来了一套基本的前端智能化工具矩阵，如下图：

我们会用这些工具去服务阿里内部的各种业务，同时我们也会服务我们的商家和用户，为商家和 ISV 生态注入活力降低成本，为用户带来可预期、合品味、易使用的产品。

针对双十一等大促场景、营销产品和频道业务，用 UI 智能化资产统一实现“大促日常化”：降低大促的规划、设计、实施成本，统一实现“日常大促化”：用丰富的场景、人货场、个性化用户产品提高承接效率和业务效率，把日常的频道导购业务都变得像个“市集”。我们还会面向阿里巴巴集团全域 APP 矩阵进行业务投放，和流量场景深度结合，提升二环和三环媒体触达用户的频率和效果。借助 UI 智能化资产和相关的工具产品体系，打造业务敏捷创新的内功，和业务一起找到自己的方向和节奏，灵活应对市场变化和竞品威胁。

▐  组织：让前端智能化真的运转起来

我们需要让这些工具能够和组织结合起来，能够和阿里现有的环境结合起来。举个简单的例子，就像每年双十一前都会进行的“0 研发”战役和鲸幂在智慧会场的应用，我们希望能够基于双十一这个场景，让大家熟悉这些产品、设计、生成技术和数据化运营能力的应用，从而更好的理解和消费 UI 智能化资产。通过不断学习和运用，让使用智能化高效、高质量和个性化解决问题成为大家的肌肉反应，称为工作中自然而然的一部分。

另外，在日常业务中，借助算法模型能力进行自动化概念的映射和翻译，减少新概念的引入，让业务、PD、设计师、运营小二和技术小二、质量小二都能够在自己熟悉的概念下，共同为业务指标负责。

除了方法论+工具+组织这三个结合起来，最终我们还需要一套体系机制，无论是业务体系、产品体系和设计体系，最有价值的部分往往都发生在交集，这个交集在方法论、工具和组织的支撑下，相互制约：任何局部创新都能够受全局其它体系约束，又能相互赋能：任何局部创新都能够向全局其它体系输送价值，还能孕育化学反应：跨界、跨领域、跨体系的全局性创新。

业务、产品、设计、技术——前端智能化的核心客户

做任何事情必须要有客户的视角，知道服务谁才知道要解决什么问题。前端智能化的核心客户和我们的发展阶段息息相关，在初期阶段，面向技术人员围绕“解决一线 C 端业务研发效率问题”构建“设计稿生成代码”的能力。在中后期，我们必须将技术能力赋能到业务升级为业务能力。面向业务人员围绕“解决业务缺乏用户产品抓手的问题”构建“透明、快速、直接干预业务”的能力。面向 PD 围绕“解决业务敏捷创新和快速试错的问题”构建“设计稿生成的代码之上所见即所得的需求标注即可交付上线”的能力。面向设计师围绕“解决设计规范执行难、设计创新研发成本高落地难的问题”构建“设计生产一体化”的能力。

运营使用未在我们的体系内定义成核心客户，因为，今天圆心领导的小二工作台，不仅完善的解决了招商、选品、投放……等一系列运营问题，构建了完整的数据化驱动运营的技术体系，还借助 PU 、SOP 编排的方式，帮助业务根据自己的需要进行定制，舒文领导的“诺亚”借助“方舟”在多年大促营销活动上沉淀的经验，进一步降低了小二工作台的使用成本，我们只需要在前端智能化赋能业务的过程中引入“诺亚”或其他 PU、SOP 能力即可服务好运营。

质量保障未在我们的体系内定义成核心客户，因为，今天清灵领导的质量保证体系在前端智能化初期就和我们在深度合作，从 ATS 自动化测试模块质量，到 TMQ 基于机器视觉和算法的自动化测试，都已经做得非常完善，并且，底层的技术体系和上层的开放能力都足以支撑我们“开箱即用”，保证两套体系的功能和体验的一致性，可方便的支撑好质量保障的同学进行质量验收和质量监控。

▐  技术人员：C端业务研发效率问题

对于我们阿里来讲，技术人员是一个巨大的群体，C 端业务又是一个面向终端用户且复杂多变的场景，跨平台、需求变更、个性化是这些复杂多变场景的核心问题，他们共同要求“有一种消除重复劳动的技术”，否则，只能靠技术人员自身来填这个大坑。对于技术人员来说，跨平台、需求变更、个性化对技术而言并没有太大的挑战和创新，只是时间成本的问题：适配不同的平台、实现变更的需求、逐个开发不同的个性化承接产品，这些就是亟待消除的“重复劳动”。

只有深入研究跨平台的业务研发问题，我们才能准确的定义 RunCook 的功能，才能解决业务研发过程中对宿主环境业务能力的适配和降级问题。只有深入研究需求变更，我们才能准确定义 BizCook、imgCook、LogicCook 的功能，才能通过 NLP 的算法模型理解业务定义的指标如何被 PD 描述成需求、设计师又如何用设计语言来表达 PD 的需求、设计稿如何借助 imgCook 生成 UI和交互逻辑、UI 的内容及状态的变化如何借助 LogicCook 从 PaaS 上获取并实例化成 Node FaaS 的胶水层代码挂载在 UI 和交互逻辑之上。深入研究消费者，我们才能准确定义 UICook和鲸幂的功能，才能通过智能设计生产一体化、代码生成能力降低一线业务研发人员为不同圈层用户开发产品功能的成本，给消费者带来极致的产品体验。

▐  业务人员

小芃在介绍数据中台的时候说：「 以观星台举例，逍遥子可以通过观星台看到全集团宏观的业务治理，这是一个最大的顶层的节点。再往下这个子节点，就是各个业务总裁和业务的矩阵，下面每个业务有自己业务数据的逻辑和数据决策的体系。再往下就是每一次的活动，或是一些节点，基本上形成了一个决策体系。我对这个观点深以为然，今天决策体系化才能让业务形成战斗力，然而，却有一些问题会阻碍这种战斗力的形成：执行。」

在技术产品里有一个生动的比喻：P9 的战略、P8 的规划、P7 的设计、P5 的执行，最后，一个好的思想和理论没有能够形成好的技术产品。为什么不能是 P9 的战略、P8 的规划、设计和执行呢？因为，信息在传递的时候会有损耗。通俗的理解就是：张大妈说你和女同学放学一起回家，李大婶说你和女同学谈恋爱，王大爷说你和女同学结婚了。信息论里研究信息的损耗，因为信号在介质中传递的时候会受到干扰，电信号在取值范围上下的波动未达到信号电压要求，从而导致信息的一些编码丢失，李大婶和王大爷自身的偏见就是导致信息损耗的干扰。下面，借助一些信息论里的知识谈谈服务业务人员过程中如何抗干扰？

• 优化业务指标编码

谈到信息论，就离不开编码。谈到信息论就离不开传递信息，传递信息的过程需要对信息进行编码，而如何用最少的编码表示所要传递的信息就是我们要研究的目标了。

假设两地互相通信，两地之间一直在传递A，B，C，D四类消息，那应该要选择什么样的编码方式才能尽可能少的使用资源呢？如果这四类消息的出现是等概率的，都为四分之一，那么肯定应该采用等编码方式，也就是

这样就能达到最优的编码方式，平均编码长度为 。

但是，如果四类消息出现的概率不同呢？例如 A 消息出现的概率是二分之一，B 是四分之一，C 是八分之一，D 是八分之一，那应该怎样编码呢？直觉告诉我们，为了使平均编码长度尽可能小，出现概率高的 A 消息应该使用短编码，出现概率低的C ，D 消息应该使用长编码。与等长编码相比，这样的编码方式叫做变长编码，它的效果更好，例如采用下表所示的编码（其实这是最优编码）

平均编码长度为

显然要优于等长编码。

业务同学决策依据的数据指标有大量的歧义和冗余，这就需要有一套编码机制有效的对业务指标进行编码，保证在决策信息传递的过程中更精确、有效，因为，信息冗余越多损耗的概率就越大，编码的有效性越差，编码的冗余信息就越多。我们在 BizCook 上重新构建 C 端业务研发的指标体系和其编码方式，对指标包含的信息进行有效编码，是决策信息有效传递的第一步。

• 度量业务指标损耗

若现在还有一种消息序列的概率分布满足 q 分布，但是它仍然使用 p 分布的最优编码方式，那么它的平均编码长度即为

其中被称为 q 分布相对于 p 分布的交叉熵（Cross Entropy），它衡量了 q 分布使用 p 分布的最优编码方式时的平均编码长度。

交叉熵不是对称的，即。交叉熵的意义在于它给我们提供了一种衡量两个分布的不同程度的方式。两个分布 p 和 q 的差异越大，交叉熵就比大的越多，如图

它们的不同的大小为，这在信息论中被称为 KL 散度（Kullback-Leibler Divergence），它满足。

KL散度可以看作为两个分布之间的距离，也可以说是可以衡量两个分布的不同程度。

对于业务的同学，围绕自己两三个核心目标层层拆解下去的业务指标也有 q 和 p 的分布，我们可以在 BizCook 上根据交叉熵来衡量实际：产品、设计和技术在承接这些指标时候的偏差程度，也可以在 BizCook 上利用 KL 散度来判断决策指标在承接过程中的信息损耗。

• 分析业务指标关联

和单变量相同，如果有两个变量 X，Y，我们可以计算它们的联合熵（Joint Entropy）

当我们事先已经知道 Y 的分布，我们可以计算条件熵（Conditional Entropy）

X 与 Y 变量之间可能共享某些信息，我们可以把信息熵想象成一个信息条，如下图：

从中可以看出，单变量的信息熵H（x）(或H（Y）)一般比多变量信息熵

H（X，Y）要小。如果把条件熵也放进来，那么可以从信息条更清晰的看出它们之间的关系

可以看出

更细一点，我们把H(X)与H(Y)重叠的部分定义为 X 与 Y 的互信息（Mutual Entropy），记作I(X,Y)，则 。互信息代表了 X 中包含的有关于 Y 的信息（或相反）。

将 X 与 Y 不重叠的信息定义为差异信息（Variation of Information），记为

V(X,Y)，则

差异信息可以衡量变量 X 与 Y 的差距，若V(X,Y)为0，就意味着只要知道一个变量，就知道另一个变量的所有信息。随着V(X,Y)的增大，也就意味着 X 与 Y 更不相关。形象化的表示可以从下图看出

总结一下

面试前要精心做好准备，简历上写的知识点和原理都需要准备好，项目上多想想难点和亮点，这是面试时能和别人不一样的地方。

还有就是表现出自己的谦虚好学，以及对于未来持续进阶的规划，企业招人更偏爱稳定的人。

万事开头难，但是程序员这一条路坚持几年后发展空间还是非常大的，一切重在坚持。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

为了帮助大家更好更高效的准备面试，特别整理了《前端工程师面试手册》电子稿文件。

前端面试题汇总