前端智能化实践（附：D2 前端技术论坛 PPT 合集）

最新推荐文章于 2024-05-05 03:05:43 发布

2401_84411767

最新推荐文章于 2024-05-05 03:05:43 发布

阅读量19

点赞数 5

分类专栏：程序员文章标签：前端

本文链接：https://blog.csdn.net/2401_84411767/article/details/138389891

版权

程序员专栏收录该内容

212 篇文章 1 订阅

订阅专栏

文章讨论了如何在P2C产品中设计符合PD特点的标注系统，强调了逻辑点在业务需求定义中的关键作用。通过结合D2C能力，P2C的目标是简化标注过程，提高出码效率，并探讨了从自然语言描述向基于设计稿标注的转变。文章还提到了出码链路升级的必要性，以及对未来的0标注和0研发愿景。

摘要由CSDN通过智能技术生成

基于设计稿已不用再过多介绍，应用 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 向外传递给大家，期望带来整个前端工业的智能化。