人機協同時代，AI助力90.4%雙11前端模塊自動生成

背景介紹

2017 年，一篇論文 pix2code: Generating Code from a Graphical User Interface Screenshot 引發業界關注，論文講述了使用深度學習技術實現從一張 UI 截圖識別生成 UI 結構描述，而後將 UI 結構描述轉成 HTML 代碼。有人認爲這種從 UI 截圖直接生成代碼的意義不大，AI 和 Sketch 軟件原本就是用數據結構保存設計文件的結構描述，不須要經過機器學習來獲取，並且生成的代碼不肯定性很大。也有一部分人對這個思路給予確定，提出讓深度學習模型學習 UI 界面特徵，還能夠作 UI 智能設計。

隨後基於 pix2code 開發的 Screenshot2Code 項目進入 Github 排行榜第一名，該工具可以自動將 UI 截圖轉成 HTML 代碼，該項目做者號稱 3 年後人工智能會完全改變前端開發，對此也有很多用戶表示質疑，認爲前端技術複雜框架各異，僅 HTML 代碼沒法知足需求。

2018 年，微軟 AI Lab 開源了草圖轉代碼工具 Sketch2Code**，**一些人認爲生成代碼效果不理想不適用於生產環境，但也有人認爲代碼自動生成還處於初級階段，將來發展值得想象。

2019 年，阿里巴巴對外開放智能生成代碼平臺 imgcook，能夠經過識別設計稿（Sketch/PSD/圖片）智能生成 React、Vue、Flutter、小程序等不一樣種類的代碼，並在同年雙 11 大促中自動生成了 79.34% 的前端代碼，智能生成代碼再也不只是一個線下實驗產品，而是真正產生了價值。

每當這些新的自動生成代碼產品發佈，網絡上總會出現「人工智能會不會取代前端」「一大批前端程序員要失業了」這些討論。

那人工智能到底會不會取代前端？人工智能在將來很長的一段時間內不會取代前端，可是會改變前端。一是會改變在前端智能化方向的前端領域探索者，他們除了能夠成爲 Nodejs 服務端工程師，還能夠成爲機器學習工程師，爲前端智能化領域創造更多的價值和成果；二是會改變享受前端智能化成果的前端開發者，改變他們的研發方式，例如代碼智能生成、代碼智能推薦、代碼智能糾錯、UI 自動化測試等能夠幫助他們完成大量簡單重複的工做，能夠把更多的時間放在更有價值的事情上。

本篇文章將給你們分享做爲前端智能化領域的探索者，咱們是如何看待人工智能在前端領域的將來發展方向，如何推動智能化能力在智能生成代碼平臺 imgcook 上的應用落地和迭代升級助力今年雙 11 會場 90.4% 新模塊的代碼智能生成，編碼效率提高 68% 的。

階段性成果

imgcook（www.imgcook.com）官網首頁平均每個月 PV 6519， 平均每個月 UV 3059。相比於 2019 年， 2020 年月平均 PV 和 UV 均是 2019 年的 2.5 倍。

imgcook 用戶共有 18305 個，其中社區用戶佔比 77%，阿里集團內用戶佔比 23%。imgcook 模塊共有 56406 個，其中外部模塊佔比 68%，內部模塊佔比 32%。相比 2019 年以前總量，2020 年用戶增加 2.7 倍，模塊增加 2.1 倍。

社區覆蓋公司至少 150 家，集團內部覆蓋 BU 10 個以上，雙 11 會場新增模塊覆蓋度 90.4%，無人工輔助狀況下智能生成的代碼被保留髮布上線的佔比 79.26%，編碼效率（模塊複雜度和研發耗時比值）提高 68%。

與 2019 年相比，用戶感官提效提高 14%；和徹底不使用 D2C 相比，固定人力單位時間模塊需求吞吐量提高約 1.5 倍。與傳統研發模式相比，使用 imgcook 研發鏈路編碼效率可提高約 68%。

（Imgcook 研發效能數據概覽）

技術產品體系升級

技術原理簡介

