正文
优点：
定制自由度高，以组件或页面维度减少工作量，非常通用；
缺点：
仅在UI层和逻辑层进行研发提效。
基于组件库
，在一些前端较简单场景，由产品或者前端
根据原型图
使用低代码平台转化为前端页面，其中在
平台页面搭建过程中添加一些页面逻辑
。使用低码平台研发。阿里集团内部有宜搭、乐高等。
基于UIPaaS、iceluna（低代码平台孵化器），集团内部衍生出宜搭、乐高两个不同方向的低代码搭建平台。
|
宜搭为代表
|
乐高为代表
|
|
面向人群
|
非技术背景（PD、运营等）
|
具有技术背景，了解一些前端基础
|
|
适用场景
|
基于表单的数据信息化产品，比如
投票、问卷、导航页等简单场景
|
定制企业级中后台系统
，乐高负责前端页面的设计和搭建
|
|
页面UI
|
拖拽搭建，一些常用基础组件
|
拖拽搭建，丰富的中后台场景组件
|
|
页面逻辑
|
组件配置
，可添加自定义方法
|
组件配置
或者
组件内置
，可添加自定义方法
|
|
优点
|
针对
表单、问卷、报表、导航页等简单页面
，支持度比较好。对产品、设计同学友好
|
针对
中后台场景等较复杂页面支持度较好
，功能完善，扩展性强
|
|
缺点
|
复杂场景支持度较低
|
上手成本高，较复杂场景需要对前端有足够的理解
|
需求研发流程
前端开发分层架构
低代码方案可以在环境搭建、UI层、逻辑层、数据层、项目发布进行整体提效，由于基于组件库，UI层和逻辑层提效参考组件复用，其中数据层提供数据绑定，平台提供项目发布。
优点：
整体研发成本降低，解决方案相对完善，对简单场景支持度较好；
缺点：
强依赖低代码平台，定制自由度受平台能力的限制，后续页面维护持续依赖平台。
基于组件库，在一些新建频率较高的场景（比如会场、活动搭建等），利用图像识别或者多模态大模型把图片中的内容都识别出来，然后根据图片内容生成具体页面代码。代表集团内ai-rapidcode、达拉然、集团外蓝湖等。
需求研发流程
前端开发分层架构
D2C方案由于其
生成型特性
区分为首次需求和需求迭代流程，可以直接生成项目环境；首次需求时
UI层部分可以直接完成，逻辑层会复用一些组件逻辑，还需要单独添加其他逻辑
；需求后续进行正常迭代，流程则参考组件复用方案：
优点：
可直接减少页面UI开发人力；非常适用于生成一次性项目
缺点：
1. 依赖图像识别准确度or设计稿图层划分清晰度；
2. 图片内容转化后，还需单独添加页面逻辑。
3. 不适用于不断迭代的项目，二次开发成本较高
目前基建不完善，要提高D2C的图片转化效果，需要在
图像识别、设计稿图层划分、转化内容布局适配等流程
耗费大量人力。
P2C，完整名称是Product Requirements Document To Code，即从产品需求文档直接到代码，目前一些AI前沿产品已经可以直接
用需求生成页面或者应用
，简化整体流程，可大幅提效，代表cursor、bolt：
需求研发流程
前端开发分层架构
P2C方案由于其
生成型特性
区分为首次需求和需求迭代流程。可以直接生成项目环境，并且在
首次需求
直接产出完整的UI层、逻辑层、数据层部分，仅需单独处理项目发布；
需求迭代流程则参考组件复用方案
，进行正常迭代。
优点：
减少大量中间环节，可大幅提效；
缺点：
对于一些特殊页面逻辑还是需要添加。依赖AI能力，页面逻辑复杂之后，后续维护和迭代的难度也会指数级别上升。
▐
方案对比
在交易产品中心这个场景中，针对已有提效方案进行分析：
1. 组件复用。在
UI层和逻辑层
可节省人力，但是还需要大量人力去支持每个产品接入，开发对应产品逻辑
2. 低代码平台。可进行整体提效，但是后续开发、维护都依赖平台，并且后续复杂能力的支持也依赖平台开放程度
3. D2C。目前图像识别效果一般，效率提升很有限，并且后续页面迭代开发都需要人力维护
4. P2C。目前还过于理想，实现效果一般，并且后续页面迭代开发都需要人力维护
|
研发模式
|
描述
|
优点
|
缺点
|
提效能力
|
可用性
|
目前适用场景
|
|
组件复用
|
基于组件库，对已实现的模块，后续页面复用公共模块
|
定制自由度高，以
组件或页面维度
减少工作量，非常
通用
|
仅在
UI层和逻辑层
进行研发提效
|
低
|
高
|
所有需要复用功能的前端场景
|
|
低代码平台
|
使用集团内其他低码平台研发。宜搭、乐高等
|
研发成本降低，解决方案相对完善，对简单场景支持度较好
|
依赖其他平台，定制自由度受低码平台能力的限制，
后续页面维护持续依赖平台
|
中上
|
中
|
宜搭为代表：问卷、投票、导航页等简单页面；
乐高为代表：中后台场景
|
|
D2C
|
使用D2C、ChatGPT等图像工具，用设计稿图片或者设计稿图层结构生成代码
|
可直接减少页面UI开发人力；适用于生成一次性项目
|
依赖
图片识别准确度
；图片转化时，需
单独添加页面逻辑
；后续
迭代开发成本较高
|
中
|
低
|
一次性生成场景，比如会场搭建，运营活动页等，有详细的需求prd和设计稿
|
|
P2C
|
利用AI能力，直接从需求生成页面
|
减少大量中间环节，可大幅提效
|
目前还过于理想，只能实现简单功能，页面复杂度提升后，
后续维护和迭代成本较高
|
高
|
低
|
一次性生成场景，仅有需求prd
|
目前没有很适合交易产品中心提效的方案，需要针对这个场景定制提效方案
回顾一下场景特征
，交易产品中心（B端运营配置平台）有以下特点：
1. 平台接入业务多、业务逻辑复杂，定制度高
2. 表单、表格页面占比高，场景单一
3. 对页面UI要求较低
希望这样一个方案：
1. 能够
复用已接入业务重复部分的UI层、逻辑层、数据层，重点是支持复用表单、表格
2. 页面UI可以妥协，但是
能力需要支持应有功能
3.
尽量能够使用AI提效
基于这些前提，再沿用P2C的思路去简化流程，就有了下面方案。
▐
方案演进——P2C协议化方案
