疯狂摩擦 AI 探索

低代码

还记得之前提到的低代码 Chat BI Agent 吧，在仪表盘的功能告一段落后，紧接着就需要实现报告功能，在支持报告功能后就也可以使用 Chat BI Agent 做一些报告相关的 AI 辅助。

通常可以做报告的生成、解析分析，让生成报告变得更智能快捷，让分析报告变得更结合数据。

已经基于 Tiptap 开源编辑器引擎实现了 MVP 报告功能，通过对 Schema 进行操作以实现 AI 辅助，天然就形成了一个自然的转换。

当然目前 MVP 报告功能还不足以提供更好的报告风格，比如背景图、水印、分页、纸张大小、占位替换符、逻辑控制符等能力。

不过从目前来看，持续迭代是可以看到一个不错的效果的。

通过对 WebContainer 运行的 Vite 插件进行迭代，支持在 <template> 标签的 DOM 上添加对应的文件路径信息，用于在外侧可以通过鼠标点选方式获得用户具体要修改的文件位置等信息。

功能实现方式参考了 code-inspector 的源码。

通过选择器 + 用户描述，可以让用户更加轻松的使用 AI 来达成想要的变更，并且避免在整体上下文中重复 Token 引起的误修改情况。

另外在借鉴功能的时候，发现 readdy.ai 的选择器支持直接修改内容，这是一个不错的能力，因为有些修改并不需要再经过 AI ，因为这些修改过于简单。

通过调研发现为 DOM 开启 contenteditable 属性即可实现，只不过目前从 readdy.ai 体验看来， readdy.ai 的实现更像是原子化的低代码结构，选中的节点并不是 DOM 节点。

而我们内部的项目选择的则是 DOM 节点（源码级别的定位器），所以关于选中后可修改的文本能力在粒度上还需要更清晰明确的定义才好实现。

场景也比较特殊，是通过 AI 能力修改交付在现场的前端代码。

分别实践了两种方案思路：

一是研发一个 Chrome 插件，通过在现有项目中植入类似文件路径信息，结合 Chrome 插件选取功能，生成给 IDE 使用的提示词。通过 IDE 读取前端编译产物结合提示词对编译结果进行修改。

二是提供一个配套服务，也是通过在现有项目中植入类似文件路径信息，提供对应路径模块的导出功能，将源码对应的 AST 对象导出，在 IDE 中进行修改，修改完成后通过服务的导入功能进行导入 AST 后编译成源码，再重新执行前端代码编译生成前端编译产物以达成修改。

AST_Control_Service

两者相对各有利弊，都需要在原项目上添加辅助插件以提供路径的生成，直接修改编译产物的好处就是快，但是相对 AST 来说产生错误的可能性更大（当然也不一定）。

也是一种很特别的 AI 应用场景探索。