作者:雷姆

背景介绍

本篇为大家介绍算法工程框架 Pipcook，它是一款面向前端开发者的机器学习框架，我们希望它会成为前端开发者学习和实践机器学习的平台，从而推进前端智能化的进程。

接下来就看看 Pipcook 是如何助力前端智能化！

助力 2020 阿里前端生成代码

imgcook 在 2020 双十一完成了90%的模块覆盖率，除此之外，基于 Pipcook 的中台解决方案，也分别在 ICBU、菜鸟、飞猪、阿里云、阿里健康和 Lazada 多点开花。

C端代码解决方案

整个 imgcook 系统结构较为复杂，从一张设计稿到最后生成可上线的代码，中间需要经历很多步骤，大致可包括图层处理、物料识别、布局生成、语义化和逻辑绑定等，其中每个步骤中都可能需要多个算法模型协作完成，而非一个端到端的模型，比如：

在物料识别层，通过图片分类模型，可以将一些更为高阶的组件（如按钮、轮播图、视频控件、搜索框等）从图片中识别，然后生成对应的组件代码
在语义化层，通过 icon 识别模型，可以更准确地为代码中的 icon 元素命名类名（推荐阅读：Icon 如何在设计稿生成代码中被识别？- Imgcook 3.0 系列）
在字段绑定层，通过文本分类模型，可以理解设计稿中某段文本的含义，从而使用正确接口字段来渲染对应元素

Pipcook 通过提供了通用的模型能力，比如图片分类、目标检测、文本分类等，减少了在 imgcook 中从开发到上线这些模型的门槛，使得如此多的底层识别能力也具备快速迭代的可能性。

中台解决方案

而中台方面，也开放了一套基于 Pipcook 的智能中台方案。

中台的诉求，其实就是开发一个内部系统用于简化流程，比如搭建系统、发布系统以及运营工作台，它们往往是为了将一部分需要由开发承担的工作，通过更简单的交互和接口降低操作的门槛，从而可以让整个团队能一齐协作，提升产品效能。

但在这个过程中，中台的开发也遇到了一些问题，比如

并非所有团队都具备前端开发能力，这大大增加了中台开发的门槛
并非所有中台都拥有很好的交互体验，大部分小中台由工程师团队自己完成，并未经过良好的交互设计
中台的需求往往千变万化，这使得大中台的用户和开发团队总存在一些取舍

以上便是智能中台方案希望解决的问题所在，而我们的切入点首先是第一个问题，如何降低中台开发的门槛，而我们的答案便是通过设计稿生成中台前端代码解决部分问题。

我们通过自动生成样本的方式解决了设计稿收集困难的问题，这种方式覆盖了图标、图表、表单和表格这些基本素材。为了降低使用该方案的硬件门槛，也尽量使用了像 Tensorflow.js 和 mobilenet 这样轻量化的框架和模型，让训练过程在 macbook 就能轻松完成。

imgcook 算法工程平台

在今年，imgcook 在集团内部也提供了全链路模型训练的能力，从样本生成/上传，到选择模型，最后到模型生成并使用，全部都可以在 imgcook 通过 GUI 的方式完成，而 Pipcook 在其中也承担着非常重要的角色。

Pipcook Service 被部署在 GPU/CPU 的训练集群，然后在 imgcook 中通过集成 Pipcook SDK 来远程调用 Pipcook 的训练能力，菜鸟前端团队也同样采取了这种方式，搭建了属于自己的 D2C 模型平台。

引子

在初步了解了 Pipcook 目前在前端经济体取得的一些进展后，接下来会从机器学习与前端的邂逅开始，讲到 Pipcook 的初心，以及我们对于前端智能化的愿景。相信读者阅读之后，就会对 Pipcook 的前世今生有一定的了解，同时也欢迎以各种方式参与进来！

前端与机器学习

提到前端智能化，就不得不说机器学习，因为这所谓的前端“革命”就是由机器学习/深度学习发起的，在一开始，机器学习作为人工智能的一门分支学科发展而来，主要研究的便是如何让机器具备像人类一样的学习能力。

但渐渐地，机器学习从人工智能领域慢慢向基础领域拓展，由所谓的应用科学慢慢地变为向互联网一样的基础设施，就像如今如火如荼的云原生，它改变着人们进行产品研发和迭代的方式，机器学习一样在慢慢地改变着人们在使用计算机的方式，从之前的面向细节的设计，转而向面向学习的设计，当计算机具备了一些基础的学习能力后，作为计算机工程师的我们，就需要学会如何去使用这种能力去替代一些脑（劳）动力。

