一

背景

電商供應(yīng)鏈的系統(tǒng)建設(shè)一般偏向于數(shù)據(jù)管理類型，但此類系統(tǒng)建設(shè)有一個(gè)很明顯的問題就是前后端開發(fā)的溝通成本較高（相對(duì)研發(fā)成本而言），特別是一些簡(jiǎn)單加減字段的訴求溝通成本甚至達(dá)到 50% 以上，如何將這部分溝通成本降低下來(lái)，并保證高質(zhì)量的交付成為目前亟待解決的問題。

經(jīng)過對(duì)需求和系統(tǒng)頁(yè)面進(jìn)行分析，我們得出如下數(shù)據(jù)：

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

通過以上數(shù)據(jù)分析，一句話總結(jié)如下：

需求簡(jiǎn)單，但是溝通成本大 ?。。?/span>

二

思考

請(qǐng)注意這里講溝通成本大是相對(duì)于簡(jiǎn)單需求的開發(fā)成本而言，單獨(dú)看絕對(duì)投入其實(shí)還好，但是需求數(shù)量大，也會(huì)造成很大的資源浪費(fèi)，我們希望探索出更高效的需求交付方式。

對(duì)于解決溝通問題其實(shí)有很多解決思路，其中有一個(gè)比較有效的方式就是目前得物技術(shù)正在推進(jìn)的 Mooncake，它的好處是已經(jīng)和發(fā)布系統(tǒng)打通，代碼部署后所有接口和出入?yún)⒌让枋鲂畔⒍紩?huì)上傳到 Mooncake，做到了統(tǒng)一以文檔方式滿足接口出入?yún)⒄f明訴求，執(zhí)行后確實(shí)有不錯(cuò)的收益，但還存在兩個(gè)主要問題：

• 即所謂的契約精神問題，什么時(shí)間交付接口描述，并且描述清晰？在現(xiàn)實(shí)環(huán)境中，這是一個(gè)比較難達(dá)成的事情。服務(wù)端什么時(shí)候能夠上傳接口說明，這個(gè)時(shí)間不確定，即使確定了，也會(huì)出現(xiàn)因?yàn)楦鞣N因素不符合預(yù)期，因?yàn)楹芏嗲闆r下一個(gè)接口和屬性的描述他認(rèn)為描述清楚了，并不代表你能理解，這個(gè)就是信息差，但是真要做到你能夠理解服務(wù)端一定會(huì)付出更多成本，有些人會(huì)認(rèn)為沒必要。
• 服務(wù)端會(huì)修改出入?yún)⒏袷蕉洔贤?，可能到了比較滯后的聯(lián)調(diào)甚至測(cè)試階段才發(fā)現(xiàn)，而且屢禁不止。

在當(dāng)前背景下，解決這個(gè)溝通問題的思路最簡(jiǎn)單的做法，就是讓服務(wù)端一個(gè)角色全棧搞定前后端開發(fā)，為什么是服務(wù)端全棧而不是前端全棧，因?yàn)橹泻笈_(tái)系統(tǒng)的服務(wù)端的工作相對(duì)復(fù)雜，通過需求數(shù)據(jù)分析發(fā)現(xiàn)，服務(wù)端投入工時(shí)是遠(yuǎn)高于前端的，另外一個(gè)原因就是需求前端部分相對(duì)簡(jiǎn)單很多。

三

具象思考

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

低成本的前提就是把復(fù)雜的前端開發(fā)變得簡(jiǎn)單，初期我們考慮了三條路進(jìn)行簡(jiǎn)化：

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

低代碼代替源碼開發(fā)的好處是可以讓服務(wù)端在配置一兩個(gè)頁(yè)面后快速掌握配置技能，它的認(rèn)知成本會(huì)降低，學(xué)習(xí)周期也會(huì)縮短，下面這張圖更方便大家理解。

源碼和低碼學(xué)習(xí)成本趨勢(shì)圖

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

低代碼和幾種跨界工具的學(xué)習(xí)成本對(duì)比

