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

AI技术正在以前所未有的速度渗透到我们工作和生活的每一个角落。面对这场变革，与其被动观望，不如主动拥抱，把它当作成长翻跟斗。顺势而为，往往能事半功倍。

大模型的典型特征

先聊聊当前大模型的核心能力边界。

1. 自然语言理解与生成
2. 广泛的知识覆盖
3. 高效的文本处理
4. 学习与适应
5. 计算能力强

1. 理解与推理局限
2. 生成内容的准确性

简单来说，现在的AI更像是一个可以持续学习、能按照指定思路理解和解决问题的“强文本处理工具”。理解它的强弱项，就是找到提效关键的第一步。

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

总结一下核心思路：

，提供相应的领域知识库，用自然语言描述专业问题，，再提供一些案例提高准确度，最后。

按这个思路，几乎所有领域的重复性工作都可以用AI提效，这个方法可以称为

。

适配场景

这个思路最关键的前提是：

下面来看一个前端场景的具体实践案例。

B端运营配置平台场景

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

这是一张交易产品中心价保产品接入的需求设计稿（约占三分之一），可以看到大量重复页面需要开发。

开发、联调、测试都需要前端投入大量人力。如果每个产品接入都这样操作，

场景页面分布

从已接入的几个产品来看，页面类型高度集中：

1. 数据查看、操作（表格页面）
2. 数据增删改查（表单页面）
3. 其他页面（占比低于10%）

核心问题

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

1. 平台接入业务多、业务逻辑复杂，定制度高
2. 表单、表格页面占比高，场景单一
3. 对页面UI要求较低

业务定制度高，接入业务多，任何业务的增删改查都消耗平台人力，成本压力非常大。因此，急需一个针对性的

。

提效方案探索

先回顾一下前端提效的演进历史，看看各种方案的优劣。

前端提效历史回顾

传统研发流程

一个完整前端页面的开发包含环境搭建和需求迭代，具体包括

：

1. UI层：负责元素结构树和元素样式树
2. 逻辑层：由JS描述，包含初始化逻辑、事件触发逻辑、组件联动逻辑
3. 数据层：获取数据，并绑定到元素上，再加上状态管理
4. 项目发布：包括版本管理

自由度极高，可以实现任何前端需求。
需求周期长、链路长。

组件复用

把已实现的模块抽成公共组件供后续页面复用，典型代表是antd等组件库。组件复用主要在UI层和逻辑层提效。

定制自由度高，以组件或页面维度减少工作量，非常通用。
提效范围仅限于UI层和逻辑层。

低代码研发流程

基于组件库，在一些简单场景下，由产品或者前端根据原型图，使用低代码平台转化为前端页面，并在搭建过程中添加页面逻辑。集团内部有宜搭、乐高等代表性平台。它们基于UIPaaS、iceluna（低代码平台孵化器）衍生而来。

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

低代码方案可以在环境搭建、UI层、逻辑层、数据层、项目发布进行整体提效。

整体研发成本降低，解决方案相对完善，对简单场景支持度好。
强依赖低代码平台，定制自由度受平台能力限制，后续维护持续依赖平台。

D2C（Design To Code）研发流程

基于组件库，在一些新建频率高的场景（如会场、活动搭建），利用图像识别或多模态大模型识别图片内容并生成代码。代表有集团内的ai-rapidcode、达拉然，集团外的蓝湖等。D2C方案由于“生成型”特性，在首次需求时UI层可部分完成，但逻辑层仍需单独添加。

直接减少页面UI开发人力，适用于一次性项目生成。

1. 依赖图像识别准确度或设计稿图层划分清晰度。
2. 图片内容转化后，还需单独添加页面逻辑。
3. 不适用于持续迭代项目，二次开发成本高。

目前基建不完善，要提升D2C的转化效果，需要在图像识别、设计稿图层划分、转化内容布局适配等环节投入大量人力。

P2C（PRD To Code）理想流程

即从产品需求文档直接生成代码。当前一些AI前沿工具（如cursor、bolt）已经可以直接用需求生成页面或应用，大幅简化流程。P2C方案在首次需求时可以直接产出完整的UI层、逻辑层、数据层，仅需单独处理项目发布。后续迭代则参考组件复用方案。

