一場腦洞實驗

雲棲大會雲上 Hello World 活動火熱進行中！每位參與者都可收穫一份阿里雲出品的全球唯一序列號紀念證書！

作為阿里經濟體前端委員會的四大技術方向之一，前端智慧化方向一被提及，就不免有人好奇：前端結合機器學習能做些什麼，怎麼做，未來會不會對前端產生很大的衝擊等等。本文以「設計稿自動生成程式碼」場景為例，細述我們的思考及過程實踐。

前端智慧化與雲 IDE 的結合，通過後者打通的各種服務與介面，再加上設計稿生成程式碼的能力，可以進一步地提升前端開發者的開發體驗，由原來的設計稿生成程式碼，轉變為生成可隨時可部署的應用/頁面，因此本文最後會介紹如何在 阿里云云開發平臺使用 imgcook 外掛，一鍵完成設計稿稿生成應用，開啟您的智慧開發之旅。

前端智慧化背景

業界機器學習之勢如火如荼，「AI 是未來的共識」頻頻出現在各大媒體上。李開復老師也在《AI · 未來》指出，將近 50％ 的人類工作將在 15 年內被人工智慧所取代，尤其是簡單的、重複性的工作。並且，白領比藍領的工作更容易被取代；因為藍領的工作可能還需要機器人和軟硬體相關技術都突破才能被取代，而白領工作一般只需要軟體技術突破就可以被取代，那我們前端這個“白領”工作會不會被取代，什麼時候能被取代多少？

回看 2010 年，軟體幾乎吞噬了所有行業，帶來近幾年軟體行業的繁榮；而到了 2019 年，軟體開發行業本身卻又在被 AI 所吞噬。你看：DBA 領域出現了 Question-to-SQL，針對某個領域只要問問題就可以生成 SQL 語句；基於機器學習的原始碼分析工具 TabNine 可以輔助程式碼生成；設計師行業也出了 P5 Banner 智慧設計師“鹿班”，測試領域的智慧化結合也精彩紛呈。那前端領域呢？

那就不得不提一個我們再熟悉不過的場景了，它就是 設計稿自動生成程式碼（Design2Code，以下簡稱 D2C），阿里經濟體前端委員會 - 前端智慧化方向當前階段，就是聚焦在如何 讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工作，讓前端工程師專注更有挑戰性的工作內容！

imgcook 是什麼？

imgcook 使用 Sketch、PSD、靜態圖片等形式作為輸入，通過智慧化技術一鍵生成可維護的前端程式碼，包含檢視程式碼、資料欄位繫結、元件程式碼、部分業務邏輯程式碼等。

它期望能夠利用智慧化手段，讓自己成為一位前端工程師，在對設計稿輕約束的前提下實現高度還原，釋放前端生產力，助力前端與設計師高效協作，讓工程師們專注於更具挑戰性的工作！

設計稿生成程式碼的目標是讓 AI 助力前端這個職能角色提效升級，杜絕簡單重複性工作內容。那我們先來分析下，“常規”前端尤其是面向 C 端業務的同學，一般的工作流程日常工作內容大致如下：

“常規”前端一般的開發工作量，主要集中在 檢視程式碼、 邏輯程式碼和 資料聯調這幾大塊，接下來，我們逐塊拆解分析。

1. 問題定義

檢視程式碼研發，一般是根據視覺稿編寫 HTML 和 CSS 程式碼。如何提效？當面對 UI 檢視開發重複性的工作時，自然想到元件化、模組化等封裝複用物料的解決方案，基於此解決方案會有各種 UI 庫的沉澱，甚至是視覺化拼裝搭建的更高階的產品化封裝，但複用的物料不能解決所有場景問題。個性化業務、個性化檢視遍地開花，直面問題本身，直接生成可用的 HTML 和 CSS 程式碼是否可行？

這是業界一直在不斷嘗試的命題，通過設計工具的開發外掛可以匯出圖層的基本資訊，但這裡的主要難點還是對設計稿的要求高、生成程式碼可維護性差，這是核心問題，我們來繼續拆解。

1）設計稿要求高

對設計稿的要求高，會導致設計師的成本加大，相當於前端的工作量轉嫁給了設計師，導致推廣難度會非常大。

一種可行的辦法是採用 CV（ComputerVision, 計算機視覺） 結合匯出圖層資訊的方式，以去除設計稿的約束，當然對設計稿的要求最好是直接匯出一張圖片，那樣對設計師沒有任何要求，也是我們夢寐以求的方案，我們也一直在嘗試從靜態圖片中分離出各個適合的圖層，但目前在生產環境可用度不夠（小目標識別精準度問題、複雜背景提取問題仍待解決），畢竟設計稿自帶的元資訊，比一張圖片提取處理的元資訊要更多更精準。

2）程式碼可維護性

生成的程式碼結構一般都會面臨可維護性方面的挑戰：

• 合理佈局巢狀：包括絕對定位轉相對定位、冗餘節點刪除、合理分組、迴圈判斷等方面；
• 元素自適應：元素本身擴充套件性、元素間對齊關係、元素最大寬高容錯性；
• 語義化：類名的多級語義化；
• 樣式 CSS 表達：背景色、圓角、線條等能用 CV 等方式分析提取樣式，儘可能用 CSS 表達樣式代替使用圖片。

