一种可复用的AI提效方案：AI点灯

在当今飞速发展的时代，AI技术正不断渗透到我们生活的各个层面，深刻改变着传统的工作方式和生活模式。面对这一重大变革，我们不能被动观望或抗拒，而应积极拥抱AI，将其作为成长的助力。只有与AI协同发展，才能在这场技术革新的浪潮中立于不败之地，顺势而为才能事半功倍。

大模型的典型特征

强项：

1. 自然语言理解与生成

2. 广泛的知识覆盖

3. 高效的文本处理

4. 学习与适应

5. 计算能力强

弱项：

1. 理解与推理局限

2. 生成内容的准确性

简单来说，可以把现在的AI看作是一个可以不断学习，能够按照指定思路理解和解决问题的强文本处理工具。那么合理利用强弱项，就可以给我们的场景带来提效了。

强项	弱项	策略
自然语言理解与生成		能够将专业领域语言跟自然语言相互转换
广泛的知识覆盖		提供相应领域知识库，可以调用知识库能力
高效的文本处理		把对应的领域问题转换为文本
学习与适应		提供一些案例进行不断学习，提高准确度
计算能力强		能够处理大量重复劳动
	理解与推理局限	指定理解问题的思路，以及解决问题的流程或步骤
	生成内容的准确性	对生成的内容进行校验

总结一下，就是

把专业领域的重复劳动的问题和解决方案都抽象为文本，提供相应的领域知识库，可以用自然语言来描述专业领域问题，指定AI理解问题的思路以及解决问题流程，提供一些案例提高准确度，最后对生成内容校验。

按这个思路，可以对所有领域的适用场景进行AI提效，我愿把这个方案称之为AI点灯。

适配场景

在任何领域中，能够把重复劳动包含的任务和解决方案都抽象为文本的场景。下面来看一个前端场景提效的实践案例。

▐  B端运营配置平台场景

交易产品中心，把交易链路中的一些基础和增值能力整合为产品，在交易产品中心中进行对应的实例配置和发布管理。比如已接入的一品多商、价保、一店多供、顺手买一件等产品。

这是一个交易产品中心，价保产品接入的需求设计稿的三分之一，有大量的重复页面需要开发。

开发+联调+测试需要前端大量人力，如果每个产品接入都需要这么多资源，那后续20+个交易产品以及其他运营产品接入，仅产品接入流程就需要占用一个前端全年人力。

• 场景页面分布

从已接入的几个产品来说，场景主要是表格页面和表单页面。

1. 数据查看、操作（表格页面，红框部分）

2. 数据增删改查（表单页面，红框部分）

3. 其他页面（10%以下）

• 核心问题

交易产品中心由于业务特征，具备以下特点：

1. 平台接入业务多、业务逻辑复杂，定制度高

2. 表单、表格页面占比高，场景单一

3. 对页面UI要求较低

由于业务定制高，在接入业务多的场景下，业务的增删改查都需要耗费平台人力，对人力成本要求很高，所以急需一个类似的B端运营配置平台提效方案。

提效方案探索

▐  前端提效历史回顾

• 传统研发流程

需求研发流程

前端开发分层架构

一个完整前端页面的开发包含环境搭建和需求迭代流程，需求迭代流程包含页面UI层、页面逻辑层、页面数据层和项目管理：

1. UI层包含元素结构树、元素样式树

2. 逻辑层由js描述，包含初始化执行逻辑、事件触发逻辑、组件联动逻辑

3. 数据层需要获取数据，然后将数据绑定到元素上，还有页面的一些状态管理

4. 项目发布包含版本管理

优点：自由度高，可以实现任何前端需求；

缺点：需求周期、链路长。

• 组件复用

对已实现的模块，后续页面复用公共模块。主要代表antd等组件库：

需求研发流程

前端开发分层架构

组件复用方案可以在UI层、逻辑层进行提效，其中在UI层可以复用组件UI，逻辑层可以复用组件逻辑：

优点：定制自由度高，以组件或页面维度减少工作量，非常通用；

缺点：仅在UI层和逻辑层进行研发提效。

• 低代码研发流程

基于组件库，在一些前端较简单场景，由产品或者前端根据原型图使用低代码平台转化为前端页面，其中在平台页面搭建过程中添加一些页面逻辑。使用低码平台研发。阿里集团内部有宜搭、乐高等。

基于UIPaaS、iceluna（低代码平台孵化器），集团内部衍生出宜搭、乐高两个不同方向的低代码搭建平台。

	宜搭为代表	乐高为代表
