《AI即软件》第八章:范式跃迁

一

先做一个小小的思想实验。

假设现在是中午十二点，你饿了，想吃饭。

在旧世界里，这个需求是这样被满足的：你掏出手机，打开一个外卖APP，点开"美食"分类，在几十家店里滑来滑去，比较评分、配送时间、满减优惠，选中一家，进店，选菜，加购物车，结算，选择地址，选择支付方式，付款，然后等配送。整个流程，你至少要点二十次屏幕。

在新世界里，这个过程会变成什么样？

你掏出手机，对它说："我饿了，还是老规矩。"

AI知道你的口味——你上次点过什么、喜欢什么口味、忌口什么。AI知道你的预算和时间——你现在在哪、什么时候要吃饭。AI帮你选好店、选好菜，把订单给你过目："还是上次那家川菜，一个回锅肉盖饭，预计30分钟送到，一共32块，确认吗？"

你说："确认。"

吃上饭了。

注意我刚才那句话：你不需要点餐界面，不需要购物车，不需要结算页。 用户要的是"吃上饭"这个结果，不是一个"操作一个个按钮"的过程。

这个思想实验，我在第五章讲过——那是我的顿悟时刻。但这一章，我想把它展开成一个完整的理论。

让我们再做一个企业版的实验。

在旧世界里，"报销"是这样完成的：员工打开报销系统，填一张报销单——出差事由、起止日期、费用明细、发票上传，一项一项填，一个字段一个字段地录。提交后，系统显示"审批中"。然后等，等主管批，等财务审，等打款。整个流程，员工至少要点三十次屏幕，填二十个字段。

在新世界里，员工只需要对AI说一句话："我上周去上海出差三天的费用，报了。"

AI去理解这句话——出差三天，需要填什么；AI去查出差申请单——日期对不对得上；AI去收集发票——从邮箱、从卡包、从聊天记录里找；AI把报销单填好，给员工过目："上海出差三天，交通费860，住宿费1200，餐补450，合计2510，发票已齐，确认提交吗？"

员工说："确认。"

报销到账了。

你发现了没有——不管是吃饭，还是报销，旧世界的软件和用户之间，都隔着一堵"操作"的墙。而新世界的软件，把墙拆了。

二

让我们先把"旧世界"的软件看清楚。

过去四十年的软件，无论什么形态——桌面软件、网页应用、手机APP——本质上都是同一个架构：

用户操作 → 程序逻辑（代码写死） → 输出结果

用户点一个按钮，触发一段代码，代码按照程序员预设的逻辑执行，输出一个结果。所有的"智能"都在代码里。代码是死的——你点什么，它做什么；你不点，它不动。

这个架构有一个隐含的设定：用户必须学会"操作"软件。 每一个按钮、每一个表单、每一个菜单，都是用户和结果之间的一堵墙。你会用，这堵墙是"功能完整"；你不会用，这堵墙是"学习成本"；对所有人来说，这堵墙是"时间浪费"。

而AI时代的软件，应该是另一个架构：

用户意图 → AI理解 → AI决策 → AI调用工具 → AI执行Skill → 输出结果

用户不需要"操作"，用户只需要"表达意图"。AI理解意图，自己决定该做什么、调什么工具、按什么流程执行、输出什么结果。

把这两个架构放在一起，你会发现：这不是程度上的变化，这是本质上的变化。

程度上的变化，是车从每小时80公里变成每小时120公里。本质上的变化，是马车变成了汽车——发动机、传动、操控，全都换了。

三

为什么说是"本质变化"？我用一张表，把新旧两个范式的每个维度都摆出来。

这八个维度，每一个都是根本性的翻转。我挑三个最关键的展开。

不过，在展开之前，我想先指出这八行里最容易被忽略的一行：执行者的角色。

旧范式里，执行者是确定性的程序——同一段代码，跑一万次，结果一模一样。新范式里，执行者是概率性的AI——同一个问题，它两次的回答可能不同。有人会担心：把企业交给一个"不确定的执行者"，是不是太冒险了？

我的回答是：企业治理从来就在管理"执行者的不确定性"——因为旧范式的执行者，从来就不只是程序。任何流程最终都要靠人执行，而人恰恰是最不确定的执行者：同一份客户分析，两个销售经理写出来不一样；同一个审批，两个主管的判断不一样。企业用模板、流程、审批，管理了几十年"人的不确定性"，这套方法没有失效，只是换了主角。至于它怎么延续到AI时代——那是下一章的主题。

第一个：核心驱动。

旧范式里，软件是被"操作"驱动的——用户点哪里，程序跑到哪里。新范式里，软件是被"意图"驱动的——用户表达想要什么，AI决定怎么实现。

这个区别有多重要？举个例子。在旧范式里，"报销"是一个有固定步骤的操作序列：填单→提交→审批→打款。每一步都需要用户操作。在新范式里，"报销"是一个意图：员工说"我上周出差的钱报了"，AI去理解、去执行、去跟踪，员工只需要在关键节点确认。

旧范式问的是"用户点了什么"，新范式问的是"用户想要什么"。这是两套完全不同的思考方式。

