一

背景

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

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

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

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

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

二

思考

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

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

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

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

三

具象思考

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

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

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

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

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

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

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

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

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

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

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

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

四

對低代碼的“吐槽”

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

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

五

主要方案設(shè)計

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

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

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

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

簡化組件配置

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

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

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

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

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

，時長00:27

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

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

高效初始化頁面

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

通過頁面模版初始化

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

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

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

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

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

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

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

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

智能答疑

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

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

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

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

六

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

Wizard 應(yīng)用的基礎(chǔ)大模型是更擅長做代碼生成的 DeepSeek Coder，我們使用的版本參數(shù)個數(shù)是 6.7b，但其實模型準(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 描述、概念描述、示例、存儲的 QA 問題等快速生成種子問題。
• Proto 和智能答疑的正負(fù)向反饋都會被作為訓(xùn)練數(shù)據(jù)放入種子問題中。
• 種子問題數(shù)量有限（1000 以內(nèi)），所以會進(jìn)過一輪人工的驗證，比如你如果發(fā)現(xiàn) SearchPage 組件相關(guān)的問答不夠準(zhǔn)確，可以搜索處理對種子問題進(jìn)行矯正，如下是一個簡單的種子問題校準(zhǔn)工具。

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

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

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

綜合流程整理如上

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

七

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

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

八

功能架構(gòu)圖

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

功能架構(gòu)圖

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

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

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

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

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

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

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

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

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

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

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

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

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

九

問題和規(guī)劃

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

需求提出流程

需求評估和交付流程

十

參考

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

來源-微信公眾號:得物技術(shù)

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