👉腾小云导读

也许你经历过这种情况：产品和设计同学用一句话就把需求说完了，你抓破脑袋做出来的版本又达不到他们的要求。不如尝试让 AI 承担痛苦，让它理解、拆解并实现一句话需求？本篇作者尝试提出一个自动配置可视化系统，通过自动生成表单解决上述痛点。欢迎阅读～

👉目录

1 简介

2 AI 生成 DSL

2.1 链路拆分

2.2 Few Shot

2.3 仿冒发言

2.4 调优方案

3 实时推送

3.1 开发阶段

3.2 本地 Proxy 代理

3.3 Nginx 反向代理
4 总结

01、简介

很多时候可视化系统是用于团队提升效率的利器，但无论使用者是产品运维还是开发者，都会遇到这样的问题：产品运维要配置可视化系统，有一定的使用配置成本。开发者要理解需求，又有一定的沟通成本。如果 AI 比你更会配置，也比你更容易懂“一句话需求”那会怎么样呢？

比如下面的两个例子，收到制作表单的需求时只有一句话：

“我想生成互联网职业调研”——将这句需求输入，会生成以下效果，系统自动补充了详细需求如：“年龄”、“性别”、“职业状态”、“最关心的互联网领域”、“工作经验”、“学历”、“毕业院校”、“毕业时间”。

“我想要一个任天堂调研”——将这句需求输入，会生成以下效果，系统自动补充了详细需求如：“是否拥有任天堂游戏机”、“最喜欢的任天堂游戏”、“最喜欢的游戏类型”、“最喜欢的游戏平台”。

从上面两个案例看的出来，自动生成的表单能满足基本的需求。

当然，你在正常工作时会收到非常明确的需求。这时你很明确自己想要什么，AI 就会根据你的需求进行输出，尽量不去做更多的拓展。

“生成一个仙剑奇侠传的调研，我想知道粉丝的年龄段分布，性别，想知道他们最爱哪个系列，提供一些最喜欢的角色给粉丝选择”——将这句详细需求输入，会生成以下效果：“年龄段”、“性别”、“最喜欢的系列”、“最喜欢的角色”。

整个展示流程：

AIGC 是零代码的体现，可视化系统则是低代码的体现。

但互联网没有银弹：

零代码的自由度十分受限，拓展性无法满足用户。
低代码通常需要内置大量的业务属性的模版，来降低用户的初始使用成本。
数据更新接入的模型是 gpt-3.5-turbo，需要一些实时数据时仍然生成的是过往的旧数据。

AIGC 的能力是可以很好地弥补这中间的 GAP，AIGC 负责根据实际的用户需求来输出模版，然后用户就在生成的模版基础上进行部分的修改来满足最终的需求。转化到技术侧就是，AI 根据需求去生成满足可视化系统的 DSL 后，并导入到可视化系统中。当我们明确我们需要 AI 实现的目标，下一步就是如何去做了。

02、AI 生成 DSL

DSL 是由人类对特定领域进行抽象的描述语言，在表单引擎这里则是 JSON Schema。要达到最终的 AI 生成 DSL 的目的，我认为有下面几个关键点：

让 AI 更好理解你的输入。
让 AI 按照你的规则输出。

但如何更好地激活 AI 达成这个听起来很简单的能力呢？

2.1 链路拆分

其实上述的关键点就是我当前系统的重要两个环节：

先让 AI 总结和描述需求所需要使用的表单组件和字段含义；
我们拿着 AI 需要使用的表单组件，组合出一个组件使用的例子，通过仿冒发言的方式让 AI 进行学习。

最终 AI 就可以参照我们的要求生成我们想要的 JSON Schema 了。

2.2 Few Shot

如何通过少量提示（Few Shot）让 AI 按照我们的要求输出数据呢？这里我参考了一个 Mr.-Ranedeer-AI-Tutor 的项目，它内置了一个 AI 导师功能来提供一个强大的学习课程能力。推荐大家在 GPT-4 上使用，效果非常的赞。它通过规范的 Prompt 传达给 AI 要做的事情，生成的规则是怎么样的。

