AIGC 很火，各個領(lǐng)域都在嘗試。通過 AI 自動生成一個管理臺站點，這會帶來開發(fā)效率的提升嗎？如果 AI 能快速開發(fā)管理臺，那么 AI 生成能否完全取代低代碼的可視化配置？如果 AI 不能開發(fā)整個管理臺，那么在什么場景下使用 AI 效果最好？

引言

隨著 ChatGPT 問世，無極也開始接入 AI，希望通過 AI 進一步提升低代碼的開發(fā)效率。

無極 是一款面向管理臺的低代碼工具，初衷就是要解決企業(yè)內(nèi)部管理臺的開發(fā)效率問題，而 ChatGPT（下文簡稱 AI）的能力讓我們看到了一種新的開發(fā)方式，能否通過人與 AI 對話的方式來完成管理臺的開發(fā)？考慮到 AI 的不確定性，要怎樣接入 AI 才能達到更好的提效？

基于這些問題，無極團隊探索了一段時間，有了些階段性的進展；下文將按照 “AI 之前” ? “局部接入 AI” ? “全場景接入 AI” ? “AI 自定義” 的方向，介紹無極逐層接入 AI 的過程。

在 AI 之前，無極的拖拽已經(jīng)做到極致

在低代碼平臺上開發(fā)頁面，常規(guī)的方案是先拖拽組件，然后再綁定數(shù)據(jù)。而無極提供了新的思路 – “智能推導(dǎo) UI”，用戶只需要接入數(shù)據(jù)或者接口服務(wù)，就能直接拖拽出 UI 組件。

AI 面世，無極開始打造智能的低代碼平臺

通過 AI 來取代單次拖拽組件，沒有任何意義，效率甚至更慢。想象一下，沒有 AI 時，直接從數(shù)據(jù)一鍵就能拖拽出列表組件；而為了使用 AI，我們需要敲很長的一段指令（“基于 xxx 數(shù)據(jù)，生成一個可以增刪改查的列表組件“），然后等待 AI 的回復(fù)之后才得到列表組件（甚至有可能得到的是不符合預(yù)期的組件）。

所以說不是所有的場景都適合使用 AI。因此我們選擇一些特定的場景，從局部功能漸進式地接入 AI，在這些場景下發(fā)揮 AI 最好的效果。

場景一：組件定制

以表單組件為例，通過智能推到 UI生成一個表單后，往往需要進一步的細節(jié)調(diào)整。而這些調(diào)整操作都是重復(fù)的，非常繁瑣，我們嘗試用 AI 來取代它。

下面視頻案例中，演示了表單的標簽翻譯和下拉框的可選項配置。通過 AI 取代簡單重復(fù)的人工操作，降低低代碼平臺的使用門檻。

，時長02:19

場景二：邏輯定制

在無極里面，有些頁面邏輯需要編寫少量的前端代碼（Javascript）來實現(xiàn)，這塊功能我們稱之為 LessCode。在 LessCode 里面可以調(diào)用我們的 API 來 “獲取頁面的狀態(tài)數(shù)據(jù)” 或者 “調(diào)用無極的工具方法”，這里的代碼規(guī)模不大，技術(shù)要求也不高，難點在于要學(xué)習(xí)無極的文檔，如果把這個文檔交給 AI 呢？（世界瞬間清凈了 ～）

下面視頻案例中，演示如何在無極中使用 AI 來編寫邏輯代碼。AI 寫出來后，我們可以人工 CR 一下，也可以跳過 CR，直接去預(yù)覽狀態(tài)下做“黑盒測試”，這樣一來，對無極用戶們的代碼能力又降低了。

，時長00:56

場景三：數(shù)據(jù)分析

上面兩個場景中，通過 AI 輔助可以降低低代碼平臺的使用門檻，但還不夠。無極解決的是從數(shù)據(jù)到 UI 的一個完整開發(fā)過程，能否通過 AI 實現(xiàn)全過程的自動化？ 這里我們進一步嘗試“零代碼”的開發(fā)，實現(xiàn)用戶的“一句話需求”。

