雙十一模塊 79.34% 的代碼是怎樣智能生成的

時間 2020-06-08

標籤雙十模塊 79.34% 代碼怎樣智能生成简体版

原文原文鏈接

做爲今年阿里經濟體前端委員會的四大技術方向之一，前端智能化方向一被說起，就難免有人好奇：前端結合 AI 能作些什麼，怎麼作，將來會不會對前端產生很大的衝擊等等。本篇文章將圍繞這些問題，以「設計稿自動生成代碼」場景爲例，從背景分析、競品分析、問題拆解、技術方案等幾個角度切入，細述相關思考及過程實踐。前端

文/妙淨/波本git

背景分析

業界機器學習之勢如火如荼，「AI 是將來的共識」頻頻出如今各大媒體上。李開復老師也在《AI·將來》指出，將近 50％的人類工做將在 15 年內被人工智能所取代，尤爲是簡單的、重複性的工做。而且，白領比藍領的工做更容易被取代；由於藍領的工做可能還須要機器人和軟硬件相關技術都突破才能被取代，而白領工做通常只須要軟件技術突破就能夠被取代。那咱們前端這個「白領」工做會不會被取代，何時能被取代多少？github

回看 2010 年，軟件幾乎吞噬了全部行業，帶來近幾年軟件行業的繁榮；而到了 2019 年，軟件開發行業自己卻又在被 AI 所吞噬。你看：DBA 領域出現了 Question-to-SQL，針對某個領域只要問問題就能夠生成 SQL 語句；基於機器學習的源碼分析工具 TabNine 能夠輔助代碼生成；設計師行業也出了 P5 Banner 智能設計師「鹿班」，測試領域的智能化結合也精彩紛呈。那前端領域呢？
那就不得不提一個咱們再熟悉不過的場景了，它就是設計稿自動生成代碼（Design2Code，如下簡稱 D2C），阿里經濟體前端委員會-前端智能化方向當前階段就是聚焦在如何讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工做，讓前端工程師專一更有挑戰性的工做內容！算法

競品分析

2017 年，一篇關於圖像轉代碼的 Pix2Code 論文掀起了業內激烈討論的波瀾，講述如何從設計原型直接生成源代碼。隨後社區也不斷涌現出基於此思想的相似 Screenshot2Code 的做品，2018 年微軟 AI Lab 開源了草圖轉代碼工具 Sketch2Code，同年年末，設計稿智能生成前端代碼的新秀 Yotako 也初露鋒芒，機器學習首次以不可小覷的姿態正式進入了前端開發者的視野。小程序

	識別目標	控件數	結果現狀	本質能力
Pix2Code	Bootstrap 基礎控件	11	實驗數據準確率接近 80%, 支持控件少	中後臺基礎組件識別
Screenshot2Code	HTML 基礎標籤	HTML 基礎標籤	準確率較低	端到端的圖片生成代碼
Sketch2Code	手繪稿到控件	9	手繪草圖下降了使用門檻	基於手繪稿的組件識別
shots	非智能識別，全人工標註	未知	有 Showcase，新設計稿沒法試用，閉源，準確度未知，人工收集了6000 個設計稿 Case	設計稿生成代碼的佈局算法能力，含各類場景下豐富的高質量的控件類型標註
Yotako	HTML 基礎標籤	未知	PSD 生成前端代碼，有Showcase，使用須要會員費，設計稿的要求很是高（幾乎每一個圖層都有命名要求），剛起步	設計稿生成代碼，目前規則的比重較大

基於上述競品分析，咱們可以獲得如下幾點啓發：設計模式

深度學習目前在圖片方面的目標檢測能力適合較大顆粒度的可複用的物料識別（模塊識別、基礎組件識別、業務組件識別）。
完整的直接由圖片生成代碼的端到端模型複雜度高，生成的代碼可用度不高，要達到所生成代碼工業級可用，須要更細的分層拆解和多級子網絡模型協同，短時間可經過設計稿生成代碼來作 D2C 體系建設。
當模型的識別能力沒法達到預期準確度時，能夠藉助設計稿人工的打底規則協議；一方面人工規則協議能夠幫助用戶強幹預獲得想要的結果，另外一方面這些人工規則協議其實也是高質量的樣本標註，能夠當成訓練樣本優化模型識別準確度。

