風口已至，多領域平臺融入社交元素！
在眾多領域平臺中，社交元素都扮演著重要角色，如直播營銷帶貨、線上配對聽歌、游戲局內互動等。隨著元宇宙時代的來臨，社交產(chǎn)品不斷升級，社交元素推動流量變現(xiàn)，多平臺領域融入社交
現(xiàn)在截圖生成代碼，已經(jīng)來到了一個新高度 —— ?個?向現(xiàn)代前端代碼?成的多模態(tài)?模型解決?案，來了！而且是開源的那種。
（注：現(xiàn)代前端代碼開發(fā)具有組件化、狀態(tài)管理和數(shù)據(jù)驅動渲染、開發(fā)規(guī)范嚴格以及動態(tài)交互性強等特點。這些特點相互關聯(lián)，共同構成了現(xiàn)代前端開發(fā)的復雜體系，對代碼生成提出了更高要求。如基于 React、Vue 等框架的開發(fā)。）
這個模型叫做 Flame，話不多說，直接來看效果。
例如截圖讓 AI 生成下面這個界面：
Flame 模型在“看”完圖片之后，給出來的代碼是這樣：
不難看出，F(xiàn)lame ?成代碼明顯是符合現(xiàn)代前端開發(fā)規(guī)范的，包括?較清晰的外聯(lián)樣式以及模塊化組件結構。
同時在組件的實現(xiàn)中正確定義了組件的各個狀態(tài)、事件響應、以及基于數(shù)據(jù)的組件動態(tài)渲染。
然而，誠如 GPT-4o 這樣頂尖的 SOTA 模型，可能也與現(xiàn)代前端開發(fā)的核?需求背道?馳，因為局限在于端到端復刻設計圖的過程中只能產(chǎn)出靜態(tài)組件。
例如同樣的界面，GPT-4o 的解法是這樣的：
問題根源在于這類靜態(tài)代碼既?法?撐模塊化架構，也難以?撐動態(tài)交互。
每個組件都是“?次性產(chǎn)物”，任何細微的需求開發(fā)和迭代，可能都要開發(fā)者開發(fā)?量定制化代碼，甚?是推倒重來。
那么 Flame 模型又是如何解決這個問題的呢？
核心問題：數(shù)據(jù)稀缺?型視覺語?模型（LVLM）在?成專業(yè)前端代碼上表現(xiàn)不盡?意的根本原因在于數(shù)據(jù)稀缺。
現(xiàn)代前端開發(fā)流程?常復雜，?如像 React 這樣的前端框架，強調組件化、狀態(tài)管理和數(shù)據(jù)驅動的渲染?式。
這就要求?成的代碼不僅要能?，還要符合開發(fā)規(guī)范，具備動態(tài)性和響應性。
然?，開源社區(qū)中?持前端開發(fā)的?質量圖像-?本（代碼）數(shù)據(jù)集極度稀缺。
像 websight 這樣的數(shù)據(jù)集只涉及靜態(tài) HTML，不適?于現(xiàn)代前端開發(fā)。
收集并構建?質量的訓練數(shù)據(jù)?臨許多挑戰(zhàn)：
如何從公共代碼庫中提取有效代碼片段？
如何在保持原有代碼效果的情況下進行渲染？
如何?成符合?程師習慣的?量、多樣化數(shù)據(jù)？
針對這些問題，F(xiàn)lame 模型的團隊給出了解法就是數(shù)據(jù)合成。
為提升 LVLM 在前端代碼?成能?，我們設計了?整套?反思的智能體?作流，?于?成前端開發(fā)場景下的?質量數(shù)據(jù)。
該?作流不僅能?動從公共代碼庫中提取真實數(shù)據(jù)，還能夠?主合成數(shù)據(jù)，?成專業(yè)、多樣化的前端代碼。
團隊設計并實現(xiàn)了 3 種合成?法：
借鑒 WizardLM 的 Evol-Instruct ?法，通過隨機進化?成多樣化的代碼。它采?兩種策略：?度進化和深度進化。
?度進化通過改變代碼的功能和視覺?格，?成新變體；深度進化則通過增加代碼的技術復雜度，優(yōu)化組件處理、狀態(tài)管理和性能，提升代碼的可靠性和可維護性。
通過不斷進化，可以得到?量覆蓋不同需求的前端代碼。
基于瀑布模型的數(shù)據(jù)合成（Waterfall-Model-Based Synthesis）模擬傳統(tǒng)軟件開發(fā)的瀑布流模型，確保?成的代碼結構清晰、邏輯?致。從需求分析開始，推導出系統(tǒng)功能需求，設計 UI 布局和架構，保證代碼符合現(xiàn)代前端開發(fā)的模塊化和可擴展性要求。
接著，通過多輪迭代，將需求轉化為具體的、可復?的前端組件和??。這種?法?成的代碼邏輯清晰，適合復雜功能的開發(fā)任務。
基于增量開發(fā)的數(shù)據(jù)合成（Additive Development Synthesis）在現(xiàn)有代碼基礎上，逐步增加功能和復雜性。通過逐步集成狀態(tài)管理、交互邏輯或 API 等功能模塊，?成的代碼能更好地滿?實際開發(fā)需求。
這種?法強調逐步提升代碼的功能和復雜度，確保每次擴展都最?可能符合最佳實踐。
上述的三種?法不僅豐富了數(shù)據(jù)集的規(guī)模和多樣性，還確保了數(shù)據(jù)質量與實際應?價值。
這些?法能夠低成本?規(guī)模合成特定前端框架的圖?數(shù)據(jù)，借助上述?法，F(xiàn)lame 團隊針對 React 框架構建了超過 400k 的多模態(tài)數(shù)據(jù)集。
同時，基于瀑布模型和增量開發(fā)的?法還?持多圖場景下的數(shù)據(jù)合成、視覺思維鏈的合成，為更復雜場景下的前端代碼?成提供了更多可能。
Flame：針對前端開發(fā)場景的 VLMFlame 團隊??構建了?套包含 80 道測試題?的?質量測試集并通過改進后的 Pass@k 來評測多模態(tài)模型的前端代碼?成能?。
如果?成的代碼能夠通過編譯驗證、符合編碼規(guī)范，并且所渲染出的??與輸?的設計圖?夠相似，則認為該代碼符合要求。
評測結果顯?，當前頂級模型如 GPT-4o，Gemini 1.5 Flash 因其?成代碼主要為靜態(tài)代碼，嚴重偏離代碼規(guī)范，使其最? Pass@1 僅為 11%，? Flame 在相同條件下達到了 52%+，展現(xiàn)出了極?的潛?。
同時，F(xiàn)lame 僅? 20w 左右的數(shù)據(jù)量級即取得以上成果，進?步驗證了上述數(shù)據(jù)合成?法的價值以及?質量數(shù)據(jù)集在多模態(tài)模型能?提升中的關鍵作?。
△ 左：測試圖；右：Flame 效果圖
值得一提的是，將訓練數(shù)據(jù)、數(shù)據(jù)合成流程、模型及測試集已經(jīng)全?開源，感興趣的小伙伴趕緊去看看吧。
GitHub 地址：
https://github.com/Flame-Code-VLM/Flame-Code-VLM/blob/main/README.md
本文來自微信公眾號：量子位（ID：QbitAI），作者：關注前沿科技
本文鏈接：http://www.www897cc.com/showinfo-45-11193-0.html前端程序員請注意：首個截圖就能生成現(xiàn)代前端代碼的 AI 開源
聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號