下面視頻案例中，我們選擇 BI 這個例子，通過 AI 自動編寫 SQL、自動選擇合適的圖表組件、或者進一步調(diào)整組件細節(jié)；從 “接入數(shù)據(jù)” -> “生成組件” -> “組件調(diào)整"，全過程由 AI 獨立完成。

，時長00:59

全場景接入 AI

目前無極的功能已經(jīng)成功接入 AI（局部 AI 化），其中最關(guān)鍵的方法就是 封裝 DSL 層 ：

1. 封裝 DSL，讓 AI 了解無極
2. 首先，按原子性的原則，把無極的能力封裝成 API 接口，比如 createData（新建數(shù)據(jù)）、createComp（拖出組件），這就是無極的 DSL
3. 然后把這些 API 以及對應(yīng)的參數(shù)描述發(fā)送給 AI，這樣 AI 能夠根據(jù)用戶的指令自行拼裝 API；
4. 最終，AI 會把用戶的指令解析成一連串 API 調(diào)用。
5. 無極作為 AI 的命令行工具對于 AI 輸出的 DSL，無極直接解析并執(zhí)行

比如上圖左邊，用戶輸入了“生成柱狀圖”，然后 AI 輸出 createData 和 createComp（當(dāng)然這里 AI 會一并輸出對應(yīng)的參數(shù)），無極直接執(zhí)行后就可以在畫布里拖拽出一個綁定了用戶數(shù)據(jù)的柱狀圖；

另外，某些場景下單憑預(yù)置的 DSL 描述，AI 無法完成用戶的指令，這時候 AI 還需要一些頁面的狀態(tài)信息。這種場景下，我們需要給 AI 預(yù)置一些獲取信息用的 DSL，讓它在有需要的時候自行獲取。 比如上圖右邊，用戶想“切換圖表的橫縱坐標”，這時候 AI 需要先獲取圖表的信息（getCompInfo），然后才能設(shè)置它（setComp）。

從產(chǎn)品的角度，目前無極只是把 AI 當(dāng)成輔助工具，用戶需要選定場景之后，再使用 AI 進行快速的功能開發(fā)；能否讓 AI 做更多的事情，比如頁面交互設(shè)計、視覺優(yōu)化等等？比如說用戶直接告訴 AI-“生成一個簡潔美觀的登錄頁面”，然后由AI 自行接入數(shù)據(jù)、設(shè)計表單、編輯登錄邏輯等等。

從技術(shù)的角度，目前我們根據(jù)用戶場景，給 AI 發(fā)送對應(yīng)部分的 DSL，“Token 限制問題” 還不是特別明顯；但是隨著用戶迭代輸入的指令，或者是更復(fù)雜的使用場景，AI 的 這個 Token 限制將是致命的問題。另一方面，就算沒有 “Token 限制”，AI 自身也存在上下文內(nèi)容干擾，比如你讓 AI “生成一個柱狀圖，然后再修改頁面上某個餅圖的標題”，它有可能給你生成一個餅圖來，或者修改了柱狀圖的標題。

無論是從產(chǎn)品還是技術(shù)的角度，單靠一個 AI 實例是無法滿足需求的，那是否可以使用多個 AI 實例呢？ 這里我們參考了 AutoGpt 的方案，嘗試實現(xiàn) 自動拆解任務(wù)、自動下發(fā)任務(wù)或交付任務(wù)，讓多個 AI 實例協(xié)同完成用戶的指令。

1. 任務(wù)拆解首先我們需要對先前規(guī)劃的 DSL 進行模塊化，比如說無極所有 DSL 共分為四個模塊，對應(yīng)無極的四個能力–導(dǎo)航、物料、畫布、組件配置。這就可以告訴 AI，用戶的任何指令，都能拆解成這四個模塊的組合。比如說剛才的指令–“切換圖表的橫縱坐標”，需要先從 畫布 中獲取到組件的信息，然后再通過 組件配置 修改組件的詳細配置，用 AI 領(lǐng)域?qū)I(yè)的術(shù)語講，這個叫!!#9900ff “鏈式思維(CoT)”!!。

