AI技术正在深刻改变软件的交互方式，但传统GUI真的会被彻底取代吗？这个问题的答案，可能比很多人的直觉要复杂得多。

近两年，业界普遍把传统软件的交互方式称为GUI，而将原生AI应用的交互概括为CUI（Conversational User Interface）。这个总结虽然方便，但其实是过度简化了。CUI这个说法，很容易让人产生一个直观联想——跟AI聊天。只要在一个对话框里聊着天，事情就办完了，听起来确实很美好。

但说句不客气的话，这大多是不切实际的空想。

有人试图改良CUI，在对话中加入交互卡片，包含数据图表或按钮组，让用户选择后续操作。这算是一种补丁，但寄希望于把所有软件使用过程都塞进一个对话线程里，这种想法依然不切实际，甚至可以说，它从根本上就不是一个合理的交互方式。

用户交互总是和上下文高度相关

首先，用户使用软件很少从一张白纸开始，更多时候是着眼于一个具体的对象。就拿AI加持的Photoshop来说，处理图片时往往要针对照片中的特定区域，比如“移走女人左手拿的那个包”。这时候如果用CUI交互就很尴尬——女人手里可能有两个包，到底指哪个？所以，用户依然习惯用鼠标点选来激活AI功能。

企业软件也是如此。无论是基于客户记录的销售流程，还是工件物料的加工过程，用户总得在数据记录的基础上选择业务动作。用可视化的方式定位到具体记录，几乎是不可避免的。只有明确了上下文，AI的处理才能更准确，用户操作起来也更有底气。

其实，生成式AI应用的发展早期，文本处理和笔记类软件就是这么做的。用户在原有编辑器里选中一段文本，然后调用“扩写”或“摘要”这样的AI功能。这种交互方式，本质上更接近传统GUI。

用户交互需要视觉辅助和引导

想象一下一个生产加工流程软件：当开启新的工件工序时，需要从实物物料上获取标识ID，通常通过光学扫描或RFID识别。识别完成后，工序和SOP要显示出来——这可不是CUI能处理好的。它可能包含图文并茂的检查清单、三张加工图纸，以及几个经过精心布局的按钮。在整个加工过程中，这个视觉交互必须始终存在。用户最终通过点选工序清单中的“完成”按钮，快速确认并切换SOP和图纸内容。这种交互虽然传统，却是最高效的。在这个场景里，AI的智能性和CUI并没有太多用武之地。

当然，有人会反驳说这只是过渡阶段。等AI更智能了，我们可以从客户订单开始，端到端全自动完成采购、生产和交付，根本不需要什么生产加工流程管理软件。但“不可能”三个字，在这里尤其适用。我们的世界不仅靠软件驱动，还受制于大量物理条件。就算所有物理控制都能自动化，也还要处理上下游的采购博弈，甚至国家间的贸易壁垒。一家应用软件公司不可能停顿下来等待世界大同。所有推演都要基于渐进路径。简单说，我们现在需要设计的是2025年的产品形态，而不是为2030年或2075年做准备。

用户交互需要安全确认

用户交互不只是输入和输出，还包括审慎地检查输出效果。商家用二维码收款后，听到“您的支付宝到账100元”，就是一个可靠的输出验证。它只用了非常简单的TTS技术，但极其有效。

很多软件交互的输出效果审查要复杂得多。用户编排了一个流程节点后，需要逐项检查各个参数是否符合期望。即便是简单的家庭自动化，也要确认距离家100米时空调是否要打开、温度设置多少、是否开所有灯还是只开门廊灯。这些对话也许能概括清楚，但到了企业事务自动化领域，要处理的动作远比开灯复杂得多。如果由AI来生成流程，生成的成果必然要用专门的视觉形式表达，这就绕不开GUI。现有软件产品的前端界面即使需要增强，也绝对不能被智能体一笔带过，还是得严丝合缝地把流程参数一项项呈现出来。

在企业软件的关键领域，即使智能体能处理极其复杂的业务，也没有用户敢完全信任它。建立信任的唯一手段，就是把中间过程展示给用户。而这个展示过程，更多依赖的是传统GUI。

