为什么大多数AI产品都会失败：来自OpenAI、Google和Amazon 50+ AI部署的教训

嘉宾：Aishwaria Raanti & Kiti Bottom ｜ OpenAI AI产品负责人 / 早期AI研究员｜领域：AI产品与未来趋势

背景与引子

2025年，AI行业发生了微妙却深刻的变化。回望2024年，许多人对AI仍持怀疑态度，认为这不过是又一个加密货币式的泡沫。当时所谓的“AI产品”，大多不过是“在你的数据上套个Snapchat的壳”。然而一年后的今天，情况截然不同——越来越多的公司开始认真反思自己的用户体验和工作流程，意识到必须解构并重建现有流程，才能真正打造出成功的AI产品。

但问题在于，执行层面依然一团糟。这是一个仅有三年历史的领域，没有现成的 playbook，没有教科书式的指南。传统的软件开发生命周期与AI产品的生命周期截然不同，而旧的角色分工——产品经理、工程师、数据科学家之间的协作模式——正在被打破。新一代的协作方式要求所有人坐在同一个房间里，共同审视 agent traces（智能体执行轨迹），共同定义产品应该如何表现。

这正是为什么我们今天要深入这场对话。我的两位嘉宾不仅亲手构建过AI产品，还深入支持了超过50个跨公司的AI产品部署，覆盖Amazon、DataBricks、OpenAI、Google以及众多创业公司和大型企业。他们还共同开设了Maven上排名第一的AI课程，专门教授产品负责人如何构建成功的AI产品。

这场对话的目标很简单：帮助你和你的团队节省痛苦、减少折磨、避免在构建AI产品过程中浪费大量时间。

一、嘉宾是谁

Kiti Bottom 目前在 OpenAI 从事 codec 相关工作，在加入 OpenAI 之前，她在 Google 和 Kumo 构建 AI/ML 基础设施长达十年。她亲历了大型科技公司如何从零开始搭建AI能力，也见证了无数踩坑与突破。

Aishwaria Raanti（Ash） 是 Alexa 和 Microsoft 的早期 AI 研究员，发表了超过35篇研究论文。她曾在企业级AI咨询一线工作，帮助各行各业的公司进行AI转型与战略规划。

两人共同的独特之处在于：她们不只是理论家，更是实践者。她们见证了太多团队满怀热情冲进AI领域，却在执行中不断受挫。基于这些一手经验，她们提炼出了构建AI产品的核心方法论，而这正是她们要在这次对话中分享的内容。

二、核心观点 TOP10

构建AI产品与构建传统软件产品有本质区别——最大的不同在于非确定性：用户行为不可预测，LLM响应也不稳定。
每给AI系统增加一分自主权，你就同时失去一分控制——这被称为“代理与控制的权衡”，是AI产品设计中最容易被忽视的命题。
从小处着手、循序渐进是成功的关键——不要一上来就构建端到端完全自主的agent，先从高控制、低代理的最小可用版本开始。
AI产品开发的正确路径是“连续校准、连续开发”——建立反馈飞轮，持续迭代，让产品逐步走向成熟。
Leader必须亲自下场——AI时代，领导者需要重建自己的直觉，而不是依赖过去10-15年的经验。
Subject Matter Expert（领域专家）是AI产品成功的关键——他们理解理想行为是什么，能帮助识别系统的盲点。
Eval和生产监控缺一不可——Eval捕捉已知错误模式，生产监控发现你完全没想到的新问题。
“一键agent”纯属营销——企业数据和基础设施极其混乱，真正有价值的方案需要数月的打磨和迭代。
多模态体验在2026年将被大幅解锁——这将让AI系统更接近人类沟通的丰富性。
Pain is the new moat（痛苦是新的护城河）——真正区分赢家的，是愿意承受学习、试错、迭代之苦的持久力。

三、关键洞察

洞察一：AI产品失败的核心原因是非确定性，而非技术本身

传统软件是一个高度可预测的系统。以Booking.com为例，用户意图（预订酒店）可以通过一系列固定的按钮、表单被精准转化。但AI产品用自然语言界面彻底替换了这层确定性结构——用户可以用无限种方式表达同一意图，而LLM的响应也是概率性的、不稳定的。这意味着你同时面临三重不确定性：不知道用户会怎么输入，不知道模型会怎么输出，也不知道两者叠加后会生出什么行为。构建AI产品，本质上是在不确定性中设计确定性体验。

洞察二：“代理与控制的权衡”让很多团队在第一天就注定失败

团队往往痴迷于构建“完全自主”的agent，却忽视了一个基本事实：每一次将决策权移交给AI系统，你都在放弃一部分控制权。更要命的是，大多数团队在尚未建立对AI系统信任的情况下，就贸然将高风险任务交给agent处理。这就像让一个刚拿到驾照的新手第一天就开F1赛车——风险极高，而且一旦出事，用户信任被摧毁，品牌受损严重。正确的方式是从“低代理、高控制”的场景起步，逐步建立信任后再扩大AI的决策权限。

