云凤蝶中台研发提效实践

最近我们在蚂蚁内部发布了全新云凤蝶 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. 总结

我们认为：

传统提效思路的努力方向“利其器”没有错误，是所有提效必须完成的第一步。

生产力产生量变的更重要武器是改变生产力关系。能够打穿层级间、打通层级内，消除生产资料壁垒，层级内层级外下游都复用上游产物而不重建，会形成产业链式生产关系，从而效率最大化。

以上讨论仅针对于云凤蝶三大目标（降门槛、提效和提升体验）中的提效，云凤蝶在其他目标下的思考会陆续呈现。