夜雨聆风我们曾经以为，AI会把软件压缩成一个聊天框。现在发生的事情却稍微复杂一些：AI越能理解人的意图，软件越需要在恰当的时候，重新长出按钮、表格、地图和操作面板。
我们常常把“入口”误认为“界面”。
譬如，你对AI说：
“把华东区过去三个月的退款订单找出来，按原因分类，再做一张能继续筛选的图。”
按照最直觉的想象，AI应该直接回答。它可以写一段分析，告诉你物流延误占多少、质量问题占多少，再归纳几个趋势。既然自然语言已经足够强，那些筛选器、表格、按钮和仪表盘，似乎也该像旧时代的操作手册一样，逐渐退到后台。
可另一种软件形态正在出现。
AI没有继续解释。几秒钟后，屏幕上出现了一块临时工作台：左边是地区和日期筛选，右边是退款原因图表，下方是订单明细。你点一下“物流延误”，订单自动收窄；等你准备导出，确认按钮才出现在手边。
这块界面也许从来没有被产品经理画进任何固定页面。任务完成之后，它甚至可以消失。但筛选条件、分析结果、权限判断和操作记录仍然留在系统里。
这件事提示我们，AI带来的变化也许并不是“没有界面”，而是另一件更不容易被察觉的事：
它正在削弱一个沿用了几十年的前提——所有界面都必须事先设计完成，等待用户前来寻找。
本文暂且把围绕一次具体任务临时形成的操作面称为“临时软件”。这不是行业已经统一使用的正式术语，而是一个便于讨论的分析概念。严格说来，它也不是真的临时造出一套软件；临时出现的只是操作面，背后的数据、权限和业务能力早已存在。
过去，人先进入软件，再寻找功能；未来，用户可能先说出任务，软件再组织完成任务所需的界面。
图：界面从“预先提供全部功能”转向“围绕当前任务临时组织”，但底层数据、权限与业务动作仍然稳定存在。
按钮为什么又回来了
如果“自然语言就是下一代界面”是一句完整的判断，那么结论应该很简单：模型能力越强，GUI越不重要。
然而，近来几条受到关注的技术路线并没有完全朝这个方向发展。
Google在2025年12月公开A2UI项目。智能体并不直接交给用户一段任意HTML，而是发送描述界面结构与数据的声明式消息，再由客户端调用已经批准的按钮、卡片、输入框和布局组件完成渲染。截至2026年8月11日，A2UI官网将v0.9.1列为当前生产版本，v1.0列为候选版本。Flutter随后提供GenUI SDK，把这类消息映射为原生组件。
另一条路线是MCP Apps。2026年1月，它成为MCP的首个官方扩展。工具可以把预先构建的HTML应用带进对话，宿主则通过沙箱iframe和受控通信通道将它隔离。OpenAI当前的插件界面也采用MCP Apps标准：查询和计算可以由工具完成，真正需要用户查看、筛选、确认和操作时，再调出相应界面。
Vercel更早探索过类似方向：模型调用工具，工具映射到预制React组件，界面随着生成过程逐步显示。
这些方案并不相同。A2UI偏向声明式组合，MCP Apps容纳的是沙箱化应用，Vercel的方案更接近工具与组件的映射。可它们共享一个耐人寻味的判断：
成熟系统没有急着删掉GUI，而是在研究怎样让AI更安全地调度GUI。
所以真正值得追问的不是“聊天框会不会取代页面”，而是：既然AI已经能够听懂我们想做什么，为什么还需要按钮？
理解意图，不等于完成操作
对话很适合表达意图。
“明晚七点，两个人，想找一家安静一点的餐厅。”
“帮我看看这几款服务器，哪个更适合AI训练。”
“把过去三个月的异常退款订单找出来。”
这些要求放进传统软件，用户往往得先知道应该进入哪个菜单、使用哪一张表单。AI改变的是这一步：人不必先学会软件的分类方式，才能说出自己要办的事。
但理解任务以后，工作才刚刚开始。
假设七点已经没有餐位，系统当然可以继续问：“18:30、19:30和20:00都有位置，您选哪一个？”可是三枚时间按钮显然更直接。比较五款服务器时，模型也可以写五段文字；但一张字段统一的参数表，加几个筛选器，往往更容易暴露差异。任务一旦涉及金额、审批状态、日期范围、地图位置或设备参数，这种差别会更加明显。
原因并不神秘。自然语言擅长容纳含混，界面擅长呈现状态。前者允许我们用不完整的方式说出目标，后者让我们看清当前有哪些选项、已经选了什么、还缺什么，以及下一步究竟会发生什么。
因此，对话与GUI不是一场只能留下一个胜者的竞争。它们更可能形成新的分工：
对话负责理解“我要做什么”；界面负责说明“现在有什么、系统处于什么状态、我下一步可以做什么”。
这里还要补上一层经常被忽略的区别。聊天框降低了“找到功能”的成本，却也可能隐藏软件的能力边界。固定菜单虽然笨重，至少会告诉用户系统大致能够做什么；一个空白输入框看似自由，有时反而让人不知道该如何开口。生成式界面的价值，正是在理解意图之后，把可用能力重新显露出来。
一项2024年的文本编辑研究提供了一个规模不大的侧面证据。研究者先调查121人，又分别通过10人和12人的两个原型实验比较对话与工具栏。参与者常常把对话当作短命令使用；当固定AI工具与自由提示同时存在时，他们会根据任务在两者之间切换。
这个样本不足以证明未来所有软件都会如此，实验场景也不能直接等同于企业系统。但它至少提醒我们：所谓“有了聊天，所以不再需要GUI”，可能从一开始就把意图表达和精确操作混成了同一件事。
“页面”也许不再是软件的最小单位
传统软件先有页面，再有任务。
首页放什么，左侧菜单放什么，订单页有哪些字段，报表页提供哪些筛选器，产品团队事先画出绝大部分路径。用户进入系统以后，再沿着这些路径寻找自己的工作。
生成式界面的次序恰好相反：任务先出现，操作面随后形成。
当用户提出目标，系统需要先回答一组问题：这次任务要用哪些数据；当前用户能执行什么动作；还缺少哪些必要字段；哪些信息适合用图表，哪些应当列成明细；哪里需要追问，哪里必须确认；客户端又有哪些经过批准的组件可以承载这些交互。
这些判断完成之后，用户才会看见最终的操作面。
从这个意义上说，“临时软件”不是AI凭空写出一套新系统。它更像一次有约束的重新编排：稳定存在的数据、业务能力和界面组件，被针对当前任务组织成一个短暂但可操作的整体。
这也解释了为什么“生成式界面”真正进入工程阶段以后，重点往往不在生成，而在约束。
图：界面生成自由度越高，系统对组件契约、沙箱、安全、测试和版本治理的要求通常也越高。
工程上的“生成”，大多是受控组合
“AI现场生成软件”很容易让人想到一幅颇具未来感的画面：模型临时写出HTML、CSS和JavaScript，然后立即运行。它当然可以被称为生成式界面，但只是自由度最高、也最难治理的一端。
生产系统里的可靠方案通常要克制得多。
最稳的一层是选择。天气卡、订单表、审批面板、地图和图表已经由开发者写好，模型只判断何时调用。
再往前是组合。模型可以决定表单包含哪些字段、几张卡片如何排列、图表绑定哪组数据，却只能从经过批准的组件目录中选择。金融应用可以允许AI组合金额输入框、账户选择器、费率说明和风险提示，但不应允许它临时发明一个未经审核的“立即转账”控件。
MCP Apps又向前一步。开发者可以准备一块完整的交互式网页应用，模型负责判断何时把它调入对话，宿主则用沙箱、权限和通信协议限制它能够读取什么、调用什么。
最后才是模型临时生成代码并立即执行。它的表达上限最高，安全、依赖、可访问性、复现和测试成本也最高。
我们不妨把它理解为一条连续谱：运行时自由度越高，系统越需要用组件契约、沙箱、权限、测试和版本治理把失去的可预测性补回来。
所以，一个看似临时生成的界面，背后依赖的恰恰是大量不能临时决定的东西：任务模型、业务数据、动作接口、权限、组件和状态。企业应用还必须加上版本、日志与责任记录。
界面可以越来越流动，软件的骨架反而要越来越稳定。
未来的软件，可能分成三层
沿着这个判断继续往下看，未来的软件并不会变成一团每次都不同的页面。它更可能形成一种“稳定—动态—稳定”的结构。
第一层是稳定外壳。
身份、账户、历史记录、全局设置、通知、帮助和主导航保持相对稳定。用户必须知道自己在哪里、以什么身份操作、刚才做过什么，出了问题又该从哪里离开。这样的方向感不能每次重新生成。
第二层是动态任务区。
真正围绕当前任务变化的部分放在这里。今天分析退款，它是一张退款工作台；明天采购服务器，它变成产品对比器；后天处理售后问题，眼前出现的又是日志、配置项和故障路径。筛选器、表单、图表、地图和上下文动作可以变化，因为任务本来就在变化。
第三层是稳定业务能力。
这里保存数据、订单、业务规则、API、权限、版本和审计日志。屏幕上的临时界面关闭了，业务事实不会随之消失。付款、发送、删除、签署和审批等高风险动作，也不能因为界面是生成的就失去固定的责任边界。
严格说来，真正适合临时存在的是操作面，不是软件本身，更不是交易事实。
图：变化最大的可能是中间的任务操作面；身份、数据、权限、业务状态和责任记录反而需要保持稳定。
并非所有软件都应该“现做现用”
说到这里，很容易滑向另一种简单结论：既然任务可以先于页面，那么固定界面终究会被淘汰。事情并没有这么整齐。
临时界面尤其适合那些频率不高、菜单难以记忆、目标相对明确，而且日期、金额、候选项和状态能够结构化的任务。复杂报销、旅行规划、一次性采购比较、数据探索和设备配置向导都属于此类。它们的障碍往往不是专业用户操作得太慢，而是普通用户根本不知道应该从哪里开始。AI把入口从“找到功能”改成“描述目标”，价值十分直接。
高频专业软件则不同。
视频剪辑、CAD、交易终端和运维控制台依赖空间记忆、快捷键、持续状态与肌肉记忆。一个工程师每天都在使用的按钮，今天在左边，明天忽然跑到右边，通常不叫智能，只叫打断。
多人协作同样需要共享坐标。“第三列审批状态”“右上角告警”“时间线上第二条轨道”之所以说得通，是因为所有人面对的是相对稳定的空间。界面在这里不仅是工具，也是团队共同使用的一张地图。
医疗、金融和工业控制等高风险场景还多了一层要求。监督、确认、停止、撤销和审计入口不能为了个性化而随意漂移。W3C的WCAG 2.2要求重复导航保持相对顺序，相同功能保持一致标识，交互行为具有可预测性。对使用屏幕阅读器、屏幕放大器或存在认知障碍的人来说，界面不断重排并不是新鲜体验，可能是切实的操作门槛。
因此，动态界面的边界从来不是“AI能不能生成”。技术能够做到的事情，未必都应该交给运行时决定。真正的问题是：
哪些部分可以随任务变化，哪些部分必须保持可预测？
这个问题没有一条适用于所有产品的答案。任务频率越高、空间记忆越重要、错误后果越严重，固定GUI的价值通常越大；任务差异越高、使用频率越低、预览与撤销越充分，临时组合的价值才越明显。
软件公司的资产，会向界面以下移动
过去，一家软件公司很容易用页面描述自己的产品：有多少模块、多少功能、多少菜单，客户购买之后可以进入哪些页面。
当操作面能够围绕任务重新组织，最难复制的资产会向更底层移动。页面仍然重要，但它不再天然等同于产品本身。
真正决定系统能否生成可靠操作面的，至少有六类东西：可信数据、业务规则、可调用动作、权限与审计、可组合组件，以及稳定的设计系统。
这也会改变设计师的问题。过去主要问：“这张页面应该长什么样？”今后还要继续追问：AI在什么条件下可以调用这个组件？哪些组件可以一起出现？哪些信息永远不能隐藏？什么时候必须向用户追问？哪些操作必须二次确认？失败以后应该退回哪里？
到了这一步，设计系统就不只是颜色、字号和按钮规范。它更像一套AI可以执行的界面语法：组件目录是词汇，组合规则是句法，权限、安全和品牌约束划出不能越过的边界。
当然，语法并不会自动产生好文章。同样地，拥有组件库也不等于能够生成好界面。任务理解、信息取舍与失败处理，仍然决定这套系统究竟是在帮助用户，还是只把页面重新洗了一遍牌。
测试对象将从页面变成边界
固定软件的测试对象相对明确：进入某个页面，输入一组参数，点击按钮，系统应该到达预期状态。
生成式界面要麻烦得多，因为团队无法提前枚举用户最终会看到的全部操作面。测试不再只是复现一条固定路径，而要覆盖输入分布与生成边界。
同一任务换一种说法会怎样？少了一个字段会怎样？权限不足、网络中断、组件版本升级又会怎样？辅助技术无法识别动态区域时，系统有没有可用的替代路径？模型误解意图以后，用户还能不能回到一个固定出口？
这些问题最后都会落到“降级”上。企业系统尤其需要保留标准页面、固定表单或人工流程。生成式界面不应该成为核心业务能力的唯一入口，因为一种新的调度方式，不应同时成为新的单点故障。
用户不需要知道模型内部出了什么问题，但至少必须知道三件事：现在发生了什么，我的数据是否保存，我还可以怎样继续。
产品指标也要从“看了什么”转向“办成什么”
页面访问量和停留时长不会立刻失效，可它们越来越难回答临时界面的核心问题：用户究竟有没有把事情办完？
更重要的指标可能是任务完成率、首次生成可用率、误操作率、撤销率、人工接管率、组件覆盖率、无障碍完成率与生成延迟。
其中，“首次生成可用”不能只表示页面成功显示。数据范围是否正确，必要控件是否齐全，用户能否理解下一步，关键动作有没有进入正确的确认流程，都应该包括在内。
撤销率也不能机械地被当成失败。适量撤销，可能说明用户仍然拥有控制权。相反，如果危险操作几乎无人撤销，却不断引发客服申诉，那么所谓顺畅，也许只是确认机制根本没有起作用。
生成式界面最终要评估的，不是AI画页面画得多漂亮，而是它是否提高了完成任务的概率，同时没有破坏安全、理解与责任。
软件没有消失，只是重新划分了稳定与变化
现在回到最初的问题：如果AI越来越强，软件最终会不会只剩下一个聊天框？
目前出现的工程路线提供了一个不那么戏剧化、却更有可能发生的答案。
自然语言会成为越来越普遍的入口，但入口统一不等于交互形式统一。任务需要比较，我们仍然需要表格；需要定位，就需要地图；需要选择时间，就需要时间控件；需要理解趋势，图表仍然比一段叙述更合适；需要执行高风险动作，明确的确认按钮不会因为AI出现而过时。
AI改变的是，这些东西不一定要事先固定在某一个页面里，等待用户穿过层层菜单去寻找。它们可以在任务需要时出现，任务结束后退出。
而真正需要长期存在的，是另外一组东西：数据、能力、权限、状态、规则和责任。
若要打一个比方，传统软件像一栋预先隔好所有房间的大楼。每个房间都有门牌，用户先找到楼层，再寻找房间。未来的软件或许更像一套稳定的基础设施：承重结构、水电、门禁和消防始终存在，至于眼前这块空间应该摆一张会议桌、一块白板，还是临时搭成一张工作台，可以等真正有人来办事时再决定。
不过，这个比方也有边界。大楼不能每天改变逃生通道，软件同样不能让身份、权限、确认和退出方式随意漂移。
所以，AI不会让软件消失。它更可能让软件从“页面的集合”，逐渐变成“稳定能力与临时操作面的组合”。
到那时，优秀的软件未必是功能最多、菜单最全的那个。它也许只是懂得在用户提出一件事情之后，恰好把完成这件事所需的东西放到手边；不多，也不少。
主要参考资料
Google Developers Blog：Introducing A2UI A2UI官方站与版本说明 Flutter：GenUI SDK MCP官方博客：MCP Apps OpenAI Developers：Add UI to your MCP server Vercel：AI SDK 3.0 with Generative UI Apple Human Interface Guidelines：Generative AI W3C WAI：WCAG 2.2 Predictable W3C WAI：WAI-ARIA Overview Microsoft Research：Predictability and Accuracy in Adaptive User Interfaces Lehmann与Buschek：Functional Flexibility in Generative AI Interfaces CHI 2025：Generative and Malleable User Interfaces European Commission：AI Act Article 14