联邦制 AI 团队：为何集中 AI 专业能力反而制造了它本应解决的问题
中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队，统一工具链，建立治理机制，让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见，在董事会演示中无懈可击。然而在实践中，它可靠地生产出一种失败模式，看起来恰恰就像它本要消除的碎片化。
中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了；一个 9 个月的安全审查把它埋葬了。
2025 年，企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。
为何企业要组建中央 AI 团队
集中化的理由初听起来很有道理。AI 技能稀缺。如果把 AI 工程师分散到二十个产品团队，就会产生二十套不一致的提示词工程方法、二十套不同的可观测性方案、二十套独立的供应商关系，以及没有任何人有权执行安全标准。汇聚专业知识能够创造杠杆。中央团队可以构建每个产品团队都能使用的共享基础设施，谈判更优惠的模型合同，并承担法律和安全部门所需的合规责任。
受监管行业对此有格外强烈的吸引力。医疗、金融服务，以及任何涉及敏感用户数据的领域都需要一致的执行标准。联邦制模型中的治理真空是真实存在的风险——而非假设。
组建中央 AI 团队的理由并没有错。问题在于它只捕捉了成本方程的一半。它考虑了碎片化的成本，却忽略了距离的成本。
随之而来的失败模式
由设计导致的瓶颈。 中央团队的产能是固定的，产品团队的需求却不是。一旦 AI 从试验升级为战略优先项，公司里每个产品经理都会提出使用场景。中央团队能够良好地并行推进两三个项目，到了八个，一切都慢下来；到了十五个，队列已经长到产品团队干脆不再提需求——他们要么自己摸索，要么等着一个不断延期的路线图排期。
这不是人员编制问题。向中央团队招人增加了人手，但并不能给那些工程师提供他们所需要的领域上下文，以便为他们并不身处其中 的团队做出正确决策。集中式架构中更多的工程师，只意味着更慢的队列和更大的知识鸿沟。
双向知识孤岛。 大多数组织直到积重难返才看到的失败模式：中央团队了解模型，产品团队了解领域，双方都不够了解彼此，无法在没有大量交接开销的情况下提供有效帮助。
当客服 AI 在边界情况下开始给出不一致的回复时，产品团队知道"边界情况"在他们语境中意味着什么——什么类型的工单、什么用户群体、什么情感基调。中央团队知道如何调试模型——温度设置、上下文窗口问题、检索失败。在集中式架构中，这两类知识必须通过会议和工单相互传递。调试周期漫长，修复往往被误判，真正能让 AI 功能变好的迭代循环始终无法收紧。
平台与产品的摩擦。 中央团队优化复用，产品团队优化结果。这两者并不相同。
构建检索层的中央团队会为多个用例而构建，使用保持通用性的抽象。而需要检索的产品团队——比如法律文档搜索，或医疗编码查找——需要针对其数据的统计特性、对其用户重要的精确率-召回率权衡，以及其用户实际遭遇的失败模式进行调优。通用层并不适用。适配它要么需要弯曲中央团队的抽象，要么构建绕过中央团队的变通方案，而后者本身就违背了组建中央团队的初衷。
康威定律不在乎你的初衷
康威定律认为，组织设计的系统会映射其沟通结构。在软件领域，这意味着如果你的后端、数据和 AI 团队是拥有独立汇报链条的分 立团队，你就会在沟通最困难的组织边界处，得到紧耦合的系统和脆弱的接口。
应用于 AI：集中化的 AI 团队生产通用的 AI 系统。服务所有人的团队最终对任何人都不够好。其模型针对聚合性能调优，评估标准反映的是跨所有用例可衡量的内容，而不是任何特定场景中最重要的东西。它交付的系统看起来就像其自身的组织结构——集中化、通用、与它本应解决的领域问题隔了一层。
反过来也成立。当 AI 能力存在于拥有领域知识的团队内部，那些团队所构建的系统会随时间发展出领域专属性。调优提示词的工程师和出席冲刺评审的是同一批人，在那里用户研究员会展示为何某种措辞让用户感到困惑。反馈循环收紧得更快，因为不需要跨越组织边界。
联邦制真正是什么样的
联邦制模型不是"每个团队各行其是"。那样做会产生中央团队本应修复的碎片化和治理缺口。有效的模式是一个轻量级的共享基础设施层，之上是自治的领域所有权。
保持集中化的内容：
- 模型服务基础设施（标准化的部署、版本管理、路由和负载管理）
- 评估框架和共享测试标准
- 安全工具和防护栏
- 计算资源分配和配额治理