咱們先來了解下 imgcook 智能生成代碼的原理， imgcook 可以自動生成代碼主要是作了兩件事:  從視覺稿中識別信息，而後將這些信息表達成代碼。

本質是經過設計工具插件從設計稿中提取 JSON 描述信息，經過規則系統、計算機視覺和機器學習等智能還原技術對 JSON 進行處理和轉換，最終獲得一個符合代碼結構和代碼語義的 JSON，再用一個 DSL 轉換器，轉換爲前端代碼。DSL 轉換器就是一個 JS 函數，輸入是一個JSON，輸出就是咱們須要的代碼。例如 React DSL 的輸出就是符合 React 開發規範的 React 代碼。

（D2C 智能生成代碼使用動線）

其中核心部分在於 JSON to JSON 這部分。設計稿中只有圖像、文本這些元信息，位置信息是絕對座標，而且設計稿中的樣式與 Web 頁面中的樣式表現存在差別，例如 sketch 中透明度 opacity 屬性不會影響子節點，但在網頁中 opacity 會影響子節點，而人工編寫的代碼具備各類佈局類型、DOM 結構須要合理可維護、代碼須要語義化、組件化、循環等信息。

如何能智能生成像人工編寫這樣的代碼，這是智能還原這部分要解決的事情。咱們把 D2C 智能還原部分作了能力分層，每一層的輸入和輸出都是 JSON，智能還原部分的本質是一層一層的作 JSON 轉換，這就是整個智能還原的流程。若是須要對生成的 JSON 作修改，能夠經過 imgcook 編輯器可視化干預，最終經過 DSL 開放層將獲得的符合代碼結構和語義的 JSON 轉換爲代碼。

（D2C 智能還原技術分層）

智能還原的核心鏈路構成了 D2C 的核心技術體系，並經過度量體系來衡量核心還原能力和研發提效效果。下層依託算法工程體系提供核心技術體系中智能化能力的底層服務，包括樣本製造、算法工程服務、前端算法工程框架，上層經過 D2C 研發體系承接智能還原的後置鏈路，經過提供可視化干預能力知足用戶二次迭代的需求，並經過將工程鏈路內置到 imgcook 平臺實現一站式開發、調試、預覽和發佈來提高總體的工程效率。再加上支持自定義 DSL、自定義開發物料等擴展性很強的自定義能力造成的開放體系一塊兒構成了整個 D2C 架構，服務於阿里內部 C 端、小程序、中後臺等以及外部社區各類不一樣的業務場景。

（D2C 技術架構圖）

今年在前端智能化大背景下，對 D2C 技術體系全鏈路進行了智能化能力升級，併爲前端同窗帶來了讓前端工程師能成爲機器學習工程師的前端算法工程框架 Pipcook 和解決樣本收集問題的樣本製造機 Samplecook。同時帶來了營銷模塊研發鏈路產品化升級，助力全鏈路研發提效。

智能化能力升級

智能化能力分層定義

《汽車駕駛自動化分級標準》基於駕駛自動化系統可以執行動態駕駛任務的程度，根據在執行動態駕駛任務中的角色分配以及有無設計運行條件限制，將駕駛自動化分紅 0 至 5 級。在高級別的自動駕駛中，駕駛員的角色向乘客轉變。這種明確的標準有助於各種企業更有針對性展開研發和技術部署的工做。

（自動駕駛分級標準）

參考自動駕駛分級標準，基於 D2C 系統可以自動生成代碼的程度，根據編碼的角色以及是否須要再人工干預和驗證，咱們定義了一個 D2C 系統交付的分級標準，用來幫助咱們認識 D2C 系統當前所處的級別以及下一階段的發展方向。 (D2C 系統交付分級參考標準)

目前 imgcook 的能力處於 D2C 的 L3 級別，智能生成的代碼還須要可視化干預或人工兜底開發後驗證上線。將來指望達到 L4 級別，咱們須要對 UI 信息架構進行拆解，對從 UI 信息自動生成代碼的智能化能力進行細分。

（UI 信息架構拆解）

