阿裡巴巴進階前端技術專家甄子帶來“《前端智能化實踐》——邏輯代碼生成”為題的演講。前端智能領域到底該如何落地人工智能技術呢？本文從UICode到LogicCode有多遠開始談起，接着從頁面結構和資料結構的視角分析，進而講述了開發者賦予的自定義能力，最後對前端智能化的未來進行了展望。
到了機器學習時代，我們能做的事情非常多，業務壓力也非常大，那麼，如何提效把我們從日常重複性勞動中釋放出來，讓我們有機會嘗試更多新技術，并用新技術改變業務？我們的初衷是想要通過機器學習提效，通過機器視覺+機器學習來了解設計稿，将設計稿轉成代碼，避免做一些人工的事情。我們希望能夠替代UI開發，能夠替代部分動效和邏輯開發。
我們到底做的怎麼樣呢？
當我們真正涉及業務中如何識别設計稿，正确識别設計稿中UI元素并保證很高的還原度，尤其是後期如何在日常工作中做到工業級可用的技術水準。我們主要将模型精度及工程鍊路上工程工具的成熟度做了大幅度的提升，借助在阿裡的天然優勢，每年在618、99大促、雙十一、雙十二等節日都有技術大考，如何在大規模的業務訴求上，使用我們的技術真正做到提效？
UICode到LogicCode有多遠？
如何做邏輯代碼生成？這源于BERT模型，它特别像翻譯的過程，比如我們基于技術對各種各樣的語言進行語義化的分析和了解，最後通過語義關系的抽象形成的模式可以把任何一種語言翻譯成目智語言，那麼，這個過程是如何做到的？
語言都是由詞、句、段、節、章、文、書組成，整個過程相當于把複雜的事情變得簡單化，把裡面存在的元資訊抽取出來，然後對這些中繼資料資訊，如果機器學習是一個皇冠，NLP就是皇冠上的寶石，NLP從搜尋開始就對網際網路産生非常大的價值，但是使用者真正在keyword中輸入的詞并不一定是他們真實想要表達的訴求，後來的搜尋引擎、問答系統、個人助理都會用到自然語言技術，比如空間上比較典型的W2V，我們會把抽出來的元資訊看作一個個vector，vector之間有很多的算法（如餘弦相似度），可以探索使用者真實訴求；還有語義化，我們定義的控件是一個link，這個link可以代表一個點選跳轉的連結位址，但真正在日常工程中實作的是基于URL路由的trigger作用，這時我們就要對link标簽在上下文中的語義做了解，才能對link對目前DSL語義做準确判斷；以及時間次元，比如當下語境說的事情和另外一個語境說的事情在語言表達上可能沒有差別，但是因為所處語境不同，表達含義也可能不同。
我們首先要對控件進行語義化，控件到底是怎樣組成基礎元件的？在基礎元件裡，控件本身的語義以及控件所處的元件中context上下文語境是什麼，緊接着是通過基礎元件之間的關系怎麼滿足業務訴求将它們組合在一起，然後是将業務元件以子產品化頁面形式組合在一起，其中包括将元資訊根據上下文資訊以它本身語義做了解，在了解的前提下，我們才能知道應該如何去表達。
那麼，這個過程就會變成通過設計稿、互動稿、線框圖、需求文檔的描述進行了解，再到生成邏輯代碼的過程，它與以往的搭建和低代碼開發是兩個概念，以往的搭建和低代碼開發是預先設定好能夠實作的能力或功能是什麼，然後以元件或控件子產品形式組裝好，讓業務人員使用這些元件或者子產品，但其中會有很多問題，比如業務人員是否具備程式員的軟體工程思想，如果不具備，那麼了解的成本會很高。我們希望未來可以變成互相之間解耦的事情，在需求了解方面可以獨立做需求了解，當輸入設計稿、需求文檔、線框圖、互動稿後，隻需要知道産品或業務真實訴求是什麼，在生成代碼時，參考功能，從軟體工程角度做過往的前端代碼語義分析，最後知道怎麼組織API和資料，用javascript等語言特性将它們組織在一起，然後生成這些功能和邏輯代碼。
我們現在做的從識别到表達的解決方案整個過程如圖所示，在識别部分，UI及UI上的文本、後續對需求的結構化收集和線框圖、互動稿的資訊收集進行識别，識别之後需要有一個了解的過程，這個了解就像将一個語言翻譯成另外一個語言一樣，我們識别出背後的模式，模式可以在任何語言中進行複用，未來的表達就是解耦生成的過程，隻要用語言的特性去組織代碼即可。
如圖即是我們權益表達的一個子產品，以軟體工程視角看待此子產品時，最開始為最上面左邊第一個子產品的樣子，repeat兩次變成視覺稿展示的形式，最後實作子產品代碼時，就不會把該子產品寫三遍，而是寫一遍并在布局時repeat兩次。緊接着可以看到，在一個子產品中包含權益，即到底可以從優惠券的互動操作上得到什麼，背後代表一些限制條件和發放規則，加購的文案背後代表的是要實作一個加購的邏輯，我們希望有一些品牌的透出，是以要展示一些品牌的logo，我們不會把這個logo寫死，但是當一個産品或業務去思考這個問題時，他們一般不會考慮将logo寫成動态去取的過程。還有進店，店名不僅僅是一個文案顯示一個店名，更多的業務和産品的訴求希望能夠通過優惠券産生一個進店的引導。将子產品内部的元素全部都梳理出來之後，我們就能抽象出來整個邏輯，包括店名/進店、品牌/進品牌号、權益/條件、文案/加購、主視覺/主色調、背景/氛圍，這些都會映射到表達的過程中，可能變成子業務資料、業務資料、權益元件、基礎樣式、業務樣式等。
頁面結構和資料結構的視角
大家可以看到，左邊是一排N的子產品，中間是橫向&縱向循環，我們怎樣識别出哪些是row哪些是column，通過對設計稿和需求的語義化了解後就會知道哪些控件适配于哪些元件的，比如幾個人在場景中轉，到底哪些像素屬于頭，哪些像素屬于身體，哪些像素屬于胳膊，這就是語義化的分割，怎麼能夠将相同語義的元素聚合到一起，通過聚合到一起的元素找出哪些是非重複的中繼資料。
通過中繼資料再到以往生成的scheme，找出到底元件上的資料scheme是什麼，再把scheme上的資料綁定到類名、圖檔字段、文本字段上去，這其中涉及到如何做資料節點的識别、資料類型規則、文案檢驗和節點類型修正，通過準确的語義化，加上過往的scheme和UI控件屬性之間的關系，能夠做到自動進行資料字段的綁定。
如圖是我們抽象出來的一些邏輯點，當我們做到資料字段的綁定後，會發現日常整個的開發工作裡還有大量的重複代碼工作，比如上報一些資料、處理頁面初始化時配置的讀取、配置的下發以及當節點銷毀後，頁面元素發生變化後需要做的一些事情，這些事情确實會有一些個性化的地方，但是個性化往往來源于對于輸入參數的生成及對于輸出資料如何去應用，這部分代碼一般來說都是抽象的，都可以以一種模式提取出來，我們給它取名為邏輯點，對頁面上的很多代碼能夠抽象成同一種模式或統一代碼塊的稱為邏輯點，在這些邏輯點上把輸入輸出做語義化識别後得到字段屬性，通過測量知道輸入參數是什麼，這樣，我們就可以做到把平時常用且需要大量人工參與的開發變成通過識别到表達的方式，通過邏輯布局和屬性的識别等，調用相應的邏輯點進行表達，這樣的代碼都是通過imgcook平台的語義識别和自然語言了解自動生成的。
因為我們背後的表達能力，我們生成依據的必要輸入包括通用的語義流程、布局樣式權重、圖檔分類、iconfont模型、w3c語義分類、文本分類、業務模型分類、配置政策等，我們發現，當我們去實作後續的邏輯字段綁定、代碼生成的過程時，我們能夠梳理出到底語義化給我們了解到什麼程度，需要從設計稿、互動稿、需求文檔中收集的資訊和缺失的資訊到底是什麼，收集的資訊和缺失的資訊盡量用機器學習和自然語言了解的方式把它做自動化補全，但這個過程一定是有精度的損耗，這也是為什麼到現在為止零研發隻能覆寫到80%的日常子產品開發中。
最後，我們回過頭看前面這張圖，左邊是邏輯識别的協定，這個協定是将了解生成代碼和後面流程串聯在一起的互動界面，右邊是邏輯表達協定，通過這個過程生成代碼未來怎樣才能複用更多的不同架構中去。
在整個過程中，我們使用到的機器學習能力包括遷移學習、卷積神經網絡、Resnet、tensorflow等，現在機器學習在圖像識别和自然語言了解領域已經非常成熟，都有非常general的模型可以解決業務中常見的80%～90%的問題，但是大家對這些能力的了解是欠缺的。是以，我們與tensorflow.js合作，未來希望能夠降低大家使用技術的成本，便于大家快速進入到其中，快速了解技術能力的優缺點，以給自己做技術選型時候做支撐，還有使用技術時的流程是怎樣的，和現有前端鍊路怎樣做深度結合，來保證未來使用技術時成本更低、體驗更好。
賦予開發者自定義的能力
如何能夠更好的使用tensorflow和機器學習的能力？我們有很多環節已經被過往的先驅屏蔽了，比如對于建立模型來說，将這個模型執行個體化就可以調用了；添加分類和樣本，前端代碼從源碼分析到生成，整個技術生态非常完備，是以我們可以自動化産生标注資料，而不像傳統機器學習很痛苦，需要請一堆人員做樣本資料，我們現在的樣本大部分可以通過調用架構、讀取gitlab上業務代碼，通過headless技術用poptear渲染出來，渲染之前就會寫清楚是什麼子產品什麼元件，将來綁定資料是什麼，整個技術體系非常完備。未來我們想訓練自己的模型時，我們的優勢是可以生成大量優質的标注資料來幫助我們描述定義的問題的重要特征。在訓練模型部分，我們有auto-machine-learning技術，部署模型也有各種各樣的工具，尤其是有了tensorflowdistribution的一些工具後，再加上現在可以在雲端很多容器裡做部署，都是很簡單的。
是以，我們與tensorflow.js技術團隊一起合作，希望能夠降低前端學習機器學習的成本，我們發明了Escher架構，Escher想讓前端開發人員零成本進入前端智能化領域去用機器學習能力解決業務上的問題，我們要保證未來大家在使用技術時能夠跟現有的前端技術生态可以無縫連接配接在一起，比如現有技術生态已經有日志收集工具，這個日志收集工具收集的日志可以直接被Escher使用做資料清洗、資料增強到模型中進行訓練等。
在此非常激動的告訴大家，我們已經走完了pipcook的開源流程，歡迎大家加入到我們的開源項目中來，初期，我們隻提供了為數不多的幾條pipeline，在pipeline中大家可以很低成本實作資料收集、模型訓練到釋出的全流程，未來我們希望能夠通過資料和模型統一的标準，讓大家可以在統一的技術生态裡做技術促進。開源網址如下：
GitHub：
https://github.com/alibaba/pipcook前端智能化的未來
最後，我們對designtocode的規劃如圖所示，需求的結構化收集是我們後面比較重要的一點，在本身的imgcook鍊路裡，體驗相對來說不是特别好，要求大家安裝sketch或者Photoshop，還要再裝插件，這些問題我們都在一點點解決，我們在下個月會release一個版本，使用者不再需要安裝sketch和插件了，隻需要上傳設計師給你的源檔案，或提供一個URL，我們就可以自動分析源檔案，幫你生成代碼，也不存在複雜粘貼的過程。隻有當你認為代碼在你的工程鍊路中無法滿足你的需求時，需要自己二次編輯時，才有必要打開web編輯器。未來我們希望通過需求結構化收集進一步提升生成邏輯代碼的準确度以及我們可以覆寫的業務場景，最後我們希望通過開源的方式把imgcook内部的模型能力和生成代碼的品質進一步打磨好，争取在明年年底開源出來。
我們希望從以前單設計稿頁面，變成更詳細的收集需求，把我們生成邏輯代碼能力覆寫到多頁面的複雜互動場景中。
最終，我們希望可以完全替代動效的開發和邏輯開發，把這部分精力釋放出來做更多有意義的事情。
我們希望當下做的很多事情，未來可以找到更多的業務場景。