第二个：AI的角色。

旧范式里，AI是一个插件——在某个节点被"调用"一次，就像查一次天气。新范式里，AI是整个系统的驱动引擎——理解、决策、执行、记忆，全都由AI驱动。

还记得第五章那只"恐龙"吗？行思远刚做完的时候，AI在整个六层架构里只出现在一个节点上："调用AI模型接口。"就这一步。查完天气，后面的事情跟它没关系了。

这就是"插件"和"引擎"的区别：插件是可选的，去掉它系统还能跑；引擎是必须的，没有它系统就不存在。

第三个：UI的角色。

旧范式里，UI是主体——用户和软件的全部交互都发生在界面上，业务逻辑就藏在界面背后。新范式里，UI退化为"AI的输出窗口"——AI决定展示什么、什么时候展示、用什么方式展示。

这不是说UI会消失。而是说，UI从"业务逻辑的载体"变成了"AI表达结果的工具"。它依然存在，但它的地位变了——从主角变成了配角。

四

"AI即软件"这句话，我在第五章喊出来的时候，是直觉。现在，让我把它拆成三层含义，每一层对应一个层面的变革。

第一层：交互层——自然语言成为主要入口。

这是最表层、最容易理解的变化：以前你操作GUI，现在你说话。以前你点按钮，现在你提需求。自然语言成为人和软件之间最主要的交互方式。

这一层，已经在你眼前发生了。你正在用的AI助手、你手机里的智能语音、你工作里的AI工具——它们都在做这一层的事：把"操作"变成"对话"。

第二层：逻辑层——Skill替代代码，成为业务逻辑的载体。

这一层，是上一章的主题。业务逻辑不再写在if/else里，而是写在Skill里——用自然语言描述、AI直接执行。人直接面对的不再是代码，而是规则本身。

这一层意味着：代码没有消失，但"人写业务代码"消失了。

这句话值得展开。代码去哪了？它变成了三种形态：

第一种，AI生成的实现代码。Skill说"做什么"，AI自己去写"怎么做"的代码。人不再手写业务逻辑的实现，但实现依然存在——在AI的生成物里。

第二种，沉淀在工具和API里的能力代码。加密、支付、消息推送、数据分析——这些通用的能力，被打包成工具和API，Agent直接调用，不需要重新发明。

第三种，数据中台的CRUD接口代码。数据的读写、校验、权限控制，沉淀在数据中台里（第12章会展开），Agent通过接口访问。

所以，"代码没有消失"不是一句空话——它是说，代码从"人直接写的东西"变成了"AI生成的、工具沉淀的、平台提供的"。人直接面对的，只有Skill。

第三层：架构层——Agent成为系统的驱动引擎，传统应用退化为Agent的工具。

这一层，是最深、最根本的变化，也是"AI即软件"这句话最完整的含义。

传统应用不再是一个独立运行的"软件"，而是退化为Agent的工具——Agent需要发消息，就调用消息服务；Agent需要查数据，就调用数据中台；Agent需要算账，就调用财务系统。应用变成了Agent的"手脚"，Skill变成了Agent的"大脑"。

这三层，一层比一层深：

• 交互层改变的是"你怎么用软件"
• 逻辑层改变的是"业务逻辑存在哪"
• 架构层改变的是"软件本身是什么"

第一层，很多企业已经在做了。第二层，是本书前七章的论证。第三层，是接下来的架构章节要展开的。

在进入架构章节之前，请允许我把"AI即软件"这句口号，说得更精确一些。它真正的工程含义是：

在意图、信息、决策、行动链条主导的软件中，AI正从"功能模块"转变为"软件控制平面"——AI不是软件里的一个智能功能，而是新一代软件的控制引擎；传统应用退化为Agent的工具、数据服务和执行末端。

"AI就是软件本身"，是让这句话被记住的口号；"控制平面"，是让这句话经得起推敲的精确表述。两者不矛盾——一个负责传播，一个负责辩护。

五

现在，我们必须回答一个诚实的问题：是不是所有软件，都应该被重构为"AI即软件"？

不是。这个问题，我在第五章结尾也提过，现在把它说透。

有三种场景，传统UI仍然有优势，AI不应该取代：

第一种：高频低认知操作。

你在写代码、做表格、修图片的时候，你需要的是精准的控制和即时的反馈。你想让光标停在第13行，你不会说"把光标移到第13行"——你直接点一下。AI的理解成本，在这里超过了操作成本。

文本编辑器、设计工具、表格软件，这些属于这一类。它们应该保持传统UI，AI是辅助，不是替代。

第二种：实时视觉反馈。

视频剪辑、3D建模、绘画——这些工作的核心是"视觉判断"，你需要看到每一步操作的结果。AI的描述无法替代你的眼睛。你说"把这段视频的色调调暖一点"，AI帮你做了，但你还是得亲眼看效果，自己微调。

第三种：多人协作的并发控制。

在线文档协作、代码评审——多人同时操作同一份内容，需要明确的冲突解决机制。谁改了哪里、版本怎么合并，这些需要精确的控制。AI可以帮忙协调，但不能替代明确的并发机制。

