設計稿智慧生成程式碼的發展

據不完全統計，淘寶天貓僅搭建類模組的年新增量 1w 以上，年頁面增量 100w 以上，這些產品頁面心智不同導致 UI 視覺多樣、業務性質不同導致業務邏輯不同，大量的模組難以複用，需要投入大量的前端人力來開發，前端同學的業務壓力非常大。

為了解決這種困境，在 2017 年研發了能夠自動生成程式碼的工具，當時叫達芬奇，後來我們逐步引入 CV、NLP 等 AI 技術來解決圖層識別問題和語義化問題，經過一年多的發展後已經能夠在對設計稿的約束很少的情況下生成可讀性和可維護性較高的程式碼，並在 2019 年 1 月正式對外開放 imgcook 平臺。

穩定性和效能是每年大促必備的橫向專案，對外保障大促會場的穩定和效能體驗，從 2019 年雙 11 開始，研發效率也成為大促的橫向專項之一，對內提升研發效率釋放人力，減輕前端同學的業務壓力。

設計稿生成程式碼(Design to Code, D2C)平臺 Imgcook 作為研發效率專項專案中提升研發效率的核心抓手，在 2019 年雙 11 大促會場中承接了 78.94% 的新增模組的自動生成，程式碼可用率達到 79.34 %。今年前端智慧化助力前端研發模式升級，數個 BU 共建前端設計稿識別演算法模型和資料集，並於雙十一會場大規模應用落地。設計稿生成程式碼技術體系全面升級（如對 UI 多型、直播影片元件、迴圈的智慧識別增強等）帶來了營銷模組研發鏈路產品化升級：雙十一會場有 90.4% （高於去年）新模組的程式碼智慧生成。升級設計稿智慧檢查能力，無人工輔助的情況下智慧生成的程式碼被保留髮布上線的佔比 79.26%。相比傳統模組開發模式，使用設計稿生成程式碼技術後編碼效率（模組複雜度和研發耗時比值）提升68%，固定人力單位時間模組需求吞吐量增加約 1.5 倍。

今年雙11的研發提效

今年雙 11 在可統計範圍內共有 52 個新增模組，其中使用 D2C 的模組佔新增模組的 90.4%，包括主會場、行業會場、專題會場、榜單會場、新品會場、U 先會場、感恩會場等，沒有使用 imgcook 的原因為：複雜互動互動、動效、3D 和 UI 設計感較強的場景。下圖展示的是本次雙十一中透過 Imgcook 視覺化研發鏈路開發的部分模組。

研發提效是一個比較常見同時比較寬泛的概念，根據真正前端的時間花去哪了，我們統計了 100+ 的淘系 C 端前端開發者的具體時間，結果（經過被統計同學私人同意，電腦安裝類似 Timing 的軟體進行批次統計，總計約 2200h+ ）如下:

前端耗時佔比最高的是編碼階段 27.7%，top2 是線上釘釘溝通 20%。除了編碼外，前端其他環節多，每個環節均有一定耗時，如分享總結和學習的時間佔比也不少，前端是一個需要不斷學習總結的職位。從全域性來看，前端整體提效關心的是整體的前端人效的提升，到底能減多少人，或者現在人員本來就緊缺，減人的統計方式不太可行，那就看需求吞吐率（固定前端人員單位時間的需求吞吐量）；從區域性看目前D2C 主要提效的是編碼階段，所以編碼效率是也是關鍵提效指標，進一步分析，影響編碼效率的主要因素有智慧生成程式碼的可用率和業務的複雜度等。研發提效的衡量指標

我們從三點來衡量是否有效的進行了研發提效，分別是：需求吞吐率、編碼效率、程式碼可用率

需求吞吐率

在本次雙 11 會場專案中，選擇了 2 位正式同學和 2 位外包同學作為試驗人員，只做模組需求，模組按高度複雜、中度複雜和低度複雜區分，模組個數按中等複雜度為單位折算，例如 1 個高等複雜度模組相當於 2 到 3 箇中等複雜度模組， 1 個低等複雜度模組相當於 0.5 箇中等複雜度模組。最終得到這樣的結果：

同時採訪了數十位同學，在不使用 D2C 的情況下平均每週能開發 1.5 個模組，所以將

定為 1.5。由此可計算出，和完全不使用 D2C 相比，固定人力單位時間模組需求吞吐量提升約 1.5 倍。

PS: 此 需求吞吐量 指標後續日常待增加更多樣本，持續驗證。

編碼效率

