前端智能化实践— P2C 从需求文档生成代码 | D2 分享视频+文章-阿里云开发者社区

作者 | 狼叔、卓风

点击查看视频

大家好，我们是来自阿里巴巴淘系技术部的狼叔、卓风。感谢 D2 组委会，让我们有机会在这里分享，关于《前端智能化实践—— P2C 从需求文档生成代码》。

狼叔（上图左），Node.js 技术布道者，Node 全栈公众号运营者，曾就职于去哪儿、新浪、网秦，做过前端、后端、数据分析，是一名全栈技术的实践者。已出版《狼书(卷1) 更了不起的 Node.js》《狼书(卷2) Node.js Web 应用开发》。入职阿里的三年时间，主要是在优酷 PC/H5 端从 0 到 1 的落地 Node.js 全栈，使用 SSR 对 Web 页面进行优化和重构，建设 SSR 应用的容灾、发布、灰度等能力，是集团内第一大 QPS 的 SSR 应用。在支撑好业务的同时，与组内同学一起孵化出开源框架 egg-react-ssr。2020 年到淘宝技术部，开启前端智能化的旅程，目前负责 P2C，和卓风是搭档。

卓风（上图右），入职阿里的八年时间，主要是在淘宝负责天猫、聚划算大促及日常营销业务产品的落地，曾负责面向天猫、淘宝、聚划算等商家的搭建产品建设和淘系智能 UI 体系建设和业务落地，相关产品和体系已陆续在向集团落地。近 1 年投身到前端智能化领域，致力于 Service to Code 体系建设，推动服务端智能出码的落地，目前相关体系具备一定雏形，在团队内业务范围进行闭环试验。

今天的主题我们会以 4 个维度进行展开，会详细介绍 P2C 这个产品概念的来龙去脉以及我们解决问题的思路，欢迎各位上车。

因为今天的话题是延续去年甄焱鲲（甄子）在 D2 的前端智能化实践的分享，所以在讲我们的话题之前，还是先介绍阿里前端智能化实践的整体布局情况是怎样的。如下这张大图，可以按三部分进行理解：

底层是以 Pipcook 为代表的“前端算法框架层”，其目的是通过它让前端工程师具备了踏入算法工程师门槛的可能，这点非常类似于 Node.js 对于前端工程师的作用，目前 Pipcook 已经发布到 v1.3 版本，开源社区也非常活跃，欢迎自取使用；
中层“研发能力层”是面向前端提升研发效率的产品工具，并且对这边提效的能力我们进行了抽象，分为 D2C（Design to Code）、P2C（PRD to Code）、S2C、和 C2C 等，今天我们要重点讲的就是前两者；
而顶层是应用底层、中层前端智能化能力服务的上层业务产品，在过去三年里我们前端智能化的产品能力已经覆盖集团 17+ 个 BU（Business Unit） 70%+ 的前端，当然这个数字不算太新，新的数字在不断上升。

提到 D2C，我们先回顾下应用 D2C 能力的 Imgcook 产品今日的发展现状，从下图可以看到 Imgcook 的发展数字比较可观，且应用覆盖了 2020 年双 11 会场 90%+ 的模块开发，出码可用率达到 79.26%，且需求吞吐量提升 1.5~2 倍，给前端研发带来实质性的提效。

然而，提效并不等于完全替代前端人工开发，从 79% 的数字上我们看到还有 21% 的出码率没有达到，且 79% 这个数字在 2019 到 2020 年一直上浮不大，所以仿佛 D2C 走到了上升瓶颈阶段。

但经过我们的调研发现，事实并不是 D2C 的能力达到极限，而是从 Design 视觉稿中挖掘的出码信息达到了极限，剩余的 21% 的出码信息，我们发现要从产研链路的上游产品经理（PD，Product Designer）的 PRD （Product Requirement Document）中才能拿到。

所以我们将输入向上游链路扩展到 PRD 这一环，而 PD 生产的 PRD 又兼顾到前端下游链路后端的出码；同时前后端的出码界限一直以来并没有那么清晰（很多前端的代码其实也可以放置在后端 BFF（Backend for Frontend）层，比如初始数据的字段加工），所以我们将输出也扩展到下游链路后端这里。

