一
背景
電商供應鍊的系統建設一般偏向于資料管理類型，但此類系統建設有一個很明顯的問題就是前後端開發的溝通成本較高（相對研發成本而言），特别是一些簡單加減字段的訴求溝通成本甚至達到 50% 以上，如何将這部分溝通成本降低下來，并保證高品質的傳遞成為目前亟待解決的問題。
經過對需求和系統頁面進行分析，我們得出如下資料：
- 供應鍊 ≤ 2 人日的需求投入工時占接近 50%，兩周的疊代周期，一個前端甚至能接到 10+ 需求，時間碎片化特别嚴重，而這些需求很簡單，基本就是一些字段的加減處理，單選改多選，增加導入導出等等。
- 供應鍊七成頁面屬于标準的清單類型，也就是我們常說的（CQUD），這種頁面的特點就是互動簡單、功能标準，我們常見的功能包括：查詢、建立、編輯、批量處理、上下線/删除、導入/導出、檢視記錄檔、檢視詳情等。
通過以上資料分析，一句話總結如下：
需求簡單，但是溝通成本大 ！！！
二
思考
請注意這裡講溝通成本大是相對于簡單需求的開發成本而言，單獨看絕對投入其實還好，但是需求數量大，也會造成很大的資源浪費，我們希望探索出更高效的需求傳遞方式。
對于解決溝通問題其實有很多解決思路，其中有一個比較有效的方式就是目前得物技術正在推進的 Mooncake，它的好處是已經和釋出系統打通，代碼部署後所有接口和出入參等描述資訊都會上傳到 Mooncake，做到了統一以文檔方式滿足接口出入參說明訴求，執行後确實有不錯的收益，但還存在兩個主要問題：
- 即所謂的契約精神問題，什麼時間傳遞接口描述，并且描述清晰？在現實環境中，這是一個比較難達成的事情。服務端什麼時候能夠上傳接口說明，這個時間不确定，即使确定了，也會出現因為各種因素不符合預期，因為很多情況下一個接口和屬性的描述他認為描述清楚了，并不代表你能了解，這個就是資訊差，但是真要做到你能夠了解服務端一定會付出更多成本，有些人會認為沒必要。
- 服務端會修改出入參格式而忘記溝通，可能到了比較滞後的聯調甚至測試階段才發現，而且屢禁不止。
在目前背景下，解決這個溝通問題的思路最簡單的做法，就是讓服務端一個角色全棧搞定前後端開發，為什麼是服務端全棧而不是前端全棧，因為中背景系統的服務端的工作相對複雜，通過需求資料分析發現，服務端投入工時是遠高于前端的，另外一個原因就是需求前端部分相對簡單很多。
三
具象思考
談到全棧，肯定不是直接把前端的工作直接交給服務端去做，得物研發目前的工作壓力還是不小的，是以需要一種低成本的全棧方案，讓服務端快速上手。
低成本的前提就是把複雜的前端開發變得簡單，初期我們考慮了三條路進行簡化：
- 通過低代碼配置化代替源碼開發，可以再很大程度上降低學習成本。
- 具象在比較标準化的 CQUD 頁面類型，減少發散，用更低的成本覆寫最多的頁面類型。
- 有沒有可能借助于目前比較火的大模型 AIGC 方向降低全棧學習成本。
低代碼代替源碼開發的好處是可以讓服務端在配置一兩個頁面後快速掌握配置技能，它的認知成本會降低，學習周期也會縮短，下面這張圖更友善大家了解。
源碼和低碼學習成本趨勢圖
另外，在知乎看到一張非常有趣的圖，雖然有點誇張成分，但是感覺可以幫助大家了解低代碼的學習成本。
低代碼和幾種跨界工具的學習成本對比
各個大廠其實在低代碼領域已經做的非常成熟，給大家列舉兩個做的比較好的，大家可以去深度了解：
- 阿裡低代碼引擎：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 配置可實作，比如接口請求、表單關聯、資料格式化等，如果這一步做不好，會導緻部分功能被閹割，是以這部分我們花費了比較大的精力去設計實作，以表單關聯舉例，效果參考如下動圖：
選擇顯示姓名，姓名展示，選擇禁用密碼，姓名隐藏，密碼禁用
源碼實作：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 }}
onValuesChange={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 的能力實作了隻需要配置目前資料格式和你需要轉換的資料格式，就可以生成轉換腳本，并且支援對函數進行快速測試，如果沒問題即可回填到配置中，以更低的成本實作腳本輸出。
下面這個示例，相信大家一看左右結構就能明白研發同學的資料轉換意圖，此處不再啰嗦。
，時長00:27
其實這種功能在有了大模型之後，實作變得很簡單，我們隻需要設計一個合理的 prompts 即可，雖然輸出的腳本有時候有點啰嗦，但是準确率和穩定性還是比較高的。
//adaptor 腳本生成 prompts
你扮演一個純函數代碼生成器，你負責生成資料格式轉換代碼，你負責接收函數出入參的文本指令，根據要求生成javascript 代碼，取變量值和給變量指派的時候請做好容錯處理，處理容錯時不要提前傳回undefined或null
幫我生成一個 js 函數: function formatData(payload, response, api) {}，要求最終傳回處理好的資料
response參數: ${before},
傳回資料為: ${target},
隻輸出函數代碼，不要輸出其他無關的東西，函數代碼中的注釋保持中文輸出，其他無關資訊不要輸出
輸出代碼縮進2個空格 高效初始化頁面
俗話說“萬事開頭難”，頁面 0 到 1 的成本如何降到盡可能的低是我們一直比較追求的，因為這樣可以有效降低全棧門檻，我們主要通過以下三個手段：
通過頁面模版初始化
針對 CQUD 的場景，我們沉澱了比較多的示例，基本能夠涵蓋系統需要的常見互動和功能訴求，這是最基礎的做法，全棧同學選擇模版建立後，修改下配置即可滿足頁面訴求。
通過接口中繼資料生成頁面
上面提到得物的 Mooncake 平台，沉澱了得物所有接口的出入參資訊，Wizard 可以做到選擇接口和頁面類型生成頁面描述，根據接口類型，可以選擇生成清單、表單、詳情，可以複制到頁面中成為頁面主體或者一部分。
根據 PRD 描述快速生成頁面
這個是為了解決上面“吐槽”中提到的第5點，很多 PRD 對于中背景需求描述過于簡單，沒有草圖說明，即使有草圖，對于全棧同學也不一定知道怎麼還原 UI，Wizard 訓練了自有的大模型（關于模型訓練，後面章節會介紹），
做到對 Wizard 足夠了解，可以結合 PRD 描述快速生成頁面效果（插件 Wizard Proto），我們隻需要提供标準的描述頁面功能的文本格式，産品同學按照格式填空書寫頁面結構即可，具體實作細節參考：大模型在産品原型生成中的應用實踐，
通過 Proto 生成的頁面既可以幫助産品用最低的成本還原頁面原型，又可以幫助研發同學快速還原 UI。
同時我們看到視訊中給予産品一定的 UI 配置能力，但是這遠遠不足，長遠的規劃上看，大模型在此步的應用隻是為了快速生成，而後還是需要提供更加完備的可視化配置能力完成頁面 UI 和互動配置（或者換句話說，大模型的應用是為了讓産品和技術快速上手），并且這部配置設定置是可以沿用到全棧開發，我們希望能夠做到 CQUD 的 UI 工作在 PRD 階段搞定，全棧同學的主要工作是做接口配置和功能校準即可，當然這個是很理想的狀态，但是我們希望全棧研發同學的單頁面輸出成本降低到 0.5 人日以下，同時不增加産品的成本。
智能答疑
前面提到的 Wizard 自有大模型，還承擔着另外一個比較重要的角色，就是輔助全棧同學答疑，比如：
- 快速了解某個元件怎麼使用或者概念；
- 複雜的表單關聯關系；
- 根據需求生成或者修改頁面結構；
- 幫你了解頁面配置。
同時我們也會支援針對回答的内容進行正向和負向回報，這些回報也會用于豐富我們的訓練池，讓大模型準确率越來越高。
這部分能力目前使用率還不夠高，根本問題還是準确率問題，關于下一步的規劃，下面章節會提到。
六
大模型訓練和應用
Wizard 應用的基礎大模型是更擅長做代碼生成的 DeepSeek Coder，我們使用的版本參數個數是 6.7b，但其實模型準确率如何，核心是訓練的資料源怎麼搞定，Wizard 不像 Antd 或者 React 一樣屬于應用廣泛的開源産品，社群有大量的代碼、文章等讓 ChatAIGC 進行訓練，Wizard 的訓練資料需要我們自己整理，思路如下：
- 根據文檔中的元件示例、元件 API 描述、概念描述、示例、存儲的 QA 問題等快速生成種子問題。
- Proto 和智能答疑的正負向回報都會被作為訓練資料放入種子問題中。
- 種子問題數量有限（1000 以内），是以會進過一輪人工的驗證，比如你如果發現 SearchPage 元件相關的問答不夠準确，可以搜尋處理對種子問題進行矯正，如下是一個簡單的種子問題校準工具。
- 針對種子問題通過成熟大模型進行擴充生成多條問題，這一步可以實作資料集的成倍增長，也是為了相容對一個問題不同的表達，提升模型對問題的相容度，主要擴充思路如下：
- 問題擴充，同一個問題換說法；
- 根據答案生成問題。
其實這裡怎麼去生成要看場景，主要思路是把大模型當做一個記憶力和了解能力超強的人去看待，你用哪些資訊能夠讓它快速了解怎麼使用一個元件，而後決定怎麼去準備你的元件 QA 池。
- 對訓練模型準确度進行綜合評估，因為上面提到的智能答疑和 Proto 都會有正負回報，也能部分說明模型準确性，更精細的準确度評估我們目前還沒有做，如果要做的話可以參考 Ragas 評估（https://zhuanlan.zhihu.com/p/675777378），針對整理的資料集可以留一部分 QA 不參與訓練，而是用于做準确度評估即可。
綜合流程整理如上
目前大模型在 Wizard 核心的應用有如下幾種場景。
七
我對大模型應用研發提效的看法
- 有用，但适可而止：以上五種應用場景中的三種都起到了一定的作用，并且我們還在考慮通過大模型實作資料 Mock 能力，因為他足夠聰明，隻要我們把上下文資料和 type Interface 全部給他，可以用比較低的成本實作CQUD 的接口，但每一種應用在我們的方案設計裡面，都不是必經路徑，核心是因為在研發這條路上，模型的準确率沒有想象那麼高，很多情況下需要人為糾正，這個也是我們實踐下來的一個最明顯的認知，不要想着把大模型訓練的特别牛，準确率特别高，ROI 不一定合理，從輔助研發的角度，我認為能達到 70% 以上已經是非常了不起了（Wizard 大模型目前準确率 60%），除非你們成立了一個專業團隊，長時間投入。
- 增強針對性：很多情況下太泛的應用會影響大模型的準确度，我們在實際場景中可以結合嚴謹的 prompts 和 TypeChat 這種工具，縮小大模型回答的範圍，因為你指向越明确，大模型回答的越精确，像上面提到的用于資料格式轉換的腳本生成，一般很少會出問題，除非站在人的角度沒法了解你要轉換的意圖，那就是你的輸入有問題了。
- 不要逃避：個人認為 AIGC 一定是未來趨勢，各行各業可能都會發生變革，包括研發，一味地按照固有思維去解決問題或者不願去了解，未來大機率會吃虧的，你不一定要自己學會怎麼訓練大模型，但最起碼要掌握兩點：大模型的成長性新聞以及應用場景。個人認為，未來簡單頁面的開發工作可能真的會被生成式 AI 替代，如果你現在的工作就是在做類似簡單 CQUD 的事情，那一定要焦慮一下了，快去多翻翻社群。一個很現實的例子：“十年夢碎，蘋果放棄造車轉 AI”，不造車可以了解成對新能源不看好或者認為已經很飽和，但是轉生成式AI，這個一定是對未來的深刻信心和期許。
八
功能架構圖
Wizard 的更多細節功能可以參考如下架構圖。
功能架構圖
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，進一步提升頁面輸出效率。
- 提供産品能夠了解的可視化配置版本，實作在業務系統上可以直接進入配置界面建立需求，從原來的截圖說明需求，變成直接配置生成草稿和變更說明，并和得物的需求建立流轉流程關聯起來，進一步降低一個需求從需求到上線各個角色參與的成本，縮短需求傳遞周期。
需求提出流程
需求評估和傳遞流程
十
參考
https://www.zhihu.com/question/457292482
https://mp.weixin.qq.com/s/Bqca6JrBlAoGlAXhey18HQ
https://mp.weixin.qq.com/s/udeE32EKlHPMjcirl6i-mQ
https://mp.weixin.qq.com/s/IxsLmaxHmR63tR2sehxwbg
https://blog.shizhuang-inc.com/article/MTQ0MTQ
https://zhuanlan.zhihu.com/p/675777378
https://arxiv.org/abs/2310.13671
https://arxiv.org/abs/2212.10560
https://arxiv.org/abs/2305.19915
https://arxiv.org/abs/2310.17876
https://arxiv.org/abs/2311.15653
作者:Steven
來源-微信公衆号:得物技術
出處:https://mp.weixin.qq.com/s/FYri0B2jYCsOVhrENUKAzQ