生成式AI和传统软件的分野和融合（全文）

推荐语

AI技术革新软件交互方式，但传统GUI仍不可或缺。

核心内容：
1. AI加持下软件交互方式的变革趋势
2. GUI与CUI的对比及其局限性
3. 用户交互中视觉辅助和上下文的重要性

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

在最近的两年内，大家都在谈论在AI能力加持以后新的软件交互形式。业界把传统软件的交互方式称为GUI，而把原生AI应用的交互方式概括为CUI （Conversational User Interface）。这也是一个过度的概括。CUI这个概念命名很容易给人的联想就是和AI聊天。通过Chat来实现和系统的交互，获取用户期望的使用成果。

告别了繁冗的GUI，用户只需要专注在一个聊天框中，聊着天就把事情给干了。这听起来挺美好，但这大多是不切实际的空想。

有人继续改造这个CUI，在对话中增加允许的信息交互卡片。卡片可以包含GUI中一些局部的信息组合，比如一项数据图表，也可以包括一个按钮组，让用户选择一个恰当的后续操作。这样做有所补充，但这种寄希望于把软件使用过程都纳入一个对话线程的想法依然是不实际的，它甚至根本不是一个合理的交互方式。

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

首先，用户使用一个软件绝非总是从全新的空白状态开始，更多的时候，是着眼于一个具体的对象。就像附加AI能力的Photoshop处理图片时，也是针对照片中的一个特定区域进行AI处理。比如“移走女人左手拿的那个包”。这时候，使用CUI交互是非常愚蠢的，因为女人手里可能有两个包，到底是哪一个呢？所以，Photoshop用户依然使用鼠标点选来激活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应用生成的不能只是WAV声音文件，而需要把乐曲呈现在五线谱上，这不仅离不开Music XML这样的业界标准，还依赖能够继续调整音符和记号的专业软件架构。在这个例子中，我们发现原生AI应用非常抗拒走回GUI的老路。在调研的数个流行的AI生成音乐应用中，没有一个产品愿意建立基于乐谱的人工编辑能力，都只能通过提示词和一些简单的选项（本质还是提示词）直接生成整段音乐。有的产品允许用户选择生成乐曲的一段重新生成（Refill），但根本也谈不上精确的控制能力。而同时，我也调研了数款老牌的乐谱软件，他们也都没有推出生成式AI能力。

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

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

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

融合的基本技术架构

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

1）在保持正确性的前提下，帮助用户加速完成任务。

2）生成式AI技术领域的迭代和变革都不会破坏应用产品本身的连续性。

3）能保持现有的产品差异化优势。

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

1）（马）车能够继续安全行驶，且要更快。

2）升级后的内燃机依然需要能够安装在现有的马车上。

3）无论是豪华的马车，还是运货的马车，都要能搭上内燃机的快车

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

为了发挥出LLM的能力，应用软件大致有三个可以利用的方式。

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

2）检索增强 (RAG) 以及结合知识图谱的GraphRAG。这个技术路径一般被用在企业客服，知识库检索和问答等通用领域，实现大模型对企业私有数据的覆盖。

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

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

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

在完成生成任务以后，用户当然继续可以用聊天窗口和AI对话，对生成的内容进行修改调整。在这一刻，用户体验开始滑落。用户会感到，无论怎么提示，都无法对生成的内容实现精确的控制。有些情况下，是因为用户提示词不够详尽，更多的情况是，无论怎么表达，自然语言都难以准确描摹用户心中期望得到的结果。在图片、音乐、文字作品的生成中，用户普遍都有这样的感受。在代码和应用生成的用例中，这个问题同样存在。Cursur也不可能保证一组提示词生成完全正确和全面的代码。但好在Cursur基于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，都没有奇迹，有的只是一个一个砸下去的人月。