前端智能化發展現狀與未來展望

前端智能化歷時三年有餘，從最初被誤解爲 “用 AI 包裝自己的 PPT 產品... 到 imgcook.com 發佈上線。從淘系技術雙十一零研發戰役，到賦能十餘個 BU。從 QCon 十週年分享“一個前端智能化的實踐” 後各種質疑，到 23000+ 用戶並被京東、騰訊、字節跳動…… 等公司模仿，平安銀行等大企業請求私有化部署……。一路走來，有過太多的不眠之夜和心酸苦楚但依舊陽光快樂的我，想對過去做一個簡要的總結，並對未來長期發展的方向做一個規劃和展望，希望能把前端智能化是啥？講清楚。

2017 年開始提出 “前端智能化” 的概念，當時負責 UC 國際瀏覽器，從前端的場景出發，有過一些嘗試：用戶體驗度量、UI 自動化測試、基於設計稿生成代碼。直到 2019 年 D2 前端論壇發佈了 “http://www.imgcook.com”，前端智能化這個詞才正式確立。

我們用智能化手段提升前端的研發效能作爲第一步，借 imgcook 的設計稿生成代碼作爲切入點，一舉徹底解決了前端切圖編寫 UI 代碼的各種一線前端工程師的部分****研發效率問題。

如果設計稿生成代碼是基礎，那麼，從我們服務的用戶：“前端工程師” 來看，生成代碼的準確性、可用性和可維護性是成敗的關鍵。通過機器視覺識別能力和深度神經網絡的理解能力、出碼規則引擎的前端 UI 代碼表達能力，利用機器代替前端工程師去 “看” 設計稿、“切圖”、“生成 UI 代碼”，從而，用識別、理解和表達能力的提升帶來了準確性、可用性和可維護性的提升。

接下去，就要擴展和豐富使用場景提升交付效率。我們把智能化能力應用到智能 UI 上，解決了個性化 UI 帶來的海量模塊和組件開發工作。應用到服務端膠水層代碼生成，替代服務端和 Node FaaS 在業務能力之上編寫具體業務邏輯。應用到自動化 UI 測試上，顯著減少了測試時間和測試投入的人力成本。

最後，向前端智能化要業務價值。我們把智能化應用到營銷活動和頻道導購業務上，藉助智能 UI 推薦算法自動生成用戶承接場景，不同程度提升業務核心指標。應用到需求生成代碼平臺 BizCook 上，建設了業務指標驅動的多角色協作業務研發平臺，讓協作在線化、編碼自動化，顯著提升業務試錯和迭代效率。應用到素材合規審覈上，解決了天貓 U 先試用的商家素材合規審覈、天合計劃流量寶商家廣告素材合規審覈，並沉澱成集團通用可配置的素材合規審覈平臺。

這一系列過程是 30 多前端在 52 個業務支撐下，利用業餘時間和加班，打造的 研發效率、交付效率、業務試錯和迭代效率 的極致生產力之路。

前端智能化的關鍵環節

2-3-1-5：

**2 個類型的業務場景：觸達用戶、**承接用戶

3 個領域：研發、交付、業務

1 個核心技術：AI 驅動的代碼生成能力

5 個關鍵環節：RunCook（把業務場景化投放至二、三環媒體進行用戶觸達）、BizCook（試錯、迭代敏捷創新用戶承接能力）、UICook（用個性化 UI 精細化用戶承接能力）、imgCook（設計生產一體化 UI 代碼自動生成）、LogicCook（PaaS 業務能力註冊發現爲基礎的邏輯代碼自動生成）、ReviewCook（自動化 Codereview 保證生成代碼的質量）。

