不知道你是否曾经听过一个词，叫做低代码平台。它的核心定位是让非专业开发人员（如业务分析师、运营人员等）或专业开发人员能够以最少的手工编码方式，快速构建和部署应用程序。通过可视化的界面、拖拽组件和预定义的模板等方式，降低软件开发的门槛，提高软件开发的效率。为了让非专业开发人员也能使用，这些平台对底层的代码进行封装，将功能转变为可视化的组件供用户使用，代码对于用户完全透明。比如像现在用于构建ai智能体的一些平台（蚂蚁的芝士饼，字节的coze等），这些平台提供了一些基础组件能力，能够让非专业开发人员基于这些基础组件进行快速的应用构建。他们的交互方式如下图所示。但通常低代码平台会面临这样一个问题：对于专业人士来说显得有点鸡肋（还不如敲几行代码），对于非专业人士来说又显得复杂（需要拖拖拽拽，出问题又不知道怎么解决） 。这个问题我感觉是出现在交互方式上，通过拖拽这样搭积木构建应用的方式还是比较繁琐，对于用户来说可能还是不太友好。那么，低代码平台有没有更还的交互方式呢？
在大模型应用发展起来之前，可能最最简单的方式只能是拖拽了，因为应用本身不具备意图理解和推理的能力，无法让用户以更简单的方式进行交互。但随着大模型应用的兴起，一种更新的交互方式逐渐呈现出来。
这种交互方交互方式就是让用户通过自然语言来描述和修正任务。比较典型的场景是使用Cursor构建应用。最近体验了一下Cursor，体验很好，感觉这就是一种理想的低代码交互方式。 当使用Cursor构建任务时，我只需要向Composer用自然语言描述任务，Cursor就能够自动完成文件生成和代码修改。并且如果有实现有问题，可以直接将问题描述给Composer，它会自动完成修改。整个过程中虽然涉及到代码的生成和修改，但对于用户来说，其实完全可以不去关心代码，这对于非专业人士也是友好的。那么参照Cursor的使用，我感觉未来低代码平台的交互方式可能是如下所示：
代码编辑区、文件目录列表、控制台在此时的作用可能不是用来做专业的代码开发，更多的作用是用来做校验，比如当运行错误提示在某个文件某一行出错的时候，我们可以可视化的将这个信息选中提取出来交给Composer。剩下的其他工作完全交给Composer完成。
感兴趣的小伙伴可以去尝试一下Cursor。另外通义的代码模式好像也快要上线了，应该也具备类似的能力。后续可以关注体验下。
