在低代码领域，随着不断榨干传统图形交互潜能，以及受限于传统软件开发思维框架，进一步提高“易用性”逐渐遭遇了瓶颈。而这种易用性的困境可能会因为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 协议
