#395.为什么大多数 AI 产品会失败？来自 OpenAI 与谷歌专家的 50 个项目实战复盘

——基于 OpenAI 与谷歌专家对 50+ 个 AI 项目实战经验的系统性总结

本期播客由硅谷顶级产品播客 Lenny’s Podcast 主持人 Lenny 对话两位拥有丰富一线实战经验的 AI 产品专家——OpenAI Codex 团队负责人 Cathy Badam（曾任职于谷歌和 Kumo，专注构建 AI/ML 基础设施）以及支持过亚马逊、DataBricks、OpenAI、谷歌等 50 多个 AI 产品落地的 Aryan Rash Reganti（前 Alexa 与微软早期 AI 研究员，发表论文超 35 篇）。他们基于共同开发课程、撰写文章及深度参与企业级 AI 落地的经验，系统性剖析了当前 AI 产品高失败率的根本原因，并提出了一套可操作的“持续校准-持续开发”（Continuous Calibration & Development, CCD）框架。

核心洞见在于：AI 产品的开发逻辑与传统软件存在本质差异，主要体现在非确定性（non-determinism）与自主权-控制权权衡（autonomy-control tradeoff）两大维度。多数失败源于忽视这些特性，盲目追求全自动 Agent 或复杂技术方案，而忽略了问题本质、用户行为演化与信任建立的渐进过程。成功的关键不在于技术先进性，而在于构建一个以问题为导向、低风险启动、数据驱动迭代的“进化飞轮”，并通过领导力重塑、文化赋能与流程痴迷实现组织协同。正如嘉宾所言：“在今天，痛苦就是新的护城河”——真正的竞争优势来自于在试错中积累的实战经验与对业务上下文的深刻理解。

1.1 非确定性：输入、输出与中间过程的不可预测性

传统软件（如 Booking.com）基于预设的工作流和明确的用户意图（例如“在旧金山订两晚房”），通过结构化表单和按钮将意图转化为确定性动作，用户体验高度可预测。而 AI 产品则运行在一个非确定性的 API 环境中，其核心挑战在于：

• 输入端的高度灵活性：用户通过自然语言表达意图，方式成千上万，开发者无法穷尽所有可能的表述；
• 输出端的概率性与黑盒性：大语言模型（LLM）对 Prompt 措辞极其敏感，且其内部机制近乎黑盒，输出结果具有概率分布特征；
• 中间过程的不可观测性：开发者无法完全理解或控制从输入到输出的完整推理路径。

“你不知道用户会怎么用你的产品，也不知道 LM 会怎么回应。”

这种三重不确定性意味着开发者无法像传统软件那样进行精确的行为映射，而必须转向行为预判与针对性开发。例如，在客户支持场景中，用户提问“我的订单为什么还没到？”可能隐含物流查询、退款申请或投诉等多种意图，系统需在模糊中做出合理响应。

1.2 自主权与控制权的权衡：每次授权都是信任的让渡

当系统引入 Agent（智能体）实现自动化决策时，开发者实质上是在交出控制权。这一权衡被严重低估：

“你每次把决策权交给 AGENT 的系统，其实就是在交出自己的控制权。”

全自动 Agent 虽具吸引力，但若缺乏足够的可靠性验证，极易导致用户体验崩坏甚至法律风险（如加拿大航空因 AI 幻觉错误解读退款政策引发诉讼）。因此，正确的策略是渐进式放权：从高控制、低自主权的“副驾驶”模式起步（如 AI 仅提供建议供人工审核），待系统表现稳定、信任建立后，再逐步增加自主权（如自动回复、执行退款等操作）。

“你得确保这种能力是它随着时间慢慢积累信任才获得的。”

这一原则要求产品经理清晰区分不同阶段的系统角色：V1 版编程助手仅做行内代码补全；V2 可生成测试用例供人类审核；V3 才能自主提交 PR。跳过中间阶段直接追求 V3，往往因复杂度失控而失败。

2.1 领导力：放下身段，重塑直觉，深度参与

AI 落地必须自上而下推动。高管若仅凭过往直觉决策，极易误判 AI 能力边界。成功企业的领导者展现出三大特质：

• 主动学习：如 Rackspace CEO 每日 4-6 点专用于跟进 AI 动态，听播客、读资料、参与编码；
• 心态开放：接受“直觉可能不对”，甘当“房间里最笨的人”，向团队成员学习；
• 深度参与：CEO 每日与 ChatGPT 或云平台交互，将学习成果直接用于公司决策。

“你得接受你的直觉可能不对，甚至要习惯自己是房间里最笨的那个人。这样你才能向每个人学习。”

若领导层预期偏差或缺乏信任，仅靠工程师自下而上推动几乎注定失败。

2.2 文化：消除焦虑，建立赋能型协作

传统企业引入 AI 时常伴随“错失恐惧症”（FOMO）或“被取代焦虑”，导致领域专家拒绝配合。成功组织通过文化建设化解阻力：