一個應用由多個頁面組成，每一個頁面中按 UI 顆粒度劃分能夠分爲模塊/區塊、原子模塊/區塊、組件（業務組件、基礎組件）、元件。每個顆粒度的 UI 咱們都須要識別到它的佈局結構和語義，才能生成像人工編寫同樣模塊化、組件化、語義化的可維護性較高的代碼。

根據對 UI 信息架構的拆解，咱們結合 imgcook 生成代碼的技術體系從不一樣顆粒度對智能化能力進行分級 I0-I5（I 是 Intelligent 的首字母）。

（D2C 智能化能力分級）

其中塗色部分是目前已具有的能力，從這個維度來看 imgcook 的智能化能力目前處在 I3 和 I4 級別，並與 I2 級別的能力協同運做於生產環境。 I3 級別的智能化能力須要不斷優化和迭代模型，當線上真實場景準確率達到 75% 以上或模型具有自我迭代能力則進入 I4 級別。若是達到了 I5 級別的智能化能力，根據 D2C 系統交付分級參考標準，D2C 系統交付分級能夠從 L3 進入 L4， 生成的代碼將不須要人工干預和驗證便可直接上線。

固然咱們可能會長期處於 L4 級別這我的機協同編程的階段，這種分級的定義是爲了促進智能化落地的進程，能夠指導 咱們提高 D2C 智能化能力，對 D2C 智能化有個更清晰的認識。

咱們以生成代碼的可用度做爲整體技術指標，並根據代碼生成鏈路的技術分層給出各階段的技術指標以及對代碼可用率影響的權重，其中生成代碼的理論準確度 = (各個環節準確度 * 權重)之和，而真實的代碼可用率 = imgcook 生成的代碼在最終上線的代碼中留存的佔比。 （各分層技術指標與權重定義）

D2C 的智能化能力分佈在還原鏈路的各個階段，咱們以提高代碼可用率爲目標，對全鏈路進行智能化能力升級，將技術方案細化到如何讓各階段模型識別準確率提高以及如何能將識別結果最終應用到智能還原鏈路生成代碼，如何作到從樣本收集、模型訓練、模型部署到模型應用到工程鏈路整個流程可以自動化、自我迭代優化，不斷優化和迭代模型能力。

智能化能力的應用還須要工程鏈路的支撐，例如模型識別結果的應用、線上用戶行爲召回、前端開發組件對 UI 組件識別結果的承接等，總體的 D2C 技術體系也須要同步升級。

（D2C 技術體系升級大圖）

各階段智能化能力升級

圖層解析階段

imgcook 經過解析設計稿圖層信息，並經過規則系統、智能化技術等識別和生成代碼，但因爲設計域與研發域的表達方式、結構和規範等差別，設計稿的圖層結構對生成代碼的合理性影響較大，一些設計不規範的設計稿須要用 imgcook 的「成組」和「圖片合併」協議對設計稿進行調整。

開發同窗在開發代碼時也常常會有寫多餘的 console.log、沒有註釋、變量重複聲明等代碼不規範的問題，爲了解決這些問題，提供了 ESLint、JSLint 等工具來保障代碼規範的統一。

在設計域，咱們也一樣能夠開發一套設計稿規範智能檢查工具來保障設計規範，智能審查設計稿的規範性，提示錯誤並輔助調整。咱們把這套工具稱爲 Design Lint（DLint），具體的實現方案能夠關注後續的設計稿生成代碼 imgcook 3.0 系列設計稿規範智能檢查篇。

（設計規範檢查）

物料識別階段

UI 物料能夠分爲模塊/區塊、組件和元件，從 Sketch/PSD 中直接提取的信息只有文本、圖片和位置信息，直接生成的代碼都是由 div、img、span 組成，實際開發中組件化、代碼語義化必不可少，如何從設計稿中提取組件和語義信息，這是 NLP、深度學習等智能化技術很是適合解決的問題。

去年咱們在組件識別、圖片識別、文本識別這幾個方向都有探索和實踐，識別的結果最終用於語義化和字段綁定，但使用的技術方案對識別的效果限制較大，今年咱們作了以下改進：

