Live UI:从被软件塑造,到塑造软件

2025/12/28 10:26

Gemini_Generated_Image_bywl4bbywl4bbywl.png

得益于 Google Antigravity 和 OpenAI Codex CLI 极为慷慨的用量,这几周的业余时间我频繁沉浸在 Vibe Coding 的体验中, 做了很多纯粹满足个人趣味的小工具,在这过程中感觉我的工具观正在被重塑。

我看到了一种软件交互新的可能性,暂且称之为:Live UI。(Live UI 和 Anthropic 、Google 探索的生成式 UI 没有本质区别,主要是借此聊聊我具体的观察和感受。)

在过去,用户使用的软件是被开发团队严格定义的,哪怕你是开发团队的老板,你提出的需求也必须经过方案策划、开发、测试、发布等这几个流程才能实现。

软件迭代是一个不断寻找共性,求取公约数的过程,很难在功能层面满足所有用户的个性化需求。而且开发团队的商业化诉求必然会和绝对意义上的用户体验产生矛盾,需要在持续产生的冲突中小心翼翼地维持均衡。而依托于大模型通过生成代码自主完成任务的能力,我看到了一丝超越现状的可能性。

试想这样的一个场景:用户 A 想要一个简单好用的笔记工具,笔记内容不复杂,几十字的碎片记录而已,但是他在体验了市面上有名的几款软件之后,发现这些软件因为持续不断的迭代和商业变现的诉求,提供了数十甚至上百种他完全不需要的丰富功能。他自然而然就产生了疑问:我只是想记几条简单的笔记,需要使用这么复杂的软件甚至为这些我用不上的功能付费吗?

当下主流的观点是不要在这些已经被充分解决的需求上浪费太多精力,找一款口碑最好的软件开始学习即可。

但在用户决定选用一款软件之后,他慢慢产生了一个新的需求:能不能把笔记转换成待办提醒?而他当初选择的最简洁的笔记软件并不支持此功能,于是他又开始了寻找……

传统的软件是基于某个用户群体共性假设的标品,用户虽然是需求来源,好像在塑造软件,但是其实最终是在被软件塑造的。

借助 Live UI,我们可能可以扭转这个局面,让用户重新掌握塑造工具的主动权。让我们回到用户 A 的例子,他一开始确实只需要一个简单的笔记功能,那让大模型生成一个输入框加一个笔记列表,足矣。随着用户 A 的深入使用,他开始希望能够将笔记转换为待办提醒,于是指挥大模型为他增加了一个待办模块,之后他又需要文字转图片的功能,于是再次要求大模型添加对应功能,如此往复,用户 A 得到了一个只属于他,不断生长的软件,而这个软件到底是不是一个笔记工具,到底能不能提供给有类似需求的其他用户使用,并不重要。用户 A 不需要再困惑他为什么要给用不到的功能付费,因为他只需要为他使用的服务和 Token 付费。

搜索引擎重塑了我们与信息的关系,推荐引擎重塑了我们与内容的关系,而 Live UI 重塑我们与软件的关系。

这一设想当然忽略了大量落地难题,但当我看到 Mac 中运转着完全根据我个人需求而定制的软件,看到 AI 替我打好签名并自动把代码上传到 GitHub ,我相信这一切一定是可以实现的。

unnamed (2).png

#实践

Vibe coding 了一个 macOS 的小工具,叫 FileBox。

我每周在更新 newsletter 的时候需要频繁的准备和上传配图,定期也需要整理一下各种素材,在这种时候 Finder 非常不好用,我希望有一个类似于 Drsfts quick capture 的工具,能够随时在屏幕上呼出,快捷地调用文件。

构建过程的体验非常典型,实现核心功能时异常顺利,调整余下细节时却处处碰壁,今天发出的 1.0 依然非常粗糙,有很多肉眼可见的问题,但我尝试改变思路,不再去纠结这些,边用边改边定制可能是软件的新常态。

这款小工具已经实实在在地帮助我提升了效率,也希望能够帮助到有类似需求的朋友。

github.com

页脚.png