面向人群	非技术背景（PD、运营等）	具有技术背景，了解一些前端基础
适用场景	基于表单的数据信息化产品，比如投票、问卷、导航页等简单场景	定制企业级中后台系统，乐高负责前端页面的设计和搭建
页面UI	拖拽搭建，一些常用基础组件	拖拽搭建，丰富的中后台场景组件
页面逻辑	组件配置，可添加自定义方法	组件配置或者组件内置，可添加自定义方法
优点	针对表单、问卷、报表、导航页等简单页面，支持度比较好。对产品、设计同学友好	针对中后台场景等较复杂页面支持度较好，功能完善，扩展性强
缺点	复杂场景支持度较低	上手成本高，较复杂场景需要对前端有足够的理解

需求研发流程

前端开发分层架构

低代码方案可以在环境搭建、UI层、逻辑层、数据层、项目发布进行整体提效，由于基于组件库，UI层和逻辑层提效参考组件复用，其中数据层提供数据绑定，平台提供项目发布。

优点：整体研发成本降低，解决方案相对完善，对简单场景支持度较好；

缺点：强依赖低代码平台，定制自由度受平台能力的限制，后续页面维护持续依赖平台。

• D2C（Design To Code）研发流程

基于组件库，在一些新建频率较高的场景（比如会场、活动搭建等），利用图像识别或者多模态大模型把图片中的内容都识别出来，然后根据图片内容生成具体页面代码。代表集团内ai-rapidcode、达拉然、集团外蓝湖等。

需求研发流程

前端开发分层架构

D2C方案由于其生成型特性区分为首次需求和需求迭代流程，可以直接生成项目环境；首次需求时UI层部分可以直接完成，逻辑层会复用一些组件逻辑，还需要单独添加其他逻辑；需求后续进行正常迭代，流程则参考组件复用方案：

优点：可直接减少页面UI开发人力；非常适用于生成一次性项目

缺点：

1. 依赖图像识别准确度or设计稿图层划分清晰度；

2. 图片内容转化后，还需单独添加页面逻辑。

3. 不适用于不断迭代的项目，二次开发成本较高

目前基建不完善，要提高D2C的图片转化效果，需要在图像识别、设计稿图层划分、转化内容布局适配等流程耗费大量人力。

困境：复杂页面准确度不高，简单页面提效能力有限。

• P2C（PRD To Code）理想流程

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协议化方案

P2C（PRD To Code）当前阶段还是过于理想，直接从需求到页面代码中间跨越了太多流程，如果在中间加一个中间层，去承载页面样式和页面功能，那就容易很多了。

希望能够复用已有能力，并且能够低成本生成页面，基于组件复用方案，采用页面协议承载了UI和逻辑，可作为需求和页面之间的中间层。

在一些流程较固定的场景（如B端运营配置平台），由产品提供PRD，使用AI把PRD转化为页面协议，最后由前端SDK转化为页面，其中降低了从产品、设计、开发、测试中重复部分的工作，协议描述了一部分页面和交互逻辑，前端SDK也内置了一部分页面UI和页面逻辑。

• 需求研发流程

核心难点如下：

1. 依赖前端协议SDK的完善度，需要协议支持足够多的能力和场景

2. 需要服务端对于页面协议结构有一些了解

3. AI生成页面协议的效果需要不断调优

• 前端开发分层架构

P2C协议化方案与传统前端开发分层有区别，新增了协议层、协议版本管理、协议SDK，协议层由UI层、逻辑层、数据层组成。可通过协议层控制页面能力和功能，首次需求仅需单独开发协议SDK和项目发布；需求迭代通过修改协议来实现，则整个需求迭代流程中前端0投入。

优点：大幅简化前端开发流程，需求迭代过程0投入。可扩展编排能力，后续可采用AI生成及优化协议；

缺点：前期投入较高，依赖前端协议SDK的完善度，调试、定位问题成本变高。

• 业务接入时序图

在前端协议SDK完善后，业务接入和业务需求迭代过程都无需前端投入。

P2C协议化方案

▐  协议设计

P2C协议化方案需要开发一套前端SDK用于把协议转换为页面，后续的页面开发就转化为开发一个页面协议，那这个过程最重要的就是设计页面协议。

一个完整前端页面包含页面UI、页面逻辑、页面数据：

1. UI层是由元素结构树、元素样式树、页面数据共同组成渲染