因为我们将输入输出在产研链路上向上下游链路进行了扩展，所以理论上我们所做的工作也发生了本质的变化，由原来的设计即代码（D2C）转变为需求即代码（P2C）、需求即生产，将多种产研角色纳入到我们的产研工作台当中，形成多角色的在线协同，通过这次跨界，理论上会带来的出码率的进一步提升。

所以这就是 P2C（PRD to Code）的由来。我们期望借助 P2C 能进一步的提升产研的交付速度，期望能给 PD 提供端到端的产品交付能力，期望间接提升 PD 的业务 KPI 辅助业务增长。所以，可以看到相对 D2C，P2C 的目标用户发生了本质性的变化（由设计师、开发者转变成了 PD），基于这个点，我们对 P2C 的产品设计理念做了如下三方面的约束：

首先，要继续基于设计稿，这部分的出码率已达到 79%，这边的出码信息对 P2C 依然有用，所以这部分不能舍弃，同时，PD 基于设计稿来完成 PRD 会更佳方便直接。
其次，将 PD 原来书写 PRD 的工作转变成基于设计稿来标注业务信息的工作，一方面这样操作对 PD 来说更直接，另一方面这样的操作对 PD 的工作负担也相对较少。
最后，我们要确保 PD 的标注信息能够出码，要做到“需求即代码”，不能出码的输入信息，意味着不会进一步提升出码率，这就失去了 D2C → P2C 升级的意义。

基于设计稿已不用再过多介绍，应用 D2C 能力的 Imgcook 已经是一个很好的例子。那么“标注”和“出码”要具体怎么设计？接下来就会依次进行介绍。

首先介绍 P2C 的标注，想要知道标注怎样设计，必须预先知道 PD 是怎样一类人，他们的工作方式是怎样的。

从 PD 的日常的工作调研发现，PD 是一类聪明、有想法有意思却又非标的工作群体，他们没有很多可标准化的工作具象内容，平时消耗在产研链路上的沟通比较多、新老产品经验传承也是断层的、书写的 PRD 文档也没有具象标准、五花八门所以书写的 PRD 下游角色也不怎么看，书写这样的 PRD 对 PD 来说本身已是一种负担和痛苦。

PD是非常擅长产品业务上定义的（比如什么叫“买贵必赔”、什么叫“冰点价”），这是除了 PD 以外其他角色不具备的能力，比如设计师，能在设计稿中表达的业务信息非常有限。

所以，P2C 标注的工作，就是要贴合 PD 的痛点和角色特点来进行设计，我们期望通过以下四点来帮助 PD 完成产品需求的定义。

第一步，我们期望 PD 在上传 Sketch 设计稿之后，P2C 会借助 D2C 的能力马上对设计稿进行第一步的解析，生成结构化可视化的在线标注画布，供 PD 进行第二步的操作；
第二步，我们期望 PD 在第一步的视觉画布基础上，进行业务信息的标注，完成业务逻辑的准确定义；
第三步，我们期望 P2C 能够提供给 PD 一种直观且轻量化的标注设计工具，辅助 PD 能快速完成类似多态等复杂业务逻辑信息的录入；
第四步，我们期望 P2C 能够提供给 PD 一种所见即所得的能力，通过预览的交互形态间接来确认产品背后的数据源信息，这就衔接到服务端的数据接口设计，下会会再讲到。
最后，经过所有的一个个步骤，本质上我们期望给 PD 提供一种非常贴合他手工标注的业务逻辑组织方式，期望 PD 的每一次标注都映射到背后的一个逻辑单元方便 PD 进行快速标注，而逻辑单元又能确保出码，这就是“逻辑点”概念的由来，尽管对 PD 是透明的，却对 P2C 非常有用。

所以，经过上面步骤对 P2C 产品的探索，我们也更加清晰了 P2C 的产品定位。概括一下如下图所示，P2C 要在 D2C 的基础上兼顾业务含义的定义和出码量的绝对提升，这就是 P2C 的产品使命。

所以 P2C 的整个标注体系，就是如下的这套结构设计，基于设计稿的 Canvas 画布，提供给 PD 基于逻辑点的标注操作面板，非常直观、方便地辅助 PD 对产品需求的定义。

那么在这里有人会问，没什么不给 PD 一个 PRD 的文档编辑器来对需求进行录入呢？