这个是其中一个 Markdown 文件，利用这个 Prompt 激活 AI 导师。

当把整个 Markdown 丢给 ChatGPT，按照 Formats 字段，它很好地学习了整个输出的格式。

于是我也按照这样的规则去制定我的 Prompt。

通过上述的 Prompt，我主要做了以下几件事：

提供了组件配置，且规定了 AI 只能使用这里的配置去实现需求。
规定了 JSON 的输出格式，一个 components 数组，一个 requirement 的需求描述字段。
不断调优过程中，制定的其他规则。

最终 ChatGPT 给我们正确返回了 JSON 数据。

用于生成 schema 的 Prompt 和这个也差不多，这里就不展开解释了。

2.3 仿冒发言

Chat Message 的定义中是有三种角色可以定义的 [System, AI, Human]。其中我们可以通过生成 Human Prompt，在我们生成 AI Prompt 来定义 AI 的回答，后续 AI 就会将这个回答的格式进行一定的参考。

在需求生成阶段，我定义的 AI 回答格式是这样的。

最终 AI 的生成格式也是按照我们的格式进行的输出。大致如下：“标题(组件,[选项])”。

和用于生成 Schema 阶段的 Fake Answer 同理，这里就不展开解释了。

2.4 调优方案

AI 在学习如何使用组件的过程中，并不是全量进行学习的，这对 Token 消耗量很大。我在第一步转换需求的任务中，已经收集了 AI 会使用到的 components 列表。然后将 AI 生成错误的组件进行定制化的教学，专门组成一个学习案例，再配合 Prompt 的部分规则要求来纠正 AI。

例如 AI 一开始没办法正常输出带有选项的组件，总会输出 items 来作为选项，而正确的规则是 enum 字段。于是我通过传入组件的正确使用方式来让 AI 学习正确的使用方式。

从输出案例中找到可以 Select 组件的 JSON 规则。

并通过一条 Prompt 规则去强化 AI 的认知。

你可以通过 AI 的返回，来不断优化 Prompt 的规则，引导 AI 往正确的方向进行内容的输出。

03、实时推送

下面快速总结一些 Langchain 的 Stream 方案中遇到的问题：

3.1 开发阶段

我为了系统的整体交互流畅，输出内容这里是参考 ChatGPT 的服务器实时推送方案，使用的是 SSE（Server-Sent Event），客户端则是使用 fetch-event-source 进行数据的接收。

服务器需要做出如下的配置来开启 SSE。

res.setHeader('Content-Type', 'text/event-stream; charset=utf-8');
 res.setHeader('Cache-Control', 'no-transform, no-cache');
 res.setHeader('Connection', 'keep-alive');

在写数据时，结尾必须遵循 data: ${message} \n\n的格式，客户端才可以正常接收。

3.2 本地 Proxy 代理

在开发阶段如果遇到内容并不是持续顺畅地输出时，请检查 Cache-Control 的 no-transform 字段是否有配置，有可能是你本地的 Proxy 导致响应内容无法持续传输到客户端。

3.3 Nginx 反向代理

部署阶段如果使用 Nginx 等做反向代理，实际使用过程中会发现服务器会合并缓存的方式进行返回，让内容输出的交互看起来没有那么流畅。针对 Nginx 则需要更多的配置来优化流式输出的情况。

location /api {
   // 禁用缓冲。代理服务器会立即将上游服务器的响应内容逐段发送给客户端，不进行缓冲。适用于需要实时传输或流式传输的场景。
   proxy_buffering off;
   // AI 生成复杂内容的时间，容易超过 Nginx 默认配置的一分钟。
   proxy_connect_timeout 600;
   proxy_send_timeout 600;
   proxy_read_timeout 600;
   
   proxy_pass http://127.0.0.1:9000;
 }