原始标题: Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google & Amazon

发布日期: 2026-01-11 | 来源频道: @LennysPodcast

📝 深度摘要

本期对话嘉宾为前OpenAI产品负责人Aishwarya Raanti与前Google AI产品负责人Khyati Bottom，她们在职业生涯中直接参与了超过50家企业的AI产品部署，涵盖OpenAI、Google、Amazon等科技巨头及传统行业客户。这场对话试图回答两个核心元问题：其一，为什么绝大多数AI产品走向失败，背后的根本原因是什么；其二，构建AI产品与开发传统软件的本质差异在哪里。嘉宾从AI作为非确定性系统的本质出发，揭示了渐进式自主权释放模型，强调从低风险用例逐步验证的重要性，为AI产品管理者和转型领导者提供了一套可操作的方法论。

核心干货概览 (Key Takeaways)

类别 核心干货点 战略意义 / 影响
思维模型 渐进式自主权释放模型 从高控制低自主权起步，逐步释放决策权，避免一次性全面自动化带来的风险与信任崩塌
关键指标 行为校准周期、用户信任度评分、自动化覆盖率 通过迭代评估与用户反馈循环，实现AI系统行为的可预测性与可控性
战略决策 从生产力用例切入而非端到端工作流替换 低自主权场景更容易建立信任并快速验证价值，再逐步扩展至高风险领域
组织能力 领导层亲自深入AI实践、重建技术直觉 自上而下推动AI转型，避免中层执行者的方向迷失与资源错配

对话背景与核心议题 (Context)

本期的对话嘉宾是 Aishwarya Raanti（曾在 OpenAI 负责产品部署，现创立 AI 咨询公司）与 Khyati Bottom（Google 前 AI 产品负责人）。她们在过去几年中直接参与或支持了超过 50 家企业的 AI 产品部署，涵盖 OpenAI、Google、Amazon、DataBricks 等科技巨头以及众多传统行业客户。

这场对话旨在解决三个核心元问题：第一，为什么绝大多数 AI 产品走向失败，背后的根本原因是什么？第二，构建 AI 产品与构建传统软件产品的本质差异在哪里，产品经理需要掌握哪些新思维？第三，成功部署 AI 产品的企业做对了什么，失败的团队又踩中了哪些陷阱？

深度逻辑拆解 (Deep Dive)

一、AI 产品失败的第一性原理：非确定性与自主权困境

嘉宾在对话开篇抛出了一个令多数人忽视但致命的认知盲区：构建 AI 产品本质上是在与非确定性系统打交道，而这一事实深刻改变了产品开发的全部逻辑。

传统软件产品遵循确定性逻辑。以 Booking.com 为例，用户预订旧金山酒店两晚的行为路径是高度可预测的——从搜索、筛选到最终下单，每一步都有清晰的按钮、表单和业务流程。产品的决策引擎已经被充分映射，产品经理能够精确预知用户在任何一个交互节点的行为。然而，AI 产品完全颠覆了这一范式。在输入侧，用户可以通过自然语言以无数种方式表达同一意图——“我想找个地方住”、“帮我订酒店”、“旧金山两晚”，AI 系统必须理解所有这些变体。在输出侧，大语言模型本身是概率性 API，同样的 prompt 可能产生不同的回复，且模型对 prompt 措辞高度敏感，本质上是黑箱。这意味着产品开发者面临一个前所未有的困境：你不知道用户会如何输入，你也不知道 AI 会如何输出，你在同时面对输入、输出和处理过程三个环节的不确定性。

嘉宾进一步指出，这种非确定性在智能体（Agent）系统中被进一步放大。她用一个令在场主持人感到震惊的观察来表达：业界极度热衷于构建完全自主的智能体系统，仿佛自动化程度越高越代表技术先进，却忽视了一个根本性的权衡——每当将决策能力交给智能体系统时，你实际上在让渡控制权。你需要确保智能体已经建立了足够的信任，能够可靠地做出正确决策之后，才能赋予它更大的自主权。这是一个需要通过渐进式验证才能建立的信任链条，而非一步到位的切换。

二、渐进式自主权释放：从爬楼梯到跑马拉松