“業務效率、交付效率、研發效率” 這些詞看起來都很好理解，但是在阿里巴巴現在體量和場景下，這些詞背後又存在着大量的難題和挑戰。以 UICook 的智能場景和智能設計爲例，1 個頁面可能包含 10+ 模塊，1 個模塊可能包含 5 個左右的組件，1 個組件會設計 20+ 樣式，1 個模塊就存在 100 次編碼、調試、測試、發佈，1 個頁面就有至少 10 x 100 = 1000 次頁面的搭建、配置、數據綁定、投放排期工作要做，而 1 次大促至少有 1000+ 頁面，而上述工作就要做 1000 x 1000 = 100w 餘次…… 針對阿里雙 11、雙十二、年貨節…… 一些列營銷活動場景，僅依賴工具在一些局部領域的優化是很難處理好的。所以，面對較常規放大上千倍的場景，很多的問題就質變成一個新領域的問題：智能化創造全新前端生產力 。這是阿里前端的機會，也是我們這些前端工程師的機會。

前端智能化的頂層設計和核心任務

上一張圖把 UI 智能化生成到應用的環節切分開了，切完後最終我們還是要聚合的。先揉碎再消化，消化後的產物叫做 “前端智能化頂層設計”，這是三年來一直在佈局並穩步推進的。

我們致力於構建能夠支撐阿里整個業務體系的 UI 智能化****資產，這是整個設計的核心。在處理和生產 UI 的背後，要有用智能化生成和智能 UI 推薦算法、智能設計生產技術升級、BizCook 和 UICook（鯨冪） 作爲直接服務業務的技術產品迭代演進作爲支撐，同時我們又要把智能 UI 生成、UI 推薦算法、智能設計系統變成通用能力和基礎技術去服務更多的****業務，讓 UI 智能化資產在各業務場景中應用的同時，以數據爲載體反向傳遞使用指標和使用情況****形成閉環，驅動前端智能化體系成熟和完善。

前端智能化的兩大核心任務

一、持續推進 UI 智能化資產建設，構建 “質量可靠、安全穩定、生產經濟、消費便捷” 的 UI 智能化資產體系。

其中，生產經濟和消費便捷是大家比較關心的問題。藉助智能化生成的 D2C 能力和 S2C 能力，構建機器生產 UI 、交互邏輯和業務邏輯的能力，降低 UI 的生產成本，是謂 “生產經濟”。今天整個阿里不同的業務發展的節奏不同、所處階段不同，遇到的問題也不一樣，所以便捷是相對的。就像齒輪一樣，要咬合的更好，才能更好地共同往前走。對於市場探索的 X 業務，“消費便捷” 的關鍵應放在開箱即用上，要最大程度降低接入和使用成本、提升接入和使用效果。對於市場擴張的常規業務，“消費便捷” 的關鍵應放在客製化能力和開放上，支撐業務在滿足複雜的用戶和業務需求時，能夠按需定製，同時，給予技術人員定製自己業務平臺和技術工程體系的機會。

智能 UI 資產

智能設計生成

智能 UI 設計模板

二、沉澱智能化技術和產品能力，賦能業務智能化到智能業務化，釋放技術及組織紅利，驅動業務增長。

智能 UI 業務定製

智能 UI 應用

方法論 + 工具 + 組織 -- 構建基本理念和落地公式

方法論：業務指標驅動的產品定義、技術生成、運營使用的業務研發模式

就像做開發一樣，任何一套框架背後還是有一套基本的思想，思想背後有一套完善的理論體系，沒有理論體系指導，我們無法在未來的複雜場景或者是在一些多變的場景中去抽象和裁剪。前端智能化技術 & 業務體系也一定有一套理論來支撐它：業務指標驅動（BizCook）、產品定義（BizCook & **鯨冪）、技術生成（P2C、D2C、S2C）、運營使用（小二工作臺）**四個部分組成。

首先，什麼是業務指標驅動（BizCook）？今天阿里有淘寶、天貓、聚划算等很多業務，業務指標定義也很多樣，即使指標是統一的，但是如果大家的業務場景都不一樣，對用戶活躍的定義理解也會不同，比如天貓 U 先的活躍要求用戶領樣品，而淘寶逛逛業務的活躍要求用戶瀏覽內容和關注等。因此，業務指標的定義需要在各自業務場景中。而驅動則不然，可統一用**聚焦（定義）、透明（傳遞）、迭代（執行）**的模式。只有目標場景化、驅動統一了才能真正實現有效的業務研發模式升級，產生化學反應裂變或者衍生出更多的商業可能性。

