AIGC 和低代码结合应用全栈研发实践总结

BingeLee 2024-05-10 发布于福建

展开全文

AIGC 和低代码结合应用全栈研发实践总结

www.toutiao.com 2024-05-10 15:18

背景

电商供应链的系统建设一般偏向于数据管理类型，但此类系统建设有一个很明显的问题就是前后端开发的沟通成本较高（相对研发成本而言），特别是一些简单加减字段的诉求沟通成本甚至达到 50% 以上，如何将这部分沟通成本降低下来，并保证高质量的交付成为目前亟待解决的问题。

经过对需求和系统页面进行分析，我们得出如下数据：

通过以上数据分析，一句话总结如下：

需求简单，但是沟通成本大！！！

思考

请注意这里讲沟通成本大是相对于简单需求的开发成本而言，单独看绝对投入其实还好，但是需求数量大，也会造成很大的资源浪费，我们希望探索出更高效的需求交付方式。

对于解决沟通问题其实有很多解决思路，其中有一个比较有效的方式就是目前得物技术正在推进的 Mooncake，它的好处是已经和发布系统打通，代码部署后所有接口和出入参等描述信息都会上传到 Mooncake，做到了统一以文档方式满足接口出入参说明诉求，执行后确实有不错的收益，但还存在两个主要问题：

在当前背景下，解决这个沟通问题的思路最简单的做法，就是让服务端一个角色全栈搞定前后端开发，为什么是服务端全栈而不是前端全栈，因为中后台系统的服务端的工作相对复杂，通过需求数据分析发现，服务端投入工时是远高于前端的，另外一个原因就是需求前端部分相对简单很多。

具象思考

谈到全栈，肯定不是直接把前端的工作直接交给服务端去做，得物研发目前的工作压力还是不小的，所以需要一种低成本的全栈方案，让服务端快速上手。

低成本的前提就是把复杂的前端开发变得简单，初期我们考虑了三条路进行简化：

低代码代替源码开发的好处是可以让服务端在配置一两个页面后快速掌握配置技能，它的认知成本会降低，学习周期也会缩短，下面这张图更方便大家理解。

源码和低码学习成本趋势图

另外，在知乎看到一张非常有趣的图，虽然有点夸张成分，但是感觉可以帮助大家理解低代码的学习成本。

低代码和几种跨界工具的学习成本对比

各个大厂其实在低代码领域已经做的非常成熟，给大家列举两个做的比较好的，大家可以去深度了解：

我们选择 Amis 作为基础的渲染引擎，主要原因如下：

另外关于和 AIGC 的结合，其实重点要看低代码在服务端全栈的场景下，可以帮助解决哪些问题？比如脚本编辑、UI布局等，这些一定会成为痛点，下面我们将随着问题的展开逐渐应用起来。

对低代码的“吐槽”

谈及我们的方案之前，我首先要“吐槽”下低代码/零代码，很多人说不好用，甚至有人说低代码是“行业毒瘤”，我翻看了很多这方面的总结性文章，以及自己的经验，理性总结如下：

主要方案设计

该篇文章我不会过多介绍低代码配置实现的原理，想了解的可以 Google 下。

我们整个全栈方案有一个统一的名字叫 Wizard，包括渲染引擎、组件、在线配置、发布流程、AI 答疑、AI Proto 等一系列工具，接下来会捡重点介绍。

特殊说明：我们初期全栈覆盖的页面类型主要聚焦在 CQUD，并没有扩散，核心原因就是目前此类页面占比较高（72%），并且交互形式足够收敛，页面类型收敛可以将全栈的成本降低很多，后期可以根据必要性选择性覆盖更多的页面类型。

另外对于上面提到的前 4 个槽点，没什么好的方法，大家只能认清事实，持续的去做，针对第 5 点，我们确实有一些方向，分享出来给大家参考，总结来讲主要是三步：简化组件配置、高效初始化页面、智能答疑。

简化组件配置

得物的基础组件建设得益于 Antd 和 ProComponents，好的东西当然直接复用，我们的主要工作是还原得物的设计标准以及业务组件的沉淀，组件注册到 Wizard 中最重要的是要将复杂属性转换成 JSON 配置可实现，比如接口请求、表单联动、数据格式化等，如果这一步做不好，会导致部分功能被阉割，所以这部分我们花费了比较大的精力去设计实现，以表单联动举例，效果参考如下动图：

选择显示姓名，姓名展示，选择禁用密码，姓名隐藏，密码禁用

源码实现：https:///edit/react-vegy7y?file=demo.tsx

Wizard 配置实现：