基于上述两个核心差异，嘉宾提出了一个具有高度操作性的产品演进框架——从高控制、低自主权的最小可行版本开始，随着对系统行为的信心积累，逐步提升自主权并降低人类干预。

她们以客户支持场景为例，详细展示了这套方法论的落地过程。在 OpenAI 部署 ChatGPT 及 DALL-E 等产品时，公司经历了产品发布后支持工单量剧增的典型挑战。传统的错误做法是直接将所有帮助中心文档丢给 AI Agent，期望它能自动回答所有问题。正确的做法是将自主权释放拆解为多个递进阶段：第一阶段，AI 仅向人类客服提供建议答案，由客服决定是否采纳；第二阶段，AI 可以直接将答案呈现给用户，但仍然需要用户确认后才执行操作；第三阶段，AI 获得了执行权限，可以直接发放退款、创建功能请求工单等。每一次阶段跃迁都建立在对前一阶段系统表现的充分验证之上。

嘉宾进一步给出了三个不同场景的版本演进范例。编码助手场景：V1 版本仅提供内联代码补全和模板片段；V2 版本生成较大的代码块（如测试用例、重构建议），供人类审核；V3 版本可以直接应用修改并自动创建 Pull Request。营销助手场景：V1 版本起草邮件或社交媒体文案，由人类确认后发送；V2 版本构建多步骤营销活动，运行 AB 测试；V3 版本自动优化跨渠道营销活动。保险预授权场景：低风险的血液检查和核磁共振检查可以由 AI 自动批准，高风险的侵入性手术则必须由人类医生决策。

这一方法论的核心逻辑在于：AI 产品的行为校准几乎不可能在事前完全预测。用户会以你未曾想到的方式与系统交互，AI 也会以你未曾预料的方式响应。如果从第一天就给予系统完全的自主权，一旦出现错误，你将面临用户体验被破坏、用户信任被侵蚀的灾难性后果。相反，从低自主权起步，你可以积累足够的交互数据来理解系统的真实行为模式，同时不牺牲用户体验。嘉宾引用了 UC Berkeley 与 Databricks 联合发布的一项研究：受访企业中 74% 至 75% 的最大痛点是可靠性，这直接解释了为何当前大多数成功的 AI 产品都集中在生产力辅助领域——这些场景允许人类始终处于决策闭环中。

三、成功构建 AI 产品的三角模型：领导力、文化与技术

在与超过 50 家企业的深度合作中，嘉宾团队反复观察到一个决定成败的核心模式：成功的 AI 产品部署并非单点技术突破，而是组织能力三角的协同效应。

领导力维度是首要因素。嘉宾分享了她在 Rackspace 担任 CEO 的 Gajen 的案例：这位 CEO 每天早晨 4 点至 6 点专门留出时间用于 AI 信息摄入，包括收听播客、学习最新研究，而非将 AI 视为委托给下属的技术活。她强调，AI 产品与传统软件的根本差异意味着领导者必须重建自己的技术直觉。过去 10 到 15 年积累的产品经验和决策模型在 AI 时代可能不再适用，领导者需要亲自上手、亲身感知 AI 的能力边界，而非仅凭汇报做判断。更关键的是，领导者需要承认自己在 AI 领域的"无知"，愿意成为房间里最愿意学习的人。一个令嘉宾印象深刻的反面案例是：许多企业的工程师团队试图向领导者推销 AI 方案，但领导者要么对技术可能解决的问题范围缺乏认知，要么对将 AI 投入生产的难度抱有不切实际的幻想，最终导致方向错配。

文化维度决定了组织能否有效利用 AI。嘉宾观察到，许多企业在面对 AI 转型时弥漫着恐惧文化——“AI 会取代我们的工作"这种 FOMO（Fear of Missing Out）情绪主导了内部对话。讽刺的是，构建有效的 AI 产品极度依赖领域专家（Subject Matter Expert）的深度参与：你需要他们来定义什么是对的输出，什么是错的输出，什么是边缘案例。然而，当这些专家担心自己的岗位将被 AI 取代时，他们完全没有动力与产品团队合作。成功的企业 CEO 会主动构建"赋能型"文化——强调 AI 是放大人类能力的工具而非替代品，员工可以通过 AI 将自己的生产力提升 10 倍，而非担心被淘汰。

