#模型时代# 50+次企业AI部署的惨痛教训：为什么你的AI产品总是失败？

Lenny's Podcast最新一期请来了两位在AI产品一线摸爬滚打的实战派：Kiriti Badam目前在OpenAI负责Codex，过去十年在Google和Kumo搭建AI/ML基础设施；Aishwarya Naresh Reganti曾是Alexa和Microsoft的早期AI研究员，发表过35篇以上研究论文。两人合作支持过50多个企业AI产品部署，涉及Amazon、Databricks、Google等公司，还联合开设了Maven平台上评分最高的AI产品课程。

这期播客最关键的观点是：AI产品的本质是行为校准。你无法预先知道系统会怎么表现，所以必须设计一个可以持续观察、持续修正的机制。同时，不能以牺牲用户信任为代价去校准。

实际操作层面：从高控制、低自主权开始，建立飞轮，逐步放权。这不是因为模型不够强，而是因为企业数据太乱、工作流太复杂、用户行为太难预测。

我印象最深刻的则是这个对护城河的看法：
Kiriti这句话很有意思。成功的公司不是因为先发优势或某个fancy功能，而是因为他们经历了理解问题、实现方案、搞清楚什么行得通的痛苦过程。这些痛苦转化成的组织知识，才是真正的护城河。

一、AI产品的两个根本性差异

Ash开门见山指出，AI系统和传统软件有很多相似之处，但有两件事从根本上改变了构建方式。

1、非确定性（Non-determinism）是双刃剑

传统软件有一套清晰的决策引擎。想想Booking.com：你输入目的地、日期、人数，系统通过一系列按钮、表单引导你完成预订。整个流程是确定的、可预测的。

AI产品完全不同。输入端，用户可以用无数种方式表达同一个意图；输出端，你在和一个概率性的API（也就是LLM）打交道。"你不知道用户会怎么和产品互动，也不知道LLM会怎么回应。输入、输出、处理过程，三个你都不太懂。"

这恰恰也是AI产品最美妙的地方——人们更习惯用自然语言交流，而不是点按钮。但问题也在这儿：你想用非确定性的技术实现确定性的结果。

2、自主权与控制权的取舍被严重忽视

"我很震惊，这么多人都不谈这个。"Ash说。每当你把决策能力交给AI系统，你就在放弃一部分控制权。你必须确保AI已经"赢得"了这种信任。

这里的关键词是赢得（earned）。不是一上来就让AI做所有决策，而是让它通过表现逐步获得更多自主权。

二、渐进式构建：从登山训练说起

Kiriti用了一个比喻："如果你的目标是爬Half Dome（优胜美地的半圆顶），你不会第一天就去爬，而是先做训练，逐步提升，最后才挑战终极目标。"

AI产品也是一样。不要第一天就部署一个拥有所有工具、所有上下文的全能智能体。

1、客户支持的三阶段演进

以客户支持为例，OpenAI自己在产品发布时也面临支持量激增的问题：
• V1（路由阶段）：AI只负责把工单分类到正确部门。就算分错了，人工可以纠正，不会破坏客户体验。同时，你能发现很多数据问题——企业的分类体系往往一团糟，比如"鞋"下面同时有"女鞋"和"For Women"两个死节点。
• V2（Co-pilot阶段）：AI根据SOP生成回复草稿，人工审核修改后发出。关键是你在记录人工的行为——哪些草稿被采纳了，哪些被改动了。你几乎是免费获得了error analysis。
• V3（端到端解决）：当你发现大部分草稿不需要修改时，才放开让AI直接回复。

编码助手也是同样的逻辑：V1只做内联补全和模板代码；V2生成测试或重构代码供人工审核；V3才自动提交PR。

2、不同的约束方式

除了按功能分阶段，你还可以按风险等级约束。Ash举了保险预授权的例子：MRI、血检这类低风险的AI可以自动处理，但侵入性手术的审批必须保留人工环节。

约束方式可以是：动作数量、话题领域、风险等级。关键是你要主动设计约束边界，别指望AI自己把握分寸。

3、为什么这样做有效

约74-75%的企业表示，可靠性（reliability）是他们最大的痛点。这也是为什么今天很多AI产品都是生产力工具——因为它们是低自主权场景。完全替代工作流的端到端智能体还远未成熟。

"今天的竞争不是谁先有智能体，而是谁建立了正确的飞轮，能够持续改进。"

三、成功AI产品的三角模型

每个技术问题首先是人的问题。Ash总结了三个维度：

1、领导者必须亲自下场

前Rackspace CEO Gajen的做法值得学习：每天早上4-6点固定学习AI，周末还有coding session。"你必须接受一个事实：你的直觉可能是错的，你可能是房间里最蠢的人。"

领导者不需要亲自写代码，但需要重建直觉。如果高层不理解AI能解决什么问题、不能解决什么问题，底层工程师再努力也推不动。

2、文化是赋能而非威胁

Subject matter expert（领域专家）对AI产品至关重要——你需要他们来判断AI的行为是否正确。但如果公司文化是"不学AI就被替代"，专家们会拒绝合作。

正确的态度是：AI帮你10x你的产出，而不是替代你。

3、技术上要深入理解工作流

"成功的团队对理解工作流有执念。"自动化任何流程时，通常是ML模型做一部分、确定性代码做一部分、人工做一部分。你必须知道每个环节该用什么工具，别什么地方都塞一个智能体。

四、Evals不是万能药

关于评估（Evals），社区吵得很凶：一边说评估解决一切，一边说生产监控才是王道。Kiriti认为这是假问题——两个你都需要。

1、Eval这个词已经被用滥了