然而真正的前端智能化并未如前面所说的那样简单。在如今的前端领域，存在着诸多的交叉领域，比如前端与嵌入式碰撞出了一些以 Web/JavaScript 为应用开发语言的嵌入式操作系统，再比如前端与区块链碰撞出了可以计算 Gas 的 JavaScript 虚拟机，当然也包括前端智能化这样一个领域。

但是，却很少有人能定义出前端智能化到底碰撞出了什么，因为这个组合词描述的问题真的不小，因此我们先从最开始说起。

不得不说的 Tensorflow.js

可以说 Tensorflow.js 是前端智能化的先驱和前辈，却也不是。

为什么这么说呢？它从 2017 年开源之初，主要的精力便是以支持在浏览器端运行模型进行推理为主，在支持的粒度之外呢，Tensorflow.js 利用了像 WebGL、WebGPU 和 WebAssembly 对这个推理引擎做了各种各样的优化，其目的也是围绕着如何让神经网络在浏览器中运行得更快、更高效。

因此 Tensorflow.js 很好地完成了作为一个神经网络运行时/引擎的工作，但却留下了两个问题，一个是使用门槛的问题，另一个则是开发者生态。

尽管 Tensorflow.js 封装了足够简单的 API，也提供了足够详细的文档和教程，但对于前端工程师的入门来说，还是略显晦涩，只有当使用者了解机器学习/深度学习的一些知识后，才能很好地使用它。

造成这样结果的原因无他，因为它本质上并不是为了让前端开发者走向智能化的道路，而仅仅是为了能让机器学习既有的开发者和学者们，通过 Tensorflow.js 具备在 Web 环境下进行模型推理的能力，从而拓展原先人工智能的用户场景，比如：在 Web 浏览器完成人脸识别、物体识别、进行照片的风格迁移等。

由此，便可大致了解之前所说的 Tensorflow.js 是前端智能化的先驱，却也不是。

第二个则是生态问题，在机器学习发展的这几十年，Python 借着学术界和工业界的亲和度红利，已经形成了几乎无法打破的生态壁垒以及完善度，即使号称社区力量庞大的 JavaScript 圈子，要凭借短时间内有机地增长并取代 Python 生态也是做不到的。

这个问题几乎会成为所有非 Python 脚本语言想要亲近机器学习的门槛，Tensorflow.js 也不例外，几乎是很难去做到让学者和工程师迁移到 JavaScript 的链路上，为此就需要花费极大的精力去抹平那些存在于 Python 生态中的内容。

Node.js 与 Tensorflow

Tensorflow.js 的 Node.js 版本一直到比较滞后的版本才出现，在那之前，我也曾经基于 Tensorflow C API 写过一个 yorkie/tensorflow-nodejs，但不久后我就停止更新了。

Node.js 对于 Tensorflow 来说，的确是一个比较尴尬的运行时，首先 Node.js 运行时环境并不像 Web 会给机器学习带来一些新的交互场景，但是如果用来构建模型，又如上一节所说，需要做大量的生态迁移工作。一旦 Python 生态有一些新模型时，往往都需要额外的迁移工作。

与 Node.js 形成对比的是 Tensorflow 的 Swift 版本，它基于 CPython 封装了 Swift 调用 Python 的接口，从而不需要做任何的迁移工作，就可以使用 Swift 代码调用所有 Tensorflow 在 Python 实现的功能。

CPython 是 Python 语言的官方实现，使用 C 语言编写，因此叫 CPython，支持嵌入到任何环境，缺点是对于多线程/并行解释支持不友好。

基于 Tensorflow Swift 的思路，Pipcook 创造了 Boa，它也是通过 CPython，提供了在 Node.js 中调用 Python 的能力，如下：

const { keras } = boa.import('tensorflow');
const { layers, Model } = keras;

class TestModel extends Model {
  constructor() {
    super();
    this.conv1 = layers.Conv2D(32, 3, boa.kwargs({ activation: 'relu' }));
    this.flatten = layers.Flatten();
    this.d1 = layers.Dense(128, boa.kwargs({ activation: 'relu' }));
    this.d2 = layers.Dense(10, boa.kwargs({ activation: 'softmax' }));
  }
  call(x) {
    return this.conv1(x)
      .flatten(x)
      .d1(x)
      .d2(x);
  }
}
复制代码