其次，產品定義 (BizCook & 鯨冪)。產品定義是針對核心產品要素：UI 智能化資產，把各個場景裏面，大家對該要素的各定義和理解抽象到一個共識的公約數：能夠讓每個場景中既有標準性，又能夠兼顧靈活性，體驗一致性上提供個性化。UI 智能化資產是數字化商業很重要的產品基礎設施。就消費而言，一個產品可能會有超過二十個場景，一個場景會有數十個生活時空維度，一個維度會對應數百個圈層的用戶，只有藉助 UI 智能化資產，才能把產品定義好，讓用戶在自己興趣偏好和習慣之下，體驗到數字化商業的價值。由此，技術人員就能夠和設計人員一起持續的用算法、數據資產進行融合，最終去還原我們對消費者的理解。當然，這是在安全隱私合規的前提下進行的，並且在前端智能化的端智能領域，將其規範化到統一的產品設計和定義領域去，保護用戶隱私下傳遞抽象用戶特徵和場景特徵的向量數據。

第三個是技術生成（P2C、D2C、S2C）。算法和數據在一起打造 UI 智能化資產，是爲了 Service 。不提供服務的技術，就只有成本，也感覺不到技術的價值。UI 智能化資產的供給由服務驅動，再借助各業務的技術團隊場景化、定製化落地，從而產生 UI 智能化資產的上層消費和底層供給之間的咬合。同時，從消費側收集和迴流數據，用指標驅動技術生成體系有目標且高效的迭代和成熟。

最後，是運營使用（小二工作臺）。在業務指標驅動下，**產品（產品力）、設計（設計力）和技術（業務力）**共同協作，交付的只是產品的定義。這就像面向對象編程裏，我們定義一個杯子：

交付產品定義：