这样的方案我们尝试过，甚至尝试过不止一个方案，但过去的失败都告诉我们 100% 采用纯的自然语言来描述需求，对 PD 虽然可行，但对出码却不可行，至少当下 NL2Code 这个学术业界难题还没有非常好的攻克掉，所以这对 P2C 不利，而且纯的自然语言描述并不如这种基于设计稿的标注对 PD 来说操作更直接、更简洁，所以当下这套标注的产品设计，也是我们经历种种失败后选择的一条非常贴合 PD 且可行的一条道路。

那么 PD 究竟怎样标注？操作方式是什么样的？

以下两张图就是 P2C 里对标注这一产品能力的具体设计思路，可供大家参考。

背后使用的是一套上卷下钻的交互设计理念，同时对于 PD 如果从 P2C 推荐的标注点（逻辑点）列表中找不到他所需的标注点的话，P2C 还给其提供的自定义的工单链路，方便其完成需求的定义。工单的背后是借助人工、机器学习来对 PD 定义的需求进行出码定义和训练，下文会再介绍。

所以从 PD 是视角来看完整的需求迭代动线就如下图所示（图中的 S2C 赋能可以理解为 P2C 背后的智能化出码能力，下文就会重点提到），需求从创建到标注到产出一份完整的可供预览和汇报的 PRD 文档和预览 Demo，再到视觉稿的更新升级如何借助以图搜图（即以图搜存量标注信息）进行存量基础上的迭代，完整地展示了需求迭代的整个过程。

而第二张图就是以真实的产品需求为例，完成这整个产品迭代过程背后的一些具体技术过程，如“布局识别”、“各种逻辑点的识别”等等。

从上图我们基本看到了逻辑点的获取途径有三种，具体如下图所示：

第一种是 D2C 视觉识别这一步骤中从视觉稿中获取到的逻辑点信息，比如从“N 件 N 折”、“商品白底图”“淘抢购坑位”等这样的视觉表达挖掘到的逻辑点信息；
第二种是从 PD 的组织结构信息、产品背景信息中挖掘到的一些需求基本信息，比如“淘抢购频道”、“大促会场”等，这部分信息可以辅助 P2C 确定业务领域，缩小逻辑点的推荐分范围；
第三种是从 PD 直接在需求工作台的视觉稿画布上标注的业务逻辑信息，比如“无门槛的定义”、“冰点价的定义”等，这部分信息可直接作为视觉稿的补偿信息，方便 P2C 挖掘更多出码所必需的业务逻辑信息。

总得来看，有这三部分的信息即可确定全量的逻辑点，同时通过这些丰富的逻辑点一步一步地指引标注，通过标注自动更新逻辑点，最后通过选择的逻辑点和标注信息出码。

说到这里，大家可以看到逻辑点和标注之间是有关系的（上文也提到逻辑点就是为了贴合标注使用的），标注信息的颗粒度也直接决定逻辑点出码的可能性效果，简单来说，粗略一点的标注，比如像用自然语言来标注，对于逻辑点的出码效果不是太理想（当然我们也在研究这部分的能力）；详细一点的标注，比如像 KV 表单，对于逻辑点的出码效果肯定是最好的，但对 PD 来说太具有挑战了，在让 PD 做完型填空，工作方式既死板又不灵活，PD 很不喜欢这种工作方式。

所以，PD 喜欢的理想标注状态就是 0 标注（即在产品需求迭代过程中，对于存量已标注过的信息不要再重复标注，甚至可以做到跨产品的标注复用），这就是标注的未来发展走向，通过 P2C 的智能化手段来逼近这个目标；与此同时，借助逻辑点与标注的映射关系，能实现 0 标注，意味着首先要实现存量逻辑点迭代的 0 研发（即在产品需求迭代过程中，借助智能化能力对于存量逻辑点可以通过细微地变种形成迭代所需的新逻辑点，甚至也做到跨产品、跨技术的逻辑点复用和生成），才能对 0 标注提供可能性。

所以，从 0 标注、0 研发的角度来看 P2C 产品从现在到未来的发展路径，基本符合下面的发展规律（如下图所示）：