通过如上代码，我们构建了一个4层的神经网络模型类，以上代码只需要通过 Boa 安装 tensorflow 包，即可运行成功。

在 Boa 的帮助下，对于 JavaScript 生态的提升非常大，维护者再也不需为了同步 Python 相关的代码而花费精力，同时也能间接使用完整、稳定的 Tensorflow 功能。

Node.js 的机器学习生态

Boa 除了能协助减少 Tensorflow 使用的成本外，同样对其他 Python 包一样，比如 numpy、sklearn、pandas 等基础库，当然也包括 pytorch、tvm 等大型框架。

了解了 Boa 的背景后，现在重点说说 Node.js 的生态和机器学习生态融合所带来的便利性。

对于不了解 Python 的前端开发者来说，上手的难度其实并没有多简单，对于新手而言、虽然语法可以快速入门，但包管理器、系统 API、熟悉各种库以及对于语言的熟练程度都不是立马能掌握的，此时如果能取长补短的话，带来的便利性会大大提升。

比如我仍然可以使用像 Koa、Express、Midway 等框架去搭建服务，然后在路由控制器中使用 Boa 提供的桥接能力调用到 Tensorflow 来完成模型的推理服务，这样对于一个已经熟悉 Node.js 生态的开发者来说，只需要掌握 Tensorflow 相关的 API，而不需要学习如何使用 Python 来搭建 HTTP 服务。

正如上一个例子，Boa 并非是让前端开发者用 JavaScript 来写 Python 代码，更大的价值还是生态的融合和补充，各自取长补短，在此基础上，发展出适合前端生态圈自己的机器学习生态来。

通过以上三个小节，我们分别了解了机器学习在前端智能化的演进过程，从一开始的 Tensorflow.js 在浏览器的使用，到 Tensorflow Node.js 的重新实现，再到通过 CPython 直接融合 Python 和 Node.js 生态，在我们的愿景，未来的前端机器学习生态将继续按照如下两个方向进行：

以 Tensorflow.js、MNN 为代表的，主要针对 Web 环境的推理优化
以 Boa 为基础发展出来的 Node.js 机器学习生态，主要通过复用两个生态，来打通各工程和算法链路，实现前端机器学习的最优解

以上就是我们对于前端和机器学习当前问题的一些观点，那么接下来，我们会以 Pipcook 的视角，来讲述关于 Pipcook 的故事。

智能化时代的 Node.js

大部分前端开发者一定对 Node.js 不陌生，从 2009 年 Ryan Dahl 开源以来，围绕着 Node.js 展开的一系列标杆技术，包括：NPM、TypeScript、Koa、Webpack 等等，都与 Node.js 发展离不开。

Node.js 的诞生，不仅让前端开发者的生态延展到了服务端开发的领域，也同样触及到了其他诸多领域，比如开发者们早就习惯了通过 commanderjs 或者 minist 来为自己开发简单易用的命令行工具，再比如 Electron 通过 Node.js 和 Chromium 来开发跨端的客户端应用，ReactNative/Weex 也间接使用了 Node.js 生态圈来帮助前端开发者构建移动应用，还有诸如 ShadowNode 和 IoT.js 这样将 Node.js 应用在嵌入式领域。

Node.js 一直在赋能前端开发者，帮助他们做到一切他们想做的事情，而 Pipcook，希望成为智能化时代的 Node.js，赋予前端开发者们智能化的能力。

Pipcook、Node.js 与机器学习

如果要用一张图来描述 Pipcook 与 Node.js 的关系，那么上图就是比较恰当的描述。对于 Pipcook 来说，我们的愿景就是像 Node.js 一样，成为前端工程师进阶为机器学习工程师的一个简单易用的平台。

那么，前端工程师到底应该如何成为机器学习工程师呢？这里的机器学习工程师又是什么工种呢，要负责哪些事情，需要掌握什么样的知识？

首先我们来看看，对于 Node.js 体系下的服务端工程师都做了些什么。

小王是一家创业公司的 Node.js 主程，公司的主要业务是一套 O2O 的线上交易系统，全部使用 Node.js 完成，那么小王需要完成的工作包括根据交易系统的主链路，设计符合系统要求的数据库、消息队列、子服务以及网关服务等，数据库方面使用了 MongoDB，消息队列用了 ZMQ 和 Resque，网关使用 Nginx 配置完成。

