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

一、低代碼的易用性困局

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

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

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

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

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

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

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

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

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

二、GPT帶來的低代碼新機(jī)遇

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

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

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

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

例如，我們前文提到四大對象之一的流程編排，其底層工作流引擎就有像BPMN2.0這樣行業(yè)較為通用的標(biāo)準(zhǔn)化協(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ù)稀缺性

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

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

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

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

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

3）人工后處理交互

為了保證最終產(chǎn)物的準(zhǔn)確性以及可用性，對于AI生成的輸出通常要提供可進(jìn)行人工后處理（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ā)揚光大，通過鼠標(biāo)在屏幕操作可視化圖標(biāo)的交互方式，主導(dǎo)著軟件工業(yè)發(fā)展，多年以來，萬變不離其宗的數(shù)據(jù)列表、各種圖表工作臺，構(gòu)成了我們絕大多數(shù)面向企業(yè)管理的數(shù)字化系統(tǒng)。

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

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

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

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

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

三、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)用

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

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

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

總結(jié)

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

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

本文由 @小博 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。