作者 | 狼叔、卓風
點選檢視視訊
大家好，我們是來自阿裡巴巴淘系技術部的狼叔、卓風。感謝 D2 組委會，讓我們有機會在這裡分享，關于《前端智能化實踐—— P2C 從需求文檔生成代碼》。
狼叔（上圖左），Node.js 技術布道者，Node 全棧公衆号營運者，曾就職于去哪兒、新浪、網秦，做過前端、後端、資料分析，是一名全棧技術的實踐者。已出版《狼書(卷1) 更了不起的 Node.js》《狼書(卷2) Node.js Web 應用開發》。入職阿裡的三年時間，主要是在優酷 PC/H5 端從 0 到 1 的落地 Node.js 全棧，使用 SSR 對 Web 頁面進行優化和重構，建設 SSR 應用的容災、釋出、灰階等能力，是集團内第一大 QPS 的 SSR 應用。在支撐好業務的同時，與組内同學一起孵化出開源架構 egg-react-ssr。2020 年到淘寶技術部，開啟前端智能化的旅程，目前負責 P2C，和卓風是搭檔。
卓風（上圖右），入職阿裡的八年時間，主要是在淘寶負責天貓、聚劃算大促及日常營銷業務産品的落地，曾負責面向天貓、淘寶、聚劃算等商家的搭建産品建設和淘系智能 UI 體系建設和業務落地，相關産品和體系已陸續在向集團落地。近 1 年投身到前端智能化領域，緻力于 Service to Code 體系建設，推動服務端智能出碼的落地，目前相關體系具備一定雛形，在團隊内業務範圍進行閉環試驗。
今天的主題我們會以 4 個次元進行展開，會詳細介紹 P2C 這個産品概念的來龍去脈以及我們解決問題的思路，歡迎各位上車。
因為今天的話題是延續去年甄焱鲲（甄子）在 D2 的前端智能化實踐的分享，是以在講我們的話題之前，還是先介紹阿裡前端智能化實踐的整體布局情況是怎樣的。如下這張大圖，可以按三部分進行了解：
- 底層是以 Pipcook 為代表的“前端算法架構層”，其目的是通過它讓前端工程師具備了踏入算法工程師門檻的可能，這點非常類似于 Node.js 對于前端工程師的作用，目前 Pipcook 已經釋出到 v1.3 版本，開源社群也非常活躍，歡迎自取使用；
- 中層“研發能力層”是面向前端提升研發效率的産品工具，并且對這邊提效的能力我們進行了抽象，分為 D2C（Design to Code）、P2C（PRD to Code）、S2C、和 C2C 等，今天我們要重點講的就是前兩者；
- 而頂層是應用底層、中層前端智能化能力服務的上層業務産品，在過去三年裡我們前端智能化的産品能力已經覆寫集團 17+ 個 BU（Business Unit） 70%+ 的前端，當然這個數字不算太新，新的數字在不斷上升。
提到 D2C，我們先回顧下應用 D2C 能力的 Imgcook 産品今日的發展現狀，從下圖可以看到 Imgcook 的發展數字比較可觀，且應用覆寫了 2020 年雙 11 會場 90%+ 的子產品開發，出碼可用率達到 79.26%，且需求吞吐量提升 1.5~2 倍，給前端研發帶來實質性的提效。
然而，提效并不等于完全替代前端人工開發，從 79% 的數字上我們看到還有 21% 的出碼率沒有達到，且 79% 這個數字在 2019 到 2020 年一直上浮不大，是以仿佛 D2C 走到了上升瓶頸階段。
但經過我們的調研發現，事實并不是 D2C 的能力達到極限，而是從 Design 視覺稿中挖掘的出碼資訊達到了極限，剩餘的 21% 的出碼資訊，我們發現要從産研鍊路的上遊 産品經理（PD，Product Designer）的 PRD （Product Requirement Document）中才能拿到。
是以我們将輸入向上遊鍊路擴充到 PRD 這一環，而 PD 生産的 PRD 又兼顧到前端下遊鍊路後端的出碼；同時前後端的出碼界限一直以來并沒有那麼清晰（很多前端的代碼其實也可以放置在後端 BFF（Backend for Frontend） 層，比如初始資料的字段加工），是以我們将輸出也擴充到下遊鍊路後端這裡。
因為我們将輸入輸出在産研鍊路上向上下遊鍊路進行了擴充，是以理論上我們所做的工作也發生了本質的變化，由原來的 設計即代碼（D2C）轉變為 需求即代碼（P2C）、需求即生産，将多種産研角色納入到我們的産研工作台當中，形成多角色的線上協同，通過這次跨界，理論上會帶來的出碼率的進一步提升。
是以這就是 P2C（PRD to Code）的由來。我們期望借助 P2C 能進一步的提升産研的傳遞速度，期望能給 PD 提供端到端的産品傳遞能力，期望間接提升 PD 的業務 KPI 輔助業務增長。是以，可以看到相對 D2C，P2C 的目标使用者發生了本質性的變化（由設計師、開發者轉變成了 PD），基于這個點，我們對 P2C 的産品設計理念做了如下三方面的限制：
- 首先，要繼續基于設計稿，這部分的出碼率已達到 79%，這邊的出碼資訊對 P2C 依然有用，是以這部分不能舍棄，同時，PD 基于設計稿來完成 PRD 會更佳友善直接。
- 其次，将 PD 原來書寫 PRD 的工作轉變成基于設計稿來标注業務資訊的工作，一方面這樣操作對 PD 來說更直接，另一方面這樣的操作對 PD 的工作負擔也相對較少。
- 最後，我們要確定 PD 的标注資訊能夠出碼，要做到“需求即代碼”，不能出碼的輸入資訊，意味着不會進一步提升出碼率，這就失去了 D2C → P2C 更新的意義。
基于設計稿已不用再過多介紹，應用 D2C 能力的 Imgcook 已經是一個很好的例子。那麼“标注”和“出碼”要具體怎麼設計？接下來就會依次進行介紹。
首先介紹 P2C 的标注，想要知道标注怎樣設計，必須預先知道 PD 是怎樣一類人，他們的工作方式是怎樣的。
從 PD 的日常的工作調研發現，PD 是一類聰明、有想法有意思卻又非标的工作群體，他們沒有很多可标準化的工作具象内容，平時消耗在産研鍊路上的溝通比較多、新老産品經驗傳承也是斷層的、書寫的 PRD 文檔也沒有具象标準、五花八門是以書寫的 PRD 下遊角色也不怎麼看，書寫這樣的 PRD 對 PD 來說本身已是一種負擔和痛苦。
PD是非常擅長産品業務上定義的（比如什麼叫“買貴必賠”、什麼叫“冰點價”），這是除了 PD 以外其他角色不具備的能力，比如設計師，能在設計稿中表達的業務資訊非常有限。
是以，P2C 标注的工作，就是要貼合 PD 的痛點和角色特點來進行設計，我們期望通過以下四點來幫助 PD 完成産品需求的定義。
- 第一步，我們期望 PD 在上傳 Sketch 設計稿之後，P2C 會借助 D2C 的能力馬上對設計稿進行第一步的解析，生成結構化可視化的線上标注畫布，供 PD 進行第二步的操作；
- 第二步，我們期望 PD 在第一步的視覺畫布基礎上，進行業務資訊的标注，完成業務邏輯的準确定義；
- 第三步，我們期望 P2C 能夠提供給 PD 一種直覺且輕量化的标注設計工具，輔助 PD 能快速完成類似多态等複雜業務邏輯資訊的錄入；
- 第四步，我們期望 P2C 能夠提供給 PD 一種所見即所得的能力，通過預覽的互動形态間接來确認産品背後的資料源資訊，這就銜接到服務端的資料接口設計，下會會再講到。
- 最後，經過所有的一個個步驟，本質上我們期望給 PD 提供一種非常貼合他手工标注的業務邏輯組織方式，期望 PD 的每一次标注都映射到背後的一個邏輯單元友善 PD 進行快速标注，而邏輯單元又能確定出碼，這就是“邏輯點”概念的由來，盡管對 PD 是透明的，卻對 P2C 非常有用。
是以，經過上面步驟對 P2C 産品的探索，我們也更加清晰了 P2C 的産品定位。概括一下如下圖所示，P2C 要在 D2C 的基礎上兼顧業務含義的定義和出碼量的絕對提升，這就是 P2C 的産品使命。
是以 P2C 的整個标注體系，就是如下的這套結構設計，基于設計稿的 Canvas 畫布，提供給 PD 基于邏輯點的标注操作面闆，非常直覺、友善地輔助 PD 對産品需求的定義。
那麼在這裡有人會問，沒什麼不給 PD 一個 PRD 的文檔編輯器來對需求進行錄入呢？
這樣的方案我們嘗試過，甚至嘗試過不止一個方案，但過去的失敗都告訴我們 100% 采用純的自然語言來描述需求，對 PD 雖然可行，但對出碼卻不可行，至少當下 NL2Code 這個學術業界難題還沒有非常好的攻克掉，是以這對 P2C 不利，而且純的自然語言描述并不如這種基于設計稿的标注對 PD 來說操作更直接、更簡潔，是以當下這套标注的産品設計，也是我們經曆種種失敗後選擇的一條非常貼合 PD 且可行的一條道路。
那麼 PD 究竟怎樣标注？操作方式是什麼樣的？
以下兩張圖就是 P2C 裡對标注這一産品能力的具體設計思路，可供大家參考。
背後使用的是一套上卷下鑽的互動設計理念，同時對于 PD 如果從 P2C 推薦的标注點（邏輯點）清單中找不到他所需的标注點的話，P2C 還給其提供的自定義的工單鍊路，友善其完成需求的定義。工單的背後是借助人工、機器學習來對 PD 定義的需求進行出碼定義和訓練，下文會再介紹。
是以從 PD 是視角來看完整的需求疊代動線就如下圖所示（圖中的 S2C 賦能可以了解為 P2C 背後的智能化出碼能力，下文就會重點提到），需求從建立到标注到産出一份完整的可供預覽和彙報的 PRD 文檔和預覽 Demo，再到視覺稿的更新更新如何借助以圖搜圖（即以圖搜存量标注資訊）進行存量基礎上的疊代，完整地展示了需求疊代的整個過程。
而第二張圖就是以真實的産品需求為例，完成這整個産品疊代過程背後的一些具體技術過程，如“布局識别”、“各種邏輯點的識别”等等。
從上圖我們基本看到了邏輯點的擷取途徑有三種，具體如下圖所示：
- 第一種是 D2C 視覺識别這一步驟中從視覺稿中擷取到的邏輯點資訊，比如從“N 件 N 折”、“商品白底圖”“淘搶購坑位”等這樣的視覺表達挖掘到的邏輯點資訊；
- 第二種是從 PD 的組織結構資訊、産品背景資訊中挖掘到的一些需求基本資訊，比如“淘搶購頻道”、“大促會場”等，這部分資訊可以輔助 P2C 确定業務領域，縮小邏輯點的推薦分範圍；
- 第三種是從 PD 直接在需求工作台的視覺稿畫布上标注的業務邏輯資訊，比如“無門檻的定義”、“冰點價的定義”等，這部分資訊可直接作為視覺稿的補償資訊，友善 P2C 挖掘更多出碼所必需的業務邏輯資訊。
總得來看，有這三部分的資訊即可确定全量的邏輯點，同時通過這些豐富的邏輯點一步一步地指引标注，通過标注自動更新邏輯點，最後通過選擇的邏輯點和标注資訊出碼。
說到這裡，大家可以看到邏輯點和标注之間是有關系的（上文也提到邏輯點就是為了貼合标注使用的），标注資訊的顆粒度也直接決定邏輯點出碼的可能性效果，簡單來說，粗略一點的标注，比如像用自然語言來标注，對于邏輯點的出碼效果不是太理想（當然我們也在研究這部分的能力）；詳細一點的标注，比如像 KV 表單，對于邏輯點的出碼效果肯定是最好的，但對 PD 來說太具有挑戰了，在讓 PD 做完型填空，工作方式既死闆又不靈活，PD 很不喜歡這種工作方式。
是以，PD 喜歡的理想标注狀态就是 0 标注（即在産品需求疊代過程中，對于存量已标注過的資訊不要再重複标注，甚至可以做到跨産品的标注複用），這就是标注的未來發展走向，通過 P2C 的智能化手段來逼近這個目标；與此同時，借助邏輯點與标注的映射關系，能實作 0 标注，意味着首先要實作存量邏輯點疊代的 0 研發（即在産品需求疊代過程中，借助智能化能力對于存量邏輯點可以通過細微地變種形成疊代所需的新邏輯點，甚至也做到跨産品、跨技術的邏輯點複用和生成），才能對 0 标注提供可能性。
是以，從 0 标注、0 研發的角度來看 P2C 産品從現在到未來的發展路徑，基本符合下面的發展規律（如下圖所示）：
- 階段一，就是當下借助 Sketch 視覺稿和 Sketch 标注資訊生成代碼的過程；
- 階段二，是将 PD 角色的完整生命周期的工作内容搬到線上需求工作台當中，同時打通産研完整的産研鍊路，形成一定程度線上協同，完成需求的傳遞過程；
- 階段三，是大量借助 AI 提供大量可替代人工重複标注和出碼的服務可能，節省産研鍊路上的人力的重複性開銷，形成一定自動化程度上的需求傳遞過程；
- 階段四，是在前面基礎上，擁有大量曆史标注、出碼資料的基礎上，将 AI 的能力進一步提升，進而達到視覺稿/PRD 的上傳即出碼過程，即需求即代碼的傳遞過程。當然，這是後話。
上文講完“标注”的産品設計過程，那麼接下來再重點介紹下“出碼”的産品設計過程。
講出碼之前，還是要先關注下 D2C 目前版本中運用邏輯點來進行出碼的實作過程。
如下圖所示（圖中的視訊可從文章頂部的直播視訊中查閱到），借助視覺稿插件我們對視覺稿做了一定程度額外标注，導出之後給到 Imgcook 工作台，然後開發者需要在 Imgcook 的邏輯庫當中錄入視覺稿中存在的邏輯點資訊，邏輯點資訊包含邏輯點的識别和表達兩部分，進而實作在設計稿導入到 Imgcook 工作台之時，馬上可以識别到視覺稿中可能存在的邏輯點。
上面過程就是 D2C 借助邏輯點來實作出碼的完整過程，可以看到面向的使用者角色是開發者，而這點就是與 P2C 的本質差別，P2C 面向的是 PD，是以不可能讓 PD 進行邏輯點的預先定義和應用。
然而不論 D2C，還是 P2C，在出碼的實作鍊路設計上都是可以抽象為“邏輯意圖的識别”和“邏輯意圖的表達”兩部分的，即從識别擷取到“邏輯意圖”（邏輯點），再基于“邏輯意圖”表達成為真正的邏輯代碼。
但 P2C 相比 D2C，它要更新點恰恰也是“識别”和“表達”的這兩個過程：
- “識别”要更新，原因是 D2C 原來的識别器是離散的，能識别的資訊都是單模态的，比如不會把 UI 上的文本、布局、UI 樣式、上下左右的資訊、業務上下文等資訊綜合作為算法模型（Model）的輸入，導緻傳統識别器能預測的語義資訊的準确程度有限，外加上今天 PD 角色标注資訊的引入，是以勢必要對“識别”的算法模型進行根本性地更新，形成多模态的語義識别模型才可提升預測語義的準确率，進而更加精準地命中邏輯意圖的語義靶點。
- “表達”要更新，原因是 D2C 面向的是開發者，而 P2C 面向的是 PD，是以原來在 D2C 場景中開發者使用特别爽的資料源綁定、字段/事件綁定，對于 PD 來說就不人道了，否則就變成了 PD 在替開發者在程式設計，這是一種工作量轉移的投機取巧，不是 P2C 的設計初心。另外，PD 标注的業務邏輯資訊，他是不關心也不清楚具體是由前端開發者實作的，還是由後端開放者實作的。是以，總得來看，對“表達”的更新，就重點展現在對資料生成、事件綁定和邏輯函數塊 OP 的表達器更新上，資料生成是為了避免 PD 要預先像開發者一樣選擇一個服務端資料源，我們采用借助語義識别出來字段語義自動關聯或生成服務端資料源；事件綁定概念會隐藏避免 PD 感覺，以免出現 PD 像開發者一樣定義事件的綁定過程；函數塊 OP 的更新，是因為 PD 定義的業務邏輯，除了含有前端的邏輯代碼生成以外，還有生成服務端 BFF 層甚至更深層次的邏輯代碼。
以上這些就是要在“出碼”鍊路上對原來 D2C 邏輯點的識别、表達進行更新的來龍去脈。
那麼新版的邏輯點在上遊标注和下遊資料/代碼之間是怎樣互動的？
具體過程可以如下圖所示，簡單來說就是借助上文提到的标注資訊，找到可能存在的邏輯點，邏輯點背後又分前端邏輯點和後端資料邏輯點，附帶 PD 标注的邏輯點限制資訊，就可以真正出碼了。
是以，概括一下，出碼鍊路從 D2C 到 P2C，更新的主要内容就是下圖中橙色到紫色和深紫色的部分：橙色部分是原來的 D2C 出碼鍊路；紫色和深紫色是當下 P2C 的出碼鍊路，而且深紫色部分中可以看到有服務端出碼部署的功能節點，比如 FaaS 代碼部署。這裡也順帶提一下，P2C 在服務端的部署是進行備援部署的，因為算法提供給 PD 的邏輯點推薦資訊很大程度上存在近似解，是以隻用多套解進行備援部署 PD 才可以借助預覽效果進行最終所需效果的甄别。
上文講到識别的更新，那麼接下來就簡單介紹下邏輯點識别的算法設計方案，以供大家進一步了解這一步更新的重要意義。
具體如下圖所示，借助多模資訊的輸入，進行綜合型的語義了解，提升語義識别的準确率。
比如，以右圖“￥4999 ”為例，當将該文本和圍繞該文本上下左右的周邊資訊，以及文字字号、顔色、長度、粗細等資訊作為算法模型的輸入，通過對其中資訊的 embedding、降維、尺度歸一化等操作之後，擷取到一些語義特征的 label 資訊，進而确定“￥4999 ”的最終語義為“618 大促商品活動價”。
上文講到出碼鍊路上邏輯點更新的設計和實作過程，那麼接下來再介紹下在 P2C 産品領域内，對邏輯點的未來階段規劃是怎樣的，以便大家能進一步了解到，原來邏輯點的設計就是對未來 0 研發打基礎的出發點。
具體如下圖所示：
- 在 P2C 産品的起步階段，PD 來到 P2C 需求工作台上的标注和背後的邏輯點資訊，都是通過人肉的方式錄入和供給的，這個過程我們認為是 Step1 階段，目的是在為 Step2 積累算法樣本；
- 當 PD 在 P2C 需求工作台上疊代起需求之後，平台上沉澱的曆史資料中的标注和邏輯點資料就會存在内在的映射關系，這部分資料會作為訓練樣本回流給算法模型，進一步提升算法模型識别和表達的準确率，進而整體降低标注的人工成本和出碼的開發人工成本，這個過程我們認為是 Step2 階段；
- 緊接着，随着 Step2 階段的不斷發展、積累和模型的演進，P2C 的需求工作台就具備了 AI 标注和自動化出碼的能力，這就是我們前面暢想的 0 标注、0 研發階段，這個過程我們認為是 Step3 階段。
理想是美好的，也給大家看看現實的具體例子，以下是我們生産當中的一些 Demo 案例，右側是我們在人工給算法準備樣本及算法預測效果的 Demo 案例（案例中資料我們做了去敏）；左側是邏輯點的中文輸入，輸出就是邏輯點的代碼，同時這也是我們在攻堅的研究課題—— NL2Code。
但 NL2Code 的學術研究，我們也在起步階段，背後涉及數理邏輯、機器學習、軟體工程、語言學、資訊論等學科知識也比較多，門檻很高，且這個領域在學術界的研究也非常有限，解決方案能用到工程當中的也幾乎少見，目前我們在各國内外各大頂級高校進行産學研的深度合作，期望在 NL2Code 領域真正産出一些根本性的進展，可服務工程生産，為 P2C 帶來更深層次的效率提升。
當然，我們在學術上的産出一些階段性地通過學術 Paper 向外傳遞給大家，期望帶來整個前端工業的智能化。
最後，我們講一下 P2C 的産品展望。
講展望之前，還是先回顧下我們今天的所講内容。
今天我們最先介紹 P2C 是怎麼來的，然後介紹了 P2C 當中兩個非常重要的産品環節的産品設計，一個是“标注”，另一個是“邏輯點”，借助“标注”我們收集到完整的需求資訊，借助“邏輯點”我們找到需求出碼的中間橋梁，借助對“标注”和“邏輯點”的“資料采集”我們找到訓練“需求意圖-服務出碼”模型的基礎資料，借助這個模型我們完成了整個需求即代碼的傳遞過程。
同時我們也介紹到，P2C 是站在 D2C 肩膀上成長出來的産品，是以原來 D2C 的産品能力并沒有浪費，而均作為 P2C 的基礎基建。當然，讓前端在 P2C 應用算法，也十分依賴底層 Pipcook 提供給前端的算法架構能力，是以，P2C 的建設也十分要感謝 D2C 和 Pipcook 能力的布局和建設。
最後，展望一下 P2C。P2C 的能力今年在業務當中在邊落地邊打磨當中，計劃明年的 4 月份提供一個對 PD 更加友好的體驗式傳遞平台，計劃明年 10 月份可以對外公測。
最後，大家如有什麼疑問，都可以在下面的群裡進行交流。同時也歡迎大家使用我們的産品、參與我們産品社群的建設。另外，我們持續保持對外招聘，非常歡迎同道中人加入我們，一起共建前端的未來産品。
謝謝大家！謝謝 D2！
更多内容，參考
- Imgcook Product： https://imgcook.com
- Imgcook Github： https://github.com/imgcook
- Pipcook Github： https://github.com/alibaba/pipcook
- IUI 2021 Paper - Auto-Icon: An Automated Code Generation Tool for Icon Designs Assisting In UI Development：
- 阿裡巴巴前端智能化掘金社群：
🔥第十五屆 D2 前端技術論壇 PPT 集合已放出，馬上擷取
關注「Alibaba F2E」
回複 「PPT」一鍵擷取大會完整PPT