小狼是一家大型互联网公司的 Node.js 工程师，日常工作是根据业务需求，使用 Node.js 来研发业务系统，其中涉及到的技术则是通过 Node.js 对接公司内部的数据库系统 XDB、内部消息队列 XMQ。在业务上线后，发现系统的某个请求的 QPS 远远达不到实际的使用要求，因此通过针对个别场景的优化，并引入缓存和修改索引，完成了线上的要求。

看完了小王和小狼的经历，其实可以看出来要完成这些工作，对于前端工程师并不容易，因为需要了解很多在服务器开发领域会用到的概念，比如数据库设计、消息队列、网关等，同时问题的优化手段与以往的前端领域也是不同的，唯一相同的点是使用了相同的语言。

这有点像是一个国家，会分为各种不同的工种，有负责军事的军人，负责政治的政客、负责经济的商人以及负责学术的学者，但他们同时都使用一种语言进行交流，当一名军人退役后想要从商，同样需要学习成为一名商人所需的素质和技能。

那么 Node.js 也是如此，一名前端工程师与 Node.js 工程师都使用 JavaScript，转型所需的知识和技能是必须要掌握的，不过 Node.js 会提供转型所需的工具和平滑的学习路线。要成为一名机器学习工程师，也需要掌握机器学习的基础知识，而 Pipcook 则是通过工具，帮助开发者更快地完成内化学习的过程。

接下来，我们就来看看 Pipcook 工具箱中都有哪些利器。

如何使用机器学习的生态

正如上一节末尾所说：

以 Boa 为基础发展出来的 Node.js 机器学习生态，主要通过复用两个生态，来打通各工程和算法链路，实现前端机器学习的最优解

Boa 便是 Pipcook 工具箱中的利器之一，它快速地填充了前端与机器学习生态的离距，让两个生态能够更加无缝地融合，那么我们就来看看它是如何融合两个生态的。

无论是 JavaScript 还是 Python，它们都是一门脚本语言，需要通过额外的虚拟机（V8 或 CPython）才能执行代码，本文将会从更宏观的角度来看待这个虚拟机这个技术问题。

虚拟机，顾其名思其义，就是在一个世界中模拟出另一个世界。那么，可以这么理解，虚拟机其实就是一个世界，这个世界上会有花、有草、有人，用编程领域的概念来说，就是有“对象”，那么对于不同的虚拟机，就像是不同的世界，不同世界的游戏法则就不同，对于不同“对象”的定义也不同，所以可以把 JavaScript 和 Python 看作是两个不同的世界，并且由于规则的不同，衍生出来的生态也不同。

那么要融合这两个不同的世界，应当如何呢？如果要将两个世界中的每个类别、对象都一一对应上去，这个工作是极大的，而且每个世界本身也在不断地发展和壮大，因此永远也不可能完成这个对应关系。

那么得益于 Python 世界的架构之初，这优雅的设计（对象模型）使得 Python 万物都可归纳于几类，并且对身处高阶世界的我们开放了控制对象的接口，这就使得我们能从 JavaScript 世界中通过这个接口来控制 Python 世界中的万物，从而让生活在 JavaScript 中的人们具备使用 Python 世界资源的能力。

希望上面这个生动的例子，可以帮助更好地理解 Pipcook 在融合 JavaScript 与 Python 生态所做的事情，那么接下来，我们会从性能上来看看使用 Boa 时所带来的开销是否可以接受。

我们将使用以下两种调用方式来进行对比：a）通过 Boa 调用 Python，b）全部使用 Python，答案是非常明显的，就是性能上至少 a = b，极大可能 a > b。

通过上图，无论对于 Boa 还是 Python，最底层都是在使用 Python Objects，它包含了 Python 中所有函数的定义、变量的定义以及操作符的定义等等，对于执行纯 Python 代码而言，它通过 CPython 的解释器将代码转换成对 Python Objects 的调用。

对于 Boa 来说，也是一样的，由 v8 完成对 JavaScript 代码的解析，然后再将对应的操作映射到 Python Objects，因此两者的差异就在于 v8 和 Python Interrupter 对于各自代码的解释/执行效率，那么对于这一点来说，Python 和 JavaScript 都有各自的优化策略和方法，所以几乎是不相伯仲的。