問題分解

設計稿生成代碼的目標是讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工做內容。那咱們先來分析下，「常規」前端尤爲是面向 C 端業務的同窗，通常的工做流程平常工做內容大體以下：網絡

「常規」前端通常的開發工做量，主要集中在視圖代碼、邏輯代碼和數據聯調（甚至是數據接口開發，研發 Serveless 產品化時可期）這幾大塊，接下來，咱們逐塊拆解分析。前端工程師

視圖代碼

視圖代碼研發，通常是根據視覺稿編寫 HTML 和 CSS 代碼。如何提效，當面對 UI 視圖開發重複性的工做時，天然想到組件化、模塊化等封裝複用物料的解決方案，基於此解決方案會有各類 UI 庫的沉澱，甚至是可視化拼裝搭建的更 High Level 的產品化封裝，但複用的物料不能解決全部場景問題。個性化業務、個性化視圖遍地開花，直面問題自己，直接生成可用的 HTML 和 CSS 代碼是否可行？less

這是業界一直在不斷嘗試的命題，經過設計工具的開發插件能夠導出圖層的基本信息，但這裏的主要難點仍是對設計稿的要求高、生成代碼可維護性差，這是核心問題，咱們來繼續拆解。機器學習

設計稿要求高問題

對設計稿的要求高，會致使設計師的成本加大，至關於前端的工做量轉嫁給了設計師，致使推廣難度會很是大。一種可行的辦法是採用 CV（ComputerVision, 計算機視覺）結合導出圖層信息的方式，以去除設計稿的約束，固然對設計稿的要求最好是直接導出一張圖片，那樣對設計師沒有任何要求，也是咱們求之不得的方案，咱們也一直在嘗試從靜態圖片中分離出各個適合的圖層，但目前在生產環境可用度不夠（小目標識別精準度問題、複雜背景提取問題仍待解決），畢竟設計稿自帶的元信息，比一張圖片提取處理的元信息要更多更精準。

可維護性問題

生成的代碼結構通常都會面臨可維護性方面的挑戰：

合理佈局嵌套：包括絕對定位轉相對定位、冗餘節點刪除、合理分組、循環判斷等方面；
元素自適應：元素自己擴展性、元素間對齊關係、元素最大寬高容錯性；
語義化：Classname 的多級語義化；
樣式 CSS 表達：背景色、圓角、線條等能用 CV 等方式分析提取樣式，儘量用 CSS 表達樣式代替使用圖片；
……

將這些問題拆解後，分門別類專項解決，解決起來看似沒完沒了，但好在目前發現的大類問題基本解決。不少人質疑道，這部分的能力的實現看起來和智能化一點關係都沒有，頂多算個佈局算法相關的專家規則系統。沒錯，現階段這部分比較適合規則系統，對用戶而言佈局算法須要接近 100% 的可用度，另外這裏涉及的大部分是無數屬性值組合問題，當前用規則更可控。若是非要使用模型，那這個可被定義爲多分類問題。同時，任何深度學習模型的應用都是須要先有清晰的問題定義過程，把問題規則定義清楚本就是必備過程。

但在規則解決起來麻煩的狀況下，可使用模型來輔助解決。好比 合理分組（以下圖）和 **循環項 **的判斷，實踐中咱們發現，在各類狀況下仍是誤判不斷，算法規則難以枚舉，這裏須要跨元素間的上下文語義識別，這也是接下來正在用模型解決的重點問題。

(合理分組示意)

邏輯代碼

邏輯代碼開發主要包括數據綁定、動效、業務邏輯代碼編寫。可提效的部分，通常在於複用的動效和業務邏輯代碼可沉澱基礎組件、業務組件等。

