从 " 上云 " 到 " 上 AI"，客户更难离场

当然，结束内部赛马确实可以减少重复投入。但对今天的 BAT 来说，省下几支产品团队的研发和营销费用，恐怕只是微不足道的因素。而他们之所以急着统一入口，更重要的原因可能是：AI 带来的客户黏性，远远超过了过去的云计算。

事实上，在过去十几年里，云厂商也一直都在尝试 " 绑架 " 客户，不过，云厂商的方式是用基础设施 " 绑住 " 客户。企业一旦把服务器、数据库和业务系统部署在某一家云上，再想离开，就要重新迁移数据、改造系统，并承担迁移过程中的业务风险。理论上，企业使用得越久、部署得越深，对云厂商的依赖也就越强。

但实际情况并没有这么简单。云计算确实提高了企业离开的门槛，却始终没有彻底改变企业衡量成本的习惯。

小红书就是一个典型案例。

创业早期，小红书几乎将全部技术体系搭建在公有云上，也是腾讯云较早的一批客户。对当时的小红书而言，购买云服务器不需要提前建设机房，也不必养一支庞大的基础设施团队，业务快速增长时还可以随时扩容。公有云提供的弹性，帮助小红书以更低的成本完成了早期扩张。

但随着业务规模扩大，小红书并没有因此越来越依赖某一家云厂商，反而开始不断分散这种依赖。

一方面，小红书逐渐采用多云架构。2024 年，它又将储存过去 11 年原始数据、规模达到 500PB 的数据湖迁往阿里云。换句话说，即便企业早期深度使用一家云厂商，仍然可以把部分核心业务转移到另一朵云上，让不同厂商相互替代、相互制衡。

另一方面，小红书也开始建设自己的基础设施。随着计算资源达到数百万核 CPU，单纯依赖公有云带来的成本、调度和运维问题逐渐暴露。为此，小红书形成了一套 " 自建优先、公有云兜底 " 的资源调度方式：稳定、可预测的业务优先放在自建集群，只有自建资源不足，或者出现突发流量时，才调用公有云进行补充。

这件事恰恰说明了云计算黏性的边界上限。

当企业规模较小时，公有云的弹性和低门槛更加划算；等到业务规模足够大，企业仍然会重新计算成本，并通过自建、混合云和多云架构，削弱对单一厂商的依赖。云厂商可以提高客户搬家的成本，却很难

其中，最重要的是模型工程体系的沉淀。今天企业把大模型接入业务，早已不是写几个提示词、调用一个接口那么简单。

一个模型要真正进入客服、销售、财务或者研发流程，企业需要先建立自己的业务测试集，明确准确率、响应速度、调用成本和风险边界，再围绕不同任务配置模型路由、工具调用、输出结构、人工审核和异常处理机制。

这意味着，企业沉淀下来的不是几个提示词，而是一套围绕特定模型建立起来的生产标准。

哪种任务交给大模型，哪种任务交给小模型；什么情况下允许它直接执行，什么情况下必须转给人工；一次调用可以容忍多少成本和延迟；模型升级之后，原有流程是否会出现新的错误，这些都需要经过长期测试和真实业务验证。

而如果切换到其他的办公应用，所调用的大模型也会改变，企业往往需要重新跑一遍业务评测，确认新模型在数百乃至数千种真实场景中，仍然能够稳定运行，而这对于有一定体量的 B 端客户来说，几乎是无法承担的后果。

这也解释了为什么三家都在此时停止了内部赛马，开启了办公产品的整合。

过去产品分散时，客户可以在 QoderWork、悟空和 MuleRun 之间选择，也可以同时试用 WorkBuddy 和 QClaw。对大厂来说，这种竞争虽然有利于探索产品方向，却不利于形成真正的客户黏性：账户分散、数据分散、资源分散，客户也不会放心把核心业务交给任何一款前途未定的产品。

只有先确定一个长期存在的主入口，大厂才有可能说服企业将更多系统和权限向它开放。

字节这次调整尤其明显，豆包掌握模型和 AI 产品，飞书掌握企业办公场景，火山引擎则掌握云服务与商业化。

三者一旦被接进同一套体系，字节向客户出售的就不再只是飞书席位、豆包模型或者火山引擎算力，而是一套从工作入口到任务执行的完整企业 AI 服务。

阿里和腾讯虽然暂时只收拢了产品线，但方向也是一样的：先结束内部产品之间的竞争，再争夺企业唯一的 AI 入口。并且可以肯定的是，未来的钉钉和企业微信，也注定会和飞书一般，成为 Qwen 和 hy 的 " 下属产品 "。

因此，这轮密集的组织调整表面上是在减少重复建设，背后却是一场更直接的客户争夺，争夺谁能成为企业客户默认的 AI 入口。

一旦他们习惯从这里发起任务，BAT 们获得的就不只是一笔软件收入，而是一段不可分开的客户关系，到时候哪怕提出一些 " 过分 " 的要求，客户们也得捏着鼻子接受。

云时代，企业还能算上云和下云的账；AI 时代，一旦入口、权限和流程都交给同一平台，企业客户就再也别想离开。届时，大厂拿到的就不只是收入，更是说一不二的绝对议价权。