各個(gè)大廠其實(shí)在低代碼領(lǐng)域已經(jīng)做的非常成熟，給大家列舉兩個(gè)做的比較好的，大家可以去深度了解：

• 阿里低代碼引擎：https://lowcode-engine.cn/index 強(qiáng)調(diào)可視化配置生成頁(yè)面；
• 百度 Amis：https://aisuda.bce.baidu.com/amis/zh-CN/docs/index 強(qiáng)調(diào) JSON 配置生成頁(yè)面。

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

• Amis JSON 配置能力更加強(qiáng)大，相對(duì)于 Lowcode Engine 需要寫很多腳本來(lái)滿足稍微復(fù)雜的場(chǎng)景，JSON 配置的學(xué)習(xí)成本更低，更適合服務(wù)端同學(xué)快速上手；
• Amis 的文檔功能更加強(qiáng)大，可以直接編輯 JSON 查看修改后的結(jié)果，這一步可以極大的方便開發(fā)學(xué)習(xí) API。

另外關(guān)于和 AIGC 的結(jié)合，其實(shí)重點(diǎn)要看低代碼在服務(wù)端全棧的場(chǎng)景下，可以幫助解決哪些問題？比如腳本編輯、UI布局等，這些一定會(huì)成為痛點(diǎn)，下面我們將隨著問題的展開逐漸應(yīng)用起來(lái)。

四

對(duì)低代碼的“吐槽”

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

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

五

主要方案設(shè)計(jì)

該篇文章我不會(huì)過多介紹低代碼配置實(shí)現(xiàn)的原理，想了解的可以 Google 下。

我們整個(gè)全棧方案有一個(gè)統(tǒng)一的名字叫 Wizard，包括渲染引擎、組件、在線配置、發(fā)布流程、AI 答疑、AI Proto 等一系列工具，接下來(lái)會(huì)撿重點(diǎn)介紹。

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

另外對(duì)于上面提到的前 4 個(gè)槽點(diǎn)，沒什么好的方法，大家只能認(rèn)清事實(shí)，持續(xù)的去做，針對(duì)第 5 點(diǎn)，我們確實(shí)有一些方向，分享出來(lái)給大家參考，總結(jié)來(lái)講主要是三步：簡(jiǎn)化組件配置、高效初始化頁(yè)面、智能答疑。

簡(jiǎn)化組件配置

得物的基礎(chǔ)組件建設(shè)得益于 Antd 和 ProComponents，好的東西當(dāng)然直接復(fù)用，我們的主要工作是還原得物的設(shè)計(jì)標(biāo)準(zhǔn)以及業(yè)務(wù)組件的沉淀，組件注冊(cè)到 Wizard 中最重要的是要將復(fù)雜屬性轉(zhuǎn)換成 JSON 配置可實(shí)現(xiàn)，比如接口請(qǐng)求、表單聯(lián)動(dòng)、數(shù)據(jù)格式化等，如果這一步做不好，會(huì)導(dǎo)致部分功能被閹割，所以這部分我們花費(fèi)了比較大的精力去設(shè)計(jì)實(shí)現(xiàn)，以表單聯(lián)動(dòng)舉例，效果參考如下動(dòng)圖：

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

源碼實(shí)現(xiàn)：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 配置實(shí)現(xiàn)：

{ "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}" } ] }

上面右側(cè) Wizard 代碼示例中，type 代表組件類型，同級(jí)的其他屬性代表組件API，body 屬于通用屬性用于子元素設(shè)置，認(rèn)真看會(huì)發(fā)現(xiàn)，Wizard 針對(duì)禁用和顯隱設(shè)置增加了 disabledOn 和 visibleOn 兩個(gè)屬性，并且支持寫簡(jiǎn)單的表達(dá)式，類似這種標(biāo)準(zhǔn)屬性的實(shí)現(xiàn)，是所有的組件統(tǒng)一去實(shí)現(xiàn)的（所有的組件都會(huì)支持 visibleOn ，所有的表單類組件都支持 disabledOn ），表達(dá)式是引擎統(tǒng)一實(shí)現(xiàn)的能力，為了更好的支持配置化，Wizard 引擎還支持?jǐn)?shù)據(jù)域、數(shù)據(jù)鏈、模版、數(shù)據(jù)映射、表達(dá)式、函數(shù)、行為等。

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