2. 逻辑层由js描述，包含初始化执行逻辑、事件触发逻辑、组件联动逻辑

3. 数据层需要获取数据，然后将数据绑定到元素上

协议页面，由页面协议和协议SDK组成，共同组成支持这些能力：

1. 页面协议支持描述元素结构树和元素样式树、事件触发逻辑、组件联动逻辑、页面数据

2. 协议SDK负责初始化逻辑、获取数据、数据绑定、状态管理

相比普通页面，添加了渲染协议能力。

• 协议SDK

协议SDK用于初始化逻辑、获取数据、数据绑定、状态管理、渲染协议，从0开发协议SDK成本很高，可以复用formily这类开源协议化能力。

渲染协议：基于formily（一套前端表单解决方案），主要复用其协议化渲染能力，可以把JSON Schema协议渲染为表单，拓展一下把表单组件替换为其他组件，就可以实现页面UI组件渲染。

数据绑定：formily以组件为最小原子，以表单数据为整体状态。可以对整个表单赋值，按树结构的位置信息进行结构和数据一一绑定，是一种弱约定的数据绑定形式。这里沿用这种方式进行数据绑定，需要限制组件数据为相同的树结构下发。

协议SDK能力	formily SDK
初始化逻辑	不支持
获取数据	不支持
数据绑定	支持
状态管理	不支持
渲染协议	支持

formily已经支持了协议化页面核心的页面渲染能力，可以在formily基础上去拓展协议SDK不支持的能力实现完整的协议SDK功能。

1. 添加页面初始化逻辑

2. 从接口获取数据（约束接口格式）

3. 添加状态管理

采用基于formily SDK+初始化逻辑+数据获取+状态管理可以组合实现协议SDK能力。

• 页面协议

页面协议用于描述页面元素，采用formily最小颗粒度的组件维度来描述；下发动态数据，包括页面数据，组件初始配置（扩展），分别用于初始化页面和组件；根据平台接入方后台服务不同，需提供数据格式处理（扩展），在不同场景采用不同数据格式处理。

页面协议能力	formily Schema协议
元素结构树--组件结构树	支持
元素样式树--组件样式树	支持
事件触发逻辑	不支持
组件联动逻辑	支持
页面数据--组件数据	不支持
组件初始配置（扩展）	不支持
数据格式处理（扩展）	不支持

在formily中协议仅支持描述元素结构、元素样式和组件联动逻辑，要描述整个页面还需要扩展一些能力：

1. 事件触发逻辑

1. 1. 复杂事件和浏览器事件，需扩展协议描述相关事件的触发和执行逻辑（约束协议格式）

   2. 简单事件，由于formily协议支持组件联动逻辑，则可以把触发和执行的行为都转换为数据驱动，通过行为依赖数据，监听其他数据变化后更改数据实现行为变更，比如某个组件的状态切换，展示\隐藏等

2. 组件数据

3. 组件初始配置

4. 数据格式处理（用于服务端处理不同场景）

其中B端运营配置平台大多都是简单事件，所以可以采用数据驱动方式简化。

采用基于formily协议+组件数据+组件初始配置+数据格式处理+数据驱动事件来组合实现页面协议能力。

• 完整协议页面

有了页面协议+协议SDK，就可以实现协议页面的能力了。但还是需要组件级能力复用，所以需要提供协议组件库，用于协议中描述元素，并且以组件维度封装功能。

协议组件库根据组件功能类型，可分为展示类、操作类、输入类。

基于formily，采用页面协议+协议SDK+协议组件库组合，比从0搭建协议页面减少了很多工作量，也实现了完整的协议页面。

• 页面联动

能够采用协议描述单个页面后，就需要添加多个页面之间的联动交互，B端运营配置平台一般有三种页面之间交互方式：

1. 跳转新页面，点击导航栏或者链接跳转

2. 在屏幕居中modal弹窗打开一个页面

3. 在屏幕右侧方drawer弹窗打开一个页面

1. 导航 or 链接跳转：

1. 1. 需要提供导航路由协议机制，下发路由协议，路由跳转联动导航栏切换

   2. 提供链接跳转功能按钮

2. modal or drawer弹窗：

1. 1. 支持触发打开modal or drawer弹窗

   2. 弹窗中间加载一个新的页面

所以需要支持额外的路由协议，以及行为触发页面交互，在B端运营配置平台场景基本都是由按钮来触发页面交互的，所以可以在按钮组件上集成链接跳转、弹窗打开新页面等能力。

