前言现在几乎所有 B 端 SaaS 团队都站在同一个十字路口 存量系统跑了很多年业务不能停、付费租户不能下线同时老板、客户、行业声音都在催着做 AI 原生。 摆在架构师面前天然只有两条路路线一在现有系统上持续改造、叠加 AI 能力相当于给一台老奥拓翻新、加装电机、换内饰、上大屏尽量让它跑得更快、看起来更智能。路线二稳住老系统并行建设一套全新底座时机成熟之后整体割接下线相当于直接放弃改造奥拓造一台全新的电车。行业里绝大多数团队下意识选择第一条。看起来风险更低、投入更可控、可以复用存量资产也是最稳妥、最容易拿到立项的方案。 但我在零售 SaaS面对六十万行代码的权限中心、资质证照、零供管理这类厚重存量模块反复推演之后结论很反直觉给奥拓加装 AI有不可突破的物理上限。一、当下主流方案给奥拓加装 “AI 聊天副驾”现在最流行的 AI 赋能玩法就是我们常说的外挂 AI 把老系统已有的 API 统一封装套一层对话入口对接大模型配上 RAG 知识库。对外包装成 AI 原生产品。 它能做到什么新手用户不知道菜单在哪可以问 AIAI 引导页面跳转简单查询类需求通过对话组装参数调用后端接口返回数据把系统手册、操作文档喂给 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不是技术选型落后而是范式层面的结构性负债。
前言现在几乎所有 B 端 SaaS 团队都站在同一个十字路口 存量系统跑了很多年业务不能停、付费租户不能下线同时老板、客户、行业声音都在催着做 AI 原生。 摆在架构师面前天然只有两条路路线一在现有系统上持续改造、叠加 AI 能力相当于给一台老奥拓翻新、加装电机、换内饰、上大屏尽量让它跑得更快、看起来更智能。路线二稳住老系统并行建设一套全新底座时机成熟之后整体割接下线相当于直接放弃改造奥拓造一台全新的电车。行业里绝大多数团队下意识选择第一条。看起来风险更低、投入更可控、可以复用存量资产也是最稳妥、最容易拿到立项的方案。 但我在零售 SaaS面对六十万行代码的权限中心、资质证照、零供管理这类厚重存量模块反复推演之后结论很反直觉给奥拓加装 AI有不可突破的物理上限。一、当下主流方案给奥拓加装 “AI 聊天副驾”现在最流行的 AI 赋能玩法就是我们常说的外挂 AI 把老系统已有的 API 统一封装套一层对话入口对接大模型配上 RAG 知识库。对外包装成 AI 原生产品。 它能做到什么新手用户不知道菜单在哪可以问 AIAI 引导页面跳转简单查询类需求通过对话组装参数调用后端接口返回数据把系统手册、操作文档喂给 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不是技术选型落后而是范式层面的结构性负债。
