每年大促前一個月都是奮戰與忙碌的時節，不僅業務上在不斷疊代創新，技術上也在推陳出新，需求推動技術變革是一個正向演進的過程，但革新是需要成本的，每一次技術與标準的革新都帶來一場翻天覆地的大改造。如果我們能将需求與産物劃上等号：需求即代碼，那麼我們隻要找到兩者之間的關聯關系即可通過需求自動産出代碼了，那豈不是樂哉美哉(diao zha tian le)。
本文主要圍繞自動化生成代碼的目标，講述我們在這一過程中的所思所想，以及我們在618期間的階段成果實踐。
前言
自然語言是及其抽象且強依賴上下文的，其整體表現為不精準，而代碼是多元具象且有強相關性的，其整體要求為精準。這樣兩個不同概念的東西怎麼找到他們之間的相關性呢？
需求和代碼之間沒有一個标準的轉換模式，通過标準轉換器來實作是不可能的，唯一可以采用的方案就是運用機器學習，并通過大量的樣本來增強之間的關聯性。但正如前面所提到的，代碼和需求都不是對局部的簡單了解就能完成的，而是對一個整體的了解，是以對每一句話的了解都不能是獨立存在的，而是互相交織在一起的，這就增高了對整個需要了解的緯度，據鄙人所了解這個難度是非常大的。
但有時一個問題的難度大小也是由當下技術邊界所決定的，比如3D列印的出現，就徹底将需求和産出物劃上了等号，過去很多繁瑣的工序都可以舍棄了，隻需要一種實作方式就能讓人們在家就可以下載下傳設計稿并自己完成産品的實作。
當然3D列印的出現并不能解決代碼自動生成的問題，3D列印隻是在生産過程中運用了統一化的解決思路，而從需求到産出的過程依舊需要依靠設計圖來對産出物的各項尺标資料做限制。是以設計稿的标準化一定是統一化的前提，3D列印更像是一個标準化出碼的機器，而指揮這台機器如何生産的正式标準化下的設計稿，是以對我們來說需要思考兩個問題：
1、自然表達的需求如何轉變為标準化的“設計語言”
2、如何通過标準化的設計語言産出代碼
我把第二個問題看作和3D列印一樣，是一個标準化的問題，而有了标準化的設計語言再轉到AST是很簡單的事情，困難的是第一個問題，如何将需求轉為标準化的設計語言。這是我們需要核心思考的問題，并且這個課題對于運用機器學習來解決也同樣是非常困難的，那我們首先是否應該來了解一下目前機器學習的邊界呢，并怎樣拆分成具體目标去實作它。
聊聊AI
當我最早了解人工智能的時候是這部著名的《AI》。
電影中的小男孩大衛是個機器人，但是他被賦予了情感，他曆經萬險，為了一個注定幻滅的結局。＂等我變成了真的小男孩，媽媽就會帶我回家了＂
“當人工智能開始尋求自我認同時，他就已經和人類沒有差別了”。如果這個世界是虛拟的，造物主一定不會讓我們發現絲毫，這也是當時這部電影令人感同身受最恸哭内心的部分。這也正驗證了人與機器的本質差別，即是否能感受自我的存在。
回到當下，現實的AI 并不像電影裡的那樣，既沒有情感也沒有邏輯，更沒有自我意識。比如知名的AI AlphaGo，從技術上講，它之是以能夠擊敗人類的圍棋高手，是因為它具有由“小”變“大”的能力，人類将十幾萬的圍棋博弈輸入到它的“大腦”中，然後它就會進行自我“對戰”，進而産生幾百萬甚至幾千萬的圍棋博弈或者叫做棋譜，是以它在應付人類的圍棋博弈時，就能夠“從容不迫”。但他産生的模型的過程不能舉一反三，當改變棋盤的尺度或改變規則時AI就再無法做出有效應對了，它必須得進行重新的學習，而人類隻需要通過了解規則即可做出應對改變。
與AI 相比，人類似乎能夠解釋和了解其所生活的環境，而計算機隻是一台從事比對工作的機器。哲學家約翰·塞爾（John Searle）很久以前就通過他的“中文房間”思維實驗（Chinese Room thought experiment）指出了這種差異。在本實驗中，他将自己關在密閉的房間中。
這個實驗是這樣設計的：Searle 他既不會說也聽不懂中文，但是在這個房間裡有一本很大的手冊，裡面有一系列的假設陳述。通過門上的一個插槽，他可以接收漢字，查找手冊中的字元串，并找到要通過插槽送出的字元串。顯然，塞爾可能會讓房間外的人相信他真的懂中文，但事實上他并不懂，他隻是在比對符号而已。
雖然從外部無法區分房内的人到底是否“懂得”中文，但是實質上房内的人是不懂中文的。是以以“是否無法區分‘懂得中文’和‘表現得完全像懂得中文’這兩個現象”而将其兩者認為是等同的，這個觀點是不能夠成立的。
AI 并不神奇，它預測的基礎甚至和《易經》和 中醫理論 都沒有太大差別，如果要有，我覺得差在了靈魂和哲學的思考上。而對我們來說AI 是否真的能産生情感還是是否能真正能夠了解處理資訊，對我們來說都不是重要的，我們隻需要他看起來可以做到準确預測即可，并不需要一個真正的人工智能。
用傳統機器學習進行模組化預測，其本質更接近于搜尋，這是一個看起來會比較傻的弱人工智能，并且所有的預置算法都是由人類來寫的，AI 隻是一個按算法規則來進行分類/聚類的機器 ，比如對單個圖形或句子進行預測，這些資料都是相對結構化的資料，而對于整篇文章或全幅大圖做分析則需要強人工智能來完成，一般我們會用到深度學習，并需要使用多層處理單元的巨大神經網絡利用強大計算能力和改進的訓練技術來學習大量資料中的複雜模式。原理是計算機在學習特定問題時，需要大量輸入這個問題相關的學習材料也就是資料，然後在計算機通過算法和模型來建構對這個具體問題的認知，也就是總結出一個規律，那麼在以後遇到相似問題時，計算機會把收集的資料轉成特征值，如果這個特征值符合這前面規律裡面的特征值，那麼這個事物、行為或者模式，就可以被識别出來。
背景
聊完AI，我們回歸正題，說一下什麼是P2C以及為什麼要做P2C？
P2C即通過 prd 自動産出 code，即是我們開頭所講的需求即代碼的終極目标。
講完P2C是啥，我們再回過頭來聊聊我們為什麼要做P2C？
在開發鍊路中耗時較長的兩個環節是「溝通成本」和「編碼成本」，「溝通」一般是需求明确的過程，一般展現在各種需求評審上。而前端的「開發」成本則主要可看作兩個部分：視圖代碼與邏輯代碼兩個部分的開發工作。目前我們團隊的 D2C産品（imgcook 設計稿到代碼） 已經能夠幫我們準确的生成大部分的視覺代碼了，甚至還可以分析出部分簡單的的業務代碼，是以對前端開發來說在開發中的成本主要花在非通用的邏輯表達部分，即粘合劑。
對于這些“粘合劑”邏輯，在産品的prd 中我們可以找到準确答案，但有時産品的prd 是不夠結構化的，資訊丢失也比較嚴重，這非常不利于機器學習進行學習和了解。是以我們需要一個平台來規範産品的需求，使産品能夠按照要求進行結構化的錄入。這就是我們做P2C 的初衷。、
挑戰
前面我們對AI 的能力已經有所知之了，而現在我們要怎樣一步步達成我們的終極目的 “Auto Code”呢？
我們知道AI 目前還不能夠像人類一樣來分析資料關系，而大部分prd 都是以文本為主的非結構化資訊，這時候我們就需要利用 NLP技術對資訊進行處理并根據意圖翻譯為可進行轉化的邏輯描述DSL，是以我們通過相對具有結構化文檔的方式來進行需求的收集，進而簡化機器學習的難度。
雖然我們可以将原本海量資訊的大文檔進行結構化的資訊表達，使局部資訊清晰可解，但此降維操作也産生了新問題，就是關鍵點與關鍵點之間的聯系變得更弱了。
我們的初衷是希望能降低需求溝通成本，并在此過程中積累智能化出碼的能力，是以我們隻是設計了簡單的結構化收集方式，并不強制改變pd原有的需求錄入方式，是以需求文檔内容有着很高的不确定性，不僅存在上下文關系依賴，還有很多未描述的知識依賴，并且内容也都是允許其自由組合天馬行空。
知乎有一篇
買蘋果的例子，很好的诠釋了一個簡單的需求背後所牽涉的複雜的關聯關系。是以可見單純的通過需求來推導出産出物是非常難的工作。既然如此為什麼不直接走向另一個極端：嚴格的結構化需求錄入呢？雖然嚴格的結構化資訊錄入可以幫助更清晰的将一個開域問題收攏回一個閉域問題，但是會讓需求産生的過程變得更困難更具專業化，這和我們服務pd 更好的進行需求錄入的初衷是相違背的，另外我們也不希望通過标準化的方式去限制業務的創新。
是以如何既能讓 pd 錄入需求的工作變得簡單，又用能借此發展我們的“Auto Code”事業，是我們最大的一個難題。另外對于整個出碼目标的技術鍊路我覺得目前也存在兩個難點：
1、擷取大量自然語言意圖分析的訓練樣本：對于pd的同一個需求可以用一千個不同的句子來表達，同樣一個需求表達也可以對應一千種實作方式。要想将自然語言的需求描述同實際産品表達進行準确關聯需要對大量的樣本資料進行學些
2、将所有自然語言邏輯使用統一的DSL描述：如開篇提到的3d列印，統一化的設計稿是實作轉換的基石，是以一套描述需求的标準化DSL是必不可少的。
推導
既要讓pd 錄入需求時能錄入的舒服，又得要求能按需出碼，似乎兩者是沖突的，但是困難也都不可能是一朝就能解決掉的。
是以我們打算分步驟實作目标，首先我認為短時間對需求的結構化資訊分析還很難達到從局部到整體的突破，文本的靈活性也會帶來諸多問題，比如子產品資訊的增删改造成的資訊錯位，是以我們覺得第一步要從以P2C為核心出碼的邏輯變為以D2C（即Design2Code - imgcook），因為視覺是産出是最終産出物比較接近終态的一個階段，通過視覺我們将會更容易分析缺失部分的内容，然後結合P2C内容從中尋找補全的關鍵資訊，比如一個視圖是否是ScrollView 單從視覺上很難辨認，需要結合從prd 中擷取的資訊，甚至prd 中沒有較長的描述時還需要跟俊産品屬性進行分析，例如這是一個音樂播放器的界面，那麼其中應該包含什麼功能組成，哪些功能組成一定會是ScrollView，這就需要一些知識依賴的輸入，而這些寶貴資料資産都是需要腳踏實地不斷積累的。
我覺的D2C和P2C的結合一定是1+1>2的，對于D2C視覺出碼有了知識依賴做背景，對于視覺稿的整體判斷及組成可以有了很好的依據，另外P2C也能夠基于準确的視覺做精準的邏輯補充。是以以視覺稿為主導出碼，以prd為輔助出碼的思想浮出水面。
即我們第一階段重修了目标：将原本的 AutoCode 目标先降低為 NoCode = 通用邏輯元件 + ProCode(AI)目标。
這個過程通俗來講就是 通用元件 + 配置資訊 的模式，配置資訊即 ProCode 的部分，該部分即為需要 AI 自動産出的内容。是以想要完成自動出碼，就需要對 ProCode 的部分進行樣本制造和監督學習。
我們來總結一下我們的三步走計劃：
1、需求的結構化收集 （為了降低NLP的分析難度）
2、創造結構化需求到标準邏輯表達的樣本（為機器學習ProCode部分提供充足樣本）
3、通過機器學習對樣本進行學習，以達到AutoCode的目标（長期目标）
即我們需建立要兩個平台，我們稱之為P2C 的 2.0 代 和 1.0 代。P2C 1.0 負責打标需求資料，并為 2.0的智能出碼提供龐大準确的資料。而 P2C 2.0則主要進行需求的結構化收集并與1.0 的樣本進行關聯學習，訓練出碼模型，最終達到創作和自動完成需求的目的。
兩個平台所代表的關鍵詞分别是：
- P2C1.0：精确收集，精确産出
- P2C2.0: 開放收集，創新産出
那麼精确收集樣本就成為我們 P2C 1.0 的主要工作方向。
打标樣本一定要從實踐出發，并能在該階段幫助需求真實的進行産出，即我們提供的打标平台能真實的完成業務需求，是以我們決定開發一個可視化編排的平台，通過該平台來收集樣本資料，并且可以順手把需求也消化掉。
那麼問題來了，這麼多的樣本打标的工作到底由誰來完成呢？
我們通過調研發現營運的角色在可視化編排方向上，是有着非常高契合度的。為什麼呢？其一，營運都具備子產品搭建的能力。其二，很多營運的需求都不一定有機會能夠落地，主要原因是開發資源不足導緻的，這也是多年來存在的業務與技術沖突，前端這十年來一直朝着工程化、規範化、子產品化的方向發展，本意是為了更有效的重用業務能力以達到解放生産力，而産品卻一直在朝着豐富化、精細化的方式來運作，各個業務方不再是單單為了滿足功能訴求而更講求的是使用者心智。最終緻使現在對一個個性化需求的提出往往是用一個标準化方案來落地的。當業務方為資源不足妥協時，其業務整體感官也會越來越平庸化、趨同化，最終導緻産品對使用者的心智弱化。
是以對于營運的訴求是希望能将創新和業務思考帶入到自己的産品中，而不是簡單的拆解為一個個的标準實作。如何拉大與競争對手的營運差異、互動差異、創新差異、視覺差異才是對于營運真正的核心價值。
在AI 的介紹篇中我們講了對于複雜的邏輯關系我們依然可以采用抽象的元件化來實作，而這部分實作對比傳統搭建體系的元件顆粒度更細，傳統搭建一般是對子產品的自定義配置，而在我們的編排體系裡最小的元件應該是原子化的不可再被拆解的，比如一個Image 元件，而對元件的配置可以是一段編排好的邏輯實作，是以它能有着同代碼一樣的絕對靈活性。
拆解
在前面3D列印的内容中我們提到，自動化統一化生産的前提一定是要有一個标準化的表達做支撐的，這個中間 DSL該如何設計才能承載住全量的需求内容呢？另外通過什麼樣的方式可以讓營運能接受和了解這部分的邏輯編排？
1、首先我們解決的問題一定是有邊界的是處在一個業務領域的，并在這個業務域下進行分析。是以我們分析了一下我們最常見的業務形态-子產品。而據統計“相同業務能力，不同技術實作”的子產品在整個天馬體系中的占比非常的高，單單拿通用商品坑來看就有上千個，而這些子產品大部分都是相同的邏輯實作，也有很多是處于不同時期的技術産品。
2、一個子產品在前端的開發設計裡，大概可以分為4部分，通用元件，通用Action，視覺代碼，驅動邏輯。
3、我們可以看到視覺和通用元件以及Action都是已經有了的，變動周期比較低。而驅動邏輯部分是是業務中的主要實作邏輯，如何讓這部分邏輯能讓營運進行産出呢？
4、首先我們将這部分能力進行一個拆解，我們得出一個初步的結構，就是由 運算符 + 表達式 + 基礎action + pipeline 組成的表達結構，這個表達也可以組成一個新的action，再加上trigger，整體就完成一個workflow的能力了。
new Expression = Variable + Operator + Expression + Pipeline
new Action = Expression + Action
Workflow = Action + Expression + Trigger
業務子產品的四個部分中，驅動邏輯就是我們主要核心産出的内容，根據我們的經驗這部分ProCode 大部分都是表達式 Expression 内容。是以我們隻要能讓營運能夠自主的完成 ProCode 部分的編排即可進階定制需求的産出物。
讓營運完成所有的ProCode 也顯然是不現實的，但是對于IFTTT 這種簡單的邏輯表達，隻要将這部分内容的表達可以使用更接近自然語言的表達方式，自然會降低整個的了解難度。
驗證
為了驗證我們的拆解過程，我們把pmod 分組下的9千多個倉庫進行一個拆解分析，發現平均每個子產品都有邏輯表達 52.6 個，函數表達 37.55 個， if 語句 35.5 個，這三大部分實作是符合我們的拆解預期的。這部分的邏輯大部分都是可以用IFTTT 的模型套用。
而一個複雜的子產品，光有IFTTT 是不夠的，邏輯的表達是具有很強的依賴上下文結構的，但是為了降低整體的複雜度，我們需要對邏輯進行拍平表述，對拍平後的邏輯我設計了一套 StateLink的工作流管理庫，這裡就不詳細介紹了。
最後我們通過一個 When + Then + Trigger 三元素的DSL就能描述我們所有的業務邏輯部分了。這個DSL也為我們2.0 版的出碼提前做好了準備，同時也能應對因技術更新而導緻子產品需要重新開發的尴尬。
為了讓營運能夠用得懂用的輕松，我們采取了中文編排的方式，即首先根據選取的視覺對象進行一些具象的操作表達。
為什麼我們決定采用中文編排呢？中文編排是怎樣一個編排方案呢？
我們将pd需求的一句可以拆分為上圖這樣的表達，對于使用者隻需要順着決策樹表達自己的意圖即可，類似于輸入法，當我們輸入一句話的時候，輸入法通過預測詞可以表達所有的表達意圖，比如輸入“我”，那麼一定能夠枚舉“我們”、“我的”、“我..”等詞并可以一直預測下去，而每個詞的預測都是一個有限的枚舉，同樣pd在描述一個需求時我們也可以根據文法和目的預測出所有的可能項。
現狀
我們将常用的邏輯表達拆解為中文關鍵詞，通過關鍵詞關系可以讓營運通過編排一句話的形式來表達事物的邏輯關系。
我們目前已初步完成了第一個版本的營運邏輯編排平台，通過該平台可以先讓營運能夠進來滿足一些簡單的需求。
營運主要通過可視化的方式對元素上的邏輯進行中文關鍵詞表達的編排
案例
“爆款來了”會場中的6個子產品，由營運自行編排釋出上線。
未來
雖然人工智能目前還有很多的不足和局限性，但随着深度學習的不斷進化，我相信從需求了解到需求實作全過程的自動化會離我們越來越近。
我相信未來不僅可以實作從需求到代碼的智能生産，也将會從智能生産覆寫到智能視覺、智能測試、智能營運的全鍊路智能場景。
就像我們的大廚，一開始是需要人工切菜人工炒菜，後來是人工按菜單備料再由機器輔助炒菜，再然後是直接輸入菜單機器就能自動根據菜單備料和炒菜，而未來隻要描述想吃什麼口味就能自動做出符合使用者的菜。
P2C的未來就是将過程描述簡化為目标描述，一個需求隻需要表達訴求和目标而不再需要描述詳細的生産過程及規則，隻需簡單的幾句話我們就能夠知道使用者想要什麼該産生什麼樣的傳遞物了，這就是我們未來的“智能大廚”。
頻道與D2C智能 F(x) 團隊
我們是阿裡巴巴-淘系技術部-頻道與D2C智能 F(x) 團隊，緻力于前端智能化領域的探索和實踐，賦能淘寶、天貓、聚劃算等日常與大促（如雙 11 ）業務，是淘系前端智能化實踐的領路人，也是阿裡經濟體前端委員會智能化方向的核心團隊。目前團隊有較多高校和海外背景的技術小二，專業領域涉及前端、算法、全棧等。我們在 D2C（Design to Code） 領域開放了
Imgcook平台，在逐漸釋放阿裡生态的前端生産力；我們也與 Google 的 tensorflow 團隊保持長線合作，基于 tfjs-node 之上，開源了我們的前端算法工程架構
Pipcook，在引領前端行業向智能化時代邁進。
既然最後打算放個招聘貼，那麼對于你一定想知道的是關于老闆的故事，那麼我就簡單放上一些和老闆相關的近期活動吧：
1、第十三屆D2前端技術論壇
- 時間：2019年1月
- 事件：第十三屆D2前端技術論壇舉辦
描述：正式開放 imgcook.com 向社群介紹阿裡經濟體前端委員會智能化方向。
2、QCon 10年前端技術分享
- 時間：2019年5月
- 事件：QCon 10年前端技術分享
描述：第一次公布 imgcook.com 背後的工程技術體系，通過實踐過程詳細揭示一路上的坎坷、挫折和我們的堅持與應對，并第一次公布 Pipcook 将開源的計劃。
3、在美國矽谷山景城 Building 41 Tensorflow總部完成合作談判
- 時間：2019年8月
- 事件：在美國矽谷山景城 Building 41 Tensorflow總部完成合作談判
描述：向Google 的Tensorflow.js 團隊介紹 D2C 的研究和實踐成果，得到Tensorflow.js團隊的一緻好評，後Tensorflow.js團隊親赴西溪園區交流，雙方在推動前端智能化方向上達成戰略合作。
團隊照片（第一張是我們帥氣的老闆）
最後，如果你對智能出碼有興趣并想成為我們的同路人請投遞履歷到
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~