阶段一，就是当下借助 Sketch 视觉稿和 Sketch 标注信息生成代码的过程；
阶段二，是将 PD 角色的完整生命周期的工作内容搬到线上需求工作台当中，同时打通产研完整的产研链路，形成一定程度在线协同，完成需求的交付过程；
阶段三，是大量借助 AI 提供大量可替代人工重复标注和出码的服务可能，节省产研链路上的人力的重复性开销，形成一定自动化程度上的需求交付过程；
阶段四，是在前面基础上，拥有大量历史标注、出码数据的基础上，将 AI 的能力进一步提升，从而达到视觉稿/PRD 的上传即出码过程，即需求即代码的交付过程。当然，这是后话。

上文讲完“标注”的产品设计过程，那么接下来再重点介绍下“出码”的产品设计过程。

讲出码之前，还是要先关注下 D2C 目前版本中运用逻辑点来进行出码的实现过程。

如下图所示（图中的视频可从文章顶部的直播视频中查阅到），借助视觉稿插件我们对视觉稿做了一定程度额外标注，导出之后给到 Imgcook 工作台，然后开发者需要在 Imgcook 的逻辑库当中录入视觉稿中存在的逻辑点信息，逻辑点信息包含逻辑点的识别和表达两部分，从而实现在设计稿导入到 Imgcook 工作台之时，马上可以识别到视觉稿中可能存在的逻辑点。

上面过程就是 D2C 借助逻辑点来实现出码的完整过程，可以看到面向的用户角色是开发者，而这点就是与 P2C 的本质区别，P2C 面向的是 PD，所以不可能让 PD 进行逻辑点的预先定义和应用。

然而不论 D2C，还是 P2C，在出码的实现链路设计上都是可以抽象为“逻辑意图的识别”和“逻辑意图的表达”两部分的，即从识别获取到“逻辑意图”（逻辑点），再基于“逻辑意图”表达成为真正的逻辑代码。

但 P2C 相比 D2C，它要升级点恰恰也是“识别”和“表达”的这两个过程：

“识别”要升级，原因是 D2C 原来的识别器是离散的，能识别的信息都是单模态的，比如不会把 UI 上的文本、布局、UI 样式、上下左右的信息、业务上下文等信息综合作为算法模型（Model）的输入，导致传统识别器能预测的语义信息的准确程度有限，外加上今天 PD 角色标注信息的引入，所以势必要对“识别”的算法模型进行根本性地升级，形成多模态的语义识别模型才可提升预测语义的准确率，从而更加精准地命中逻辑意图的语义靶点。
“表达”要升级，原因是 D2C 面向的是开发者，而 P2C 面向的是 PD，所以原来在 D2C 场景中开发者使用特别爽的数据源绑定、字段/事件绑定，对于 PD 来说就不人道了，否则就变成了 PD 在替开发者在编程，这是一种工作量转移的投机取巧，不是 P2C 的设计初心。另外，PD 标注的业务逻辑信息，他是不关心也不清楚具体是由前端开发者实现的，还是由后端开放者实现的。所以，总得来看，对“表达”的升级，就重点体现在对数据生成、事件绑定和逻辑函数块 OP 的表达器升级上，数据生成是为了避免 PD 要预先像开发者一样选择一个服务端数据源，我们采用借助语义识别出来字段语义自动关联或生成服务端数据源；事件绑定概念会隐藏避免 PD 感知，以免出现 PD 像开发者一样定义事件的绑定过程；函数块 OP 的升级，是因为 PD 定义的业务逻辑，除了含有前端的逻辑代码生成以外，还有生成服务端 BFF 层甚至更深层次的逻辑代码。

以上这些就是要在“出码”链路上对原来 D2C 逻辑点的识别、表达进行升级的来龙去脉。

那么新版的逻辑点在上游标注和下游数据/代码之间是怎样交互的？

具体过程可以如下图所示，简单来说就是借助上文提到的标注信息，找到可能存在的逻辑点，逻辑点背后又分前端逻辑点和后端数据逻辑点，附带 PD 标注的逻辑点约束信息，就可以真正出码了。