数据标注公司说专家在写evals，PM说evals是新的PRD，工程师说evals是整个反馈循环。Martin Fowler在2000年代就说过"语义扩散"现象——一个术语被各种定义稀释后，就失去了原本的意义。

回到本质：你需要的是可执行的反馈循环（actionable feedback loop）。

2、预部署 vs 后部署
• 预部署评估：在上线前，你有一组数据集，确保AI在这些场景下表现正确。这是"你已知"的错误模式。
• 生产监控：用户的隐式信号（比如ChatGPT里的"重新生成"按钮被点击=用户不满意）和显式信号（点赞/点踩）。你需要这些来发现"你不知道"的错误模式。

3、OpenAI Codex的做法

Kiriti坦言，Codex采用的是平衡方法。代码智能体的特殊之处在于它天然是可定制的——用户会用在各种不同的集成和工具上，你不可能预先为所有场景写评估数据集。

"每次发布新模型，团队会一起测试不同的场景，每个人负责不同方向，把我们收集的'hard problems'扔给新模型，看进展如何。你可以说这是每个工程师的custom evals。"

社交媒体上的用户反馈也是重要信号，出现问题会快速修复。没有人能说"我有一套万能的evals，然后就不用想别的了"。

五、持续校准持续开发框架（CC/CD）

这个命名致敬了CI/CD（持续集成/持续部署）。核心理念是：AI产品的开发不是一次性的，而是持续的行为校准。

1、开发循环
• Scope capability & curate data：在动手之前，先定义期望的输入输出。这个练习非常有价值——经常会发现团队成员对产品应该如何表现没有共识。
• Set up application & design evaluation metrics：搭建应用，设计评估指标。
• Deploy：上线。

2、校准循环
• Analyze behavior & spot error patterns：分析实际行为，发现错误模式。
• Apply fixes & design new metrics：修复问题，设计新的评估指标。

关键是两点：低自主权版本在前，高自主权版本在后；不断从用户行为中学习，别假设你能预知一切。

3、什么时候进入下一阶段？

没有固定规则，但核心原则是最小化意外。如果你每一两天校准一次，发现没有新的数据分布模式，用户行为稳定，你获得的新信息量很低，那就可以考虑进入下一阶段。

校准不是一劳永逸的。模型更新（比如GPT-4o被弃用，要换成5）、用户行为演变（人们跟ChatGPT说话的方式两年前和现在完全不同），都会让你的校准失效。

Ash还分享了一个案例：他们给银行的承保人员做了一个AI工具，帮助审批贷款申请。前三四个月大家都很满意，效率提升明显。结果三个月后，用户开始问一些从未预料到的深度问题——比如把整份申请文件扔过来问"以前类似案例的承保员是怎么处理的"。用户觉得这只是功能的自然延伸，但背后的技术复杂度完全不同。这就是用户行为演变的典型例子。

六、被低估和被高估的趋势

被误解的：多智能体系统

Kiriti直言，很多人有个误解：把复杂问题拆成多个智能体，让它们点对点通信，就能解决一切。实际上，让智能体之间用某种"gossip protocol"（八卦协议）通信极难控制——你的guardrails要部署到每个智能体上，客户支持场景下你根本不知道哪个智能体在跟客户说话。

成功的多智能体系统通常是supervisor架构——有一个监督智能体协调子智能体。

被低估的：编码智能体

Twitter和Reddit上关于coding agent的讨论很热闹，但跟Bay Area之外的普通工程师聊，你会发现渗透率其实很低。2025-2026年会是编码智能体大规模落地的年份。

Ash则认为Evals被误解了。工具切换的FOMO被高估了，真正被低估的是深入思考要解决什么问题。"构建越来越便宜，设计越来越贵。"

七、给AI从业者的核心建议

1、痛苦是新的护城河（Pain is the new moat）

Kiriti这句话很有意思。成功的公司不是因为先发优势或某个fancy功能，而是因为他们经历了理解问题、实现方案、搞清楚什么行得通的痛苦过程。这些痛苦转化成的组织知识，才是真正的护城河。

2、问题优先，工具其次

80%的AI工程师和AI PM的时间花在理解工作流和用户数据上，而不是构建最酷的模型。"看你的数据"——这对从没做过AI的软件工程师是个巨大的revelation。

3、执行会越来越便宜，设计会越来越贵

一个新招的员工带着自己白手起家做的任务管理App来开会，直接说"我们用这个"。这种agency和ownership会越来越重要。你不能再躲在角落做不推动业务的忙活了。

4、多模态是2026的大方向

Ash认为多模态体验会是下一波重点。语言只是人类进化的最后一种表达形式，对话中的点头、表情、停顿都是信号。如果能更好地理解多模态输入，我们会更接近人类般的交流丰富度。

---

核心归纳

Q1: 为什么我的AI产品总是上线后一堆问题？

因为你可能跳过了"行为校准"阶段。传统软件的bug是确定的，修复一次就好；AI的问题是涌现的（emerging），你需要在低风险环境下先理解系统的实际行为。建议从"人工审核所有AI输出"开始，等稳定了再逐步放权。

Q2: 我该花多少精力在Evals上？

Evals重要但不是万能药。它只能捕捉你已知的错误模式。你同样需要生产监控来发现未知问题——关注用户的隐式信号，比如"重新生成"按钮的点击率、会话中途退出率等。两者结合才能形成完整的反馈循环。

Q3: 作为PM或工程师，我应该培养什么能力来应对AI时代？

构建越来越便宜，设计越来越贵。深入理解你要解决的问题，理解用户的工作流，比快速上手新工具更重要。另一个被低估的能力是愿意经历痛苦——亲自去理解、实现、搞清楚什么行得通，这些经验会成为你和你团队的护城河。