在低代碼領(lǐng)域，隨著不斷榨干傳統(tǒng)圖形交互潛能，以及受限于傳統(tǒng)軟件開發(fā)思維框架，進一步提高“易用性”逐漸遭遇了瓶頸。而這種易用性的困境可能會因為GPT的成熟迎來新的機遇，本文作者對GPT帶來的低代碼新機遇進行了分析，一起來看一下吧。

一、低代碼的易用性困局

作為一個承載了人們對于“全民數(shù)字化”美好期許的技術(shù)方向，低代碼領(lǐng)域過去二十年，在不斷降低軟件開發(fā)門檻的道路一路狂奔。然而，隨著不斷榨干傳統(tǒng)圖形交互潛能，以及受限于傳統(tǒng)軟件開發(fā)思維框架，進一步提高“易用性”逐漸遭遇了瓶頸。

市場上的低代碼產(chǎn)品解題思路是相似的：通過可視化拖拉拽的編程方式，使得非專業(yè)程序員也能夠快速地構(gòu)建應(yīng)用程序，從而降低軟件開發(fā)成本、提高開發(fā)效率。但大家不得不面對的是，即便通過可視化編排，對于特定領(lǐng)域DSL生成門檻依然不低。而這種易用性的困境可能會因為GPT的成熟迎來新的機遇。

目前的低代碼產(chǎn)品，為了降低學習門檻，普遍將一個應(yīng)用抽象為四個對象：頁面、流程、邏輯、數(shù)據(jù)。

可視化拖拉拽的方式，對于頁面搭建的提效是最為顯著的，通過組件拼裝，無需專業(yè)的前端知識，一個小白經(jīng)過簡單指導(dǎo)，也可以快速搭建出一個標準中后臺管理系統(tǒng)或者營銷H5頁面。比起頁面的直觀，流程的可視化就稍顯抽象，不過，得益于類似流程圖的編排方式，非技術(shù)用戶也是可以自主編排OA簽報、工單流轉(zhuǎn)等大多數(shù)數(shù)字辦公場景。

相比前兩者，對于邏輯、數(shù)據(jù)流的可視化編排，在易用性上一直給行業(yè)帶來不小的挑戰(zhàn)。通常的做法是將我們平時寫代碼的一些常用方法，抽象為一個個算子組件，以“觸發(fā)條件+事件”的格式引導(dǎo)用戶進行配置。但在這個過程中，依然對用戶的業(yè)務(wù)抽象推理能力有較高的要求。

例如：一個入庫管理中，物料入庫更新庫存數(shù)的動作，通過可視化邏輯編排也大約需要定義：數(shù)據(jù)新增時觸發(fā)、獲取數(shù)據(jù)、計算庫存、更新庫存數(shù)、以及相關(guān)限定條件判斷等不少于五個節(jié)點，涉及配置項超過10個，而這已經(jīng)是行業(yè)的頭部產(chǎn)品一再簡化之后給出的高分答卷。對于數(shù)據(jù)流的處理也在面臨同樣的挑戰(zhàn)。

現(xiàn)有思路逐漸進入瓶頸，再進一步，更多是增加海量應(yīng)用模板——降低用戶需要自行配置的概率，或者，增加輔助引導(dǎo)——提高用戶對于操作的理解能力。

但這些，其實很難從數(shù)量級上降低這類配置搭建的難度。很長一段時間，低代碼的易用性問題也就囿于“可視化”的框架得不到突破。

GPT的出現(xiàn)，給低代碼從業(yè)者帶來了新的機遇。

二、GPT帶來的低代碼新機遇

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

在一個數(shù)字化系統(tǒng)“搭建”過程中，無論是流程編排還是邏輯流設(shè)計，本質(zhì)是將業(yè)務(wù)語言轉(zhuǎn)化為系統(tǒng)語言，是對于業(yè)務(wù)流程、規(guī)范、限定的數(shù)字化“翻譯”。

傳統(tǒng)IT開發(fā)經(jīng)歷機器語言、匯編語言、高級語言，到領(lǐng)域特定的DSL，編程語言的演進一直在朝著提供更高層次的抽象和更易用的語法方向發(fā)展，使開發(fā)者能夠更快速、更有效地表達和解決問題。雖然GPT本身并不能作為一種編程語言，但借助GPT這樣的LLM（大語言模型，Large Language Model）對于自然語言的處理能力，配合相應(yīng)的模型訓練，可以直接生成特定領(lǐng)域的代碼，從而建立起從自然語言直接到領(lǐng)域代碼的橋梁。

