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