阿里前端也切圖？不，人工智能幫你作

關注個人公衆號：一顆小樹，一塊兒交流，共同成長。

做爲負責 Aliyun 大官網和營銷中臺團隊中的一員，咱們的平常工做是橫向支撐各種運營同窗的需求，建設線上運營場和營銷能力，幫助他們實現用戶和收入的增加。在之前咱們經常會聽到這樣的聲音：

• 「今天咱們有一個緊急的需求，能夠幫忙支持一下嗎？」
• 「這個頁面很簡單的，可是咱們沒有本身的前端同窗，能幫忙支持一下嗎？」
• 「個人需求提交好久了，何時才能排期呢？」

過去的協做徹底基於人工支持，你們疲於奔命，但前端每每仍是成爲瓶頸，難以抽出時間來進行深度的思考和能力建設，久而久之會陷入一個惡性循環，同時外包和計件服務的也在逐漸減退，開發提效迫在眉睫。你們很容易可以想到，針對常見的業務場景和模式進行組件化的沉澱，沒錯，咱們成功和設計同窗改變協做模式，組成統一戰線，實現了核心營銷玩法和通用組件的沉澱，實現大部分平常場景的運營自主搭建。 但與此同時，咱們發現組件化並不能解決全部的問題，同時組件化的開發自己也是具備不小的開發成本的，是否能經過集團沉澱的能力和經驗，爲咱們帶來一些新的思路呢？這時咱們盯上了集團智能化方向，在幫助咱們進一步提效開發的同時，也爲咱們智能化能力的演進打下了基礎。

集團造風，咱們乘風

對我來講，智能化是集團前端四大方向中最神祕的一隅。通過研讀智能化小組的分享以及和小組成員的交流，梳理出了咱們的場景和集團智能化方向場景的異同。

	集團（淘係爲主）	Aliyun 大官網
場景	營銷導購	營銷導購
客戶端	無線場景爲主	PC + H5
場景特色	複雜度相對較低，展現型爲主	複雜度相對較高，存在複雜的交互和狀態切換
需求特色	業務模式和視覺規範更成熟	玩法和營銷模式長期處於探索期，業務需求變更比較頻繁
數據模型	有成熟的業務數據模型，搭投一體輸出數據	數據模型結構化程度還不夠，多須要運營人工完成錄入
提效思路	在認爲基礎組件和業務組件複用難度高的前提下，經過 D2C 能力和可視化編輯，下降二次開發的成本	組件化沉澱約束設計規範和複雜玩法；
簡單模塊零開發，不須要前端參與；
服務人羣	前端開發	運營 + 設計師 + 前端開發

淘系是在場景、數據模型甚至需求標準化的前提下，利用智能化實現開發提效。咱們是在各個層面的標準化暫未成熟的前提下，指望經過智能化能力，下降平常需求的投入，用技術爲開發提效，爲運營賦能。 當前集團智能化方向的核心能力是 D2C（Design to Code）能力，其中 UI、數據、邏輯的識別和表達，是基於「智能化的前提是標準化」這一前提進行的模型構建和訓練，最終以 imgcook 做爲產品載體輸出。在集團的其它 多個 BU 中，多爲利用 imgcook 的能力，配合可視化編排引擎，落地低代碼開發，提升開發效率。 這證實智能化能力在開發提效的路徑是走得通的，這時候須要結合咱們的場景，思考更多的可能性。因爲咱們會有大量的平常/臨時需求，純粹靠人工或外包的模式始終是成本很高，對業務的體感也較差。 最終咱們肯定進一步優化 D2C 能力，經過工具自動完成數據坑位的提取，轉換生成模塊 DSL，直接從視覺稿輸出可渲染的模塊，最終讓前端之外的角色能本身玩起來。與此同時，咱們的設計（稿）規範、數據模型、業務需求，還不具有成熟的標準，所以，咱們須要根據差別點，梳理解法並設計對應的技術方案。

站在巨人的肩膀上，構建適合咱們的智能化能力

最終通過和團隊小夥伴的共同努力，上線了兩種可以助力咱們提效的智能化方案。

Design to Component - 組件設計器落地零開發

實現了視覺稿直接生成模塊，自動挖取數據坑位的能力。對於普通展現類型的頁面，能夠在小時級完成配置並上線。

Design to Code - 借力 imgcook 提效二次開發

