AIGC 和低代碼結合應用全棧研發實踐總結精華

發布于 2024-4-29 09:55

瀏覽

0收藏

一、背景

電商供應鏈的系統建設一般偏向于數據管理類型，但此類系統建設有一個很明顯的問題就是前后端開發的溝通成本較高（相對研發成本而言），特別是一些簡單加減字段的訴求溝通成本甚至達到 50% 以上，如何將這部分溝通成本降低下來，并保證高質量的交付成為目前亟待解決的問題。

經過對需求和系統頁面進行分析，我們得出如下數據：

供應鏈 ≤ 2 人日的需求投入工時占接近 50%，兩周的迭代周期，一個前端甚至能接到 10+ 需求，時間碎片化特別嚴重，而這些需求很簡單，基本就是一些字段的加減處理，單選改多選，增加導入導出等等。
供應鏈七成頁面屬于標準的列表類型，也就是我們常說的（CQUD），這種頁面的特點就是交互簡單、功能標準，我們常見的功能包括：查詢、新建、編輯、批量處理、上下線/刪除、導入/導出、查看操作日志、查看詳情等。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

通過以上數據分析，一句話總結如下：

需求簡單，但是溝通成本大！！！

二、思考

請注意這里講溝通成本大是相對于簡單需求的開發成本而言，單獨看絕對投入其實還好，但是需求數量大，也會造成很大的資源浪費，我們希望探索出更高效的需求交付方式。

對于解決溝通問題其實有很多解決思路，其中有一個比較有效的方式就是目前得物技術正在推進的 Mooncake，它的好處是已經和發布系統打通，代碼部署后所有接口和出入參等描述信息都會上傳到 Mooncake，做到了統一以文檔方式滿足接口出入參說明訴求，執行后確實有不錯的收益，但還存在兩個主要問題：

即所謂的契約精神問題，什么時間交付接口描述，并且描述清晰？在現實環境中，這是一個比較難達成的事情。服務端什么時候能夠上傳接口說明，這個時間不確定，即使確定了，也會出現因為各種因素不符合預期，因為很多情況下一個接口和屬性的描述他認為描述清楚了，并不代表你能理解，這個就是信息差，但是真要做到你能夠理解服務端一定會付出更多成本，有些人會認為沒必要。
服務端會修改出入參格式而忘記溝通，可能到了比較滯后的聯調甚至測試階段才發現，而且屢禁不止。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

在當前背景下，解決這個溝通問題的思路最簡單的做法，就是讓服務端一個角色全棧搞定前后端開發，為什么是服務端全棧而不是前端全棧，因為中后臺系統的服務端的工作相對復雜，通過需求數據分析發現，服務端投入工時是遠高于前端的，另外一個原因就是需求前端部分相對簡單很多。

三、具象思考

談到全棧，肯定不是直接把前端的工作直接交給服務端去做，得物研發目前的工作壓力還是不小的，所以需要一種低成本的全棧方案，讓服務端快速上手。

低成本的前提就是把復雜的前端開發變得簡單，初期我們考慮了三條路進行簡化：

通過低代碼配置化代替源碼開發，可以再很大程度上降低學習成本。
具象在比較標準化的 CQUD 頁面類型，減少發散，用更低的成本覆蓋最多的頁面類型。
有沒有可能借助于目前比較火的大模型 AIGC 方向降低全棧學習成本。

低代碼代替源碼開發的好處是可以讓服務端在配置一兩個頁面后快速掌握配置技能，它的認知成本會降低，學習周期也會縮短，下面這張圖更方便大家理解。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

另外，在知乎看到一張非常有趣的圖，雖然有點夸張成分，但是感覺可以幫助大家理解低代碼的學習成本。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

各個大廠其實在低代碼領域已經做的非常成熟，給大家列舉兩個做的比較好的，大家可以去深度了解：

阿里低代碼引擎：https://lowcode-engine.cn/index 強調可視化配置生成頁面；
百度 Amis：https://aisuda.bce.baidu.com/amis/zh-CN/docs/index 強調 JSON 配置生成頁面。

我們選擇 Amis 作為基礎的渲染引擎，主要原因如下：

Amis JSON 配置能力更加強大，相對于 Lowcode Engine 需要寫很多腳本來滿足稍微復雜的場景，JSON 配置的學習成本更低，更適合服務端同學快速上手；
Amis 的文檔功能更加強大，可以直接編輯 JSON 查看修改后的結果，這一步可以極大的方便開發學習 API。