▐  整体架构

协议化方案是由协议层控制整个产品路由展示和页面展示，由颗粒度从大到小分为几个部分：

1. 路由协议，由协议控制导航栏和页面之间跳转

2. 页面协议，用于渲染页面，展示对应数据，描述页面逻辑

3. 协议组件库，最小原子能力，用于协议调用

还有额外的工具层用于生成页面协议，目前有两种方式：

1. 后端工具生成协议

2. AI工具生成协议

▐  当前阶段研发流程

在需求文档到页面协议转换过程中，采用大模型转换页面协议，依附AI生长，具备了AI成长性。

其中前端SDK需要在这个模式运行过程中，不断完善支持新功能，类似搭积木一样，积木不断堆叠后，已有功能都能由协议直接调用，具备了功能成长性。

▐  运行图

AI提效

▐  表单页面

完整流程

1.0 AI生成表单协议

最初的版本是完全采用AI生成表单协议，通过prd生成一套formily JSON Schema协议来进行渲染。

优点：把前端相关部分都由AI来生成，可以减少前端工作量；

缺点：平台主要用户为服务端同学，对协议内容和结构不太理解，他们拿到生成的schema协议后，进行一些组件属性或者组件结构修改很复杂，并且没有编码IDE提示，浪费了程序员的代码优势。

适合场景：简单表单场景，非代码用户（比如产品、设计）；复杂表单场景，前端用户。

2.0 后端工具生成表单协议，AI优化组件功能

协议生成流程：

1. 采用后端java代码描述表单，通过java的类进行属性限制和备注，然后用java工具本地运行生成一份基础formily JSON Schema协议

2. 采用AI优化组件前端相关的能力（比如调整样式，合并信息框、添加组件联动等）

优点：发挥服务端同学的代码优势，用最擅长的代码描述表单协议结构，不擅长的前端部分采用AI处理，前端工作量降低

缺点：整体链路变长，需后端接入

适合场景：复杂表单场景、服务端用户

使用流程

1. 添加需要优化的schema和优化需求

2. 把生成的协议拿到预览地址，贴在schema协议，进行预览

方案对比：

	1.0 AI生成协议	2.0 后端JAVA生成协议，AI优化
使用场景	简单表单场景、复杂表单场景	复杂表单场景
服务用户	简单表单场景，非代码用户（比如产品、设计）； 复杂表单场景，前端用户	复杂表单场景，服务端用户
优点	减少前端工作量	减少前端工作量，发挥服务端同学代码优势
缺点	非前端用户无法直接修改生成的协议，浪费了代码优势	整体链路加长，需后端介入

▐  表格页面

表格页面可以拆分成不同的组件分别描述，整个页面都可以采用AI生成协议。

• 使用流程

1. 需要输入相应表格配置的描述

1. 表名（必填
2. 左上角按钮
3. 右上角按钮
4. 是否开启关键词搜索
5. 高级搜索配置
6. 提示（灰色）
7. 强提示（红色）
8. 是否开启分页
9. 表头配置（必填
10. 操作列配置
11. 是否开启表头隐藏
12. 是否展示总计内容

2. 拿到生成的表格协议后到页面预览

案例--高级搜索配置、表头配置、表头隐藏、总计

输入

1. 表名（必填）需求信息管理
2. 左上角按钮 无
3. 右上角按钮 无
4. 是否开启关键词搜索 否
5. 高级搜索配置1. date，日期选择框2. type需求类型，下拉框，选项有全部、数据不全需求、业务、平台、xx需求3. id需求ID，输入框
6. 提示（灰色）
7. 强提示（红色）
8. 是否开启分页 是
9. 表头配置（必填） 1. 需求名称，点击后跳转"https://xxx"，携带列表参数url2. 产品树3. 前端人日4. 后端人日5. 测试人日6. 总人日7. 完成时间8. 状态
10. 操作列配置1. 编辑，点击后打开模态框，"schemaKey"为"modifySchema"，保存地址"/demand/save"
11. 是否开启表头隐藏 是
12. 是否展示总计内容 是，展示总计、总人日、PD人日、后端人日、测试人日、其他人日

AI输出：