這部分依託 imgcook 的標準開發鏈路，拓展自定義 DSL，下降 70% 以上視覺還原的成本。

以智能化爲主線，沉澱通用技術能力

首先須要解決 DSL 可維護性和可拓展性的問題，好比多種模塊 DSL 的組裝和輸出，所以建設了 DSL 轉換引擎。另外一方面，零開發須要實現數據自動挖坑和綁定的能力，就要求咱們從視覺稿中獲取更多信息，具有識別模塊結構的能力，即合理的分組和節點的識別，所以建設告終構化引擎。 在整個過程當中，對團隊須要的智能化能力進行了一輪梳理，技術設計上，也增長了更多靈活的設計，應對將來的可能性。 最終爲咱們的開發實現了不一樣程度的提效。

下面爲你們詳細介紹實現 D2C 能力的技術方案。

DSL 轉換引擎：配置化輸出可運行的 DSL

這一步是將相對定位的模塊描述數據轉化爲前端直接可用的代碼。自定義 DSL 的原理不在此贅述，咱們的訴求是DSL 轉換能力能夠支持在 Node、Web 等多端可用，同時因爲咱們將來須要支持多種 DSL 規範，這些規範有可複用的部分，也須要有靈活拓展的能力。

所以咱們將其中的能力分爲核心層（Core）和處理器（Processor），每個處理器是一個獨立的功能單元，分別負責最終代碼須要的模板、樣式、數據和 Schema 生成等功能。核心層負責標準化輸入輸出，完成處理器流程的串聯，補充拓展性。最終完成配置化 DSL 轉換引擎的輸出。

結構化引擎：掌握模塊結構，解析定義元素

結構化的基礎思考是當前 imgcook 能力須要對視覺稿進行簡單的規劃化整理，咱們指望儘量少的對視覺稿進行干預，下降其餘角色的使用成本，那就有必要對模塊進行標準化的描述。同時 imgcook 的官網推薦鏈路中可視化的二次編輯尤其重要，在這裏會補充視覺稿不太方便直接描述的信息，好比數據字段的綁定、循環的處理、事件的聲明等等邏輯。 若是咱們指望實現零開發的鏈路，就必需要自動補所有分這類信息。針對數據字段的綁定，須要瞭解當前模塊中有哪些節點、每一個節點須要開放哪些配置，即須要具有 UI 模型的識別和解析能力。針對組件結構的識別，借鑑了集團的佈局算法方案，實現了一版基於咱們場景下較簡單的分組算法。 最終結構化引擎輸出的設計以下，其中元素模型負責對模塊中元素的識別和解析，抽象基類處理通用邏輯，不一樣元素可輸出不一樣能力，實現精細化識別；結構轉換的基礎是標準的分組結構，將來輔助精細化的元素模型，實現更智能的結構識別，如循環等。

結構化引擎在底層設計作了更多通用化的考量，將來能夠做爲通用的模塊結構解析能力，不侷限在 D2C 生成的模塊中，標準結構化信息能夠覆蓋全部的搭建平臺模塊，拓展更多的業務場景。

乘風破浪，持續探索智能化建設方向

目前初步實現了 D2C 能力的最小閉環，已經在部分業務場景中使用，期待能在提效上帶來的成果，將來還有不少能夠想象的空間：

• 以智能化爲基礎，充實提效能力，重點是結構化引擎優化，充實識別能力。如：
  • 標準組件匹配率提高，補充配置化能力
  • 循環結構自動識別，數據循環配置自動輸出
  • 推動視覺規範，利用 PC 自動完成 H5 適配
  • 持續接入其它智能化能力，如智能配色、智能合圖
• 以智能化爲契機，探索業務賦能方向，如：
  • 改變業務支撐模式，提升業務支撐效率
  • 串聯數據體系，提供業務效果優化建議，輔助業務決策
  • 接入標準模型，內容智能匹配，減小人工配置
  • 模塊結構分析，智能匹配已有組件，提升搭建效率

結語

目前不可避免地還存在一些問題，好比須要對視覺稿作標準化的處理，短期內還難以免前端同窗零投入。但智能化能力仍是給咱們帶來了史無前例的強大能力，幫助前端解放生產力，投入到更有價值的領域中去。

最後的最後，歡迎一塊兒來建設 Aliyun ToB 的線上體系，作點不同的事兒。長期接收任意姿式的社招同窗，郵箱 yeshu.lrt@alibaba-inc.com，歡迎交流。