GPT：低代码的终局性机遇

在低代码领域，随着不时榨干传统图形交互潜能，以及受限于传统软件开发思维框架，进一步进步“易用性”逐步遭遇了瓶颈。而这种易用性的窘境可能会因为GPT的成熟迎来新的机遇，本文作者对GPT带来的低代码新机遇停止了分析，一起来看一下吧。

一、低代码的易用性困局

作为一个承载了人们对于“全民数字化”美好期许的技术方向，低代码领域过去二十年，在不时降低软件开发门槛的道路一路狂奔。然而，随着不时榨干传统图形交互潜能，以及受限于传统软件开发思维框架，进一步进步“易用性”逐步遭遇了瓶颈。

市场上的低代码产品解题思路是类似的：通过可视化拖拉拽的编程方式，使得非专业程序员也可以快速地构建应用程序，从而降低软件开发本钱、进步开发效率。但大家不得不面对的是，即便通过可视化编排，对于特定领域DSL生成门槛仍然不低。而这种易用性的窘境可能会因为GPT的成熟迎来新的机遇。

目前的低代码产品，为了降低学习门槛，普遍将一个应用笼统为四个对象：页面、流程、逻辑、数据。

可视化拖拉拽的方式，对于页面搭建的提效是最为显著的，通过组件拼装，无需专业的前端知识，一个小白经过简单指导，也可以快速搭建出一个规范中后台管理系统或者营销H5页面。比起页面的直观，流程的可视化就稍显笼统，不过，得益于类似流程图的编排方式，非技术用户也是可以自主编排OA签报、工单流转等大多数数字办公场景。

相比前两者，对于逻辑、数据流的可视化编排，在易用性上不时给行业带来不小的挑战。通常的做法是将我们平时写代码的一些常用方法，笼统为一个个算子组件，以“触发条件+事件”的格式引导用户停止配置。但在这个过程中，仍然对用户的业务笼统推理才干有较高的要求。

例如：一个入库管理中，物料入库更新库存数的动作，通过可视化逻辑编排也大约需要定义：数据新增时触发、获取数据、计算库存、更新库存数、以及相关限定条件判断等不少于五个节点，涉及配置项超越10个，而这已经是行业的头部产品一再简化之后给出的高分答卷。对于数据流的处置也在面临同样的挑战。

现有思路逐步进入瓶颈，再进一步，更多是增加海量应用模板——降低用户需要自行配置的概率，或者，增加辅助引导——进步用户对于操作的理解才干。

但这些，其实很难从数量级上降低这类配置搭建的难度。很长一段时间，低代码的易用性问题也就囿于“可视化”的框架得不到突破。

GPT的呈现，给低代码从业者带来了新的机遇。

二、GPT带来的低代码新机遇

1. AIGC突破低代码的“易搭”困局


在一个数字化系统“搭建”过程中，无论是流程编排还是逻辑流设计，实质是将业务语言转化为系统语言，是对于业务流程、规范、限定的数字化“翻译”。

传统IT开发经历机器语言、汇编语言、高级语言，到领域特定的DSL，编程语言的演进不时在朝着提供更高层次的笼统和更易用的语法方向开展，使开发者可以更快速、更有效地表达和处置问题。虽然GPT自身并不能作为一种编程语言，但借助GPT这样的LLM（大语言模型，Large Language Model）对于自然语言的处置才干，配合相应的模型训练，可以直接生成特定领域的代码，从而建立起从自然语言直接到领域代码的桥梁。

低代码的演进开展的过程中，为理处置易用性的问题，不时在停止着“无限枚举”的工作，无论是对于组件配置属性的构造化、对于显影规则/校验规则这样的前端事件配置化，还是对于流程编排的事件节点提取、对于逻辑方法的算子封装，底层都是对于特定领域代码的笼统化，与传统编程语言的演进方式非常类似，为利用LLM处置这类场景问题，提供了天然的条件。

例如，我们前文提到四大对象之一的流程编排，其底层工作流引擎就有像BPMN2.0这样行业较为通用的规范化协议，通过定义了一套符号和规范，来描绘业务流程的各个元素、流程逻辑、参与者角色、任务、事件等。

2022年十月，微软发布了AIGC在他们流程自动化Power Automate模块中的应用，其中就展示了基于自然语言描绘一个业务流，系统会给出相应的流程示例，再经过用户自定义调整，最终生成一个系统的自动化流程。

我们在低代码借助大语言模型AIGC才干，处置应用搭建易用性问题的过程中，还是遇到了一些较为明确的挑战。

1）领域数据稀缺性

要训练GPT模型生成特定领域的代码，首先需要搜集并准备足够的领域代码数据集，并停止数据清洗、预处置和标注，以便用于训练。

不同于GPT-3.5训练时广泛采用了，包括了互联网上的大量文本、书籍、文章、对话记录在内的几千亿个单词。像BPMN2.0协议代码这样的语料，相比较之下要小好几个数量级。同时，像页面表单Schema、规则逻辑引擎的DSL代码各个厂商之间的差别化宏大，很难找到标注完成的高质量语料。因而，各个厂商不得不自主停止数据清洗、标注，“消费”出可以停止训练的高质量数据，这也是我们正在停止贮藏工作。

2）领域理解和需求一致性

做过需求访谈的同学应该有很深化的感受，引导用户清楚描绘自己的需求或者协助用户梳理业务自身就是一个非常有挑战性的问题，加上中文很强的二义性特征，准确描绘需求自身是有难度的。