另外關于和 AIGC 的結合，其實重點要看低代碼在服務端全棧的場景下，可以幫助解決哪些問題？比如腳本編輯、UI布局等，這些一定會成為痛點，下面我們將隨著問題的展開逐漸應用起來。

四、對低代碼的“吐槽”

談及我們的方案之前，我首先要“吐槽”下低代碼/零代碼，很多人說不好用，甚至有人說低代碼是“行業毒瘤”，我翻看了很多這方面的總結性文章，以及自己的經驗，理性總結如下：

沒有認清使用人群：B 端低代碼產品的絕大部分用戶是前端，專業人士用低代碼多少有點抵觸情緒的，給別人用之前一定要想清楚，他為什么會用？或者說他因為什么才會用？個人認為給前端提供低代碼工具做 B 端系統，大概率是行不通的，也許會有效率提升，但是相對專業降級及蹩腳研發體驗可能不值一提。
靈活性不足：當遇到某種邏輯的時候，用起來就會很蹩腳或者根本沒法做下去，正所謂 “一行代碼難倒英雄漢”，只能源碼開發一遍，這種不斷嘗試后的返工確實會讓體驗大大降低，這種一般受組件不支持或者低代碼引擎不支持影響。
功能不完備：其實做好一個頁面，要考慮多方面問題：聯調、頁面管理、發布/回滾、菜單、權限等，這些是不是都考慮在內了，那種體驗割裂，流程分散在各個平臺的方式一定會被吐槽的。
缺乏設計理念：比如常用組件的一種配置有多種屬性命名方式，還有就是功能實現不符合大眾認知等等，導致 API 的理解和學習成本巨大。
認知成本高：比如我們目前服務端全棧的場景，他們甚至不知道組件的概念，也不知道所謂的數據驅動，拿到的 PRD 對于頁面的描述很有可能只是一大段文字描述，連個像樣的線框圖都沒有，對于一個新手如何做才能還原成和標準交互一樣的頁面，其實是一個很大的考驗，這些細節都是我們需要考慮并解決的。

五、主要方案設計

該篇文章我不會過多介紹低代碼配置實現的原理，想了解的可以 Google 下。

我們整個全棧方案有一個統一的名字叫 Wizard，包括渲染引擎、組件、在線配置、發布流程、AI 答疑、AI Proto 等一系列工具，接下來會撿重點介紹。

特殊說明：我們初期全棧覆蓋的頁面類型主要聚焦在 CQUD，并沒有擴散，核心原因就是目前此類頁面占比較高（72%），并且交互形式足夠收斂，頁面類型收斂可以將全棧的成本降低很多，后期可以根據必要性選擇性覆蓋更多的頁面類型。

另外對于上面提到的前 4 個槽點，沒什么好的方法，大家只能認清事實，持續的去做，針對第 5 點，我們確實有一些方向，分享出來給大家參考，總結來講主要是三步：簡化組件配置、高效初始化頁面、智能答疑。

簡化組件配置

得物的基礎組件建設得益于 Antd 和 ProComponents，好的東西當然直接復用，我們的主要工作是還原得物的設計標準以及業務組件的沉淀，組件注冊到 Wizard 中最重要的是要將復雜屬性轉換成 JSON 配置可實現，比如接口請求、表單聯動、數據格式化等，如果這一步做不好，會導致部分功能被閹割，所以這部分我們花費了比較大的精力去設計實現，以表單聯動舉例，效果參考如下動圖：

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

選擇顯示姓名，姓名展示，選擇禁用密碼，姓名隱藏，密碼禁用

源碼實現：??https://stackblitz.com/edit/react-vegy7y?file=demo.tsx??

import React, { useState } from 'react';
import { Radio, Form, Input } from 'antd';


type FieldType = {
  username?: string;
  password?: string;
  type?: number;
};


