大家好，我們是來自阿里巴巴淘系技術部的狼叔、卓風。感謝 D2 組委會，讓我們有機會在這里分享，關于《前端智能化實踐—— P2C 從需求文檔生成代碼》。

淘系技術微信公眾號后臺回復「D2」即可下載第十五屆 D2前端技術論壇 PPT 集合！！！

狼叔（上圖左），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：

• • https://www.yuque.com/docs/share/ec67f566-60c6-4cb4-967f-118829b7e63b?#

???拓展閱讀

作者|狼叔、卓風

編輯|橙子君

總結

以上是生活随笔為你收集整理的前端智能化实践（附：D2 前端技术论坛 PPT 合集）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。