enter image description here#680px

2. 任務(wù)下發(fā)與交付對于上面“切換圖表的橫縱坐標”的例子，我們至少需要三個 AI 實例
3. “無極大管家”負責(zé)拆分任務(wù)，
4. “畫布主管”負責(zé)畫布功能
5. “組件配置主管”負責(zé)組件配置功能。

然后這里就涉及到 AI 之間的相互通信：“大管家”拆分任務(wù)后要下發(fā)給對應(yīng)的“主管”，“主管”完成任務(wù)后要講結(jié)果交付給“大管家”。因此需要新增一套獨立的 DSL-用于 AI 通信，比如 assign(fromAI, toAI, content)。

解決了任務(wù)拆解和任務(wù)交付的問題之后，接下來就是 “重復(fù)的遞歸調(diào)用”（類似 DFS）。在任務(wù)拆解中，我們對 DSL 進行模塊化，但是這個模塊化不是水平的，而是引入了層級的概念，形成一顆 DSL 樹。如下圖左邊，物料這個模塊又可以繼續(xù)拆分成數(shù)據(jù)和組件庫，數(shù)據(jù)繼續(xù)拆分等等，這樣樹的葉子結(jié)點就是一個個無法拆分的原子性 API 了；

根據(jù)上面的 DSL 樹，我們把任何 DSL 節(jié)點以及它的子節(jié)點合并成一個 prompt 節(jié)點，就可以形成一個 prompt 樹，由這個 prompt 樹可以生成多個具有上下級觀念的 AI 管家，形成一個AI 團隊，為無極的用戶打工！

PS：下圖解釋下 DSL 節(jié)點合并成 prompt 節(jié)點，一個 prompt 節(jié)點 由 “一個 DSL 節(jié)點功能”、“所有 DSL 子節(jié)點功能”、“再加上子節(jié)點功能的拆解方法”組成。這個“拆解方法”是可選的，如果邏輯比較簡單，不跟 AI 說它也能無師自通。

進一步的視頻演示請期待無極的下一個 AI 版本～～

為了加深理解，這里再貼一個大管家的 prompt 和 AI 返回。

# 系統(tǒng)上下文部分，定義大管家的基本規(guī)則，以及大管家下面的主管能力role: systemcontent: You are a website builder to help user to develop website on a low-code platform Constraints: 1. Write command argument in JSON format. 2. Please write the thoughts in Chinese 3. You should only use the commands and agents below to solve the task 4. When running the runAgent command, please provide the information obtained from the current task in the task argument. The task should be a string 5. If you cannot solve the task, try to break down the task into smaller tasks that commands can solve 6. if you have solved the task, please response `next` as false, or else response `next` as true to run next step Commands: 1. taskComplete(): "run after the whole task is completed" 2. runAgent(<"agentId">, "<task>">: "If the agent exists in Agents, run the agent to solve the task. The task should be a string. Don't pass agentId you don't have" Resources: 1. You can use commands below to solve the task 2. If the agent exists in Agents, You can use runAgent command to ask agent to solve the task Agents: material: 物料模塊包括了數(shù)據(jù)庫和數(shù)據(jù)源的操作,頁面變量,等和數(shù)據(jù)相關(guān)的部分,連接db數(shù)據(jù),使用臨時變量,讀取url參數(shù),讀取用戶信息等 canvas: 獲取可以添加的組件類型、添加組件到頁面 component: 每個組件有一個唯一的組件id(componentId)，提供componentId，此機器人可以選中組件、或者當(dāng)前選中的組件、以及修改組件的屬性,樣式,行為/事件、刪除組件或者獲取組件的位置 You should only respond in JSON format as described below Response Format: { "thoughts": "thoughts summary to say to user", "command": { "name": "command name", "args": { "arg name": "value" } }, "next": true } Ensure the response can be parsed by JavaScript JSON.parse# 用戶輸入指令“生成一個登錄頁面，用戶需要輸入用戶名和密碼進行登錄”role: usercontent: Determine which agents use and respond using the format specified above. Task: <生成一個登錄頁面，用戶需要輸入用戶名和密碼進行登錄># AI的返回是一個JSON，把任務(wù)下發(fā)給畫布主管role: assistantcontent: { "thoughts": "首先，我們需要創(chuàng)建一個新的頁面，然后在頁面上添加用戶名和密碼的輸入框以及登錄按鈕。", "command": { "name": "runAgent", "args": { "agentId": "canvas", "task": "創(chuàng)建新頁面" } }, "next": true }

