聊天框不是 SaaS 的终局:AI 时代,软件界面会长成什么样?

正文共约1850字，预计阅读时间5分钟

聊天框不是 SaaS 的终局

AI 时代，软件界面会长成什么样？

01 ｜ 对话式交互，为什么没有赢

这几年，不少软件都尝试把 AI 以对话的形式嵌进产品里，但几乎都不成功。我认为原因至少有三个：

第一，打字没有点选快。 UI 的本质，是把高频操作"固化"成按钮——鼠标点一下就完事。如果每一次小操作都要先组织语言跟 AI 说一段话，效率反而是倒退。而且对话是线性的，往回翻、全局浏览信息，都很别扭。

第二，Token 烧的是真金白银。 每一次对话都有成本，同样一个操作，传统软件点一次就行，对话式却每次都要重新提问、重新生成，一遍遍地付费。更要命的是，这种交互还不保证有效——描述稍有偏差，这一轮输出就白烧了。

第三，这个能力谁都有。 就算你把某个业务环节 AI 化了，用户拿通用 AI 软件照样能干，而且通用大模型迭代更快、效果更好，自研的那点能力随时会被追平。

那 AI 应该以什么方式进入软件？

02 ｜ 一个辩论赛计时器的启发

这个思考来自我最近的真实经历：由于工作需要，我想在网上找一个辩论赛用的计时器工具。按理说，"辩论赛计时器"是个再常见不过的小工具，应该到处都是。但真正去找的时候，才发现找到一个好用的并不容易，于是我就想自己做一个。

如果按传统思路做这个软件，它一定会做得很"重"：辩论赛有立论、攻辩、自由辩、总结陈词等环节，每个环节正方几分钟、反方几分钟、超时怎么提醒、环节怎么切换——所有差异都要变成"设置项"。

但用 AI 来做，方法完全不同。只需要把一份比赛规则交给 AI，它就针对这份规则生成了一个专属计时器，我不需要任何设置页面。如果规则变了，那就再生成一个。

设置项消失了。因为"设置"的本质，是在一套通用软件上模拟个性化；而当"生成一个专属软件"的成本趋近于零时，设置就没有存在的必要了。

03 ｜ SaaS 的困局

计时器只是一个小工具，但它背后的问题，是所有 SaaS 厂商共同的困局。

为了服务千差万别的用户，厂商不得不在同一套系统里堆砌海量设置。对单个企业来说，这些设置一旦调好就常年不变；但对厂商来说，用户众多、细微差别无数，只能把每一个可能的差异都做成配置项。

这就是传统 SaaS 最大的结构性矛盾：用户的需求变得很快，而软件的架构改得很慢。 一个想法从提出到变成可用功能，要等版本、等排期。于是行业里发明了"最小可用原型（MVP）"这样的概念来安慰自己——先做个最糙的版本给用户凑合用。

04 ｜ 把前端交给用户去定义

既然往系统里堆设置项不是出路，那 SaaS 应该长成什么样？我的答案是：把前端交给用户去定义。

我把它称之为"千面系统"：前端千人千面、由用户自己定义、快速生成、随改随用的界面。

在这个结构里，聊天交互不会取代传统 UI——它真正的角色，是帮用户以最快的速度做出他最需要的那个 UI，然后退到幕后。

这个模型下，Token 成本也不会失控，因为界面是"用完即固"的。界面一旦生成、被用户认可，就可以固化下来，变成一个普通的前端页面正常使用——之后每一次操作都是常规的点选，不再消耗 Token。用户先和 AI 一起"迭代"出趁手的界面，然后沉淀为常态化运行，而不是每次进系统都先让 AI 现做一个界面、再开始干活。一次生成，长期使用，这本身就是最大的成本节约。

05 ｜ 真正的壁垒：数据的同一性

与完全个性化的前端相匹配的，则是后端完善的数据管理。数据结构的设计复杂度和对业务的覆盖深度，才是 SaaS 厂商真正的壁垒。

举个例子，我们学校有一名体育老师，他想做个小系统。按传统做法，得立项、审批、报价、开发排期，一套流程走下来根本等不起。于是他自己用 AI "手搓"了一个信息系统，初始数据自己手工导，就在自己电脑上跑着用，玩得乐此不疲。

这个系统好不好？对他自己是真好。但问题也很典型：他的数据和学校主系统完全不通，学校根本拿不到这些数据。

一名体育老师凭一己之力就能搓出自己趁手的系统，如果他能直接在学校的主系统上自定义出这套界面，数据孤岛的问题就不存在了。

06 ｜ 回归用户价值

其实科幻电影早已拍过类似的场景：《流浪地球2》里，人类要在月球上建设基地，AI 不是搬来一套通用软件，而是根据这个具体场景，即时编写出一套专属的操作系统。

但无论如何进化，落脚点一定是用户价值：不是把"点选"换成"聊天"就算 AI 化，而是尽可能个性化地满足用户的真实业务流程，一旦稳定下来，就常态化、可靠地运行。说到底，AI 不会让软件都变成对话框——SaaS 的未来，是后端统一管理数据，前端交给用户定义。

——END——