{"pageType": "table","pageView": {"name": "需求信息管理","initParams": {"modifySchema": ""},"detailOperate": [],"rightButton": [],"tips": null,"strongTips": null,"filterSearch": [{"key": "date","label": "日期","component": "DatePickerWithOptions","componentProp": {"options": [{"label": "周","value": "周"},{"label": "月","value": "月"},{"label": "季","value": "季"},{"label": "年","value": "年"}]}},{"key": "type","label": "需求类型","component": "Select","componentProp": {"options": [{"label": "全部","value": "全部"},{"label": "数据不全需求","value": "数据不全需求"},{"label": "业务","value": "业务"},{"label": "平台","value": "平台"},{"label": "xx需求","value": "xx需求"}]}},{"key": "id","label": "需求ID","component": "Input","componentProp": null}],"hideSearch": true,"enablePagination": true,"total": null,"tableSource": {"header": [{"key": "name","title": "需求名称","clickEvent": {"type": "jump","path": "https://xxx","params": ["url"]}},{"key": "productTree","title": "产品树"},{"key": "frontendPerson","title": "前端人日","sorter": true},{"key": "backendPerson","title": "后端人日","sorter": true},{"key": "testPerson","title": "测试人日","sorter": true},{"key": "totalPerson","title": "总人日","sorter": true},{"key": "finishTime","title": "完成时间","sorter": true},{"key": "status","title": "状态"},{"key": "operate","title": "操作","map": {"edit": {"type": "schemaButton","text": "编辑","buttonConfig": {"title": "编辑","type": "link","path": "/demand/save","behavior": "modal","schemaKey": "modifySchema"}}}}],"scenes": [{"name": "示例需求1","productTree": "产品树1","frontendPerson": 5,"backendPerson": 10,"testPerson": 3,"totalPerson": 18,"finishTime": "2023-10-01","status": "已完成","operate": null,"url": "example_url_1"},{"name": "示例需求2","productTree": "产品树2","frontendPerson": 8,"backendPerson": 15,"testPerson": 5,"totalPerson": 28,"finishTime": "2023-10-15","status": "进行中","operate": null,"url": "example_url_2"}],"showHiddenCheckBox": true,"summary": ["总计","总人日: xx","PD人日: xx","后端人日: xx","测试人日: xx","其他人日: xx"]}}
}

助力运营平台

▐  背景

顺手买需要在双十一前支持顺买商品运营，其中包含商品运营平台和千牛后台商家端改造。需求比较着急需要赶双十一节奏，在排期爆满的阶段，突然插入一个紧急需求，这种酸爽相信大家都懂～

以下是运营平台的工作流程：

为了快速上线，以及后续让顺买同学自己维护这个平台页面，就采用了在交易产品中心协议化的方式接入该产品。

前端主要需要投入一些新功能的开发，包含Select请求组件、文件导入、批量操作、图片上传、新增SKU弹窗、列表头部、二次确认按钮，这些能力。类似的功能后续接入时，就不再需要前端投入了。

▐  上线效果

商品总览页面：

支持文件批量导入、批量操作表单：

商品审核页面：

后续页面调整，包含按钮、筛选项、展示内容或者表单操作等，都可以由业务服务端同学通过直接改协议实现，无需前端参与。

后续发展

在这套体系建全后，可以大幅减少前端工作量。后续仅需要针对新功能、新组件的进行开发，类似于搭积木一样能力越来越多的时候，需要开发的部分就越来越少；已有能力都能直接由协议去调用，前端理论上可以达到一劳永逸的效果。

目前一些交易产品在持续接入，前端已经无需投入，甚至无需感知。由服务端同学根据协议去构建页面，减少了前端很多工作量。

但是有一个隐患是已有功能越来越多，维护成本越来越高，页面共用组件代表对页面组件的任何修改都可能影响所有复用页面。积木搭的越高，后面搭建工作就会越来越难，所以搭建之初就需要一个稳定的基座。

AI点灯的未来

未来会在更多场景尝试把重复劳动包含的任务和解决方案都抽象为文本，然后用AI去处理文本，以此来对场景提效。有兴趣的朋友也可以尝试一下～

团队介绍

我们是淘天集团-基础交易终端团队，一支专注于手淘APP交易域（购物车、下单、订单、物流等）业务研发和体验优化的技术团队，并且负责集团内部AI应用搭建的AI Studio平台。在丰富的业务场景下，我们通过持续的技术探索、不断的创新突破，给数亿用户提供极致可靠的交易保障、极致流畅的操作交互以及极致顺滑的购物体验。另外基于AI Studio平台资源沉淀，按照电商标准环节进行拆解，同时针对典型场景支撑最佳AI实践，让集团内业务团队利用AI能力低成本实现业务效果。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法