不止如此，無極還能開發(fā)智能的管理臺應(yīng)用

前面章節(jié)說的都是在無極的編輯端引入 AI 的能力，但是，低代碼平臺的 AI 能力不應(yīng)該限制在編輯端，用戶可以在無極平臺上，開發(fā)出一個具備 AI 能力的應(yīng)用，也就是“AI 低代碼化”

為此，我們新增了 “chatGPT”調(diào)用的行為原子（關(guān)于行為原子的概念，點擊進入無極文檔搜索行為原子），支持用戶配置 AI 的各種行為。

基于 AI 行為原子的能力，我們可以在無極上搭建更復(fù)雜的 AI 應(yīng)用，比如下面視頻這個 AI 對話，支持多個 AI 間的消息傳遞。

數(shù)據(jù)安全邊界

目前無極使用的是 ChatGPT，這里解釋下數(shù)據(jù)安全的邊界。

作為一個面向管理臺的低代碼平臺，其操作的數(shù)據(jù)都屬于企業(yè)內(nèi)部數(shù)據(jù)，不能對外泄漏。無論是無極的編輯器，還是由無極開發(fā)出來的應(yīng)用，我們都應(yīng)該明確一個點：數(shù)據(jù)本身是敏感的，但是數(shù)據(jù)的結(jié)構(gòu)、頁面的結(jié)構(gòu)并不敏感。

比如上面介紹的“基于數(shù)據(jù)自動生成分析圖表”的場景，我們只需給 AI 發(fā)送數(shù)據(jù)的結(jié)構(gòu)即可，整個交互過程不涉及明確的數(shù)據(jù)；又比如“AI 自動提取文章簡介”的場景，我們的文章本來就是對外發(fā)布的，所以發(fā)給 AI 也無所謂，但是如果是 “KM 文章”（僅限司內(nèi)查看），就不適合用 ChatGPT 來自動提取了～

萬物皆可 AI，但 AI 不是唯一

現(xiàn)在我們回過頭來繼續(xù)討論開篇的問題：

AI 是最高效的嗎？

根據(jù)前面的場景案例，AI 不一定是最高效的，由兩方面的因素決定：

1. 使用場景

對于一個非常具體的小場景，比如 “根據(jù)現(xiàn)有的 學(xué)生數(shù)據(jù)表 生成一個列表”，因為 學(xué)生數(shù)據(jù)表 的數(shù)據(jù)結(jié)構(gòu)已經(jīng)完全固定，低代碼平臺有很多方案可以實現(xiàn)一鍵生成它對應(yīng)的列表組件，這時候使用 AI 反而會更雞肋；但是如果需求換成 “根據(jù) 學(xué)生數(shù)據(jù)表 統(tǒng)計學(xué)生的男女比例”，這時候需要一定的思念成本，低代碼無法自動化，這時候引入 AI 來理解自然語言、并生成 SQL，就能吊打低代碼；

