前言

为提升人效，我们组自研了一个低代码平台，说是自研但其实还是amis为核心的低代码平台，众所周知，低代码平台使用起来都会有一定的学习成本，尤其是在用户体量上来之后，经常会有人来问我如何使用或者让我答疑等等，咱也不是没文档，但是用低代码的各类人群都有，比如产品，测试等。这类人群基础薄弱，根本不想看文档，他们就想很方便快捷的弄出来一个页面。因此，我们推出了智能化低代码计划。

智能化一代

在某天我闲暇之余看到了一篇关于(问答机器人)的文章，我突然灵光一闪，想到了将低代码平台的文档喂给GPT，通过问答的方式帮助用户解决问题，这样用户可以直接问机器人，而不必问我了，于是初版智能化方案营运而生。

实现方案

技术栈我们分别采用了Node + Nestjs + LangChian + React。
1、在我们的编辑器页面，添加一个机器人入口图标。
2、用户输入的文本发送至后端服务。
3、检查是否有向量库，如果有则将用户输入的文本进行脱敏，没有则创建向量库并脱敏。

之所以要这么做是因为，没有向量库是没办法进行向量搜索的，没办法搜索就没办法回答。

4、将脱敏后的文本传入到一个模板中，也就是最后的Prompt(提示词)中。

如： 我希望你作为XXX，帮我XXX, ${ 脱敏文本 }， - 如果不知道答案，只能回答'对不起我不知道'

5、问答结束后，判断返回结果是否失败，如果成功将历史记录存储到数据库，下次提问携带上历史记录利于上下午的建设，如果失败则跳过存储历史直接返回给前端，但是由于各种限制，我这里是直接存入了文件。
最终的一期的实现效果如下所示，对于基本的问题已经能够回答了，但是还不够智能，对用户来说问机器人和问我都差不多，而且如下图所示，它对于用户的问题理解得好像还是有一些问题，把「文本框」理解成了「多行文本框」。初版的机器人还有很长的路要走。

缺陷

1、提问时有50%的几率直接返回「我不知道」，原因是，向量库使用的是本地向量库，部署的时候是多云部署，所以会导致请求有概率打到没有向量库的机器。
2、模式单一，节省的成本有限与直接问开发者几乎没有差别。
3、prompt提示词对GPT引导不足，导致它无法更好的从文档中获取答案。

智能化二代

在上一版的基础上进行了大量优化，
首先是我们将 prompt 进行了一版优化，GPT的回答准确率直线上升。
第二是我们对机器人的形态进行了重构，拆分了三种形态的机器人，他们分别是 组件机器人，表达式机器人，全局机器人。
最后是将多云部署修改为了单台部署，避免出现第一期的问题。

实现方案

1、拆分为三种机器人形态，请求时根据type字段来区分它们。
2、根据type类型的不同可以传入更多参数args，该参数中包含了配置上下文，代码前缀，代码后缀。

配置上下文能让GPT更好的理解用户的问题

3、将参数&用户问题嵌入与type类型匹配的Prompt中发起提问。
4、每种机器人的历史记录单独存放，避免出现提问上下文错乱的情况。

表达式机器人

用过amis的同学应该都知道，表达式是amis中很常用的功能，包括控制显隐，数据映射，数据转换等。而表达式的语法既能使用JS表达式又能使用表达式函数，通常表达式函数都记不住。所以我们打造了表达式机器人来帮助我们编写表达式，减轻我们的心智负担。
核心流程如下：

通过一个AI输入框，输入问题，点击「回车」or「发送」生成相应表达式。
生成表达式后会让用户自行确认是否应用，在用户确认前可对机器人进行点赞，点踩操作。

组件机器人

在我们日常使用低代码的过程中，超80%的时间都是在配置组件，每个组件的配置不尽相同，就算有可视化界面也有一定的查找成本。所以我们推出了组件机器人，通过用户当前选中的组件的配置和用户的问题，来精确的回答用户并将其直接写入到该组件的配置中，高效的完成一次修改，一次修改时间不超过6s。
原理
单个组件的配置比预期的可能要长，一个基础的组件转换为字符串后，字符已然超过100，如果是选中了带子组件的组件，长度可想而知，所以我们采用了两套策略。

• 首先是将我们的模型更改为gpt-3.5-turbo-16k它允许我们传递16k Token量。

Token 计算方式 输入 + 输出 <= 16k， 输入 = 用户问题 + 用户配置 + 预设Prompt + 组件文档，输出 = GPT回答

• 其次是我们将含有子组件的组件，提问时置空其子组件，避免浪费Token。

含children 的组件 排除 type 类型为 select, checkbox 等

对于输入基本已经解决了，但是输出的问题还没解决，为何这么说？
因为输出的 Token 如果让 GPT 按照问题修改后全量返回，这可能导致 Token 不足。
所以我们经过思考后，决定定义一套规则让GPT来 patch，让 GPT 先理解规则和组件文档，再对用户的配置进行patch，最终将修改结果当做一系列操作返回给前端，然后执行相应的修改操作。
核心流程如下：

通过在组件上的工具栏中增加一个机器人图标，点击后出现AI输入框，输入问题，点击「回车」or「发送」生成相应配置并直接应用，对修改结果不满意直接撤回组件修改即可。最终的实现效果如下。

全局机器人

首先是将一期的预设Prompt进行了优化，让其回答成功率和精确度更加出色。对其入口进行了更改，其次是全局机器人入口从顶部工具栏图标进入，转为可拖拽的常驻机器人进入，最后是加入了更多场景的文档包括但不限于公共文档&api文档等等，期望能弥补用户在未覆盖的场景中也能找到合理的答案和需要的文档。

总结

经过此次迭代，不仅节省了我个人的时间，而且提升了低代码平台的易用性，让更多人参与的低代码又往前迈进了一步。后续我们可能会对其继续进行迭代，包括但不限于重构文档，高质量文档对回答准确性有着决定性的作用，采用微调手段让GPT更加符合我们的应用场景。最后，这是我们上线该功能后采集的反馈。
看完觉得还不错的话，麻烦给个一键三连