为什么大多数 AI 产品会失败：来自 50+ 企业部署的经验教训

打破传统产品开发的两个根本差异

Aishwarya Ranti 曾在 Alexa 和 Microsoft 从事 AI 研究，发表了 35+ 篇研究论文。Kiriti Bhattam 在 Google 和 Kumo 构建 AI 基础设施十年后，现领导 OpenAI 的 Codex 项目。他们共同支持了 50+ 个 AI 部署项目，并在 Maven 教授排名第一的 AI 课程。他们的核心观点是：AI 产品需要完全不同的思维方式。

第一个差异是非确定性。 "You don't know how your user might behave with your product and you also don't know how the LLM might respond to that." 在传统软件中，你构建的是一个映射明确的决策引擎。Booking.com 有按钮和表单，能将用户意图可预测地转化为行动。而使用 AI 时，输入（自然语言可以用无数种方式表达同一意图）和输出（LLM 是概率性的黑箱）都是不可预测的。你面对的是一个你无法完全理解的输入、输出和过程。

第二个差异是自主性与控制权的权衡。 "Every time you hand over decision-making capabilities to agentic systems, you're kind of relinquishing some amount of control on your end." Ash 感到惊讶的是，很少有人讨论这个问题。AI 社区痴迷于构建自主智能体，但自主性意味着失去控制。在赋予 AI 智能体更多自主权之前，你需要通过可靠性验证来确认它已经赢得了信任。

74% 的可靠性问题是真实存在的。 UC Berkeley 的一篇论文发现，74-75% 的企业将可靠性列为最大问题。这就是为什么他们不愿意部署面向客户的产品——他们无法信任这个系统。这解释了为什么今天大多数企业 AI 都专注于生产力工具，而非端到端的工作流替代。

为什么 CCCD 框架能防止灾难性 AI 故障

两位嘉宾在痛苦的经历后开发了持续校准、持续开发（Continuous Calibration, Continuous Development）框架。他们曾构建了一个端到端的客服智能体，但需要如此多的热修复，最终不得不关闭它。Air Canada 的聊天机器人编造了一个不存在的退款政策，而他们在法律上不得不兑现。这些灾难是可以预防的。

从高控制、低自主性开始。 "It's not about being the first company to have an agent among your competitors. It's about have you built the right flywheels in place so that you can improve over time." 对于客服智能体：V1 只是将工单路由到各部门（人工仍然做决策）。V2 建议草稿回复供人工编辑，并记录他们做了哪些修改。V3 只有在 V1 和 V2 证明可靠后才处理端到端的解决方案。

对于编程助手，同样的模式适用。 V1：建议行内补全和代码片段。V2：生成更大的代码块如测试或重构供人工审查。V3：自主应用更改并创建 PR。对于营销：V1 起草文案，V2 在批准后构建和运行活动，V3 跨渠道自动启动和优化。

客服进阶过程教会了我们一切。 即使是路由——看起来很简单——在企业中也可能极其复杂。分类体系混乱，有重复的类别和 2019 年遗留的死节点。人工客服凭经验了解这些怪癖；AI 不了解。从路由开始，你可以在数据问题破坏更雄心勃勃的自动化之前修复它们。飞轮效应意味着每个版本都为下一个版本生成训练数据。

是什么让公司在 AI 产品上取得成功

两位嘉宾看到了一个"成功三角"，包含三个维度：优秀的领导者、良好的文化和技术进步。三者缺一不可。

领导者必须重建他们的直觉。 "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." Ash 合作的一位 CEO 每天早上 4-6 点都会留出时间"跟进 AI"——没有会议，只是从可信来源学习。然后他会带着问题与 AI 专家探讨。那些花了 10-15 年建立直觉的领导者现在需要重新学习。

赋能文化胜过 FOMO 恐惧。 领域专家至关重要——他们理解 AI 实际应该做什么。但在许多公司，他们拒绝帮忙，因为他们认为自己的工作正在被取代。领导者必须将 AI 定位为实现 10 倍生产力的增强工具，而非替代品。让整个组织协同工作，使 AI 变得有用。

技术上要专注于工作流，而非工具。 成功的团队在选择技术之前深入理解他们的工作流。"80% of so-called AI engineers, AI PMs spend their time actually understanding their workflows very well." 智能体可能只处理工作流的一部分。机器学习可能处理另一部分。确定性代码处理其余部分。没有工作流理解的工具执念会导致失败。

为什么评估被误解了以及该怎么做

"eval"（评估）的争论已经变成了语义扩散——每个人对这个术语的理解都不同。数据标注公司称专家标注为"评估"。PM 写验收标准也叫"评估"。模型基准比较被称为"评估"。一个客户告诉 Ash "我们做评估"，意思是他们查看了 LM Arena 排名。

单独的评估或生产监控都不够。 评估是你编码在测试数据集中的可信产品知识——你的智能体绝对不应该出错的事情。生产监控捕获隐式信号：用户重新生成答案（表示不满意）、点踩、或完全关闭功能。评估捕获已知的失败模式；生产监控捕获你无法预测的新兴模式。

流程是：部署、监控、分析、迭代。 你无法预先预测每种失败模式。生产监控会提醒你值得检查的跟踪记录。错误分析揭示模式。只有这时你才决定：这是一次性修复，还是需要新评估标准的系统性问题？过早构建太多评估会带来维护负担，却无法捕获真正的问题。

构建真正有效的 AI 产品的 5 个要点

• 问题优先，始终如此 - 从小处着手迫使你定义实际问题；解决方案复杂性是一个滑坡
• 痛苦是新的护城河 - 成功的公司经历了学习什么有效的痛苦；目前还没有剧本或教科书
• 一键智能体是营销噱头 - 任何推销即时自主部署的人都在误导你；企业数据混乱，需要校准
• 多智能体被误解了 - 在没有人工协调的情况下将责任分散到对等智能体之间极难控制
• 编程智能体仍被低估 - 尽管 Twitter/Reddit 上讨论很多，但湾区之外的渗透率仍然很低；巨大的价值创造在前方

这对部署 AI 智能体的组织意味着什么

核心洞察：AI 产品开发不是简单地将 AI 替换到传统软件开发中。非确定性和自主性-控制权权衡意味着你无法预测行为、无法完全控制结果，必须逐步赢得信任。CCCD 框架——从高控制开始，随着可靠性得到证明逐渐增加自主性——可以防止导致停机和侵蚀客户信任的灾难性故障。在 AI 上取胜的公司不是动作最快的；而是那些构建能随时间复合改进的飞轮的公司。