大模型下B端前端代碼輔助生成的思考與實踐
一、背景
重復工作，代碼規范：B端前端代碼開發過程中開發者總會面臨重復開發的痛點，很多CRUD頁面的元素模塊基本相似，但仍需手動開發，將時間花在簡單的元素搭建上，降低了業務需求的開發效率，同時因為不同開發者的代碼風格不一致，使得敏捷迭代時其他人上手成本較高。
AI代替簡單腦力：AI大模型的不斷發展，已經具備簡單的理解能力，并可以進行語言到指令的轉換。對于基礎頁面搭建這樣的通用指令可以滿足日常基礎頁面搭建的需要，提升通用場景業務開發效率。
二、生成鏈路一覽
B端頁面列表、表單、詳情都支持生成，鏈路大概可分為以下幾個步驟。
圖片
- 輸入自然語言
- 結合大模型按照指定規則提取出相應搭建信息
- 搭建信息結合代碼模板與AST輸出前端代碼
三、表達需求
圖形化配置
輔助代碼生成第一步是告訴它開發出怎樣的界面，提到這里，我們首先想到的是頁面配置，即目前主流的低代碼產品形式，用戶通過一系列的圖形化配置對頁面進行搭建，如下圖：
圖片
以上配置方式對于通用場景（如后臺邏輯較為簡單的CURD頁面）或是特定的業務場景（如會場搭建）有較好的提效作用 。而對于需要不斷迭代邏輯相對復雜的需求來說，由于是通過圖形化操作的方式進行配置，對于交互設計要求較高，并且具備一定的上手成本，并且隨著需求的復雜度越來越高，配置表單交互越來越復雜，維護成本也越來越高。因此，頁面配置的方式前端領域的使用是相對克制的。
AI直接生成代碼
AI生成代碼在工具函數場景下應用較多，但對于公司內部特定業務場景的需求，可能需要考慮以下幾點：
- 生成定制化：公司團隊內部有自己的技術棧與重型通用組件，需要將這些知識進行預訓練，目前對于長文本的預訓練內容僅支持單次會話注入，token數消耗較高；
- 準確度：AI生成代碼的準確度挑戰是比較大的，加上預訓練包含大段prompt，因為代碼輸出的內容細節過多，加上模型幻覺，目前來看業務代碼的失敗率是較高的，而準確度是考量輔助編碼的核心指標，如果這一點無法解決，輔助編碼效果將大打折扣；
- 生成內容殘缺：由于GPT單次會話的存在限制，對于復雜需求，代碼生成有一定幾率被截斷，影響生成成功率。
自然語言轉指令
GPT其實還有個很重要的能力，那就是自然語言轉指令，指令即行動，舉個例子：我們假設一個函數方法實現，輸入是自然語言，結合GPT與內置的prompt，讓其穩定的輸出某幾個單詞，我們是不是就可以通過對這些單詞輸出做出進一步的行動？這相對于圖形化配置有以下幾個優點：
- 學習門檻低：因為自然語言本身就是人類的原生語言，你只需要根據你的想法描述頁面即可，當然描述的內容是需要遵循一些規范的，但相對于圖形化配置來說效率是有明顯提升的；
- 復雜度黑盒：圖形化配置的復雜度會隨著配置頁面復雜度的上升而上升，而這樣的復雜度會一覽無余地展示在用戶面前，用戶可能會迷失在復雜的配置頁面交互中，配置成本逐步上升；
- 敏捷迭代：如果要在用戶端新增一個頁面配置功能，基于大模型的交互方式可能只需要新增幾個prompt，但圖形化配置需要開發復雜表單以便于快速輸入。
這里大家可能會有個疑問：
生成的指令信息不也會出現大模型幻覺嗎？如何保證每次生成指令信息是穩定且一致的呢？
自然語言轉指令可行大致有以下幾個原因：
- 由長文本轉關鍵信息屬于總結內容，大模型在總結場景下的準確度遠高于擴散型場景；
- 由于指令信息只是提取需求中的關鍵信息，不需要做代碼技術棧上的預訓練，因此prompt存在很大的可優化空間，通過優化完善prompt內容可以有效提升輸出準確度；
- 準確性可驗證，對于每一個場景不同表述需求輸入，可以通過單測預測輸出驗證準確性，當出現badCase，我們在優化后針對該badCase接入單測。保證準確度不斷提高。
讓我們來看最終的信息轉化結果：
對于代碼輔助來說，基于用戶的需求描述，經過PROMPT處理，可以拿到這樣的信息。為代碼生成提供基礎信息。
圖片
四、信息轉化為代碼
通過大模型拿到自然語言對應可編碼的信息（即上面例子中的JSON）后，我們就可以基于這個信息轉化代碼了。對于一個有明確場景的頁面而言，一般情況下可分為主代碼模板（列表、表單、描述框架）+ 業務組件。
轉化流程
圖片
我們如何開發代碼的？
其實這一步很像我們自己開發代碼，我們拿到需求后，大腦中會提取其中的關鍵信息，即上方提到的自然語言轉指令，然后我們會在vscode中創建一個文件，然后會進行以下操作：
首先一定是創建代碼模板，然后根據場景引入對應重型組件，如列表就引入ProTable，表單就引入ProForm。
基于ProTable等重型組件并向其中添加一些屬性，如headerTitle、pageSize等列表相關信息。
根據需求描述引入組件，比如識別到篩選項中存在類目選擇，會在useColumns新增業務組件，識別到需求描述中存在導入導出組件，會在頁面的指定位置新增導入導出業務組件。
拿到mock鏈接，新增請求層，在頁面指定位置引入。
對于以上常用的代碼插入場景都可以封裝進JSON中，然后通過代碼模板結合AST插入或字符串模板替換的方式生成對應代碼。
五、源碼生成
定位
源碼輔助主要幫助開發者減少重復的工作，提升編碼效率，和低代碼頁面搭建屬于完全不同的賽道，低代碼重在特定場景下搭建完整的頁面，并且頁面功能數量是可枚舉的，業界低代碼搭建也有很優秀的實踐。而源碼輔助工具旨在幫助用戶盡可能多的初始化業務需求代碼，后面的修改維護在代碼層面交給用戶，提升新增頁面的開發效率。
具體的功能架構見下方：
圖片
六、組件向量搜索與嵌入
對于前端開發來說，提效的本質是少開發代碼，更快的頁面生成是一方面，良好的組件抽離是相當重要的一環，我們結合向量對組件的引入鏈路進行了優化，在初始化模板與存量代碼中快速搜索定位組件。
組件向量引入鏈路
圖片
組件信息錄入
支持快速獲取組件的描述內容與組件引入范式，一鍵錄入組件，組件描述會轉化為向量數據存入向量數據庫。
圖片
組件向量搜索
用戶輸入描述后，會將描述轉化為向量，基于余弦相似度與組件列表進行比對，找到相似度最高的組件TOP N。
圖片
組件快速插入
用戶可以在存量代碼中快速通過描述搜索匹配度最高的組件，回車進行插入。
圖片
七、未來展望
- 組件嵌入模板：目前組件已支持向量搜索，通過結合源碼頁面生成，支持動態匹配組件并嵌入模板；
- 存量代碼的編輯生成：目前僅支持新增頁面的源碼生成，后續將支持存量頁面的局部代碼新增；
- 代碼模板流水線：AST的代碼操作工具化，將自然語言與代碼寫入進一步打通，提升場景拓展效率。
