智能生成前端代碼的信息輸入思考

文 / 波本

背景 & 趨勢

隨着近幾年人工智能的發展，AI 已經在各行各業初露頭角。在互聯網 Web 研發設計這塊，近幾年也能看到相似像 Rico（移動端應用程序標註數據集）這樣的公開數據集涌現出來，供業界研究人員能更好地在移動應用程序（App）這個場景下作一些學術研究，智能生成前端代碼就是其中一個不錯的方向。

除開一些用作學術研究的數據集外，也有一些互聯網產品直接嘗試作智能生成代碼的服務，旨在提供生成代碼服務的同時，經過蒐集服務生成代碼的質量評測，能更進一步的去不斷優化自身生成代碼的服務能力。

• imgcook：擅長設計稿生成代碼服務
• fronty：擅長圖像生成網站首頁
• Yotako：擅長 PSD 生成代碼服務

以上三款生成代碼的產品，輸入信息的渠道大都來源於設計師的結構化設計稿或者圖像，同時，這份輸入的解析也決定了最終輸出自動生成代碼的質量，那麼如何去衡量這裏面代碼生成的質量呢？咱們先來看看一般狀況下咱們的前端代碼構成是怎樣的。

代碼的結構化構成

一般咱們的前端代碼結構上可大體分爲這兩塊：靜態 GUI 代碼和動態邏輯代碼。

靜態 GUI 代碼

靜態 GUI 代碼通常由超文本標記語言（HTML）和層疊樣式表（CSS） 組成。代碼在視覺樣式上的描述可以對照設計階段中各圖層節點的填充樣式，但在層級結構上的描述一般是前端代碼獨有的，不在設計階段裏能體現。

動態邏輯代碼

前端的邏輯代碼（Javascript）一般是交互邏輯代碼，每每是賦予靜態 GUI 代碼一些動態的交互邏輯行爲，也是編程實現需求中最繁瑣的一部分，但此類交互邏輯行爲一般在設計階段不太能直接體現（靜態設計工具中）這裏面的意圖。

在當下 Serverless 的火熱趨勢下，前端即將面對的另外一塊編程代碼即服務端 FaaS（Function as a Server）研發，這裏麪包含了前端對需求中服務端數據的獲取以及處理過程，更貼近程序背後數據流的編碼處理。

上面這三部分的代碼佔據了咱們前端現在大部分編程內容，要實現這些代碼的智能化生成，咱們須要這兩方面的準備：

• 將這些代碼的描述結構化，經過數據描述進行轉換
• 從相關的素材中提取出關鍵的信息進行結構化的數據描述

本文重點講第二部分信息數據獲取的思考，下面咱們來看看獲取生成代碼的信息渠道來源都包含哪幾部分。

信息的輸入來源

在實際業務需求場景中，咱們在研發前能接觸到的信息包含以下幾塊：產品經理的需求稿、交互設計師的交互稿、視覺設計師的視覺稿以及定稿後的頁面圖像。
若是把咱們的網頁（程序）信息流通的過程對比到著名數學家克勞德·香農提出的信息論中（信息源-編碼器-信道-譯碼器）：

• 信息源對應需求稿即對網頁（程序）的策劃需求
• 編碼器對應交互稿即設計師對獲得的需求進行交互以及頁面總體設計形態的安排
• 信道對應設計稿即設計師在設計中使用圖像、色彩、文本、音響等做爲信息傳輸信道
• 譯碼器則對應這些信道最終展示在用戶面前去翻譯成自身理解的信息過程，好比理解圖像中某個具體的功能組件

從上能夠看出，用戶對一個應用程序的完整信息獲取及理解來源於信息在各個階段的流動，只看單一的渠道咱們勢必會丟失其餘部分重要的信息內容，這對於研發態信息的獲取也同樣，就比如你只看視覺稿不看需求稿去作研發，顯然交付的代碼所實現的需求每每是不合格的。

需求稿（PRD）

需求稿每每含括了前臺和服務端數據的需求功能點，也是用戶信息得到的最原始的起點。但基本上需求稿的內容是無法結構化描述的，也意味着咱們只能人爲主觀地消化理解這裏面的信息，若是咱們把產品經歷的需求稿交付作約束讓其結構化地表達呢？

	前臺數據展示	前臺交互邏輯	後臺數據邏輯
模塊 A	展示字段 A、字段 B 等	字段 A 沒有時隱藏；模塊點擊時發送埋點	字段 A 從 xx 渠道獲取，並作 xxx 處理