上述所表达的是，虽然听上去是要从 JavaScript 调用到 Python，但其实从实现的机制来说，并非将 JavaScript 转成 Python 代码，然后再由 Python 解释器执行，而是直接与 Python 底层的对象交互，这样并不会增加额外的性能开销，所以可以放心使用。

在性能问题解决之后，我们再说一下它对于前端机器学习的意义。

在有了它之后，我们不再需要像 nodejieba，tfjs-node 这样的桥接库了，它就像打开了一扇通往机器学习新世界的大门，从此 JavaScript 的世界中，可以以非常低的成本使用到最成熟、最前沿的机器学习生态了。

前端机器学习的领域语言

什么是领域语言呢？或者我换一种说法 —— DSL，Pipcook 为了隐藏掉一些不必要的技术细节，基于 JSON 定义了一套用来描述如何训练模型的语言，叫 Pipeline。

我们首先从一个简单的 Pipeline 例子开始：

{
  "plugins": {
    "dataCollect": {
      "package": "@pipcook/plugins-mnist-data-collect",
      "params": {
        "trainCount": 8000,
        "testCount": 2000
      }
    },
    "dataAccess": {
      "package": "@pipcook/plugins-pascalvoc-data-access"
    },
    "dataProcess": {
      "package": "@pipcook/plugins-tensorflow-image-classification-process",
      "params": {
        "resize": [224, 224]
      }
    },
    "modelDefine": {
      "package": "@pipcook/plugins-tensorflow-mobilenet-model-define",
      "params": {}
    },
    "modelTrain": {
      "package": "@pipcook/plugins-image-classification-tensorflow-model-train",
      "params": {
        "epochs": 15
      }
    },
    "modelEvaluate": {
      "package": "@pipcook/plugins-image-classification-tensorflow-model-evaluate"
    }
  }
}

Pipeline 的结构看上去比较简单，基本上是由不同的插件（plugins）构成，每个插件节点由 package 和 params 组成，前者指定了插件的包名，后者则指定了插件所需的参数。

我们将一个完整的训练模型的过程，通过这种声明式的方式，分为了不同的节点，每个节点定义明确的输入与输出，而对于想要训练模型的开发者而言，只需要配置对应的插件和参数即可。

比如当我想要更换上述 Pipeline 的数据集，那么修改以下节点即可：

{
  "plugins": {
    "dataCollect": {
      "package": "@pipcook/plugins-image-classification-data-collect",
      "params": {
        "url": "数据集的地址"
      }
    },
    ...
  }
}

想要浏览官方插件的可以点击这里。

通过这种声明式的方式，可以帮助用户在不需要理解任何代码的情况下，就能用自己的数据集轻松训练出自己的模型了，训练完成后，会生成如下文件：

output
 ┣ logs
 ┣ model
 ┣ package.json
 ┣ metadata.json
 ┗ index.js

在 output 目录下执行 npm 安装命令，即可通过 index.js 使用训练好的模型了。

import * as predict from './output';
predict('your input data');

使用 Pipcook 进阶机器学习

上一节中介绍了我们如何降低前端开发者训练一个模型的门槛，那么本节将以之前提到的插件开发展开，说说如何通过 Pipcook 进一步学习机器学习的知识。

在机器学习界，流传着一句这样的名言：特征工程（Feature Engineering）决定着机器学习的上限，而模型要做的只是无限地逼近它。对于 Pipcook 而言，同样需要帮助所有开发者解决特征工程和模型训练的问题，因此 Pipeline 将插件基本分为了两大类：

数据类（DataCollect/DataAccess/DataProcess）解决数据和特征工程的问题
模型类（ModelDefine/ModelTrain/ModelEval）解决模型训练的问题

是指在定义好一个机器学习任务后，定义真实数据中哪些特征值会被输入到模型中去学习，这就好比当你分派一个任务给某人时，我们需要把任务的目标分解下去，并制定一些指标（KPI）去衡量，然后执行者就会通过这些指标去学习如何做好这件事，这个分解任务的过程就是特征工程，而后面执行者去学习的这个过程便是模型训练。

虽然特征工程描述起来简单，但真实的场景千变万化，需要处理的数据类型也多种多样，所以这是一项需要经验积累慢慢成长的过程。但对于前端开发者而言，还缺少一些关键的工具库，在 Python 生态下，有像 opencv、sklearn、numpy、pandas 这些强有力的工具能够辅助特征工程，不过好在 Boa 能够暂时帮我们补足这块劣势，通过 Node.js 也能快速使用这些工具。

