最近我們在螞蟻內部發布了全新雲鳳蝶2.0，把產品的重點由H5 搭建徹底轉向了中台方向。使用雲鳳蝶，快速製作高品質中台應用。

我們目前聚焦於以下三個方面來服務中台業務：

• 降門檻讓更多人進的來參與中台建設
• 提效是否可以做到10倍提效？
• 提升體驗設計規範自動化落地，默認好用

本文主要探討雲鳳蝶對於中台提效的理解，從研發模式的角度來看，我們對於十倍提效的達成思路。

1. 中台應用分層模型

相信不少同學聽說過用戶體驗五要素，一個中台產品的從想法到實現落地，也是一個近似的分層模型。

這不僅是一個過程模型，也是實現模型，如今我們寫代碼也是這麼來寫的：

• 需求層描述產品目標、功能範圍，以人的視角詮釋原始需求。目前還沒有形式化語言支撐，以PRD 的形式流轉於word 文檔和語雀平台。產品經理工作在這一層。
• 模型層把所有業務概念和操作用形式化系統表述，把需求映射到計算機可理解的格式。這裡是一個比較泛的分層模式，可以簡單理解為充血的廣義模型，涵蓋了多層傳統分層。後端工程師工作在這一層。
• API層把所有的業務數據形式化，由於BS架構形成了天然邊界。後端工程師工作在這一層。
• 展現層把所有的內容視覺化，使用交互承載所有的業務操作。產品經理、設計師和前端工程師工作在這一層。

在這樣一個中台分層模型中，越靠上的部分細節越豐富，而越靠下的部分越靠近用於原始訴求，越簡潔抽象。

基於這樣一個分層模型，我們來思考，現有的研發模式是否足夠高效。

2. 層間關係

2.1 層間具有推導性

一般來說下層一定程度上可推導出下層，上層一定要遵循下層約束。

例如需求層約束單筆轉賬金額小於1 萬元，那麼模型層一定會遵循這個約束，絕對不會允許大於1 萬元的轉賬發生。模型層在這個基礎上可能會補充額外的約束，例如只能是在賬戶餘額大於轉賬金額的時候、轉賬目標賬戶沒有被封禁的時候才允許交易的發生。經過這一層細節補充後，需求更加具體，約束更加詳細。 API 層和展現層又會遵循這一約束。

2.1.1 強推導性

如果是上層可完全由下層推導而出，那麼是一種強推導關係。在這種關係下，平台能力滿足的情況下，可通過No-code 方式快速達成需求。

2.1.2 弱推導性

如果上層需要在下層推導結果中增加額外約束和細節補充，那麼是一種弱推導關係。在這種關係下，兼具效率和可定制性的Low-code 方式是更好的選擇。

由於細節由下而上遞增，所以越靠下層推導性越強，越靠上層推導性越弱。

在單一強組織架構內通過強制的高約束，可達成強推導性；但在廣闊的企業開發市場，跨約組織或組織內層級結構龐大，完成高約束性治理是無法完成的任務，只能達到弱推導性。

2.2 層間提效的關鍵在於完成推導性過程

完成推導性過程是提效的重中之重，因為它會簡化生產關係。如果上層可完全享受到下層的工作成果，而不需要換一種方式重建，將會大大節省時間，提高效率。

打通上下游生產資料壁壘是雲鳳蝶提效的主要抓手之一，這樣更容易完成推導性過程。

例如，模型層建立的模型，是否可直接通過推導性幫助建立API，甚至直接生成API（取決於需要補充的額外訊息，也就是是強推導性關係還是弱推導關係）；API 是否可以通過對到行幫助建立展現層界面和交互，甚至直接生成Form 和Table 等業務界面；甚至模型層是否可以直接跨越API 層，直接推導展現層。

如果想完成這種推導性關係，打通層間生產資料壁壘就是必須的，要建立一種穩定可被上層理解並加以利用的數據格式。

3. 層內關係

因為需求層的形式化語言探索業界還沒有突破，所以不再討論範圍內。

對於除需求層外每一層的建立過程，如何才是更塊更好的方式？如何搭配生產關係才會達到總體效率的最優？

3.1 使用Low-code 研發每一層

3.1.1 可視化研發

可視化開發不局限於UI 繪製視圖，是指基於GUI 配置化、聲明式的開發方式。