减少大量中间环节，可大幅提效。
对于一些特殊逻辑仍需手动添加。依赖AI能力，页面逻辑复杂后，后续维护和迭代难度指数级上升。

方案对比

在交易产品中心这个场景下，对已有提效方案逐一分析：

1. 组件复用：
   可在UI层和逻辑层节省人力，但仍需大量人力支持每个产品的个性化逻辑。

2. 低代码平台：
   可整体提效，但后续开发和维护依赖平台，复杂能力支持也受限。

3. D2C：
   图像识别效果一般，效率提升有限，迭代仍需人力维护。

4. P2C：
   目前过于理想，实现效果一般，迭代仍需人力维护。

研发模式	描述	优点	缺点	提效能力	可用性	目前适用场景
组件复用	基于组件库，复用公共模块	定制自由度高，以组件或页面维度减少工作量，非常通用	仅在UI层和逻辑层提效	低	高	所有需要复用功能的前端场景
低代码平台	使用宜搭、乐高等低码平台	研发成本降低，方案相对完善，简单场景支持好	依赖其他平台，定制自由度和后续维护受限	中上	中	宜搭：问卷、投票等简单页面；乐高：中后台场景
D2C	用设计稿图片或图层结构生成代码	直接减少页面UI人力；适用于一次性项目	依赖图片识别准确度；需单独添加页面逻辑；迭代成本高	中	低	一次性生成场景，如会场搭建，运营活动页
P2C	利用AI从需求生成页面	减少大量中间环节，大幅提效	目前过于理想，仅能实现简单功能；复杂度提升后，迭代成本高	高	低	一次性生成场景，仅有需求PRD

目前没有完全适合交易产品中心提效的方案，需要针对这个场景定制。

1. 平台接入业务多、业务逻辑复杂，定制度高
2. 表单、表格页面占比高，场景单一
3. 对页面UI要求较低

1. 能够

   复用已接入业务重复部分的UI层、逻辑层、数据层
   ，特别是支持复用表单和表格。
2. 页面UI可以妥协，但

   能力必须保障
   。

3. 尽量使用AI提效
   。

基于这些前提，沿着P2C的思路去简化流程，就有了下面这个方案。

方案演进——P2C协议化方案

当前阶段的P2C还是过于理想，直接从需求到页面代码跨越了太多流程。如果在中间加一个

，事情就简单多了。

希望复用已有能力，并能低成本生成页面。核心思路是：

。

在流程较固定的场景（如B端运营配置平台），由产品提供PRD，

，最后由前端SDK渲染成页面。这个流程。

需求研发流程

核心难点如下：

1. 依赖前端协议SDK的完善度
   ，协议需要支持足够多的能力和场景。
2. 服务端需要对页面协议结构有一定了解。
3. AI生成页面协议的效果需要不断调优。

前端开发分层架构

P2C协议化方案与传统前端分层不同，

。协议层由UI层、逻辑层、数据层组成，通过协议层控制页面的能力和功能。只需单独开发协议SDK和项目发布；

大幅简化前端开发流程，需求迭代过程前端零投入。可扩展编排能力，后续。
前期投入较高，，调试和定位问题成本变高。

业务接入时序图

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

协议设计

。后续的页面开发就变成了开发一个页面协议，所以最关键的一步就是。

一个完整前端页面包含：

1. UI层：由元素结构树、元素样式树、页面数据共同渲染。
2. 逻辑层：由JS描述，包含初始化逻辑、事件触发逻辑、组件联动逻辑。
3. 数据层：获取数据，并将数据绑定到元素上。

，共同支持这些能力：

1. 页面协议支持描述元素结构树、样式树、事件触发逻辑、组件联动逻辑和页面数据。
2. 协议SDK负责初始化逻辑、获取数据、数据绑定、状态管理。

相比普通页面，它多了

。

协议SDK

从零开发协议SDK成本很高，可以复用formily这类开源协议化能力。formily是一套前端表单解决方案，主要复用其协议化渲染能力——可以把JSON Schema协议渲染为表单。拓展一下，将表单组件替换为其他组件，就可以实现页面UI组件的渲染。