接口字段綁定：從可行性上分析仍是高的，根據視覺稿的文本或圖片判斷所屬哪一個候選字段，能夠作，但性價比不高，由於接口數據字段綁定太業務，通用性不強。
動效：這部分的開發輸入是交互稿，並且通常動效的交付形式各類各樣良莠不齊，有的是動畫 gif 演示，有的是文字描述，有的是口述；動效代碼的生成更適合用可視化的形式生成，直接智能生成沒有參考依據，考慮投入產出比不在短時間範圍內。
業務邏輯：這部分開發的依據來源主要是 PRD，甚至是 PD 口述的邏輯；想要智能生成這部分邏輯代碼，欠缺的輸入太多，具體得看看智能化在這個子領域能解決什麼問題。

邏輯代碼生成思考

理想方案固然是能像其餘詩歌、繪畫、音樂等藝術領域同樣，學習歷史數據，根據 PRD 文本輸入，新邏輯代碼能直接生成，但這樣生成的代碼能直接運行沒有任何報錯嗎？

目前人工智能雖然說發展迅速，但其能解決的問題仍是有限，須要將問題定義成其擅長解決的問題類型。強化學習擅長策略優化問題，深度學習目前在計算機視覺方面擅長解決的是分類問題、目標檢測問題，文本方面擅長 NLP（Natural Language Processing, 天然語言處理）等。

關於業務邏輯代碼，首先想到的是對歷史源代碼的函數塊利用 LSTM（Long Short-Term Memory, 長短時間記憶網絡）和 NLP 等進行上下文分析，能獲得代碼函數塊的語義，VS Code 智能代碼提醒和 TabNine 都是相似的思路。

另外，在分析問題中（以下圖）咱們還發現，智能化在業務邏輯領域還能夠協助識別邏輯點在視圖出現的位置（時機），並根據視圖猜想出的邏輯語義。

綜上，咱們總結一下智能化現階段的可助力點：

由歷史源代碼分析猜想高頻出現的函數塊（邏輯塊）的語義，實際獲得的就是組件庫或者基礎函數塊的語義，可在代碼編輯時作代碼塊推薦等能力。
由視覺稿猜想部分可複用的邏輯點，如這裏的字段綁定邏輯，可根據這裏文本語義 NLP 猜想所屬字段，部分圖片元素根據有限範圍內的圖片分類，猜想所屬對應的圖片字段（以下圖示例中的，氛圍修飾圖片仍是 Logo 圖片）；同時還能夠識別可複用的業務邏輯組件，好比這裏的領取優惠券邏輯。

因此，現階段在業務邏輯生成中，能夠解決的問題比較有限，尤爲是新的業務邏輯點以新的邏輯編排出現時，這些參考依據都在 PD 的 PRD 或腦海中。因此針對業務邏輯的生成方案，現階段的策略主要以下：

字段綁定：智能識別設計稿中的文本和圖片語義分類，特別是文字部分。
可複用的業務邏輯點：根據視圖智能識別，並由視圖驅動自由組裝，含小而美的邏輯點（一行表達式、或通常不足以封裝成組件的數行代碼）、基礎組件、業務組件。
沒法複用的新業務邏輯：PRD 需求結構化（可視化）收集，這是一個高難度任務，還在嘗試中。

小結

目前用智能化的方式自動生成 HTML + CSS + 部分 JS + 部分 DATA 的主要分析如上，是Design to Code 的主要過程，內部項目名稱叫作 D2C ，後續系列文章會使用此簡稱，集團內外的落地產品名稱爲 imgcook。隨着近幾年主流設計工具（Sketch、PS、XD 等）的三方插件開發能力逐漸成熟，飛速發展的深度學習那甚至超過人類識別效果的趨勢，這些都是 D2C 誕生和持續演進的強大後盾。

（目標檢測 2014-2019 年 paper）

技術方案

基於上述前端智能化發展歸納分析，咱們對現有的 D2C 智能化技術體系作了能力概述分層，主要分爲如下三部分：

