飞书并入豆包，“书包”来了？

本文是圆方的第1589篇原创

（点击标题下方小耳机标志可收听音频）

01

7月30日，字节跳动发布内部邮件，完成ToB业务重大组织重构。

将飞书拆分，分别归入豆包与火山引擎两大体系。

产品研发层面，飞书产品团队并入豆包，组建全新豆包产品团队，后续飞书将深度与豆包融合打造企业AI生产力产品。

商业化销售层面，飞书市场、销售、客户服务GTM团队并入火山引擎，成立名为“创造力服务平台”的统一To B销售组织；

统筹所有云服务、大模型服务与办公产品的客户拓展。

本次调整并非法律主的体拆分，而是字节内部业务架构重组。

此前豆包、飞书、火山引擎三条业务线独立运营，客户资源与方案相互割裂。

重构后形成清晰分工：

豆包承担AI应用与产品研发底座，火山引擎统一承载云基础设施、商业化销售，打通产品与算力、销售链路，集中发力企业AI市场。

飞书原有功能持续保留，定位转变为豆包企业版重要办公生态载体。

大家好，我是圆方，今天我们一起聊聊：

飞书并入豆包，“书包”来了？

02

熟悉圆方的小伙伴们都知道，圆方一直是飞书的拥趸。

从几年前跟飞书深度合作之后，我们一直也在尝试着深度融入飞书的生态，飞书也把我们作为智慧后勤领域的标杆企业在进行协作。

那么，如何从一个深度使用和参与的角度，理解这一次的调整和变化呢。

其实我个人更倾向于，这就是在已经跟即将到来的AI时代，所带来的必然的调整趋势。

这次组织重构背后所揭示的，是一个远比产品线调整更深层的判断：

组织的形态，正在被模型的能力重新塑造。

03

过往许多年，企业购买软件，本质上是在购买一套固化的流程逻辑。

SaaS产品把最佳实践封装成功能模块，组织去适应系统。

协同工具把沟通和任务管理线上化，追求的是信息的高效流转。

这些积累构成了上一个时代企业运转的数字骨架。

现在，当大模型开始能够理解非结构化指令，能够直接生成分析结论和行动草案。

原本需要人工在多个系统间搬运信息、组合判断的工作，正在被模型能力一层层覆盖。

文档里的要点提取、表格里的趋势归因、跨部门协作中的上下文对齐，这些过去消耗大量认知精力的环节，会逐渐退后成为后台计算。

04

所以，如果一个组织不是从模型原生的视角，去构建自己的运转方式，就意味着它依然把智能当作外挂，把系统和流程当作骨架。

这样的组织会发现，自己精心维护的那套流程逻辑，在模型可以直接穿透信息孤岛、直接响应意图的时候，显得越来越沉重。

这无关某一家SaaS公司做得好不好，也无关某个协同工具是否先进。

关键在于，上一个时代的组织架构，是为人的逐级传递和系统的逐级对接而设计的。

模型能力一旦成熟，它可以跳过许多中间层，直接连接需求与结果。

这种替代，归根结底是组织自身的迭代。

就像工业化生产替代手工作坊时，不是某个匠人的手艺被淘汰；

而是围绕匠人建立起来的那一整套分工、评级和交付体系，被围绕机器建立的工厂体系所取代。

05

今天，模型就是那个新的生产组织核心。

当模型可以持续消化知识、生成判断、调度资源，组织的核心命题就从“如何让人和系统更顺畅地协作”，变成了“如何让模型更深入地理解业务，并把人放在最需要创造力与决断的位置上”。

那些不被模型能力渗透的组织，它的反应速度、认知密度和决策质量，会与模型原生组织之间拉开代际差距。

这种差距不是通过升级某个软件版本能够追平的，因为底层运作逻辑已经分叉。

所以，在这个趋势下，未来真正有竞争力的组织，会呈现一种新的特征：

它的所有业务动作，从第一刻起就发生在模型可理解、可加工的环境中。

沟通记录天然是模型可读取的上下文，决策过程天然有模型参与的痕迹，知识沉淀天然是可被检索和重组的向量。

组织不再需要额外花费巨大力气去搞数字化转型，因为组织的运行本身，就是在持续喂养和训练那个逐渐熟悉自身业务的模型系统。

反过来，如果一个组织，今天还在纠结要不要引入某个协同功能，还在把AI当作一个独立的试点项目，它就错过了这种“原生”构建的时间窗口。

模型能力的吞噬，不是选择性的，而是系统性的。

它会先消化信息处理层，再渗透决策辅助层，最终改变组织边界和组织内权力分配的方式。

06

所以，圆方认为，观察这次行业变局，视线应该越过具体的产品合并，去看那个正在浮现的组织新范式。

模型原生组织，不是用上某个AI功能，而是它的骨架一开始就长在模型之上。

这种迭代已经在发生，它会重新定义什么叫做一个“现代化”的企业。