AI 热潮让许多并购新闻看起来像一场模型军备竞赛，但模型本身更新很快，单一榜单优势也可能在几个月后消失。真正耐用的收购对象，通常是难以短期复制的组合：研究团队、行业数据、嵌入工作流的产品、计算与交付能力，以及已有客户入口。
本文选取四条已经公开完成、且能看到后续整合动作的路径。它们来自公司公告，适合观察战略方向，却不能把公告中的预期收益当成已被独立验证的经营结果。复盘重点不是判断哪笔交易“最划算”，而是看收购方究竟想补齐哪一层能力。
## 先区分四种被收购能力
第一种是研究与核心技术，目标是获得长期模型能力和高密度人才。第二种是垂直工作流，产品已经进入具体岗位，理解行业术语、流程和交付标准。第三种是数据基础，包括集成、质量、目录、元数据和主数据。第四种是用户入口，把自然语言请求连接到现有业务系统。
一家公司可能同时具备多种能力，但主线必须清楚。若只用“拥有 AI”解释收购，就很难设计整合优先级，也无法判断一年后是否取得进展。
收购前应把能力写成可测试假设，例如“把临床语音直接转成结构化记录”“让智能体访问统一的数据语义”“把员工问答连接到可执行工单”。完成交易只是取得资源，假设仍要通过产品和客户数据验证。
## Google DeepMind：研究并购走向组织合流
DeepMind 在 2014 年加入 Google。它早期的强化学习、AlphaGo、WaveNet 和 AlphaFold 等成果，展示了独立研究组织的探索能力；Google 则提供大规模计算、工程基础设施和触达产品的渠道。
到了 2023 年，Google 将 DeepMind 与 Google Brain 合并为 Google DeepMind。2024 年又进一步把更多模型研发集中到该组织，并把 Gemini 应用团队拉近模型团队。公开说明反复强调的不是某一次模型移植，而是简化决策、集中算力和缩短研究到产品的反馈链。
这个案例说明，研究型收购往往需要较长时间保留自主性，但随着技术进入主产品，又需要重新设计组织接口。过早把研究团队拆散，可能损失探索能力；长期完全隔离，则难以利用收购方的工程与分发优势。
## 微软与 Nuance：购买垂直工作流
微软在 2022 年完成对 Nuance 的收购。2021 年公告给出的交易价值为 197 亿美元，包含净债务。Nuance 的价值不只在语音识别模型，还在医疗等行业长期积累的产品、术语、部署经验和工作流程。
通用模型能把语音转成文字，却不自动知道临床记录如何组织、医生在什么时刻确认、结果怎样进入既有系统。垂直产品的护城河往往藏在这些细节里：字段、模板、集成、纠错方式和一线使用习惯。
对收购方而言，合理整合不是立刻把所有界面换成统一品牌，而是先让云平台、身份、计算与垂直应用形成稳定接口。对被收购团队而言，行业知识若只存在于少数专家脑中，就很难扩展；它需要转化为数据规范、评测集和产品流程。
## Salesforce 与 Informatica：先补数据底座
Salesforce 在 2025 年 11 月完成收购 Informatica。公告列出的重点包括数据目录、集成、质量、元数据和主数据管理，并明确把这些能力与智能体所需的数据基础连接起来。
这代表另一类 AI 并购逻辑：不是再买一个聊天界面，而是解决智能体“能读到什么、字段是什么意思、不同系统中的客户是否是同一个对象”这些底层问题。
数据产品的整合难点在于语义而非搬运。两个系统都可能有名为“客户状态”的字段，却采用不同更新周期和业务定义。若只打通 API，没有统一对象、血缘和质量规则，模型会更快地读取冲突数据。
这类并购是否产生价值，应观察跨系统数据接入是否更快、重复管道是否减少、智能体使用的数据能否追溯，以及客户是否真的采用组合后的工作流，而不是只看功能清单变长。
## ServiceNow 与 Moveworks：把入口接到执行
ServiceNow 在 2025 年 12 月完成对 Moveworks 的收购。Moveworks 带来员工侧的对话助手、企业搜索和推理能力，ServiceNow 的基础则是跨 IT、人力和客户服务等场景的工作流。
2026 年 2 月，ServiceNow 公布 EmployeeWorks，把 Moveworks 的会话与搜索界面连接到统一门户和自动化流程。这个时间线体现了较清楚的产品组合：一个负责理解员工请求和寻找入口，一个负责把请求转化为可追踪的业务动作。
用户入口与执行引擎互补，但也容易重叠。双方可能都有搜索、助手、路由和管理界面。整合团队需要尽快确定哪个组件成为默认入口、哪个保留为服务，以及原有客户的集成是否继续兼容。
## 并购前先画能力地图
技术尽调不能只跑几套公开基准。团队应把目标公司的模型、数据、产品、基础设施和人员能力分别列出，再对应到收购方已有系统，标记真正缺口、可复用接口和明显重叠。
模型层要检查训练与推理能否复现、关键能力是否依赖第三方服务、线上成本随流量如何变化。数据层要确认来源、版本、标注流程和更新频率。产品层则要观察真实用户从输入到完成任务的全过程，而不是只看演示。
还要识别“关键知识载体”。某项能力究竟存在于代码、数据、客户配置、少数研究人员，还是长期建立的一线服务团队？载体不同，整合计划完全不同。
## 用联合评测代替口号协同
并购双方常说技术“高度互补”，但互补需要具体实验。最有效的起点是共同建立一套任务评测：使用被收购产品的真实工作流，比较整合前后质量、延迟、人工步骤和完成率。
例如，数据平台与智能体结合后，不只测回答是否流畅，还要测实体匹配、字段新鲜度和工具调用成功率；对话入口连接工作流后，要测请求是否真正闭环，而不只是用户是否点开了聊天窗口。
联合评测也能降低组织争论。两个团队不必先决定谁的技术“更先进”，而是让各自方案在同一任务、同一数据和同一成本口径下运行。
## 百日整合先保护正在运行的产品
交易完成后的第一个阶段，应建立统一负责人、系统清单和客户依赖图。高风险动作包括立即迁移所有账号、改写稳定 API、合并计费或停止旧版本。它们看起来能快速统一，实际上容易制造支持压力。
前 30 天先固定服务水平、关键人员和版本发布节奏；接着选择一个互补度高的联合场景，打通身份、数据与遥测；到 100 天时，用真实客户或内部用户验证组合流程，再决定更大范围迁移。
技术团队还需要共同的事件编号和可观测性。一次跨产品失败，必须能追到源系统、模型、数据版本和工具调用，否则合并后的系统只会形成更大的黑箱。
## 组织设计决定知识是否留下
AI 收购高度依赖人才，但用留任奖金锁住人员不等于保住能力。研究人员、数据工程师、产品经理和行业专家之间形成的协作网络，才是难以复制的资产。
整合时应保留能做完整决策的小团队，同时建立与平台、销售和客户支持的明确接口。若每项技术选择都要经过多层审批，原团队会失去速度；若完全不共享基础设施，又会重复建设。
文档、评测和轮岗比大规模会议更有效。让两个团队共同维护模型卡、数据字典、故障手册和基准样本，知识会逐步从个人经验变成组织资产。
## 最常见的四类失败
第一，买的是当时的模型分数，技术窗口过去后没有留下产品或数据优势。第二，双方产品大量重叠，却长期不决定主线，客户面对两套入口和两套路线图。
第三，只完成账号和品牌合并，没有打通数据语义、评测与故障追踪。第四，把所有希望都写进交叉销售，却没有证明组合产品能完成一个新的端到端任务。
还有一种隐蔽失败：为了统一平台，过度重写成熟产品，使原有用户体验退化。整合价值应来自减少摩擦，而不是让客户为组织调整重新实施一次系统。
## 用哪些指标复盘并购
短期看关键人员稳定性、服务连续性和首个联合场景的上线时间。中期看组合流程的任务完成率、人工步骤、成本、延迟和原有客户迁移情况。长期才看新产品收入、客户留存和研发复用。
对研究型交易，还应观察论文或演示到产品能力的转化周期，以及共享计算和工具是否减少重复工作。对工作流与数据交易，则更适合衡量连接系统所需时间、数据错误率和端到端解决率。
所有指标都需要交易前基线。没有基线，“协同显著”只是无法核验的叙述。
## 大厂案例给出的共同答案
四个案例分别强调研究组织、垂直工作流、数据基础和用户入口，但共同点很清楚：AI 并购的价值发生在模型之外。只有把新能力接入计算、数据、产品和客户反馈，收购才可能形成长期资产。
因此，复盘一笔 AI 并购时，不妨少问“买到了哪一个明星模型”，多问三个问题：它补齐了哪一层系统；并购后第一个可验证任务是什么；两年后即使模型换代，什么仍然难以复制。
## 参考资料