需求吞吐量會將整個需求中的因素包括需求溝通時間也考慮進去，而編碼效率則可以衡量單位時間內完成的開發工作量。我們統計了 2020 年 9 月份之後在 IDE 中開發的 38 個模組與使用 imgcook 開發的 34 個模組的複雜度和開發時長，並計算出每個模組的效率值 E=Complexity/Time。

在 IDE 中平均研發編碼效率值是 0.604，在 imgcook 中的研發編碼效率值是 1.89，換算成相同複雜度模組的編碼時間比較，可以看出使用 imgcook 研發編碼效率上可提升約 68%。

程式碼可用率

我們統計了 Imgcook 最後一次還原生成的程式碼在此次還原最靠近的線上版本中的留存行數佔比。即程式碼可用率 = (imgcook 生成程式碼行數 - 刪除的程式碼行數) / 線上程式碼行數。雙 11 會場無人工輔助的情況下純檢視程式碼可用率 70.07 %，CSS 程式碼可用率 73.88%，總體程式碼可用率 79.26%。

我們以一個雙 11 模組為例分析程式碼生成的情況，對於一個佈局生成較好的模組，程式碼的改動主要在於新增一些事件繫結和欄位繫結程式碼，此模組程式碼生成可用率為 89.8%。

（U先會場-短影片）

變化和創新

在前端智慧化大背景下，對 D2C 技術體系全鏈路進行了智慧化能力升級，併為前端同學帶來了讓前端工程師能成為機器學習工程師的前端演算法工程框架 Pipcook 和解決樣本收集問題的樣本製造機 Samplecook。同時帶來了營銷模組研發鏈路產品化升級，助力全鏈路研發提效。

（D2C 技術升級架構圖）

D2C 技術體系升級

D2C 的智慧化能力分佈在還原鏈路的各個階段，我們以提升程式碼可用率為目標，對全鏈路進行智慧化能力升級，將技術方案細化到如何讓各階段模型識別準確率提升以及如何能將識別結果最終應用到智慧還原鏈路生成程式碼，如何做到從樣本收集、模型訓練、模型部署到模型應用到工程鏈路整個流程能夠自動化、自我迭代最佳化，不斷最佳化和迭代模型能力。

智慧化能力的應用還需要工程鏈路的支撐，例如模型識別結果的應用、線上使用者行為召回、前端開發元件對 UI 元件識別結果的承接等，整體的 D2C 技術體系也需要同步升級。

（D2C 技術體系升級大圖）

D2C 研發模式升級

淘系營銷以模組開發為主，模組開發的完整鏈路是從模組管理平臺建立模組 ⇥ 進入 Imgcook 平臺智慧生成程式碼&視覺化研發 ⇥ 開發完成後進入 IDE 除錯預覽 ⇥ 測試完成後進入工程平臺釋出。整個研發流程需要切換多個平臺，開發鏈路體驗和工程效率都有待提升。

建立模組後進入 Imgcook 平臺智慧生成程式碼&視覺化研發，如果能夠直接在 imgcook 平臺開發、除錯、預覽和釋出，一站式的 D2C 研發模式是提升整體研發效率和研發體驗的一個不錯的選擇。

所以我們自定義了具有視覺化模式和原始碼模式的營銷版本 Imgcook 視覺化編輯器，在視覺化模式智慧生成程式碼和視覺化研發，並將生成的程式碼一鍵同步到原始碼模式的 WebIDE，在 WebIDE 中支援介面化的除錯、預覽、釋出。

(天馬模組 Imgcook 視覺化研發動線)

我們透過計算使用傳統研發模式開發的模組與使用 Imgcook 視覺化研發模式開發的模組的效率值（複雜度與研發耗時比值）看到，使用 Imgcook 視覺化研發鏈路開發的模組編碼效率提升 68%。

增加演算法工程體系

Pipcook 透過提供通用的模型能力，比如圖片分類、目標檢測、文字分類等，減少了在 imgcook 中從開發到上線這些模型的門檻，使得如此多的底層識別能力也具備快速迭代的可能性。imgcook 全鏈路的識別能力，如元件識別、Icon 識別、欄位語義識別等都是基於 Pipcook 訓練。

（前端演算法工程框架 Pipcook）

來年展望

編碼和溝通是佔比最大的部分，期望透過結構化需求、提高 PRD 交付質量以減少溝通時間。未來期望業務研發平臺能夠打造需求即程式碼、需求即生產、協作線上化的全新業務研發模式，提升整體需求鏈路研發效率。

(業務研發架構)