技术维度要求团队彻底理解工作流程并选择合适的工具组合。嘉宾指出一个常见的认知陷阱：企业往往痴迷于"最新最强"的 AI 模型，认为只要部署最领先的模型就能解决所有问题。现实情况是，企业数据和基础设施的高度复杂性远超预期。几乎每个大型企业都存在混乱的数据分类体系（taxonomy），不同系统间的数据定义不一致，遗留技术债务堆积如山。一个典型的例子是零售企业的商品分类体系：有的节点将"女鞋"和"男鞋"放在同一层级，有的节点则在"鞋"类目下同时存在"女鞋”、“男鞋”、“女式鞋”、“男式鞋"等多个交叉重叠的分类。当 AI Agent 需要在这种混乱体系中做决策时，它完全无法理解应该如何路由。一个声称可以"一键部署"即插即用的 AI Agent 解决方案，在嘉宾眼中纯粹是营销话术。她更倾向于选择那些承诺"帮助你建立持续学习管道、逐步构建改进飞轮"的合作伙伴，而非承诺"开箱即用立即产生显著回报"的供应商。她明确表示，即使拥有最完善的数据和基础设施层，要获得显著的投资回报也需要四到六个月的工作周期。

四、评估体系（Evals）：AI 产品质量保障的核心基础设施

对话后半段聚焦于 AI 产品的评估方法论，这是一个在业界引发两极化观点的议题：一部分人认为评估是解决 AI 产品可靠性问题的灵丹妙药，另一部分人则认为评估被过度神化，仅靠"感觉"即可驾驭 AI 产品。

嘉宾的立场处于两者之间的务实地带。她将 AI 产品的评估体系解构为两个核心阶段。第一阶段是部署前评估（Pre-deployment Evaluation），即在上线前建立基准：你需要定义系统的预期行为，建立测试数据集，并针对该数据集运行评估指标。第二阶段是部署后评估（Post-deployment Evaluation）与持续校准（Continuous Calibration）的循环。这个阶段的核心挑战在于：用户在真实环境中会以你从未预见的方式与系统交互，最初设计的评估数据集往往不够全面。当你发现新的行为模式时，你需要分析这些错误模式，应用修复方案，同时设计新的评估指标来捕捉这些新出现的问题。这是一个持续迭代的过程，而非一次性完成的工作。

嘉宾强调了一个关键洞察：AI 产品的开发迭代周期与评估指标体系紧密耦合。当你从高控制、低自主权的版本逐步演进到更高自主权的版本时，每一次版本升级都应该对应着新的评估维度和更严格的性能要求。这与第一部分提到的"渐进式自主权释放"形成了方法论上的闭环——你不仅在产品功能层面释放自主权，同时在评估体系层面同步升级监控能力。

关于评估的具体实践，嘉宾建议区分两类错误模式：一类是可以通过直接修复解决的"点状错误”，例如工具定义不当导致的调用失败，这类问题修复后即可迭代前进；另一类是需要重新设计评估框架的系统性偏差，例如用户交互模式发生了结构性变化，这类问题需要更深入的根因分析。她特别提到，在企业级场景中，评估体系的建设本身就是一种组织能力——它需要产品经理、工程师和领域专家的协同，需要对业务指标的深刻理解，还需要持续投入的资源保障。

五、实战避坑指南：来自 50+ 部署案例的教训

在对话的最后部分，嘉宾系统性地总结了她们观察到的最常见失败模式。

坑点一：跳跃式演进。许多团队试图直接从 V0 跨越到 V3——即期望从第一天就实现完全自动化。这种心态源于对 AI 能力的过度乐观预期，以及对"非确定性"本质的忽视。其结果往往是系统行为完全失控，用户信任崩塌，产品被迫回炉重造。

坑点二：技术优先而非问题优先。团队容易被最新的模型能力所吸引，在没有充分理解业务问题的前提下就着手"用 AI 解决某事"。正确的顺序应该是：首先深刻理解你要解决的工作流程，识别其中适合 AI 介入的环节（通常是重复性高、容错空间大的任务），而非试图用 AI 重构整个业务流程。