所以，概括一下，出码链路从 D2C 到 P2C，升级的主要内容就是下图中橙色到紫色和深紫色的部分：橙色部分是原来的 D2C 出码链路；紫色和深紫色是当下 P2C 的出码链路，而且深紫色部分中可以看到有服务端出码部署的功能节点，比如 FaaS 代码部署。这里也顺带提一下，P2C 在服务端的部署是进行冗余部署的，因为算法提供给 PD 的逻辑点推荐信息很大程度上存在近似解，所以只用多套解进行冗余部署 PD 才可以借助预览效果进行最终所需效果的甄别。

上文讲到识别的升级，那么接下来就简单介绍下逻辑点识别的算法设计方案，以供大家进一步理解这一步升级的重要意义。

具体如下图所示，借助多模信息的输入，进行综合型的语义理解，提升语义识别的准确率。

比如，以右图“￥4999 ”为例，当将该文本和围绕该文本上下左右的周边信息，以及文字字号、颜色、长度、粗细等信息作为算法模型的输入，通过对其中信息的 embedding、降维、尺度归一化等操作之后，获取到一些语义特征的 label 信息，从而确定“￥4999 ”的最终语义为“618 大促商品活动价”。

上文讲到出码链路上逻辑点升级的设计和实现过程，那么接下来再介绍下在 P2C 产品领域内，对逻辑点的未来阶段规划是怎样的，以便大家能进一步了解到，原来逻辑点的设计就是对未来 0 研发打基础的出发点。

具体如下图所示：

在 P2C 产品的起步阶段，PD 来到 P2C 需求工作台上的标注和背后的逻辑点信息，都是通过人肉的方式录入和供给的，这个过程我们认为是 Step1 阶段，目的是在为 Step2 积累算法样本；
当 PD 在 P2C 需求工作台上迭代起需求之后，平台上沉淀的历史数据中的标注和逻辑点数据就会存在内在的映射关系，这部分数据会作为训练样本回流给算法模型，进一步提升算法模型识别和表达的准确率，从而整体降低标注的人工成本和出码的开发人工成本，这个过程我们认为是 Step2 阶段；
紧接着，随着 Step2 阶段的不断发展、积累和模型的演进，P2C 的需求工作台就具备了 AI 标注和自动化出码的能力，这就是我们前面畅想的 0 标注、0 研发阶段，这个过程我们认为是 Step3 阶段。

理想是美好的，也给大家看看现实的具体例子，以下是我们生产当中的一些 Demo 案例，右侧是我们在人工给算法准备样本及算法预测效果的 Demo 案例（案例中数据我们做了去敏）；左侧是逻辑点的中文输入，输出就是逻辑点的代码，同时这也是我们在攻坚的研究课题—— NL2Code。

但 NL2Code 的学术研究，我们也在起步阶段，背后涉及数理逻辑、机器学习、软件工程、语言学、信息论等学科知识也比较多，门槛很高，且这个领域在学术界的研究也非常有限，解决方案能用到工程当中的也几乎少见，目前我们在各国内外各大顶级高校进行产学研的深度合作，期望在 NL2Code 领域真正产出一些根本性的进展，可服务工程生产，为 P2C 带来更深层次的效率提升。

当然，我们在学术上的产出一些阶段性地通过学术 Paper 向外传递给大家，期望带来整个前端工业的智能化。

最后，我们讲一下 P2C 的产品展望。

讲展望之前，还是先回顾下我们今天的所讲内容。

今天我们最先介绍 P2C 是怎么来的，然后介绍了 P2C 当中两个非常重要的产品环节的产品设计，一个是“标注”，另一个是“逻辑点”，借助“标注”我们收集到完整的需求信息，借助“逻辑点”我们找到需求出码的中间桥梁，借助对“标注”和“逻辑点”的“数据采集”我们找到训练“需求意图-服务出码”模型的基础数据，借助这个模型我们完成了整个需求即代码的交付过程。

同时我们也介绍到，P2C 是站在 D2C 肩膀上成长出来的产品，所以原来 D2C 的产品能力并没有浪费，而均作为 P2C 的基础基建。当然，让前端在 P2C 应用算法，也十分依赖底层 Pipcook 提供给前端的算法框架能力，所以，P2C 的建设也十分要感谢 D2C 和 Pipcook 能力的布局和建设。

最后，展望一下 P2C。P2C 的能力今年在业务当中在边落地边打磨当中，计划明年的 4 月份提供一个对 PD 更加友好的体验式交付平台，计划明年 10 月份可以对外公测。