AI+低代码+语音识别，让用户闭着眼睛开发

上篇文章中提到利用 AI 配合低代码平台，可以让用户快速搭建页面和应用。本文将会对这个问题展开聊聊，不讲概念，直接上干货。

架构设计

在本次设计中，我们考虑到三个要素：AI 平台、低代码平台、语音识别为文本。用户进入应用后，可通过说话来控制运作，应用通过浏览器接口、自建语音识别模型等方法，将用户说的话转化为文本，将文本都给 AI 平台，由 AI 对用户描述进行理解和处理，最后输出 DSL 或 Schema 给低代码平台，再交由低代码平台执行后输出应用。

系统可以与现有的工作平台解耦，只在完成体验后，提交到发布系统进行审批和上线生产环境。

语音识别

语音识别在现阶段已有成熟的方案，不过准确度流畅度等往往与价格成正比。另外，我们平时说话时，往往伴随着思考，语句的中断，或者携带一些口气词（嗯、哼、额、哦……）需要语音识别系统加以处理。当然，只要语句完整，LLM 总是能结合上下文理解你说的话。

DSL/Schema

基于文本来驱动低代码平台执行命令，我们往往需要设计一套 DSL 或 Schema 来为低代码平台增强接入 AI 的能力。Schema 往往是具备严格结构的数据块，可以被我们的编程语言直接使用；DSL 则需要有一套编译器/解释器来处理。采用 DSL 方案有利于 AI 生成合理的文本，tokens 较少也可以起到节约资源的作用，而且往往可以让 AI 更容易准确生成，毕竟一旦你选择 DSL 方案，那么就会有一套关于该 DSL 的语法说明文件。而严格结构的 Schema 往往由于数据结构过于通用，反而让 AI 无所适从，准确度降低。

提高 AI 生成准确度

一种方案是 examples，也就是提供例子，让大模型可以从例子中顿悟你这门 DSL 语言的奥秘，然后根据用户说的话，生成对应的 DSL。另一种方案是模型微调，通过收集用户百花齐放的输入，主动帮用户写 DSL，以 few-shot 进行微调训练，得到一个能够对当前业务场景下有更好响应的模型。我觉得，这两种方案可以同步进行，早期的时候以第一种为主，等积累较多 case 之后，以第二种为主。

Auto 工作流

在本场景下，用户本身并不做编程、逻辑处理、低代码编辑等工作，所有这些过程性的工作，都是由 AI 来完成。我们需要将 AI 接入一套 Auto 系统，或者说，我们需要把我们的 AI 开发成 Auto 系统，在系统中，AI 被分配不同角色，对用户的意图进行理解和分析、任务拆分、调用执行接口等。对于用户而言，从开始工作，到体验修改，提交给发布系统，全部都由 Auto 系统对用户指令的理解而自动发起和完成。在之前的文章中我提到过，类似 AutoGen 等框架可以完成类似的系统能力。

为障碍群体发声

障碍群体包含残障群体、老年人、行动不便的正常人等。普通人的一生中，有约 20%-30% 的时间处于障碍中。根据中国残疾人联合会发布的数据（2023），中国有约 8500 万残疾人，占全国总人口的约 6.36%。这个群体包括视力障碍、听力障碍、言语障碍、肢体障碍等多种类型。根据国家统计局的数据，2019 年中国 60 岁及以上的老年人口达到了 2.54 亿，占总人口的 18.1%。人总有生病、困难、老的一天，在这些处于障碍中的日子里，我们能否顺利的参与到工作中呢？

通过 AI 来改变传统的工作模式，不一定需要鼠标键盘，甚至不需要屏幕，产物不局限于应用软件，也可以是智能硬件等。通过 AI，即使障碍人群也可以完成开发工作，生成服务于障碍群体的软件或硬件，让天下人各享其幸。

结语

在电影《HER》中，大部分人只关注男主西奥多和人工智能萨曼莎之间的情感纠葛，但是你是否还记得西奥多的工作及其工作形式呢？男主心思缜密，情感丰富，他的工作是帮人写出感人至深抚人心扉的信件，他的工作形式，是坐在工位上像念诗一样，通过麦克风撰写。也许，我们大部分人的日常，都不太可能被拍成一部电影。但或许，我们大多数人的生活，本就比西奥多精彩。