低代碼的演進發(fā)展的過程中，為了解決易用性的問題，一直在進行著“無限枚舉”的工作，無論是對于組件配置屬性的結(jié)構(gòu)化、對于顯影規(guī)則/校驗規(guī)則這樣的前端事件配置化，還是對于流程編排的事件節(jié)點提取、對于邏輯方法的算子封裝，底層都是對于特定領(lǐng)域代碼的抽象化，與傳統(tǒng)編程語言的演進方式非常類似，為利用LLM處理這類場景問題，提供了天然的條件。

例如，我們前文提到四大對象之一的流程編排，其底層工作流引擎就有像BPMN2.0這樣行業(yè)較為通用的標準化協(xié)議，通過定義了一套符號和規(guī)范，來描述業(yè)務(wù)流程的各個元素、流程邏輯、參與者角色、任務(wù)、事件等。

2022年十月，微軟發(fā)布了AIGC在他們流程自動化Power Automate模塊中的應(yīng)用，其中就展示了基于自然語言描述一個業(yè)務(wù)流，系統(tǒng)會給出相應(yīng)的流程示例，再經(jīng)過用戶自定義調(diào)整，最終生成一個系統(tǒng)的自動化流程。

我們在低代碼借助大語言模型AIGC能力，解決應(yīng)用搭建易用性問題的過程中，還是遇到了一些較為明確的挑戰(zhàn)。

1）領(lǐng)域數(shù)據(jù)稀缺性

要訓練GPT模型生成特定領(lǐng)域的代碼，首先需要收集并準備足夠的領(lǐng)域代碼數(shù)據(jù)集，并進行數(shù)據(jù)清洗、預(yù)處理和標注，以便用于訓練。

不同于GPT-3.5訓練時廣泛采用了，包括了互聯(lián)網(wǎng)上的大量文本、書籍、文章、對話記錄在內(nèi)的幾千億個單詞。像BPMN2.0協(xié)議代碼這樣的語料，相比較之下要小好幾個數(shù)量級。同時，像頁面表單Schema、規(guī)則邏輯引擎的DSL代碼各個廠商之間的差異化巨大，很難找到標注完成的高質(zhì)量語料。因此，各個廠商不得不自主進行數(shù)據(jù)清洗、標注，“生產(chǎn)”出能夠進行訓練的高質(zhì)量數(shù)據(jù)，這也是我們正在進行儲備工作。

2）領(lǐng)域理解和需求一致性

做過需求訪談的同學應(yīng)該有很深刻的感受，引導(dǎo)用戶清楚描述自己的需求或者幫助用戶梳理業(yè)務(wù)本身就是一個十分有挑戰(zhàn)性的問題，加上中文很強的二義性特征，準確描述需求本身是有難度的。

DSL代碼需要準確表達特定的業(yè)務(wù)邏輯和行為，才能夠被低代碼平臺或工具正確地解析和執(zhí)行。從實際場景到需求描述、從需求描述到DSL、DSL到系統(tǒng)執(zhí)行，整個鏈路上提高信噪比、保證語義一致性是至關(guān)重要的。

3）人工后處理交互

為了保證最終產(chǎn)物的準確性以及可用性，對于AI生成的輸出通常要提供可進行人工后處理（post-processing）的能力。在這個過程中需要做到不引入新概念、減少用戶編輯其他中間產(chǎn)物，才能不增加用戶理解成本。我們看到微軟和國內(nèi)一些廠商，采用了舉例多個結(jié)果+多輪次對話調(diào)整的方案，的確是一個很有價值的探索方向。

2. LUI助力面向結(jié)果的數(shù)字化系統(tǒng)

距離施樂公司最早推出基于GUI（Graphical User Interface）的用戶操作界面，已經(jīng)過去了50多年，經(jīng)蘋果、Windows發(fā)揚光大，通過鼠標在屏幕操作可視化圖標的交互方式，主導(dǎo)著軟件工業(yè)發(fā)展，多年以來，萬變不離其宗的數(shù)據(jù)列表、各種圖表工作臺，構(gòu)成了我們絕大多數(shù)面向企業(yè)管理的數(shù)字化系統(tǒng)。

當我們回過頭來思考企業(yè)數(shù)字化的本質(zhì)究竟是什么？從企業(yè)主的角度來看就是——助經(jīng)營。為了達到這個目標，我們傳統(tǒng)的SaaS是怎么協(xié)同的：ERP、CRM、CMS、PMS這類系統(tǒng)解決流程在線、自動化的問題，并且完成數(shù)據(jù)采集，再將數(shù)據(jù)通過BI類工具進行分析、以及可視化呈現(xiàn)，最終體現(xiàn)為一個可以“指導(dǎo)”業(yè)務(wù)發(fā)展的數(shù)據(jù)洞察。對于企業(yè)主來講，第一目標始終都是這個所謂的“經(jīng)營建議”，過程管理更多時候只是為了達到這個目標的副產(chǎn)物和輔助。

