7月，飞书内部群弹了一条消息。
不是公告，不是全员邮件——是一封内部邮件的截图，从某个高管群流出来的。
上面写着：飞书产品团队并入豆包产品团队，GTM团队并入火山引擎。
我正在调一个多维表格的自动化流程，手指悬在触控板上，愣了大概5秒。
然后我默默刷新了一下飞书官网。首页已经弹了个窗口："豆包进飞书啦！低至99元/月。"

我在飞书做了3年半。
说"飞书"准确来说是飞书的多维表格团队。我们组6个人，负责自动化引擎的后端重构，技术栈是Go + gRPC + TiDB，典型的飞书中后台标配。
这3年半我做得不差。绩效B+，带过1个实习生，写过团队内部的自动化引擎文档。去年季度会上还被点名表扬了一次"工程效率提升显著"。
但看到那封邮件的瞬间，我知道——这些都不算数了。

不是个例，是整个产品线在变
消息出来后，我翻了一圈招聘平台。数据很扎心：

• 飞书2024年ARR约3亿美元
• 字节大模型业务ARR已达40亿美元，超过国内其他模型公司总和
• 豆包日均Token调用量突破180万亿

在40亿面前，3亿是什么概念？是零头。是一个可以被"整合"掉的数字。
更让人慌的是，不只是飞书。阿里把多个Agent产品整合为"千问办公"交给钉钉操盘；腾讯把QClaw业务并入WorkBuddy体系；华为小艺从诞生起就是鸿蒙全场景统一AI入口。

大厂已经用脚投票了：办公工具不再是独立生意，而是AI能力的交付渠道。
当天下午，我做了一件事
我没有等HR找我聊，而是主动去找了我们组的tech lead。
他说："目前产品侧并入豆包，人员编制暂时不变。但——"
他顿了一下："接下来的项目方向会全面围绕豆包企业版来做。你之前做的自动化引擎，可能要'翻译'成豆包可以调用的Skill。"
"翻译"这个词，刺痛了我。
我之前花3年搭建的自动化引擎，现在需要被"翻译"成另一个系统的组件。就像你盖了一栋楼，然后被告知这栋楼要变成另一个小区的配套设施。
但说实话，我也不是完全没准备
去年开始，我就在自学大模型相关的东西。不是跟风，是隐隐觉得——光做办公工具的后端，天花板越来越低了。
我做了3年Go后端，对并发、分布式事务、数据一致性这些东西是熟的。但大模型时代的后端，和传统后端有一个本质区别：
传统后端处理的是确定性逻辑——输入A，经过B处理，输出C。
大模型时代的后端处理的是不确定性——你给AI一个指令，它可能返回任何东西。你的系统设计要围绕"AI可能犯错"来做兜底。
这两件事完全不同。

对了。顺嘴提一句，技术大厂，前后端-测试机会，全国一线及双线城市均有坑位，待遇和稳定性还不错，感兴趣看看。

一个月后
我现在还没被调岗，但工作方式已经变了：
原来的自动化引擎需求，70%变成了"怎么让豆包AI更好地调用自动化能力"

• 我花了2周时间学了一套Prompt Engineering的基础范式
• 组内的代码review标准变了——以前看的是代码质量，现在看的是"AI调用链路是否安全、可控、可回滚"

上周，新来的豆包侧产品负责人开了一次全员会。他说了一句话，我印象很深：
"飞书不是一个被干掉的产品。它是豆包进入企业的入口。"
这话听着像安慰，但细想有道理——如果豆包的AI能力需要通过飞书的文档、表格、会议场景来落地，那飞书的工程师确实还有活干。
只是，活的性质变了。

给所有做SaaS的同行一句话
SaaS没死。死的是"独立存在的SaaS"。
2026年的企业服务逻辑是：大模型是底座，办公工具是场景，AI能力是交付物。三者必须拧成一股绳。
你如果只懂写Go、写gRPC、写TiDB查询优化，你会越来越边缘化。
但如果你懂大模型的工具调用、懂AI的安全边界、懂怎么把传统后端能力"翻译"成AI可以调度的Skill——你反而比以前更值钱。
时代变了，你的技能树也得跟着长。