文/甄子，阿里经济体前端委员会智能化方向负责人，淘系前端 D2C 智能团队负责人。

道：为什么做前端智能化

最初，前端智能化方向的提出是为了给前端技术带来变革，借助 AI 和机器学习的能力拓展前端，就像拥有望远镜人类就有了神话中的千里眼，拥有了 AI 前端也会在自身能力的基础上产生更强的“超能力”。

随后，在保持这个目标推动的时候，发现很难落地。通过思考 AI 的能力特点、前端的生存现状，决定从“解决一线研发人员问题，提升一线研发人员幸福感。”为出发点，重构智能化的战略和战术体系。

最后，切入点就是设计生成代码。搭建体系日臻成熟、模块化开发方式深入人心的今天，大量需求变更和复杂的业务环境，造成前端无法用“复用”的思想简单解决问题，所以，用前端智能化进行设计稿识别和理解，再通过规则生成代码，Design to Code（D2C）能够良好的解决日常模块开发的问题。

术：怎么做前端智能化

道生一

D2C 在淘系电商C端业务上应用，支持双促会场模块 0 研发，再结合智能 UI 和智慧会场，基于会场规划的约束、场模板和运营投放配置，智能化生成会场，并针对不同圈层用户提供不同的 UI 和交互方式，再加上端智能的智能插卡、智能权益弹出挽留等能力，多管齐下，真正做到前端智能化技术赋能业务，在研发提效的基础上，做出用户价值和业务价值。

一生二

Design+ to Code（D+2C）

在原有设计稿识别和理解的基础上，融入 PD 对设计稿上数据、功能、交互的描述（原 PD 的线框图和交互稿等工作），从而进一步完善模型的输入，从而生成更多逻辑代码，以应对更复杂的业务场景。

Pipcook

用于解决前端使用机器学习成本的问题，0成本帮助前端快速掌握和使用机器学习 OTA 算法能力。同时，帮助业务落地的团队训练自己的模型，保证模型在自己业务场景能够自我迭代、更加精准。

二生三

做好宣传：

因为大家对 AI 的陌生，所以对前端智能化产生顾虑和质疑，难以规模化推广。从淘系业务、拍卖、健康、蚂蚁、支付宝、体育、CBU……已落地场景中收集和梳理实践经验和案例，形成通俗易懂的系列文章，帮助大家了解 AI 和前端智能化。进一步落地推广，使前端智能化可以在前端领域里成为普惠技术，让一线前端研发人员获得幸福感。

做好应用：

模仿是高效的学习方式，机器学习本质上也是从人类的经验中模仿。在更多领域内实践，形成更多的样板工程是做好应用的重点事项。要有清晰明确的业务领域版图、技术领域版图、工程领域版图，通过涂色的方式，一点点在版图上扩大应用的领域。扩大的方式也要从我们做大家用，变成我们做样板，大家模仿并衍生出更多优秀的应用案例。同时，加强应用领域和核心领域之间的链接，充分回流应用思想、应用方法、应用能力……反哺核心领域，用来自实际应用场景的客观需求，数据化驱动核心领域的精益迭代。

做好技术：

持续对智能化技术体系进行深耕，也是未来的重点之一。今天的智能化技术体系仍然有很多问题，跑的太快、为了解决问题，很多应用和核心技术之间耦合，很多技术的开放能力和客制化能力不足，很多技术的理论基础不扎实，很多技术的工程化体系不完备。此外，在“人机协同的编程方式”大方向下，如何跟PD、设计、运营、用户产生标准化、数据化、自动化的链接？真正支持应用体系降低理解和使用技术的成本，做到：需求暨代码、需求暨生产、协同在线化，从而进一步、全链路、端到端的提升业务交付能力。

三生万物

前端技术体系升级：

D2C 技术体系升级，引入 S2C 能力，形成 P2C 端到端业务交付平台：在无状态简单UI代码和简单前端业务逻辑代码生成基础上，升级到复杂UI代码和复杂业务逻辑代码生成，同时，复杂UI代码里对状态进行识别和处理，生成带状态变化的UI逻辑代码，端侧调用JSBridge、数据和服务接口的业务逻辑胶水层代码，服务端调用数据和服务接口的业务逻辑胶水层代码。

智能 UI 技术体系升级，能力下沉同时支持频道业务的智能 UI 个性化，技术内敛将偏业务部分交给 P2C 端到端业务交付体系，算法自建将搜索推荐海神的算法收回前端智能化团队自己设计维护。三管齐下，保证智能 UI 技术体系普适、内聚、可控，从而做好归因分析在广泛业务场景里数据驱动的方式进行迭代。

前端智能化算法工程体系升级，引入云原生能力使智能化算法框架 Pipcook 可以从数据侧、模型侧、训练侧、部署侧支持云原生，能够更便捷的融入云原生体系，保障使用者可以直接上线模型算法支撑业务，打通业务的全链路。

业务研发模式升级：

P2C 业务研发平台打造：需求暨代码、需求暨生产、协作在线化的全新业务研发模式。打通需求、设计、研发的全链路，保证信息流转的完整性、迅捷性、连贯性，确保最终交付物和需求的结构化信息的一致性，需求迭代的数据化驱动。

设计下沉和异步化，从以往针对需求的设计进化到针对业务的设计，从设计趋势和社会发展、技术进步三个角度出发，以设计语言为依据，以设计系统为规范，提供设计范式，由模型根据设计范式进行自动化设计生产，从一个 UI 方案衍生出 N 个 UI 方案、从一个 Element 衍生出 N 个Elements。

服务端下沉和抽象化、原子化，提供标准的、原子的领域能力，由 S2C 体系进行能力的理解，并通过需求的约束对调用逻辑：胶水层代码 进行生成。