組件識別 本來使用目標檢測的方案來識別 UI 組件，但這種方案既須要識別出正確的組件類別還須要識別出正確的位置，以整個視覺圖片做爲輸入，複雜的圖片背景很容易被誤識別，而且因爲識別出的位置誤差致使很難掛載到正確的節點上，模型識別結果在線上的應用準確率較低。

基於這些緣由，以及 imgcook 可以從視覺稿中獲取每一個圖層位置信息的優點，咱們將方案轉換成了圖片分類，並能將識別結果然正的應用到線上，這其中依託一套組件可配置、可識別、可渲染、可干預、可出碼的智能物料體系。具體實現方案能夠關注後續的設計稿生成代碼 imgcook 3.0 系列組件識別篇。

（組件識別應用全鏈路）

如下是組件識別應用到線上的演示，識別視覺稿中的視頻信息，並用 rax-video 前端組件承接生成組件粒度的代碼，須要配置自定義的組件(組件庫設置)、組件識別模型服務(模型服務設置)、支持渲染 video 組件的畫布資源（編輯器配置-畫布資源）以及應用組件識別結果的業務邏輯點（業務邏輯庫配置）。

（組件識別全鏈路演示）

Icon 識別 Icon 識別實際上是一個圖片分類的問題，依然沿用圖片分類的方案，但爲了可以讓模型的泛化能力能自我加強，咱們設計了一個 Icon 自動收集、處理數據、自動訓練模型、自動發佈模型的模型閉環鏈路，讓模型可以自我迭代優化。 （Icon 識別模型閉環鏈路）

自上線以來，新增訓練集總數達到了 2729 個，平均每個月回撈有效數據 909 個, 模型通過幾回自我迭代測試集的準確度從 80% 提高到了 83%。具體實現方案能夠查看 物料識別篇之 Icon 識別模型閉環鏈路搭建。

圖片/文本語義識別 在 imgcook 智能化系統中有一個很關鍵的部分，就是如何對 UI 界面內的元素綁定語義化信息，以前解決方法是基於圖片和文本分類模型識別，該方法有很大的侷限性：僅對文本進行分類，沒有考慮與整個 UI 界面內的上下文語義，致使模型效果很差。

舉個例子：$200，這個字段文本分類是沒辦法對其進行語義識別的，由於它放到不一樣的場景中有着不一樣的意思，如：活動價、原價、優惠劵...，正確的作法是考慮該字段與在 UI 界面的聯繫（即獨特的樣式）來對它進行語義分析。

所以，咱們引入了一種能結合 UI 中上下文語義的方案來進行語義識別，採用圖片元素決策+文本分類兩步走的方案解決界面元素語義化問題，具體流程是：先基於強化學習對界面元素按樣式「過濾」一遍，識別出有樣式的非純文本字段，再對純文本的字段進行文本分類。具體框架以下。

（強化學習 + 文本分類）

如下是模型算法訓練結果，具體的探索和實踐方案能夠查看 物料識別篇之基於UI上下文語義的文本分析。 （基於上下文的語義分析）

佈局還原階段

佈局便是代碼中每一個節點與節點之間的關係，是父子關係仍是兄弟關係。從顆粒度大小上劃分，能夠分爲頁面間模塊/區塊以前的關係、模塊/區塊內原子模塊/區塊之間的關係以及原子模塊/區塊內組件、元件之間的關係。

目前 imgcook 已具有了循環識別與多態識別的能力，識別設計稿中的循環體生成循環代碼，識別同一個節點有多種 UI 狀態時生成多狀態的 UI 代碼，並定義了佈局可維護度衡量方式來衡量還原階段的準確度。具體技術方案能夠關注後續的設計稿生成代碼 imgcook 3.0 系列佈局還原篇。 （佈局還原階段識別能力升級）

邏輯生成階段

在業務邏輯生成階段優化原有的配置鏈路，將業務邏輯庫與算法工程鏈路解耦，並承接全部識別結果的應用和表達。物料識別階段只關心 UI 中有什麼物料，不關心識別的結果如何用於生成代碼，佈局還原階段的循環識別和多態識別同理。這樣作的好處是咱們能夠自定義識別結果的表達，而且可讓用戶感知智能識別的結果並選擇是否使用。