相較于GUI需要不斷通過點按、拖拽的交互，直接使用自然語言進行直接面向結(jié)果的交互才是人機交互的終局形態(tài)，誰會不期望自己有一個賈維斯呢？

自上個世紀90年代賈力尼克利用語言模型將語音識別的錯誤率控制到了10%以內(nèi)，語言模型的產(chǎn)品價值嶄露頭角，后來經(jīng)過引入語法語音等語言知識、借助云計算的海量資源、結(jié)合深度學習等，迭代成為了這一代生成式（Generative）大語言模型為LUI（自然語言交互界面，Language User Interface）的突破帶來了可能。作為一種新的交互，無論是微軟365 Copilot，還是國內(nèi)飛書、釘釘推出的AI工具，都在強調(diào)通過自然語言描述一個目標，AI直接生成對應(yīng)的結(jié)果，而省去用戶在傳統(tǒng)系統(tǒng)中“瀏覽”、“發(fā)現(xiàn)”的過程。

網(wǎng)易數(shù)帆在新發(fā)布的CodeWave智能開發(fā)平臺中，展示了通過對AI助手描述目標，系統(tǒng)自動生成對于應(yīng)用數(shù)據(jù)的聚合統(tǒng)計表，并對可能的異常數(shù)據(jù)進行了標注，展示了自然語言交互帶來的便捷和高效。

相較于GPT在AIGC領(lǐng)域所面臨的諸多挑戰(zhàn)，憑借LLM較強的泛化能力，基于自然語言對話的形式，可以在LUI方向獲得更快的進步與普及。

三、GPT融合低代碼探索地圖

根據(jù)技術(shù)成熟度以及應(yīng)用方向的匹配性，結(jié)合低代碼產(chǎn)品生命周期現(xiàn)狀，將GPT融合低代碼的探索分為了三個階段。

一階段：提供更便捷的AI智能問答接入能力

作為一個正在帶來產(chǎn)業(yè)變革的新技術(shù)，ChatGPT這樣的語言模型，還處在技術(shù)采用生命周期中“創(chuàng)新者”（Innovator）階段，正在完整從創(chuàng)新者到“早期大眾”（Early Adopters）的跨越。因此，第一階段的應(yīng)用，還是圍繞這一代LLM最成熟的能力——智能問答。低代碼作為快速搭建應(yīng)用的平臺工具，可以為用戶提供快速接入GPT、并融合搭建業(yè)務(wù)應(yīng)用的能力。

二階段：基于LUI的業(yè)務(wù)化應(yīng)用

基于智能問答的交互形式，以智能助手、智能機器人的產(chǎn)品化包裝，用戶通過提問來描述需求或指令，系統(tǒng)能夠理解用戶意圖并做出相應(yīng)的響應(yīng)和操作，結(jié)合ChatGPT和低代碼開發(fā)平臺的數(shù)據(jù)處理和可視化功能，為用戶提供數(shù)據(jù)洞察的能力，幫助用戶直接地理解和利用數(shù)據(jù)，拓展數(shù)字化應(yīng)用在企業(yè)“助經(jīng)營”中的作用。在這個方向，智能知識庫是成熟度最高，能夠快速進行產(chǎn)品化包裝的場景。

三階段：AIGC面向結(jié)果的應(yīng)用生成

GPT與低代碼在較長時間跨度的融合賦能應(yīng)該集中在代碼、應(yīng)用生成的方向。為了更好的準備數(shù)據(jù)集訓練語料，早期階段針對垂直領(lǐng)域進行模型訓練以及產(chǎn)品化包裝，例如自然語言生成表單Schema、自然語言生成工作流、自然語言生成邏輯流、數(shù)據(jù)流。后期探索通過自然語言生成完整應(yīng)用，并可通過多輪對話完成人工后處理及應(yīng)用迭代。

總結(jié)

GPT這類的大語言模型，在同低代碼產(chǎn)品的融合賦能中，有兩個很重要的方向：一是利用LLM較強的語言理解及泛化能力，幫助數(shù)字化應(yīng)用完成從GUI到LUI的演進，為終端用戶提供更友好、直接面向結(jié)果的人機交互體驗；二是利用LLM生成式特性，通過AIGC方式幫助應(yīng)用搭建用戶以自然語言對業(yè)務(wù)場景的描述，生成相應(yīng)的應(yīng)用功能或完整應(yīng)用。

GPT的出現(xiàn)可以幫助低代碼產(chǎn)品突破長期陷入瓶頸的易用性問題，為低代碼帶來終局性機遇。