昨日，两位来自 OpenAI 及前微软的 AI 产品一线从业者——Aishwarya Naresh Reganti 与 Kiriti Badam，在 Lenny 的播客节目中深入分享了他们在超过 50 个 AI 产品落地项目中的实践经验与教训。
这些经验源于反复的试错与总结。播客主持人 Lenny 提炼出一个核心观点：痛苦是新的护城河。
两位嘉宾均具备深厚的技术与产品背景：
* Kiriti Badam 是 OpenAI Codex 团队的成员，过去十年曾在 Google 和 Kumo 从事 AI 与机器学习基础设施的构建工作。
* Aishwarya Naresh Reganti 曾是 Alexa 和 Microsoft 的早期 AI 研究员，发表过 35 篇以上的研究论文。
他们共同领导和支持了超过 50 个 AI 产品的落地项目，客户覆盖 Amazon、Databricks、OpenAI、Google 等科技巨头，以及初创企业和大型传统企业。
此外，他们还在 Maven 平台联合教授一门 AI 课程，传授构建成功 AI 产品的核心经验，该课程长期位居排行榜首位。
在本期节目中，他们探讨了构建 AI 产品过程中的诸多关键问题，包括 Codex 团队内部的应对策略。
Aishwarya 指出，AI 系统与传统软件系统存在本质差异：AI 系统具有更大的不确定性，并且需要在 AI 的代理能力与人类控制权之间进行权衡——这将从根本上改变系统的构建方式。
两位嘉宾达成共识：构建 AI 代理应从人类控制度最高的场景开始，遵循 “先高控制、低自治，再逐步升级” 的路径。Kiriti 以 OpenAI 的客服支持场景为例，阐述了如何让 AI 逐步替代人工客服。他强调：
“如果你在第一天就尝试把所有能力交给 AI，复杂度一定会失控。”
同时，他们分享了一套名为 “持续校准、持续开发” 的 AI 产品开发工作流框架。该框架展示了 AI 产品开发的全流程，并遵循从“低自治”到“高自治”的渐进演进过程。
评估是近期业界热议的话题。Kiriti 特别强调，AI 产品的评估与生产监控同等重要。
他透露了 Codex 团队内部的评估方法——采用一种平衡策略：既通过系统性评估守住产品底线，也大量收集用户反馈，从而快速发现并修复问题。
最后，他们分享了观察到的 AI 产品公司成功规律：CEO 必须深度参与其中。领导者需要谦逊地放下既有经验，重新学习 AI 知识。
“AI 转型几乎不可能自下而上完成。如果领导者不信任技术，或对 AI 能力有错误预期，工程团队将无法推动真正的落地。”
对于个人如何构建优秀的 AI 产品，他们指出，未来几年 AI 产品的构建成本将持续下降，因此个人需要具备良好的判断力、审美、主动性以及坚持不懈的品质。Kiriti 表示：
“真正的护城河，来自你反复踩坑、反复试错所积累的‘痛苦经验’。”
此外，Kiriti 表示看好 2026 年能够接入生产工作流的主动式、后台型 Agent，并透露他们也可能构建类似产品。
AI系统与传统软件系统的差异：不确定性、AI代理与人类控制的权衡
Lenny：
你亲手打造过不少 AI 产品，也深度参与和观察过许多公司的 AI 产品构建过程——其中有成功的，也有在 AI 产品和 AI 代理上不断踩坑、反复受挫的。同时，你还在教授一门关于如何成功构建 AI 产品的课程。
我想先问一个宏观问题：你现在在企业一线看到的真实情况是什么？哪些事情进展得不错？又有哪些地方依然做得不太好？
Aishwarya：
如果要总结一句话，我会说：2025 年和 2024 年已经有了非常明显的不同。
首先，整体的怀疑和观望情绪大幅下降。去年，许多公司高管仍认为 AI 可能只是“下一波加密货币式的浪潮”，因此对是否投入持高度怀疑态度。那时我看到的很多所谓 AI 用例，本质上只是“把一个聊天界面贴到自己的数据上”，然后便宣称是 AI 产品。
但今年情况不同了。大量公司开始真正反思自己的用户体验和内部工作流程，并逐渐意识到：要构建成功的 AI 产品，必须先拆解现有流程，再重新构建。这是非常积极的变化。
当然，挑战依然存在。最大的问题在于：执行层面依旧非常混乱。
可以这样理解：这是一个仅有三年历史的领域，没有成熟的操作手册，也没有教科书，所有人都在边做边学。而且，AI 的产品生命周期，无论是上线前还是上线后，都与传统软件的生命周期截然不同。
这直接打破了许多传统角色之间既有的分工和“交接契约”，例如产品经理、工程师、数据团队之间原本清晰的边界。现在，大家不得不适应一种全新的协作方式：共同拥有同一个反馈回路。
过去，PM、工程师、数据人员各自优化各自的指标；而现在，可能需要大家坐在同一个房间里，一起查看代理的执行轨迹，共同讨论产品在特定情况下“应该如何表现”。这是一种全新的协作形态，而很多公司仍在摸索如何适应——这是我今年在咨询实践中看到的真实状态。
Lenny：
我们几个月前合作撰写过一篇客座文章，其中让我印象最深刻、至今仍记得的一个核心洞察是：构建 AI 产品，与构建非 AI 产品，本质上是不同的。
而你一直反复强调，这种不同主要体现在两个关键点上。能否系统地阐述一下这两个差异？
Aishwarya：
当然。不过我想先强调一点：构建 AI 系统和构建传统软件系统之间，确实存在大量相似之处。但与此同时，也有一些差异会从根本上改变你构建系统的方式。
第一个根本差异是：非确定性。
在传统软件中，你面对的是一个高度确定性的系统：决策引擎、工作流都被清晰定义和映射。
例如，在 Booking.com 上预订酒店。你有一个明确的意图：在旧金山订两晚酒店。整个产品流程就是围绕如何将你的意图，通过点击按钮、填写表单、筛选选项等一系列确定操作，最终完成预订。这是一个高度可预测、结构化的过程。
但在 AI 产品中，这一层被一种极其“流动”的界面（主要是自然语言）所取代。这意味着：用户表达同一个意图，可能有无数种方式。
这在输入端带来了巨大的不确定性——你无法预知用户将如何与产品交互。而在输出端，你调用的又是一个非确定性的 API（大模型）。LLM 对提示词的措辞极其敏感，其本身又是“黑箱”，你甚至无法预先知道其输出空间的具体形态。
于是，你现在面对的是一个你并不完全理解的输入、一个你并不完全理解的输出，以及一个你同样不完全理解的过程。你只能试图预测行为，并围绕这种不确定性来设计系统。在代理系统中，这种复杂性会进一步放大。
这就引出了第二个根本差异：代理能力与控制权之间的权衡。
许多人极度热衷于构建高度自治的系统，希望 AI 代理能够“替你做事”。但问题在于：每一次你将决策权交给代理，就意味着你放弃了一部分控制权。
因此，你必须确保这个系统已经“赢得”了这种自主权——它是否足够可靠、是否值得信任。这正是我们所说的 “代理-控制权衡” ：你赋予 AI 的决策能力越多，就越需要确信它配得上这份信任。
就像你说的，去 Booking.com，每次体验大体一致，但 AI 产品不是这样。用户输入不可预测，输出也不可重复。再加上你还要在“AI 做多少”和“人类做多少”之间做权衡。
而真正的关键信息在于：这会彻底改变你构建产品的方式。接下来我们会聊这些变化如何影响产品开发生命周期。在此之前，你还有什么想补充的吗？
Kiriti：
是的，我觉得一个非常关键的前提是：你必须在认知上真正建立起这种区分。
打个比方，如果你的目标是攀登优胜美地的 Half Dome，你不会第一天就直接去爬。你会从低强度训练开始，逐步提升，最终完成目标。
构建 AI 产品也是一样。你不应该在第一天就试图构建一个拥有公司所有工具、所有上下文、完全自治的 agent，并期待它能正常工作。相反，你需要刻意从影响范围最小、人类控制最多的场景开始 。
这样你才能真正理解当前能力的边界，知道 AI 现在能解决什么问题、不能解决什么问题，然后再逐步增加 agent 的自主性、上下文和工具能力。
这既是好事，也是坏事。好的一面是，你不需要一开始就面对所有“超级 agent”的复杂性；坏的一面是，如果你试图一步到位，复杂度会立刻失控。
但在实践中我们反复看到一个模式：几乎所有成功的团队，都是从极简结构开始，然后不断演进的。
Lenny：
那我们就顺着这个思路继续。你们反复强调：先高控制、低自治，再逐步升级。能不能给我们一个具体的例子，说明这种“循序渐进”的路径？
Kiriti：
一个非常典型的例子是客户支持。想象一家拥有大量客服工单的公司——其实 OpenAI 自己就是这样，在发布 Image、GPT-5 这类产品时，客服请求量会出现巨大峰值。
一开始，你并不是把所有帮助中心文档直接丢给一个 AI agent。第一步往往是：AI 给人工客服提供建议 ，告诉他们“我认为应该这样回复”。
人工客服会对这些建议进行反馈：哪些是好的，哪些是错误的。你由此发现系统的盲点，并持续修正。当你对系统表现足够有信心之后，才可以升级为让 AI 直接回复用户。
再往后，你可以逐步增加能力，比如自动退款、提交功能请求、触发更多系统操作。如果你在第一天就尝试把所有能力交给 AI，复杂度几乎一定会失控。所以我们的建议始终是：一步一步来，逐级提升自治能力。
Lenny：
我来复述一下你的意思：从一开始的“高控制、低自治”，到逐步增加 agent 的决策能力、减少人类干预，前提始终是你已经对它的行为建立了足够信心。
Aishwarya：
从更高层来看，这其实是一个行为校准的问题。你几乎不可能在一开始就准确预测系统的行为，所以正确的做法不是破坏现有用户体验，而是在保持体验稳定的前提下，逐步减少人类控制。
没有唯一正确的路径，你可以用多种方式来约束 agent 的自主性。
比如在医疗保险的预授权场景中：某些低风险项目（如血检、MRI）可以交给 AI 自动处理；但高风险项目（如侵入性手术）就必须保留人工介入。整个过程中，你还会记录人类的决策行为，用来构建持续改进系统的反馈飞轮。
这样既不破坏用户体验，也不侵蚀信任，同时还能不断提升系统能力。
Lenny：
我再补充几个你们在文章中提到的例子。比如编码助手：
V1只是给出补全和样板代码；V2是生成测试或重构建议供人审查；V3才是自动应用修改并提交 PR。
再比如营销助手：从写文案，到运行多步骤活动，再到自动测试和跨渠道优化。
总结一下目前为止的建议：AI 产品是非确定性的——不仅在输出端，在输入端也是如此。这既是挑战，也是机会。
Aishwarya：
没错，这其实也是 AI 最迷人的地方。人类更擅长“说话”，而不是点按钮。但问题在于，你最终还是要在一个确定性的系统中，借助非确定性的技术，达成确定性的结果，这正是复杂性的来源。
Kiriti：
而现实中，很多团队的问题在于：他们在还没建立信心之前，就试图直接跳到 V3。
当 agent 在一百个地方出错时，你几乎不可能从那个阶段回头修正。
相反，从高控制、低自治的最小版本开始，不仅更安全，也会迫使你真正思考：我到底在解决什么问题？这正是我们反复强调的 “problem-first” 思维。
这也是为什么，这种渐进式构建模式，会一次又一次在不同团队中被验证有效。
Lenny：
限制 AI 的自主性其实有很多现实层面的好处。一个很直接的原因是：一旦系统“替你做得太多”，风险就会急剧放大。它可能会改乱你的数据库，或者发出一堆你完全没预期的邮件。类似这样的事故场景非常多，所以从工程和产品角度来看，限制自主性本身就是一个非常合理、甚至必要的选择。
Aishwarya：
我最近读了一篇 UC Berkeley 团队的论文，作者包括 Mae Aha Ion Steer 以及 Databricks 的一些研究者。论文提到，他们访谈的企业中，大约 74%～75% 最大的问题是“可靠性” 。
这也是为什么很多企业并不敢把 AI 产品真正推向终端用户，或者做成面向客户的产品——他们并不确定系统是否足够稳定，也不愿意让用户暴露在这些潜在风险之下。
这同样解释了为什么当下大量 AI 产品集中在“生产力提升”上，而不是高自主性的系统或直接替代完整工作流的应用。低自主性显然更可控。我个人也非常认可这篇研究的结论，而且这和我们在自己创业公司里看到的情况高度一致。
Lenny：
很有意思。在这次对话之前，我们会先上线一期节目，深入讨论另一个“低自主性”间接规避的问题：提示词注入和越狱 。
这对 AI 产品来说是一个非常严重的风险，甚至可能是一个尚未解决、也可能根本无法彻底解决的问题。
Aishwarya：
我认为，一旦这些系统真正走向主流，这会成为一个巨大的问题。现在大家都忙着把 AI 产品做出来，几乎还顾不上安全性，但未来这一定会“反噬”。
尤其是在这种“非 street-legal API”的场景下，也就是模型行为本身不可完全约束，你其实是被卡住的。因为你可以在 prompt 里注入无数指令，结果几乎注定会失控，后果会非常糟糕。
Lenny：
我其实很想在这里多停留一会儿，因为这件事真的非常有意思，而且几乎没人公开讨论。
现实是：让 AI 去做它不该做的事情，其实非常容易 。虽然大家都在加各种 guardrails，但事实证明这些护栏并不牢靠，总能被绕过去。
而且正如你说的，当 agent 变得更自主，甚至进入机器人形态之后，这件事就会变得非常可怕——你真的有可能诱导 AI 去做一些绝对不该发生的事情。
Kiriti：
我同意这是一个真实存在的问题。但从当前企业和客户采用 AI 的整体阶段来看，大多数公司其实还没有真正充分利用 AI，距离“深度重塑流程”也还有不小的距离。
我们仍然处在非常早期的阶段。2025 年对 AI agents 来说确实异常忙碌，很多客户都在尝试落地，但整体渗透率还远不足以让大多数公司获得决定性的竞争优势。
在这种情况下，只要在关键节点引入合适的 human-in-the-loop ，我认为是可以规避相当一部分风险的。
相比一味强调“可能会出什么问题”，我个人更偏向乐观的一方：企业应该先尝试采用 AI。几乎我接触过的每一家公司，都会发现至少有一组流程是 AI 能够优化的，然后才是思考“我该如何把它真正用起来”。
AI产品公司成功的规律：CEO必须深度参与其中
Lenny：
我想再问一个问题：你们观察到，那些真正把 AI 产品做成功的公司和团队，有哪些共通的工作方式？以及，最常见的坑又是什么？
Aishwarya：
我通常将成功理解为一个由三个维度构成的“三角形”：领导力、组织文化和技术能力。几乎不存在“纯技术问题”，每一个技术问题，本质上首先都是人的问题。
首先是领导力。在为众多公司提供AI转型与战略培训时，我观察到一个普遍现象：许多领导者依赖的是过去10到15年积累的直觉，这些直觉曾是他们的成功基石。但在AI时代，这些直觉必须被重新学习。领导者需要足够的谦逊，甚至敢于承认“我可能不再是对的”。
我曾与Rackspace的CEO共事。他每天清晨4点到6点会预留一个名为“Catch up with AI”的时段，不安排任何会议，专门用于收听最新的AI播客、跟进研究进展，周末还会组织白板讨论。我认为领导者需要重新变得“亲力亲为”——并非亲自写代码，而是重建自己的直觉体系，接受“我的判断可能已经过时”这一事实。
你甚至应该假设自己可能是会议室里最不懂AI的人，并主动向所有人学习。这一点往往是成功公司的显著特征。AI转型几乎不可能自下而上完成，如果领导者不信任技术或对AI能力有错误预期，工程团队将无法推动真正的落地。
第二个维度是文化。我接触的许多企业，其核心业务并非AI，但因竞争对手采用或存在明确的投资回报率场景，他们不得不引入AI。然而，过程中许多公司会形成一种“错失恐惧（FOMO）+ 被取代恐惧”的文化。结果是，真正关键的领域专家不愿参与，因为他们担心自己的工作被替代。这本质上仍是领导层的问题。
你真正需要的是一种“赋能型文化”：将AI视为对现有工作流的增强，而非威胁。不是告诉员工“不学AI就会被淘汰”，而是告诉他们“AI可以将你原本的工作放大10倍”。当整个组织站在同一边时，AI才能真正为公司服务。
第三个维度才是技术。本质上，成功的团队都对自己的工作流理解得极其深入，非常清楚哪些环节适合用AI，哪些地方必须有人参与。不存在“一个AI智能体解决一切”的情况。你一定是模型 + 确定性代码 + 人类的组合。关键不是迷信技术，而是选对工具。
今天的竞争重点，已不再是“谁第一个上线智能体”，而是谁能构建一个可以持续学习和迭代的飞轮。
如果有人告诉我：“我们有一个一键智能体，接入两三天就能看到显著收益”，我几乎可以肯定这是营销话术。问题往往不在于模型不够强，而在于企业的数据、系统和分类体系过于混乱，技术债务太多。真正能产生可观投资回报率的系统，即使在最理想的条件下，通常也需要4到6个月。
Lenny：
非常精彩。这与我在播客中听到的许多观点高度一致。一个公司要真正从AI中获得巨大价值，CEO必须深度参与其中。Dan Shipper曾指出，他观察到的最强成功信号，是CEO每天多次使用ChatGPT、Claude等工具。你刚才提到的Rackspace CEO的例子也非常典型。
AI产品的评估与生产监控同样重要
Lenny：
那我换个话题。这是一个曾在Twitter上引发广泛讨论的问题：评估。有些人非常着迷于评估，认为它几乎是解决AI各类问题的答案；但另一派人则认为评估被严重高估了，认为你不需要评估，仅凭感觉将产品推向用户也能做得不错。你怎么看待评估？在解决你刚才提到的那些问题时，评估到底能起到多大作用？
Kiriti：
从整个社区的讨论来看，我认为目前存在一种错误的二分法：要么认为评估能解决一切问题；要么认为线上监控或生产环境监控才是万能的。
如果我们退一步看，评估到底是什么？ 本质上，它是你对产品的理解、你对“什么是重要的”的判断，被编码进了一组数据集中。例如：哪些行为是我的智能体绝对不能做的？哪些失败是不可接受的？那我就围绕这些关键点构建评测数据集，确保系统在这些问题上表现稳定。
而在生产监控这件事上，你做的是另一件事：将应用真正部署出去，通过一组关键指标持续接收用户如何使用产品的反馈。例如，你上线了一个智能体，如果用户在某次交互后点了“赞”，你显然希望知道这件事。这正是生产监控的价值所在。其实生产监控在传统软件中早已存在，只是到了AI智能体时代，你需要监控的粒度变得更细、更复杂。
而且，反馈并不总是显性的。你还能获得大量隐性反馈。以ChatGPT为例，用户如果喜欢一个回答，可以点“赞”；但如果不满意，很多时候他们不会点“踩”，而是直接重新生成一次答案。这本身就是一个非常明确的信号：说明第一次生成的结果未达预期。这些隐性信号，正是生产监控中你必须持续思考和捕捉的内容，而且这个信号谱系还在不断扩展。
所以回到最初的问题：到底是评估重要，还是生产监控重要？这个问题本身其实并不关键。
真正关键的是，你到底在构建什么？你想给用户一个可靠的应用，它不会做出明显错误的事情；即便真的做错了，你也能非常快地收到告警并介入。从这个目标出发，我通常会把问题拆成两部分。
第一部分是：在你部署任何应用之前，一定会先做测试。这个测试可以很简单，比如“有10个问题是无论我怎么改系统，它都不应该答错的”。那你就把这些问题整理成一个数据集，我们可以称之为一个评测数据集。你先用它做验证，然后把系统部署上线，接下来才进入第二阶段。
如果你的系统是高吞吐、高交易量的应用，你不可能人工检查每一条交互记录。你需要一些信号来告诉你哪些交互值得关注。这正是生产监控的价值所在：你无法提前预测智能体会以什么样的节奏、在什么地方出错，但各种显性和隐性的用户信号，会不断告诉你哪些记录值得你回头仔细分析。
当你拿到这些记录后，接下来要做的是分析：不同交互中出现了哪些失败模式？有没有某些你特别在意、绝对不应该发生的行为？如果发现某类失败模式频繁出现，那你就应该为它专门构建一个评测数据集。例如，你发现智能体开始主动提出退款建议，而这在设计上是被明确禁止的，那你就围绕这一点构建评测集，修改工具或提示词，再部署新版本。
但即便如此，也无法保证这就是你会遇到的最后一种问题。你仍然需要生产监控来捕捉未来可能出现的其他问题。所以在我看来，评估很重要，生产监控同样重要；但“只靠其中一个就能解决所有问题”的想法，是完全站不住脚的。
Lenny：
这是一个非常理性且成熟的回答。重点并不只是“两个都要做”，而是它们各自能捕捉到不同类型的问题，任何一种方法都无法覆盖全部风险。
Aishwarya：
我想再退一步，聊聊为什么在2025年下半年，“评估”这个词突然背负了如此大的语义负担。你去和一家数据标注公司聊，他们会说“我们的专家在写评估”；你又会听到一些人说，产品经理应该写评估，他们是新时代的产品需求文档撰写者；还有人直接说，评估就是一切，是你用来改进产品的完整反馈闭环。
如果你是一个刚入门的人，很容易感到困惑：什么是评估？为什么所有人都在说评估？ 实际上，这些人谈论的往往是流程中的不同部分。大家并不一定是错的，但当数据标注公司说“专家在写评估”时，他们往往指的是错误分析，或者专家在标注什么是对的、什么是错的。律师和医生当然可以做出这些判断，但这并不意味着他们在构建一个完整的LLM评判器，或者一个可用于生产的反馈闭环。同样，产品经理写评估，也不意味着他们要写出一个可以直接上线的LLM评判器。而且你事先根本无法确定：到底该不该构建一个评判器，还是应该更多依赖生产环境中的隐性信号。
Martin Fowler：
如果你把一群真正的实践者拉到一起问：“为 AI 产品建立一个可执行的反馈闭环重不重要？”
我相信所有人都会说重要。只是具体怎么做，完全取决于你的应用本身。
在复杂场景下，构建 LLM judge 是极其困难的。你可能为某个维度（比如冗长程度）做了一个 judge，但很快就会发现新的失败模式出现，而你的 judge 完全捕捉不到。最后的结果往往是：你不断地堆评测，却并没有真正解决问题。
在这种情况下，反而更合理的做法是：关注用户信号，修复问题，检查是否出现回退，然后继续往前走。
所以，还是那句话：一切取决于具体场景。
Lenny：
这一点真的非常重要。现在评估对不同人来说意味着完全不同的东西：有些人指的是数据标注公司给你的东西，有些人指的是 PM 在做的事情，还有一些人把 benchmark 也算作评估。这让“讨论评估本身”变得越来越困难。
Aishwarya：
我最近就遇到一个客户跟我说：“我们在做评估。”
我问他们：“那你们的数据集能给我看看吗？”
他们回答说：“没有数据集，我们只是看了一下 LM Arena 和 Artificial Analysis 的榜单，确认这个模型适合我们的用例。”
我当时就说：那你们不是在做评估，你们只是在选模型。
Codex是如何做评估的
Lenny：
这个词当然可以被那样使用，但确实只会让事情变得更混乱。也正因为如此，评估才会成为一个争论点。比如 Claude Code 的负责人 Boris 就公开说过：他们不做评估，全靠 vibes。
那你们 Codex 团队是怎么做评估的？
Kiriti：
在 Codex，我们采取的是一种平衡式的方法：评估很重要，但倾听用户同样重要。
Coding agent 和其他领域的 agent 非常不一样，因为它本身就是为工程师、为高度可定制化而设计的。它不是只解决“前五个工作流”的产品，而是会被嵌入到各种工具、各种集成里。
这也意味着，你几乎不可能为用户的所有使用方式构建一个完整的评估数据集。但与此同时，你至少要保证：当你做出一个改动时，它不会破坏产品最核心的能力。
所以我们确实有评估来守住这些底线；同时，我们也会非常仔细地观察用户是如何使用产品的。
比如我们最近推出的代码审查功能，增长非常快，很多 OpenAI 内部以及外部用户的 bug 都是通过它被发现的。
如果我们对模型或训练方式做了改动，并准备部署新版本，我们一定会做 A/B 测试，确认它是否还能找出正确的问题，用户的反应如何。
有时候，如果代码审查结果不准，用户甚至会直接关掉这个功能。这些行为本身，就是你必须高度重视的信号。
而这些场景，事前几乎不可能完全靠评测预先覆盖。
所以现实情况是：既有评估，也有大量来自用户的反馈，还有一定程度的“直觉判断”。我们也会非常活跃地关注社交媒体，快速发现问题并修复。
这不是某一个单一动作，而是一整套你在这个领域里持续要做的事情。
Lenny：
这听起来非常合理。我的理解是：Codex 有评估，但它们远远不够；你们同时密切关注用户行为、用户反馈，甚至也会问一个“vibes”的问题——作为用户用起来是不是爽？生成的代码是不是让人兴奋？
Kiriti：
如果有人觉得：“我有一套评估，可以完全依赖它，其他什么都不用管”，那基本是行不通的。
每次我们要上线一个新模型，团队都会一起测试，每个人关注的点都不一样。我们会拿一组公认的“难题”去试模型，看看它在这个新世界里到底表现如何。
某种程度上，这是每个工程师自己的定制评估，用来重新理解产品在新模型下的行为。
AI产品开发工作流：“持续校准、持续开发”框架
Lenny：
你在课程里教授了一套 AI 产品开发工作流——那套把评测、监控、用户反馈全部串起来的、一步步构建 AI 产品的方法论。你把它称为“持续校准、持续开发框架”。
我们不妨拉一张图出来，带大家完整走一遍：它是什么？怎么运作？团队如何通过这种方式，改变构建 AI 产品的方式，从而避免大量不必要的痛苦和试错。
Aishwarya：
在解释整个生命周期之前，我想先讲一个我们为什么提出这个框架的小故事。
我和 Kiriti 在和大量公司交流时，反复看到一种压力：“竞争对手都在做全自动 agent，我们是不是也该这么做？”
我确实和一些客户一起，从零搭建过端到端、完全自治的智能体。但问题很快暴露出来了——在一开始，你并不知道用户会如何与系统交互，也无法预判 AI 会生成什么样的响应或采取什么行动。当一个工作流包含四五个步骤、需要做出大量决策时，一旦出现问题，几乎只能不停地 debug、热修复。
我们甚至有过这样的经历：原本是为客服场景构建的 agent，但因为热修复太多、问题不断涌现，最后只能直接下线产品。你根本无法穷举所有正在出现的新问题。
最近网上也有不少类似的新闻，比如 Air Canada 的案例：他们的一个客服 agent“编造”了一条退款政策，这并不在官方规则里，但因为法律原因，公司最后不得不认账。类似的事故其实相当可怕。
这正是我们提出这个方法的出发点：你如何在不损害用户信任的前提下构建 AI 系统？如何避免 agent 做出对公司本身极其危险的决策？同时，又能建立一个持续进化的飞轮，让产品不断变好？
基于这些教训，我们提出了“持续校准+ 持续开发”这个框架。
这个思路本身并不复杂。循环右侧是持续开发：你首先需要明确能力边界、整理数据，也就是构建一个数据集，清楚地定义“什么是预期输入”“什么是正确输出”。这是任何 AI 产品启动前都非常关键的一步，因为很多时候你会发现，团队内部对“产品应该如何表现”本身就并未对齐。这正是 PM 和领域专家能发挥巨大价值的地方。
在此基础上，你搭建应用，并设计合适的评估指标。我这里刻意强调“评估指标”，而不是笼统地说 evals，因为评估是一整个过程，而指标只是你在过程中关注的维度。然后，你基于这些指标去部署、运行、观察结果。
循环的另一半是持续校准。
一旦产品上线，你很快会意识到：用户的行为方式往往超出最初的设想。最开始用于优化的数据集，几乎一定是不完整的。
评估指标可以帮助你发现一部分问题，但你也会发现，有些新模式、新错误，根本不在你原来的指标覆盖范围内。
这时你需要做的，是分析行为、识别错误模式，对明显问题进行修复；同时，判断哪些新的问题值得被系统性地纳入评估体系。当然，并不是所有错误都需要回到“设计新 eval”这一步。有些只是一次性的工程问题，比如工具调用配置错误，修掉即可，没必要反复评估。
这基本就是一个 AI 产品应有的生命周期。
但我们还特别强调一点：在早期，尽量采用“低自治、高控制”的版本；随着理解加深，再逐步提高 agent 的自治程度。
也就是说，一开始要限制 AI 能做出的决策数量，并始终保持人类在环；当你逐渐理解用户行为、积累足够信号后，再慢慢放权。
在 newsletter 里，我们用客服系统作为示例，把“自治程度”和“控制强度”当作两个维度，展示不同版本的演进路径。
第一阶段是路由：只负责把工单分类并分发到正确的部门。很多人会觉得，路由听起来很简单，但在企业环境中，这往往是个极其复杂的问题。
大型零售企业通常有层级混乱、历史包袱极重的分类体系，这些问题往往只有在你真正开始构建系统时才会暴露出来。
在路由阶段，即使智能体分错了部门，人类也可以快速介入纠正，这是一种高控制、低风险的模式。
当路由稳定运行、数据问题被逐步修复后，便可进入第二阶段：Copilot。即让智能体基于标准作业程序生成处理建议或回复草稿，由人工编辑后发出。
这个阶段至关重要，因为你无形中获得了“免费”的错误分析：你可以观察人类修改了哪些内容、删除了哪些建议，这些行为本身就是极高价值的反馈信号。
当你发现大多数草稿几乎无需修改，人工可以直接采纳时，才适合进入第三阶段：端到端的处理辅助。此时智能体不仅能生成回复，还能协助完成问题关闭。
这是一个从低自治到高自治的渐进过程。
我们还整理了一张表格，明确了每个阶段的目标、收获以及可以反馈到循环中的信息。
例如在路由阶段，你获得的是更高质量的路由数据、对提示词和上下文工程的理解，这些都将成为后续演进的基础。
需要强调两点：
第一，采用这个框架并不意味着问题被“一劳永逸”地解决。即便已进入第三阶段，也可能遇到全新的数据分布和未知行为。但至少，你是在更低风险的前提下逐步逼近自治。
第二，这本质上是在构建一种隐式日志系统。评估指标只能捕捉你已意识到的错误，而真正危险的，往往是上线后才显现的新模式。
最后，这不是唯一的路径。你可以按“决策数量”来限制自治，也可以按“业务主题”区分高风险与低风险领域。关键不在于形式，而在于：让产品经理、工程师和领域专家对风险、控制和演进路径形成共识，在不失去用户信任的前提下持续校准系统行为。
Lenny：
我特别喜欢的一点是：你们强调这是一个持续、渐进式的过程——逐步提高自治、逐步降低控制。这也是“持续校准、持续开发”这个名字的含义，本身就是对 CI/CD 理念的一种致敬。关于这个框架，你觉得还有什么是大家必须知道的？
Aishwarya：
我们最常被问到的一个问题是：我怎么知道自己是否应该进入下一个阶段？当前系统算“校准到位”了吗？
坦率地说，这里没有一本可以照搬的“规则手册”。核心原则只有一个：尽量减少“意外”。
举个例子，如果你每一到两天进行一次校准，却发现系统没有出现新的数据分布变化，用户使用方式也相当稳定，那么你实际上已获取不到太多新增信息。当信息增量变得很低时，往往就是可以进入下一阶段的信号。
那时，更多是一种直觉判断：你是否“感觉”已经准备好了？你是否已不再从当前阶段获得新的认知？
但同时也要意识到：有些外部事件可能会直接打破你原有的校准状态。
例如 GPT-4o 的下线及相关 API 的弃用。许多原本基于 GPT-4 的公司被迫迁移到 GPT-5，而新模型的特性完全不同。这种情况下，之前所有的校准结论基本都需要重来。
此外，用户行为本身也会随时间演变。
你今天与 ChatGPT 的交互方式，和两年前已完全不同。一方面是模型能力变强了，另一方面是用户在“学会”系统后，会不断尝试将其用于新的任务。
我们曾为银行的核保人员构建过一个系统。核保工作本身非常繁琐，贷款申请文件往往长达三四十页。该系统的目标是帮助核保人员快速查找相关政策和银行规则，从而更高效地审批贷款。
在最初的三四个月里，所有人都对这个系统非常满意。核保人员明确反馈，他们的工作时间大幅减少、效率显著提升。
但后来我们意识到一个问题：正是因为他们太喜欢这个系统了，开始向它提出一些我们完全没有预料到的“深度问题”。
他们会直接把整份贷款申请丢进系统，然后问：“像这样的案例，以前的核保人员是怎么处理的？”
从用户角度看，这只是个非常自然的延伸问题；但从产品和工程角度看，事情立刻复杂了几个数量级。
“像这样的案例”究竟指什么？是收入区间相似？地理位置相似？还是家庭结构相似？
你需要理解问题的语义，回溯历史文档、分析大量旧案例，才能给出合理答案。这已完全超出了“查政策”的范畴。
这正是用户行为不断演化，而系统必须随之重新校准的典型例子。
Lenny：
你觉得现在 AI 领域里，什么是被高估的？更重要的是，什么是被低估的？
Kirit：
我整体对 AI 的发展非常乐观，所以与其说“被高估”，我更愿意说是被误解。其中一个典型例子就是多智能体系统。
很多人认为：我有一个复杂问题，那就把它拆分成多个子任务——你是这个智能体，负责这块；你是那个智能体，负责那块；只要把它们连在一起，就会形成一个“智能体乌托邦”。
现实几乎从来不是这样。确实存在非常成功的多智能体系统，但关键不在“拆分”，而在于你如何限制系统偏离轨道的空间。
例如，“监督式智能体 + 子智能体”的结构就是一个非常成熟、有效的模式。但那种纯粹按功能拆分、再指望智能体之间通过某种“点对点协作协议”自动协同的想法，在当前模型能力和工程现实下，是被严重高估和误解的。
相反，我认为代码智能体仍然被低估了。
你在社交媒体上能看到很多相关讨论，但如果你去和湾区以外的普通工程团队交流，会发现它们真正产生的影响力和渗透率还非常低。
我认为 2025–2026 年将是全面优化软件工程流程的黄金时期，而编码智能体会在其中创造巨大价值。
Lenny：
这点很有意思。你的意思是，比起一堆各司其职、彼此协作的智能体，更有效的方式是：一个更大的智能体，自己负责拆分和调度子任务？
Kirit：
没错。你当然可以由人类来编排多个智能体，或者由一个更大的智能体做整体调度；但让智能体之间进行完全的点对点通信，尤其是在客服这类高风险场景中，几乎不可控。你很难保证最终是“哪个智能体”在对用户说话，也很难维护一致的安全边界和护栏。
Lenny：
从产品角度看，你们觉得未来一年 AI 会走向哪里？如果看向 2026 年底，会是什么样？
Kirit：
我非常看好后台型、主动式智能体。
目前 AI 难以创造更大价值的核心原因在于：它并不真正理解你的工作上下文，而这往往是因为它没有嵌入到“真正发生工作的地方”。
一旦智能体被深度接入工作流，理解你优化的指标、你的目标任务，它就可以开始主动行动、反向提示你。例如：每天早上告诉你，“我已经修复了 5 个线性问题，这是补丁，你只需要审核。”
我认为这是 2026 年一个非常重要的发展方向，我们也打算构建类似产品。
Lenny：
也就是说，智能体会开始“走在你前面”，提前帮你解决问题。这听起来确实非常震撼。
Aishwarya：
我个人非常看好多模态、模型驱动的未来。
人类本身就是多模态生物，而语言其实是我们比较晚才进化出来的一种表达方式。我们在对话中不断接收视觉、语气、停顿等信号，而这些丰富的表达维度，目前还远没有被充分利用。
如果多模态理解能力进一步提升，我们不仅能更接近真实的人类对话，还能解锁大量“无聊但重要”的工作，比如手写文档、杂乱 PDF 的理解——这些地方蕴藏着巨量尚未被 AI 利用的数据。
构建AI产品的重要能力：审美、主动性和坚持
Lenny：
我刚看到 Google DeepMind 的 Demis 也在谈类似方向，结合视觉模型、语言模型和世界模型。这会是一个非常疯狂的时代。
最后一个问题：如果一个人想变得更擅长构建 AI 产品，你们觉得最重要的一两项能力是什么？
Aishwarya：
如果站在更高的层面看，未来几年实现成本会持续下降 。真正重要的，是你的设计能力、判断力和审美 。
职业早期，我们往往专注于执行技巧；但当 AI 能大幅压缩执行成本后，真正拉开差距的，是你“为什么这么做”的判断力。
我们最近招了一个新人。他直接带着自己写的白标工具来开会，把我们整个团队 onboarding 进他的系统。那一刻我非常震惊——不是因为技术多复杂，而是那种主动性和所有权意识 。
Kiriti：
我想补充一点：坚持 。今天的信息前所未有地触手可及，但真正的护城河，来自你反复踩坑、反复试错所积累的“痛苦经验”。
我常说一句话：“痛苦，是新的护城河。”
成功的公司，并不是因为它们最先做某件事，而是因为它们真正理解了那些不明显的权衡，并在反复失败中形成了独特的认知。这些痛苦，最终会沉淀成组织或个人的能力壁垒。
Aishwarya：
最后想留给大家一句话：痴迷你的客户，痴迷你的问题。
真正优秀的 AI 产品团队，80% 的时间都在理解工作流、理解数据、理解用户行为，而不是在追逐最炫的模型。
Lenny：
说得太好了。AI 不是答案，它只是解决问题的工具。
参考链接：
https://www.youtube.com/watch?v=z7T1pCxgvlA&list=PL2fLjt2dG0N6unOOF3nHWYGcJJIQR1NKm
关注“鲸栖”小程序，掌握最新AI资讯
本文来自网络搜集，不代表鲸林向海立场，如有侵权，联系删除。转载请注明出处：http://www.itsolotime.com/archives/17642