前言
现在几乎所有 B 端 SaaS 团队，都站在同一个十字路口： 存量系统跑了很多年，业务不能停、付费租户不能下线，同时老板、客户、行业声音都在催着做 AI 原生。 摆在架构师面前，天然只有两条路：
- 路线一：在现有系统上持续改造、叠加 AI 能力，相当于给一台老奥拓翻新、加装电机、换内饰、上大屏，尽量让它跑得更快、看起来更智能。
- 路线二：稳住老系统，并行建设一套全新底座，时机成熟之后整体割接下线，相当于直接放弃改造奥拓，造一台全新的电车。
行业里绝大多数团队，下意识选择第一条。看起来风险更低、投入更可控、可以复用存量资产，也是最稳妥、最容易拿到立项的方案。 但我在零售 SaaS，面对六十万行代码的权限中心、资质证照、零供管理这类厚重存量模块反复推演之后，结论很反直觉：给奥拓加装 AI，有不可突破的物理上限。
一、当下主流方案：给奥拓加装 “AI 聊天副驾”
现在最流行的 AI 赋能玩法，就是我们常说的外挂 AI： 把老系统已有的 API 统一封装，套一层对话入口，对接大模型，配上 RAG 知识库。对外包装成 AI 原生产品。 它能做到什么？
- 新手用户不知道菜单在哪，可以问 AI，AI 引导页面跳转；
- 简单查询类需求，通过对话组装参数，调用后端接口返回数据；
- 把系统手册、操作文档喂给 RAG，回答一些标准化操作问题。
这里面还有一类更偏向“皮包 AI”的形态：交互上看着是 AI 通过对话帮用户解决了业务问题，仔细拆解就会发现，它本质只是把一个传统报表、筛选页面的能力，包装成了自然语言对话。数据查询、汇总、过滤、统计，不用大模型，原生报表页面点几下同样能拿到结果。
AI 在这里没有产生新的业务能力，仅仅是换了一层交互外壳。它把本可以一键出表的能力，包装成 AI 的价值，用户获得的业务价值没有增量，甚至因为大模型的延迟、不确定性，体验还不如直接用报表。
这些方案落地快、demo 好看，汇报的时候效果很好。很多客户、产品、管理层第一眼都会认可。 但它的短板非常明确： 熟练的系统使用者，点开菜单、填好筛选条件，速度远比和大模型对话更快、确定性更高。AI 副驾只对新手友好，对核心生产力人群几乎没有业务、效率价值。
问题不在交互层，而在底层： 老系统是多年迭代逐步堆出来的，实体定义不统一、权限切面散落在各个服务、业务规则埋在代码深处，没有统一语义契约。哪怕所有 API 全部开放给大模型，Agent 也没办法理解这套混沌业务。
AI 只能按固定 API 去 “尝试调用”，它不知道这个单据实体和证照实体之间的业务关系，不知道一条隐藏权限规则，不知道字段背后的业务约束。一旦流程稍微复杂、存在分支判断，幻觉、误操作、权限越界风险立刻凸显。
这就好比：你给一台奥拓加装了一个智能副驾。副驾可以帮你看导航、提醒路况（可能你的奥拓连导航都没），但它改变不了车身结构、底盘、刹车、发动机的先天限制。 你可以把内饰做得再豪华，副驾再聪明，这台车永远跑不出奥拓的上限。底盘先天不支持自动驾驶、整车架构不是为智能单元设计的。所有智能，都只是样子货。
二、另一条路线：放弃改造，新建电车底盘
这条路线，很多人第一反应是风险巨大：重写系统，成本高、周期长、还要并行维护两套体系，老租户迁移也是难题。
但首先要认清一个核心事实：这个转型不是可选的优化项，是范式迭代下的必然方向。老奥拓不是慢慢变老，而是正在迎来行业层面的 “强制报废”。
一旦市面上成熟的 AI 原生基座产品出现，它将具备极高的自主编排能力、极度灵活的业务适配能力、更低的采购与实施成本、极短的租户切换周期、敏捷且廉价的迭代模式。到那个时候，传统存量 SaaS 不会有平缓、漫长、慢慢流失客户的过渡期，淘汰会来得非常快。
淘汰节奏不取决于老系统好不好修、能不能继续补 bug，只取决于率先拿到这套 AI 原生底座的厂商，它的客户拓展与交付能力有多强。客户在横向对比之后，会快速倾向于可以低成本、快速落地、按需编排业务的新平台。老旧系统的客户流失不是渐变，而是断崖式的。
这个报废不是今天立刻停服下线，而是三重约束在持续收紧：客户的诉求、竞品的能力、AI Agent 的底层逻辑，三者共同抬高了下一代 SaaS 的准入门槛。未来客户采购软件，不再只是买单据录入、报表查询的功能，而是要看平台能不能支撑 Agent 自主编排、自动实施、自助运维；同行一旦率先跑出标准化元模型基座，就会形成代差。
到那个时候，就算愿意持续投入人力修补存量系统，也拿不出匹配下一代需求的能力，产品会快速失去竞争力。就像老旧燃油车，还能开，但政策、市场、配套生态不再为它持续投入，淘汰只是等待对手吹响号角。
所以我们的战术原则：战略上认清必然、择机替换，战术上隔离稳住、双线并行。老奥拓继续上路、保养、维修、接待现有乘客，保证业务连续性；与此同时，我们从零开始，按照面向 AI 编排的标准，设计一套全新的基座。
早启动、早沉淀标准、早跑通试点，就能更早吃到范式跃迁带来的红利，而不是等到竞品产品成熟、市场窗口关闭之后，被动仓促重构。 也就是我们后面要展开讲的：元模型中心、多维鉴权中心、流程规则引擎三驾马车。 这套基座从设计第一天开始，目标就不是给人拖拽页面，而是构建一套机器可读、语义标准、边界清晰、原子化的业务世界。
80% 同质化的管理场景（档案、证照、基础单据、通用审批、标准查询详情），由元模型统一驱动，库表、接口、视图、权限切面自动标准化生成；基座只输出干净、不带业务分支的原子能力。 差异化策略、动态分支，交给上层规则引擎和 AI 编排层。 当底座本身的业务语义是标准化的，Agent 才真正具备可靠编排、自主实施、自助运维的可能性。这个智能，不是贴在外面的副驾，而是整车原生设计的一部分。
电车不是 “跑得更快的奥拓”，它的动力、电控、感知、底盘全部是重新设计，原生适配智能化。AI-Native 基座同理：它不是重构一版更好看的传统 SaaS，它是一套新的领域运行时范式。
三、怎么选？判断标尺
我不会简单说改装路线完全不能选。如果你的目标，仅仅是应付老板和客户，皮包AI未尝不可。
但如果你的判断是：AI 会深度重构 B 端 SaaS 的生产、交付、运维方式，未来平台核心竞争力来自 Agent 自主处理业务，那存量改造这条路，本质是一条天花板明确的死胡同。
我的选择：稳住奥拓，造电车。 老系统作为存量资产持续运维，保障现有租户；把下一代产品主线、核心研发资源，投向元模型驱动的 AI-Native 基座。
下一篇预告
很多人会问：为什么不能一边用一边慢慢改造？存量系统的问题，难道只是代码写得烂，重构一遍代码就能解决？ 下一章《认知对齐：范式问题导致的结构性负债》，我们深入拆解：存量 SaaS 的复杂度根源，不是 bug，不是技术选型落后，而是范式层面的结构性负债。