除了從業務邏輯庫生成邏輯代碼也能夠從需求稿生成部分邏輯，或者來源於代碼片斷推薦，或者來源於代碼智能推薦（ Code to Code，C2C）。關於業務邏輯生成階段的實踐和思考請關注後續的設計稿生成代碼 imgcook 3.0 系列 業務邏輯生成篇。

（通用業務邏輯庫配置）

算法工程體系升級

樣本製造機

算法工程服務提供了 UI 特徵識別的模型訓練產品，爲全部想使用業務組件識別的小夥伴打造一個玩弄機器學習的鏈路。爲了解決使用算法工程服務的關鍵痛點，因此有了新的衍生產品：樣本製造機，爲前端 UI 識別的模型提供樣本製造捷徑。具體請關注後續的設計稿生成代碼 imgcook 3.0 系列算法工程篇之樣本製造機 Samplecook

前端算法工程框架

有不少同窗會以爲，讓前端同窗用機器學習技術去解決前端領域的問題，會不會難度很大。爲了下降前端工程師使用機器學習的門檻，咱們開發了前端算法工程框架 Pipcook。前端工程師能夠用熟悉的 JavaScript 來完成機器學習任務。

咱們能夠這樣理解 Pipcook， Node.js 的出現可讓前端工程師成爲一位服務端工程師，作服務端同窗能作的事情， Pipcook 的出現可讓前端工程師成爲一位機器學習工程師，能夠作機器學習工程師作的事情。

關於 Pipcook 是如何用 Node.js 橋接機器學習生態以及目前 Pipcook 的應用狀況請關注後續的設計稿生成代碼 imgcook 3.0 系列算法工程篇以前端算法工程 Pipcook。

(前端與機器學習)

研發鏈路升級

模塊研發鏈路

淘系營銷以模塊開發爲主，模塊開發的完整鏈路是從模塊管理平臺建立模塊 ⇥ 進入 imgcook 平臺智能生成代碼&可視化研發 ⇥ 開發完成後進入 IDE 調試預覽 ⇥ 測試完成後進入工程平臺發佈。整個研發流程須要切換多個平臺，開發鏈路體驗和工程效率都有待提高。

建立模塊後進入 imgcook 平臺智能生成代碼&可視化研發，若是可以直接在 imgcook 平臺開發、調試、預覽和發佈，一站式的 D2C 研發模式是提高總體研發效率和研發體驗的一個不錯的選擇。

因此咱們自定義了具備可視化模式和源碼模式的營銷版本 imgcook 可視化編輯器，在可視化模式智能生成代碼和可視化研發，並將生成的代碼一鍵同步到源碼模式的 WebIDE，在 WebIDE 中支持界面化的調試、預覽、發佈。

(淘系模塊 imgcook 可視化研發動線)

咱們經過計算使用傳統研發模式開發的模塊與使用 imgcook 可視化研發模式開發的模塊的效率值（複雜度與研發耗時比值）看到，使用 imgcook 可視化研發鏈路開發的模塊編碼效率提高 68%。

智能 UI 研發鏈路

智能 UI 是一種經過分析用戶特徵爲用戶提供個性化 UI 的方案，所以須要開發大量的 UI 界面，在淘系智能 UI 平臺鯨冪中開發智能 UI 的原始鏈路是在上傳視覺稿解析物料以後會批量建立 imgcook 模塊，但每種物料都須要進入對應的 imgcook 可視化界面單獨開發、建立倉庫、單獨發佈，而且看不到智能 UI 總體的視覺效果。這樣致使智能 UI 所須要的大量物料的開發成本很大，業務接入智能 UI 的成本比較大。

(智能 UI imgcook 可視化研發動線)

此次升級了智能 UI 的研發鏈路， D2C 可視化研發鏈路承接了智能 UI 的批量化生產。在上傳設計稿解析出 UI 物料以後，建立 imgcook 模塊，批量生成物料 UI 代碼，同時建立代碼倉庫與 imgcook 模塊關聯，並支持將已建立的物料批量導入 imgcook，批量生成 UI 方案（不一樣類型的 UI），在生成的 UI 方案中集中式對物料進行開發，最後還將支持物料的批量發佈，整個鏈路集中高效了不少。