好的可視化關鍵是對於常見實現路徑的高層抽象，對眾多處理細節的收斂。只要完成了這種可視化過程，說明完成了細節收斂，用戶每一次操作都力挺萬鈞，以一當十，天然擁有高效率的特點。

不好的可視化只是把代碼世界里東西一一映射到可視化世界，不做多對一收斂，這可能會有降門檻的效用，但提效無從談起。

3.1.2 代碼研發

代碼開發需要開發者掌握龐大的專業技能體系，但擁有全部的靈活性，功能強大。

3.1.3 Low-code 兼顧層內建設兩種需求

由於企業開發市場對於交付效率和可定制性的雙重追求，Low-code平台成為這一市場最合適的開發方式，因為它兼具高效率和靈活性的特點。

所以，Low-code 平台需要解決好可視化開發和代碼開發之間的關係，它是一種部件生產和生產線組裝的關係。

3.2 層內提效的關鍵在於建立產業鍊式結構

3.2.1 富士康如何製造出高精尖產品iPhone

下圖是iPhone 的供應鏈，紅框內的是富士康。

產業鏈上游企業集中科技優勢，生產有高精尖屬性的大猩猩玻璃、屏幕模塊、攝像頭模塊等，蘋果公司輸出設計（中台的需求層），富士康就可以做出整體高精尖的產品iPhone 。

富士康的核心優勢，是以技能要求不高的方式流水線批量生產高精尖的iPhone。

3.2.2 傳統中台研發（Pro-code）

基於代碼做bottom-up 式研發，成本高昂。以展現層為例，它要求每一個參與者是專家（資深的前端開發經驗），它要求每個人都既會研發高科技的輪胎、齒輪、方向盤，也要掌握整車組裝。在這樣一個研發模式下，人員要求高，生產效率只能對人提出高要求以此提升生產效率，難以有量變的提升。

3.2.3 Low-code 中台研發

代碼用於生產零部件，可視化用於組裝。形成上下游分工的產業鍊式結構。

在這樣的分工模式下，專家做高科技研發，會有更多更優質的能力以組件化的方式被開發出來，而中台的建設是以流水線的方式進行組裝。後者人員技能要求低，模式固定，因此生產力也會大大提高。

很容易做出對比，一家工廠生產iPhone 的所有零部件並負責組裝，對比以上產業鏈結構，那種生產力更高？

以展現層為例，我們認為，一個平台即便完成了可視化操作，但還是需要專業的前端技能或深度理解，那麼就是失敗的。因為這是一個要求博士學歷的富士康，注定無法規模化生產。這也是我們特別注意控制產品透出的技術要求復雜度，對用戶提出最小的技能要求範圍。

4. 雲鳳蝶的提效思路

雲鳳蝶中台應用是Low-code 平台，目前聚焦於展現層流水線的打造，將UI 資產快速組裝出可用站點。

做好工具屬性只是滿足提效的基本要求，更重要的是從橫豎兩個方向改善生產關係和打通生產資料壁壘。

4.1 層內建立產業鏈提效

UI資產包專家級前端工程師使用代碼開發組件（UI資產），完全交由pro-code優化專家的生產效率（未來可能轉向CloudIDE），是產業鏈的上游。

低代碼組裝使用可視化+低代碼方式組裝UI界面和製作交互，是我們的核心生產線，是產業鏈的下游。

自由佈局畫布打破層內生產資料壁壘工作在展現層的PD、設計師和前端工程師工作產物無縫復用。

4.2 層間完成推導性提效

智能嚮導初探層間推導性關係由API層弱推導展現層，允許用戶在過程中補充額外訊息（交互細節）。初步打破層間生產資料壁壘，目前正在建設中。

4.3 Next

模型層下半年啟動模型層建設，並在智能嚮導中打通模型-> API ->界面的推導過程，進一步打破層間生產資料壁壘。

5. 總結

我們認為：

• 傳統提效思路的努力方向“利其器”沒有錯誤，是所有提效必須完成的第一步。
• 生產力產生量變的更重要武器是改變生產力關係。能夠打穿層級間、打通層級內，消除生產資料壁壘，層級內層級外下游都復用上游產物而不重建，會形成產業鍊式生產關係，從而效率最大化。

以上討論僅針對於雲鳳蝶三大目標（降門檻、提效和提升體驗）中的提效，雲鳳蝶在其他目標下的思考會陸續呈現。