用户交互是一个渐进的创作过程

在我所涉及的零代码应用平台领域，两年前就有公司推出了“一句话生成应用”的功能，比如“给我生成一个服装制造业的ERP系统”。别说两年前的模型能力，就是现在，它也毫无实用意义。

那么，进一步丰富提示词能解决问题吗？或者先写一份详尽的需求文档？也不行。因为人类创作任何信息产物时，都是逐步展开的。开发应用、写文章、画油画、谱曲，都会依赖来回往复的揣摩、掂量和取舍。出口成章、五步成诗，那是传奇故事，不是常态。回到用智能体完成任务这件事上，我们很少能靠一次提示词就让AI完成最终任务。就像文生图应用，也需要提供多幅作品供选择，并允许用户选定后继续通过提示词优化。

于是，我们再次面临如何让用户确认中间创作成果的问题。这些中间成果仍然需要一个特定的GUI来表达。专业级的音乐创作AI应用，生成的不能只是WA V声音文件，而需要把乐曲呈现在五线谱上。这不仅离不开Music XML这样的业界标准，还需要能继续调整音符和记号的专业软件架构。有意思的是，原生AI应用非常排斥走回GUI的老路。在调研的几个流行AI音乐生成应用中，没有一个愿意建立基于乐谱的人工编辑能力，都只能通过提示词和简单选项（本质还是提示词）直接生成整段音乐。有的产品允许用户选择生成的片段重新生成（Refill），但谈不上精确控制。而同时，几款老牌乐谱软件也都没有推出生成式AI能力。

这个现象，正好勾勒出生成式AI时代软件产业的分野。原生AI认为再也不需要那些旧有的同类软件，传统软件则在战战兢兢中看着AI能力突飞猛进。这个悬念即将结束，因为一个逐步被验证的新范式正在形成。这个范式会全面纳入生成式AI能力，也给现有应用软件指明改造方向。这是一种融合的范式，能推动产业分工、提升市场效率，也是工业社会演进的内在规律。这里用五个动词来概括它，称为IVERS模式（Instruct, Visualize, Edit, Reinstruct, Submit）。

接下来，我们来详细拆解这个模式。看完后你不会觉得特别陌生，因为越来越多的应用已经开始采纳它——比如AI编程领域的Github Copilot和Cursor，工作流领域的Zapier。这些成功案例虽然出身不同，但都逐步建立起一个AI能力与传统GUI相互贯通的清晰范式，通过人机协同既提高了效率，也保障了精确性所需的人类控制。

传统软件和生成式AI能力能否融合？答案当然是肯定的。但传统软件作为生成式AI出现之前的先导技术（Precursor Technology），本身也需要完成必要的技术里程碑。就像动力机械出现之前，马车也需要设计出车辕和车轴这两个关键的动力传导装置。一旦机械动力模块化，只需把现有的动力来源换掉就行。当然，实际过程比这个简单的原理要冗长得多——从最早的内燃机到最早的汽车，之间竟相隔了二十多年。

融合的基本技术架构

今天，传统软件厂商正在积极寻找一个有效的融合AI能力的架构模式。这个模式需要达成几个必要目标：

1）在保持正确性的前提下，帮助用户加速完成任务。
2）生成式AI技术领域的迭代和变革，不会破坏应用产品本身的连续性。
3）能保持现有的产品差异化优势。

翻译成马车装上内燃机的例子就是：

1）（马）车能继续安全行驶，且要更快。
2）升级后的内燃机依然能安装在现有的马车上。
3）无论是豪华马车还是运货马车，都能搭上内燃机的快车。

为实现这个图景，软件业界在过去一两年中摸索出一些可行路径，并组合出一个日益稳定的框架。下面是这个框架的抽象总结。

为了发挥LLM的能力，应用软件大致有三种利用方式：

1）定制模型（Custom Model）：对开源模型和公共大模型进行微调，提升特定领域指令和响应的准确率。在医疗、法律、金融等垂直领域，应用软件厂商广泛依赖这个路径。

