中心化 AI 平台陷阱：为什么共享 ML 团队会扼杀产品速度
大多数工程组织发现问题的方式都差不多：AI Demo 效果不错，领导层推动更广泛的落地，于是有人决定正确的做法是建立一个专职团队来负责"AI 基础设施"。该团队获得了人员编制、路线图和加速全组织 AI 落地的使命。
十八个月后，产品团队开始提工单来部署他们的提示词。平台团队疲于奔命。那些 Demo 阶段只需几天的功能，现在要花上好几个季度才能上线。而那个最初为了加速 AI 落地而创建的团队，却成了最大的瓶颈。
这就是中心化 AI 平台陷阱——而且出奇地容易跌入其中。
为什么中心化感觉是对的（但实际并非如此）
中心化 AI 基础设施的直觉，乍看之下是合理的。共享基础设施避免重复建设。标准 化工具确保一致性。专职团队可以搞定难题，让产品团队不必操心。
这正是计算资源、CI/CD 和可观测性领域平台工程的运作方式——而且效果不错，因为这些问题本质上是基础设施问题。Kubernetes 集群就是 Kubernetes 集群，部署流水线就是部署流水线。领域专业知识存在于应用中，而非平台。
机器学习则完全相反。领域专业知识——哪些特征重要、哪些失败模式可以接受、产品能容忍多少延迟、哪个评估指标对应业务价值——存在于模型及其运行上下文中。将这些知识与负责构建系统的团队分离，会产生工具无法弥合的鸿沟。
当你中心化 AI 开发时，你并不是在抽象基础设施，而是在抽象专业知识。问题就从这里开始。
三种失败模式
工单队列问题。 每个产品团队的 AI 需求最终都会汇入中心团队的待办列表。需要微调模型？提工单。需要修改检索策略？提工单。需要给智能体添加工具？提工单。中心团队跨业务部门排优先级，这意味着有紧急领域专属需求的团队，要排在优先级各异的其他团队后面。看似协同，实为争抢。
这里有个组织层面的讽刺：ML 专业知识最薄弱的团队——那些最需要帮助的团队——反而受这个队列伤害最深。理解 ML 到可以自给自足的团队会绕过瓶颈。不懂 ML 却离不开支持的团队，既是提工单最多的，也是等待最久的。
抽象错位问题。 中心平台团队构建的抽象旨在适配所有场景。这些抽象能较好地解决中间地带的问题，却在边缘案例上表现欠佳。构建实时定价智能体的 产品团队，与运行夜间文档分类的团队，有着截然不同的延迟需求。做医疗信息检索的团队，与生成营销文案的团队，有着迥异的质量标准。当平台决定统一使用某个模型提供商、某个评估框架、某种部署模式时，有非中间需求的团队便将大量时间花在绕开抽象上，而非构建产品。
更糟的是：这些绕道方案会积累成一套非官方的影子基础设施，平台团队既不知晓也无法支持。平台声称提供的能力与团队实际使用的之间的落差，成了双方共同的维护负担。
所有权空白问题。 当中心团队拥有模型基础设施、产品团队拥有用户体验时，两者之间的接缝就成了责任真空。延迟在集成边界处退化。评估指标无法映射到产品结果。生产事故暴露出不清晰的升级路径。没有哪个团队对全链路有端到端的可见性，在压力下进行根因分析需要跨团队协调。
ML 系统尤其需要基于生产反馈快速迭代——观察错误模式、调整提示词、优化检索——而只有拥有完整技术栈的团队才能做到这种快速迭代。跨团队协调给每一个改进周期都增加了延迟。
康威定律告诉你什么
康威定律指出：组织产生的系统会镜像其沟通结构。对于 AI 系统，这一规律分毫不差：单体式中心化 ML 团队，会产生单体式、僵化的 ML 平台；产品内嵌的 ML 团队，会产生契合各自产品实际需求的系统。
实践含义是：要构建快速、领域感知的 AI 系统，就要围绕业务领域来组织团队。如果你想要一个能快速响应产品反馈的 AI 定价系统，就把一名 ML 工程师放进定价团队。如果你想要一个理解内容语义的 AI 搜索系统，就把一名 ML 工程师放进搜索团队。
反之亦然。如果你想要一致、可审计、成本可控的 AI 基础设施，确实需要一定程度的中心化——但中心化的是基础设施层，而非应用层。
真正需要中心化的是什么
问题不在于平台团队这个想法本身，而在于将平台定义得过于宽泛。
确实有一些问题受益于中心化，而它们几乎全是基础设施层面的问题：
限流与成本归因。 LLM 的使用是基于 Token 的，具有可变性且成本不低。按秒的请求限制无法反映实际的成本分布。一个能执行团队 Token 预算、将成本归因到具体团队和功能、并呈现消耗速率数据的中心 AI 网关，是真正有价值的基础设施——不是因为它控制团队构建什么，而是因为它让每个人都能看到决策的真实成本。
模型访问控制与审计追踪。 模型 API 访问的认证、鉴权与审计日志，是横切关注点，不应出现在每个产品团队的代码库里。中心网关统一处理合规要求，而无需每个团队各自实现（且可能出错的）访问控制。
可观测性与遥测。 一个单点捕获所有模型调用的延迟、成本、质量指标和错误率，能提供分布式实现无法给出的全局洞察。当需要排查延迟突升或成本异常时，数据汇聚在一处要方便得多。
共享基础设施原语。 GPU 集群访问、模型评估的 CI/CD 模板、黄金路径部署模式——这些是合理的平台关注点。 平台的职责是让产品团队能快速启动新 AI 功能，而不是替他们构建这个功能。
不应该被中心化的：使用哪个模型、如何设计提示词、采用什么检索策略、如何针对特定产品上下文评估输出。这些决策所需的领域知识存在于产品团队中。
有效的模式
那些能快速交付 AI 功能的组织，有一个共同的结构：嵌入式 ML 专业能力 + 中心化基础设施。
Netflix、Uber、Airbnb 等组织并没有中心化的 AI 开发团队。它们有提供共享基础设施和工具的平台团队，同时产品团队拥有各自的模型及其决策权。平台团队用采用率和开发者效率来衡量成功，而非构建了多少模型。产品团队用模型质量和业务结果来衡量成功，使用无需自行构建的基础设施。
这一区别至关重要。一个以控制 AI 开发为存在目的的平台团队，会成为瓶颈。一个以消除分布式 AI 开发摩擦为存在目的的平台团队，则能提升效率。人员编制相同，组织结果天壤之别。
对于规模较小的组织，正确答案往往更简单：全栈工程师同时拥有模型和产品界面，再加上针对横切关注点的轻量共享基础设施。小规模下维护清晰团队边界的开销，往往超过其带来的收益。
持续失败的人员配置模式，是那种将模型开发与产品开发完全分离的模式——ML 工程师坐在中心团队，产品工程师完全没有 ML 能力。这会在双向产生永久性依赖，并随着中心团队积压增长、产品团队对交付无能为力而愈演愈烈。
瘦平台界面
如果你正在设计或重新设计 AI 团队结构，该问的问题是：哪些横切关注点是每个团队都需要的，且统一做一次比各自独立实现更有价值？
这个列表比看起来短得多。中心化治理模型访问、成本归因和审计日志。计算与部署的共享基础设施。团队可以根据自身约束选择采纳或忽略的参考实现和黄金路径。
不在列表中的：决定产品团队用哪些模型、构建阻止团队直接调用模型 API 的抽象、为每个产品拥有评估框架、要求每次模型变更上线前都经过中心审批。
大多数中心化 AI 平台努力的讽刺之处在于：建设它们的团队其实知道好的样子——他们见过快速移动的组织如何交付 AI 功能——但"治理 AI"和"防止蔓延"的组织压力不断扩大平台范围，直至平台在自身重量下垮塌。
构建瘦界面。让产品团队拥有自己的模型。用团队交付第一个功能的速度来衡量平台，而不是用组织 AI 技术栈在 PPT 上看起来多标准。
你试图预防的瓶颈，往往正是你自己创造的。