那么，什么软件适合被重构？

答案是：凡是"意图→信息→决策→行动"这条链条涉及的软件。

企业管理系统、审批流程、客户服务、数据分析、报告生成、采购、报销、合同……这些软件的本质，不是"精确的像素控制"，而是"按规则走流程"。它们的核心，就是"用户表达意图→系统理解→系统决策→系统执行→输出结果"。

而企业里的软件，恰恰大多数属于这一类。

我做了二十多年的企业IT。CRM、PLM、ERP、MES——这些系统的本质，都是"用户表达意图→系统执行流程→输出结果"。它们的核心不是"精确控制"，而是"按规则走流程"。规则在哪里？在代码里，在if/else里，在那些没有人看得懂的ABAP和Java里。

如果规则不在代码里，而在Skill里呢？如果执行者不是死板的程序，而是能理解、能判断的AI Agent呢？

那企业IT，就不再是我做了二十年的那个样子了。

六

这一章，我们从"我饿了"这个思想实验开始，讲完了范式跃迁的全部论证：新旧范式的八个维度对比、AI即软件的三层含义、代码的三种去向、适用边界。

但我想，光讲理论是不够的。让我用我自己的经历，把这场范式切换的过程，再走一遍。

我在第五章讲过"行思远"是怎么从一头恐龙，被我重新理解成一个新范式应用的。但那一次，我说的是"发现"——我发现我做错了。

这一章，我想说说"切换"——发现之后，我做了什么。

起初，我试图"修补"行思远。我给它加更多的AI功能：让AI出题、让AI判题、让AI生成学习计划。但我很快发现，这是在给恐龙装更多的马达——它还是恐龙。页面还是那些页面，路由还是那些路由，AI还是那个被"调用"的插件。

然后我停下来，问了自己一个问题，就是第五章那个问题：如果这个应用，完全由AI来驱动，它应该长什么样？

答案，让我的思路彻底转了向。

我不再想"AI能给现有功能加什么"，而是想"用户想要什么，AI该怎么实现"。

拿"学习计划"来说。旧做法是：后端有个定时任务，每天晚上8点跑一次，按预设规则生成一个JSON，存数据库，第二天前端渲染成页面。这个功能里，AI不在——它是个定时任务+规则引擎+CRUD。

新做法是：孩子说"我今天想复习函数"，AI知道这个孩子上周学了二次函数、掌握度68%、错题本里还有三道没清、学习风格是喜欢先做简单的找信心。AI不需要定时任务，不需要JSON，它直接跟孩子对话："今天复习函数怎么样？你上周的二次函数还有三道错题没清，我们先从最简单的那道开始？"

没有页面。没有路由。没有数据库查询。没有前端渲染。有的只是：AI理解意图、AI调用记忆、AI做出判断、AI输出内容。

这就是从"给恐龙装马达"到"重新设计交通工具"的区别。

当然，我并不是说所有功能都应该这样。学习助手需要偶尔展示公式、画思维导图、显示错题统计——这些时候，UI仍然有用。但UI的作用变了：它不再是"操作入口"，而是"AI的表达窗口"。孩子想看错题统计，AI调出统计图；孩子想画个图，AI画出图。展示什么，由AI决定。

这种"切换"不是一次性的。它是一场持续的重构——每想清楚一个功能，就把它从"页面驱动"改成"意图驱动"。而每完成一次切换，我都会更确信一件事：范式跃迁不是"在旧软件上加AI"，而是"用AI重新想象软件"。

七

回到那个"我饿了"的例子。它藏着这个理论里最容易被忽略的一点。

在那个例子里，AI替用户做了大量的事情：选店、选菜、比价、下单。但有两件事，AI没有做：

第一，它没有替用户决定"吃什么"。 它把订单给用户过目："还是上次那家川菜……确认吗？"用户说"确认"，才下单。

第二，它没有替用户承担"下单错了"的责任。 如果AI点错了菜，或者送错了地址，责任不在AI，而在那个说"确认"的人，以及设计这个系统的企业。

这个细节，不是小事。它指向这本书最根本的一条原则——我称之为"第一公理"：

AI是执行主体，人是责任主体。AI不承担责任，判断和承担责任的，始终是人。

AI可以越来越聪明，可以替我们做越来越多的事。但有一条线，永远不能越过：决策的责任，最终必须由人承担。 因为AI不会负责——它没有"负责"这个概念。会负责的，只有人。

这条公理听起来像一句废话，但它的推论，会贯穿这本书后面的所有章节：Skill必须定义"哪些自动执行、哪些需要人批准"；审批节点、升级机制、裁量边界，都是这条公理的自然延伸；AI出错时怎么追责、怎么审计，也都由这条公理决定。

下一章，我们就把这条公理，展开成一套完整的"人机权责"理论。

在进入下一章之前，先记住这一章的三句话：

旧软件是"操作驱动的"，新软件是"意图驱动的"。AI不是软件的插件，AI是软件本身。但无论AI多强大，责任始终在人。

范式跃迁了，责任没有。