再比如“把名稱這個表單項的標簽，由 name 改成 '名稱'”，讓 AI 來處理，它會先尋找表單項、獲取表單項的信息、最后才是設(shè)置標簽值，但是對于一個稍微熟悉低代碼的開發(fā)者來說，單擊一下配置框直接輸入“名稱”兩字就完事了，這樣跟 AI 對比，人工操作更快更準。但是如果重復(fù)的操作量增大，比如“把整個表單的所有標簽都翻譯成中文”，這時候讓 AI 來循環(huán)操作就非常合適。

所以，適合 AI 的場景：具備一定的思考成本 或者 操作體量大。

2. AI 的成熟度

幻覺問題是大預(yù)言模型的致命問題，我們可以通過 “提示詞工程” 逐步優(yōu)化 AI，使它的回復(fù)更符合預(yù)期。但是無法避免的是某些場景下它會“抽風(fēng)”，讓我們的“苦苦等待”得到了錯誤的答復(fù)，如此重復(fù)的輸入指令并驗證 AI 的返回也會帶來更大的時間成本。

所以， AI 的輸出不一定是 100%準確，在未來很長一段時間，AI 和人工是共存的。一方面，我們可以先人工再 AI，使用無極的“智能推導(dǎo) UI”，快速生成固定模板的組件，然后配合 AI 完成細節(jié)調(diào)整；另一方面，我們也可以先 AI 再人工，用 AI 快速生成一個可用的 Demo，然后再通過低代碼的可視化配置能力進行修正。

它能否取代低代碼？

接入 AI 后，無極的交互方式有了很大的變化，很多需求可以直接通過“AI 聊天框”完成，并且隨著接入功能越來越多，“AI 聊天框”的使用率將會更大，那么這個“AI 聊天框”最終能否取代低代碼的其他交互，成為唯一的交互入口呢？

很多領(lǐng)域都有 AIGC，但是所有的 AI 出品必須要經(jīng)過人工的審批、調(diào)整后才能被正式使用。從“AI 出文” ? “AI 出圖” ? “AI 出視頻” ? “AI 出網(wǎng)站”，專業(yè)性越來越強，審閱或二次編輯的成本越來越高。AI 出的圖片問題，我們可以用 PS 進行局部修復(fù)；視頻也有對應(yīng)的編輯器能夠逐幀調(diào)整；但是如果 AI 生成一個完整的網(wǎng)站代碼，讓程序員用代碼編輯器打開來閱讀并修 bug，相信工作量只會更大；

AI 必須要結(jié)合工具，而在 AI 生成網(wǎng)站這一領(lǐng)域，低代碼就是最好的工具。我們需要讓 AI 結(jié)合低代碼的能力來生成網(wǎng)站，讓低代碼成為“AI 生成網(wǎng)站”的一個中間驛站，這樣人工介入時才能借助低代碼快速驗證或修改 AI 生成的內(nèi)容。

萬物皆可 AI

文章的最后，分享一下無極接入 AI 的經(jīng)驗。

無極接入 AI 的方式是抽象出一層 DSL（領(lǐng)域特定語言），讓 AI 通過 DSL 了解無極的能力，同時輸出 DSL 交給無極解析執(zhí)行。基于這一層抽象，任何領(lǐng)域的應(yīng)用都能夠接入 AI，只要它的能力能被原子性地描述出來。只需要三步 ：

1. 領(lǐng)域能力封裝成 DSL
2. 將 DSL 的組合方式（鏈式思維的方式，CoT）提煉成 Prompt
3. 執(zhí)行 AI 返回的指令

最后，無極的 AI 之路會繼續(xù)走下去，目標不僅僅是借助 AI 來提效，更是讓無極成為 AI 生成管理臺 的一個可視化編輯工具；把低代碼和 AI 融合一體，相輔相成，敬請期待后續(xù)的更新。

作者:vvdennis

來源:微信公眾號:騰訊技術(shù)工程

出處:https://mp.weixin.qq.com/s/7MDSJdEfRiDjBpH3vzsiHg