上面右侧 Wizard 代码示例中，type 代表组件类型，同级的其他属性代表组件API，body 属于通用属性用于子元素设置，认真看会发现，Wizard 针对禁用和显隐设置增加了 disabledOn 和 visibleOn 两个属性，并且支持写简单的表达式，类似这种标准属性的实现，是所有的组件统一去实现的（所有的组件都会支持 visibleOn ，所有的表单类组件都支持 disabledOn ），表达式是引擎统一实现的能力，为了更好的支持配置化，Wizard 引擎还支持数据域、数据链、模版、数据映射、表达式、函数、行为等。

另外一种比较复杂的情况，是组件自带的数据请求能力，比如 ProTable、Select、Form 等，而且一般都需要解决数据处理问题，比如数据查询前需要对入参进行格式调整，拿到数据之后需要对出参进行格式校准等，是非常常见的操作，我们统一设计了 api 配置，除了满足基本的 url、method、data 设置外，还支持请求前后的 adaptor 设置，当然这里就是我们说的需要写脚本的地方，而且目前是整个 Wizard 唯一需要写脚本的地方，这部分还是有点复杂的，但是我们这里借助于 AI 的能力实现了只需要配置当前数据格式和你需要转换的数据格式，就可以生成转换脚本，并且支持对函数进行快速测试，如果没问题即可回填到配置中，以更低的成本实现脚本输出。

下面这个示例，相信大家一看左右结构就能明白研发同学的数据转换意图，此处不再啰嗦。

，时长00:27

其实这种功能在有了大模型之后，实现变得很简单，我们只需要设计一个合理的 prompts 即可，虽然输出的脚本有时候有点啰嗦，但是准确率和稳定性还是比较高的。

高效初始化页面

俗话说“万事开头难”，页面 0 到 1 的成本如何降到尽可能的低是我们一直比较追求的，因为这样可以有效降低全栈门槛，我们主要通过以下三个手段：

通过页面模版初始化

针对 CQUD 的场景，我们沉淀了比较多的示例，基本能够涵盖系统需要的常见交互和功能诉求，这是最基础的做法，全栈同学选择模版创建后，修改下配置即可满足页面诉求。

通过接口元数据生成页面

上面提到得物的 Mooncake 平台，沉淀了得物所有接口的出入参信息，Wizard 可以做到选择接口和页面类型生成页面描述，根据接口类型，可以选择生成列表、表单、详情，可以复制到页面中成为页面主体或者一部分。

根据 PRD 描述快速生成页面

这个是为了解决上面“吐槽”中提到的第5点，很多 PRD 对于中后台需求描述过于简单，没有草图说明，即使有草图，对于全栈同学也不一定知道怎么还原 UI，Wizard 训练了自有的大模型（关于模型训练，后面章节会介绍），

做到对 Wizard 足够了解，可以结合 PRD 描述快速生成页面效果（插件 Wizard Proto），我们只需要提供标准的描述页面功能的文本格式，产品同学按照格式填空书写页面结构即可，具体实现细节参考：大模型在产品原型生成中的应用实践，

通过 Proto 生成的页面既可以帮助产品用最低的成本还原页面原型，又可以帮助研发同学快速还原 UI。

同时我们看到视频中给予产品一定的 UI 配置能力，但是这远远不足，长远的规划上看，大模型在此步的应用只是为了快速生成，而后还是需要提供更加完备的可视化配置能力完成页面 UI 和交互配置（或者换句话说，大模型的应用是为了让产品和技术快速上手），并且这部分配置是可以沿用到全栈开发，我们希望能够做到 CQUD 的 UI 工作在 PRD 阶段搞定，全栈同学的主要工作是做接口配置和功能校准即可，当然这个是很理想的状态，但是我们希望全栈研发同学的单页面输出成本降低到 0.5 人日以下，同时不增加产品的成本。

智能答疑

前面提到的 Wizard 自有大模型，还承担着另外一个比较重要的角色，就是辅助全栈同学答疑，比如：

同时我们也会支持针对回答的内容进行正向和负向反馈，这些反馈也会用于丰富我们的训练池，让大模型准确率越来越高。

这部分能力目前使用率还不够高，根本问题还是准确率问题，关于下一步的规划，下面章节会提到。

大模型训练和应用

Wizard 应用的基础大模型是更擅长做代码生成的 DeepSeek Coder，我们使用的版本参数个数是 6.7b，但其实模型准确率如何，核心是训练的数据源怎么搞定，Wizard 不像 Antd 或者 React 一样属于应用广泛的开源产品，社区有大量的代码、文章等让 ChatAIGC 进行训练，Wizard 的训练数据需要我们自己整理，思路如下：