作為阿裡經濟體前端委員會四大技術方向之一，前端智能化項目經曆了 2019 雙十一的階段性考驗，交出了不錯的答卷，天貓淘寶雙十一會場新增子產品 79.34% 的線上代碼由前端智能化項目自動生成。在此期間研發小組經曆了許多困難與思考，本次《前端代碼是怎樣智能生成的》系列分享，将與大家分享前端智能化項目中技術與思考的點點滴滴。
【閱讀提示】
- 全文較長，部分術語阿裡淘系内部營銷領域特有。有困惑之處可以評論交流。
- 本文重點介紹 D2C 面對阿裡内部淘系大促場景遇到的問題和解決方案，更多的研發場景我們将在不遠的将來一一涉足。
- 本文提及的部分功能隻有阿裡内部版 imgcook 才有，社群版 imgcook 暫時無法體驗，敬請期待。
概述
imgcook 是以各種設計稿圖像（Sketch/PSD/ 靜态圖檔）為原材料烹饪的匠心大廚，通過智能化手段将各種原始設計稿一鍵生成可維護的 UI 視圖代碼和邏輯代碼。
邏輯開發是前端開發的需求動線圖中最後，也是耗時最多的一步。從整個前端的開發過程上看，除了初始的靜态視圖編寫，所有的資料映射、添加動效、函數編寫、事件流、埋點日志等代碼本質上都是對靜态視圖資訊的一種補充。
下圖中，需求的産出是産品、互動設計師、視覺設計師共同協作的結果，而需求落地全由程式員實作。如果說“視覺稿結合 PRD 互動文檔”等于最終可傳遞開發的需求文檔，那麼“靜态視圖 + 邏輯”就等于一個前端頁面的最終代碼。
（需求動線圖）
探索曆程
前端開發工作屬于 GUI（GraphicUserInterface）程式設計的一種，從指令行時代進入圖形使用者界面時代之後直到現在，對便捷的進行界面開發的探索就沒有停歇過。在年頭尚淺的前端領域，也有 MVC 和 MVVM 的設計思想落地和 jquery、Backbone.js、Angular、vue、react 這些優秀架構類庫的湧現。
關注點分離（Separationofconcerns）是 GUI 開發領域的指導思想，通過将View 視圖和 Model 資料分離來簡化軟體内部結構。事實上大部分界面開發領域設計思想和架構都是遵循此基礎思路實作的，html+css+js 的 web 技術也是此思想的一種展現。
集團推崇的 react 的思想比較接近這個最初的核心理念，僅提供 V 和 M，以及一個兩者關聯的渲染過程。簡單來說就是 Ui=render(Data)，我們認同并作為依據之一開展了基于視覺稿視圖還原代碼的 D2C 項目。
我們本文所要探索的業務邏輯是項目代碼中除了 View視圖 以外的内容。如果說D2C 是一個視覺稿到代碼的過程，那麼距最終可上線頁面代碼的缺失部分就要交給本文的業務邏輯層來實作。
所在分層
業務邏輯層處于 D2C 核心能力的最下遊，所有服務化的智能化能力都需要在邏輯層實作最終的落地。
(D2C 技術能力分層 )
挑戰和難點
現狀分析
在 D2C 的體系裡，大部分技術體系都是基于設計稿視覺稿次元出發的，目标是解決布局結構、字段類名、内聯元件識别的準确性和合理性。而業務邏輯需要補全D2C 欠缺的能力，技術方案上和整個項目都不太一緻。
同時，業務邏輯層作為承上啟下的關鍵層，負責承接 D2C 智能化能力，輸出到可視化編排平台。智能化結果的是一個機率，是一個有幾率不準确的值，而下遊的可視化編排 IDE 卻是一個需要有确定性協定的程式，這樣才能保證輸出的代碼可最終上線。業務邏輯能否實作智能化的穩定落地是我們一個極大的挑戰。
在現有的 D2C 鍊路圖裡，業務邏輯層的輸入資訊除了布局算法轉換後的 UI 結構，還有以下輸入項：
- 語義化推測出的類名
- 字段綁定猜測出的可綁定字段（含圖檔分類和 NLP 分類）
- 元件物料識别出的小元件
- ...
業務邏輯層的産出結果是一份攜帶邏輯的可視化編排協定。這份協定的字段通過最終實作的功能來看又可劃分成如下幾種：
- 視圖模型
- 字段綁定
- 函數邏輯
- 自定義元件轉換
目标鍊路
傳統開發鍊路中，UI 編碼和邏輯需要人工編碼。在目前的 D2C 鍊路中，基于D2C 視覺還原能力，我們可以将 UI 編碼實作自動化開發，基本省略 UI 的開發時間。而 D2C 業務邏輯層的目标，就是實作邏輯編碼的自動化。我們希望将 D2C 能力進行全面更新，實作視覺 + 邏輯的統一還原，達到前端編碼的零投入。
( 傳統編碼鍊路、D2C 鍊路與目标鍊路 )
上圖中，藍色的部分實作了自動化開發，紅色的部分是 D2C 能力介入的位置。在我們期望的鍊路裡，D2C 将還原并實作前端全部代碼，而設計稿作為唯一的輸入必然存在一些需求的缺失，為此我們在還原步驟之前增加邏輯預配置階段，實作對缺失的需求進行補充。
問題分析
步驟一：思考真實的邏輯開發過程
我們在實作邏輯智能自動化之前，要分析一個邏輯代碼是如何編寫出來的。
假設我們已經開發好了靜态視圖，接下來需要為頁面增加的邏輯代碼需要一個輸入的過程，這個輸入源可以是我們的視覺稿、過往開發經驗、架構下的特殊規則、PD的需求文檔等，從需求的輸入源裡我們擷取需求相關的資訊并具象為一個個邏輯點。
比如：視覺稿中有一個寫着搜尋的按鈕，我們觀察的同時檢索腦海中過往經驗，這個搜尋大機率是一個點選觸發一個網絡請求的邏輯，借助需求文檔和與相關接口人溝通，我們知曉了這個網絡請求的方式和傳回内容。據此，一個需求的形态就具象成了一個邏輯點，下一步就是邏輯編碼并提測。
( 前端需求編碼操作動線 )
為了實作邏輯的智能生成，以上操作動線必須實作全自動。我們觀察需求編碼動線，可以明顯的發現：以需求具象為分割線，邏輯編碼過程可拆分為前後兩個大階段。前一階段實作需求的收集，後一階段實作需求的實作，中間具象化的一個個需求點就是我們開發中要編碼解決的工作。
在我們期望的鍊路中，業務邏輯層将為 D2C 能力提供邏輯預配置和邏輯還原兩個增量能力。這兩個增量能力對應到需求動線上就是需求的收集與需求的實作。在D2C 體系裡，我們稱其為邏輯識别與邏輯表達，并分别融入到鍊路下述兩個位置上。
(D2C 邏輯鍊路 )
步驟二：如何識别邏輯？
D2C 體系裡，邏輯識别是一個預先配置的過程。不同的邏輯點可提前配置好不同的預案，使用者使用 D2C 時命中了哪一項配置就認為此處存在哪個邏輯。
在 D2C 首先落地的淘系營銷場景裡，我們嘗試分析邏輯智能化生成面臨的最大問題。
思考一：“如何判别子產品所含有的邏輯點？”
( 如何觀察子產品含有的邏輯點 )
掃一眼上述子產品的布局模式，是一個 1 排 2 子產品，需要一個循環邏輯。
“掃一眼”這個動作，通過分析布局算法給出的頁面結構可以識别。
分析下各個文字，“跨店滿減，錯過等明年”是一個利益點類型文案。
人“分析文字”是對文字提取特征的過程，不同的目的下通常要提取不同的特征。此處文字中“跨店”、“滿減”等利益點相關的詞高頻出現，我們基于 ALiWs 的分詞算法和樸素貝葉斯多分類可以有效區分。
“已售 1000 件”看起來需要綁定到月銷字段上；
此處也是個分析文字的過程，用正則可以準确區分。
左下方的券在含有一定顯著的視覺特征，對于這種小區塊通常抽象為一個業務元件；
左下方的券是一個業務元件，其樣式，文字，節點數目存在資料特征，我們可以運用傳統機器學習進行分析。
商品的圖檔是一張白底圖，大機率綁定到白底圖字段上；
商品圖是一類特征明顯的圖，基于圖像分類算法可較為輕松的識别。
立即購買按鈕可能需要一個跳轉到詳情頁的事件，也有不跳轉，轉而交給子產品外層來跳轉。
這個邏輯隻能通過領域經驗來識别。
思考二：“是否可以覆寫我們的場景？”
類似的分析過程還有很多，我們暫不贅述。為了能解決命題，我們迫切的需要知道實際場景中上述邏輯點的構成情況，為此我們分析淘系營銷大促相關子產品，得到如下邏輯點分布柱狀圖：
( 營銷子產品邏輯分析柱狀圖 )
其中資料綁定類邏輯數量占比 50% 以上，其次是埋點相關邏輯，循環相關邏輯，處理業務的函數相關邏輯，元件邏輯等。總的來說，淘系營銷場景的子產品開發邏輯是一套有規矩可循、有規範可依，可枚舉、可複用、模式化、體系化的程式。經過多年雙 11 驗證，基本可以确定當下的規範可以滿足業務需求，不會在短時間内有大規模的未知需求湧入。
( 淘系營銷子產品開發規範 )
思考三：“我們的識别手段有哪些？”
D2C 體系本身具有許多底層智能化手段，輔助以專家經驗，可以對上述邏輯進行全面檢索識别。舉例如下：
随機森林算法：随機森林是一個包含多個決策樹的分類器，并且其輸出的類别是由個别樹輸出的類别的衆數而定。既可以用于回歸也可以用于分類任務，并且很容易檢視模型的輸入特征的相對重要性。
xgboost 多分類：XGBoost 全名叫（eXtremeGradientBoosting）極端梯度提升，經常被用在一些比賽中，其效果顯著。它是大規模并行 boostedtree 的工具，它是目前最快最好的開源 boostedtree 工具包。
文本 NLP 分類：基于阿裡 PAI 平台提供的 ALiWs 的分詞算法和樸素貝葉斯多分類進行文本分析。AliWS 的主要主要功能包括：歧義切分，多粒度切分，命名實體識别，詞性标注，語義标注，支援使用者自己維護使用者詞典，支援使用者幹預或糾正分詞錯誤。
圖檔分類：對業務場景中的圖檔進行分類，使用 CNN 網絡，在 ResNet 的基礎上進行遷移訓練。同樣部署于 PAI 平台之上，和文本 NLP 分類産品化鍊路完全一緻。
語義化服務：D2C 基于移動場景定制的類名語義服務。内部運用專家系統制定政策樹，在具體判别過程中運用 Alinlp 語義實體、詞法分析、翻譯等二方服務，并自建iconFont 服務實作了小圖示的鑒别。
布局算法：D2C 基于自創的行列掃描政策發展出的絕對定位轉 flex 布局的規則算法，同時提供了循環檢測、局部成組等關鍵性功能。
等等。
除此之外，我們有一些業務域下獨有的邏輯是沒有特征的，這部分邏輯使用人工幹預手段來實作。
最終，我們決定選用多種識别手段，從布局視覺、文本語義、圖像特征、經驗規則的層面實作邏輯的判别，并補充必要的額外資訊供邏輯表達使用。這些對子產品邏輯進行識别的程式我們命名為邏輯識别器。
每一個識别器都會基于自身擅長的領域給出鑒别結果，通過全方位的檢索視覺稿，達到近似人工思考的目的。
步驟三：如何表達邏輯？
邏輯表達依賴于兩個要素：邏輯的表達形式和邏輯的具體内容。
思考一：“邏輯以何種形式表達？”
為了明确邏輯的表達形式，我們 D2C 需要一個可承載智能化成果的場景，具體到實作上就是一套承載智能化成果的協定和一個智能化幹預平台。
imgcook（D2C 能力落地應用）結合 react、vue 等優秀的前端架構，參考各種競品，實作了一套簡版的基于資料驅動（Ui=render(Data)）的生命周期，并希望使用者能基于此規範進行元件的開發和編寫。
(imgcook 自定義生命周期 )
阿裡淘系營銷于 2019 年将營銷子產品規範更新到了基于 hooks 的 rax1.0 體系，imgcook 針對新的元件規範，實作了 mobile 和 PC 各一套的代碼生成服務。這樣開發者在 hooks 下也有生命周期可以使用，對開發者來說，不需要關心子產品是 hooks還是其他技術方案，隻需要認準 imgcook 規定的子產品開發方式就可以。
(imgcook 天馬子產品項目結構組織圖 )
限制了使用者 的 編 碼 規 範 之 後，imgcook 提 供 了 可 視 化 的 操 作 來 實 現 代 碼。imgcookIDE 目前可實作大部分靜态子產品的可視化編寫，下面是子產品邏輯可視化高頻操作的面闆：
(imgcook 可視化面闆【内部版】)
以淘系營銷中的典型需求舉例，在 imgcook 的可視化編輯器内，我們通常會這樣實作（假定子產品目前資料是一個單循環一排二商品子產品，循環疊代對象 item）
- 為節點的價格綁定資料：點選節點屬性 -> 資料 -> 新增一個資料綁定，值為item.itemActPrice。
- 子產品不足一行的時候進行截斷：點選快速設定 -> 代碼編寫 -> 新增一個方法 -> 編寫截斷代碼，将 items 的長度不被 2 整除的資料去除。
- 埋點邏輯：普通埋點需要點選節點屬性 -> 類型切換為埋點連結，點選新增一個資料綁定，增加 data-track-type、exp-type 等屬性，并為其增加資料綁定；主會場實時埋點在做節點類型轉換和資料綁定之餘，還需要在循環節點裡新增一個用于實時曝光的節點，其曝光類型需要設定為實時曝光。
- 加載更多：下滑式加載更多需要為子產品增加曝光事件，事件句柄裡編寫加載更多代碼。點選加載更多需要為子產品增加點選事件，事件句柄裡編寫加載更多代碼
對各個邏輯的操作步驟進行抽象化梳理，得出了如下邏輯實作步驟：
( 邏輯實作步驟抽象梳理 )
表格裡每一個列都是 imgcookIDE 一類抽象化的能力，可見大部分邏輯都可以通過配置的形式來實作。由于大規模業務邏輯的營銷子產品較少，是以我們決定基于複用而不是基于推測來生成函數算子，僅使用執行順序和是否有傳回值來控制流程，更為細粒度的算數、邏輯操作符和流程控制語句暫不在我們的考慮範圍内。
思考二：“邏輯以何種内容填充？”
可視化和真實代碼之間的媒介就是 imgcook 的協定，接下來我們就需要實作協定的自動化生成。
自動化的協定生成的核心是内容。節點将執行何種操作不是關鍵，要綁定到哪個節點、生成的代碼裡面内容才是關鍵。為此，我們邏輯識别器執行時會将目前處理過程涉及到的節點資訊、全局變量、人工配置等内容進行傳遞，在邏輯表達的運作時裡執行注入，這些目前邏輯要表達清晰準确所必需的資料在 D2C 業務邏輯層裡被命名為邏輯上下文。
下面來看一些真實的邏輯上下文：
邏輯一：為節點綁定活動價
邏輯二：不足一行截斷渲染數組
此邏輯函數内容是一個可複用的
xtpl模闆，可以直接通路 recognizeResult 作為渲染上下文。
使用渲染上下文可以在最終要增加的協定中“占坑”，實作協定的準确表述。
通過冗長的分析，我們業務邏輯智能生成的命題已經細化到了如何運用智能化能力識别邏輯并産出上下文和基于上下文實作邏輯自動化表達兩點上了。這兩點确認可行後，我們開始進行正式設計。
智能邏輯層設計
方案概述
根據對命題完整的推導，我們已經有了業務邏輯層能力的完整輪廓。
邏輯識别 + 邏輯表達 = 邏輯意圖
邏輯識别器需要您根據實際場景決定使用何種方式來執行識别。此階段接收視覺稿和人工規則，輸出為識别結果。
類比人的思考過程，D2C 此時已經“确認了子產品的需求”。
邏輯表達器是 imgcook 可視化操作的預置版，将識别結果進行翻譯，将此條邏輯帶來的影響直接表現在最終的子產品上。
類比人的思考過程，D2C 此時已經“寫完了這個需求”。
(D2C 業務邏輯層能力 )
功能劃分
基于上述推導過程和職責界定，我們将業務邏輯層劃分為邏輯識别、邏輯表達、邏輯核心等子產品。
- 邏輯識别提供智能化能力統一接入，確定業務邏輯可以被指定識别器準确識别并産出統一邏輯上下文。
- 邏輯表達負責對邏輯進行可視化協定的配置，能自動應用邏輯上下文，在邏輯被識别出來之後自動表現到子產品上。
- 邏輯層核心部分提供兩者的串聯整合和擴充能力，比如執行時序控制、布局模式支援、兜底 VO（ViewObject）生成、邏輯上下文注入、人工幹預等。從全局把控整個靜态設計稿邏輯化的過程。
- Libs 提供基礎能力，一部分供核心調用，一部分可在邏輯上下文中供識别函數調用。
(D2C 業務邏輯層結構圖 )
前文也說過，D2C 試點的是阿裡内部淘系營銷領域，為了友善以後接入集團其他業務場景，我們有了附着于團隊的邏輯場景概念。邏輯場景是解決一個業務域的邏輯合集，隻要某個業務域下的業務邏輯可枚舉、可規範、可定制，就可以建構自己的邏輯場景，友善自己的團隊的其他同學進行子產品開發。
邏輯核心功能拆解
布局模式識别
D2C 支援對一排 N 類型子產品，橫向縱向循環和任意層級的循環嵌套這些布局的識别，覆寫營銷域下大部分的靜态子產品布局。值得注意的是，D2C 對設計稿的規範程度要求較高，在雙 11 這種級别的活動裡對子產品 100%，這就要求智能化必須有規則化做兜底。為此我們更新了 D2C 設計稿布局還原準确度的要求必須是協定，您可以在設計稿上用标注的形式規整設計稿，確定布局還原結構準确、循環檢測正常。
(D2C 已支援的布局模式 )
視圖模型推演
智能化的前提是标準化。D2C 識别出的視圖需要和資料模型（schema）映射上才可以正常表達邏輯。對子產品視圖布局識别的過程中 D2C 會同步檢索 schema，確定循環層級和每一層的字段能對應上。然而現階段開發者不能保證子產品具有成型的schema，為此 imgcook 實作了視圖模型推演，在沒有 schema 時能自動推測出模型，確定僅從視覺稿視角出發的 D2C 也是一個完備的體系。
推演是一個建構資料模型樹的過程，在布局結構的過程中，我們将循環布局視作枝幹，将每個觸發綁定資料綁定的節點視作枝幹的葉子，葉子的具體内容從淘系過往子產品資料聚合結果中擷取。
渲染上下文注入
函數識别器和視圖表達器是邏輯層兩個基于 nodeVM 執行函數的地方，從接口定義上可以看來他們之間的聯系。
函數識别器
視圖表達器
函數算子時序控制
實際場景中，需要經由 D2C 自動化生成的編碼相關的邏輯較少。我們采用時序和是否有傳回值來做簡單資料流向控制。流程控制隻會出現在生命周期事件或節點事件的句柄函數裡，舉個例子，假設我們有三個邏輯需要在 created 裡面實作，分别是：“向循環數組塞入一個圖檔”、“根據一排幾來截斷數組”和“發送一個曝光埋點”。那麼通過配置順序和是否有傳回值，我們可以得到這樣的 created 函數。
人工幹預
我們也知道，許多邏輯是無法通過設計稿 Design 擷取到資訊的。為了解決這種無特征邏輯的生成，我們加入了人工幹預來進行協調。
協調方式一是參數問詢：定義自定義表單擷取使用者的輸入，在内部鍊路的layoutResult.userLogicConfig 中通路。
協調方式二是邏輯過濾：每個邏輯的配置都有開發者幹預選項，勾選之後，子產品開發者有權對此邏輯進行屏蔽。
這些管控措施都會展現在子產品還原的詢問彈窗上，若不了解彈窗内容的具體意圖，需要聯系目前邏輯場景的負責人。
(D2C 開發問詢面闆 )
邏輯識别器一覽
邏輯識别器是一個N選一的配置方式，對于一個邏輯，我們有如下圖示來引導使用者使用正确的識别器：
( 選擇一個正确的 D2C 邏輯識别器 )
1. UI 物料識别器
- 特點：
- 使用 xgboost 算法對子產品中含有邏輯的視覺特征節點進行識别，相較于随機森林算法在我們的資料集上表現更優越
- 适用于子元件視覺特征足夠明顯，邏輯元件具有一定複雜性的場景
- 物料識别器本質是一個分類器，隻告訴管理者某個節點是某個邏輯的載體。而不會告訴更多資訊
- 當 UI 物料識别器不滿足預期時，可以使用設計稿注入協定來進行此條邏輯的兜底
2. NLP 文本識别器
-
- 基于 ALiWs 的分詞算法和樸素貝葉斯多分類實作文本分類模型。對您輸入的文本樣本進行訓練，有助于您對自己問題域下文本進行有效歸類。
- 當您擁有大規模文本體量時，推薦用此方法進行文本的分類
- 含有内置識别結果，涵蓋不友善走文本 NLP 訓練鍊路的一些常用分類。比如：價格、原價、商品圖、白底圖等。
3. 自定義函數識别器
-
- 當目标邏輯可以通過 javascript 代碼分析樣式、結構、文字等資訊的方式識别出時使用
- 在沒有樣本訓練 UI 物料識别器和 NLP 文本識别器的情況下，它是一個比較不錯的邏輯庫建設方案
- 函數識别器可接收使用者傳參來做邏輯決策。比如天貓業務場景下對于埋點有兩套截然不同的邏輯表述，我們可以編寫兩個埋點邏輯，在各自的識别函數裡做二選一。除此之外，函數識别器可以攫取元件樹資訊，給邏輯表達器提供更為強大的邏輯上下文
4. 預設識别器
-
- 預設邏輯會被所有子產品應用，它的邏輯識别結果永遠為 true
- 用于一些視覺層面沒有特征的、較為通用的邏輯
- 多與“開發者幹預”配套使用，由開發者決策是否使用
- 預設識别器無法擷取元件樹資訊，如果有攫取資訊的需求請移步函數識别器
5. 正則識别器
是 NLP 的正則分析版，能力是 NLP 識别的子集。
邏輯表達器一覽
邏輯表達器是多個抽象化的子表達器組合的結果。我們将一個邏輯的實作方式拆解為最細粒度的可視化操作，通過分析此邏輯的具體實作方式，依次在背景配置表達式，進行邏輯組裝。當識别器告知表達器目前邏輯激活時，則自動化實作該條邏輯的代碼。
( 邏輯表達器功能劃分 )
1. 視圖子表達器
- 可以處理視圖層面的變更，能力極強，理論上可以覆寫其他所有表達器的能力。未來 imgcook 希望對視圖操作也進行可視化配置，是以希望視圖表達器隻關注視圖層面的變化，職責劃分明确，不要涉足其他表達器的能力範疇
- 此表達器接收一個被 vm 執行的視圖處理函數
2. 資料綁定子表達器
- 可以新增一條标準資料綁定，自動去重。大部分時候都需要借助邏輯上下文内的屬性做動态表達
- 此表達器接收一條資料綁定的配置
3. 事件綁定子表達器
- 可以新增一個事件綁定，此事件會預設帶一個事件執行句柄，每個事件執行句柄内部可以用函數算子填充流程。
- 此表達器接收一條事件綁定的配置
4. 函數算子子表達器
-
構造一個自定義方法，并決定在哪個句柄裡調用。一般來說，函數算子隻能在事件執行句柄和生命周期函數的流程中被調用，并通過排序和是否有傳回對象
來控制流程。
- 此表達器接收一個函數的配置，内容可使用 xtemplate 文法編寫
5. 依賴管理子表達器
- 在前幾個子表達器需要引入三方依賴的時候使用
- 此表達器接收一個依賴的注入
落地成效
雙 11 邏輯場景建設
本次雙 11 子產品的開發中，基于本文提及的智能邏輯鍊路，imgcook 建構出了一套淘系營銷活動獨有的業務邏輯場景。内置了基于淘系營銷視覺規範的邊距設定邏輯、基于淘系營銷埋點規範的埋點邏輯、基于 rax-hookssolution 的子產品渲染拆行邏輯等預設邏輯。
除此之外，結合文本 NLP、UI 物料分類算法等識别器提供的智能化能力，配置了大量的資料綁定、元件識别的邏輯，當開發者視覺稿中含有此類特征時會自動将邏輯代碼運用到結果上。
(D2C 雙 11 邏輯場景【内部版】)
雙 11 邏輯還原名額
根據統計，2019 雙 11 有 78.94% 左右子產品使用 imgcook 業務邏輯生成鍊路，生成的子產品代碼有 79.34% 數量留存至此次還原之後的上線代碼中，平均命中的業務邏輯數量約為 14，也就是說平均每個基于 D2C 新鍊路開發的新子產品幫開發者少寫了至少十幾條邏輯。
在弱邏輯的靜态 UI 的子產品上，相關名額更高。以下方子產品舉例，基本可達到一鍵還原至可提測狀态，大大減輕了開發者的工作量。
(D2C 雙 11 邏輯命中示例【内部版 imgcookWEBIDE 開發鍊路】)
未來展望
目前不足
在雙 11 落地的過程中也暴露了很多問題，比如流程不夠友好，淘系子產品開發流程是需求 -> 設計稿 -> 子產品開發 -> 前後端聯調 -> 子產品上線。作為一個為設計稿賦予邏輯，使其直接轉為可上線子產品的全新理念的體系，沒有為之預留的開發時間。當下我們通過加大人力在開發前提前介入來彌補上述不足，未來我們将會把需求和設計稿的産出過程都納入業務邏輯層範疇，對于可支援的子產品提供一站式研發閉環體驗。設計師負責設計 UI，PD 基于 UI 添加需求，開發負責在背景維護可用邏輯。結合團隊未來趨勢，D2C 在業務邏輯領域的實戰經驗将在未來有效的助力整個體系。
未來計劃
D2C 智能邏輯體系已經驗證了自己的想法并邁出了堅實的一步，未來，邏輯智能體系 2.0 将聚焦在以下幾個方向：
産品形态更新
如本文開始所述，Design+PRD 才等于需求。D2C 是一個基于設計稿的技術體系，我們将在未來接入需求 PRD 結構化能力，替代 imgcook 目前的人工幹預鍊路，實作全鍊路零研發。
名額驅動優化
基于雙促子產品統計結果，我們産出了代碼可用度的概念，即 imgcook 産出的代碼占上線代碼的比例。未來，我們将擴充更多的邏輯識别器算法接入、提供更抽象易用的邏輯表達器、實作業務邏輯層核心的組織。imgcook 将基于名額驅動開發，讓智能化生成的代碼與實際業務産生真實的碰撞，并最終朝着提供更優異的智能化服務而邁進。
ImgcookStudio
imgcook 編輯器核心更新。基于核心我們将衍生出營銷業務、社群業務、小程式業務等業務平台，并将邏輯場景的建設擴充到集團級别，在更多的業務場景裡實作定制。最終實作前端智能化能力的穩定輸出。
小結
簡單來說，我們希望有更強的智能化能力，更廣的服務場景，更高的提效訴求。使整個體系真正成為一個從視覺稿視圖推演并生成全部子產品邏輯的智能化服務。從前端編碼占比 79.34%，到前端“零研發”，到需求“零研發”，最終到整個需求的“零投入”。