昨天看到一篇文章 这个开源的「AI + 低代码」开发平台绝了，Gitee 上斩获 9.2K Star!，恰逢我也有相关的低代码和可视化方面的经验，这里就谈谈自己的看法，首先过下 VTJ.PRO 支持的功能列表。
- 代码还原，从大屏还原到本地代码
- 现有代码转化，转化为平台支持的代码（事件、参数等）
- 设计稿转化代码
- AI 流程检测
- 多平台
这篇文章不是基于 VTJ.PRO 实现来探讨，只是我自己对 AI + 低代码的一些看法，算是这段时间 AI 学习的一个知识发散输出的一个过程。
我的思考
在我去年开发的可视化平台实践过程中，有一个比较大的矛盾点，就是对于很多定制化场景跟标准组件之间存在差异，需要有一个灵活的方式来弥补，当时的策略是通过开发自定义的组件来暴露能力。
但是在工程实践中也发现存在一些问题：
- 配置起来可能需要了解，因为是在线使用，安装第三方包之类的使用需要熟悉；
- 对于大屏的渲染不是最优，因为存在一个网络加载的过程，初始化看起来有点奇怪；
- 代码体积可能没有办法优化，因为核心是通过 CDN 来加载包名，但是这个没办法来优化体积。
但是在今年随着 AI 的不断发展完全有另外一套玩法，全平台基于 AI 来实现，一个简单的页面划分则为：
- 我的项目
- 项目页面（多页面，可以理解成一个多页面的路由）
如果考虑商业化的，则还可以包含物料仓库等更多模块，当然这个不是这次讨论的重点。
核心
对于 AI 低代码平台我认为最核心的有两个模块：
- 画布核心能力
- 接入 AI 的具体落地方案
画布核心能力
一个个来阐述，首先画布核心能力比较好理解，就是我们组件拖拽到画布区域除了预览，还应当有一系列相关的内置插件部分，还有支持功能的拓展部分，我们可以称为插件合适。
例如：
- 组件的交互，例如如何对组件的属性来修改
- 页面层级的交互，怎么来跳转起来页面，获取当前页面的信息等
- 操作的撤销等，需要维护一个历史记录
- 支持插件的注册，例如我们需要维护的操作历史同步和历史记录回滚都可以通过插件能力来实现
综上基于画布核心能力，我们可以得到一个认知，一个低代码平台比较重要的就是统一协议，暴露底层能力让拓展可以基于插件的形式来进行维护和迭代新功能。例如我们要讨论的方案 2 就是基于协议和插件来实现。
协议之所以重要，是因为对于这种低代码的平台，必须对格式以及事件、交互等有统一、具体的要求，不然就会导致陷入泥潭状态漫天分。
接入 AI
这一步比较庞大，需要思考的点也很多，在传统的 AI IDE 中，更多的时候我们通过对话的形式，Agent 根据对话内容就会创建相关的文件来对文件进行创建和修改，排查问题等。
但是考虑在低代码这样的平台中，我认为从 0 到 1 可能不是完全可取的，因为首先我们的低代码肯定是给没有太多编程基础的人使用
- 不了解代码
- 重复生成多个文件，没有利用到平台架设的便利性，展开来说就是其实就是平台可能内置了很多大屏相关的生态组件库，理想情况下，AI 生成的时候直接复用，然后基于生成的组件进行拖拽布局，结合画布也可以做到很好的微调效果。
之所以内置很多大屏相关的组件库，其实也是为了健壮性，以及充分利用平台的优势，如果只是单纯的一个壳子，虽然也很重要，但是会写很多的代码，从长久来看内置这部分会导致 AI 可以省去很多的工作量。
在 AI 能力这块，从 23 年的对话和 AI IDE 的对话，到最新的各种 CODE CLI 的 AI 工具，可以发现我们更多跟 AI 的配合还是通过对话框的形式来去触发。
有这么多的实践在这里，所以结合平台接入 AI 的最佳路径依然是通过对话框 + Agent 的形式来去使用。
具体来看交互则是：
- 用户输入自己的需求
- AI（微调过的），结合当前的组件库和实践，给出需求拆解后的组件列表
- 通过协议插入到画布的组件物料区域
- 用户拖拽物料到画布区域
- 点击发布
这个就是一个完整的交互流程，不过在真实的场景中也需要考虑很多信息
- 如果超出上下文怎么处理
- 对于组件的微调和修改怎么做
- 对于动态创建的组件我们怎么能实现性能最佳
- ...
可以看到结合 AI 的赋能，我们依然有很多问题需要去解决和完善，这里就一一讨论一下。
-
模型的上下文随着对话的轮次增加大概率是会超出的，解决方案我认为有两个 1 个是选择模型的时候选择上下文比较大的，例如 Gemini，这个支持最高 200M 的 token，很多场景绝对用不完，但是假设模型用的是比较小的上下文，这里可以考虑使用记忆功能，这个是一个比较火热的 AI 研究方向，基于对信息的压缩，让 AI 记忆重要信息。
-
对于组件的微调，我认为依然需要有一个在线的 IDE 提供给用户，让用户修改的时候可以实时看到，此外还应当提供类似 Cursor 这样的直接在编辑器内对话的能力，可以直接对齐内容进行 AI 的修改
这里有一个前提，就是我们在解析用户的对话的时候会根据意图创建多个组件，但是这个组件的划分是一个个大的组件来实现的，这样我们去修改和拖拽的时候更多的时候是拖拽一个模块
- 对于动态组件这个也是需要核心考虑的地方，因为最初最初的自定义组件是基于 iframe 来创建的，这个是导致性能降低的罪魁祸首，但是只考虑性能的最佳实践我认为有两个
- 基于云打包代码来实现，把自定义组件归纳成一个个文件，通过云在线打包工具把代码打包成相关的 js 文件，最后随着平台一起加载
- 基于联邦模块（Module Federation）来实现，虽然本质还是在线加载，但是不是基于 iframe 方案实现的表现也很好，例如 模块联邦 - Rsbuild模块联邦 - Rsbuild
其他
设计稿
这块技术站在这个时间节点来看已经比较成熟了，各家的平台基本都支持 MCP 获取设计稿的信息了，只需要配置填写下即可。
所以如果要做，我们的平台肯定要一个地方暴露和设置的地方，当然如果野心更大一些，我们设置可以把设计平台接进来， 同样基于 AI 生成设计稿，直接无缝插入进来。这也是一个广阔的前景。
代码还原本地
这个功能也非常有代表性，可以显著提升定制化的能力，如果我们的核心架构能力实现足够优秀，这个问题不是一个很大的问题，具体来讲解：
- 我们的平台也就是画布预览的基层可以发布到 npm 上，后续我们还原的话，也只需要给一个初始化的工程结构，里面安装了我们平台的依赖包，我们默认帮他写好
- 通过数据库我们了解画布的相关设置，然后对初始化工程进行修改
- 基于 AI 组件的拖拽，我们直接可以获取到源代码，还原成类似的 vue 之类源码
组装完成后，直接生成 zip 文件给用户，完成整个平台的流程。
多平台
这块其实我觉得还是借助 AI 的能力，我们的画布本身支持相关的缩放即可，预设好相关的响应式能力。
后续生成 AI 的时候，无论是通过微调还是提示词，我们让 AI 了解怎么来适配响应式，结合我们的平台就可以做到。
当然对于小程序这样的平台可能有点麻烦，因为一方面语法对比传统的 web 可能不支持，另外一方面则是小程序的生态以及文档不够多，AI 可能需要专门对这方面来进行训练。
但是一定是可以的，因为我的 nextjs 搭建的博客，就是基本是 AI 开发，支持 pc、平板和手机。
最后
还有很多可以讨论的点，例如关于接口的交互，物料区域的搭建等，甚至延伸来看是不是版本的控制也很重要，以及多人的协作开发？