const App: React.FC = () => {
  const [form] = Form.useForm();
  const [hiddenName, setHiddenName] = useState(false);
  const [diablePassword, setDiablePassword] = useState(false);


  const onValuesChangeHandler = (values: FieldType) => {
    setHiddenName(values.type !== 1);
    setDiablePassword(values.type === 2);
  };


  return (
    <Form
      form={form}
      name="basic"
      labelCol={{ span: 8 }}
      wrapperCol={{ span: 16 }}
      style={{ maxWidth: 600 }}
      notallow={onValuesChangeHandler}
      autoComplete="off"
    >
      <Form.Item<FieldType> name="type" wrapperCol={{ offset: 8, span: 16 }}>
        <Radio.Group>
          <Radio value={1}>顯示姓名</Radio>
          <Radio value={2}>禁用密碼</Radio>
        </Radio.Group>
      </Form.Item>
      {!hiddenName && (
        <Form.Item<FieldType> label="姓名" name="username">
          <Input />
        </Form.Item>
      )}


      <Form.Item<FieldType> label="密碼" name="password">
        <Input.Password disabled={diablePassword} />
      </Form.Item>
    </Form>
  );
};


export default App;

Wizard 配置實現：

{
    "type": "form",
    "body": [
      {
        "type": "radio",
        "name": "type",
        "label": "類型",
        "options": [
          {
            "label": "顯示姓名",
            "value": 1
          },
          {
            "label": "禁用密碼",
            "value": 2
          }
        ]
      },
      {
        "type": "text",
        "name": "username",
        "label": "姓名",
        "visibleOn": "${type == 1}"
      },
      {
        "type": "password",
        "name": "password",
        "label": "密碼",
        "disabledOn": "${type == 2}"
      }
    ]
 }

上面右側 Wizard 代碼示例中，type 代表組件類型，同級的其他屬性代表組件API，body 屬于通用屬性用于子元素設置，認真看會發現，Wizard 針對禁用和顯隱設置增加了 disabledOn 和 visibleOn 兩個屬性，并且支持寫簡單的表達式，類似這種標準屬性的實現，是所有的組件統一去實現的（所有的組件都會支持 visibleOn ，所有的表單類組件都支持 disabledOn ），表達式是引擎統一實現的能力，為了更好的支持配置化，Wizard 引擎還支持數據域、數據鏈、模版、數據映射、表達式、函數、行為等。

另外一種比較復雜的情況，是組件自帶的數據請求能力，比如 ProTable、Select、Form 等，而且一般都需要解決數據處理問題，比如數據查詢前需要對入參進行格式調整，拿到數據之后需要對出參進行格式校準等，是非常常見的操作，我們統一設計了 api 配置，除了滿足基本的 url、method、data 設置外，還支持請求前后的 adaptor 設置，當然這里就是我們說的需要寫腳本的地方，而且目前是整個 Wizard 唯一需要寫腳本的地方，這部分還是有點復雜的，但是我們這里借助于 AI 的能力實現了只需要配置當前數據格式和你需要轉換的數據格式，就可以生成轉換腳本，并且支持對函數進行快速測試，如果沒問題即可回填到配置中，以更低的成本實現腳本輸出。

下面這個示例，相信大家一看左右結構就能明白研發同學的數據轉換意圖，此處不再啰嗦。

其實這種功能在有了大模型之后，實現變得很簡單，我們只需要設計一個合理的 prompts 即可，雖然輸出的腳本有時候有點啰嗦，但是準確率和穩定性還是比較高的。

//adaptor 腳本生成 prompts
你扮演一個純函數代碼生成器，你負責生成數據格式轉換代碼，你負責接收函數出入參的文本指令，根據要求生成javascript 代碼，取變量值和給變量賦值的時候請做好容錯處理，處理容錯時不要提前返回undefined或null
      幫我生成一個 js 函數: function formatData(payload, response, api) {}，要求最終返回處理好的數據
      response參數: ${before},
      返回數據為: ${target},
      只輸出函數代碼，不要輸出其他無關的東西，函數代碼中的注釋保持中文輸出，其他無關信息不要輸出
      輸出代碼縮進2個空格

高效初始化頁面

俗話說“萬事開頭難”，頁面 0 到 1 的成本如何降到盡可能的低是我們一直比較追求的，因為這樣可以有效降低全棧門檻，我們主要通過以下三個手段：

通過頁面模版初始化

針對 CQUD 的場景，我們沉淀了比較多的示例，基本能夠涵蓋系統需要的常見交互和功能訴求，這是最基礎的做法，全棧同學選擇模版創建后，修改下配置即可滿足頁面訴求。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

通過接口元數據生成頁面

