引言
若将时间拨回今年年中，当 Google 发布那份关于《Simulating a neural operating system》的技术报告时，如果你问我对 Generative UI 的看法，我或许会觉得这是一个迷人的技术愿景，却难以触及现实。但站在年末的当下，回望这一年，尤其是目睹了 Gemini 3 等模型所展现出的惊人跃升，我不得不承认，自己之前的看法或许有些保守了。
坦白讲，在 AI 概念层出不穷的当下，保持适度的怀疑是一种美德。确实也不少人冷眼旁观，视 Generative UI 为"代码生成"的旧瓶装新酒；即便是 Google 最近发表的论文，也诚实地揭示了当下的两难困境——用户虽然偏爱千人千面的界面，却难以忍受生成过程中的等待（"Our evaluations indicate that... This evaluation did not take into account generation speed."）。
然而，当我们拨开这些落地层面的迷雾，依然能感受到一种底层的震动。透过这些尚显粗糙的原型，我们似乎窥见了 UI，乃至整个互联网行业诞生以来最根本的一次范式转移。
Generative UI 所蕴含的变革力量，我认为远不止"动态生成一个界面"这么简单。在接下来的篇幅中，我希望跳出单纯的技术视角，尝试从过去我们如何打造互联网服务的维度切入，去探讨它可能带来的颠覆。鉴于其技术原理并不晦涩，本文将简要介绍定义，并以此为契机，静下心来聊聊它到底"意味着什么"。
Generative UI 是什么？
目前 Generative UI 的定义呈现出一个从严格到宽泛的光谱。不同组织基于各自的技术能力、应用场景和理解角度，对 Generative UI 有着不同程度的诠释。
Google Research：最本质的定义
在整个光谱中，Google Research 的定义最接近 Generative UI 的本质。在他们的论文《Generative UI: LLMs are Effective UI Generators》中，他们给出了这样的定义：
Generative UI is a powerful capability in which an AI model generates not only content but an entire user experience. Dynamically creates immersive visual experiences and interactive interfaces — such as web pages, games, tools, and applications — that are automatically designed and fully customized in response to any question, instruction, or prompt.
这个定义的核心在于三个关键词：完全生成（completely generated）、实时（on the fly）、定制化（fully customized）。
完全生成 vs 组件组装
Google 强调的是真正的"生成"——从无到有地创造界面，而非从预定义组件库中选择和组合。这是一个根本性的区别：
-
组件组装：LLM 从有限的组件集合中选择、排列、配置参数
-
完全生成：LLM 直接生成界面的代码和结构，没有预设的组件边界
在实际落地过程中，组件组装的思路因为其可落地性更为工程所偏好，后面会再展开。但完全生成是更加面向未来的。
用户偏好的验证
Google 的评估研究揭示了一个关键发现：
Our evaluations indicate that, when ignoring generation speed, the interfaces from our generative UI implementations are strongly preferred by human raters compared to standard LLM outputs.
这句话有两层含义：第一，完全生成式界面相对语言模型的标准输出（Markdown, Pure Text）确实能带来更好的用户体验；第二，当前的最大瓶颈在于生成速度，而非生成质量。
范式意义
Google 将这个工作定位为"fully AI-generated user experiences"的第一步，其愿景是：
Users automatically get dynamic interfaces tailored to their needs, rather than having to select from an existing catalog of applications.
不是改进现有应用的界面，而是让"应用"这个概念本身变得流动——用户不再需要在 App Store 中寻找和下载工具，而是通过自然语言描述需求，AI 即时生成满足需求的完整交互体验。
其他立场
守序善良：CopilotKit 的系统化分类
CopilotKit 代表了工程实践中的系统化思考。他们定义了三种 Generative UI 类型：
-
声明式 UI（Declarative UI）：开发者预定义组件和逻辑，LLM 只负责选择和填充数据
-
混合式组装（Hybrid Assembly）：LLM 可以组合组件并调整布局，但仍在预定义的设计系统内
-
完全生成式（Fully Generative）：LLM 生成全新的界面代码，最接近 Google 的定义
此外，CopilotKit 还通过 AG-UI 协议（Agent-UI Protocol）标准化了前端与 Agent 的通信方式，这为 Generative UI 的工程落地提供了具体的技术路径。他们的价值在于：既建立了清晰的概念分类体系，又提供了可落地的工程方案。
守序中立：Vercel AI SDK 的实用主义
这个思路的延伸便是 MCP-UI：mcpui.dev/guide/intro…
Vercel 提出了一个类比："UI version of function calling"。
在他们的实现中，UI 组件本质上是函数，LLM 根据应用状态决定调用（渲染）哪个组件。这延续了 Function Calling 的思路，但将调用对象从后端 API 扩展到前端 UI 组件。
这种方法最实用：既保留了开发者的控制权（通过预定义组件），又引入了 LLM 的智能决策（动态选择组件）。对于现有 Web 应用的 AI 化改造，这是阻力最小的路径。
混乱善良：Anthropic
Anthropic 的"The Generative Computer"概念，其实和 Google 并没有太大区别，但定义上最具哲学意味：
Software exists only because users imagine it in this moment.
避免误用
在这些定义中，有一个最常见的混淆需要澄清：
UI Code Generation vs Generative UI
-
UI Cod Generation：开发阶段通过自然语言生成静态代码和界面（如 v0.dev、GitHub Copilot）
-
Generative UI：运行时根据上下文动态生成界面组件（如 Google 的 Dynamic View、Anthropic 的 Generative Computer）
核心区别：生成的时机（开发时 vs. 运行时）和对象（代码 vs. 界面）完全不同。
UI Code Generation 加速的是开发流程，生成的代码最终会被编译、打包、部署成固定的应用。而 Generative UI 改变的是应用的运行方式，每次用户交互都可能触发新的界面生成。
两者都是 AI 驱动，但服务于不同的范式，想象空间自然也有所不同。
Generative UI，不仅改变 UI
UI 定义了软件
在深入探讨 Generative UI 的变革之前，我想先退一步，思考一个容易被忽视的问题：UI 在软件中究竟扮演什么角色？
长久以来，我们习惯把 UI 看作"展示层"或"皮肤"——似乎它只是业务逻辑之上的一层装饰。但当我们仔细观察，会发现这个理解可能过于简化了。UI 实际上从根本上定义了软件是什么、能做什么、如何被使用。只有理解这一点，我们才能真正理解为什么 Generative UI 的变革会波及整个软件工程领域。
让我们从一个基础问题开始：什么是软件？
如果仅仅是算法和数据处理逻辑，那还算不上软件产品。一段排序算法、一个推荐系统的模型，它们是逻辑，但不是软件。真正让逻辑变成可用工具的，是可交互性——用户能够通过某种方式与逻辑对话、输入需求、获取结果。在现代软件中，这个"可交互性"的具体化就是 UI。可以说，没有 UI，业务逻辑只是休眠的代码；有了 UI，逻辑才成为可体验的产品。
但这还不是全部。UI 不仅定义了软件是什么，它还悄然划定了软件不是什么。
这个观察听起来有些反直觉，但传统 UI 的限制其实发生在两个层面：
功能的可见性
用户只能使用"暴露在界面上"的功能。即使软件具备某个能力，如果界面没有对应的入口，这个能力对用户而言就是不存在的。
比如剪映，我们可以想象通过修改草稿，来实现几乎任意的剪辑行为。但在实际使用中，你的所有操作都被简化到了界面上的那几个按钮、滑块和预设选项中。绝大多数用户永远不会知道，背后还有更大的可能性空间等待被探索。功能的存在，不单单取决于代码能做什么，而取决于界面选择暴露什么。
流程的固化
即使功能是可见的，用户也只能按照界面预设的流程来使用它们。界面不仅决定了你能做什么，还决定了你必须怎么做。
想想抖音。假设你从来不看视频，就是喜欢逛抖音商城购物。无论你的偏好多么明确、习惯多么稳定，抖音也不可能为你单独把商城入口挪到首页第一个位置，遑论重新设计一套以购物为中心的使用流程。界面是固定的，它定义了所有人都必须遵循的交互路径——无论这个路径是否真的适合你。
这揭示了传统 UI 的一个根本局限：它不仅固化了界面，也固化了软件的能力边界。功能的存在与否，不再取决于代码能做什么，而是取决于界面选择暴露什么；使用的方式，不完全由你的需求决定，而由界面预设的流程决定。这个边界一旦确定，就很难突破。
Generative UI 重新定义软件的可能性
现在，让我们回到 Generative UI。
最初，我们或许会认为它只是"动态生成界面"——让 UI 变得更灵活、更个性化。但如果仔细观察当前的技术演进，会发现一个有趣的现象：Generative UI 的实践结合业务以 Agent 为中心的转型，往往伴随着更深层的架构转变。当前端界面变得可生成时，后端的业务逻辑也在悄然解耦和重组。
这不是偶然。正是因为 UI 从根本上定义了软件，所以当 UI 的生成方式改变时，整个软件的组织方式也必然随之演化。我们似乎正在目睹软件开发的一次双重转变：不只是界面的生成，更是逻辑的重组。
前端的动态生成：不再是固定的页面和组件，而是 Agent 根据用户意图、任务上下文、当前状态，动态决定生成什么样的界面。同一个功能，可能在不同情境下呈现完全不同的交互形式。
后端的能力编排：不再是预设的业务流程，而是一组可被调用的原子能力（通过 tool calling / function calling）。Agent 根据任务需求，动态组合这些能力，形成适合当前场景的执行路径。
一个具体的对比或许能说明这种转变：
想象一下订机票这个场景。在传统的航空公司app中，所有用户看到的都是相同的界面——固定的筛选器、标准化的搜索结果页面、统一的信息布局。无论你是商务旅客还是休闲游客，是价格敏感型还是时间优先型，你看到的都是同样的界面设计，只能按照预设的排序和布局查看航班信息。
而在 Agent-centric 的架构下，同样是订票，体验可能完全不同。以 Google Research 描述的一个案例为例：用户 Alex 在 Delta 航空app中搜索飞往芝加哥的航班。系统知道她最关心价格和旅行时间，所以这两项信息在搜索结果中被更突出地显示；系统还知道她总是偏好窗边座位，所以在第一个航班选项旁主动显示"无窗边座位"的警告提示；她从不选择红眼航班，所以这些选项被自动折叠并放在列表最底部。系统甚至检测到目的地有大型活动，主动提醒她这段时间价格会更贵、建议尽早预订。
同样是订票功能，但界面的呈现方式、信息的优先级、交互的流程，都根据 Alex 的个体需求动态生成。这不是简单的"个性化设置"——而是 Agent 理解用户意图后，动态调用合适的能力（价格查询、座位检查、事件日历），并生成最适合当前情境的界面。
软件从"固定的产品实例"变成了"能力的集合"，由 Agent 按需编排和呈现。而这种解耦，如果确实成为主流趋势，将会带来开发范式的深刻变化：
-
从定义完整的用户旅程到定义原子能力和组合规则
开发者不再预设"用户应该怎么做"，而是暴露"系统能做什么"，让 Agent 去理解和编排。 -
从设计固定的界面到设计生成策略和约束空间
设计师不再画具体的页面，而是定义"什么样的生成是合理的"，设立边界和原则。 -
从实现业务流程到暴露可调用的工具
后端不再编码固定的流程链路，而是提供足够细粒度、可组合的能力单元。
未知的终点
当然,我们必须承认,这些转变还处在非常早期的阶段。传统 SaaS 也不会一夜消失,两种范式很可能会长期并存。许多场景下,固定的流程和界面依然更高效、更可靠。而且,Agent-centric 架构带来的复杂性——如何保证生成的质量?如何处理错误和边界情况?如何让用户建立信任?——这些问题都还没有成熟的答案。
但当我们谈论 Generative UI 时,值得意识到:它可能不只是在改进软件的某个层面,而是在邀请我们重新思考"软件是什么"这个问题本身。
而这自然引出一个更深层的追问:当软件从"固定的产品实例"变成"动态的生成系统",当界面和逻辑都不再预设而是实时编排,这不仅仅是技术架构的改变。更根本的问题是:我们"打造软件"的方法论本身,是否也在经历同样的范式转移?
前面我们讨论了软件"是什么"的变化——从固化到流动,从定义到生成。但软件"是什么",从来都是由"如何打造"决定的。如果软件变成生成式的、由模型驱动的,那么打造软件的整个方法论——从需求如何分析、设计决策如何做出、到质量如何评估——是否也在发生根本性的转变?
AI 时代，我们做产品的方式要变化吗？
回顾过去几十年的软件开发，我们会发现一个基本特征：这是一套以人类经验为核心的体系。产品经理基于市场洞察做决策，设计师依据设计原则创造界面，工程师遵循最佳实践编写代码。整个流程建立在经验的积累、总结和传承之上。
这套体系的底层逻辑，某种程度上类似成衣的生产方式。我们设计S、M、L、XL这样的标准尺码，目标是找到那80%的共性需求，让大多数人都能找到"差不多合适"的选择。这是标准化的经济学逻辑：通过降低边际成本来实现规模化。但代价也显而易见——那些个性化的、特殊的、边缘的需求，往往被主动放弃了。
另外一点值得注意的是，即便在当今最强调数据驱动的互联网环境中，人依然是决策的中心。我们可能同时运行数千个AB实验，收集海量的用户行为数据，但最终仍需要人来解读数据、提炼洞察、设计方案、推动迭代。这种"Human in the loop"的模式，一方面让我们能够注入人文关怀和创造性思考，另一方面也意味着优化的速度和规模受限于人的认知带宽。
推荐系统的启示
标准化时代的"二八原则"看似不可避免，直到推荐系统的出现，让我们看到了另一种可能性。从广播电视到Netflix、从门户网站到TikTok，内容的呈现方式经历了从"所有人看同样内容"到"每个人看不同内容"的转变。这个转变的核心，不是简单的自动化，而是引入了能够理解个体差异的智能模型。
Generative UI似乎在尝试将这种"千人千面"从内容层面扩展到界面层面。理论上，当个性化不再依赖人工定制，而是由模型基于数据动态生成时，个性化与规模化之间的矛盾可能会被解耦——个性化的边际成本趋近于零，服务长尾需求变得可行。
这种转变如果成立，意味着软件开发的组织模式也可能随之演化。产品经理可能不再主要负责"需求的最大公约数"，设计师可能不再主要设计"适合所有人的通用方案"。相应的，我们可能需要新的角色。
从经验驱动到数据驱动
Generative UI带来的变革，可能还有一个更深层的维度。如果我们把视野放得更开一些，会发现这不仅关乎界面如何生成，而是整个软件服务可能以一种全新的方式"生长"出来。
设想这样一个场景：一个搭载了基础设施的生成式应用，它不预设任何固定的功能模块。当用户开始使用时，系统根据用户的行为模式、诉求和偏好，逐渐"长"出适合这个用户的功能组合。频繁查看天气的用户可能"长"出气象信息模块，经常点外卖的用户"长"出餐饮服务模块，喜欢购物的用户"长"出商城功能。更重要的是，这些模块不只是简单的功能开关，而是以每个用户最习惯的方式——信息架构、交互逻辑、视觉呈现——被交付到手上。
换句话说，不同用户看到的不只是界面不同，而是他们实际上在使用"不同的应用"。软件从预设的功能集合，变成了根据数据动态演化的有机体。
这个愿景听起来很激进，但它背后的逻辑，其实延续了AI历史上一个反复被验证的模式。Rich Sutton在《The Bitter Lesson》中总结道：长期来看，利用计算和学习的方法总是会胜过基于人类知识的方法。从国际象棋到围棋，从语音识别到图像识别，人类的知识和直觉在短期内有用，但最终会成为瓶颈，而搜索和学习的可扩展性则要强得多。
这个模式是否也会在软件工程领域重演——不只是UI设计，而是整个软件架构和功能组织？
传统的软件开发，本质上是人类经验的编码。我们基于经验判断"用户需要什么功能"、"这些功能应该如何组织"、"信息应该如何呈现"。这些判断被编码到产品设计、技术架构、交互流程中。而生成式软件的方向，则是让系统从实际用户行为数据中学习什么有效，根据上下文动态生成功能组合和交互界面，并不断从反馈中优化。就像AlphaGo不需要理解围棋哲学也能下出精妙棋局，生成式软件系统理论上也不需要"理解"产品设计原则，就能演化出有效的服务形态。
这个转变如果发生，会带来一些值得深思的问题：
我们现在预设的"一个应用应该有哪些功能"这个假设本身，会不会就是一种限制？几十年积累的产品设计最佳实践——用户旅程、信息架构、功能优先级——这些原则基于有限的人类观察，而系统可能从数十亿次真实交互中发现完全不同的组织方式。
The Scaling Law of User Experience?
顺着 Sutton 的逻辑，我们不得不面对一个更具挑衅性，也更迷人的问题：如果计算和学习终将胜出，那么用户体验（User Experience）是否也存在类似大语言模型的 Scaling Law？
在 LLM 领域，规律显得冷酷而清晰：更多的数据、更强的算力、更大的模型，几乎必然带来更强的智能。这让我们不禁遐想：是否存在一个公式，比如 "海量的交互数据 + 巨大的生成模型 = 极致的用户体验"？
这个假设听起来令人心潮澎湃，但当我们试图将其落地时，却撞上了几个根本性的难题。
最核心的困境在于，我们似乎找不到那个完美的"损失函数"。对于大语言模型，预测下一个 token 的准确率是一个相对客观的指标。但在交互设计中，"好"是一个极其模糊且流动的概念。是更高的点击率吗？那可能是诱导设计（Dark Patterns）。是更短的停留时间吗？对于工具或许是，但对于内容消费则未必。
此外，反馈循环的建立也远比想象中复杂。在围棋中，输赢是确定的；在对话中，语意是相对清晰的。但在交互中，用户没有点击某个按钮，是因为没看到、不需要、还是因为困惑？这种沉默的反馈充满了噪声。更何况，"好的体验"往往包含着难以量化的审美愉悦和情感共鸣，它高度主观，且因人、因时、因地而异。
这或许是 Generative UI 带给我们最大的悬念。如果 UX Scaling Law 真的存在，软件行业的竞争逻辑将被重写，数据和算力将构成难以逾越的护城河；如果它不存在，或者存在明显的边界，那么这恰恰证明了设计中存在着某种无法被计算还原的"人性"成分——那是属于人类最后的，也是最珍贵的领地。
目前，我们还不知道答案。但这正是它迷人的地方：我们正站在一个新的十字路口，看着通往未知的路标。
结论：才刚开始
Generative UI 不是一个已定型的技术，而是一个正在展开的范式转变。它在三个层面上挑战我们的认知：
经济层面：突破标准化的限制，让个性化与规模化不再矛盾，从"服务 80%"到"服务 100%"成为可能
认识论层面：从人类经验转向数据驱动，重演 "The Bitter Lesson"
优化范式层面：可能开启"UX Scaling Law"时代，但我们还不知道这个 Law 是否存在、如何运作
当前的实践还很初级——我们在探索组件组装、标准化协议、基本的动态生成。真正的"千人千面"可能还需要若干年的技术积累和认知突破。
但方向已经清晰：UI 的制作方式正在从标准化生产转向智能化生成，从"适合大多数人"转向"通用的个性化方案"。这个转变会深刻影响软件产品的形态、组织的结构、职业的定义，甚至我们对"好的用户体验"的理解本身。
历史告诉我们，当生产方式发生根本性改变时，我们往往低估它的长期影响。就像推荐系统彻底改变了内容消费的方式，Generative UI 可能会彻底改变软件交互的方式——不是某个具体技术的胜利，而是整个领域的范式跃迁。
我们只需决定，如何参与这场革命。