数据绑定方面，formily以组件为最小原子，以表单数据为整体状态，是一种弱约定的数据绑定形式。这里沿用这种方式，限制组件数据为相同的树结构下发。

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

formily已经支持了协议化页面的核心渲染能力。在此基础上拓展不支持的功能：添加页面初始化逻辑、从接口获取数据（约束接口格式）、添加状态管理，就可以组合实现完整的协议SDK。

页面协议

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

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

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

1. 事件触发逻辑：
   复杂事件和浏览器事件，需要扩展协议描述相关事件的触发和执行逻辑（约束协议格式）。简单事件则可以利用formily的组件联动逻辑，将触发和执行行为都转换为数据驱动。

2. 组件数据

3. 组件初始配置

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

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

完整协议页面

有了页面协议+协议SDK，还需要组件级能力复用。因此，需要提供

，用于在协议中描述元素，并以组件维度封装功能。根据功能类型，可分为展示类、操作类、输入类。

页面联动

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

1. 跳转新页面
   ：点击导航栏或链接跳转。

2. Modal弹窗
   ：在屏幕居中打开一个页面。

3. Drawer弹窗
   ：在屏幕右侧打开一个页面。

1.

：需要导航路由协议机制，下发路由协议，路由跳转联动导航栏切换。同时提供链接跳转功能按钮。

2.

：支持触发打开弹窗，并在弹窗中间加载新页面。

在B端运营配置平台场景，基本都是通过按钮触发页面交互，所以可以在按钮组件上集成链接跳转、弹窗打开新页面等能力。

整体架构

协议化方案的核心理念是

，由颗粒度从大到小分为：

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

2. 页面协议
   ：渲染页面、展示数据、描述逻辑。

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

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

1. 后端工具生成协议
2. AI工具生成协议

当前阶段研发流程

在需求文档到页面协议的转换过程中，

，依附AI生长，。同时，前端SDK在这个模式运行过程中不断完善，支持新功能，像搭积木一样不断堆叠，已有功能都能由协议直接调用，。

AI提效

表单页面

1.0 AI生成表单协议

最初版本完全由AI生成表单协议，通过PRD生成一套formily JSON Schema协议进行渲染。

将前端相关工作都交给AI，减少前端工作量。
平台主要用户是服务端同学，对协议内容和结构不太理解，修改复杂，且没有IDE提示。
简单表单场景（非代码用户）；复杂表单场景（前端用户）。

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

1. 采用后端Ja va代码描述表单，通过Ja va类进行属性限制和备注，然后本地运行生成基础formily JSON Schema协议。
2. 采用AI优化组件前端相关的能力（如调整样式、合并信息框、添加组件联动等）。

发挥服务端同学的代码优势，用擅长的方式描述表单结构，不擅长的前端部分交给AI处理，降低前端工作量。
整体链路变长，需后端介入。
复杂表单场景、服务端用户。

使用流程：

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

2. 将生成的协议拿到预览地址进行预览。

	1.0 AI生成协议	2.0 后端Ja va生成协议，AI优化
使用场景	简单表单场景、复杂表单场景	复杂表单场景
服务用户	简单场景：非代码用户；复杂场景：前端用户	复杂场景：服务端用户
优点	减少前端工作量	减少前端工作量，发挥服务端代码优势
缺点	非前端用户无法直接修改生成协议	整体链路加长，需后端介入

表格页面

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

使用流程

1. 输入表格配置的描述，包括表名、按钮、搜索配置、表头、操作列等。
2. 拿到生成的表格协议后到页面预览。

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

{
  "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": "年"}
          ]
        }
      },
      ...
    ],
    ...
  }
}

助力运营平台

背景

顺手买需要在双十一前支持商品运营，包括商品运营平台和千牛后台商家端改造。需求紧急，排期爆满，突然插入紧急需求的情况，大家都懂。

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

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

上线效果

商品总览页面支持了文件批量导入、批量操作表单。商品审核页面也实现了功能。

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

后续发展

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

不过有一个

：已有功能越来越多，维护成本也随之上升。页面共用组件意味着任何修改都可能影响所有复用页面。

AI点灯的未来

未来会在更多场景尝试

，然后用AI去处理文本，以此对场景提效。有兴趣的朋友也可以试试看。