作者： 也樹
作為負責阿里雲大官網和營銷中臺團隊中的一員，我們的日常工作是橫向支撐各類運營同學的需求，建設線上運營場和營銷能力，幫助他們實現用戶和收入的增長。在以前我們常常會聽到這樣的聲音：
- “今天我們有一個緊急的需求，可以幫忙支持一下嗎？”
- “這個頁面很簡單的，但是我們沒有自己的前端同學，能幫忙支持一下嗎？”
- “我的需求提交很久了，什麼時候才能排期呢？”
過去的協作完全基於人工支持，大家疲於奔命，但前端往往還是成為瓶頸，難以抽出時間來進行深度的思考和能力建設，長此以往會陷入一個惡性循環，同時外包和計件服務的也在逐漸減退，開發提效迫在眉睫。大家很容易能夠想到，針對常見的業務場景和模式進行組件化的沉澱，沒錯，我們成功和設計同學改變協作模式，組成統一戰線，實現了核心營銷玩法和通用組件的沉澱，實現大部分日常場景的運營自主搭建。
但與此同時，我們發現組件化並不能解決所有的問題，同時組件化的開發本身也是具有不小的開發成本的，是否能通過集團沉澱的能力和經驗，為我們帶來一些新的思路呢？這時我們盯上了集團智能化方向，在幫助我們進一步提效開發的同時，也為我們智能化能力的演進打下了基礎。
集團造風，我們乘風
對我來說，智能化是集團前端四大方向中最神祕的一隅。經過研讀智能化小組的分享以及和小組成員的交流，梳理出了我們的場景和集團智能化方向場景的異同。
淘系是在場景、數據模型甚至需求標準化的前提下，利用智能化實現開發提效。我們是在各個層面的標準化暫未成熟的前提下，期望通過智能化能力，降低日常需求的投入，用技術為開發提效，為運營賦能。
當前集團智能化方向的核心能力是 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 適配
- 持續接入其它智能化能力，如智能配色、智能合圖
-
以智能化為契機，探索業務賦能方向，如：
- 改變業務支撐模式，提高業務支撐效率
- 串聯數據體系，提供業務效果優化建議，輔助業務決策
- 接入標準模型，內容智能匹配，減少人工配置
- 模塊結構分析，智能匹配已有組件，提高搭建效率
結語
目前不可避免地還存在一些問題，比如需要對視覺稿做標準化的處理，短時間內還難以做到前端同學零投入。但智能化能力還是給我們帶來了前所未有的強大能力，幫助前端解放生產力，投入到更有價值的領域中去。
關注「Alibaba F2E」
回覆 電子書 立即下載