識別能力：即對設計稿的識別能力。智能從設計稿分析出包含的圖層、基礎組件、業務組件、佈局、語義化、數據字段、業務邏輯等多維度的信息。若是智能識別不許，就可視化人工干預補充糾正，一方面是爲了可視化低成本干預生成高可用代碼，另外一方面這些干預後的數據就是標註樣本，反哺提高智能識別的準確率。
表達能力：主要作數據輸出以及對工程部分接入
- 經過 DSL 適配將標準的結構化描述作 Schema2Code
- 經過 IDE 插件能力作工程接入
算法工程：爲了更好的支撐 D2C 須要的智能化能力，將高頻能力服務化，主要包含數據生成處理、模型服務部分
- 樣本生成：主要處理各渠道來源樣本數據並生成樣本
- 模型服務：主要提供模型 API 封裝服務以及數據迴流

（前端智能化 D2C 能力概要分層）

在整個方案裏，咱們用同一套 **數據協議規範（D2C Schema）**來鏈接各層的能力，確保其中的識別可以映射到具體對應的字段上，在表達階段也能正確地經過出碼引擎等方案生成代碼。

智能識別技術分層

在整個 D2C 項目中，最核心的是上述識別能力部分的 機器智能識別 部分，這層的具體再分解以下，後續系列文章會圍繞這些細分的分層展開內部實現原理。

物料識別層：主要經過圖像識別能力識別圖像中的物料（模塊識別、原子模塊識別、基礎組件識別、業務組件識別）。
圖層處理層：主要將設計稿或者圖像中圖層進行分離處理，並結合上一層的識別結果，整理好圖層元信息。
圖層再加工層：對圖層處理層的圖層數據作進一步的規範化處理。
佈局算法層：轉換二維中的絕對定位圖層佈局爲相對定位和 Flex 佈局。
語義化層：經過圖層的多維特徵對圖層在生成代碼端作語義化表達。
字段綁定層：對圖層裏的靜態數據結合數據接口作接口動態數據字段綁定映射。
業務邏輯層：對已配置的業務邏輯經過業務邏輯識別和表達器來生成業務邏輯代碼協議。
出碼引擎層：最後輸出通過各層智能化處理好的代碼協議，通過表達能力（協議轉代碼的引擎）輸出各類 DSL 代碼。

（D2C 識別能力技術分層）

技術痛點

固然，這其中的 **識別不全面、識別準確度不高 **一直是 D2C 老生常談的話題，也是咱們的核心技術痛點。咱們嘗試從這幾個角度來分析引發這個問題的因素：

識別問題定義不許確：問題定義不許確是影響模型識別不許的首要因素，不少人認爲樣本和模型是主要因素，但在這以前，可能一開始的對問題的定義就出現了問題，咱們須要判斷咱們的識別訴求模型是否合適作，若是合適那該怎麼定義清楚這裏面的規則等。
高質量的數據集樣本缺少：咱們在識別層的各個機器智能識別能力須要依賴不一樣的樣本，那咱們的樣本能覆蓋多少前端開發場景，各個場景的樣本數據質量怎麼樣，數據標準是否統一，特徵工程處理是否統一，樣本是否存在二義性，互通性如何，這是咱們當下所面臨的問題。
**模型召回低、存在誤判：**咱們每每會在樣本里堆積許多不一樣場景下不一樣種類的樣本做爲訓練，指望經過一個模型來解決全部的識別問題，但這卻每每會讓模型的部分分類召回率低，對於一些有二義性的分類也會存在誤判。

問題定義

深度學習裏的計算機視覺類模型目前比較適合解決的是分類問題和目標檢測問題，咱們判斷一個識別問題是否該使用深度模型的前提是——咱們本身是否可以判斷和理解，這類問題是否有二義性等，若是人也沒法準確地判斷，那麼這個識別問題可能就不太合適。