將這些問題拆解後，分門別類專項解決，解決起來看似沒完沒了，但好在目前發現的大類問題基本解決。

很多人質疑道：這部分能力的實現看起來和智慧化一點關係都沒有，頂多算個佈局演算法相關的專家規則系統。沒錯，現階段這部分比較適合規則系統，對使用者而言佈局演算法需要接近 100% 的可用度，另外這裡涉及的大部分是無數屬性值組合問題，當前用規則更可控。如果非要使用模型，那這個可被定義為多分類問題。同時，任何深度學習模型的應用都是需要先有清晰的問題定義過程，把問題規則定義清楚本就是必備過程。

但在規則解決起來麻煩的情況下，可以使用模型來輔助解決。比如 合理分組（如下圖） 和 迴圈項 的判斷，實踐中我們發現，在各種情況下還是誤判不斷，演算法規則難以列舉，這裡需要跨元素間的上下文語義識別，這也是接下來正在用模型解決的重點問題。

2. 技術方案

基於上述的概述和問題分解後，我們對現有的 D2C 智慧化技術體系做了能力概述分層，主要分為以下三部分：

• 識別能力：即對設計稿的識別能力，智慧從設計稿分析出包含的圖層、基礎元件、業務元件、佈局、語義化、資料欄位、業務邏輯等多維度的資訊；如果智慧識別不準，就視覺化人工干預補充糾正，一方面是為了視覺化低成本干預生成高可用程式碼，另一方面這些干預後的資料就是標註樣本，反哺提升智慧識別的準確率；

• 表達能力：主要做資料輸出以及對工程部分接入：a）通過 DSL 適配將標準的結構化描述做 Schema2Code；b）通過 IDE 外掛能力做工程接入；

• 演算法工程：為了更好的支撐 D2C 需要的智慧化能力，將高頻能力服務化，主要包含資料生成處理、模型服務部分：

  • 樣本生成：主要處理各渠道來源樣本資料並生成樣本；
  • 模型服務：主要提供模型 API 封裝服務以及資料迴流。

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

在整個方案裡，我們用同一套資料協議規範（D2C Schema）來連線各層的能力，確保其中的識別能夠對映到具體對應的欄位上，在表達階段也能正確地通過出碼引擎等方案生成程式碼。

1）智慧識別技術分層

在整個 D2C 專案中，最核心的是上述識別能力部分的 機器智慧識別部分，這層的具體再分解如下：

• 物料識別層：主要通過影像識別能力識別影像中的物料（模組識別、原子模組識別、基礎元件識別、業務元件識別）；

• 圖層處理層：主要將設計稿或者影像中圖層進行分離處理，並結合上一層的識別結果，整理好圖層元資訊；

• 圖層再加工層：對圖層處理層的圖層資料做進一步的規範化處理；

• 佈局演算法層：轉換二維中的絕對定點陣圖層佈局為相對定位和 Flex 佈局；

• 語義化層：通過圖層的多維特徵對圖層在生成程式碼端做語義化表達；

• 欄位繫結層：對圖層裡的靜態資料結合資料介面做介面動態資料欄位繫結對映；

• 業務邏輯層：對已配置的業務邏輯通過業務邏輯識別和表達器來生成業務邏輯程式碼協議；

• 出碼引擎層：最後輸出經過各層智慧化處理好的程式碼協議，經過表達能力（協議轉程式碼的引擎）輸出各種 DSL 程式碼。

（D2C 識別能力技術分層）

2）技術痛點

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

• 識別問題定義不準確：問題定義不準確是影響模型識別不準的首要因素，很多人認為樣本和模型是主要因素，但在這之前，可能一開始對問題的定義就出現了問題，我們需要判斷我們的識別訴求模型是否合適做，如果合適那該怎麼定義清楚這裡面的規則等；

• 高質量的資料集樣本缺乏：我們在識別層的各個機器智慧識別能力需要依賴不同的樣本，那我們的樣本能覆蓋多少前端開發場景，各個場景的樣本資料質量怎麼樣，資料標準是否統一，特徵工程處理是否統一，樣本是否存在二義性，互通性如何，這是我們當下所面臨的問題；

• 模型召回低、存在誤判：我們往往會在樣本里堆積許多不同場景下不同種類的樣本作為訓練，期望通過一個模型來解決所有的識別問題，但這卻往往會讓模型的部分分類召回率低，對於一些有二義性的分類也會存在誤判。

【問題定義】

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

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

• 第一步：儘可能多地找出相關的設計稿，一個個列舉裡面的圖片型別；

• 第二步：對圖片型別進行合理歸納歸類，這是最容易有爭論的地方，定義不好有二義性會導致最有模型準確度問題；

• 第三步：分析每類圖片的特徵，這些特徵是否典型，是否是最核心的特徵點，因為關係到後續模型的推理泛化能力；

• 第四步：每類圖片的資料樣本來源是否有，沒有的話能否自動造；如果資料樣本無法有，那就不適合用模型，可以改用演算法規則等方式替代先看效果。

