Aishwarya Naresh Reganti, Kiriti Badam: 为什么大多数 AI 产品会失败：OpenAI、Google 和 Amazon 的 50 多次 AI 部署经验
Why most AI products fail: Lessons from 50+ AI deployments at OpenAI, Google, and Amazon
Guests: Aishwarya Naresh Reganti, Kiriti Badam
Full transcript · Read the full conversation in order, with its original context.
Contents1 chapter
§01对话正文§01对话正文
我们一起写过一篇客座文章。他们提出了一个非常关键的洞察：做 AI 产品和做非 AI 产品是完全不同的两回事。
大多数人倾向于忽略非确定性。你不知道用户会怎么使用你的产品，也不知道 LLM 会怎么回应。第二个差异是自主性与控制权之间的取舍。每当你把决策能力交给智能体系统，你其实就在自己这一端放弃了一部分控制权。
这会显著改变你构建产品的方式。
所以我们建议一步一步来。从小处开始时，它会逼着你去想：我要解决的问题到底是什么。在 AI 的这一堆进展里，一条很容易滑进去的歧路，就是一直琢磨解决方案有多复杂，却忘了你真正想解决的问题。
重点不是成为竞争对手里第一个拥有 agent 的公司，而是你有没有搭起正确的飞轮，让你能随着时间不断改进。
在那些成功构建 AI 产品的公司里，你看到的是什么样的工作方式？
我以前和现在这家 Rackspace 的 CEO 共事过。他每天早上都有一块固定日程，上面写着「跟进 AI，凌晨 4 点到 6 点」。领导者必须重新回到亲自动手的状态。你必须接受一个事实：你的直觉可能是错的。你很可能就是屋子里最笨的那个人，而你要向所有人学习。
你觉得 AI 的下一年会是什么样子？
坚持极其有价值。现在在任何新领域里做事的成功公司，都在经历学习、落地、搞清楚什么有效什么无效的痛苦。痛苦就是新的护城河。
今天我的嘉宾是 Aishwarya Reganti 和 Kiriti Badam。Kiriti 在 OpenAI 做 Kodex，过去十年在 Google 和 Kumo 构建 AI 和 ML 基础设施。Ash 是 Alexa 和 Microsoft 早期的 AI 研究员，发表过 35 篇以上研究论文。他们一起领导并支持过 50 多个 AI 产品落地，覆盖 Amazon、Databricks、OpenAI、Google 这样的公司，也有初创公司和大企业。他们还在 Maven 上教那门排名第一的 AI 课程，把他们在构建成功 AI 产品上学到的所有关键经验教给产品负责人。这期节目的目标，是帮你和你的团队省下大量在构建 AI 产品过程中会碰到的痛苦、折磨和浪费掉的时间。无论你已经在自己产品上挣扎，还是想避开这种挣扎，这期都适合你。如果你喜欢这档播客，别忘了订阅，并在你常用的播客 App 或 YouTube 上关注。（00:02:22）：这会帮上大忙。另外，如果你成为我 newsletter 的年度订阅用户，可以免费获得一整年一堆很棒的产品，包括 Lovable、Replit、Bold、Gamma、NA、Linear Dev 和 Posttalk、Superhuman、Descript、Whisper Flow、Perplexity、Warp、Granola、Magic [听不清 00:02:38] Mobbin，以及 Stripe Atlas 的一年免费。去 lennysnewsletter.com 点 product pass。就说这些，在赞助商短暂发言之后，我把 Aishwarya Reganti 和 Kiriti Badam 请上来。（00:02:49）：本期节目由 Merge 赞助。产品负责人讨厌做集成。它们又乱、建得又慢，是 roadmap 上的巨大消耗，而且绝对不是你当初做产品的原因。算你走运，Merge 痴迷于集成。通过一个 API，B2B SaaS 公司把 Merge 嵌进自己的产品，几周而不是几个季度就能上线 220 多个面向客户的集成。（00:03:14）：可以把 Merge 想成 Plaid，但它是给所有 B2B SaaS 用的。Mistral AI、Ramp、Drata 这样的公司用 Merge 把客户的会计、HR、工单、CRM 和文件存储系统连起来，支撑从自动 onboarding 到 AI-ready 数据管道的各种场景。更好的是，Merge 现在支持把 connector 安全地部署给 AI agent，这是一个新产品，让你可以用真实的客户数据安全地驱动 AI 工作流。如果你的产品需要从几十个系统里拿客户数据，Merge 是最快、最安全的方式。到 merge.dev/lenny 预约并参加会议，他们会送你一张 50 美元的 Amazon 礼品卡。就是 merge.dev/lenny。本期节目由 Strella 赞助，这是一个为 AI 时代打造的用户研究平台。关于用户研究的真相是：它从未如此重要，也从未如此痛苦。团队想知道客户为什么这么做，但招募用户、做访谈、分析洞察要花好几周。（00:04:14）：等结果出来，可以行动的时刻已经过去了。Strella 改变了这一点。它是第一个用 AI 自动执行并分析深度访谈的平台，把快速、持续的用户研究带给每个团队。Strella 的 AI 主持人会问出真正的追问，在回答含糊时挖得更深，并在几百场对话里归纳出模式，全部在几小时内完成，而不是几周。Amazon、Duolingo 这类公司的产品、设计和研究团队已经在用 Strella 做 Figma 原型测试、概念验证和客户旅程研究，一夜之间拿到洞察，而不是等下一个 sprint。如果你的团队想以你发布产品的速度去理解客户，试试 Strella。在 strella.io/lenny 跑你的下一项研究。是 S-T-R-E-L-L-A.io/lenny。Ash 和 Kiriti，非常感谢你们来，欢迎来到播客。
谢谢你，Lenny。
谢谢你邀请我们。非常期待。
我先为今天这场对话搭个台子。你们两位自己做过不少 AI 产品，也和很多公司深聊过——有的把 AI 产品做成了，有的在 AI 产品上挣扎，有的在做 AI agent。你们还在教一门如何成功构建 AI 产品的课，某种程度上你们的使命就是减少你们不断看到的、人们在构建 AI 产品时经历的那些痛苦、折磨和失败。所以，先给我们要展开的对话打个底：在那些想做 AI 产品的公司内部，你们在一线看到的是什么？什么进展顺利？什么不顺利？
我觉得 2025 年和 2024 年差别很大。第一，怀疑明显减少了。去年有一大堆领导者大概觉得这不过是又一轮 crypto 浪潮，对上手很怀疑。去年我看到的很多用例，更像是往你的数据上糊一个聊天框，然后管这个叫 AI 产品。而今年，一大批公司是真的在重新思考自己的用户体验、工作流这些东西，真的明白了：要做出成功的 AI 产品，你得拆解并重建自己的流程。这是好的一面。不好的一面是，执行仍然参差不齐。想想看，这是个只有三年的领域，没有 playbook，没有教科书。所以你只能边做边摸。而且 AI 的生命周期，从部署前到部署后，都和传统软件生命周期很不一样。（00:06:57）：所以很多旧的约定，以及传统角色之间的交接——比如 PM、工程师、数据的人——现在都被打破了，大家真的在适应这种新的协作方式，某种程度上是在共同拥有同一个反馈回路。因为以前我觉得 PM、工程师这些人各自优化各自的反馈回路。而现在你可能得坐在同一个房间里，一起看 agent 的 trace，一起决定产品该怎么表现。这是一种更紧密的协作。公司还在摸索这件事。这大概就是我今年在咨询实践里看到的。
那我顺着这条线往下问。我们几个月前一起写过一篇客座文章。做完那篇之后，最让我印象深、一直留在我脑子里的，就是这个关键洞察：做 AI 产品和做非 AI 产品很不一样。而你们特别想讲清楚的，是有两个非常大的差异。说说这两个差异吧。
对。再强调一下，我想确保我们把正确的点讲透。构建 AI 系统和构建软件系统也有大量相似之处，但确实有一些东西会从根本上改变你做软件系统还是做 AI 系统的方式。其中之一，也是最容易被大多数人忽略的，就是非确定性。相比传统软件，你基本上是在跟一个非确定性的 API 打交道。这是什么意思、为什么它会影响我们？在传统软件里，你基本上有一个映射得很清楚的决策引擎或工作流。想想 Booking.com 这类产品。你的意图是在旧金山订两晚房，等等。产品被设计成能把你的意图转换成某个具体动作，你点过一堆按钮、选项、表单之类的东西，最后实现了你的意图。（00:08:59）：但在 AI 产品里，这一层已经被一个非常流动的界面完全取代了，这个界面主要是自然语言，也就是说用户可以用一大堆不同的方式说出或表达自己的意图。这会改变很多东西，因为现在你不知道用户会以什么方式出现。这是输入端。输出端也一样：你在跟一个非确定性的、概率性的 API 打交道，也就是你的 LLM。而 LLM 对 prompt 的措辞相当敏感，而且它们基本上就是黑盒。所以你甚至不知道输出的表面会长成什么样。所以你不知道用户会怎么使用你的产品，也不知道 LLM 会怎么回应。也就是说，你现在面对输入、输出和过程这三样东西，而你三样都理解得不够清楚。你是在试图预判行为，并为此而构建。（00:09:53）：到了智能体系统，这就更难了。这就是我们要说的第二个差异：自主性与控制权的取舍。我们的意思是——我有点惊讶这么多人都不谈这个。大家极度执着于构建自主系统，构建能替你干活的 agent。但每当你把决策能力或自主权交给智能体系统，你其实就在自己这一端放弃了一部分控制权。而当你这么做时，你需要确保你的 agent 已经赢得了你的信任，或者它足够可靠，你可以让它做决策。这就是我们说的自主性与控制权的取舍：如果你给你的 AI agent 或 AI 系统——不管是什么——更多自主性，也就是做决策的能力，你同时也失去了一些控制权，而你需要确保这个 agent 或 AI 系统是靠实力赢得这种能力，或者说随着时间建立起了信任。
我简单复述一下你讲的。本质上，人们做产品、做软件产品已经做了很久。现在我们处在一个这样的世界：你构建的软件，第一，是非确定性的，它可能做出不一样的事。就像你说的，你上 booking.com 订酒店，每次的体验是一样的。你会看到不同的酒店，但体验是可预测的。有了 AI，你没法预测它每次都会是同一件事、就是你计划中的那件事。第二，就是自主性和控制权之间的取舍：AI 替你做多少，人还要在多大程度上掌舵？我听到的关键点是，这会显著改变你构建产品的方式。接下来我们会聊，这会如何影响产品开发生命周期。（00:11:35）：在进入那部分之前，你还有什么想补充的吗？
对，这绝对是关键点之一：你开始动手构建的时候，脑子里必须有这种区分。举个例子，如果你的目标是徒步 Yosemite 的 Half Dome，你不会第一天就天天去爬，而是先在小的路段上训练自己，慢慢提升，然后才去冲终点。我觉得这跟做 AI 产品极其相似：你不会第一天就上那种拥有公司里所有工具、所有上下文的 agent，还指望它能跑通，甚至不会一上来就在那个层级上折腾。你需要刻意从影响最小、人的控制最多的场景开始，这样你才能牢牢掌握当前的能力边界，知道我能拿它做什么，然后再慢慢往自主性更多、控制更少的方向走。（00:12:29）：这会给你那种信心：好，我知道我面对的是这个具体问题，AI 能解决到这一步。然后我再往下想，我需要带进来什么上下文，需要加什么工具来改善体验。所以我觉得这既是好事也是坏事：好的一面是，你不必一上来就看到外面世界那套复杂的、花哨的 AI agent 阵容，然后觉得自己做不到。每个人都是从极简的结构起步，然后演化。坏的一面是，当你想把这种一键式 agent 做进公司时，你不必被这种复杂性压垮，你可以慢慢升级。（00:13:16）：这极其重要。而且我们看到这是一个一遍又一遍重复出现的模式。
好，那我们就顺着这个往下走，因为这是你建议人们怎么构建 AI 东西——AI 产品、AI agent、各种 AI——时一个非常重要的组成部分。给我们举个例子，说说你讲的这件事：从自主性低、控制权高开始慢慢起步，然后一级一级往上走。
好。举个例子，AI agent 一个非常重要、也非常普遍的用法是客服。想象你是一家公司，有很多客服工单——甚至可以想想 OpenAI 自己，我们在发布产品时完全是一回事，发布 Image 或 GPT-5 这类成功产品时，支持请求量会暴涨。你收到的问题类型不一样，客户带来的问题也不一样。所以这不是把你手上所有帮助中心文章一股脑丢给 AI agent 就完事。你得先搞清楚自己能建什么。最初的第一步大概是这样的：你还有你的支持人员，人类客服，但系统会给出建议——AI 认为正确的做法是这个。（00:14:33）：然后你从人那里拿到反馈回路：这个建议在这个具体场景下对我有用，那个建议不行。然后你可以回头去理解，好，缺点在这里，盲区在这里，那我怎么修？一旦你拿到这些，你就可以提高自主性：好，我不需要再向人建议了，我可以直接把答案给客户看。然后你可以再加复杂度：我之前只是基于帮助中心文章回答问题，现在我来加点新功能，我可以给客户退款了，我可以向工程团队提功能需求了，诸如此类。所以如果你第一天就把这些全上，复杂度会极难控制。（00:15:19）：所以我们建议一步一步建，然后再往上加。
太好了。你其实有一张可视化图，我们到时候会分享出来，展示这个过程长什么样。我先把你的描述复述一遍：从高控制、低自主性开始，你举的例子是客服只是给建议，什么都做不了，用户说了算。然后当它变得有用、你有信心它做的是对的那类活，你就给它多一点自主性，同时把用户手里的控制收回来一点。再往后如果这一步也走顺了，你就给它更多自主性，用户需要的控制就更少。太好了。
我觉得更高一层的想法是：对 AI 系统来说，核心全是行为校准。你几乎不可能事先预测你的系统会怎么表现。那怎么办？你要确保不毁掉客户体验或终端用户体验——这一块保持原样，但逐步减少人手里的控制量。而且这件事没有唯一正确的做法。你可以自己决定怎么约束这种自主性。换个例子说明怎么约束自主性：预授权类场景。保险预授权是非常适合 AI 的用例，因为临床医生花大量时间在血液检查、MRI 这类东西的预授权上。其中有些是更容易摘的果子，比如 MRI 和血液检查，因为你一旦知道病人的信息，批准起来更容易，AI 可以做；而像侵入性手术之类风险更高，你不会想让它自主去做。（00:17:11）：所以你可以判断哪些用例该走人在环的那一层，哪些用例 AI 可以顺理成章地处理。而整个过程中，你还要记录人在做什么，因为你想搭一个飞轮，用它来改进系统。所以你实质上既没有改变用户体验、没有侵蚀信任，同时又记录了人本来会怎么做，从而能持续改进系统。
那我再给你几个你推荐的这类渐进路径的例子。我在这里花这么多时间，是因为这是你建议里非常关键的一部分，能帮人做出更成功的 AI 产品：从高控制、低自主性慢慢起步，等你建立起「它做的是对的那类活」的信心之后，再逐步往上加。你文章里还分享了几个例子，我直接念一下。假设你在做一个编码助手，V1 只是给行内补全建议和样板代码片段；V2 生成更大的块，比如测试或重构，交给人审阅；V3 就是直接应用改动、自主开 PR。还有一个例子是营销助手，V1 是起草邮件或社交文案，就是「我会这么做」。（00:18:26）：V2 是搭一个多步骤的 campaign，并把 campaign 跑起来。V3 就是直接发布、做 A/B 测试、跨渠道自动优化 campaign。太好了。对，我再总结一下我们现在的进度，把到目前为止给到的建议讲清楚。第一，要理解 AI 产品是不一样的，它们是非确定性的。你指出过、而我刚才忘了复述这一点：输入和输出两端都是。用户体验是非确定性的，人们会看到不同的东西、不同的输出、不同的对话，如果它在帮你设计 UI，可能 UI 也不同。输出显然也是非确定性的。所以这是个问题、是个挑战。然后——
我是说，如果你换个角度看，这也正是 AI 最美的地方：我们所有人都更愿意说话，而不是跟着一堆按钮走。所以用 AI 产品的门槛低得多，因为你可以像跟人打交道一样自然。但这也正是问题所在：我们沟通的方式有无数种，而你要确保意图被正确传达、正确的动作被执行，因为你的大多数系统是确定性的，你想要一个确定的结果，却用的是非确定性的技术——麻烦就麻烦在这里。
太好了。好，我很喜欢这个乐观版本的「为什么这是好事」。另一块就是设计东西时自主性与控制权之间的这个取舍。我猜你看到的是，人们会想直接跳到理想状态，比如一上来就做 V3，然后就在两方面都出问题：做那个大概难得多，而且它就是跑不通。然后他们就说，「行吧，这就是失败了。我们到底在干什么？」
正是。我觉得在走到 V3 之前，有一堆东西你必须先建立起信心。而且很容易被压垮：我的 AI agent 在这一百种不同的地方做错了，你根本不会真的一条条列出来修。就算你学会了怎么处理评估实践之类的东西，如果你起点选错了，你后面纠正起来会非常吃力。而当你从小处开始、从一个人控很高、自主性很低的极简版本开始时，它也会逼你去想：我要解决的问题是什么。我们用了一个词叫「问题优先」。对我来说这本来很显而易见，我确实得想问题，但它跟人的共鸣程度惊人：在 AI 这一波进展里，一条很容易滑进去的歧路，就是一直琢磨解决方案有多复杂，却忘了你真正想解决的问题。（00:21:10）：所以当你从更小规模的自主性开始时，你会真正去想：我要解决的问题是什么？我怎么把它拆成以后可以逐级搭建的自主性层级？这极其有用，而我们跟每个聊过的人都在反复讲这一点。
而且限制自主性还有很多其他好处，因为这东西替你做太多也有风险，会搞坏你的——我不知道——你的数据库，把一堆你根本没预期的邮件发出去。这是这么做的理由之一，而且还有很多。
对。我最近读了 UC Berkeley 一群人写的一篇论文，基本就是 Matei Zaharia 和 Databricks 的人，里面说他们访谈过的企业里大约 74% 到 75% 最大的问题是可靠性。这也是为什么他们不放心把产品部署给终端用户，或者做面向客户的产品——因为他们就是不确定，或者不放心这么做、不放心让用户暴露在一堆这类风险里。这也是为什么他们认为今天很多 AI 产品都跟生产力有关，因为相比端到端、会替代工作流的 agent，它的自主性低得多。对，我本来也很喜欢他们的工作，但我觉得这跟我们至少在我的创业公司看到的情况非常一致。
好，很有意思。还有一期节目会在这期之前播出，我们深入聊了另一个问题，也就是这能避开的问题之一：prompt injection、越狱，以及这对 AI 产品来说风险有多大——它本质上可能是一个尚未解决、甚至无法解决的问题。我不打算往那条路上走，但那是我们做过的一场挺吓人的对话，会在这期之前上线。
我觉得等系统进入主流，那会是个巨大的问题。我们现在都忙着做 AI 产品，还没顾上担心安全，但它会变成非常大的问题，尤其是又碰上这种非确定性的 API。你有点被困住了，因为你的 prompt 里可以注入一大堆指令，然后就真的会很糟。
好，我们在这儿稍微花点时间，因为这对我真的很有意思，而且没人聊这些——就是我们那场对话说的：让 AI 去做它不该做的事相当容易。大家上了一堆护栏系统，结果这些护栏其实并不好用，你总能绕过去。而且就像你说的，当 agent 变得更自主、变成机器人，你能让 AI 做出不该做的事，这挺吓人的。
我觉得这绝对是个问题，但我感觉在目前客户采用 AI 的光谱上，公司能真正从 AI 里获益、或者说改进流程、精简现有流程的程度，还处在非常早期的阶段。2025 年对 AI agent 和试图采用 AI 的客户来说是极其忙碌的一年，但我觉得渗透率还远没到你能真正从中获益的程度。所以只要在合适的位置设好人在环的节点，我觉得我们其实可以避开一堆这类问题，把更多精力放在精简流程上。我比较偏乐观的一边：你得先去尝试、去采用，而不是只盯着可能会出什么错的负面方面。（00:24:47）：所以我强烈感觉，公司一旦开始采用，他们肯定……我们聊过的公司里，在 OpenAI 从来没有出现过「AI 在这个场景里帮不了我」这种情况。从来都是「有这么一组事情它可以帮我优化，那让我看看怎么把它用起来」。
太好了。我一向喜欢乐观的视角。我很期待你去听那期节目、看看你怎么想，因为那真的很有意思。而且就像你说的，要关注的东西很多，那只是众多需要担心和思考的事情之一。好，我们回到正轨。我们已经分享了一堆实用技巧和重要建议。我想问，在那些做得好的公司、那些成功构建 AI 产品的团队里，你还看到哪些模式和做事方式？另外，人们最常掉进的坑是什么？或许我们可以先从这点开始：公司还有哪些做法能把 AI 产品做好？
我几乎把它想成一个成功三角，三个维度，而且从来都不只是技术问题。每一个技术问题，首先都是人的问题。就我们合作过的公司而言，就是这三个维度：出色的领导者、良好的文化，以及技术实力。单说领导者，我们和很多公司合作过它们的 AI 转型、培训、战略之类的事情。我感觉很多公司里，领导者在十到十五年里建立起了直觉，他们也因为这些直觉而备受尊敬。但现在有了 AI，这些直觉得重新学一遍，领导者必须愿意示弱才能做到这一点。我以前和现在 Rackspace 的 CEO Gagan 共事。他每天早上都有一个时间块，写着「补 AI 的课，凌晨 4 点到 6 点」，那段时间他不安排任何会议之类的。(00:26:42): 那就是他用来看最新 AI 播客或信息的时间。他周末还会搞 vibe coding 之类的东西。所以我觉得领导者必须重新回到亲自动手的状态。这不是因为他们得亲自去实现这些东西，而更多是为了重建自己的直觉，因为你必须能够接受一个事实：你的直觉可能是错的，你很可能就是屋里最笨的那个人，而你想向所有人学习。我见过这一点成为那些成功做出产品的公司非常显著的区分因素，因为你带进来的是一种自上而下的方式。几乎不可能自下而上做成。你不可能让一群工程师去说服领导者买单，如果领导者根本不信任这项技术，或者对这项技术有错位的预期。(00:27:34): 我从很多做产品的人那里听到，我们的领导者根本不理解 AI 能在多大程度上解决某个具体问题，或者他们随手 vibe code 一个东西，就以为很容易搬到生产环境。你真的需要理解 AI 今天能解决什么范围的问题，这样你才能在公司内部指导决策。第二个是文化本身。同样，我和一些企业合作，AI 不是它们的主业，它们需要把 AI 引入流程，只是因为竞争对手在做，或者只是因为这么做确实合理，因为有些用例已经非常成熟。然后在这个过程中，我感觉很多公司有一种 FOMO 的文化，一种「你会被取代」之类的文化，人们真的会很害怕。领域专家是构建有效 AI 产品中极其重要的一环，因为你真的需要咨询他们，才能理解你的 AI 表现如何，或者理想的行为应该是什么。(00:28:27): 但我和很多公司聊过，那里的领域专家就是不想跟你说话，因为他们觉得自己的工作要被取代了。所以，这又回到领导者本身。你要建立一种赋权的文化，把 AI 增强到你自己的工作流里，让你在做的事情上做到 10 倍，而不是说如果你不采用 AI 可能就会被取代之类的话。这种赋权的文化总是有帮助的。你要让整个组织一起投入，让 AI 为你所用，而不是各自守着自己的岗位等等。而且有了 AI，也确实打开了比以前多得多的机会。所以你的员工可以做比以前多得多的事情，生产力提升 10 倍。第三个是我们谈到的技术部分。(00:29:18): 我觉得成功的那些人，极其执着于把自己的工作流理解得非常透彻，并且增强那些适合用 AI 的部分，而不是那些在某处需要人介入的部分，等等。每当你试图自动化工作流的某个部分时，从来都不是「用一个 AI agent 就能解决问题」。永远是这样：你可能有一个机器学习模型做其中一部分工作，有确定性代码做另一部分工作。所以你真的需要执着于理解那个工作流，这样你才能为问题选择正确的工具，而不是执着于技术本身。我看到的另一个模式是，这些人真正理解「和一个非确定性 API 打交道」这件事，也就是你的 LLM。这意味着他们也理解 AI 开发生命周期看起来非常不同，他们迭代得相当快，也就是：我能不能做出一个东西，快速迭代，同时既不破坏客户体验，又能给我足够的数据去估计行为。(00:30:31): 所以他们很快就建起了那个飞轮。到今天，重要的不是成为竞争对手里第一个有 agent 的公司，而是你有没有建好正确的飞轮，能够随着时间不断改进。当有人跑来跟我说，「我们有这个一键式 agent，部署到你的系统里，两三天就能给你带来显著收益」，我几乎会怀疑，因为这根本不可能。这不是因为模型不行，而是因为企业的数据和基础设施非常混乱，你需要一点时间…… 就连 agent 也需要一点时间去理解这些系统是怎么运作的。到处都是很混乱的分类体系。人们往往做的是「取客户数据，我们要；取客户数据，我们做」这类事情。那些函数都存在，也都在被调用，基本上有大量技术债需要处理。(00:31:23): 所以大多数时候，如果你执着于问题本身，并且非常了解自己的工作流，你就会知道如何随着时间改进你的 agent，而不是随手糊一个 agent 上去，然后假设它第一天就能用。我甚至敢说，如果有人卖你一键式 agent，那纯粹是营销。你不要买账。我宁愿选一家说「我们要为你搭建这条流水线」的公司，它会随着时间学习，建立飞轮不断改进，而不是一个开箱即用的东西。要替换任何关键工作流，或者做出能带来显著 ROI 的东西，即便你有最好的数据层和基础设施层，也很容易需要四到六个月的工作。
太棒了。这里面有很多东西和我在这档播客里其他对话中听到的深深共鸣。其中一个就是，一家公司要想成功地从 AI 中获得大量影响，创始人兼 CEO 必须深度投入。我请过 Dan Shipper 上播客，他们和很多公司合作，帮它们采用 AI。他说这是预测成功的第一要素：CEO 有没有一天很多次地和 ChatGPT、Claude 之类的聊天。我很喜欢你举的 Rackspace CEO 每天早上补 AI 新闻的例子。我本来想象他是在和聊天机器人对话，而不是读新闻。
以你今天能拿到的信息量，你完全可以…… 我的意思是，你也得选对渠道，因为每个人都有观点。那你要押注谁的观点？我觉得拥有一批高质量的信息源、并且去听他们，真的很有道理。所以他只有两三个来源的清单，一直看。然后他带着一堆问题回来，和一群 AI 专家来回讨论，看看他们怎么想。我当时就在那个群里，所以我大概知道——
我喜欢这个。
……他提出的那些问题。
太酷了。
挺酷的。我当时问，「你为什么要做这么多？」然后他说，「这会渗透到我们做出的一堆决策里。」
好。我们聊另一个话题，这个话题非常…… 它在这档播客里一直很热，也在 Twitter 上热过一阵子：evals。很多人痴迷于 evals，觉得它是 AI 中很多问题的解法。也有很多人觉得它被高估了，你不需要 evals，凭感觉就行，不会有事。你对 evals 怎么看？它能在多大程度上帮人解决你提到的那些问题？
就社区里正在发生的事而言，我感觉存在一种虚假的二分法：要么 evals 能解决一切，要么线上监控、生产监控能解决一切。我觉得没有理由去相信任何一个极端，也就是说，我不会把整个应用完全押在这一个或那一个上。所以退一步看，什么是 evals？evals 基本上就是把你对产品的可信思考，或者你对产品的理解，注入到你要构建的那组数据集里——意思是，这才是我在乎的东西，这些是我的 agent 不该做的问题，然后我建一个数据集清单，让自己在这些方面表现良好。而生产监控，你做的是把应用部署出去，然后有一些关键指标能真正反馈给你，客户是怎么用你的产品的。(00:34:47): 你可能部署了任何 agent，如果客户对你的交互点了赞，你最好知道这件事。这就是生产监控要做的事。生产监控在普通产品里已经存在很久了，只是现在有了 AI agent，你需要监控的粒度细得多。不只是客户总是给你明确反馈，还有很多你可以获得的隐式反馈。比如在 ChatGPT 里，如果你喜欢答案，你可以点个赞。如果你不喜欢，有时候客户不会点踩，而是直接重新生成答案。那就明确说明最初那个答案没有达到客户预期。这些就是你始终需要考虑的隐式信号。(00:35:35): 而在生产监控这一侧，这个谱系一直在扩展。现在回到最初的话题：到底是 evals 还是生产监控？这有什么要紧？我感觉，还是要回到问题优先的方式：你到底想构建什么。你想为你的客户构建一个可靠的应用，它不会做坏事，它总是会做正确的事；或者如果它做错了，你会很快收到警报。所以我把这拆成两部分。第一，没有人会在部署应用之前不做测试。这个测试可能是「擦除」式的，也可能是：好，我这有 10 个无论如何都不该出错的问题，让我把这个建起来，我们就叫它评估数据集。现在，假设你建好了，部署了，然后你发现，好，现在我需要理解它有没有在做正确的事。(00:36:32): 那如果你是高吞吐或高交易量的客户，你实际上不可能坐下来评估所有的 trace。你需要一些指示，来理解我应该看哪些东西。这就是生产监控登场的时刻：你无法预知你的 agent 可能在哪方面出错，但所有这些隐式和显式信号会反馈给你，告诉你需要看哪些 trace。这就是生产监控发挥作用的地方。而一旦你拿到这类 trace，你就需要检查这些不同类型的交互里出现了哪些失败模式，有没有什么是你真正在乎、不该发生的。如果这些失败模式在发生，那我就需要考虑为它建一个评估数据集。(00:37:20): 那么，假设我为我的 agent 建了一个评估数据集，针对的是它在退款场景下试图退款，而我明确配置了它不许这么做。我建好了这个数据集，然后在工具或提示词之类的地方做了修改，然后部署了产品的第二个版本。现在不能保证这就是你唯一会遇到的问题。你仍然需要生产监控去真正捕捉你可能会遇到的不同类型的问题。所以我觉得 evals 重要，生产监控也重要，但「只有其中一个能帮你解决问题」这个说法，在我看来完全可以否定。
好。一个非常合理的回答。而这里的重点不是——它不只是「两个都做」这么简单。更确切地说，需要捕捉的东西是不一样的，一种方法抓不到所有你需要关注的东西。
正是。
太棒了。
我想退两步，聊聊 evals 这个词在 2025 年下半年承担了多少重量。因为你去见一家数据标注公司，他们告诉你，我们的专家在写 evals；然后又有这么多人说得让 PM 来写 evals，它们是新的 PRD；再然后有人说 evals 几乎就是一切，就是你应该构建用来改进产品的那个反馈回路。现在，作为一个初学者退一步想，什么是 evals？为什么大家都在说 evals？实际上这些是流程里不同的部分，而且没人说错——是的，这些都是 evals，但当一家数据标注公司告诉你我们的专家在写 evals 时，他们实际上指的是错误分析，或者专家只是在记录什么才算对。(00:39:02): 律师和医生写 evals，这不代表他们在构建 LLM 评判器，也不代表他们在构建整个反馈回路。而当你说 PM 应该写 evals，并不意味着他们得写出一个足够好、能上生产的 LLM 评判器。我觉得这里面也有非常教条化的做法，另外给 KD 点个赞：你无法事先预测自己到底需要建一个 LLM 评判器，还是需要用生产监控里的隐式信号等等。我记得 Martin Fowler 在 2000 年代有个说法叫「语义扩散」，大致意思是，有人提出一个词，所有人开始用自己的定义去糟蹋它，然后你就丢掉了它真正的定义。这就是 evals 或者 agents，或者今天 AI 里任何一个词正在经历的事，每个人大概都看到了它的不同侧面。(00:39:54): 但如果你让一群从业者坐在一起，问他们「为 AI 产品构建一个可行动的反馈回路重要吗？」我觉得所有人都会同意。至于怎么做，真的取决于你的应用本身。当你进入复杂的用例，构建 LLM 评判器会极其困难，因为你会看到大量涌现的模式。如果你建了一个评判器去测啰嗦程度之类的东西，结果你会发现出现了更新的模式，你的 LLM 评判器抓不到，最后你只是建了太多 evals。到那个点上，看用户信号、修掉问题、检查有没有回归、然后继续往前走，反而更合理，而不是真的去建这些评判器。所以都得看情况。我觉得每个 ML 从业者都会告诉你的一句话是：真的取决于上下文。不要痴迷于那些会变的教条。
这是一个非常重要的点，尤其是 evals 现在对不同的人意味着很多东西。它就是一个指代太多东西的词。当你把它看成数据标注公司给你的东西、还有 PM 的那些东西时，只谈 evals 就很复杂，对吧？还有 benchmark。人们也把 benchmark 叫做某种程度的 evals。就像——
我最近和一位客户聊，他跟我说，「我们也做 evals。」我说，「好，能给我看看你们的数据集吗？」他说，「没有，我们只是看了 LM Arena 和 Artificial Analysis。这些是独立 benchmark，我们知道这个模型对我们的用例是对的。」我说，「你这不是在做 evals。那不是 evals。那是模型评估。」
但这也能理解。这个词在那个语境下也能用。我明白人们为什么会那么想，但确实，现在只是让它更混乱了。
对。
这里我还想再追问一句，也是我心里一直想的：这件事之所以变成一场大争论，是因为 Claude Code。Claude Code 的负责人 Boris 说，「不，我们不在 Claude Code 上做 evals。全靠感觉。」Kiriti，关于 Codex 和 Codex 团队，你能分享些什么吗？你们是怎么做 evals 的？
所以对 Codex，我们采取的是一种平衡的方式：你需要有 evals，同时你也必须去听客户的声音。我记得 Alex 最近上过你的播客，他讲过你们有多专注于做出正确的产品。而其中很大一部分就是听客户说话。编码 agent 和其他领域的 agent 相比非常独特，因为它们是为可定制性而建的，是为工程师而建的。所以编码 agent 不是一个去解决前五大工作流或者前六大工作流之类的产品。它是要以多种不同方式被定制的。这意味着你的产品会被用在不同的集成、不同类型的工具、不同种类的东西里。所以要为你客户可能使用你产品的所有交互类型建一个评估数据集，真的很难。(00:42:38): 话虽如此，你也需要理解，好，如果我要做一个改动，至少不能破坏产品里真正核心的东西。所以我们有评估来做这件事，但同时我们极其用心地去理解客户是怎么用它的。比如我们最近做了这个 code review 产品，它获得了极大的关注。我感觉 OpenAI 内部以及我们外部客户那里很多很多 bug 都被它抓出来了。那假设我要对 code review 做一个模型改动，或者换一种我训练它用的 RL 机制，现在如果我打算部署，我肯定想做 A/B 测试，确认它是不是真的找到了正确的错误，以及用户对它反应如何。有时候如果用户被你错误的代码评审烦到了，他们会做到直接关掉这个产品的地步。(00:43:36): 所以那些就是你想看的信号，确保你的新改动在做正确的事。而我们要事先想到这类场景并为它开发评估数据集，是极其困难的。所以我觉得两者都有一些。有很多感觉，也有很多客户反馈，我们在社交媒体上非常活跃，去了解有没有人遇到某些类型的问题，然后快速修掉。所以我觉得这是一个…… 怎么说呢？这是你做事情的一个领域。
这太好理解了。好，我听到的是：Codex，支持 evals，但还不够。
对。
但也要看客户的行为和反馈。另外还有一些感觉层面的东西，就是：这个用起来顺手吗？我用它的时候，它生成出让我兴奋的好代码，我觉得很棒。
我不觉得如果有人跑来说，我有一套具体的 evals，我可以拿命去赌，然后其他什么都不用想——这不会行得通。而且每一个你要发布的新模型，我们都会作为团队聚在一起测试不同的东西。每个人关注的点不一样。我们有一份难问题的清单，我们把它丢给模型，看它进展得怎么样。所以可以说，这像是每个工程师自己的定制 evals，就是去理解产品在新模型下的表现。
如果你是创始人，创业最难的部分不是有那个点子，而是在不被后台杂务埋没的情况下把业务做大。这就是 Brex 出场的地方。有了 Brex，你能拿到高额度公司卡、便捷的银行服务、高收益的资金管理，还有一支 AI agent 团队替你处理手工财务工作。他们会做所有你不想做的事，比如报销、扫描交易找浪费、按你的规则跑报表。有了 Brex 的 AI agent，你可以跑得更快，同时完全掌控。美国三分之一创业公司已经在用 Brex。你也可以，访问 brex.com。(00:45:43): 我们已经聊了快一个小时，还没讲到你们开发的那套极其强大的 AI 产品软件开发工作流，是你们两位做出来、在课程里教的，基本上把我们聊的所有东西整合成了一套逐步构建 AI 产品的方法。你们叫它持续校准、持续开发框架。我们把图调出来给大家看看我们到底在说什么，然后请你带我们过一遍：这是什么、怎么运作、团队怎么把构建 AI 产品的方式转向这种方法，从而避免大量的痛苦和折磨。
在解释这个生命周期之前，先讲个小故事，说说 Kiriti 和我为什么会想出这个。因为我们一直在和很多公司聊，它们承受着来自竞争对手的压力，因为大家都在建 agent。我们应该建完全自主的 agent。我确实和几个客户合作过，建了这些端到端的 agent。结果发现，因为你一开始并不知道用户会怎么和你的系统交互、AI 会给出什么样的回复或动作，当你面对一个要走四五步、做大量决策的巨大工作流时，要修问题真的很难。你最后就是不停地调试，然后热修复，修到某个时候——我们当时是在为一个客户支持用例构建，也就是我们在通讯里给的那个例子。(00:47:13): 最后我们不得不把产品关掉，因为我们做了太多热修复，根本没有办法数清冒出来多少问题。网上也有不少新闻。最近我想 Air Canada 就有这么一个事，他们的一个 agent 预测或者说幻觉出了一条退款政策，那不在他们原本的剧本里，但因为法律原因他们得照办。还有一大堆非常吓人的事故。这个想法就是从那里来的。你要怎么构建，才能既不失去客户信任，也不会让你的 agent 或 AI 系统做出对公司本身极其危险的决定。同时，还要建立一个飞轮，让你能随着推进不断改进产品。这就是我们提出持续校准、持续开发这个想法的由来。(00:48:08): 想法很简单：我们在这个回路的右侧是持续开发，在这里你去界定能力范围、整理数据，基本上就是拿到一组数据集，里面是你预期的输入，以及预期的输出应该长什么样。
在你开始构建任何 AI 产品之前，这是一个非常好的练习，因为很多时候你会发现，团队里很多人对产品应该如何表现根本没有对齐。这正是你的 PM 能提供更多信息的地方，你的领域专家也是。所以你有了这组数据集，你知道你的 AI 产品应该在这些上面做得很好。它不全面，但它能让你开始。然后你搭建应用，设计正确的评估指标。我特意用「评估指标」这个说法，虽然我们说 evals，因为我想非常具体地说明它是什么：评估是一个过程，评估指标是你在过程中要关注的维度。(00:49:07): 然后你去部署，跑你的评估指标。第二部分是持续校准，这一部分是你去理解一开始没有预料到的行为，对吧？因为当你开始开发过程时，你有这组数据在优化，但更多时候你会发现这组数据不够全面，因为用户开始以你没预料到的方式和你的系统交互。这就是你要做校准的部分。我部署了系统，现在我看到有一些我确实没预料到的模式，你的评估指标应该能给你一些关于这些模式的洞察，但有时候你会发现那些指标也不够，你可能有一些你没想到的新错误模式。这就是你去分析行为、发现错误模式的地方。(00:49:59): 你针对看到的问题应用修复，但你也会设计更新的评估指标，去发现那些正在涌现的模式。这并不意味着你总该设计评估指标。有些错误你修掉就行，不必回头再看，因为它们是非常点状的错误。比如某个工具调用错误，只是因为你的工具没定义好之类的。你修掉然后继续就行。
这基本上就是 AI 产品生命周期该有的样子。但我们特别还提到一点：在你经历这些迭代时，尽量在早期用低自主性迭代、高控制度的迭代。意思是，限制你的 AI 系统能做的决策数量，确保有人类在回路中，然后随着时间逐步放开，因为你在建立一个行为的飞轮，你在理解会进来什么样的用例，或者用户是怎么使用系统的。(00:50:59): 我们在通讯里给的一个例子是客户支持。这张图很好地展示了如何把自主性和控制看成两个维度。你的每个版本都在提升自主性，也就是你的 AI 系统做决策的能力，同时随着推进降低控制。我们给的一个例子是客户支持 agent，你可以把它拆成三个版本。第一个版本只是路由：你的 agent 能不能把一张工单分类并转到正确的部门？有时候你读到这个会想，做个路由有那么难吗？agent 为什么不能轻松做到？而当你进入企业，路由本身就可能是一个超级复杂的问题。任何零售公司，你能想到的任何一家热门零售公司，都有层级化的分类体系。(00:51:52): 大多数时候这些分类体系极其混乱。我做过一些用例，里面的分类体系可能写着某种层级，然后写着鞋子，然后女鞋和男鞋都在同一层——而按理说应该是鞋子，然后女鞋和男鞋作为子类。然后你想，好吧，合并一下就行。再往下看，鞋类下面还有另一个区块写着「女款」和「男款」，就是没聚合，不知道为什么没修好。所以如果一个 agent 看到这样的分类体系，它该怎么做？它该路由到哪里？
而且很多时候，这些问题你根本意识不到，直到你真的动手去搭点东西、去理解它。(00:52:39)：遇到这类问题，真正的人类坐席一看就知道接下来该查什么。比如他们可能发现，鞋子下面那个写着「女款」「男款」的节点最后更新是 2019 年，这说明它就是个躺在那儿的死节点，根本没人用。所以他们大致知道，好吧，我们该看的是另一个节点，诸如此类。我不是说智能体理解不了这个，也不是说模型能力不够——而是企业内部真有一些特别奇怪的规则，哪里都没有文档记录。你要确保智能体拿到所有这些上下文，而不是直接把问题扔给它。(00:53:17)：对。回到我们做的那几个版本，路由是控制力非常高的一个，因为就算你的智能体把工单路由到了错误的部门，人类也能接管、把这些操作撤销掉。而且在这个过程里你也会发现，你手上大概有一大堆数据问题需要修，得确保你的数据层足够好，智能体才能跑起来。接下来我们说的是 Copilot 那一步：既然你经过几轮迭代发现路由能正常工作了，数据问题也都修好了，就可以往下走一步——我的智能体能不能基于我们给客服坐席准备的那些标准作业流程给出建议？它可以先生成一份草稿，人类再在上面改。做这件事的时候，你同时在记录人类的行为，也就是说，这份草稿被客服坐席用了多少、哪些被删掉了。所以这相当于你白拿了一份错误分析，因为你把用户做的每一件事都记下来了，之后可以反哺进你的飞轮。(00:54:22)：然后我们说，再往后，一旦你发现这些草稿看着不错，大多数时候人类也没怎么大改，基本是原样用。
那就是你该走向端到端解决方案助手的时候了——它可以起草一份处理方案，连工单一起解决掉。这些就是自主性的几个阶段，从低自主性开始，一步步往上走。我们还整理了一张很好用的表，讲的是每个版本你该做什么、你学到了什么从而能进入下一步，以及你拿到了哪些信息可以喂回循环里，对吧？当你在做路由的时候，你有了质量更好的路由数据，你也知道了要改进路由系统该去搭什么样的提示词。(00:55:09)：本质上，你是在把上下文工程的结构想清楚，把想要的那个飞轮建起来。讲这些的时候，我想特别说清两点。第一，当你带着 CCCD 的思路去构建，并不意味着你就一劳永逸地把问题解决了。很可能你已经走到 V3，然后又看到了一种你之前完全没想象过的数据分布。这只是降低风险的一种方式——在走向完全自主之前，先拿到足够多关于用户如何与你的系统互动的信息。第二，你其实也在顺手建一个隐性的日志系统。很多人跑来问我们：「等等，不是有 evals 吗？为什么还需要这种东西？」只搭一堆评估指标、然后让它们在生产环境里跑，问题在于：评估指标只能捕捉你已经意识到的那些错误，但很多新冒出来的模式，只有把东西放到生产环境之后你才会懂。(00:56:17)：所以针对这些新兴模式，你是在造一个低风险的框架，让你能理解用户行为，而不是落到有一大堆错误、你想一次性全修完的处境。而且这不是唯一的方法，办法有很多很多。你要决定的是怎么给自主性设约束。可以按智能体执行动作的数量来约束，就像我们在这个例子里做的；也可以按话题来约束。
有些领域里，让系统在某些决策上完全自主，风险是相当高的；但另一些话题就完全可以放手让它自主，这要看问题的复杂度。这种时候，你特别需要产品经理、工程师和领域专家对齐，一起定下这个系统怎么建、怎么持续改进。(00:57:10)：说白了就是行为校准，以及在做行为校准的过程中不要丢掉用户的信任。
想深入了解的听众，我们会把那篇文章的链接放出来。里面基本上就是一步步走完全部流程，还配了一堆例子。这里的核心想法，就像你说的，你讲的这一切都是为了让它持续、迭代，沿着「自主性更高、控制更少」这条路径往前推。而把它叫做 continuous calibration、continuous development，本身就是在传达这是个迭代过程。说清楚一点，这个命名是对 CI/CD——持续集成、持续部署那套东西的致敬。这里的想法是，这是 AI 版本的 CI/CD：不是把代码集成进单元测试然后不停部署，而是跑 evals、看结果、针对你在盯的指标做迭代、找出它在哪儿崩，然后继续迭代。太好了，好。(00:58:08)：所以再说一次，想深入的我们会把那篇文章指给大家。这个概览讲得很好。在转到别的话题之前，关于这个框架本身，还有什么你觉得大家应该知道的吗？
我觉得我们被问得最多的一个问题是：我怎么知道该不该进入下一个阶段，或者现在这个状态是不是已经校准得够好了？其实没有一本规则手册可以照着做，核心就是让「意外」最小化。意思是，假设你每一两天做一次校准，然后你发现自己已经看不到新的数据分布模式了，用户跟系统互动的方式一直很一致。那你获得的信息量其实非常低，这时候你就知道可以进到下一个阶段了。到那个点上，靠的基本上就是感觉：你知道自己准备好了，因为你已经收不到新信息了。但也有必要理解，有时候会出现一些事件，把你系统的校准彻底打乱。举个例子，GPT-4o 现在没有了，或者说它在 API 里也要被弃用了。(00:59:16)：所以大部分用 4o 的公司都得切到 5，而 5 的特性差别非常大。这时候你的校准又偏了，你就得回去把整个流程再走一遍。有时候用户跟系统互动的方式也会随时间改变，也就是用户行为会演化。就算是消费级产品，你跟 ChatGPT 说话的方式也和两年前不一样了，因为这些能力提升太多了。而且人们一旦发现这些系统能解决某个任务，就会很兴奋，想拿别的任务也试一试。我们之前给核保员做过一个系统。核保是件很痛苦的事。那些协议、贷款申请动不动就是三四十页，这家银行的想法是做一个系统，帮核保员挑出保单和银行的相关信息，好让他们能批贷款。(01:00:15)：头三四个月，所有人对这个系统都挺满意的。核保员确实汇报了时间上的收益，等等。但头三个月我们就发现，他们太喜欢这个产品了，开始问一些我们完全没预料到的很深的问题。他们会直接把整份申请文档扔给系统，说：「像这种案子，以前的核保员是怎么处理的？」对用户来说，这看起来只是他们原本在做的事的自然延伸，但背后要建的东西得大变。现在你得弄清楚，在贷款这个语境下「像这种案子」到底指什么？是指某个收入区间的人，还是指某个地区的人，诸如此类。(01:00:58)：然后你还得把历史文档调出来，分析这些文档，再告诉他们「好，情况是这样的」，而不是简单地说这里有 X、Y、Z 三条政策，你去查那条政策。所以，对终端用户来说特别自然的一件事，对产品构建者来说可能非常难做。你会看到用户行为也在随时间演化，这时候你就知道，该回去重新校准了。
你觉得现在 AI 领域里什么被过度炒作了？更重要的是，你觉得什么被低估了？
就像我说的，我对 AI 里正在发生的各种事情都非常乐观。所以我不会说它被过度炒作，但我觉得 multi-agents 这个概念有点被误解了。人们有种想法：「我有个极其复杂的问题。现在我要把它拆开——嘿，你是这个智能体，你负责这个；你是那个智能体，你负责那个。」然后如果我能把这些智能体用某种方式连起来，他们就觉得这是智能体的乌托邦。但事实从来不是这样——确实有极其成功的多智能体系统被建出来，这一点毫无疑问。但我觉得很多时候关键在于：你怎么限制系统跑偏的方式。比如说，如果你在做一个 supervisor agent，让一些子智能体真正去为这个主管智能体干活，那是一个非常成功的模式。(01:02:24)：但如果抱着这种想法——我按功能划分职责，然后指望这些部分靠某种 gossip protocol 自己协同起来——这是极其被误解的，大家以为这样能行。我不认为现在构建的方式和当前的模型能力已经到了能做出那类应用的程度。所以我觉得这更多是被误解，而不是被高估。被低估的部分，可能很难让人相信，但我还是觉得 coding agents 被低估了。意思是，你上 Twitter、上 Reddit，能看到大量关于 coding agents 的讨论，但你去跟随便一家公司的工程师聊，尤其是湾区以外的，你就能看到这些 coding agents 能创造多大的影响，而渗透率还非常低。所以我觉得 2025 和 2026 会是优化所有这些流程的惊人年份。(01:03:25)：我觉得这会用 AI 创造出大量价值。
第一点特别有意思。所以你的意思是，做一个能自己拆分出子任务的智能体，大概会比搞一堆 Codex 智能体——你干这个任务、你干那个任务——更容易成功？
你可以让智能体去做这些事，由你作为人类来编排；也可以有一个更大的智能体来编排所有这些事。但如果让智能体之间以点对点那种协议互相通信，尤其是在客服这类场景里，你极其难以控制到底是哪个智能体在回复你的客户，因为你得把防护栏到处搬来搬去，诸如此类。
好。不错，这两个选得很好。好，Ash，你呢？
我能说 evals 吗？我会被封杀吗？
归到哪一类？放哪个桶里？
被高估。
被高估。好，说吧，我们不会让你被封杀的。
开玩笑的。我觉得 evals 是被误解了。它们很重要，各位。我不是说它们不重要。但我觉得问题在这儿：我会不停地跳来跳去换工具，看到新工具就去上手学，这本身是被高估的。我还是老派，觉得你真的需要对你要解决的业务问题痴迷。AI 只是个工具，我尽量这么看它。当然，你得了解最新最好的东西，但别痴迷于只是快速地搭东西。今天构建真的很便宜。设计更贵——真正去想你的产品、想你要构建什么、它是不是真的能解决一个痛点，这在今天有价值得多。而且在不远的将来，这一点只会更加成立。所以，真正痴迷于你的问题和设计是被低估的，而只是机械地构建是被高估的，我猜。
太好了。好，类似的问题。从产品角度看，你觉得 AI 的下一年会是什么样？给我们描绘一下你认为到 2026 年底会走到哪儿。
对，我觉得 background agents——也就是主动型智能体（proactive agents）——这块很有前景。它们基本上会更懂你的工作流。如果你想今天 AI 在哪儿没能创造价值，主要就是它不理解上下文。而不理解上下文的原因是，它没有接到真正发生工作的那些地方。你越多做这件事，就能给智能体越多上下文，然后它开始看到你周围的世界，理解你在优化的那组指标是什么，或者你试图做的那些活动是什么。从那儿再往前延伸就很容易了，你可以从中拿到更多价值，然后让智能体反过来提示你。我们在 ChatGPT pulse 上已经在做这个了，它每天给你一份你可能关心的事情的更新。(01:06:20)：有东西来这么拨一下你的脑子其实挺好的——「哦，这个我之前没想到过。也许这个不错。」现在你把这个延伸到更复杂的任务上，比如一个 coding agent 说：「好，我已经修完了你五个 linear 工单，这是补丁。你一天开始的时候过一遍就行。」我觉得这会极其有用。我认为这是 2026 年产品会走的一个很强的方向。
太酷了。所以本质上，智能体在预判你想做什么，跑到你前面去，说我已经帮你把这些解决了，或者我觉得这个会让你的站点崩，也许你该修修这里，或者我看到这儿有个尖峰，我们把数据库重构一下吧。太厉害了。多好的世界。好，Ash，你呢？
2026 年我全力押注多模态体验。我觉得 2025 年我们已经取得不少进展，不只是生成，还有理解。到目前为止，LLM 一直是我们最常用的模块，但作为人类，我会说我们是多模态的生物。语言大概是我们演化出来的最后几种形式之一。就像我们三个人在聊天，我觉得我们一直在接收大量信号。我会想：「哦，Lenny 在点头，那大概我可以往这个方向说」，或者「Lenny 无聊了，我别说了。」所以你的思维链背后还有一条思维链，你一直在用语言去调整它——那个表达维度还没有被充分探索。所以如果我们能做出更好的多模态体验，就能更接近人类对话的那种丰富度。而且，就现在这些模型而言，还有一堆无聊的任务，它们正适合 AI。(01:08:04)：如果多模态理解变强了，有那么多手写文档和极其凌乱的 PDF，即便是今天最好的模型也处理不了。如果这成为可能，那能挖掘的数据就太多了。
太好了。我刚看到 DeepMind 的 Demis——AI、Google，不管他们整个组织叫什么——在讲这个，他认为这会是他们前进方向的一大块，把图像模型的工作、LLM，还有他们的世界模型，好像是叫 Genie，结合起来。是的。所以那会是个疯狂、疯狂的时代。好，最后一个问题。如果有人就想把构建 AI 产品这件事做得更好，你觉得他们应该重点投入、去培养的一个技能，或者两个技能，是什么？
我觉得我们已经讲了不少 AI 产品的最佳实践，就是从小的做起、把迭代跑顺、建起飞轮等等。但再说一次，如果你用一万英尺的高度来看今天任何一个做产品的人，就像我说的，未来几年实现会便宜到离谱。所以真正要把你的设计、你的判断力、你的品味这些东西打磨扎实。而且一般来说，如果你在建立职业生涯，我觉得过去这几年，你早期那几年、比如说职业生涯头两三年，总是聚焦在执行、机制这些东西上。现在我们有了 AI，能帮你很快地爬过这个阶段，过了之后——我是说，几年之后，我觉得每个人的工作都会变成关于你的品味、你的判断，以及什么是独特的你。(01:09:49)：我觉得要把这部分打磨扎实，想办法把这种视角带进来。这并不意味着你必须年纪很大、有很多年经验。我们最近招了一个人，我们用一个很流行的 app 来追踪任务，用了好多年，还付着很高的订阅费。结果这家伙直接带着他自己 vibe code 出来的 app 来开会，给我们做了全套上手，然后说：「好，我们开始用这个吧。」我觉得那种能动性、那种真正重新思考体验的主人翁意识，才是让人脱颖而出的东西。我也不是对 vibe coded 的应用维护成本高这件事视而不见。也许随着公司规模变大，我们得换掉它，或者得想更好的办法。(01:10:36)：但考虑到我们现在是家小公司，而且……我当时真的很震惊，因为我从来没这么想过。如果你习惯以某种方式工作，你会给「构建」这件事关联上一个成本。我觉得在这个年代长大的人，脑子里关联的成本要低得多。他们就是不介意动手做点东西然后往下走。而且他们也非常热衷于尝试新工具。这大概也是 AI 产品有留存问题的原因之一——每个人都太兴奋于尝试这些新工具了。但本质上，拥有能动性和主人翁意识，我觉得这也将是忙碌工作时代的终结。你不能坐在角落里做些不推动公司前进的事。你真的需要去思考端到端的工作流，思考怎么带来更多影响。(01:11:26)：我觉得这些都会超级重要。
这让我想起，我刚请了 Jason Lemkit 上播客。他在销售、go to market、跑 SaaStr 这些方面非常聪明，他把整个销售团队都用智能体替换了。他原来有 10 个销售，后来变成 1.2 个人加 20 个智能体。其中一个智能体就是追踪每个人在 Salesforce 里的更新，根据他们的通话自动帮他们更新。结果有个销售说：「好，我辞职。」后来发现他其实什么都没干，就是坐在那儿闲着，他心里想：「好吧，这玩意儿会把我抓出来，我得赶紧撤。」所以你说的那点——以后想坐在那儿捻手指混日子会更难——我觉得非常对。
对，我想补充一点，我觉得坚持也是极其有价值的东西，尤其是现在，任何想做出点东西的人，信息比过去十年更触手可及。你可以一夜之间学会任何东西，变成那种钢铁侠式的路子。所以我觉得，有那份坚持，去经历学习这个、实现这个、弄明白什么行什么不行的痛苦。当你在经历开发多种方案、然后解决问题的这个痛苦过程时，我觉得那才会成为你作为个体真正的护城河。我喜欢把它叫做「痛苦是新的护城河」，但我觉得在构建这些 AI 产品时，这一点确实超级有用。
多说一点。我很喜欢这个概念。痛苦是新的护城河。还有更多吗？
对，我觉得作为一家公司，我的意思是，现在在任何新领域里构建的成功公司，它们成功不是因为它们最先进入市场，也不是因为它们有个更多客户喜欢的花哨功能。它们经历了那个痛苦——去理解哪些东西是不可让步的，并且正好用它们能用来解决这个问题的功能或模型能力去做取舍。这不是一个直接的过程。没有教科书教你怎么做，也没有直截了当的办法，或者一条已知的捷径能走到这儿。所以我说的很多痛苦，就是经历这种迭代：「好，试试这个，不行再试试这个。」而你在整个组织里、或者在你自己的亲身经历里积累起来的那类知识，我觉得那份痛苦就是转化成公司护城河的东西。它可能是一个 evals 的产物，或者你建出来的什么东西。我觉得那会是改变游戏规则的东西。
太棒了。就像把煤变成钻石。
是的。
好。我觉得我们已经很好地帮大家避开了一些人们在构建 AI 产品时反复撞上的最大问题。我们讲了很多坑，也讲了真正做对的方法。在我们进入非常激动人心的闪电轮之前，你还有什么想分享的吗？还有什么想留给听众的？
对你的客户痴迷。对问题痴迷。AI 只是一个工具，要确保你真的理解你的工作流。80% 所谓的 AI 工程师、AI PM，他们花时间做的是非常深入地去理解自己的工作流。他们不是在搭最花哨、最酷的模型或者围绕它的工作流。他们实际上是扎在细节里，理解客户的行为和数据。每当一个从没做过 AI 的软件工程师听到这句话——「去看你的数据」——我觉得这对他们是个巨大的启发，但其实一直如此。你需要去那儿，看你的数据，理解你的用户，那会是一个巨大的差异化因素。
这是个很好的收尾方式。AI 不是答案。它是解决问题的工具。说到这里，我们到了非常激动人心的闪电轮。我给你们俩准备了五个问题。准备好了吗？
耶。准备好了。
好。所以你们俩都可以回答，也可以挑一个想回答的。都行，看你们。你们最常向别人推荐的两三本书是什么？
对我来说，是这本叫 When Breath Becomes Air 的书，Lenny。作者是 Paul Kalanithi。我记得他是个印度裔神经外科医生，31 还是 32 岁的时候被诊断出肺癌。整本书是他的回忆录，就是确诊之后写的。写得非常美，尤其是因为我在 COVID 期间读的，而 COVID 期间我们唯一想做的就是活下去。书里有很多很好的句子，但我记得其中一句，他是在反驳苏格拉底一句非常有名的话——「未经省察的人生不值得过」，或者类似的意思，就是说你真的需要去思考你的选择，需要理解你的价值观、你的使命等等。然后 Paul 说：「如果未经省察的人生不值得过，那未曾活过的人生值得省察吗？」意思是你是不是花了太多时间去理解你的使命和目的，以至于忘了去活？(01:16:32)：我觉得每个留在 AI 时代、在构建、不断经历自我重塑的人，都需要停一下，去活一会儿，我猜。他们得别再对生活做那么多 eval 了。
我正想说这个。我脑子里冒出来的就是这个。你得给自己的人生写点 evals。天啊，我们走得太远了。
对。是啊。
很美。
这是我最喜欢的一本书。
我更喜欢科幻类的书。所以我特别喜欢 3 Body Problem 这个系列。它是一个三本书的系列。里面有比科幻更宏大的元素——地球之外的生命，以及它如何影响人类的决策过程。它还有地缘政治的元素，以及抽象科学对人类进步有多重要、多有价值。然后当它被中止时，在日常生活中你注意不到，但它可能造成毁灭性的后果。所以我觉得，AI 在这些领域帮忙，会是极其关键的。而那本书就是「否则会怎样」的一个很好的例子。
完全同意。绝对的。我很喜欢。可能是我最喜欢的科幻书，或者甚至说是系列，而且它是三本。顺便说，三本我都得读。我发现它大概到一本半之后才真正好看起来。所以如果有人试过，心想「这到底在讲什么鬼」，继续读，读到第二本中间，然后就炸裂了。
对。
如果你喜欢科幻，又在 AI 行业，你一定要读这本 Vernon Vinge 写的 A Fire Upon the Deep。去看看吧，非常了不起。我看到 Noah Smith 在他的 newsletter 里推荐这本书，它还有续集，但这一本是真的了不起。而且它其实讲的是 AGI 和超级智能这些事，就是特别史诗。而没人听说过它。
谢谢。
这就对了。我还你一本。好，下一个问题。你最近特别喜欢的一部电影或电视剧是什么？
我开始重看 Silicon Valley，我觉得它太真实了，太永恒了。所有事情又在重演一遍。几年前看过的人应该重看一遍，你会发现它跟现在 AI 浪潮里发生的一切惊人地相似。
重看是个好主意。我很喜欢他们整个生意就是一个压缩算法——像是一个压缩算法。某种程度上也许算是 LLM 的前身。不，我懂。好，Kiriti，你呢？
我要跑题一下，说个游戏而不是电影或电视剧，但我最近上手了一个叫 Expedition 33 的游戏。它跟 AI 毫无关系，但做得极其精良，无论是玩法，还是像电影一样的叙事和音乐。非常惊艳。
我很喜欢你还有时间玩游戏。这是个好迹象。我喜欢。OpenAI 的人，我就在想象你……除了写代码和开会之外没别的事了。
是啊，要找出时间来做这个真的非常难。
那挺好。这是个好迹象。我很高兴听到这个。好，你最近发现并且特别喜欢的一个产品是什么？
对我来说是 Whisper Flow。我觉得我用得挺多的，我都不知道我这么需要它。最好的地方是它是一个概念性的转写工具，意思是如果你去 Codex 里开始用 Whisper Flow，它会开始识别变量这些东西。而且它在「转写」到「指令」之间切换得非常顺滑。你可以说类似「我今天太兴奋了。加三个感叹号」，它就会无缝切换，真的加上那三个感叹号，而不是把「加三个感叹号」这句话写下来。我觉得这挺酷的。如果你没用过，该试试。
我打个广告。成为我 newsletter 的年度订阅用户，就能免费拿到一整年的 Whisper Flow。
我就是这么拿到访问权的，Lenny。
这就对了。这个合作好像是我谈下来的。我觉得人们没真正理解这有多划算。他们会说：「不可能，这不可能是真的。」是真的。还有另外 18 个产品，lennysproductpass.com，去看看。继续。Kiriti。
太棒了。我其实对生产力很讲究。我一直在试新的 CLI 工具，以及能让我更快的东西。所以我觉得 Raycast 一直很棒。我发现了一堆新快捷键，可以用来打开不同的东西、输入快捷命令之类的。另外 Caffeinate 是我最近从同事那儿发现的。它能防止 Mac 睡眠，这样你可以在本地跑一个长达四五个小时的 Codex 任务，让它把东西建出来，然后你醒来就可以说：「好，这个不错。我喜欢。」
这个组合太好笑了。Codex 加 Caffeinate。你们得用起来，自己做一个 OpenAI 版本，或者 Codex 智能体就该顺便让你的 Mac 不睡眠。太好笑了。顺便说，Raycast 也是 Lenny's product pass 的一部分。一年的 Raycast。厉害。是啊。
Lenny 之前可没跟我们说这些。对。这些其实都是我们最喜欢的产品
这只是 19 个产品里的两个。不过没有 Caffeinate。我都不知道它是不是收费的。好，继续吧。你有没有一句最喜欢的人生格言，在工作或生活里会反复回到它？
对我来说，这是我小时候我爸跟我讲过的一句话，我一直记着：他们跟他说这事做不成，可那傻瓜不知道，所以他还是一路做下去了。我觉得就是要傻到相信自己只要全心投入就能做成任何事，尤其是现在——你手上有那么多数据，随时都能指向「你大概会失败」这个结论。有多少播客能过一千订阅？有多少公司能做到一百万美元 ARR？总能找到数据证明你不会成功，但有时候就是要犯傻，然后往前冲。
说得太好了。是啊。
对我来说，我更是个想太多的人。所以我很喜欢 Steve Jobs 那句话：你只能在回头看的时候把点连起来。很多时候面前有无数个选择，你并不知道哪个是最优的，但生活的方式是，你回头看的时候会发现：「哦，原来这些转折其实挺美的。」所以我觉得这在「继续往前走、继续做实验」这件事上特别有用。
最后一个问题。每次我在播客里同时请两位嘉宾，我都会问这个：你欣赏对方身上的哪一点？
我觉得 Kiriti 这个人特别冷静、特别稳，他一直是我的回音壁。我可以把一大堆想法扔给他，他总能想到、他能预判到可能踩进去的坑。而且他极其善良，习惯让作品说话，而不是自己讲很多。但如果只能选一个，我觉得他是最了不起的丈夫。
揭晓了。大家可都不知道。
我们结婚四年了，是我人生中最美的四年。
哇。好。这怎么接得上？
是啊，这真的很难接。我得说，我特别幸运，能在硅谷和极聪明的人一起、在很棒的公司里工作。而 Aishwarya 让我觉得与众不同的地方——在我合作过的所有聪明人里——是她有一种非常了不起的本事，能把一件事讲得极其易懂、极好理解。这种能力和韧劲结合起来特别有用，尤其是在我们身处的这个快速变化的 AI 世界里：新东西层出不穷，让人感觉招架不住。但当我听她讲「这件事该怎么理解、它接在哪里」的时候，我就会觉得，哦，原来这么简单，我也能做到。所以她通过简化、用最容易懂的方式去解释，赋能了很多人。(01:24:25): 我觉得这是一种了不起的品质。
太好了。真温馨。我得一直做这个环节。我需要更多嘉宾来玩这个。太棒了。好，最后几个问题：大家在哪里能找到你们在做的东西、在网上找到你们，把课程链接也分享一下，然后就是——听众怎样才能帮到你们？
我在 LinkedIn 上写得很多。如果你想听一些在一线摸爬滚打、真正在做 AI 产品的人聊他们看到了什么，可以关注我的内容。我们还有一个大约 2 万 star 的 GitHub 仓库，里面全是学 AI 的好资源，完全免费。如果你喜欢我们今天聊的，我们还有一门超受欢迎的课，讲的是怎么打造企业级 AI 产品，链接会放在下面。这门课很大一部分在讲「卸载旧思维」，以及走问题优先的路子，而不是工具优先、炒作优先。所以也可以去看看。如果你不想上课，我们也写很多东西、发很多免费资源、办免费分享，所以记得关注我们的作品。
对，我也想补充，你也可以在 LinkedIn 上找到我。我写得不多，我猜，但我特别乐意聊你正在做的任何复杂产品。如果你对怎么用 coding agents 让自己的生活更好有想法，或者对你正遇到的问题有想法，我的私信永远开着，我们可以好好聊一聊。
太好了。Kiriti 和 Ash，非常感谢你们来。
非常感谢。
谢谢你 Lenny。这太有意思了。
太有意思了。大家再见。(01:25:58): 非常感谢大家的收听。如果你觉得有价值，可以在 Apple Podcasts、Spotify 或你常用的播客 app 上订阅节目。也请考虑给我们评分或留下评论，这真的能帮其他听众发现这个播客。你可以在 lennyspodcast.com 找到所有往期节目、了解更多关于节目的信息。我们下期见。