洞察三：Eval解决不了所有问题，生产监控才是发现未知错误的窗口

很多人陷入了非此即彼的误区：要么觉得Eval能解决一切问题，要么觉得只要盯着生产数据就够了。真相是两者都很重要，但解决的问题完全不同。Eval本质上是“已知问题清单”——你知道自己在意什么，你构建数据集来确保系统在这些问题上表现良好。但用户行为是活的，他们总会以你从未预料到的方式与系统交互。生产监控的价值在于捕捉这些“Emerging patterns”（新出现的模式），这些是Eval永远覆盖不到的领域。正确的做法是：两手都要抓，两手都要硬。

洞察四：多agent系统被严重误解

很多人认为，多agent就是“我有5个agent分别负责不同功能，把它们连接起来就天下无敌”。但现实是，当多个agent以peer-to-peer方式通信时，系统行为的复杂度会指数级上升。你需要把guardrails（防护栏）部署到每个agent节点，否则一个agent的错误会像涟漪一样扩散到整个系统。更可行的模式是“Supervisor-Agent Pattern”：一个主管agent负责任务分解和调度，具体执行由子agent完成，但所有输出都必须流回主管节点做质量把控。

洞察五：痛苦是新的护城河

在AI时代，信息获取前所未有的容易——你几乎可以在一夜之间学会任何技能。但真正的壁垒在于：有多少团队愿意承受反复试错、反复迭代的痛苦？真正的护城河不是“我第一个推出了某个功能”，而是“我们已经走过了所有该踩的坑，我们知道什么行什么不行，我们的产品已经过充分校准”。这种组织层面的knowledge和intuition，是花钱买不来、靠PPT讲不出的东西。

四、精彩金句

“在AI产品中，你不是在编写代码，而是在校准行为。”

解读：传统软件开发是写specification，AI产品开发更像是养孩子——你需要持续观察它的行为，持续纠正偏差，持续引导它走向正确方向。这要求完全不同的心态和工作方式。

“构建是廉价的，设计是昂贵的。你需要真正想清楚你要解决什么问题，而不是急着把最新的agent技术用上去。”

解读：2025年的今天，快速构建一个MVP已经非常容易。但真正区分好产品和坏产品的，是产品设计阶段对用户问题、workflow、边界的深度思考。

“如果有人说卖给你一个’一键agent’，那纯属营销。你需要的是一家愿意和你一起经历4-6个月阵痛期的合作伙伴。”

解读：企业数据环境极其混乱——数据 taxonomy 混乱、历史遗留问题堆积、workflow 未被文档化。没有任何agent能开箱即用地解决这些复杂问题。真正有价值的，是愿意陪你一起理解数据、迭代产品、建立飞轮的团队。

“Leaders have to get back to being hands-on. You must be comfortable with the fact that your intuitions might not be right and you probably are the dumbest person in the room.”

解读：过去十年积累的经验和直觉，在AI时代可能不适用甚至有害。优秀的leader需要重新成为一个学习者，愿意承认“我不知道”，愿意向一线的工程师和产品经理请教。

“Pain is the new moat.”

解读：能真正穿越周期的公司，不是那些第一个冲进赛道的，而是那些愿意承受反复试错之苦、不断校准产品、不断优化workflow的团队。

五、实战案例

客服agent的演进之路

让我们用一个真实的例子来说明“连续校准、连续开发”框架是如何落地的。

想象你是一家拥有大量客服工单的公司，像OpenAI在发布GPT-4o时那样面临着支持量的暴涨。第一反应可能是：“把历史帮助文档全扔给AI，让它自动回复所有问题。”——这几乎注定会失败。

V1：路由（Routing）

第一阶段，AI只做一件事：对工单进行分类和路由，判断它应该被发送到哪个部门处理。听起来很简单？但企业数据 taxonomy 的混乱程度远超想象。一个零售平台的分类体系可能有10层嵌套，同一层级下既有“男鞋”又有“男鞋-for-men”，新旧节点并存。人类客服知道哪些是死节点、哪些是活跃分类，但AI完全不知道。这种混乱只能通过实际部署才能暴露，而V1阶段的“人类复核”机制让错误不会伤及用户体验，同时让你积累了大量真实数据。

V2：辅助建议（Copilot）

在Routing稳定运行、数据问题被逐一修复之后，进入V2阶段：AI开始基于标准操作流程生成回复建议，人类客服可以采纳或修改。这阶段的关键收获是：你开始免费获得Error Analysis（错误分析）——通过记录人类客服采纳了什么、忽略了什么、修改了什么，你精确地知道AI的盲点在哪里。

V3：端到端自主处理（Full Automation）