• 明确 AI 定位：强调 AI 是“增强”而非“取代”，目标是“让效率翻十倍”；
• 激发主人翁意识：鼓励员工利用 AI 扩展能力边界，做更多“以前做不到的事”；
• 跨职能协同：PM、工程师、领域专家需共同拥有反馈回路，坐在同一房间盯 Agent 运行轨迹（Traces）。

“只有全公司心往一处想，让 AI 为人服务，大家才不会为了保住饭碗而设防。”

2.3 技术实践：痴迷流程，而非技术本身

成功团队对业务流程的理解达到痴迷程度，而非盲目追逐最新模型：

• 拆解流程：识别哪些环节适合 AI（如低风险预授权），哪些需人工介入（如高风险手术审批）；
• 混合架构：结合机器学习模块与确定性代码，而非依赖单一 Agent；
• 上下文工程：构建高质量数据管道与分类体系（如客服工单路由），为 AI 提供足够上下文。

“你得痴迷于流程本身，而不是痴迷于技术，这样才能选对工具。”

3.1 核心理念：从低风险启动，建立反馈闭环

CCD 框架借鉴软件工程 CI/CD 思想，但针对 AI 特性重构：

• 持续开发（Continuous Development）：启动前明确能力边界，准备评测数据集，达成 PM 与专家共识；
• 持续校准（Continuous Calibration）：上线后监控用户行为（显性如点赞，隐性如“重新生成”点击），分析未预料行为，修补漏洞并扩充评测集。

“新问题只有在投产后才会冒出来，所以这套框架能帮你建立一个低风险的环境，去理解用户行为，而不是等出了一堆错才手忙脚乱地去修。”

3.2 实施路径：代理阶梯（Agent Ladder）与版本演进

以客服系统为例，演进路径如下：

| 版本 | 功能 | 学习目标 | 风险控制 |

|------|------|----------|----------|

| V1 | 自动分流（路由） | 理顺分类体系，获取高质量路由数据 | 仅处理低风险、明确分类 |

| V2 | 副驾驶（草稿建议） | 记录人工修改行为，免费获得错误分析 | 人类保留最终决策权 |

| V3 | 端到端解决助手 | 验证草稿质量稳定性，扩展至退款/提需 | 逐步放开高风险操作权限 |

“比如客服场景，第一版只做自动分流……等分流稳定了，第二版再做副驾驶，让 AI 给人工客服提供建议。”

此过程同时构建了隐性日志系统，捕获评估指标无法覆盖的新错误模式。

3.3 评测与监控：互补而非对立

社区常陷入“评测 vs 监控”的二元争论，实则二者缺一不可：

• 评测（Evaluation）：将产品理解转化为数据集，明确 Agent “不能做什么”，用于上线前验证；
• 生产监控（Production Monitoring）：捕捉真实用户行为信号（如 GPT 中“重新生成”点击），发现未知失败模式。

“一旦发现失败案例，你就得研究它是怎么做的，然后针对这个错误模式建立新的评测数据集。比如我的 Agent 乱给用户退款，那我就得针对这个行为写评测。”

需警惕“语义扩散”——将榜单跑分、模型选型等同于产品评测，实则偏离核心。

4.1 当前主要误区

• 过度追求全自动 Agent：忽视调试复杂性与信任建立过程，导致系统崩溃（如端到端客服因补丁过多被迫下线）；
• 忽略可靠性优先级：74-75% 企业将可靠性视为最大障碍，故当前成功产品多聚焦“提效”而非“取代”；
• 低估 Prompt 注入风险：非确定性使系统易被指令劫持，全自动 Agent 放大安全威胁。

4.2 被低估的机会与技能

• 编程助手渗透率仍低：除头部公司外，多数企业尚未充分释放其生产力价值；
• 设计感与品味成为核心竞争力：开发成本趋近于零，差异化取决于对问题与用户体验的深刻理解；
• 毅力即护城河：

“坚持是非常值钱的……在今天，痛苦就是新的护城河。”

4.3 2026 年趋势预判

• 主动性 Agent 兴起：从被动响应转向主动观察工作流、预判需求（如“我帮你修了五个工单，补丁写好了”）；
• 多模态理解突破：结合图像、文本、世界模型，解锁手写文档、杂乱 PDF 等非结构化数据矿藏；
• 多智能体协作优化：成功模式为“主管 Agent + 子 Agent”编排，而非无约束点对点通信。

所有讨论最终回归产品本质：

“迷恋你的客户和问题，而不是 AI。AI 只是工具，百分之八十的 AI 工程师和产品经理其实时间都花在理解工作流和数据上了。”

成功不源于技术炫技，而在于对业务上下文的深耕、对用户行为的敬畏，以及在痛苦迭代中积累的实战智慧。正如嘉宾所言：“从小处着手会逼你思考：我到底要解决什么问题？我们管这叫问题优先。” 在 AI 时代，这句看似朴素的原则，恰是穿越 hype、避免失败的终极指南。