上面提到得物的 Mooncake 平臺，沉淀了得物所有接口的出入參信息，Wizard 可以做到選擇接口和頁面類型生成頁面描述，根據接口類型，可以選擇生成列表、表單、詳情，可以復制到頁面中成為頁面主體或者一部分。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

根據 PRD 描述快速生成頁面

這個是為了解決上面“吐槽”中提到的第5點，很多 PRD 對于中后臺需求描述過于簡單，沒有草圖說明，即使有草圖，對于全棧同學也不一定知道怎么還原 UI，Wizard 訓練了自有的大模型（關于模型訓練，后面章節會介紹），做到對 Wizard 足夠了解，可以結合 PRD 描述快速生成頁面效果（插件 Wizard Proto），我們只需要提供標準的描述頁面功能的文本格式，產品同學按照格式填空書寫頁面結構即可，具體實現細節參考???：大模型在產品原型生成中的應用實踐??，這里放一個視頻用于說明使用方式：

，時長00:30

通過 Proto 生成的頁面既可以幫助產品用最低的成本還原頁面原型，又可以幫助研發同學快速還原 UI。

同時我們看到視頻中給予產品一定的 UI 配置能力，但是這遠遠不足，長遠的規劃上看，大模型在此步的應用只是為了快速生成，而后還是需要提供更加完備的可視化配置能力完成頁面 UI 和交互配置（或者換句話說，大模型的應用是為了讓產品和技術快速上手），并且這部分配置是可以沿用到全棧開發，我們希望能夠做到 CQUD 的 UI 工作在 PRD 階段搞定，全棧同學的主要工作是做接口配置和功能校準即可，當然這個是很理想的狀態，但是我們希望全棧研發同學的單頁面輸出成本降低到 0.5 人日以下，同時不增加產品的成本。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

智能答疑

前面提到的 Wizard 自有大模型，還承擔著另外一個比較重要的角色，就是輔助全棧同學答疑，比如：

快速了解某個組件怎么使用或者概念；
復雜的表單聯動關系；
根據需求生成或者修改頁面結構；
幫你理解頁面配置。

同時我們也會支持針對回答的內容進行正向和負向反饋，這些反饋也會用于豐富我們的訓練池，讓大模型準確率越來越高。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

這部分能力目前使用率還不夠高，根本問題還是準確率問題，關于下一步的規劃，下面章節會提到。

六、大模型訓練和應用

Wizard 應用的基礎大模型是更擅長做代碼生成的 DeepSeek Coder，我們使用的版本參數個數是 6.7b，但其實模型準確率如何，核心是訓練的數據源怎么搞定，Wizard 不像 Antd 或者 React 一樣屬于應用廣泛的開源產品，社區有大量的代碼、文章等讓 ChatAIGC 進行訓練，Wizard 的訓練數據需要我們自己整理，思路如下：

根據文檔中的組件示例、組件 API 描述、概念描述、示例、存儲的 QA 問題等快速生成種子問題。
Proto 和智能答疑的正負向反饋都會被作為訓練數據放入種子問題中。
種子問題數量有限（1000 以內），所以會進過一輪人工的驗證，比如你如果發現 SearchPage 組件相關的問答不夠準確，可以搜索處理對種子問題進行矯正，如下是一個簡單的種子問題校準工具。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

針對種子問題通過成熟大模型進行擴展生成多條問題，這一步可以實現數據集的成倍增長，也是為了兼容對一個問題不同的表達，提升模型對問題的兼容度，主要擴展思路如下：

問題擴充，同一個問題換說法；
根據答案生成問題。

其實這里怎么去生成要看場景，主要思路是把大模型當做一個記憶力和理解能力超強的人去看待，你用哪些信息能夠讓它快速理解怎么使用一個組件，而后決定怎么去準備你的組件 QA 池。

對訓練模型準確度進行綜合評估，因為上面提到的智能答疑和 Proto 都會有正負反饋，也能部分說明模型準確性，更精細的準確度評估我們目前還沒有做，如果要做的話可以參考 Ragas 評估（https://zhuanlan.zhihu.com/p/675777378），針對整理的數據集可以留一部分 QA 不參與訓練，而是用于做準確度評估即可。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

綜合流程整理如上

目前大模型在 Wizard 核心的應用有如下幾種場景。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

七、我對大模型應用研發提效的看法