前端能力模型升级

编程思想升级

• 确定性

首先，智能化思维解决问题的过程很简单，简单的过程就代表了确定性：一定会有答案。其实，这就像人生的困惑，每个人都有自己的答案，即便我们告诉模型所谓的正确答案，模型训练后对未知问题也不一定给我们期待的答案，但是，模型一定会给我们一个答案。

其次，从经验的角度看，只要是行业里解决的很好的问题，在自己的领域里应该也能解决的很好。比如，使用图像分类模型，人家在严谨的实验中验证了图片里只要有猫或狗，图像分类模型就能准确识别出来。如果我把自己拍摄的猫猫狗狗的图片标注好喂给模型，模型训练后一定能识别出别人拍摄的猫和狗的图片，这就是确定性的另一个层面。

最后，用个现实的例子，比如你来到一个新的团队，无法把所有人的面孔和名字对应上，经过一段时间的相处，你们天天交流、一起吃喝玩乐，最终你能把每个人都记住，看到其中任何一个人都能叫出ta的名字。模型也是一样，起初模型也无法记住不同人的面孔，但是，把每个人、每个角度、每种光线条件下大大小小的图片标注上每个人的名字，模型经过恰当的训练，就能跟我们一样喊出每个人的名字，这就是确定性。

• 鲁棒性

首先，智能化思维解决问题的方法很简单，告诉模型正确答案后，模型自己在样本数据里训练模型的参数和权重，自己归纳总结答案背后的思想，这就很鲁棒了。再回到“达芬奇”用OpenCV遇到的问题：阈值谬误，要总结和提炼出所有情况下image、Text、Controller成为image、Text、Controller的特征很难，然鹅，当拥有足够大规模样本数据的正确答案，模型就能提炼出足够鲁棒性的答案。

其次，对算法有兴趣的同学可以Google一下遗传算法和蚁群算法等，你会发现凡是鲁棒性很强的算法都超出我们的意料，说简单点儿就是人很难总结提炼出这些算法背后的模式和思想，但是，这不妨碍我们写出遗传算法和蚁群算法去在模拟或现实的环境中训练出这些具备鲁棒性的模式和算法，这种写程序的方法本来就很鲁棒了。回忆一下，以往我们在写代码的时候都是想清楚了再写，今天，用智能化思维解决问题的时候想不清楚就能写代码，这种软件开发的方式还不够鲁棒么？

• 进化性

今天在面对服务端高可用问题的时候，至少10年前我就跟同事讨论过系统的“自愈性”问题，10年过去了，讲真没几个公司接近这个目标，然鹅，今天用智能化思维就可以做到！我先从智能化思维的进化性讲起，最后来分享一下我对系统“自愈性”的一些探索和思考。

智能化思维的进化性体现在我们解决问题的方式上，以往在开发之前就确定了解题思路，开发过程中把解题思路实现掉，说白了就是Hardcode。在面对超出灵活性设计的问题时，我们还是要去写新的代码，不断给自己之前所谓的“解题思路”打补丁。用智能化思维解决问题的时候，我们并不提供解题思路，模型自己从正确答案里提炼解题思路，一旦遇到新的情况我们可以把这些情况当作新答案喂给模型，模型就能自我进化了，再遇到类似问题自行解决，这个过程就实现了自我进化，我们唯一要做的就是形成这个进化的闭环：模型答案的评估、新答案生成正负样本、构造在线训练的通路。

机器学习能力的升级

会用 Pipcook 或 Python 技术生态的机器学习相关框架、库、包……

会数据获取、数据处理、模型配置、模型训练、模型验证、模型部署、数据回流闭环，能够用Pipcook 配置Pipline 进行流式计算，处理海量数据。

会调试模型，知道如何评估模型、定位模型问题、调优模型、压缩剪枝和知识蒸馏降低模型算法复杂度提升模型性能。

智能化关键指标

模型功能指标之模型选择：业务是用来服务用户的，对用户的理解可以帮助我们审查业务理解的正确性。通过用户理解，可以确定用户的任务；通过理解用户的任务，可以确定模型的任务；通过理解模型的任务，可以确定模型的功能。只有确定了模型的功能，才能正确选择模型。通过对模型功能指标的梳理，后续可以监控这些指标来判断模型选择是否正确。

模型理解之模型准确率：理解了模型应该做什么？才能通过模型在业务上反馈的数据设定评估指标。根据指标暨存业务、类似业务和全新业务上的指标表现，可以分别判断模型在应对已知问题、类似问题和全新问题的准确率，而类似问题和全新问题的准确率是模型的泛化能力。通过模型自身的准确率数据，结合业务上反馈数据的评估指标情况，能够更全面判断模型准确率指标。

准确率理解之模型泛化能力：应对类似问题和全新问题的准确率就是模型的泛化能力。类似问题较好理解，诚如字面上“同类型”和“相似”的问题。全新问题的准确率应该理解为：未被发现、不直观、难以理解，背后却有共性的问题。不应该理解为：肆意创造且和经验完全无关的问题。因为，今天的机器学习还属于弱人工智能，对未知领域的感知、理解和创造能力缺失。使用准确率和泛化能力指标的时候，必须对各指标的边界有清晰定义。准确率指标是用于评估模型发现（召回）和解决问题能力（模型的演绎能力），泛化能力指标是用于评估模型解决非训练集问题的能力（模型的总结归纳能力）。

前端智能化方向仍在不断的快速发展着，我们也仍然在路上。我们会不断的探索使用智能化的能力解决一线研发人员问题，提升一线研发人员幸福感，我们充满信心。