坑点三：低估数据基础设施的复杂性。许多团队假设企业数据是"干净"的，可以直接喂给 AI 系统使用。现实是几乎所有大型企业都存在数据孤岛、定义不一致、分类体系混乱等问题。在解决这些数据基础问题之前，任何 AI 系统的表现都会受到根本性制约。嘉宾建议在 AI 项目启动前先进行数据健康度评估，这往往需要占据整个项目 40% 至 60% 的时间。

坑点四：将 AI 视为可以"一劳永逸"解决方案。AI 产品需要持续的监控、调优和再训练。部署只是起点而非终点。成功的团队会将"构建学习飞轮"作为核心目标，而非追求"一步到位"的完美系统。

方法论与工具箱 (Tactical Toolbox)

干货建议/SOP

  1. 从高控制低自主权版本起步

    • 定义最小可行功能，仅让 AI 提供建议而非执行
    • 建立人类审核环节，确保每一步输出都经过确认
    • 收集至少两周的用户反馈数据后再评估是否进入下一阶段

  2. 建立行为校准循环

    • 部署前：定义评估指标基线，准备测试数据集
    • 部署后：每周审查错误模式，识别系统性与偶发性错误
    • 迭代升级：每次提升自主权前完成完整的行为验证

  3. 构建组织级 AI 能力三角

    • 领导层：每天至少投入 30 分钟亲自使用 AI 工具，建立技术直觉
    • 文化层面：明确 AI 是"赋能"而非"替代"的定位，让领域专家参与定义正确行为
    • 技术层面：在启动 AI 项目前完成数据基础设施健康度评估

推荐资源/工具

  • LLM 评估框架：基于规则的评价指标 + 自动化测试套件
  • Agent tracing 工具：用于分析智能体的决策路径与行为模式
  • RAG 系统评估：用于验证检索增强生成场景下的上下文相关性
  • UC Berkeley + Databricks 联合研究：关于企业 AI 部署可靠性挑战的实证研究

反直觉洞察与辩论 (Insights & Reflections)

反直觉点

  • “一键部署"的 AI Agent 几乎都是营销噱头。嘉宾明确指出，任何承诺"开箱即用"的 Agent 解决方案在企业级场景中都不具备现实可行性。真正有效的 AI 产品需要四到六个月的建设周期，包括数据清理、工作流理解和持续迭代。

  • AI 产品失败的首要原因不是技术问题，而是组织问题。领导层的认知深度、组织的学习文化、跨职能协作机制，这些"软性"因素往往比选择哪个模型更能决定 AI 产品的成败。

  • 从低自主权起步反而更快达到高自主权目标。表面上看，从 V1 到 V3 的渐进路径似乎"慢”，但实际上它避免了 V3 直接失败带来的回炉成本，是最快的到达终点的路径。

争议/冲突点

  • 关于"评估是否被神化"的辩论：业界一部分人认为评估可以解决 AI 产品的可靠性问题，嘉宾持务实态度——评估是必要条件但非充分条件，过度依赖评估会导致"测试集上的完美表现"与"真实用户环境中的灾难"之间的巨大落差。

  • 关于"AI 是否会取代人类工作"的恐慌：嘉宾明确反对这种非此即彼的二元思维。她强调，在构建 AI 产品的实践中，领域专家的参与度决定了产品的质量上限，而非被 AI 替代。成功的 AI 部署应该让人类做得更多、更高价值，而非无所事事。

金句 (Golden Quotes)

  • “AI 产品开发是在与非确定性系统打交道，你不知道用户会如何输入，你也不知道 AI 会如何输出。”

  • “每当你将决策能力交给智能体系统时，你实际上在让渡控制权。你需要确保智能体已经建立了足够的信任，才能够赋予它更大的自主权。”

  • “如果你从第一天就给予系统完全的自主权，一旦出现错误，你将面临用户体验被破坏、用户信任被侵蚀的灾难性后果。”

  • “领导者在 AI 时代需要承认自己是房间里最愿意学习的人，而非最懂的人。”

  • “构建 AI 产品的最大挑战不是选择哪个模型，而是组织是否具备理解工作流程、持续迭代和改进的学习能力。”

📺 视频原片

视频ID: z7T1pCxgvlA