假如判斷適合用深度學習的分類來作，那就須要繼續定義清楚全部的分類，這些分類之間須要嚴謹、有排他性、可完整枚舉。好比在作圖片的語義化這個命題的時候，通常圖片的 ClassName 通用常規命名有哪些，舉個例子，其分析過程以下：

第一步：儘量多地找出相關的設計稿，一個個枚舉裏面的圖片類型。
第二步：對圖片類型進行合理概括歸類，這是最容易有爭論的地方，定義很差有二義性會致使最有模型準確度問題。
第三步：分析每類圖片的特徵，這些特徵是否典型，是不是最核心的特徵點，由於關係到後續模型的推理泛化能力。
第四步：每類圖片的數據樣原本源是否有，沒有的話可否自動造；若是數據樣本沒法有，那就不適合用模型，能夠改用算法規則等方式替代先看效果。

D2C 項目中不少這樣的問題，問題自己的定義須要很是精準，而且須要有科學的參考依據，這一點自己就比較難，由於沒有可借鑑的先例，只能先用已知的經驗先試用，用戶測試有問題後再修正，這是一個須要持續迭代持續完善的痛點。

樣本質量

針對 **樣本 **問題，咱們須要對這部分數據集創建標準規範，分場景構建多維度的數據集，將收集的數據作統一的處理和提供，並以此指望能創建一套規範的數據體系。

在這套體系中，咱們使用統一的樣本數據存儲格式，提供統一的針對不一樣問題（分類、目標檢測）的樣本評估工具來評估各項數據集的質量，針對部分特定模型可採起效果較好的特徵工程（歸一化、邊緣放大等）來處理，同類問題的樣本也指望能在後續不一樣的模型裏可以流通做比較，來評估不一樣模型的準確度和效率。

（數據樣本工程體系）

模型

針對模型的召回和誤判問題，咱們嘗試 **收斂場景來提升準確度。**每每不一樣場景下的樣本會存在一些特徵上的類似點或者影響部分分類局部關鍵特徵點，致使產生誤判、召回低，咱們指望可以經過收斂場景來作模式化的識別，提升模型準確度。咱們把場景收斂到以下三個場景：無線 C 端營銷頻道場景、小程序場景以及 PC 中後臺場景。這裏面幾個場景的設計模式都有本身的特點，針對各個場景來設計垂直的識別模型能夠高效地提升單一場景的識別準確度。

（D2C 場景）

過程思考

既然使用了深度模型，有一個比較現實的問題是，模型的泛化能力不夠，識別的準確率必然不能 100% 讓用戶滿意，除了可以在後續不斷地補充這批識別不到的樣本數據外，在這以前咱們能作什麼？

在 D2C 的整個還原鏈路裏，對於識別模型，咱們還遵照一個方法論，即設計一套協議或者規則能經過其餘方式來兜底深度模型的識別效果，保障在模型識別不許確的狀況下用戶仍可完成訴求：手動約定 > 規則策略 > 機器學習 > 深度模型。舉個例子好比須要識別設計稿裏的一個循環體：

初期，咱們能夠在設計稿裏手動約定循環體的協議來達成
根據圖層的上下文信息可作一些規則的判斷，來判斷是不是循環體
利用機器學習的圖層特徵，可嘗試作規則策略的更上游的策略優化
生成循環體的一些正負樣原本經過深度模型進行學習

其中手動約定的設計稿協議解析優先級最高，這樣也能確保後續的流程不受阻塞和錯誤識別的干擾。

業務落地

2019 雙十一落地

在今年的雙十一場景中，咱們的 D2C 覆蓋了天貓淘寶會場的新增模塊，包括主會場、行業會場、營銷玩法會場、榜單會場等，包含了視圖代碼和部分邏輯代碼的自動生成，在可統計範圍內，D2C 代碼生成佔據了 79.34%。目前代碼的人工改動的主要緣由有：全新業務邏輯、動畫、字段綁定猜想錯誤（字段標準化狀況不佳）、循環猜想錯誤、樣式自適應修改等，這些問題也都是接下來須要逐步完善的。