LUI系列的上一篇介绍了什么是LUI、LUI的本质特征和优势。本篇我会介绍LUI与GUI（图形交互）的关系，以及未来什么样的APP会留存。

如果你看了我有关LUI主题系列的第一篇文章，我相信你的认知一定得到了一定程度的清晰甚至是升级。你应该已经认识到，未来人机交互的范式是属于LUI的，因为它是最灵活最直接的。GUI可能是确认，可能是一些多选项下的选择、确认。

未来GUI和LUI的关系会是怎样？

LUI增加了灵活性，但是降低了直觉性。具体来说，LUI在给人直觉引导方面，仍然有不如GUI的地方，比如初级用户面对一张白纸会很迷茫，不知道自己可以做什么。LUI的学习曲线过于陡峭，什么都依赖于用户的主动发现，这不是好的on-boarding的过程。GUI给了更多的限制，但也让选项和路径明显，大家上手会更轻松。

GUI是LUI的内容

试想一下这样一个场景：你对豆包说：帮我推荐一下附近1公里内的火锅店。豆包识别了你的意图、调用了地址API查到了你当前的地址以及天气情况、再调用点评的API（理想情况~）按照评分和菜色读取了商家列表，再读取的你的偏好数据（比如你来自重庆等等），帮你推荐了5家火锅店并以卡片的形式展示在聊天框内（GUI），你可以点击卡片查看商家的详情信息、评论等。这就是一种典型的未来LUI与GUI的存在关系。

当你使用豆包或者ChatGPT 的时候，你跟它聊天（即 LUI ），它可以根据你对它说的要求生成你需要的图表、代码乃至软件，然后，你可以在这个新鲜出炉的软件界面上（即GUI上）点点戳戳。 也就是说，在这个场景里，在你跟AI 的对话中（LUI），GUI 被作为对话内容的一部分，生成出来，给到你。

也就是说，软件会成为 LUI 的内容。

搜索引擎本身就是一个超大型的软件，如果搜索引擎成为LUI的内容会怎样： 如果搜索引擎成为 LUI 的内容会怎么样？当你跟 AI 说“我想找XXX”，它不是返回一个有搜索结果的网页，而是生成一个搜索引擎——专门为你的搜索请求新鲜生成、特别定制的搜索引擎！ 它有特定的GUI，专门为你这次查找任务所定制。 它有特别定制的搜索算法，同样为你这次查找任务定制。 它有特定的后台任务、工作流、Pipeline，以及对应所有这些的后台代码…… 它其实就是一个 Agent。

未来什么样的APP会留存？

说了这么多颠覆性的观点，难道现在的这些APP在将来都要退出历史舞台啦？未来哪些APP会幸存下来？ 现在的软件其实基本都是按照角色和场景拆分出来的：什么样的角色、什么样的场景下用什么样的软件。现在看起来，如果一个软件服务的是单角色、单场景，大模型很容易把它击穿掉，这个软件很容易变成通用型的能力。如果是多角色、多业务流在组织内的协作软件，它会相对更复杂一些（如B端软件）。

另外，用户侧的产品冲击很大，因为用户的切换成本非常低，有变化，用户很快就变了。但是，客户的切换成本是很高的，所以越靠近客户侧的产品，它其实越能承载AI带来的这些变化。因为它在客户内的协同网络越复杂，反而变成加强它价值厚度的一种可能。数据肯定是一个很重要的点。另外，客户侧的产品，影响决策的要素多。特别是多角色、跨部门的时候，往往要共同去做决定，这对组织来讲是有成本的。用户的话，好不好用、谁便宜，自己就定了，不需要开会商量，是一个消费品的逻辑。所以客户侧的产品是可以相对容易守得住，可以承载变化的。

本人有话说：本人恰巧B端（SaaS）、C端产品都做过，对两者的产品方法论都有一定的理解。SaaS产品的一个重要指标是续费率，我认为单纯从软件本身的使用角度来看，客户续费的原因主要是：用得挺顺的了，从上到下的员工都用惯了，跟业务流程也磨合地很好了，有用的数据也积累了一堆了，真要切换需要很高昂的成本（各个部门各个角色的重适应）以及数据的废弃；而C端产品的护城河，更多的是内容（或者说服务，比如dy提供的是一种娱乐服务，tb提供的是买卖服务，外卖提供的是一种餐饮服务等等），如果有一天，xhs的创作者集体搬迁到dy，或者tb商家全部入驻到jd，那APP本身也就剩下了个空壳子。

本篇介绍LUI与GUI（图形交互）的关系，以及未来什么样的APP会留存，下一篇我会介绍LUI如何进行落地。