下面這個(gè)示例，相信大家一看左右結(jié)構(gòu)就能明白研發(fā)同學(xué)的數(shù)據(jù)轉(zhuǎn)換意圖，此處不再啰嗦。

，時(shí)長(zhǎng)00:27

其實(shí)這種功能在有了大模型之后，實(shí)現(xiàn)變得很簡(jiǎn)單，我們只需要設(shè)計(jì)一個(gè)合理的 prompts 即可，雖然輸出的腳本有時(shí)候有點(diǎn)啰嗦，但是準(zhǔn)確率和穩(wěn)定性還是比較高的。

//adaptor 腳本生成 prompts你扮演一個(gè)純函數(shù)代碼生成器，你負(fù)責(zé)生成數(shù)據(jù)格式轉(zhuǎn)換代碼，你負(fù)責(zé)接收函數(shù)出入?yún)⒌奈谋局噶睿鶕?jù)要求生成javascript 代碼，取變量值和給變量賦值的時(shí)候請(qǐng)做好容錯(cuò)處理，處理容錯(cuò)時(shí)不要提前返回undefined或null 幫我生成一個(gè) js 函數(shù): function formatData(payload, response, api) {}，要求最終返回處理好的數(shù)據(jù) response參數(shù): ${before}, 返回?cái)?shù)據(jù)為: ${target}, 只輸出函數(shù)代碼，不要輸出其他無(wú)關(guān)的東西，函數(shù)代碼中的注釋保持中文輸出，其他無(wú)關(guān)信息不要輸出 輸出代碼縮進(jìn)2個(gè)空格

高效初始化頁(yè)面

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

通過頁(yè)面模版初始化

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

通過接口元數(shù)據(jù)生成頁(yè)面

上面提到得物的 Mooncake 平臺(tái)，沉淀了得物所有接口的出入?yún)⑿畔ⅲ琖izard 可以做到選擇接口和頁(yè)面類型生成頁(yè)面描述，根據(jù)接口類型，可以選擇生成列表、表單、詳情，可以復(fù)制到頁(yè)面中成為頁(yè)面主體或者一部分。

根據(jù) PRD 描述快速生成頁(yè)面

這個(gè)是為了解決上面“吐槽”中提到的第5點(diǎn)，很多 PRD 對(duì)于中后臺(tái)需求描述過于簡(jiǎn)單，沒有草圖說明，即使有草圖，對(duì)于全棧同學(xué)也不一定知道怎么還原 UI，Wizard 訓(xùn)練了自有的大模型（關(guān)于模型訓(xùn)練，后面章節(jié)會(huì)介紹），

做到對(duì) Wizard 足夠了解，可以結(jié)合 PRD 描述快速生成頁(yè)面效果（插件 Wizard Proto），我們只需要提供標(biāo)準(zhǔn)的描述頁(yè)面功能的文本格式，產(chǎn)品同學(xué)按照格式填空書寫頁(yè)面結(jié)構(gòu)即可，具體實(shí)現(xiàn)細(xì)節(jié)參考：大模型在產(chǎn)品原型生成中的應(yīng)用實(shí)踐，

通過 Proto 生成的頁(yè)面既可以幫助產(chǎn)品用最低的成本還原頁(yè)面原型，又可以幫助研發(fā)同學(xué)快速還原 UI。

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

智能答疑

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

• 快速了解某個(gè)組件怎么使用或者概念；
• 復(fù)雜的表單聯(lián)動(dòng)關(guān)系；
• 根據(jù)需求生成或者修改頁(yè)面結(jié)構(gòu)；
• 幫你理解頁(yè)面配置。