class 杯子 {

init(材質、高度、直徑……『運營使用的路徑在這裏』){

材質處理 (『運營使用的結果在這裏！』）

}

func 材質處理 (材質){

if(材質 == 水晶){

1、檢查水晶庫存

2、測算水晶成本

3、……

……

}

}

}

運營使用：

『運營選品動作爲例』

new 杯子（水晶、10cm、5cm……）『運營使用的起點在這裏』

運營將產品、設計、技術圍繞業務指標共同交付的產品定義：產品的可能性，例如材質可能是玻璃、也可能是水晶，運營再根據業務指標和庫存、成本等狀況決定，這次運營動作的具體參數是什麼？

工具：產品及解決方案

有了理論之後，第二步是建立一套工具承接理論。理論很多公司都能講，如果沒有一套好的工具，去把這個理論承接，能讓這個理論延續、演進和演化，這個理論是無法落地的，所以方法論背後必須有一套工具。

組織換了、業務變了、人員離職轉崗了……，只有工具和技術能力的產品化，才能讓我們這個體系不斷地站在前人的肩膀上前進。在阿里場景裏面，通過實踐最後沉澱下來了一套基本的前端智能化工具矩陣，如下圖：

我們會用這些工具去服務阿里內部的各種業務，同時我們也會服務我們的商家和用戶，爲商家和 ISV 生態注入活力降低成本，爲用戶帶來可預期、合品味、易使用的產品。

針對雙十一等大促場景、營銷產品和頻道業務，用 UI 智能化資產統一實現 “大促日常化”：降低大促的規劃、設計、實施成本，統一實現 “日常大促化”：用豐富的場景、人貨場、個性化用戶產品提高承接效率和業務效率，把日常的頻道導購業務都變得像個 “市集”。我們還會面向阿里巴巴集團全域 APP 矩陣進行業務投放，和流量場景深度結合，提升二環和三環媒體觸達用戶的頻率和效果。藉助 UI 智能化資產和相關的工具產品體系，打造業務敏捷創新的內功，和業務一起找到自己的方向和節奏，靈活應對市場變化和競品威脅。

組織：讓前端智能化真的運轉起來

我們需要讓這些工具能夠和組織結合起來，能夠和阿里現有的環境結合起來。舉個簡單的例子，就像每年雙十一前都會進行的 “0 研發” 戰役和鯨冪在智慧會場的應用，我們希望能夠基於雙十一這個場景，讓大家熟悉這些產品、設計、生成技術和數據化運營能力的應用，從而更好的理解和消費 UI 智能化資產。通過不斷學習和運用，讓使用智能化高效、高質量和個性化解決問題成爲大家的肌肉反應，稱爲工作中自然而然的一部分。

另外，在日常業務中，藉助算法模型能力進行自動化概念的映射和翻譯，減少新概念的引入，讓業務、PD、設計師、運營小二和技術小二、質量小二都能夠在自己熟悉的概念下，共同爲業務指標負責。

除了方法論 + 工具 + 組織這三個結合起來，最終我們還需要一套體系機制，無論是業務體系、產品體系和設計體系，最有價值的部分往往都發生在交集，這個交集在方法論、工具和組織的支撐下，相互制約：任何局部創新都能夠受全局其它體系約束，又能相互賦能：任何局部創新都能夠向全局其它體系輸送價值，還能孕育化學反應：跨界、跨領域、跨體系的全局性創新。

業務、產品、設計、技術 -- 前端智能化的核心客戶

做任何事情必須要有客戶的視角，知道服務誰才知道要解決什麼問題。前端智能化的核心客戶和我們的發展階段息息相關，在初期階段，面向技術人員圍繞 “解決一線 C 端業務研發效率問題” 構建 “設計稿生成代碼” 的能力。在中後期，我們必須將技術能力賦能到業務升級爲業務能力。面向業務人員圍繞 “解決業務缺乏用戶產品抓手的問題” 構建 “透明、快速、直接干預業務” 的能力。面向 PD 圍繞 “解決業務敏捷創新和快速試錯的問題” 構建 “設計稿生成的代碼之上所見即所得的需求標註即可交付上線” 的能力。面向設計師圍繞 “解決設計規範執行難、設計創新研發成本高落地難的問題” 構建 “設計生產一體化” 的能力。

運營使用未在我們的體系內定義成核心客戶，因爲，今天圓心領導的小二工作臺，不僅完善的解決了招商、選品、投放…… 等一系列運營問題，構建了完整的數據化驅動運營的技術體系，還藉助 PU 、SOP 編排的方式，幫助業務根據自己的需要進行定製，舒文領導的 “諾亞” 藉助 “方舟” 在多年大促營銷活動上沉澱的經驗，進一步降低了小二工作臺的使用成本，我們只需要在前端智能化賦能業務的過程中引入 “諾亞” 或其他 PU、SOP 能力即可服務好運營。

質量保障未在我們的體系內定義成核心客戶，因爲，今天清靈領導的質量保證體系在前端智能化初期就和我們在深度合作，從 ATS 自動化測試模塊質量，到 TMQ 基於機器視覺和算法的自動化測試，都已經做得非常完善，並且，底層的技術體系和上層的開放能力都足以支撐我們 “開箱即用”，保證兩套體系的功能和體驗的一致性，可方便的支撐好質量保障的同學進行質量驗收和質量監控。

技術人員：C 端業務研發效率問題

對於我們阿里來講，技術人員是一個巨大的羣體，C 端業務又是一個面向終端用戶且複雜多變的場景，跨平臺、需求變更、個性化是這些複雜多變場景的核心問題，他們共同要求 “有一種消除重複勞動的技術”，否則，只能靠技術人員自身來填這個大坑。對於技術人員來說，跨平臺、需求變更、個性化對技術而言並沒有太大的挑戰和創新，只是時間成本的問題：適配不同的平臺、實現變更的需求、逐個開發不同的個性化承接產品，這些就是亟待消除的 “重複勞動”。

只有深入研究跨平臺的業務研發問題，我們才能準確的定義 RunCook 的功能，才能解決業務研發過程中對宿主環境業務能力的適配和降級問題。只有深入研究需求變更，我們才能準確定義 BizCook、imgCook、LogicCook 的功能，才能通過 NLP 的算法模型理解業務定義的指標如何被 PD 描述成需求、設計師又如何用設計語言來表達 PD 的需求、設計稿如何藉助 imgCook 生成 UI 和交互邏輯、UI 的內容及狀態的變化如何藉助 LogicCook 從 PaaS 上獲取並實例化成 Node FaaS 的膠水層代碼掛載在 UI 和交互邏輯之上。深入研究消費者，我們才能準確定義 UICook 和鯨冪的功能，才能通過智能設計生產一體化、代碼生成能力降低一線業務研發人員爲不同圈層用戶開發產品功能的成本，給消費者帶來極致的產品體驗。

業務人員

小芃在介紹數據中臺的時候說：「 以觀星臺舉例，逍遙子可以通過觀星臺看到全集團宏觀的業務治理，這是一個最大的頂層的節點。再往下這個子節點，就是各個業務總裁和業務的矩陣，下面每個業務有自己業務數據的邏輯和數據決策的體系。再往下就是每一次的活動，或是一些節點，基本上形成了一個決策體系。我對這個觀點深以爲然，今天決策體系化才能讓業務形成戰鬥力，然而，卻有一些問題會阻礙這種戰鬥力的形成：執行。」

在技術產品裏有一個生動的比喻：P9 的戰略、P8 的規劃、P7 的設計、P5 的執行，最後，一個好的思想和理論沒有能夠形成好的技術產品。爲什麼不能是 P9 的戰略、P8 的規劃、設計和執行呢？因爲，信息在傳遞的時候會有損耗。通俗的理解就是：張大媽說你和女同學放學一起回家，李大嬸說你和女同學談戀愛，王大爺說你和女同學結婚了。信息論裏研究信息的損耗，因爲信號在介質中傳遞的時候會受到干擾，電信號在取值範圍上下的波動未達到信號電壓要求，從而導致信息的一些編碼丟失，李大嬸和王大爺自身的偏見就是導致信息損耗的干擾。下面，藉助一些信息論裏的知識談談服務業務人員過程中如何抗干擾？

優化業務指標編碼

談到信息論，就離不開編碼。談到信息論就離不開傳遞信息，傳遞信息的過程需要對信息進行編碼，而如何用最少的編碼表示所要傳遞的信息就是我們要研究的目標了。

假設兩地互相通信，兩地之間一直在傳遞 A，B，C，D 四類消息，那應該要選擇什麼樣的編碼方式才能儘可能少的使用資源呢？如果這四類消息的出現是等概率的，都爲四分之一，那麼肯定應該採用等編碼方式，也就是

這樣就能達到最優的編碼方式，平均編碼長度爲 。

但是，如果四類消息出現的概率不同呢？例如 A 消息出現的概率是二分之一，B 是四分之一，C 是八分之一，D 是八分之一，那應該怎樣編碼呢？直覺告訴我們，爲了使平均編碼長度儘可能小，出現概率高的 A 消息應該使用短編碼，出現概率低的 C ，D 消息應該使用長編碼。與等長編碼相比，這樣的編碼方式叫做變長編碼，它的效果更好，例如採用下表所示的編碼（其實這是最優編碼）

平均編碼長度爲 

顯然要優於等長編碼。

業務同學決策依據的數據指標有大量的歧義和冗餘，這就需要有一套編碼機制有效的對業務指標進行編碼，保證在決策信息傳遞的過程中更精確、有效，因爲，信息冗餘越多損耗的概率就越大，編碼的有效性越差，編碼的冗餘信息就越多。我們在 BizCook 上重新構建 C 端業務研發的指標體系和其編碼方式，對指標包含的信息進行有效編碼，是決策信息有效傳遞的第一步。

度量業務指標損耗

若現在還有一種消息序列的概率分佈滿足 q 分佈，但是它仍然使用 p 分佈的最優編碼方式，那麼它的平均編碼長度即爲

其中被稱爲 q 分佈相對於 p 分佈的交叉熵（Cross Entropy），它衡量了 q 分佈使用 p 分佈的最優編碼方式時的平均編碼長度。

交叉熵不是對稱的，即。交叉熵的意義在於它給我們提供了一種衡量兩個分佈的不同程度的方式。兩個分佈 p 和 q 的差異越大，交叉熵就比大的越多，如圖

它們的不同的大小爲，這在信息論中被稱爲 KL 散度（Kullback-Leibler Divergence），它滿足。

KL 散度可以看作爲兩個分佈之間的距離，也可以說是可以衡量兩個分佈的不同程度。

對於業務的同學，圍繞自己兩三個核心目標層層拆解下去的業務指標也有 q 和 p 的分佈，我們可以在 BizCook 上根據交叉熵來衡量實際：產品、設計和技術在承接這些指標時候的偏差程度，也可以在 BizCook 上利用 KL 散度來判斷決策指標在承接過程中的信息損耗。

分析業務指標關聯

和單變量相同，如果有兩個變量 X，Y，我們可以計算它們的聯合熵（Joint Entropy）

當我們事先已經知道 Y 的分佈，我們可以計算條件熵（Conditional Entropy）

X 與 Y 變量之間可能共享某些信息，我們可以把信息熵想象成一個信息條，如下圖：

從中可以看出，單變量的信息熵 H（x）(或 H（Y）) 一般比多變量信息熵

H（X，Y）要小。如果把條件熵也放進來，那麼可以從信息條更清晰的看出它們之間的關係

可以看出

更細一點，我們把 H(X) 與 H(Y) 重疊的部分定義爲 X 與 Y 的互信息（Mutual Entropy），記作 I(X,Y)，則 。互信息代表了 X 中包含的有關於 Y 的信息（或相反）。

將 X 與 Y 不重疊的信息定義爲差異信息（Variation of Information），記爲

V(X,Y)，則

差異信息可以衡量變量 X 與 Y 的差距，若 V(X,Y) 爲 0，就意味着只要知道一個變量，就知道另一個變量的所有信息。隨着 V(X,Y) 的增大，也就意味着 X 與 Y 更不相關。形象化的表示可以從下圖看出

對於業務的同學來說，可以很容易通過互信息來衡量：產品、設計、技術承接自己的決策時，其指標和自己目標之間的關聯度，BizCook 可以藉助互信息和差異信息來進行度量，從而幫助業務同學解決目標落地執行的偏離問題。

由於業務決策被編碼成業務指標，業務生產指標被編碼成產品指標、設計指標、技術指標，藉助前端智能化的生成技術體系，決策和執行將前所未有的統一，而不再是割裂的，由此，BizCook 解決了 “張大媽說你和女同學放學一起回家，李大嬸說你和女同學談戀愛，王大爺說你和女同學結婚了。” 這個信息損耗的問題。

產品和設計人員

和 B 端業務不同，在 C 端業務裏，因爲大部分情況設計直接決定了 UI 的視覺和交互，UI 的視覺和交互又是 C 端業務非常核心的部分，因此，產品和設計多數情況下是共同定義產品的功能的，可以放在一起說。

產品定義產品的工具是：需求文檔，設計定義產品的工具是：設計稿、交互稿，這兩者都是在描述：什麼用戶？在什麼場景？看到什麼？做什麼？只是，需求文檔在視覺方面更加抽象、功能層面更加具體，而設計稿、交互稿在視覺方面更加具體、功能層面更加抽象，結果，PD 和設計師一合計，乾脆合一起吧！於是，平常在生產過程中拿到的設計稿大多是醬紫的：

這個視覺和功能二合一的描述方式，怎一個 “贊” 字了得？簡單清晰，把設計和產品功能完美的融合在一起，一目瞭然。既然 PD 和設計師都喜歡這樣的產品定義描述方式，我們何不在前端智能化領域吸收借鑑一下呢？於是，有了 “基於設計稿生成代碼所見即所得的產品定義” 能力在 BizCook 上誕生，在繼承了 imgCook 設計稿生成代碼的基礎上，擴展了 LogicCook 的業務邏輯代碼生成和推薦，讓 PD 和設計師在定義產品的過程中就完成了 MVP 並可以上線灰度進行小批量產品驗證。

可以從上圖看到，左側預覽區域的內容都是 imgCook 通過設計稿生成的，PD 可以在這個基礎上選擇一個區塊去定義這個區塊承接什麼業務？完成什麼關聯業務指標？功能上有什麼約束？要怎樣提供個性化服務？…… 從定義業務到子業務、到頁面、再到一個區塊層層遞進，把定義產品的過程和業務決策、業務指標無縫連接在一起。

所以，BizCook 服務產品和設計這兩個核心客戶的時候，首要原則就是符合 PD 和設計師的工作習慣，用 PD 和設計師熟悉的概念描述產品的定義和業務的功能，不額外引入新概念，也堅決不用晦澀難懂的技術概念。這樣，不僅能夠讓產品定義 “高度保真”，還能夠極大將降低 PD 和設計師理解和使用的成本。

總結和展望

從最初服務一線研發人員，到後來的服務於產品和設計人員，再到未來服務於業務人員，這個路線背後的思考是：在技術領域圍繞效率創新，必須逐步過渡到生產，再進入業務領域進行昇華。脫離業務、生產單純在技術領域裏兜兜轉轉，是制約大部分技術人向上發展的王屋和太行。

仰望星空再回到現實裏腳踏實地，必須清醒認識到：技術向生產乃至業務領域過渡是一個複雜且漫長的過程。進入生產領域需要大局觀和架構能力，進入業務領域需要全局觀和商業能力，不去改變和提升自己，終是畫虎畫皮難畫骨，形似而神不在。

大部分同仁，在聽過、見過甚至部分實踐過後，仍會覺得雲裏霧裏，初時，覺得頭頭是道，做時，覺得千頭萬緒。總的來說，我認爲缺的是內觀、俯察。所謂內觀，要求我們向自己找原因，真正有價值的東西是方案和成果背後的思考，是無法通過表象所感應、知覺、理解的，這就像兩個音叉，敲響一個另一個諧振的原因是這兩個音叉的質地一致，我們在無法跟別人的觀點產生共鳴的大部分情況是自己的質地無法和別人觀點背後的質地一致而已，去修煉自己即可。所謂俯察，要求我們向腳下之路找原因，不要好大喜功、好高騖遠，要清楚自己邁出的每一步：輕了？重了？快了？慢了？甚至要進行逆察，不斷審視過去的每一步。

今天的前端智能化，在技術上有點兒小成績，同時也有很多問題。今天的生產領域、業務領域拓展嘗試，在結果上有點兒小業務效果，同時也有很多過程上乃至源頭能力上的缺失和不足。這就需要我們仰觀俯察，既要看到大方向、大趨勢、大戰略，又要看到小閉環、小問題、小細節。從大處着眼、小處着手，把 UI 智能化資產並前端智能化易學、易用落到實處，解決一線業務研發過程中的實際問題。

爲此，我們把未來的發展具象化到一些大方向、大趨勢、大戰略上，同時，拆解到類似 “開箱即用的算法”、“業務上取得實際效果”…… 等一系列小閉環、小問題、小細節中去。在教授（展炎）的指導下，新財年裏設立“用戶體驗升級” 這個主題，來聚焦我們要解決的問題，把前端智能化落到實處：

由此，設定我們的 OKR （還是討論版）去約束我們的發展方向和發展目標，給出一個清晰明確的路徑：

期望在新的一年，我們能夠建設好我們的數據、標籤、算法、物料…… UI 智能化資產，還能夠繼續把我們的生產能力進行升級，同時，藉助 PipCook 降低前端應用門檻，讓前端智能化對阿里集團每個前端普惠和開放。同時，也期望每個參與前端智能化的同仁，都能夠在自己的業務場景中，用自己的慧眼去發現更多因機器學習、算法所帶來的技術、工程乃至業務的可能性，用自己的智慧並前端智能化一起，給業務創造更多屬於阿里前端的價值！共勉！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6PHxZb7x7aHTWe4HZHGLWg

猜你喜歡