導讀：作為今年阿里經濟體前端委員會的四大技術方向之一，前端智能化方向一被提及，就不免有人好奇：前端結合 AI 能做些什麼，怎麼做，未來會不會對前端產生很大的衝擊等等。本篇文章將圍繞這些問題，以「設計稿自動生成代碼」場景為例，從背景分析、競品分析、問題拆解、技術方案等幾個角度切入，細述相關思考及過程實踐。
背景分析
業界機器學習之勢如火如荼，「AI 是未來的共識」頻頻出現在各大媒體上。李開復老師也在《AI·未來》指出，將近 50％ 的人類工作將在 15 年內被人工智能所取代，尤其是簡單的、重複性的工作。並且，白領比藍領的工作更容易被取代；因為藍領的工作可能還需要機器人和軟硬件相關技術都突破才能被取代，而白領工作一般只需要軟件技術突破就可以被取代。那我們前端這個“白領”工作會不會被取代，什麼時候能被取代多少？
回看 2010 年，軟件幾乎吞噬了所有行業，帶來近幾年軟件行業的繁榮；而到了 2019 年，軟件開發行業本身卻又在被 AI 所吞噬。你看：DBA 領域出現了 Question-to-SQL，針對某個領域只要問問題就可以生成 SQL 語句；基於機器學習的源碼分析工具 TabNine 可以輔助代碼生成；設計師行業也出了 P5 Banner 智能設計師“鹿班”，測試領域的智能化結合也精彩紛呈。那前端領域呢？
那就不得不提一個我們再熟悉不過的場景了，它就是設計稿自動生成代碼（Design2Code，以下簡稱 D2C），阿里經濟體前端委員會-前端智能化方向當前階段就是聚焦在如何讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工作，讓前端工程師專注更有挑戰性的工作內容！
競品分析
2017 年，一篇關於圖像轉代碼的 Pix2Code 論文掀起了業內激烈討論的波瀾，講述如何從設計原型直接生成源代碼。隨後社區也不斷湧現出基於此思想的類似 Screenshot2Code 的作品，2018 年微軟 AI Lab 開源了草圖轉代碼 工具 Sketch2Code，同年年底，設計稿智能生成前端代碼的新秀 Yotako 也初露鋒芒， 機器學習首次以不可小覷的姿態正式進入了前端開發者的視野。
基於上述競品分析，我們能夠得到以下幾點啟發：
1、深度學習目前在圖片方面的目標檢測能力適合較大顆粒度的可複用的物料識別（模塊識別、基礎組件識別、業務組件識別）。
2、完整的直接由圖片生成代碼的端到端模型複雜度高，生成的代碼可用度不高，要達到所生成代碼工業級可用，需要更細的分層拆解和多級子網絡模型協同，短期可通過設計稿生成代碼來做 D2C 體系建設。
3、當模型的識別能力無法達到預期準確度時，可以藉助設計稿人工的打底規則協議；一方面人工規則協議可以幫助用戶強幹預得到想要的結果，另一方面這些人工規則協議其實也是高質量的樣本標註，可以當成訓練樣本優化模型識別準確度。
問題分解
設計稿生成代碼的目標是讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工作內容。那我們先來分析下，“常規”前端尤其是面向 C 端業務的同學，一般的工作流程日常工作內容大致如下：
“常規”前端一般的開發工作量，主要集中在視圖代碼、邏輯代碼和數據聯調（甚至是數據接口開發，研發 Serveless 產品化時可期）這幾大塊，接下來，我們逐塊拆解分析。
視圖代碼
視圖代碼研發，一般是根據視覺稿編寫 HTML 和 CSS 代碼。如何提效，當面對 UI 視圖開發重複性的工作時，自然想到組件化、模塊化等封裝複用物料的解決方案，基於此解決方案會有各種 UI 庫的沉澱，甚至是可視化拼裝搭建的更 High Level 的產品化封裝，但複用的物料不能解決所有場景問題。個性化業務、個性化視圖遍地開花，直面問題本身，直接生成可用的 HTML 和 CSS 代碼是否可行？
這是業界一直在不斷嘗試的命題，通過設計工具的開發插件可以導出圖層的基本信息，但這裡的主要難點還是對設計稿的要求高、生成代碼可維護性差，這是核心問題，我們來繼續拆解。
▐ 設計稿要求高問題
對設計稿的要求高，會導致設計師的成本加大，相當於前端的工作量轉嫁給了設計師，導致推廣難度會非常大。一種可行的辦法是採用 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 老生常談的話題，也是我們的核心技術痛點。我們嘗試從這幾個角度來分析引起這個問題的因素：
1、識別問題定義不準確：問題定義不準確是影響模型識別不準的首要因素，很多人認為樣本和模型是主要因素，但在這之前，可能一開始的對問題的定義就出現了問題，我們需要判斷我們的識別訴求模型是否合適做，如果合適那該怎麼定義清楚這裡面的規則等。
2、高質量的數據集樣本缺乏：我們在識別層的各個機器智能識別能力需要依賴不同的樣本，那我們的樣本能覆蓋多少前端開發場景，各個場景的樣本數據質量怎麼樣，數據標準是否統一，特徵工程處理是否統一，樣本是否存在二義性，互通性如何，這是我們當下所面臨的問題。
3、模型召回低、存在誤判：我們往往會在樣本里堆積許多不同場景下不同種類的樣本作為訓練，期望通過一個模型來解決所有的識別問題，但這卻往往會讓模型的部分分類召回率低，對於一些有二義性的分類也會存在誤判。
▐ 問題定義
深度學習裡的計算機視覺類模型目前比較適合解決的是分類問題和目標檢測問題，我們判斷一個識別問題是否該使用深度模型的前提是——我們自己是否能夠判斷和理解，這類問題是否有二義性等，如果人也無法準確地判斷，那麼這個識別問題可能就不太合適。
假如判斷適合用深度學習的分類來做，那就需要繼續定義清楚所有的分類，這些分類之間需要嚴謹、有排他性、可完整枚舉。比如在做圖片的語義化這個命題的時候，一般圖片的 ClassName 通用常規命名有哪些，舉個例子，其分析過程如下：
- 第一步：儘可能多地找出相關的設計稿，一個個枚舉裡面的圖片類型。
- 第二步：對圖片類型進行合理歸納歸類，這是最容易有爭論的地方，定義不好有二義性會導致最有模型準確度問題。
- 第三步：分析每類圖片的特徵，這些特徵是否典型，是否是最核心的特徵點，因為關係到後續模型的推理泛化能力。
- 第四步：每類圖片的數據樣本來源是否有，沒有的話能否自動造；如果數據樣本無法有，那就不適合用模型，可以改用算法規則等方式替代先看效果。
D2C 項目中很多這樣的問題，問題本身的定義需要非常精準，並且需要有科學的參考依據，這一點本身就比較難，因為沒有可借鑑的先例，只能先用已知的經驗先試用，用戶測試有問題後再修正，這是一個需要持續迭代持續完善的痛點。
▐ 樣本質量
針對 樣本 問題，我們需要對這部分數據集建立標準規範，分場景構建多維度的數據集，將收集的數據做統一的處理和提供，並以此期望能建立一套規範的數據體系。
在這套體系中，我們使用統一的樣本數據存儲格式，提供統一的針對不同問題（分類、目標檢測）的樣本評估工具來評估各項數據集的質量，針對部分特定模型可採取效果較好的特徵工程（歸一化、邊緣放大等）來處理，同類問題的樣本也期望能在後續不同的模型裡能夠流通作比較，來評估不同模型的準確度和效率。
數據樣本工程體系
▐ 模型
針對模型的召回和誤判問題，我們嘗試 收斂場景來提高準確度。往往不同場景下的樣本會存在一些特徵上的相似點或者影響部分分類局部關鍵特徵點，導致產生誤判、召回低，我們期望能夠通過收斂場景來做模式化的識別，提高模型準確度。我們把場景收斂到如下三個場景：無線 C 端營銷頻道場景、小程序場景以及 PC 中後臺場景。這裡面幾個場景的設計模式都有自己的特色，針對各個場景來設計垂直的識別模型可以高效地提高單一場景的識別準確度。
D2C 場景
過程思考
既然使用了深度模型，有一個比較現實的問題是，模型的泛化能力不夠，識別的準確率必然不能 100% 讓用戶滿意，除了能夠在後續不斷地補充這批識別不到的樣本數據外，在這之前我們能做什麼？
在 D2C 的整個還原鏈路裡，對於識別模型，我們還遵守一個方法論，即設計一套協議或者規則能通過其他方式來兜底深度模型的識別效果，保障在模型識別不準確的情況下用戶仍可完成訴求：手動約定 > 規則策略 > 機器學習 > 深度模型。舉個例子比如需要識別設計稿裡的一個循環體：
- 初期，我們可以在設計稿裡手動約定循環體的協議來達成
- 根據圖層的上下文信息可做一些規則的判斷，來判斷是否是循環體
- 利用機器學習的圖層特徵，可嘗試做規則策略的更上游的策略優化
- 生成循環體的一些正負樣本來通過深度模型進行學習
其中手動約定的設計稿協議解析優先級最高，這樣也能確保後續的流程不受阻塞和錯誤識別的干擾。
業務落地
2019 雙十一落地
在今年的雙十一場景中，我們的 D2C 覆蓋了天貓淘寶會場的新增模塊，包括主會場、行業會場、營銷玩法會場、榜單會場等，包含了視圖代碼和部分邏輯代碼的自動生成，在可統計範圍內，D2C 代碼生成佔據了大比例。目前代碼的人工改動的主要原因有：全新業務邏輯、動畫、字段綁定猜測錯誤（字段標準化情況不佳）、循環猜測錯誤、樣式自適應修改等，這些問題也都是接下來需要逐步完善的。
D2C 代碼生成用戶更改情況
整體落地情況
我們對外的產品 imgcook，截止 2019.11.09 日，相關的使用數據情況如下：
- 模塊數 12681 個， 周新增 540 個左右；
- 用戶數 4315 個，周新增 150 個左右；
- 自定義DSL：總數 109 個；
目前可提供的服務能力如下：
- 設計稿全鏈路還原：通過 Sketch、PhotoShop 插件一鍵導出設計稿圖層，生成自定義的 DSL 代碼。
- 圖像鏈路還原：支持用戶自定義上傳圖片、文件或填寫圖片鏈接，直接還原生成自定義的 DSL 代碼。
後續規劃
- 繼續降低設計稿要求，爭取設計稿 0 協議，其中分組、循環的智能識別準確度提升，減少視覺稿協議的人工干預成本。
- 組件識別準確度提升，目前只有 72% 的準確度，業務應用可用率低。
- 頁面級和項目級還原能力可用率提升，依賴頁面分割能力的準確度提升。
- 小程序、中後臺等領域的頁面級還原能力提升，含複雜表單、表格、圖表的整體還原能力。
- 靜態圖片生成代碼鏈路可用度提升，真正可用於生產環境。
- 算法工程產品完善，樣本生成渠道更多元，樣本集更豐富。
- D2C 能力開源。
未來我們希望能通過前端智能化 D2C 項目，讓前端智能化技術方案普惠化，沉澱更具競爭力的樣本和模型，提供準確度更高、可用度更高的代碼智能生成服務；切實提高前端研發效率，減少簡單的重複性工作，不加班少加班，一起專注更有挑戰性的工作內容！
閱讀更多 阿里云云棲號 的文章
