字节跳动过去三年最值得关注的内部变化不是某款产品突然爆量而是一条清晰的组织动作AI 能力从分散在业务线逐步向一个中心收敛。张一鸣推动的这次“挥刀”重组本质上就是把这个收敛过程推到顶点。如果你在技术公司带团队或者正在做 AI 大模型应用、AI Agent、AI 编程、AI 视频这类方向这篇文章值得看完。真正要理解的问题不是“谁留下了谁被调整”而是为什么大厂做 AI 最后几乎都会走向“集权”以及这一轮组织重构背后有哪些可以迁移到中型团队的设计思路。1. 先把“AI 集权”这三个字拆清楚很多人看到“集权”两个字会下意识理解为创始人重新夺回业务控制权类似“一言堂”。这个理解太窄。字节跳动这三年围绕 AI 的组织调整真正收走的是三类关键权力而不是单纯的汇报关系。1.1 收走模型能力的主导权最早的时候各业务线都有自己规模不大的算法团队。内容推荐团队做召回和排序工具团队做文本理解视频团队做画面分类这些能力在各自场景里都能跑但彼此不共享底层模块。到了大模型阶段问题开始暴露。如果还按业务线拆分每个团队都要维护一套底模微调、推理服务、评测链路和训练框架人力成本翻倍计算资源浪费非常严重。更关键的是没有一个大团队能对“模型本身”负责。集权之后模型能力变成公司级资产。业务线不再保留独立训练大模型的权限需要模型能力时走统一平台。这是第一个核心变化。1.2 收走算力资源的分配权大模型训练和推理都是重资产投入。显卡采购、训练集群搭建、推理资源池扩容每一项都涉及大额预算。如果算力分散在各业务线就会出现典型的“公地悲剧”每个团队都怕分不到资源所以申请预算时习惯性多报另一方面谁的关系硬谁就能拿到更多卡最终导致资源利用率并不高。集权之后算力资源由中心统一规划。训练任务按优先级排队推理服务按调用量结算资源使用情况沉淀成可视化指标。这个转变看着很简单实际落地时阻力非常大因为它直接触动了各业务线的预算支配能力。1.3 收走数据回流和产品定义的主权AI 产品有个特点使用场景越丰富数据回流越重要。系统需要知道新增用户在哪里被卡住在哪类输入上效果不好哪个场景的召回率明显偏低。在分散模式下数据散落在不同产品里模型团队拿不到完整链路。即使拿到了业务线和模型团队对“什么问题优先解决”也经常有分歧。业务线想尽快上线功能模型团队想先补数据质量两边都觉得自己是对的。集权之后数据治理、标注规范、评测集建设都被归口到统一团队业务线负责提供使用场景和反馈信息决策路径变短了。2. 三年时间线从内部并线到最终收敛我梳理这个主题时不会把每一步都不加验证地说成官方时间点因为大厂内部调整很难被外部完整观察。但从公开报道和行业观察来看这三年基本可以分成三个阶段。2.1 第一阶段各线自建边界模糊最早期AI 能力是作为一种“技术支持”分散在各业务线里的。用户体验团队用 AI 做推荐内容安全团队用 AI 做审核创作者工具团队用 AI 做辅助编辑。大家各自采购算力各自维护训练任务甚至会重复训练结构非常相似的模型。这个阶段的好处是业务响应快。产品经理提出需求算法团队直接排期不需要经过任何中台审批。坏处是组织之间缺乏统一协议模型格式不一样数据标准不一样评测方法也不一样。等到公司发现这些重复建设已经变成巨大成本时再回头统一代价比一开始就集中要大得多。2.2 第二阶段中台初现模型团队开始收编意识到问题后很多大厂会先做“中台化”。具体表现是成立一个统一的基础模型团队承接通用能力比如语言理解、视觉识别、语音合成。各业务线可以把数据提给中台训练训练完再拿回去做场景适配。这个阶段比完全分散好一点但仍有明显问题。中台团队和业务团队的绩效目标不一致。中台希望把模型底座做好倾向稳业务线希望快速出新功能倾向快。于是产生大量“资源协调”会议模型的迭代周期并没有想象中那么快。那段时间经常能看到的现象是业务线表面接入中台私下又保留了一套“影子团队”继续维护自己的小模型。这种双轨运行既消化了中台的资源又增加了额外人力。2.3 第三阶段顶层直接重组AI 从模块变成主线到第三阶段创始人或最高管理层会直接介入。不再通过中台去协调各业务线而是直接把 AI 相关团队从业务线里抽调出来形成独立的一级组织并且拥有独立预算、独立考核、独立负责人。张一鸣这次“挥刀”重组最明显的信号就是AI 不是某一个业务线的附庸而是一个需要顶层直接定义的战略主线。产品线仍然存在但在 AI 能力上必须依赖统一的模型中心和基础平台。这一步非常关键。因为只有当组织机构真正调整到位后续的算力池化、数据复用、模型共享、人事考核才能顺利推开。否则不管口号喊得多响业务线还是会把 AI 理解成自己的某块业务而不是整个公司的底座。3. 为什么是张一鸣在这个节点“挥刀”很多公司也在挣扎要不要把 AI 团队集中起来但迟迟不敢动因为组织重组通常伴随阵痛。张一鸣选在这个节点推动重组背后有几个很现实的原因。3.1 大模型时代的技术栈不再允许重复建设在早期 AI 领域重复建设的成本还能忍。一个推荐模型和一个图像识别模型底层框架差别很大合并收益不高。但大模型出现后技术栈开始收敛。训练范式基本统一缩放法则被验证多模态架构也被证明可以共用。这时候继续分散本质上是在重复支付巨额训练成本。每多一个训练团队就要多一组 GPU 集群、多一套数据管线、多一批算法工程师而产出的模型能力可能大同小异。这种浪费在财务报表上非常刺眼。作为一个对效率极度敏感的创始人张一鸣不会容忍这种重复建设持续太久。所以“挥刀”不是情绪化动作而是对大模型技术栈逻辑的清醒判断。3.2 算力战争正在变成公司级竞争大模型竞争不只是算法竞争更是算力储备、推理成本和迭代速度的综合竞争。如果算力还分散在业务线公司最需要的“集中冲刺”就做不了。比如某个大版本模型要集中训练需要连续数周占用大规模集群。但业务线如果还在跑各自的推理任务资源就不好协调。最后的结果是谁都慢谁也没省下成本。集中管理之后公司可以对算力做优先级排序哪条产品线最重要先保证哪条哪些业务可以继续用轻量模型不单独吃资源。这种调度能力只有中心化组织才能高效落地。3.3 业务线和模型团队的博弈会拖慢产品节奏一个常见误区是只要模型够强产品自然能做好。实际上大模型产品的竞争非常依赖“模型更新”和“产品迭代”的节奏匹配。模型团队更新了一版能力更强的模型但产品团队还停在旧版接口上体验就体现不出来。产品团队想做一个新的交互形态但模型团队下一个版本才支持产品就只能等。在分散模式下这两个团队经常在“优先级”上博弈。集权的另一个好处就是让这些博弈从“跨部门谈判”变成“同一个组织的内部排期”。虽然也会有优先级冲突但决策链条明显变短。4. 重组之后的组织结构会是什么样很多人最关心的是重组后到底怎么排兵布阵。虽然任何外部观察者都无法拿到精确的内部架构图但从大型科技公司做 AI 平台化时的常规思路可以画出一个相对清晰的参考结构。4.1 典型的四层结构第一层是基础设施层。负责算力集群、训练平台、推理引擎、模型存储和版本管理。这一层目标是让训练和推理像水电一样按需取用。第二层是模型层。负责大模型底座包括预训练、微调、对齐、评测、安全过滤。模型层的产出不是某条业务线专属而是公司内所有产品都能调用的公共能力。第三层是平台层。负责模型接入包括 API 网关、提示词管理、应用框架、外部工具插件、Agent 编排等。业务线不需要理解模型内部细节通过平台就能做 AI 应用开发。第四层是业务应用层。各产品线仍然保留自己的产品经理、交互设计师和运营团队但它们的 AI 功能实现方式变成“调用平台能力 场景化配置”而不是自己再训练一个大模型。这个结构下团队边界非常清楚底层团队对模型能力负责上层团队对用户体验负责平台团队对调用效率负责。4.2 人员评价体系会发生连锁变化组织调整之后最敏感的是考核指标。如果考核体系不跟着变团队协作仍然会出问题。模型团队如果只考核模型精度就会无限堆模型参数不考虑推理成本。平台团队如果只考核调用量就会鼓动业务线多接 API不管业务线实际收益。应用团队如果只考核功能数量就会不断上线新玩法忽略稳定性和安全性。合理的做法是设置联合加权指标。比如模型团队的考核包含模型效果、推理成本、支撑业务数量平台团队的考核包含接口稳定性、调用性能、接入效率应用团队考核包含用户指标和 AI 功能渗透率。这样才能避免各层之间互相推锅。4.3 新产品仍然要有相对独立的“灵活边界”中心化最容易出现的副作用是流程僵化。如果每一次产品试错都要先走模型平台的需求评审、排期、灰度、上线那创新天然会被卡住。所以大厂通常会在中心化体系之外给重点新产品预留实验空间。允许它们在特定前提下用实验性模型快速试错等验证清楚后再并回统一平台。这是很多“集权”方案里最容易忽略也是最能保护创新的设计。5. 这类组织调整最容易踩的坑我不能说这次重组一定会完全成功因为任何大规模组织调整都有返工可能。但从过往大厂经验看以下几个坑是集中化过程中最常见的。5.1 模型团队变成新的性能瓶颈分散模式是各业务线自己调度虽然重复但响应快。集中之后所有业务都依赖统一模型团队如果模型团队排期不合理就会拖累全线产品。出现这个问题的典型现象是业务线提了一个模型优化需求半个月没有动静模型团队说自己在做更重要的大版本升级。这其实是中心化组织特有的“单点阻塞”必须在调整初期就建立明确的 SLA 和需求分级机制。5.2 数据流没有真正打通集中了个寂寞有些公司集中了团队但没有集中数据。模型团队拿不到各业务线的真实数据只能用公开数据集或以前积累的旧数据最终模型能力反而不如业务线自己训练。判断数据是否真正打通可以看三个指标模型团队能不能看到实时的线上样本、能不能把业务反馈回流到训练集、能不能对某个行业场景做专门的数据配比。如果这三条都做不到集中化就名存实亡。5.3 KPI 冲突没有解决就会形成隐形对抗公司说“集中资源”但各业务线的预算还是独立的于是业务线会担心我把数据贡献出去自己的指标却没提升凭什么这种隐形对抗不会写进周报但会在流程中处处体现。解决这个问题的办法不是靠“强调大局观”而是重设利益分配。要么把 AI 能力相关成本从业务线预算里拿掉变成公司公共成本要么允许业务线在调用平台能力后把模型带来的增量效果计回自己团队。只有利益分配清晰了协作才能真正发生。5.4 合并过程造成关键人员流失模型和算法团队的优秀人才往往不只看薪资还看重自主权和项目影响力。组织调整后如果个人原本负责的边界不再清晰部分人会选择离开。尤其是那种业务线里的高级算法工程师原先是“队里的技术权威”合并后变成“中心团队的其中一个角色”心理落差并不小。这种流失往往不在组织架构图里体现却会在后续模型迭代速度上造成明显空白。5.5 回退标准没有提前定义组织调整不是一次性的。调整完成后必须定义清楚什么情况下可以继续加大集权什么情况下要允许部分团队独立退出。如果完全没有回退机制遇到问题只能硬扛成本反而更高。我通常会建议负责人把回退标准写到调整方案里哪怕不公开也要让自己心里有数。6. 不是每家公司都适合“挥刀”看到大厂调整组织结构很多中小团队容易冲动模仿。但搞组织调整和搞技术框架选型一样必须看自己的实际情况。6.1 真正适合集权的几种状态如果你所在公司能满足以下大部分条件集中化调整的收益会明显大于风险。第一有多个业务线都在使用 AI 能力。如果只有一条产品线集中和分散没有本质区别纯看管理偏好。第二各业务线正在重复建设类似的模型能力。比如两个团队都在做文本摘要三个团队都在做视频理解这就是明显的合并信号。第三公司能提供一个足够强的模型中心团队。如果现状是大家都差不多的水平盲目合并反而会让最差的人主导公共能力。第四算力和训练成本已经成为公司级瓶颈。这时候不集中成本几乎没法控制。6.2 不适合照抄“集权路线”的情况如果你的团队人数较少比如算法团队总共只有十几个人不建议完全照抄大厂的四层结构。层级一旦增加沟通成本可能比重复建设还要大。如果产品高度垂直业务场景非常特殊通用模型平台不一定能准确满足业务线需求。这时候更适合让业务线保留部分模型定制能力平台负责提供基础模型和工具链而不是把权限全部收走。如果公司正处于极早期产品方向还没跑通也不要急着调整组织。先用小团队快速验证产品等确认 PMF 后再考虑把能力平台化。这个阶段过早集权只会拖慢试错速度。6.3 一张自查清单我以前整理过一个简化版自查清单适合管理者在开会前先过一遍检查项判断方式是否存在重复模型建设统计各团队正在训练或微调的模型数量及功能重合度算力资源是否集中可控看基础设施预算审批路径和实际使用报表数据是否跨团队共享测试模型团队能否直接访问关键业务数据模型迭代是否有统一节奏看新模型上线时间和各产品接入时间的间隔关键人才是否愿意留在新体系做一次投入产出访谈别只看薪资数据是否有回退机制临时记录调整后的不良信号和触发条件这些条目不需要全部满足但至少过半才有必要学大刀阔斧的“集权”路线。7. 落到团队管理层的实际操作建议如果你不是字节的员工也不是张一鸣级别的决策者这套分析还有什么用我觉得最有用的是把“组织调整”这件事从“老板拍板”变成“可拆解的管理动作”。下面是一套比较通用的落地顺序。7.1 第一步先做一次 AI 能力盘点不要急着调整汇报线。先回答几个客观问题团队里有哪些模型哪些依赖外部 API哪些已经在业务线上稳定运行哪些还处于试用阶段。然后算一下总成本训练成本、推理成本、人力成本、协调成本各占多少。这一步做完你会看到一张现状地图。有些团队其实没有多少模型能力但为了面子也在对外宣称“自研大模型”。这类信息不澄清后面所有重组设计都会失真。7.2 第二步按三个维度定义权限边界建议在组织图上明确三个维度的归属模型训练权限归谁、算力申请权限归谁、业务发布权限归谁。这三个维度可以分开设计。例如模型训练权限可以集中但业务线允许在平台上做轻量微调算力申请权限可以集中但产品线可以按固定配额自主调度业务发布权限尽量留在业务线中心只做质量门禁。7.3 第三步设置一个三个月的验收期大规模组织调整最怕“新架构还没磨合就急着证明自己对”。我建议给新架构至少设置一个季度的验收期前两个月允许效率略降第三个月才开始看关键指标是否恢复。指标不建议只盯着模型精度。重点看模型迭代周期、业务接入速度、单位请求成本、团队协作满意度这几个方向。只有这些综合指标同步改善“集权”才算真正有效。7.4 第四步把治理机制沉淀成文档和系统很多公司重组后靠人治架构图变了但流程仍然靠各负责人私下沟通。长期看这样不稳定。更好的做法是把权限边界、需求流转路径、资源申请模板、评测标准和发布门禁固化成可执行的东西。哪怕是内部的飞书文档、接口文档、配置工具都可以。制度化程度越高重组后再次陷入混乱的概率越低。8. 写在最后的核心判断字节这轮重组是一个很典型的信号当大模型基础设施化之后AI 组织也会跟着基础设施化。模型、算力、数据、平台不再是某个业务线的私产而是公司共用的底层能力。对于管理者来说真正要学到的不是“张一鸣挥刀”这个动作而是动作背后的判断顺序先确认技术栈是不是趋于统一再确认算力和数据是否已经构成瓶颈最后才决定是否通过组织调整来解决问题。如果你正在负责一个 AI 相关团队我的建议很直接先花两周把团队现有的模型能力、成本、调用量、核心瓶颈拉通再看自己到底需不需要“集权”。很多时候问题不是出在组织架构而是出在算力账单、数据断点或者 KPI 错位。这些问题不改就算把团队翻来覆去重组合并也很难解决真正的麻烦。