D2C 專案中很多這樣的問題，問題本身的定義需要非常精準，並且需要有科學的參考依據，這一點本身就比較難，因為沒有可借鑑的先例，只能先用已知的經驗先試用，使用者測試有問題後再修正，這是一個需要持續迭代持續完善的痛點。

【樣本質量】

針對 樣本問題，我們需要對這部分資料集建立標準規範，分場景構建多維度的資料集，將收集的資料做統一的處理和提供，並以此期望能建立一套規範的資料體系。

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

（資料樣本工程體系）

【模型】

針對模型的召回和誤判問題，我們嘗試 收斂場景來提高準確度。往往不同場景下的樣本會存在一些特徵上的相似點或者影響部分分類區域性關鍵特徵點，導致產生誤判、召回低，我們期望能夠通過收斂場景來做模式化的識別，提高模型準確度。

我們把場景收斂到如下三個場景：無線 C 端營銷頻道場景、小程式場景以及 PC 中後臺場景。這裡面幾個場景的設計模式都有自己的特色，針對各個場景來設計垂直的識別模型可以高效地提高單一場景的識別準確度。

（D2C 場景）

3）思考與解法

總的來說，既然使用了深度模型，有一個比較現實的問題是，模型的泛化能力不夠，識別的準確率必然不能 100% 讓使用者滿意，除了能夠在後續不斷地補充這批識別不到的樣本資料外，在這之前我們能做什麼？

在 D2C 的整個還原鏈路裡，對於識別模型，我們還遵守一個方法論，即設計一套協議或者規則能通過其他方式來兜底深度模型的識別效果，保障在模型識別不準確的情況下使用者仍可完成訴求： 手動約定 > 規則策略 > 機器學習 > 深度模型。舉個例子比如需要識別設計稿裡的一個迴圈體：

• 初期，我們可以在設計稿裡手動約定迴圈體的協議來達成；
• 根據圖層的上下文資訊可做一些規則的判斷，來判斷是否是迴圈體；
• 利用機器學習的圖層特徵，可嘗試做規則策略的更上游的策略優化；
• 生成迴圈體的一些正負樣本來通過深度模型進行學習。

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

imgcook x 雲開發平臺

瞭解前端智慧化和 imgcook 大致思路之後，那麼為什麼會選擇在雲開發平臺上整合 imgcook 呢？那就是 imgcook 和雲開發平臺通過彼此的打通，將能夠為雙方解決彼此的痛點，無論是為雲上開發者，還是 imgcook 開發者都提供了全新的使用者體驗。

對於 imgcook 開發者來說，其中一個痛點就來自於對於設計稿的管理，以及前後端互動的邏輯，然而通過雲開發平臺，開發者不再需要在本地安裝 Sketch，通過雲開發平臺直接上傳設計稿即可開始生成程式碼，真正做到了0成本一鍵生成。

另外雲開發平臺上直接提供了 Midway Serverless 框架，我們通過雲開發平臺的外掛定製化，可以讓開發者直接選擇某個頁面所使用的函式（Function），這樣就節省掉編寫一些前後端互動的基礎邏輯或請求程式碼。

對於雲開發平臺的開發者來說，最想得到的便是極速的上線體驗和更加便捷的開發體驗，imgcook 可以降低雲開發平臺的使用門檻，比如一位 FaaS 應用工程師不再需要學習如何切圖，如何寫 CSS，而只需要編寫 FaaS 函式的邏輯即可，剩下的前端邏輯程式碼都可以通過 imgcook 外掛在開發平臺內即可完成，這是多麼棒的體驗啊！

那麼，接下來就看看如何快速地從0到1生成程式碼吧。

首先需要先開啟 雲開發平臺建立應用，選擇 imgcook 建立應用：

然後在應用的 WebIDE 中通過右鍵開啟 imgcook 雲外掛，就可以正式開始使用了。

第一步，在外掛中選擇“匯入”，開啟上傳設計稿介面：

第二步，imgcook 視覺化編輯器：

第三步，生成程式碼：

第四步，匯出程式碼到應用：

第五步，上線應用：

$ npm install
$ npm run dev
正在啟動，請稍後...
---------------------------------------
開發伺服器已成功啟動
請開啟 >>> http://*****-3000.xide.aliyun.com/
---------------------------------------
感謝使用 Midway Serverless，歡迎 Star!
https://github.com/midwayjs/midway
---------------------------------------

啟動成功後通過命令列的地址開啟頁面效果如下，是不是很簡單呢？

總結

本文通過介紹前端智慧化的背景，imgcook 的問題定義以及技術方案，以及如何在雲開發平臺上使用 imgcook 開始智慧開發，總的來說，還是希望讓業內的前端工程師們從使用 imgcook 開始，將日常工作中的一些繁瑣、耗時的工作交給 AI 來完成，這樣能關注工程師本身更感興趣，也更有價值的事情，也相信不久的將來，前端工程師將藉助於 AI 能更加快樂與從容地工作！

點選連結立即體驗： https://yunqi.aliyun.com/2020/hol

“ 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”