作者 | 甄子
前端智能化曆時三年有餘，從最初被誤解為“用 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 智能化資産的上層消費和底層供給之間的咬合。同時，從消費側收集和回流資料，用名額驅動技術生成體系有目标且高效的疊代和成熟。
最後，是營運使用（小二工作台）。在業務名額驅動下，産品（産品力）、設計（設計力）和技術（業務力）共同協作，傳遞的隻是産品的定義。這就像面向對象程式設計裡，我們定義一個杯子：
傳遞産品定義：
營運使用：
營運将産品、設計、技術圍繞業務名額共同傳遞的産品定義：産品的可能性，例如材質可能是玻璃、也可能是水晶，營運再根據業務名額和庫存、成本等狀況決定，這次營運動作的具體參數是什麼？
工具：産品及解決方案
有了理論之後，第二步是建立一套工具承接理論。理論很多公司都能講，如果沒有一套好的工具，去把這個理論承接，能讓這個理論延續、演進和演化，這個理論是無法落地的，是以方法論背後必須有一套工具。
組織換了、業務變了、人員離職轉崗了……，隻有工具和技術能力的産品化，才能讓我們這個體系不斷地站在前人的肩膀上前進。在阿裡場景裡面，通過實踐最後沉澱下來了一套基本的前端智能化工具矩陣，如下圖：
我們會用這些工具去服務阿裡内部的各種業務，同時我們也會服務我們的商家和使用者，為商家和 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 （還是讨論版）去限制我們的發展方向和發展目标，給出一個清晰明确的路徑：
- 面向場景和人群的視覺設計智能化
KR1：基于 UI 互動的場景、人群标簽擴充2~3倍，準确率達到 80% 以上
KR2：基于 UI 互動的場景、人群了解算法自動化生成使用者承接 UI
KR3：利用設計中台打通智能 UI 和智能設計兩大體系，實作高品質方案自動化生成
- 人機互動方式的智能化
KR1：端側模型和服務端算法模型能力協力實作 UI 的個性化呈現，提升使用者粘性
KR2：基于算法對使用者的了解，以使用者任務驅動 UI 組裝和互動路徑決策，提升使用者互動的有效性
KR3：用端側算法模型能力開拓新的使用者互動方式和使用者承接場景，用新奇特智能人機互動驅動使用者體量增長
- 降低面向上述場景下的前端應用門檻
KR1：達成智能 UI 生成能力和智能 UI 推薦算法、端智能模型優化和下發的開箱即用
KR2：用 PipCook 降低前端學習、應用、部署機器學習算法的成本
KR3：外派專家輔導和共建的方式，融合前端算法課程教育訓練，帶動集團前端應用算法在業務中創新
期望在新的一年，我們能夠建設好我們的資料、标簽、算法、物料…… UI 智能化資産，還能夠繼續把我們的生産能力進行更新，同時，借助 PipCook 降低前端應用門檻，讓前端智能化對阿裡集團每個前端普惠和開放。同時，也期望每個參與前端智能化的同仁，都能夠在自己的業務場景中，用自己的慧眼去發現更多因機器學習、算法所帶來的技術、工程乃至業務的可能性，用自己的智慧并前端智能化一起，給業務創造更多屬于阿裡前端的價值！共勉！