有用，但適可而止：以上五種應用場景中的三種都起到了一定的作用，并且我們還在考慮通過大模型實現數據 Mock 能力，因為他足夠聰明，只要我們把上下文數據和 type Interface 全部給他，可以用比較低的成本實現CQUD 的接口，但每一種應用在我們的方案設計里面，都不是必經路徑，核心是因為在研發這條路上，模型的準確率沒有想象那么高，很多情況下需要人為糾正，這個也是我們實踐下來的一個最明顯的認知，不要想著把大模型訓練的特別牛，準確率特別高，ROI 不一定合理，從輔助研發的角度，我認為能達到 70% 以上已經是非常了不起了（Wizard 大模型目前準確率 60%），除非你們成立了一個專業團隊，長時間投入。
增強針對性：很多情況下太泛的應用會影響大模型的準確度，我們在實際場景中可以結合嚴謹的 prompts 和 TypeChat 這種工具，縮小大模型回答的范圍，因為你指向越明確，大模型回答的越精確，像上面提到的用于數據格式轉換的腳本生成，一般很少會出問題，除非站在人的角度沒法理解你要轉換的意圖，那就是你的輸入有問題了。
不要逃避：個人認為 AIGC 一定是未來趨勢，各行各業可能都會發生變革，包括研發，一味地按照固有思維去解決問題或者不愿去了解，未來大概率會吃虧的，你不一定要自己學會怎么訓練大模型，但最起碼要掌握兩點：大模型的成長性新聞以及應用場景。個人認為，未來簡單頁面的開發工作可能真的會被生成式 AI 替代，如果你現在的工作就是在做類似簡單 CQUD 的事情，那一定要焦慮一下了，快去多翻翻社區。一個很現實的例子：“十年夢碎，蘋果放棄造車轉 AI”，不造車可以理解成對新能源不看好或者認為已經很飽和，但是轉生成式AI，這個一定是對未來的深刻信心和期許。

八、功能架構圖

Wizard 的更多細節功能可以參考如下架構圖。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區

功能架構圖

1. Wizard 提供 3 種新建頁面的方式，根本目的是為了盡可能降低頁面 0 到 1 的成本，研發可以選擇合適的方式或者組合使用。

a. 通過示例模板創建頁面；

b. 通過 Mooncake 元數據創建頁面；

c. Proto 工具實現根據 PRD 智能生成頁面。

2. Mock 能力使得 Proto 生成的頁面效果更加逼真，包括動態枚舉，列表數據，表單提交等，既方便了產品豐富頁面原型，又降低研發復用創建頁面的成本。

3. Migrate 用于結合 AIGC 對于 ProTable、ProForm 等常用組件的配置轉換成 Wizard 配置，用于進一步降低就頁面遷移到 Wizard 頁面的成本，提升全棧占比。

4. 基于天網和統一配置中心，完善了調試、發布、回滾、下線、菜單和權限管理等能力。

5. Wizard 根據文檔和日常答疑并結合 AI 輸出大量 QA 訓練自有大模型，在整個全棧過程提供比較大的幫助。

a. 幫助產品畫原型圖，生成的頁面可用于進一步配置；

b. 全棧答疑，降低認知成本；

c. 分析源碼轉換成 Wizard 頁面，降低頁面遷移成本；

d. 后期還會考慮通過需求描述做頁面功能修改，進一步降低認知成本；

e. 通過訓練大模型解決復雜的表達式生成問題，進一步降低聯動配置成本。

九、問題和規劃

Proto 和智能答疑的應用占比不高，組件 API 查看率 70%，這個評估下來和準確度還是有比較大關系，針對這個問題我們做的是從 JSON 配置往可視化配置進行轉換，盡量減少大家的認知成本。
通過智能答疑和 Proto 的正負向反饋，不斷訓練模型，提升其準確度，最起碼要做到 70%。
增強 Proto 的配置能力，提升產品同學使用 Proto 輸出頁面的比例，爭取做到 PRD 階段輸出 UI，進一步提升頁面輸出效率。
提供產品能夠理解的可視化配置版本，實現在業務系統上可以直接進入配置界面創建需求，從原來的截圖說明需求，變成直接配置生成草稿和變更說明，并和得物的需求創建流轉流程關聯起來，進一步降低一個需求從需求到上線各個角色參與的成本，縮短需求交付周期。

AIGC 和低代碼結合應用全棧研發實踐總結-AI.x社區