同時(shí)我們也會(huì)支持針對(duì)回答的內(nèi)容進(jìn)行正向和負(fù)向反饋，這些反饋也會(huì)用于豐富我們的訓(xùn)練池，讓大模型準(zhǔn)確率越來(lái)越高。

這部分能力目前使用率還不夠高，根本問題還是準(zhǔn)確率問題，關(guān)于下一步的規(guī)劃，下面章節(jié)會(huì)提到。

六

大模型訓(xùn)練和應(yīng)用

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

• 根據(jù)文檔中的組件示例、組件 API 描述、概念描述、示例、存儲(chǔ)的 QA 問題等快速生成種子問題。
• Proto 和智能答疑的正負(fù)向反饋都會(huì)被作為訓(xùn)練數(shù)據(jù)放入種子問題中。
• 種子問題數(shù)量有限（1000 以內(nèi)），所以會(huì)進(jìn)過一輪人工的驗(yàn)證，比如你如果發(fā)現(xiàn) SearchPage 組件相關(guān)的問答不夠準(zhǔn)確，可以搜索處理對(duì)種子問題進(jìn)行矯正，如下是一個(gè)簡(jiǎn)單的種子問題校準(zhǔn)工具。

• 針對(duì)種子問題通過成熟大模型進(jìn)行擴(kuò)展生成多條問題，這一步可以實(shí)現(xiàn)數(shù)據(jù)集的成倍增長(zhǎng)，也是為了兼容對(duì)一個(gè)問題不同的表達(dá)，提升模型對(duì)問題的兼容度，主要擴(kuò)展思路如下：
• 問題擴(kuò)充，同一個(gè)問題換說法；
• 根據(jù)答案生成問題。

其實(shí)這里怎么去生成要看場(chǎng)景，主要思路是把大模型當(dāng)做一個(gè)記憶力和理解能力超強(qiáng)的人去看待，你用哪些信息能夠讓它快速理解怎么使用一個(gè)組件，而后決定怎么去準(zhǔn)備你的組件 QA 池。

• 對(duì)訓(xùn)練模型準(zhǔn)確度進(jìn)行綜合評(píng)估，因?yàn)樯厦嫣岬降闹悄艽鹨珊?Proto 都會(huì)有正負(fù)反饋，也能部分說明模型準(zhǔn)確性，更精細(xì)的準(zhǔn)確度評(píng)估我們目前還沒有做，如果要做的話可以參考 Ragas 評(píng)估（https://zhuanlan.zhihu.com/p/675777378），針對(duì)整理的數(shù)據(jù)集可以留一部分 QA 不參與訓(xùn)練，而是用于做準(zhǔn)確度評(píng)估即可。

綜合流程整理如上

目前大模型在 Wizard 核心的應(yīng)用有如下幾種場(chǎng)景。

七

我對(duì)大模型應(yīng)用研發(fā)提效的看法

