AI已经成为替代编程工作的火热话题，本期主要来聊一聊，如何在低代码平台的建设成果上，利用LLM的能力，可以实现简单的智能化UI生成需求。
在线收听
喜马拉雅：点击播放
你还可以在苹果自带的 Podcast 应用、小宇宙APP、QQ音乐中搜“Robust”找到我们的节目收听。
捐赠支持
求打赏🙇如果你觉得 Robust 这样一档技术类的谈话节目还不错，希望我继续做下去，不妨打赏支持。
内容摘要
过去1年，LLM-based已经成为AI的新范式，于此同时，自然语言生成图片、视频、数字人等一系列关联领域都取得了巨大突破。在今年2月，出现了被称为史上第一个全能AI程序员的Devin，而上周也有消息称阿里入职了工号为AI001的全智能程序员。通过AI替代以往的编程工作，已经是被验证的可行路径，只不过目前的成熟度还不够，后续的发展仍然有待观察。对于前端开发者而言，我们需要有警惕感的同时，也应该思考，如何利用AI技术，提升自己的开发效率，以在激烈的竞争中出类拔萃。今天，我们就要来聊一聊有关AI生成UI的话题。
在前端，我们在某一个无法用单一词汇来描述的领域，有着非常执着的追求，那就是尽可能的减少代码层面的编写，快速完成UI输出。在这一追求下，从古至今衍生出来很多技术，例如最早的网页制作工具frontpage以及其继承者dreamweaver，其后的H5编辑工具及其继承者页面编辑器，过去几年这一路径演变为风靡一时的低代码运动，以及D2C（Design To Code）运动。
前端界一直在寻求一种可以根据需要自动生成UI界面及其交互效果的一劳永逸的方法，但即使出现了低代码这样的方案后，仍然无法成为新的主流范式，直接通过code编程写UI还是目前的主流。在低代码方案中，核心问题在于，低代码平台无法满足灵活的UI效果需求，以及无法满足复杂的逻辑判断需求，而一旦一个平台尝试去解决这些问题，就会发现低代码平台的使用困难度指数级上升，这种使用学习成本，以及使用所消耗的时间，不亚于直接使用代码来编写UI。
由此可见，在低代码的发展中，我们不能一味的追求理想化的全能平台的目标，一旦追求全能，就会陷入成本指数级上升的窘境。而通过低成本搭建一个可以满足当前业务需要场景的低代码实现，虽然不能复用到其他场景中，但是只要能在当下场景中被反复使用，赚回成本，就是不错的选择。因此，在过去两年中，我们鲜有再见全能型低代码平台的产品出现，因为任何全能型低代码平台，都无法绝对满足真实的业务需求。
在低代码运动中，我们收获了一些成果。而这些成果的沉淀，却在今天带来了转机。
前几天，一个名为open webui的项目引爆了社区，这个项目基于LLM，让开发者可以通过自然语言来描述搭建web页面。和以往D2C等一次性生成UI不同，openwebui支持通过自然语言实时的连续的反复的调整UI，以对话的形式逐步调整界面，最终获得你满意的效果。
告诉它哪里应该放什么元素，颜色是什么，高度如何……有没有回忆起产品或设计同学站在你的身后指着屏幕指导你修改界面的场景。基于openwebui，你可以换一个身份体验一下。
不过目前来看，openwebui还只能通过语言描述来工作，而不能把图像（设计稿）、鼠标动作等因素囊括起来，功能上感觉还是比较初级，毕竟语言所表达的往往不够准确。
但是，我之所以对这个项目如此感兴趣，在于它基于LLM-based AI提供了一种在AI时代进行UI生成的模式雏形。接下来，我将基于我自己的一些经验和想法，分解利用LLM-based AI实现UI生成的技术原理。
我们都知道，web UI界面是靠HTML5、CSS3和ES标准完成的，我们用ui框架，如react、vue等就是把这些最底层的原生实现封装为高级的框架，从而提升开发效率。而在这些框架的基础上，我们又出现了很多组件，这些组件包含了UI的结构和样式，甚至交互效果都固定了，因此，这些组件可以被抽象化，只要有组件名和对应的props参数，即可得到对应的UI效果。而低代码平台则可以利用这些组件，在平台上完成布局，以及组件props参数的配置，从而输出对应组件体系的界面。在低代码平台上，我们通过某种Schema数据结构来描述布局和组件调用规则，在实际渲染或生成代码是按照该数据结构真实的载入组件来完成渲染。而这里的Schema，往往可以是纯文本的，因此，一个低代码应用原理，可以被认为本质上就是一种配置文件的生成。既然是纯文本，那么也就意味着我们可以让LLM来生成它。
没错，讲了这么多，我们终于让LLM登场。现在，我们的目标切换成了，如何让我们的AI系统，可以通过LLM应用，实现从自然语言描述到Schema数据的生成过程。
LLM应用的发展过程有好几个阶段，你可以关注我的公众号 wwwtangshuangnet 阅读相关文章了解。如果是早期，我们主要强调的是 prompt 工程，利用大模型的推理、思维链等特性，想尽办法让大模型可以在推理过程中按照Schema的特征进行生成。但是，这种方法效果非常差，一方面我们需要提供庞大的example和schema描述，toekns太多，性能扛不住，另一方面我们必须让自然语言是在描述schema，而非描述UI，这显然是不符合预期的。后来，我们尝试使用lora、fine-tune等微调方案来让模型更懂schema，这样就可以用更少token，但是这种方案仍然是要求用户自然语言描述中，必须是在熟知schema的前提下进行，否则很难对应到schema中。
可见，这一时期，想直接通过描述UI长什么样子，到我们获得Schema文件之间，存在着巨大的鸿沟，通过描述Schema信息来生成Schema，虽然比拖拉拽看上去更快，但准确性却并不理想。总而言之，少那么点意思。
今年，也就是2024年，LLM的应用进入到一个新阶段，通过设计大型工作流架构来完成任务目标成为新范式。过去，我们往往希望通过LLM一次或几次对话就能一步到位得到我们想要的数据，在经过这1年的社会毒打之后，发现是不可行的，纯粹的LLM交互是无法提升效果的。吴恩达在其研究中发现，如果只是单独依靠一两次对话就想获得想要的目标，其成功率，GPT-3.5能打3分，GPT-4能打6分，但是如果设计出恰到好处的工作流，即使GPT-3.5也能打到9分。
什么是工作流呢？简单讲，就是不妄想通过简单的1个步骤就立马得到结果，而是有规划有策略的进行多轮对话，让不同的Agent担任不同的角色，分工合作，再加入一些验证、调整等环节，从而让走完整个流程后出来的结果更逼近我们想要的结果。
可以说，2024年所有的AI应用都在利用这个思路，包括最新的大模型底座架构，也在强调多专家模型的网络结构。也就是说，整个业界都意识到，单纯靠一个LLM单打独斗是无法高效实现目标的，通过系统化的任务拆分能让效果瞬间翻倍。这种分工协作思想，是今年AI应用架构的核心思想，也是我们这段时间看到各类效果不错的AI产品令人惊艳的原因。
回到我们的主题，当用户在对UI进行描述时，openwebui将整个任务进行了划分，通过不同的阶段、不同的模型调用、不同的任务目标、不同的工具调用，最终让生成的代码更为逼近用户描述的目标。如果再结合我们上文提到的，我们通过微调，可以让大模型可以根据用户描述获得更逼近与我们Schema结构的输出。这个过程本身就有点像一个开发团队的工作过程，产品描述需求，产出交互稿，设计根据需求产出设计稿，开发根据需求和设计稿产出代码。通过这种分工协作，虽然用户不懂专业的编码过程，但是只要他可以描述正确自己的需求，就可以得到对应的结果。
由于我们已经有低代码的成果，因此，利用低代码平台现有的能力，把低代码平台作为一个第三方工具，挂载在AI系统上，当上述工作流运行到某个节点时，把低代码平台作为工具进行调用，就形成了符合眼下Agent架构的合理模式。
这里其实有一个细节，就是workflow执行调用工具任务时，需要向工具传参，而这个参数往往是上游的节点中的LLM生成的，这个参数应该就是我们需要的Schema文件。
这样，就形成了一个完整的闭环。
不过这里我没有详细展开当下业界主流的workflow架构模式，以后有机会的话，会专门做一起节目来讲。
可以看到，从路径上讲，用自然语言描述来生成UI是完全可以实现的，而且openwebui还有一个特点，就是可以通过自然语言来对界面进行调整，这一点也是非常友好。如果可以在加入鼠标控制的能力，配合上语音识别，那就更加有意识了，我们可以通过鼠标点击某处，然后说话“这个地方改为蓝色”，就可以修改出我们需要的效果。这样的场景相信也并不难实现。
好了，本期详细阐述了用AI生成UI的技术实现原理。随着LLM技术的不断发展，我们前端会逐渐受到影响，只有不断学习和进步，才能重复利用更为先进的工具提升我们的开发效率，让我们的开发更加有意思。