落地結果

今年前端智能化助力前端研發模式升級，數個 BU 共建前端設計稿識別算法模型和數據集，並於雙 11 會場大規模應用落地。

設計稿生成代碼技術體系全面升級（如對 UI 多態、直播視頻組件、循環的智能識別加強等）帶來了營銷模塊研發鏈路產品化升級：雙十一會場有 90.4% （高於去年）新模塊的代碼智能生成。升級設計稿智能檢查能力，在可統計範圍內，無人工輔助的狀況下智能生成的代碼被保留髮布上線的佔比 79.26%。

相比傳統模塊開發模式，使用設計稿生成代碼技術後編碼效率（模塊複雜度和研發耗時比值）提高68%，固定人力單位時間模塊需求吞吐量增長約 1.5 倍。

目前還須要人工改動代碼的主要緣由有：循環未被識別、條件展現邏輯代碼未自動生成、字段綁定猜想錯誤（字段標準化狀況不佳）、業務特性必須的圖片合併問題等，這些問題也都是接下來須要逐步完善的。 （D2C 代碼生成用戶更改狀況）

同時，imgcook 支撐了天貓淘寶的主會場和行業會場智能 UI 的批量化生產，極大的提高了智能 UI 的生產效率。 （智能 UI 批量化生產結果）

將來展望

智能化方式不管是使用計算機視覺仍是深度學習技術，都會有準確率的問題，準確率低在線上環境可能沒法被接受。須要創建一套與線上用戶使用數據造成閉環的算法工程鏈路，實現樣本自動化收集、算法工程鏈路的閉環才能讓模型線上識別準確率不斷提高。目前在 imgcook 的系統中，Icon 識別從樣本收集到模型識別結果的最終應用已經造成了完整的鏈路閉環，開發同窗不須要花太多精力用於模型的優化。對於其餘的模型，後續也會用一樣的思路讓模型具備自我迭代的能力。

另外一個 D2C 智能化的難點是模型識別的結果最終如何用於生成代碼，例如組件識別模型能識別組件的類別，但最終生成代碼使用哪一個組件庫的組件、如何識別 UI 中的組件屬性值這些問題，imgcook 的平臺能力與智能還原技術分層架構具有解決這些問題的能力，將來會有更多的智能化方案用於生產環境。

後續咱們會繼續根據對 imgcook 的 D2C 智能化能力拆解，探索更多智能化解決方案，優化現有模型能力，創建算法工程閉環機制實現每個模型的自我迭代，不斷提升模型的泛化能力和線上識別準確度，輔助生成可維護性更高語義更強的前端代碼。

歡迎加入釘釘羣與咱們一塊兒交流，社區同窗 請釘釘掃碼加入 社區羣，阿里內部同窗 請加入 內部羣。

系列文章預告

設計稿智能生成代碼 掘金帳號

• 設計稿生成代碼 Imgcook 3.0 系列-開篇
• 設計稿生成代碼 Imgcook 3.0 系列-設計稿規範智能檢查篇
• 設計稿生成代碼 Imgcook 3.0 系列-組件識別篇
• 設計稿生成代碼 Imgcook 3.0 系列-Icon識別篇
• 設計稿生成代碼 Imgcook 3.0 系列-佈局還原篇
• 設計稿生成代碼 Imgcook 3.0 系列-字段語義分析篇
• 設計稿生成代碼 Imgcook 3.0 系列-業務邏輯生成篇
• 設計稿生成代碼 Imgcook 3.0 系列-算法工程篇（前端智能化與 Pipcook）
• 設計稿生成代碼 Imgcook 3.0 系列-算法工程篇（樣本製造機 Samplecook）
• 設計稿生成代碼 Imgcook 3.0 系列-雙11落地篇
• 設計稿生成代碼 Imgcook 3.0 系列-雙11落地篇之智能UI