DSL代码需要准确表达特定的业务逻辑和行为，才可以被低代码平台或工具正确地解析和执行。从实际场景到需求描绘、从需求描绘到DSL、DSL到系统执行，整个链路上进步信噪比、保证语义一致性是至关重要的。

3）人工后处置交互

为了保证最终产物的准确性以及可用性，对于AI生成的输出通常要提供可停止人工后处置（post-processing）的才干。在这个过程中需要做到不引入新概念、减少用户编辑其他中间产物，才干不增加用户理解本钱。我们看到微软和国内一些厂商，采用了举例多个结果+多轮次对话调整的方案，确实是一个很有价值的探究方向。

2. LUI助力面向结果的数字化系统


间隔施乐公司最早推出基于GUI（Graphical User Interface）的用户操作界面，已经过去了50多年，经苹果、Windows发扬光大，通过鼠标在屏幕操作可视化图标的交互方式，主导着软件工业开展，多年以来，万变不离其宗的数据列表、各种图表工作台，构成了我们绝大多数面向企业管理的数字化系统。

当我们回过头来考虑企业数字化的实质终究是什么？从企业主的角度来看就是——助经营。为了到达这个目的，我们传统的SaaS是怎么协同的：ERP、CRM、CMS、PMS这类系统处置流程在线、自动化的问题，并且完成数据采集，再将数据通过BI类工具停止分析、以及可视化呈现，最终体现为一个可以“指导”业务开展的数据洞察。对于企业主来讲，第一目的始终都是这个所谓的“经营建议”，过程管理更多时候只是为了到达这个目的的副产物和辅助。

相较于GUI需要不时通过点按、拖拽的交互，直接使用自然语言停止直接面向结果的交互才是人机交互的终局形态，谁会不期望自己有一个贾维斯呢？

自上个世纪90年代贾力尼克利用语言模型将语音识别的错误率控制到了10%以内，语言模型的产品价值崭露头角，后来经过引入语法语音等语言知识、借助云计算的海量资源、结合深度学习等，迭代成为了这一代生成式（Generative）大语言模型为LUI（自然语言交互界面，Language User Interface）的突破带来了可能。作为一种新的交互，无论是微软365 Copilot，还是国内飞书、钉钉推出的AI工具，都在强调通过自然语言描绘一个目的，AI直接生成对应的结果，而省去用户在传统系统中“阅读”、“发现”的过程。

网易数帆在新发布的CodeWave智能开发平台中，展示了通过对AI助手描绘目的，系统自动生成对于应用数据的聚合统计表，并对可能的异常数据停止了标注，展示了自然语言交互带来的便利和高效。

相较于GPT在AIGC领域所面临的诸多挑战，凭仗LLM较强的泛化才干，基于自然语言对话的形式，可以在LUI方向获得更快的进步与普及。

三、GPT交融低代码探究地图

根据技术成熟度以及应用方向的匹配性，结合低代码产品生命周期现状，将GPT交融低代码的探究分为了三个阶段。

一阶段：提供更便利的AI智能问答接入才干


作为一个正在带来产业革新的新技术，ChatGPT这样的语言模型，还处在技术采用生命周期中“创新者”（Innovator）阶段，正在完好从创新者到“早期群众”（Early Adopters）的跨越。因而，第一阶段的应用，还是围绕这一代LLM最成熟的才干——智能问答。低代码作为快速搭建应用的平台工具，可以为用户提供快速接入GPT、并交融搭建业务应用的才干。

二阶段：基于LUI的业务化应用


基于智能问答的交互形式，以智能助手、智能机器人的产品化包装，用户通过发问来描绘需求或指令，系统可以理解用户意图并做出相应的响应和操作，结合ChatGPT和低代码开发平台的数据处置和可视化功能，为用户提供数据洞察的才干，协助用户直接地理解和利用数据，拓展数字化应用在企业“助经营”中的作用。在这个方向，智能知识库是成熟度最高，可以快速停止产品化包装的场景。

三阶段：AIGC面向结果的应用生成


GPT与低代码在较长时间跨度的交融赋能应该集中在代码、应用生成的方向。为了更好的准备数据集训练语料，早期阶段针对垂直领域停止模型训练以及产品化包装，例如自然语言生成表单Schema、自然语言生成工作流、自然语言生成逻辑流、数据流。后期探究通过自然语言生成完好应用，并可通过多轮对话完成人工后处置及应用迭代。

总结

GPT这类的大语言模型，在同低代码产品的交融赋能中，有两个很重要的方向：一是利用LLM较强的语言理解及泛化才干，协助数字化应用完成从GUI到LUI的演进，为终端用户提供更友好、直接面向结果的人机交互体验；二是利用LLM生成式特性，通过AIGC方式协助应用搭建用户以自然语言对业务场景的描绘，生成相应的应用功能或完好应用。

GPT的呈现可以协助低代码产品突破长期陷入瓶颈的易用性问题，为低代码带来终局性机遇。

本文由 @小博 原创发布于人人都是产品经理，未经容许，制止借鉴

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者自己，人人都是产品经理平台仅提供信息存储空间效劳。

低代码其实可以对应以前的专家系统，后来被机器学习取代，所以低代码一定是绝路，人工智能根据要求自动编程，人类负责监视才是可行的道路。

转发了

说了半天没有落地产品，大家都是在搞理论研究吗？

没一个能到达商业化的

有意思

转发了

转发了

将来低代码必然结合人工智能，GPT让低代码更上一层楼

转发了