只有在V2阶段人类几乎不需要修改AI建议时，才进入V3：AI直接面向用户生成回复，甚至自动处理退款、提交功能需求等操作。即便如此，这个过程也需要持续监控，持续校准。

这个演进路径的核心逻辑是：在每个阶段建立足够的置信度后，再向下一阶段跃迁。如果跳过中间阶段直接做V3，你将面对的是一个你完全不理解、用户行为无法预测、错误模式五花八门的系统，等待你的只有无休止的hotfix和灾难性的用户投诉。

六、行动建议

建议一：先识别高控制、低代理的场景作为切入点

为什么要做：AI产品在完全自主之前，需要先证明自己值得被信任。如果从高风险、高复杂度的场景起步，一旦出错，用户信任和品牌声誉都会被严重损害。

如何开始：列出你所在业务中最频繁、最标准化、容错率最高的5个任务场景。优先选择那些“即使AI错了，人类也能轻松纠正”的场景作为起点。例如：文档分类、工单路由、数据格式转换。

得到什么：你会获得一个低风险实验场，积累真实用户数据，理解AI的强项和弱点，而不会对用户体验造成实质伤害。

建议二：建立“人类复核”作为默认机制，逐步降低控制比例

为什么要做：每一步扩大AI自主权之前，都需要确保AI已经“Earned”这份信任。盲目跃进只会导致系统行为失控。

如何开始：为每个AI功能定义“Human-in-the-loop”检查点。记录AI的每一次输出和人类的每一次干预（采纳、修改、忽略）。用这些数据计算AI的准确率和改进速度，当准确率持续超过阈值（比如95%）且人类干预率持续下降时，再考虑扩大AI权限。

得到什么：你会构建一个清晰的校准仪表盘，精确知道什么时候可以“安全地”扩大AI的决策范围。

建议三：Leader每天至少留出1-2小时深度使用AI工具

为什么要做：AI时代，Leader的直觉需要被重新训练。如果不了解AI当前能做什么、不能做什么，就无法做出正确的资源分配和优先级决策。

如何开始：每天早上设定一个“无会议时段”，专门用来使用最新的大模型产品（如ChatGPT、Claude、DeepSeek），尝试用它们解决你实际工作中遇到的问题。记录下AI表现好的场景和表现差的场景，定期与团队讨论这些观察。

得到什么：你将重建对AI能力的直觉，能够在战略层面做出更准确的判断，也能更好地向团队解释为什么我们需要某种技术路线或为什么某个方案不可行。

建议四：建立包含“显性反馈”和“隐性反馈”的生产监控系统

为什么要做：Explicit feedback（如用户点击“thumbs down”）只能捕捉到很小一部分问题。很多时候用户不满但懒得反馈，他们只是简单地“重试”或者“离开”——这些行为本身就是最强的负面信号。

如何开始：在你的产品中添加关键埋点：用户是否重试了？用户是否在AI生成的回复后自己重新输入了新query？用户的会话时长是否异常缩短？这些隐性信号比显性评分更能反映真实的产品问题。

得到什么：你能持续获得新出现的错误模式（Emerging patterns），比竞争对手更早发现产品漏洞，比任何预定义的Eval套件都更全面。

建议五：每个季度至少安排一次“回到数据”深度复盘

为什么要做：大多数团队在完成初始开发后就停止了“理解用户”的工作。但用户行为会随时间演变，AI模型的更新也会改变系统行为，原先的假设可能已经失效。

如何开始：每个季度抽出1-2天，让整个产品技术团队一起做“Data Deep Dive”——不是看dashboard，而是实际抽样查看100-200条真实的用户对话和agent行为轨迹。让工程师、产品经理、领域专家共同参与，每个人从自己的视角发现问题。

得到什么：你将持续发现那些在dashboard上看不到的“角落问题”，保持对产品的深度理解，并据此调整下一阶段的产品路线图。

七、我的总结

构建AI产品，本质上是在不确定性中创造确定性价值。这场对话揭示了一个核心真相：大多数AI产品失败，不是因为技术不够强大，而是因为团队用错了方法——他们试图跳过循序渐进的过程，直接跳到“完美agent”的终点；他们忽视了非确定性带来的输入输出双重风险；他们在尚未建立信任的时候就贸然扩大AI的自主权。而成功的路径其实清晰可循：从小处着手，通过连续校准、连续开发的飞轮逐步扩大AI能力，同时持续积累用户反馈和领域知识，让产品在校准中走向成熟。AI只是工具，真正决定成败的，是你有多理解你的用户、你有多愿意承受迭代之苦、以及你有多大的耐心陪伴产品一起成长。Pain is the new moat——愿意走这条路的人，终将获得别人无法复制的壁垒。

📺 播客信息

发布时间：2026-01-11
时长：1小时26分钟23秒
播放量：43669 次观看
原版视频：『YouTube』