因此，第一条成长路线便是通过帮助 Pipcook 拓展数据类插件，积累自己对于特征工程的经验，在这个过程中的你，仍然需要阅读这些仓库的文档，去了解每个函数在特征工程中的使用方式，最后以插件的形式提供给 Pipeline 用户。

Pipeline 将训练任务分成不同的类型放在不同节点去执行，这意味着它带来了极大的灵活性，当数据不改变的情况下，用户可以通过更换 ModelDefine 插件来对比模型效果，比如一个图片分类任务，当使用 mobilenet 效果不佳时，可以切换为 resnet 模型插件来对比效果，因此对于想在模型这条路上进阶的开发者而已，仍然可以通过开发或者优化模型插件的方式来学习相关的底层知识。

未来与展望

机器学习的势能已经让前端智能化势在必行，而 Pipcook 正如之前所说的一样，会成为智能化时代的 Node.js，但对于今天的 Pipcook 而言是远远不足的，未来的一年，我们仍然会围绕着机器学习生态和如何降低门槛为目标，让大家更轻松地使用一些已经成熟的能力，来赋能前端社区。

生态再融合

如今的 Boa 借助于 Python 生态，算是补足了一部分机器学习的能力，但在使用的体验上，还是有极大的提升空间。比如从安装的角度来看，现在要使用 Boa，需要同时安装 Python 和 Node.js，另外由于 Python 本身的限制，对于像 ARM 或 PowerPC 这样的平台，支持起来并不容易。

因此如何更好地整合 Python/Node.js 的生态，以及提供更快、更轻以及兼容性更好的 Python & Node.js 运行时，将是未来 Boa 努力的方向。

另一方面，用户在使用 Boa 时，仍然需要阅读 Python 的文档，这一点也是我们期望改变的现实，Pipcook 团队期望借助于 TypeScript、Python Interface(pyi) 以及一些源码理解的能力，让未来的 Boa 写起来就像在用 JavaScript/TypeScript 一样简单。

拥抱 Web

Web 最大的优势在于快速、跨平台以及轻量，现在要把训练好的模型运行起来，仍然需要更高的成本，比如一个通过 Tensorflow（借助 Boa）训练的模型，要部署到 Node.js 服务上，需要重新安装 Boa 以及其他的 Python 依赖，这个过程往往又会浪费用户大量的时间。

我们做过一个试探性的尝试，在模型训练完，使用 TVM 将模型直接编译成 WebAssembly 格式，这样用户在部署模型时，只需要在 Web 或 Node.js WASI 上加载编译好的文件就好，分发时不再需要安装任何 Node.js 或 Python 的依赖，因此我们会将这一功能进行完整地支持。

TVM，Tensor Virtual Machine，是一种深度神经网络的编译器，用于将基于 Python 神经网络编译为更适合目标环境/机器运行的本地代码，类似的产品还有 MLIR 和 Tensorflow XLA。

要做到上面所说的，完整地生成与训练时无关的运行时代码，我们还需要对目前特征工程，即数据类插件的部分进行重构，但现状是这些插件仍然依赖于 Python 生态，而这些代码是无法被 TVM 编译为 WebAssembly 的。因此我们已经在和 danfojs 团队共同开发 imgcook/datacook，它被定义为面向 Web 环境（也包括 Deno 和 Node.js）的特征工程库。当它完成后，就能做到使用 TVM 将所有训练时代码编译为面向 Web 环境的运行时代码了。

另外，我们也希望面向 Web 端提供一些真正开箱即用的 Pipeline，一方面是为了降低使用门槛，让用户不需要服务器就能用上 Pipcook 的能力，另一方面则是希望依托于浏览器端，真正为前端开发者所服务的用户，提供下一代的交互体验。

从离线到在线

Pipcook 目前的应用场景大部分还是离线的开发者服务场景，并未直接地为用户服务，这就让 Pipcook 本身的业务价值并未完全发挥出来。

因此在新的一年，Pipcook 会基于一些推荐场景，打通从 MaxCompute 到推荐服务，再到端智能的链路，这对于 Pipcook 会提出一些全新的挑战，然而，我们会全面拥抱云原生，让前端开发者零门槛也能搭建稳定可靠的推荐服务，实现前端智能化所带来的业务价值。

最后，真诚地感谢过去对 Pipcook 提出宝贵意见和贡献的开发者们，希望在接下来的一年，能一起，继续探索通往前端智能化的道路。