• 有用，但適可而止：以上五種應(yīng)用場(chǎng)景中的三種都起到了一定的作用，并且我們還在考慮通過大模型實(shí)現(xiàn)數(shù)據(jù) Mock 能力，因?yàn)樗銐蚵斆鳎灰覀儼焉舷挛臄?shù)據(jù)和 type Interface 全部給他，可以用比較低的成本實(shí)現(xiàn)CQUD 的接口，但每一種應(yīng)用在我們的方案設(shè)計(jì)里面，都不是必經(jīng)路徑，核心是因?yàn)樵谘邪l(fā)這條路上，模型的準(zhǔn)確率沒有想象那么高，很多情況下需要人為糾正，這個(gè)也是我們實(shí)踐下來(lái)的一個(gè)最明顯的認(rèn)知，不要想著把大模型訓(xùn)練的特別牛，準(zhǔn)確率特別高，ROI 不一定合理，從輔助研發(fā)的角度，我認(rèn)為能達(dá)到 70% 以上已經(jīng)是非常了不起了（Wizard 大模型目前準(zhǔn)確率 60%），除非你們成立了一個(gè)專業(yè)團(tuán)隊(duì)，長(zhǎng)時(shí)間投入。
• 增強(qiáng)針對(duì)性：很多情況下太泛的應(yīng)用會(huì)影響大模型的準(zhǔn)確度，我們?cè)趯?shí)際場(chǎng)景中可以結(jié)合嚴(yán)謹(jǐn)?shù)?prompts 和 TypeChat 這種工具，縮小大模型回答的范圍，因?yàn)槟阒赶蛟矫鞔_，大模型回答的越精確，像上面提到的用于數(shù)據(jù)格式轉(zhuǎn)換的腳本生成，一般很少會(huì)出問題，除非站在人的角度沒法理解你要轉(zhuǎn)換的意圖，那就是你的輸入有問題了。
• 不要逃避：個(gè)人認(rèn)為 AIGC 一定是未來(lái)趨勢(shì)，各行各業(yè)可能都會(huì)發(fā)生變革，包括研發(fā)，一味地按照固有思維去解決問題或者不愿去了解，未來(lái)大概率會(huì)吃虧的，你不一定要自己學(xué)會(huì)怎么訓(xùn)練大模型，但最起碼要掌握兩點(diǎn)：大模型的成長(zhǎng)性新聞以及應(yīng)用場(chǎng)景。個(gè)人認(rèn)為，未來(lái)簡(jiǎn)單頁(yè)面的開發(fā)工作可能真的會(huì)被生成式 AI 替代，如果你現(xiàn)在的工作就是在做類似簡(jiǎn)單 CQUD 的事情，那一定要焦慮一下了，快去多翻翻社區(qū)。一個(gè)很現(xiàn)實(shí)的例子：“十年夢(mèng)碎，蘋果放棄造車轉(zhuǎn) AI”，不造車可以理解成對(duì)新能源不看好或者認(rèn)為已經(jīng)很飽和，但是轉(zhuǎn)生成式AI，這個(gè)一定是對(duì)未來(lái)的深刻信心和期許。

八

功能架構(gòu)圖

Wizard 的更多細(xì)節(jié)功能可以參考如下架構(gòu)圖。

功能架構(gòu)圖

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

a. 通過示例模板創(chuàng)建頁(yè)面；

b. 通過 Mooncake 元數(shù)據(jù)創(chuàng)建頁(yè)面；

c. Proto 工具實(shí)現(xiàn)根據(jù) PRD 智能生成頁(yè)面。

2. Mock 能力使得 Proto 生成的頁(yè)面效果更加逼真，包括動(dòng)態(tài)枚舉，列表數(shù)據(jù)，表單提交等，既方便了產(chǎn)品豐富頁(yè)面原型，又降低研發(fā)復(fù)用創(chuàng)建頁(yè)面的成本。

3. Migrate 用于結(jié)合 AIGC 對(duì)于 ProTable、ProForm 等常用組件的配置轉(zhuǎn)換成 Wizard 配置，用于進(jìn)一步降低就頁(yè)面遷移到 Wizard 頁(yè)面的成本，提升全棧占比。

4. 基于天網(wǎng)和統(tǒng)一配置中心，完善了調(diào)試、發(fā)布、回滾、下線、菜單和權(quán)限管理等能力。

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

a. 幫助產(chǎn)品畫原型圖，生成的頁(yè)面可用于進(jìn)一步配置；

b. 全棧答疑，降低認(rèn)知成本；

c. 分析源碼轉(zhuǎn)換成 Wizard 頁(yè)面，降低頁(yè)面遷移成本；

d. 后期還會(huì)考慮通過需求描述做頁(yè)面功能修改，進(jìn)一步降低認(rèn)知成本；

e. 通過訓(xùn)練大模型解決復(fù)雜的表達(dá)式生成問題，進(jìn)一步降低聯(lián)動(dòng)配置成本。

九

問題和規(guī)劃

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

需求提出流程

需求評(píng)估和交付流程

十

參考

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

來(lái)源-微信公眾號(hào):得物技術(shù)

出處:https://mp.weixin.qq.com/s/FYri0B2jYCsOVhrENUKAzQ