智能服务卡片平台 STAR
项目背景：
卡片平台是云客服内部的一个 IM 消息的搭建工具
搭建产物：卡片消息(文本+图片+链接+事件)
服务对象是：基金、保险、证券、银行等偏金融行业的公司的客服小二
业务模式是：主要是B to C，B端是业务方的客服小二，C端就是支付宝上的用户(载体：H5 + 支付宝小程序)
业务痛点:
1 相比传统开发，需要一定的学习成本
2 业务复杂度上升后，可视化模式的维护成本上升
3 与现有源码模式更好的互通需要加强
短期规划:
1 提供更丰富的基础物料组件、业务组件、逻辑组件
2 优化源码->搭建模块的交互方式 长期规划:
chatGPT 连接低代码，进一步降低使用门槛
**GPT 的优势 **
openAI 最大的价值：降低AI的技术门槛，让AI小白也能上手，提升工作效率
通过 DSL + prompt 的构建，能更大程度发挥价值
(指令-上下文-输入数据-输出指示符)
S: 情况
业务压力大：很多公司的定制化业务需求，开发同学被需求捆绑
生产效率低：case by case 编码开发，复用率低，生产周期长
设计保障差：各个公司独立设计，不成体系，可控性低
系统耦合：客服系统也和业务强耦合，定制业务一多，整个项目就会很臃肿
T: 目标
1 为了快速满足商家的定制化诉求，同时降低开发同学的业务压力
2 并且能支持PC、H5、支付宝小程序、微信小程序的统一渲染
A: 解决
封装低代码引擎，搭建卡片平台
各个端独立封装 cardLoader 实现异步加载渲染
R: 结果
1 门槛：业务方可以自己拖拉拽生成卡片
2 效率：一次搭建，多端渲染，效率提升
3 体验：产品使用体验统一
4 解耦：业务需求不与 IM 主链路耦合
5 横向输出：搭建系统也支持了兄弟小组的 CRM 可视化表单的搭建
6 丰富IM消息：不再是像(wx/DD/飞书)单纯的文本、图片、链接，而是这几个的组合，表达的内容也更丰富
角色-困难-解决 RPSE
R： 角色
项目发起人、负责人
P：困难
1 判断技术选型，选择符合 IM 业务的方案 (也决定了卡片平台的发展方向)
2 Java后端同学转到其他业务去了
3 IM 卡片跨云通信难
4 培训客服小二，推广使用难
S：解决
1 前期负责封装低代码搭建引擎
2 后期补位Java后端和产品
3 推广、培训(文档、视频)
E：经验
从前端、产品设计，到后端、再到推广运营，一整个流程的成长
传统模式开发的弊端
1 工作量大
2 调整成本高
3 复用性底
低代码开发的优缺点：
优点：
1、开发快效率高
2、维护成本低
3、降低开发成本和部署时间
4、提高团队效率
5、快速完成原型制作
缺点：
1、使用有一定门槛
2、限制专业程序员的使用
3、可靠性和安全性存在风险
4、功能有限
5、复杂业务逻辑，实现的成本高
低代码的本质
一套标准的页面JSON结构/组件描述DSL，屏蔽了源码技术栈本身的差异，提供全新的技术生态底盘,实现低代码可视化开发平台和低代码物料生态
低代码解决的问题：门槛、效率、体验
降低门槛
提升效率、兼容&可扩展性
标准化体验
(市面上拖拉拽的低代码平台很多，轮子也很多，为什么要自己造一个？譬如阿里就有 YiDa、云凤蝶等等产品)
为什么要自己做低代码搭建平台
我是这样考虑的
1 首先，我们分析了市面上开源的低代码搭建系统，页面级别的解决方案，太重了，需要构建、部署、发版
2 其次，搭建的页面数据是存在搭建平台的，在使用的时候，需要跨系统调用，从云客服的后端到搭建平台的后端去获取搭建产物，这样 IM 消息的安全性、实时性、稳定性得不到保证
3 外部搭建工具不能配合着云客服的私有化部署
总结起来，
综合我们的需求是搭建能在云客服 IM 沟通中使用的卡片类型的消息，比较轻量，搭建产物不是页面级别的，不需要构建和部署，而且数据只能存在金融云内。如果我们自己做，IM 沟通中 安全性、实时性、稳定性 能够得到保证，也支持私有化部署。
(最后权衡了 ROI，发现搭建低代码卡片平台这件事情，是一件低优先级但很重要的事情，在业务不忙的时候，确定使用开源的 lowCode-engine 内核，简单封装搭建内核就可以产生消息卡片的 json schema，在 IM 系统中可以像文本消息一样流转...)
(想做、能做、应该做)
方案一 资源 型、 页面 型、 应用 型
搞定设计、创客贴
有赞微页面、淘宝店铺装修、鲁班H5
宜搭、Builder、微搭、云凤蝶
方案四 lowCode-engine
基于 lowCode-engine 拖拉拽生成卡片的 json schema
组件：
物料：Card、 button、 Input、div、img、动画组件、音频组件
画板：视图
页面样式、页面属性、页面功能
保存：生成 JSON schema (默认1.0版本)
数据源：预填死数据、接口异步请求的动态数据
引擎 出码
出码引擎：内置组件DSL -> schema(AST) (componentName、fileName、props(onClick)、css、children[])
渲染引擎：运行时编译 ：schema(AST) -> 端上的渲染引擎编译(react renderer 、rax renderer) -> 可以运行时的code(实时修改实时生效)
Rax 跨端 - 转码
Rax(阿里的跨端解决方案)：支持开发者通过React DSL编写web、小程序、flutter等不同容器的跨端应用
通过 Schema 作为中间态，Rax 转码 AST 文本，来实现一码多端
为什么是运行时
IM 业务场景中：发送卡片就是发送的是带 UI 的消息，最主要的是要考虑渲染问题
0 端未知(适配多端)：IM 消息在流转过程中，不需要任何处理(也不知道发给哪端PC、H5、支付宝小程序、微信小程序)，JSON可以像文本一样传递，到了具体某一端，运行时再解析、渲染。: 中，再去适配渲染，div->div、view、click->onClick、onTap
(onTouchStart/onTouchMove/onTouchEnd)
1 合成事件: 渲染时，渲染组件会通过ref获取组件里暴露出去的方法，并绑定到自己容器上 事件是绑定到渲染组件上的，方便触发事件前统一进行安全校验(sql或 xss数据特殊字符)、错误边界处理、埋点日志上报等操作
2
3 多版本支持: 需要渲染时才能确定使用的react版本、 v18 react.createRoot() 异步增量渲染、-v17 react.render、特别是小程序UI
4 条件渲染: 渲染组件需要知道当前环境是否支持展示卡片，能才展示，不能则展示兜底文案
(弱网环境异步加载：先展示的是兜底文案，加载完成再替换：类似于react suspense)
5 国际化动态数据支持: 数据内容展示需要知道当前的语言环境，展示对应的文案(promise -> dataSource)
事件绑定 click
1 在拖拽生成卡片时，会有事件描述，匹配已经预制的点击type，在渲染的时候暴露出来
2 卡片渲染时，渲染容器组件会通过ref获取组件里暴露出去的方法，并绑定到自己容器上
3 渲染组件发送的数据前会先进行安全校验、埋点日志上报等(方便统一处理)
taro 是怎样支持多端的
底层是通过 babel 插件去转换的