能夠看到，對於結構化表達的需求稿，咱們能更容易地提取出具體模塊在上述三部分前端代碼中所對應的信息，經過天然語言處理（NLP）等能力結合具體領域存量數據模型便可分析並結構化地描述出咱們所須要的重要邏輯代碼。

視覺稿設計

設計稿的內容描述相對就比較簡單了，目前設計師使用的一些設計工具好比 Sketch、Photoshop、XD 等軟件，自己都是帶有必定的結構化描述，咱們只須要經過設計工具附帶的開發者能力將視覺稿中的這部分結構化信息提取出來，轉換成咱們自身所須要的結構化描述便可填充到咱們的靜態 GUI 視覺代碼中。

交互稿（動效）設計

這裏主要講述能偏動效以及響應的交互稿，不一樣於視覺稿對圖層節點靜態信息的描述，交互稿一般表達的是節點狀態間的響應，在一些常見的能製做交互響應的設計工具中（好比 AE、Principle），若是咱們能提取出設計工具裏對設計師製做的交互結構化描述，那麼咱們也能夠去將其轉換爲咱們編程中所對應的交互行爲，將這部分做爲前端前臺交互邏輯代碼實現部分。

模型信息學習

除開上述直接的從信息載體獲取數據外，咱們還能基於咱們的經驗經過模型訓練學習的方式讓咱們所提取到的數據更加豐富，好比設計稿中描述不了常見 Web 組件，咱們能夠經過目標檢測的模型去提取到這部分的信息；好比對於業務域中文本內容對應的字段，咱們也能夠經過分類學習的方式將設計稿中靜態的文本內容自動映射到動態的字段上。

圖像

不一樣於上述的信息攜帶載體，圖像中是不含有結構化的信息數據的，咱們只能直觀地獲取圖像中的像素點陣信息。不過藉助目前的深度學習的能力，咱們能夠提取圖像裏基本的設計元素的內容（文本、圖像、Shape）以及樣式屬性。

除此外，咱們還能夠經過訓練模型來達到識別一張圖像中存在的目標（組件）的信息內容描述。

文本

對於設計稿中一些靜態的文本內容，若是存在跟接口下發的動態字段映射的關係，咱們也可分析設計師常描繪的文本內容，結合具體業務該內容可能對應的數據字段去作結合，好比 xxx 旗艦店，咱們可能猜想其爲業務數據 店鋪 數據源中的 店鋪標題 字段，從而能在生成代碼的時候跟接口中的字段作自動的映射。

結構描述

結構描述指的是從上述設計稿中提取的產物（JSON 數據描述），咱們在使用 GUI 靜態代碼描述頁面或應用程序時，除了基本的樣式信息，每每還會帶有一部分的語義結構，即結構佈局分組。實際上視覺稿中是不包含結構語義這層信息的，所以咱們每每須要使用咱們過往的佈局結構語義經驗去經過模型來訓練獲得這部分的結果，以使 GUI 的佈局結構描述更具語義化。

信息的深度鏈接

智能生成代碼的信息來源渠道有許多，每一個渠道都多多少少跟最終生成的代碼息息相關，若是不能所有消化使用這些信息，那麼生成的代碼必然是不完整的，於是將這些來源於不一樣維度的信息點如何彙集到一條線上也是很是關鍵的。

如下是咱們將不一樣渠道的信息去作關聯分析的一個嘗試，能夠看到，各渠道的輸入咱們可使用模塊的維度去作關聯，即一個模塊對應了 GUI 靜態代碼、前臺邏輯代碼、服務端數據邏輯代碼以及對模塊內潛在的模型組件識別的結果。經過這些信息的鏈接，咱們生成的模塊代碼裏除了最先階段單單從視覺稿中還原獲得的靜態 UI 代碼之外，還能結合其餘邏輯、語義信息將其中靜態的部分自動轉換爲動態，從而達到完整代碼的目的（字段綁定、模塊物料識別、渲染邏輯等）。

總結

imgcook 經歷了兩年的磨練，論證了當下從設計稿中提取信息去自動生成部分 GUI 代碼的方案是可行的，那麼下一步如何能從其餘信息渠道去獲取到更多的信息，在一個平面上將這些信息點去作關聯分析，創建成一個完整的圖譜，以達到覆蓋生成更多的準確的代碼，將是咱們持續去探索的方向。