2）检索增强（RAG）及结合知识图谱的GraphRAG：通常用于企业客服、知识库检索和问答等通用领域，实现大模型对企业私有数据的覆盖。

3）功能调用（Function Calling）：这是传统软件和生成式AI能力融合的最重要方式。应用软件根据自身API定义好函数给大模型，大模型分析指令语义，将其转换为精确的调用接口和参数传给应用软件。应用软件执行后，将结果返回给大模型。通过功能调用，生成式AI可以建立与应用软件的互操作能力。

上图底部勾勒了这三个技术路径。这一点在产业中已建立基本共识——尤其是功能调用，几乎所有的AI应用都必须纳入实现路径。就连ChatGPT自己的应用，也高度依赖这个能力来服务终端用户场景。但图的上方，大模型和传统软件用户体验的结合部分，依然存在不少分歧。

在此之前，一部分应用引入了Copilot（副驾驶）的概念，通过一个助手来激活AI能力，用Chat实现与系统的交互。就像一个对话窗口开启产品使用旅程。

完成生成任务后，用户可以用聊天窗口继续与AI对话，对生成内容进行修改调整。但就在这一刻，用户体验开始滑落。用户会感到，无论怎么提示，都无法对生成内容实现精确控制。有时候是因为提示词不够详尽，更多时候是——自然语言很难准确描摹用户心中期望的结果。在图片、音乐、文字作品的生成中，用户普遍都有这种感受。代码和应用生成的用例中，同样存在这个问题。Cursor也不可能保证一组提示词生成完全正确和全面的代码。好在Cursor基于VS Code二次开发，背后是一个功能全面的集成开发环境（IDE），开发者拥有继续操纵项目和文件的自由。但所谓原生AI应用不具备这样的“先导技术”构成——除了文本生成场景，它们只能“为生成而生成”，不能“为再编辑而生成”。

IVERS范式

对于严肃的商业应用和专业级应用来说，这样显然不够。尤其是企业级应用，用户需要通过它完成非常复杂和关键的任务。生成式AI所创建的所有数据或应用片段，至少都要经过用户确认。而这个确认过程需要回到原有的GUI上妥善呈现，用户才能拍板。这就是为什么要在AI和软件产品的融合框架中加入一个新范式。称之为IVERS，全称是Instruct, Visualize, Edit, Re-instruct, Submit。用户给出指令（也可以自动触发）；软件提供带有操作句柄的可视化渲染；用户不满意可以再次给出指令或通过人工编辑；确认后提交。通过这个范式，可以将生成式AI的能量与现有软件工具铺设的交互轨道连接起来——就像把马车的车轴挂接上机械动力的传动装置。

先看一个简单的例子。这个应用叫AIVA，是生成式AI时代之前就诞生的AI作曲应用。和原生AI应用不同，它着眼于为专业作曲家提供AI辅助服务。AI生成的不是声音文件，而是一个结构精密的曲目文件，能被专有编辑器打开，把节奏、音符和音轨等所有元素的控制权交给用户。这些呈现曲目元素的控件都带有允许用户控制的句柄（Handle），用户依然使用GUI进行操作。

作为对比，更“新潮”的原生AI应用却没有这样做。比如SUNO通过提示词生成音乐文件后，虽然也提供了一个Song Editor，却只能让用户重新用提示词修改乐曲片段。说到底，永远是生成啥样就啥样，用户始终无法对成果实现精确控制。

在这第一个例子中，AIVA使用的是IVERS范式，而SUNO使用的是典型的CUI。在音乐创作领域，SUNO也许能满足非专业创作者的兴趣级需求，但在企业软件领域，不存在这样的“业余需求”。每一个软件都有精确完成用户任务的要求。这就是为什么大多数传统软件都需要选择IVERS范式，让用户能够精准Edit，再Submit。

