中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队，统一工具链，建立治理机制，让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见，在董事会演示中无懈可击。然而在实践中，它可靠地生产出一种失败模式，看起来恰恰就像它本要消除的碎片化。
中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了；一个 9 个月的安全审查把它埋葬了。
2025 年，企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。
周二早上收到了一张支持工单：一名客户收到了关于退款期限的、言之凿凿的错误回答。工程团队调取了追踪记录，发现模型识别错了意图。产品 PM 查看仪表板，发现上个迭代发布的“极速退款”入口触发了一个 Prompt 从未针对其进行过调优的意图。平台 PM 指着评估套件（eval suite）说，测试全是绿色的。两人在技术层面都是正确的。但客户得到的回答依然是错的。
这就是“两个 PM 问题”，大多数 AI 团队都存在这个问题，只是没有给它命名。产品 PM 负责面向用户的界面——意图、成功指标、支持升级路径。平台或 ML PM 负责 Prompt、模型选择、评估套件和成本上限。两者的路线图在季度规划层面是协调的，但在每周发布层面却在背道而驰，因为两个 PM 在不同的仪表板上针对不同的指标进行优化，且有着不同的变更控制流程。
这种有趣的失效模式并不是因为两个 PM 意见不合，而是因为他们都在各自的职责范围内正确地完成了发布，却共同导致了一个无人负责的退化（regression）。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
