GPT 出現(xiàn)后，對于低代碼產(chǎn)品的影響、沖擊一直是一個懸而未決的問題。事實(shí)上 GPT 不僅不會干掉低代碼產(chǎn)品，還可以幫助低代碼產(chǎn)品做得更好。
最近開始梳理網(wǎng)易 CodeWave 智能開發(fā)平臺平臺的 AI 方向，本文會從產(chǎn)品技術(shù)角度詳細(xì)聊聊 AI+低代碼結(jié)合的機(jī)會，以及 CodeWave 低代碼平臺如何通過 AI 能力，大幅降低低代碼產(chǎn)品的開發(fā)門檻，提升產(chǎn)品競爭力的一些實(shí)踐。
01 低代碼的困境
低代碼市場目前已經(jīng)達(dá)到了50億規(guī)模左右，并且以年30%的復(fù)合增長率高速增長，低代碼產(chǎn)品也成了用戶降本增效的重要選擇之一。那對于市場上的諸多低代碼產(chǎn)品，用戶最看重什么呢？用戶實(shí)際使用低代碼產(chǎn)品的體驗(yàn)如何？
在我們的市場調(diào)研過程中發(fā)現(xiàn)，70%的用戶會把“用戶體驗(yàn)”作為重要的關(guān)注方向，用戶會深入關(guān)注低代碼產(chǎn)品的交互、操作等，并且直接會作為自己決策的依據(jù)之一。
同時，45.3%的企業(yè)用戶覺得，目前采購的低代碼平臺并不好用，其中70%為中小型企業(yè)。
為什么會這樣？說好的降本增效呢？我們來分析一下。
下面看這張圖：
獻(xiàn)丑了，這是 CodeWave 平臺對接登陸的一個邏輯編排過程。我們可以看到需要做這樣的一個登陸邏輯，需要對登陸的全流程、Http 基礎(chǔ)知識、日志等功能模塊、加密解密都非常熟悉，同時要熟悉低代碼平臺調(diào)用接口、賦值、設(shè)置 Header、打日志、解析數(shù)據(jù)等操作。一般來講一個熟練的低代碼教練可能要花費(fèi)一天左右時間來完成這段邏輯的搭建，而對于一個完全不懂開發(fā)的人員來講，他完全無法實(shí)現(xiàn)這塊邏輯。
事實(shí)上，對于一個熟練的后端開發(fā)者來講，用代碼實(shí)現(xiàn)這段邏輯可能也就花費(fèi)一個小時左右。這里暴露了低代碼重要的一個問題：定制開發(fā)的使用門檻太高，效率太低。低代碼產(chǎn)品進(jìn)入到企業(yè)當(dāng)中，首先要通過平臺完成很多定制開發(fā)工作，以便跟企業(yè)自身it設(shè)施集成，這個過程一般通過低代碼平臺的邏輯編排或者流程編排能力，要求用戶在熟悉編碼能力的基礎(chǔ)上使用平臺進(jìn)行搭建，其使用門檻相當(dāng)高。
CodeWave 平臺也經(jīng)常會走進(jìn)客戶去了解客戶實(shí)際的反饋。在一次調(diào)研中我們發(fā)現(xiàn)，邏輯編排這塊反饋的問題非常多：
邏輯模塊的問題中，最高頻的問題：問題邏輯閱讀（69%），其次是邏輯編寫（56%）
邏輯閱讀
另外則是一個老生常談的話題：質(zhì)量問題。低代碼產(chǎn)品能做核心系統(tǒng)嗎？大部分低代碼產(chǎn)品并沒有考慮性能、高可用、安全、可觀測性等核心 Web 應(yīng)用不可或缺的部分，同時搭建者的良莠不齊，也無法保證邏輯、sql 、數(shù)據(jù)建模的低代碼部分設(shè)計(jì)合理，沒有性能問題。擁有因此很多客戶選擇低代碼產(chǎn)品，只會構(gòu)建他們認(rèn)為不太重要的一些內(nèi)部管理系統(tǒng)、項(xiàng)目管理系統(tǒng)等。很多低代碼仍然無法解決核心應(yīng)用的搭建問題。
那么作為發(fā)展歷史有幾十年之久的低代碼廠商，會坐以待斃嗎？答案是不會的。目前的廠商逐步開始往以下這兩塊方向努力：
而隨著人工智能技術(shù)的發(fā)展，很多低代碼廠商逐步嘗試將人工智能技術(shù)引入，用于解決以上的兩個問題。
02 低代碼&AI業(yè)內(nèi)發(fā)展
Mendix & Outsystem 作為世界老牌低代碼廠商，2018年就開始在自己的低代碼平臺中引入 AI 技術(shù)。Mendix 10 發(fā)布時，首次提出了 AI-ENHANCED APP DEVELOPMENT 概念。他們的主要思路為人工智能輔助開發(fā)（AIAD），他們會將下一代產(chǎn)品引入生成式人工智能（AIGC）。同時，生成式AI加入低代碼和無代碼開發(fā)平臺，將會進(jìn)一步降低使用低代碼和無代碼開發(fā)工具的門檻，并或?qū)⒄Q生新的智能開發(fā)技術(shù)。
Mendix 的思路以 AI 輔助編程為主（https://www.mendix.com/platform/ai/）。舉例來講，由于他們擁有一個強(qiáng)大的 IDE ，他們的 AI assist 能力首先考慮用戶的編輯器體驗(yàn)。對于低代碼編輯器使用者來講，最頭疼的就是如何在一大堆組件和邏輯中快速選擇想要的了，所以 Mendix 從 IDE 的基本體驗(yàn)出發(fā)，參考代碼補(bǔ)全和代碼推薦的方式創(chuàng)造性地提出了節(jié)點(diǎn)推薦的方式:（如圖所示）
這種做法有效解決了“選擇困難癥”。AI 會根據(jù)用戶上下文計(jì)算推薦需要的內(nèi)容，并計(jì)算權(quán)重用來排序，很類似搜索引擎的工作。同時類似的工作還有著名數(shù)據(jù)可視化平臺 Tableau 的 Show Me 功能：
show me 則通過一系列的規(guī)則和數(shù)據(jù)類型的嗅探，智能的給用戶提示需要的圖表，有效的治療了用戶在數(shù)據(jù)可視化場景的“選擇困難癥”。
對于后起之秀來講，OutSystems 則從質(zhì)量出發(fā)，推出了 OutSystems AI Mentor System
這個產(chǎn)品另辟蹊徑，通過提示和改善用戶搭建應(yīng)用的質(zhì)量，來提升低代碼產(chǎn)品的可用性。
此類產(chǎn)品的思路更加貼近開發(fā)者，最重要的是能夠有效的提升搭建出來產(chǎn)品的質(zhì)量。AI Mentor System 會自動分析產(chǎn)品內(nèi)的技術(shù)債務(wù)并給出優(yōu)化建議，維度包括性能、安全、可維護(hù)性、架構(gòu)設(shè)計(jì)等。同時產(chǎn)品會掃描目前的代碼，判斷里面是否會存在不合理性。
目前 CodeWave 產(chǎn)品 language server 的一些檢查也屬于此類。通過一系列的代碼掃描和規(guī)則檢測，能夠有效避免用戶搭建不合理的代碼，構(gòu)造不合理的架構(gòu)，也利于企業(yè)IT能力的提升。
03 D2C 技術(shù)的發(fā)展
由于在低代碼搭建和日常編碼中，前端的還原效率一直被詬病，D2C 技術(shù)在近幾年也得到了長足的發(fā)展。通常的做法是解析設(shè)計(jì)稿中的 DSL 轉(zhuǎn)換為代碼，此種方式存在很多問題，比如邊界條件的處理，需要手動標(biāo)注等，因此一直沒有得到大規(guī)模的應(yīng)用。
2017年論文 Pix2Code 首次提出使用深度學(xué)習(xí)技術(shù)實(shí)現(xiàn) UI 截圖生成 UI 結(jié)構(gòu)描述，是人工智能技術(shù)結(jié)合前端的一次飛躍，也是首次“前端一絲論”的誕生。隨之而來 2018年微軟 AI Lab 開源了草圖轉(zhuǎn)代碼工具 Sketch2Code，2019年阿里巴巴開源 Imgcook，都是端智能技術(shù)蓬勃發(fā)展的寫照。
04 大模型的熱潮：AIGC 技術(shù)
從2022年3月 openai 悄然 beta 他們的開放 api 開始，到9月份 Stable Diffusion 的橫空出世，一直到12月 chatGPT 的發(fā)布，每個程序員都經(jīng)歷著日新月異的變革和是否會被代替掉的恐懼。
AIGC 技術(shù)的本質(zhì)是通過自然語言交互增強(qiáng)原先的人機(jī)交互，主要解決各種場景的使用門檻高、容易出錯、學(xué)習(xí)成本高的問題，因此 AIGC 主要分為以下的幾個方向：
辦公協(xié)同與內(nèi)容創(chuàng)作
辦公協(xié)同的代表作為 office copilot，以及國內(nèi)做辦公協(xié)同的 WPS、飛書、葡萄城等產(chǎn)品。此類產(chǎn)品通過自然語言驅(qū)動辦公軟件自動化生成產(chǎn)物，提升辦公效率。內(nèi)容創(chuàng)作的代表則是 Stable Diffusion、Jasper 等一眾通過自然語言創(chuàng)造文本音視頻的產(chǎn)品。這兩類由于大家接觸的很多，并且跟本文關(guān)系不大就不贅述了。重點(diǎn)講講另一塊 AIGC 技術(shù)：AI 代碼生成與智能體編程技術(shù)。
AI代碼生成底層技術(shù)的代表代表為一眾開源閉源代碼大模型，國外代表為 Code llama，StarCoder 等，國內(nèi)代表為 Codegeex，PanGu-Coder 等。此類技術(shù)競爭非常激烈，有官方的排名(sota humaneval）。產(chǎn)品代表當(dāng)然是我們耳熟能詳?shù)?nbsp;Github copilot 以及網(wǎng)易的 Codemaker 了。
而智能體編程技術(shù)我們會在后面的 AI 架構(gòu)部分詳細(xì)展開，這個概念被大眾所熟知來源于6月23日，OpenAI 專家提出了 《LLM Powered Autonomous Agents》概念，將智能體的通用架構(gòu)明確闡述出來。LLM 并不是無所不能的。在這種情況下，以插件等形式對大語言模型進(jìn)行能力拓展逐漸成為了一種有效形式。工具/插件的使用極大地拓寬了大語言模型的能力和應(yīng)用邊界。通常將 LLM 和工具的組合系統(tǒng)稱為“智能體”（又稱 Language Agents）。
因此基于智能體的編程框架如火如荼的出現(xiàn)了，智能體內(nèi)包含需求理解和一系列代碼生成插件，通過“一句話需求”，智能體框架就可以生成完整的可運(yùn)行的全棧代碼以及項(xiàng)目工程。智能體框架在23年得到了蓬勃發(fā)展，由于其借助一些 Prompt 技巧讓 LLM 擁有了任務(wù)調(diào)度能力，從而產(chǎn)生了過于玄幻的效果，被稱作 AGI (通用人工智能)的前夜 https://github.com/yzfly/Awesome-AGI-Agents
代碼生成技術(shù)以及智能體編程技術(shù)出現(xiàn)后，“程序員一絲”的言論又甚囂塵上，很多人表示自己每天的工作就是靠 copilot 來 tab ，然后等著 xxxGPT 來干掉自己。作為 github copilot 的測試用戶，copilot 工具確實(shí)大幅度提升了我糊業(yè)務(wù)的效率，因此很多人問，既然代碼生成技術(shù)那么成熟，還需要低代碼平臺甚至程序員干什么呢？我是不是一句需求過去，整個軟件能出來？（別笑，這就是客戶的疑問和心聲）
那 AI 代碼生成或者 copilot 能力為什么不能代替低代碼甚至程序員呢？我認(rèn)為有以下幾個原因：
1、程序設(shè)計(jì)語言是人用來指揮計(jì)算機(jī)干活的，是人與計(jì)算機(jī)的一種協(xié)議。自然語言是人類溝通的媒介，他的特點(diǎn)就是模糊性，很難精確跟需求冪等。而計(jì)算機(jī)語言才是程序精確運(yùn)行的必要條件。想象一下，你如何用自然語言來描述以下的界面
2、隨著復(fù)雜度上升，軟件開發(fā)已經(jīng)不是單純 coding 能夠完成，需要通過組件、服務(wù)的封裝以屏蔽細(xì)節(jié)。同時需要依賴業(yè)務(wù)背景知識的輸入才能夠構(gòu)建。由于 AIGC 依賴大模型無記憶，缺少現(xiàn)有 IT 資產(chǎn)和領(lǐng)域知識的輸入，很難在高度封裝的基礎(chǔ)上啟動開發(fā)。
這個我們就不展開講了，很容易理解，即使目前有 RAG 技術(shù)，也很難將領(lǐng)域知識或自己的代碼倉庫完全灌輸給模型并讓模型參考去生成我們想要的代碼。代碼生成技術(shù)通常只能生成那種比較底層的代碼，很難按照我們的需求逐步封裝，而這正是跟軟件開發(fā)相悖的。
3、一個需要穩(wěn)定運(yùn)行的系統(tǒng)需要很多的周邊設(shè)施，如中間件、存儲、運(yùn)維等。AIGC 技術(shù)目前只能有限的解決一些代碼生成問題。代碼編寫完就結(jié)束了嗎，那肯定不是的，不信你看這張圖：
4、基于各類評測，AIGC 仍然難以完成復(fù)雜度高、專業(yè)度高的編碼工作，甚至在一些簡單場景的表現(xiàn)都較差。這里我們還是以事實(shí)說話，由于我之前做醫(yī)療的，我就問了他一些醫(yī)療的專業(yè)知識，回答當(dāng)然是啼笑皆非的。同樣回到剛才所講的智能體技術(shù)，我們也可以從下圖中某個開源智能體框架的評測中看到，只有少數(shù)簡單的場景能夠用智能體編程實(shí)現(xiàn)，稍微復(fù)雜點(diǎn)就完全無法實(shí)現(xiàn)了，評價為不如直接復(fù)制粘貼。
事實(shí)上，構(gòu)建一個軟件從來都不是一個簡單的事情。即使讓一個 AI 來“寫代碼”，也并不是一件簡單的事情。我們看下圖：
以 Web 應(yīng)用為例，用戶需要學(xué)習(xí) js/java 等基礎(chǔ)語言，并在此基礎(chǔ)上學(xué)習(xí)前端框架、后端框架、數(shù)據(jù)定義、數(shù)據(jù)查詢以及流程引擎等框架、庫、DSL 等。對于 AI 生成來講，很難收斂技術(shù)，更別說精確到某種框架了。
究其原因傳統(tǒng)開發(fā)方式自由度過大，上下文復(fù)雜且不標(biāo)準(zhǔn)，概念太多，不利于 AI 構(gòu)建能夠收斂的應(yīng)用，往往用戶第一次描述的需求是模糊和發(fā)散的，一次生成往往很難達(dá)到用戶最終意圖。同時由于 AIGC 的編碼產(chǎn)品缺少所見即所得的能力，也很難讓用戶進(jìn)行需求的更改。同時應(yīng)用開發(fā)很復(fù)雜，從需求轉(zhuǎn)換成應(yīng)用本身需要設(shè)計(jì)很多模塊，編碼者需要具備的問題拆解和規(guī)劃能力AI是很難具備的。同時做過代碼生成模型訓(xùn)練的同學(xué)也會明白，開發(fā)場景不僅包括自有 IDE 知識，還包括用戶導(dǎo)入的接口、擴(kuò)展庫和SDK 等，知識眾多，很難讓 AI 完全學(xué)習(xí)。
那如果有什么機(jī)制或工具，既能夠從語言層面保證AI生成代碼的收斂和可維護(hù)性，又能借助現(xiàn)有的工具和庫，還能完成應(yīng)用從開發(fā)到上線托管的全流程，是不是能夠解決問題呢？這便是 CodeWave 低代碼平臺+AI 的實(shí)踐。
05 CodeWave 的實(shí)踐 NASL-做 AI 友好的低代碼設(shè)計(jì)
NASL 是網(wǎng)易數(shù)帆 CodeWave 智能開發(fā)平臺用于描述 Web 應(yīng)用的領(lǐng)域特定語言。它主要包含兩部分：基礎(chǔ)語言和 Web 應(yīng)用特定領(lǐng)域（如數(shù)據(jù)定義、數(shù)據(jù)查詢、頁面、流程、權(quán)限等）的子語言集合。他通過一套基礎(chǔ)的語言系統(tǒng)（例如類型、常量變量、表達(dá)式等）支撐了各種 Web 應(yīng)用的領(lǐng)域語言，做到了一套語言就可以描述 Web 應(yīng)用開發(fā)的方方面面。
基于這樣的設(shè)計(jì)，我們只需要構(gòu)建能夠生產(chǎn) NASL 的低代碼平臺，并將生成的 NASL 轉(zhuǎn)換為應(yīng)用實(shí)際運(yùn)行時的 java 和 js 代碼，就可以完成應(yīng)用從開發(fā)到構(gòu)建部署的全流程了。因此 CodeWave 提供了五個設(shè)計(jì)器專門來生產(chǎn) NASL，并提供了 language server 能力做實(shí)時的類型檢查，保證用戶開發(fā)產(chǎn)物的質(zhì)量，同時提供翻譯器在發(fā)布階段把 nasl 轉(zhuǎn)換為 java 和 js 代碼，產(chǎn)品架構(gòu)如下：
通過 Nasl 來定義編程語言，并以此設(shè)計(jì)低代碼平臺架構(gòu)的優(yōu)勢，主要體現(xiàn)在三點(diǎn)：
· 產(chǎn)品上限高。能夠通過豐富的表達(dá)能力來表達(dá) Web 開發(fā)中的各種場景，包括頁面、數(shù)據(jù)查詢、邏輯、流程等，并且可以根據(jù)業(yè)務(wù)的需求定制翻譯能力
· 質(zhì)量可控。盡可能減少專業(yè)概念的數(shù)量，通過類型檢查、靜態(tài)、動態(tài)分析和排錯來降低用戶寫出低質(zhì)量代碼的可能性。
· AI友好。通過統(tǒng)一的 NASL 語言及可擴(kuò)展的定義，可以方便的對大模型進(jìn)行訓(xùn)練后讓其生成，不需要讓大模型生成各種語言框架，這點(diǎn)是 CodeWave 平臺區(qū)別于其他低代碼平臺的重要因素：一顆大心臟。只有架構(gòu)本身對 AI 友好， 才能更好的結(jié)合 AIGC 能力。
基于這樣的架構(gòu)設(shè)計(jì)，我們就推出了一系列的 AI 能力：
我們很容易就能夠發(fā)現(xiàn)，如果把原來的編輯器通過用戶輸入代替，就能夠給低代碼平臺帶來各類自然語言的輔助功能。因此我們直接規(guī)劃了一系列的自然語言生成的場景：
根據(jù)之前調(diào)研的結(jié)果，我們優(yōu)先上線了自然語言生成邏輯的功能。CodeWave 智能開發(fā)平臺的開發(fā)者在使用低代碼平臺編寫邏輯時，首先需要深入理解業(yè)務(wù)邏輯，并將其轉(zhuǎn)化為可視化邏輯片段。他們需要能夠高效、高質(zhì)量地編寫邏輯，避免操作復(fù)雜、重復(fù)編寫的問題。有些開發(fā)者缺乏傳統(tǒng)代碼開發(fā)經(jīng)驗(yàn)，因此邏輯開發(fā)上手門檻較高，難度較大。為了解決這個問題，我們提供開發(fā)輔助，降低邏輯編寫門檻，幫助開發(fā)者快速上手，提高邏輯開發(fā)效率。
在技術(shù)調(diào)研時我們考慮了 LangChain 和 Agent 框架等，并確定了基于 LangChain（JS/TS版）框架的方案。
用戶確認(rèn)后的執(zhí)行計(jì)劃，與上下文生成的 ts 代碼，再結(jié)合檢索出的平臺資產(chǎn)上下文（包括擴(kuò)展邏輯和組件邏輯等），組裝成 Prompt 傳遞給大語言模型。
大語言模型按限定要求生成 ts 代碼，然后通過 ts2nasl 的 transformer 解析并轉(zhuǎn)換成 nasl json 格式。再結(jié)合原來用戶操作的上下文路徑，在編輯器中組合執(zhí)行。效果如下：
自然語言生成邏輯功能的上線大幅度提高了邏輯編寫的效率，降低了邏輯編寫門檻。采用對話式操作流程，開發(fā)者可以在編寫邏輯的過程中隨時向 AI 助手提問，并通過多輪對話詳細(xì)描述意圖。AI 助手會分析開發(fā)者的意圖并向開發(fā)者反饋，開發(fā)者可以根據(jù)分析內(nèi)容選擇是否執(zhí)行，如果不執(zhí)行，可以持續(xù)進(jìn)行對話。AI 助手可以自由展開或收起，隨時提問，隨時開啟新對話，并且支持同時在多個邏輯編輯頁面上開啟AI助手，高效輔助開發(fā)者進(jìn)行邏輯編寫。
簡單重復(fù)的邏輯不再需要復(fù)雜繁瑣的操作，生成的邏輯可復(fù)制拖動。對于復(fù)雜邏輯，開發(fā)者只需通過自然語言描述意圖即可快速生成。生成的邏輯可以進(jìn)行修改后使用。
CodeWave AIGC 能力基座：智能體架構(gòu)
隨著大模型技術(shù)的發(fā)展，為了支撐日益膨脹的 AI 需求，不僅僅傳統(tǒng)的人機(jī)界面交互會被顛覆，維持了很多年的存儲-領(lǐng)域模型-服務(wù)端-客戶端的應(yīng)用架構(gòu)也極有可能會被顛覆。我們迫切需要一個全新的架構(gòu)來構(gòu)筑 AI 應(yīng)用，Agent 架構(gòu)應(yīng)運(yùn)而生。
AI Agent 今年 4 月在開發(fā)者社區(qū)格外火熱，AutoGPT 成為 Github 歷史上漲星最快的項(xiàng)目。火熱的背后是 Agent 的思路為我們帶來了 Software 2.0 的圖景：LLM 作為推理引擎能力不斷增強(qiáng)，AI Agent 框架為其提供結(jié)構(gòu)化思考的方法，軟件生產(chǎn)進(jìn)入“3D 打印”時代，可以根據(jù)用戶需求進(jìn)行個性化定制，Agent 框架打造每個知識工作者信賴的 AI 工作伙伴。6月23日，OpenAI 專家提出了 《LLM Powered Autonomous Agents》概念（https://lilianweng.github.io/posts/2023-06-23-agent/）正式將 Agent 智能體架構(gòu)搬上舞臺。
Agent 和早期的 LLM-based 應(yīng)用相比，有幾個顯著差異點(diǎn)：
· 合作機(jī)制 orchestration：存在多模型、多 Agent 分工與交互的機(jī)制設(shè)計(jì)，能實(shí)現(xiàn)復(fù)雜的工作流。例如編程場景下可能有需求工程師 Agent 與編碼工程師 Agent。
· 與環(huán)境交互 grounding：Agent 能理解自己的不足，并適時從外部尋找合適的工具解決問題。例如目前很多 Agent 支持查詢搜索引擎內(nèi)容等。
· 個性化記憶 memory：能記憶用戶偏好和工作習(xí)慣，使用越久越了解用戶。例如目前廣泛使用的 RAG 技術(shù)來增強(qiáng) LLM 的記憶能力
· 主動決策 decision：Agent 有能力在虛擬環(huán)境中探索、試錯、迭代。這個能力目前主要依賴 prompt 技巧，例如cot/reAct/plan & solve 等。
由于低代碼平臺需要通過判斷用戶意圖來確定采用哪塊代碼生成能力，因此我們也使用了 Agent 架構(gòu)來構(gòu)建我們的低代碼平臺，并進(jìn)行了技術(shù)調(diào)研，包括提示工程（FewShot、CoT、ReAct、Agent等技術(shù)）、LangChain 和 Agent 框架等，確定了基于LangChain（JS/TS版）框架的方案。
我們建立了一個對話式的需求分析智能體（AnalyzerAgent），通過這個 Agent 來判讀用戶的意圖，并交給界面鏈（UIChain）或邏輯鏈（LogicChain）等，同時通過 nasl 語言轉(zhuǎn)換的方式來精簡 token，提高準(zhǔn)確率。我們還通過向量數(shù)據(jù)庫進(jìn)行擴(kuò)展庫的知識緩存，支持?jǐn)U展功能，解決 token 受限問題。
用戶的應(yīng)用上下文和交互上下文通過 json2nasl2ts 轉(zhuǎn)換成大語言模型能夠識別的 ts 代碼，如：
{ "concept": "IfStatement", "label": "條件分支", "test": {...}, "consequent": [ {...} ], "alternate": [...] }
if (isNameDuplicated == true) { nasl.ui.showMessage('重復(fù)的角色名！'); } else { ... }
結(jié)合經(jīng)過反垃圾之后的聊天內(nèi)容，再檢索出歷史經(jīng)驗(yàn)，組裝成 Prompt 傳遞給大語言模型。
大語言模型按照格式返回 { "plan": "...", "text": "...", "executable": "true/false" } 的 JSON 形式。當(dāng) executable 為 true 時，為用戶提供一個確認(rèn)執(zhí)行的按鈕。
基于 Agent 架構(gòu)，可以更好的識別用戶意圖，共享上下文和記憶，并提供 AI 應(yīng)用的橫向擴(kuò)展能力，方便接入更多的 AI 能力。
自然語言生成技術(shù)（AIGC）只是 AI 能力的一部分， 為了方便用戶使用平臺更好的搭建出高質(zhì)量的應(yīng)用，我們也提供了AI Coach能力。其中包括：
基于大模型與 NLG（自然語言生成）技術(shù)，對用戶、平臺生成的代碼邏輯、可視化圖表等進(jìn)行解讀，有效提升工作效率與團(tuán)隊(duì)協(xié)同效率。
CodeWave 智能開發(fā)平臺的開發(fā)者往往是一個團(tuán)隊(duì)，他們需要編寫邏輯同時也需要閱讀他人編寫的邏輯成果物，多人合作完成應(yīng)用的開發(fā)。然而，閱讀已有的邏輯成果物往往是一個難題，需要按照邏輯的聯(lián)絡(luò)一步一步閱讀，費(fèi)時費(fèi)力，可能會出現(xiàn)獲取錯誤信息的情況，從而無法有效支持邏輯的復(fù)用和協(xié)作開發(fā)，用各種優(yōu)化方式（如折疊、注釋等）效果也不大。因此，開發(fā)者需要能夠快速、準(zhǔn)確地閱讀已有的邏輯，并將邏輯片段簡要概括翻譯，為其他開發(fā)者提供幫助。
靈感來源于原來做數(shù)據(jù)可視化使用的 NLG（自然語言生成技術(shù)），NLG 的一個很重要的應(yīng)用就是解讀這些數(shù)據(jù)，自動的輸出結(jié)論和觀點(diǎn)。
我們利用 GPT 的能力，設(shè)計(jì)了對話式邏輯解讀方式，將低代碼 DSL 語言轉(zhuǎn)換成大語言模型熟悉的通用語言，提高準(zhǔn)確率；采用分段解讀技術(shù)，采取注釋原來位置的方式，讓大語言模型自行標(biāo)記所在位置。用戶的應(yīng)用上下文和交互上下文通過 json2nasl2ts 轉(zhuǎn)換成大語言模型能夠識別的 ts 代碼，其中會在邏輯塊中標(biāo)記原來 nasl 塊的位置信息。
結(jié)合經(jīng)過反垃圾之后的聊天內(nèi)容，再檢索出歷史確認(rèn)過的經(jīng)驗(yàn)，組裝成 Prompt 傳遞給大語言模型。
大語言模型按照格式返回Array<{ "content": "...", "jsonPath": "..." }>的 JSON 形式。
當(dāng)用戶點(diǎn)擊解讀后的某塊內(nèi)容時，可以定位到可視化邏輯中的相應(yīng)位置。
根據(jù)用戶操作上下文指導(dǎo)用戶后續(xù)工作，解決教練和用戶在使用平臺時“節(jié)點(diǎn)、組件太多了，我不知道該選擇什么”這一類問題。
節(jié)點(diǎn)推薦目前有兩條路線，一是通過統(tǒng)計(jì)分析的算法 N-gram 來驅(qū)動。
N-gram 是一種語言模型，他把文本中每一個字節(jié)片段稱為 gram，對所有 gram 的出現(xiàn)頻度進(jìn)行統(tǒng)計(jì)，并且按照事先設(shè)定好的閾值進(jìn)行過濾，形成關(guān)鍵 gram 列表，也就是這個文本的向量特征空間，列表中的每一種 gram 就是一個特征向量維度。該模型基于這樣一種假設(shè)，第 N 個詞的出現(xiàn)只與前面 N-1 個詞相關(guān)，而與其它任何詞都不相關(guān)，整句的概率就是各個詞出現(xiàn)概率的乘積。這些概率可以通過直接從語料中統(tǒng)計(jì) N 個詞同時出現(xiàn)的次數(shù)得到。
由于我們整個邏輯節(jié)點(diǎn)是由 Nasl 節(jié)點(diǎn)來描述，所以可以通過 N-gram 對 Nasl 節(jié)點(diǎn)的預(yù)測來完成節(jié)點(diǎn)的推薦功能。
按照此思路， AI 團(tuán)隊(duì)對目前現(xiàn)有應(yīng)用的邏輯節(jié)點(diǎn)進(jìn)行了抽取，分析
· 一共有11155個工程 json 文件，從中抽樣了200個文件進(jìn)行隔離
· 基于畫布名稱出現(xiàn)次數(shù)的統(tǒng)計(jì)，分別對每個工程文件中的所有畫布進(jìn)行了過濾
經(jīng)過調(diào)優(yōu)最終達(dá)到了一個比較好的效果：
但這條路線的問題在于，節(jié)點(diǎn)推薦只能推薦到節(jié)點(diǎn)粒度，對內(nèi)部邏輯的實(shí)現(xiàn)無法推薦。也就是說如果用戶選擇了一個接口，你只能推薦到“數(shù)據(jù)處理”，但沒法直接把整個數(shù)據(jù)處理過程補(bǔ)全。因此會有第二個方案：
第二條路線是基于 nasl 的文本補(bǔ)全，類似 copilot 的補(bǔ)全能力。
由于 nasl 本身也是代碼，因此如果將 nasl 交給代碼模型進(jìn)行學(xué)習(xí)，就有可能實(shí)現(xiàn)整段邏輯的補(bǔ)全，之后將補(bǔ)全邏輯轉(zhuǎn)換為可視化節(jié)點(diǎn)即可。
但這個方案也有不少問題：
-
用戶在 WebIDE 進(jìn)行可視化編程時，傳給 LLM 的語言是什么？json 形式的 nasl ？文本化 nasl ？ts or java？
-
json 形式的 nasl 理論上太過龐大，token 容易超出限制，導(dǎo)致上下文不完全
-
文本化 nasl ，理論上需要建立一套文本化的 nasl 語法，并建立大量樣本，給大模型學(xué)習(xí)，才有可能
-
借助于一門通用語言 nasl -> 通用語言 -> LLM -> recommend -> 詞語法分析 > 通用語言ast -> nasl ast
-
nasl中有很多的領(lǐng)域 DSL，通用語言不認(rèn)識：解決方案->開發(fā) edsl 函數(shù)庫，建立映射關(guān)系
1. 數(shù)據(jù)查詢子領(lǐng)域本身 recommend：select * from student left join ...
2. 數(shù)據(jù)查詢子領(lǐng)域與邏輯域結(jié)合 recommend：List students = select * from Student
3. 流程子領(lǐng)域 recommend：流程圖推薦
4. ......
-
鏈路較長，本身 LLM 就不快，性能問題是個較大的挑戰(zhàn)。需要建立實(shí)時編譯(nasl->sourcecode)與反編譯(sourcecode->nasl)的快速編譯機(jī)制
此方案目前也在探索中。
CodeWave 雖然是低代碼平臺，但用戶仍然會通過平臺搭建出難以維護(hù)的模塊和應(yīng)用。按照我們的梳理，用戶的搭建產(chǎn)物可能影響系統(tǒng)穩(wěn)定性的部分如下：
解決這類問題最先想到的便是靜態(tài)代碼分析方案，但由于平臺本身內(nèi)容均通過 NASL 去生成維護(hù)，傳統(tǒng)的靜態(tài)代碼掃描方案（如SonarQube）并不能滿足要求，因此低代碼平臺設(shè)計(jì)了一套基于 NASL 的代碼分析引擎，架構(gòu)如下：
除了靜態(tài)分析能夠涵蓋的內(nèi)容，針對用戶自定義編寫的復(fù)雜邏輯，平臺也會結(jié)合大模型的能力，讓大模型給出適合的重構(gòu)方案，其思路與 AI 邏輯解讀類似，只是要求大模型返回其中不合理的設(shè)計(jì)和邏輯。
Design2NASL-設(shè)計(jì)稿轉(zhuǎn) NASL
D2C 技術(shù)本身在公司內(nèi)的研究很多，如云音樂的海豹 D2C 就是非常優(yōu)秀的平臺能力。在此就不贅述了。但大模型能力大幅度發(fā)展的今天，傳統(tǒng) D2C 技術(shù)同樣能夠被大模型技術(shù)所增強(qiáng)。以下是 CodeWave 結(jié)合傳統(tǒng) D2C 技術(shù)的設(shè)計(jì)：
D2C 技術(shù)的本質(zhì)是設(shè)計(jì)稿/圖片的 schema 與代碼的互相轉(zhuǎn)換，最大的問題是頁面布局排版的最佳實(shí)踐，在編碼側(cè)和設(shè)計(jì)側(cè)是完全不一樣的，設(shè)計(jì)側(cè)需要平鋪，獲取到的內(nèi)容是在同一層級的，而在編碼階段（HTML+CSS），頁面元素通常會有嵌套關(guān)系。一般 D2C 技術(shù)需要寫很多的邊界 Case 來處理這樣的問題，例如：
區(qū)別于通常的 D2C 技術(shù)，CodeWave 這邊會采用大模型能力對轉(zhuǎn)換效果進(jìn)行優(yōu)化，由大模型來判斷哪些元素在編碼上需要進(jìn)行分組。
對于一個復(fù)雜的低代碼產(chǎn)品來講，文檔是極為重要的，傳統(tǒng)通過關(guān)鍵詞進(jìn)行搜索的文檔不僅搜索命中率不高，搜索出來的內(nèi)容也只能在單個文檔中查看，若用戶有跨場景的綜合需求，傳統(tǒng)的搜索能力就無法滿足了。
為此我們也接入了 AI 部門 Chat Document 背后的服務(wù)，其原理為目前火熱的 RAG 技術(shù)：
整個方案會將文檔切片，向量化后存儲到向量數(shù)據(jù)庫。當(dāng)用戶搜索時會首先在向量數(shù)據(jù)庫中查詢相似度高的內(nèi)容，之后將搜索出來的內(nèi)容交給大模型去加工、總結(jié)，最后返回答案。這樣不僅可以有效解決用戶搜索的效率，也能夠讓用戶更好地理解文檔的內(nèi)容。
未來我們也會跟 AI 團(tuán)隊(duì)一起，推出企業(yè)私有化知識庫的搭建解決方案，讓每個企業(yè)都可以用低代碼快速搭建自己的 copilot。
06 CodeWave 低代碼+AI 產(chǎn)品核心原則
在做低代碼跟 AI 結(jié)合的基礎(chǔ)上，為了保證用戶的體驗(yàn)，避免 AI 能力的突兀，真正做到潤物細(xì)無聲，我們也總結(jié)了一系列的 AI產(chǎn)品核心原則：
· 產(chǎn)品心智統(tǒng)一。Chat 類 AI 產(chǎn)品需要對話時的獨(dú)立上下文，用戶需要關(guān)注對話的交互操作。對于生產(chǎn)力工具，要避免 AI 功能與目前產(chǎn)品體驗(yàn)的使用割裂，做到無縫融入。
· 降低操作門檻。生成式 AI 本質(zhì)是基于自然語言的人機(jī)交互生產(chǎn)力產(chǎn)品，目標(biāo)是幫助用戶提升使用效率，如果 AI 能力的接入反而提升了用戶的操作門檻，這類產(chǎn)品就失去了原本的意義了。
· 推動最佳實(shí)踐。AI 真正體現(xiàn)“智能化”，不僅是通過大模型的 Zero shot 能力體現(xiàn)，還要跟目前產(chǎn)品自身的數(shù)據(jù)資產(chǎn)、技術(shù)資產(chǎn)積累結(jié)合起來，體現(xiàn)企業(yè)自身的技術(shù)優(yōu)勢。
· 避免額外風(fēng)險。AIGC會出現(xiàn)產(chǎn)出物不受控、冗余、被用戶繞過做其他用途等情況，因此在 AIGC 產(chǎn)品設(shè)計(jì)時要把控好邊界，做好內(nèi)容質(zhì)量的檢測，避免 AI 生成物影響系統(tǒng)的穩(wěn)定性，出現(xiàn)更大的不可控因素。
07 未來
早在今年七月份的對外演講中我就提到，大模型能力的最大價值并不是各種 AIGC 能力，而是低門檻的 AI 服務(wù)化能力，我稱之為 AI 下鄉(xiāng)。隨著大模型技術(shù)的發(fā)展，以后 AI 技能將向編程技能甚至生活技能發(fā)展，成為每個人都能理解且能夠使用的技術(shù)底座。CodeWave 團(tuán)隊(duì)會始終跟進(jìn)目前 AI 技術(shù)的發(fā)展，不斷往產(chǎn)品中注入 AI 能力，讓低代碼產(chǎn)品變成 AI 的試驗(yàn)田，讓低代碼+AI 這樣的實(shí)踐給用戶更大的價值。
繼續(xù)閱讀：
未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動力 | RPA新聞 | 推動中國RPA生態(tài)發(fā)展 | 流 > 如何做一個GPT干不掉的低代碼產(chǎn)品
heng.png)
實(shí)操演示 | 如何從0到1，快速搭建企業(yè)信息管理系統(tǒng)？
GPT驅(qū)動下，如何通過低代碼為構(gòu)建企業(yè)應(yīng)用提效？
集成自研智能大模型，網(wǎng)易數(shù)帆CodeWave重塑軟件開發(fā)模式
AI+低代碼將帶來怎樣的生產(chǎn)力變革？
熱門信息
閱讀 (14728)
1 2023第三屆中國RPA+AI開發(fā)者大賽圓滿收官&獲獎名單公示閱讀 (13753)
2 《Market Insight：中國RPA市場發(fā)展洞察（2022）》報(bào)告正式發(fā)布 | RPA中國閱讀 (13055)
3 「RPA中國杯 · 第五屆RPA極客挑戰(zhàn)賽」成功舉辦及獲獎名單公示閱讀 (12964)
4 與科技共贏，與產(chǎn)業(yè)共進(jìn)，第四屆ISIG中國產(chǎn)業(yè)智能大會成功召開閱讀 (11567)
5 《2022年中國流程挖掘行業(yè)研究報(bào)告》正式發(fā)布 | RPA中國