这个机制并不落后。在产业和企业中，因为分工和责任的原因，每一项计算任务都可能被人为划分阶段，由不同角色完成。有时候甚至不是因为技术能力不足，而是社会和法律都要求这样做。就算有一天AI能准确诊断疾病，它也只能开出建议处方，而不可能直接生产出一个盲盒药丸直接喂给病人。

再看第二个例子。Zapier是一个为企业构建跨应用系统自动化工作流的平台。今年他们也推出了copilot，允许用户用自然语言描述需要生成的工作流，比如“Hubspot中每增加一个线索，就同步到Salesforce中”，或“每天上午7点，获取本地天气预报，发送到Slack的某个频道”。

用户完成提示（Instruct）后，Zapier并没有直接创建完整工作流，而是在页面左侧提供一个建议的动作卡片序列（Visualize）。用户通过点选加号，逐个将认为正确的触发器和动作节点添加到右侧工作流画布中（Edit）。右侧画布和AI能力到来之前的设计别无二致。

激活这些节点后，用户还可以利用右侧节点属性对话框中的AI按钮，继续Instruct系统来协助配置节点参数（Re-instruct）。接力棒被继续传递下去，直至用户对编排的工作流完全满意再提交（Submit）。

Zapier在利用AI解决工作流配置智能化的过程中，抛弃了所有浮夸的目标。每一步的Copilot只着眼于一个较小的目标，并且每一步都让用户参与决定后再提交。这正是企业级软件打开AI能力的正确姿势。通过这个范式，AI能力才能真正用于实际生产，而不是停留在演示的噱头上。

要做到这一点，Zapier在工程上需要做很多工作。

首先，Zapier必须为构建工作流的所有组件提供编程接口，并转换为包含完整语义信息的JSON声明——这是实现Function Calling的必要条件，让AI能理解可操作的动作方式。

其次，他们需要仔细规划Agent组合，让每个Agent专注于一个目标，并能有效与其他Agent通讯，将任务传递到下一个目标上。

最后，AI生成的内容必须能直接与前端通讯，使指令生成的内容能准确渲染在画布上。一旦渲染完成，用户就可以直接接手Edit或修改Instruct。

有了这些工程努力，才让Zapier实现了现实可用的工作流编排Copilot。这远比“一句话生成一个工作流”来得靠谱。

IVERS范式也能让应用开发者解耦AI能力。无论生成式AI领域的技术如何变迁，应用软件只需管理好自己的开发接口，配置好提示词和Tool的定义，哪怕换不同的LLM，都不会影响自己的代码项目。在更复杂的场景中，如果用户需要与其他第三方工具开发的Agent交互，业界已经开始尝试标准化——MCP Server协议很可能成为这个领域的标准。

按照这个思想，大多数应用软件都需要重新思考如何与AI能力融合。不放弃自己的独特定位，才有机会在AI浪潮下获取新能量。但现实中，很多应用软件却在做转型的事——工具、平台和应用套件都在竞相做智能体编排工具，似乎一夜之间大家都成了原生AI应用。市场根本不需要那么多Agent Builder，但需要更多更好的、结合AI能力的应用软件。这些改造工作要耗费大量时间和精力。AI能力无论怎么增强，落到具体应用场景时，都需要应用厂商穿针引线，解决大量工程细节，才能给用户提供实用可靠的解决方案。因此，这篇文章的一大目标，就是敦促传统软件厂商重新审视自己的AI战略。

微软CEO纳德拉在最近的采访中有一个非常极端的表达。他认为AI和智能体会摧毁所有应用软件，尤其是Dynamics这样的企业软件——认为它们不过是数据库加一堆业务规则，最终AI层不仅能替代GUI层，还能接管业务规则。这个看法，可能是在揣着明白装糊涂，反正里外都是微软家的。首先，这并不意味着GUI没有独特价值，它作为软件技术的重要组成部分将长期存在——就连配置一个Agent工作流，目前也依赖GUI。其次，不能把数十年后的愿景误认为是可以一步登天的捷径。从企业软件市场的长期经验来看，无论是软件还是AI，没有奇迹，有的只是一个一个砸下去的人月。