为什么 AI 评估是产品建设者最炙手可热的新技能 | Hamel Husain 和 Shreya Shankar（排名第一的评估课程创作者）

Hamel+Shreya 2025-09-25

为什么 AI 评估是产品建设者最炙手可热的新技能 | Hamel Husain 和 Shreya Shankar（排名第一的评估课程创作者）

关于评估（evals）

Lenny Rachitsky： 要构建出色的 AI 产品，你必须非常擅长构建评估。这是你能从事的投资回报率最高的活动。

Hamel Husain： 这个过程非常有趣，每个做过的人都会立刻上瘾。在构建 AI 应用时，你会学到很多东西。

Lenny Rachitsky： 厉害的地方在于，你不需要反复做很多次。对大多数产品来说，你做一次这个过程，然后就可以在此基础上继续构建。

Shreya Shankar： 目标不是把评估做到完美，而是切实改进你的产品。

Lenny Rachitsky： 我没想到围绕评估有这么多争议和风波，很多人持有非常强烈的观点。

Shreya Shankar： 人们过去在评估上吃过亏——做过糟糕的评估，然后就不信任它了，接着就说”我反对评估”。

Lenny Rachitsky： 人们对评估最常见的几个误解是什么？

Hamel Husain： 排第一的是，“我们生活在 AI 时代，难道不能让 AI 自己来评估吗？“但这行不通。

Lenny Rachitsky： 你在文章中用过一个非常吸引人的概念——“仁慈的独裁者”（benevolent dictator）。

Hamel Husain： 在做开放编码（open coding）的时候，很多团队会被委员会式的决策拖住。在很多情况下，这完全没必要。你不希望把这个过程弄得太昂贵以至于无法执行。你可以指定一个你信任其品味的人，这应该是有领域专业知识的人，通常来说就是产品经理。

今天的嘉宾：Hamel Husain 与 Shreya Shankar

Lenny Rachitsky： 今天的嘉宾是 Hamel Husain 和 Shreya Shankar。过去一年里，这个播客最热门的话题之一就是评估的兴起。Anthropic 和 OpenAI 的首席产品官都表示，评估正在成为产品构建者最重要的新技能。从那以后，这成了我邀请的众多顶级 AI 构建者口中反复出现的主题。两年前，我从未听说过评估这个词。现在它不断出现。上一次出现产品构建者必须掌握才能成功的新技能，是什么时候的事了？

Hamel 和 Shreya 在将评估从一个冷门、神秘的议题转变为 AI 产品构建者最必要的技能之一这件事上，发挥了重要作用。他们教授关于评估的权威在线课程，恰好也是 Maven 平台上排名第一的课程。他们已经教授了超过 2000 名产品经理和工程师，覆盖 500 家公司，包括 OpenAI 和 Anthropic 的大量团队成员，以及其他所有主要 AI 实验室。

在这次对话中，我们做了很多实操演示而非纸上谈兵。我们走了一遍开发有效评估的流程，解释了评估到底是什么、长什么样，讨论了围绕评估的许多主要误解，给了你开始为产品构建评估的前几个步骤，还分享了 Hamel 和 Shreya 过去几年积累的大量最佳实践。这期节目是你能找到的关于评估世界最深入同时又最易懂的入门指南。说实话，它让我都兴奋地想写评估了，尽管我根本没有什么需要写评估的东西。我想你看完之后也会有同样的感觉。

如果你看完这次对话感到兴奋，一定要去看看 Hamel 和 Shreya 在 Maven 上的课程。我们会在节目说明中附上链接。购买课程时使用代码 LENNYSLIST，可以享受 35% 的折扣。下面，请出 Hamel Husain 和 Shreya Shankar。

评估入门

Lenny Rachitsky： Hamel 和 Shreya，非常感谢你们来到这里，欢迎来到播客。

Hamel Husain： 谢谢邀请。

Shreya Shankar： 非常期待。

Lenny Rachitsky： 我比你们更期待。好的，几年前，我从未听说过评估这个词。现在它基本上是我播客上最热门的话题之一——要构建出色的 AI 产品，你必须非常擅长构建评估。而且，事实证明，世界上一些增长最快的公司基本上就是在为 AI 实验室构建、销售和创建评估。我之前刚邀请了 Mercor 的 CEO 来到播客。所以这里确实正在发生一些大事。我想利用这次对话帮助大家深入理解这个领域，但让我们从基础开始。到底什么是评估？对于完全不知道我们在说什么的人，给我们一个快速的理解，让我们先从 Hamel 开始。

Hamel Husain： 没问题。评估是一种系统化地衡量和改进 AI 应用的方式，它完全不需要让人觉得可怕或高不可攀。它的核心其实就是对 LLM 应用做数据分析，以及用系统化的方式来审视这些数据，并在必要的地方创建指标，这样你就能衡量正在发生的事情，然后进行迭代、做实验并改进。

Lenny Rachitsky： 这是一个非常好的宏观理解方式。如果再深入一层，给大家一种更具体的想象和可视化的方式，哪怕有一个示例来展示就更好了，有没有更深层的理解评估的方式？

Hamel Husain： 假设你有一个房地产助手应用，它没有按照你想要的方式工作——它没有按你的期望给客户写邮件，或者没有调用正确的工具，或者出现了各种其他错误。在评估出现之前，你只能靠猜。你可能会修改一个 prompt，然后祈祷你没有因此破坏其他东西，你可能依赖感觉检查（vibe checks），这倒也没什么问题。

评估比感觉检查走得更远

Hamel Husain： 感觉检查本身没问题，一开始你也应该做感觉检查。但它很快就会变得非常难以管理，因为随着应用不断增长，单纯依赖感觉检查实在太困难了。你会感到茫然无措。而评估可以帮助你创建指标，用来衡量应用的运行状况，让你有信心地去改进应用——你有了一个可以据此迭代的反馈信号。

Lenny Rachitsky： 为了让大家更有实感，我们继续用这个房地产助手的例子。假设它在帮客户预约看房或者参加开放日。这个助手在和用户对话、回答问题、推荐房源。作为这个助手的构建者，你怎么知道它给出的是好建议、好回答？它有没有在说完全错误的东西？

所以评估的本质，就是建立一套测试，告诉你这个助手有多频繁地在做你不希望它做的错误事情。“错误”可以有很多种定义：可能是在编造信息，可能是以非常奇怪的方式回答。我对评估的理解，跟我说得对不对啊，简单来说就像是代码中的单元测试。你笑了。你是不是在想，“不，你这个傻瓜。”

Shreya Shankar： 不，我刚才不是那个意思。

Lenny Rachitsky： 好吧好吧好吧，那你来说，这个比喻感觉怎么样？

Shreya Shankar： 好。我同意你一开始说的——我们给了一个非常宽泛的定义。评估是一个衡量应用质量的大光谱，方法多种多样。单元测试确实是其中一种方式。也许你的 AI 助手有一些不可妥协的功能，单元测试能够检查这些。但另一方面，由于这些 AI 助手执行的任务非常开放，你也会想要衡量它们在模糊或含混的事情上表现如何——比如应对新型用户请求，或者判断是否出现了新的数据分布，比如有新类型的用户开始使用你的房地产助手，你甚至不知道会有这样的用户来使用你的产品。然后你突然意识到，“哦，我需要用不同的方式来适应这个新群体。”

评估也可以是一种定期查看数据的方式，用来发现这些新的用户群体。评估还可以是你想要持续追踪的指标，比如你想追踪用户说”是的，点赞，我喜欢这条回复”。这些都是非常基础的东西，不一定与 AI 直接相关，但可以回流到改进你产品的飞轮之中。所以总的来说，单元测试只是那个巨大拼图里很小的一部分。

用真实案例演示评估

Lenny Rachitsky： 很好。你们其实带来了一个评估的具体示例，好让大家看看我们到底在说什么。我们一直在讲大概念，那不如我们打开一个例子，让大家看看，“评估就是这个东西。”

Hamel Husain： 好，让我先稍微铺垫一下背景。呼应一下 Shreya 刚才说的，很重要的一点是，我们不要把评估仅仅等同于测试。很多人会掉进一个常见陷阱——一上来就直奔测试，“我来写几个测试”。但通常这不是你应该做的。你应该先做一些数据分析，来明确你到底应该测试什么。这跟传统的软件工程有所不同，传统工程中你对系统的行为有更多确定性预期。而 LLM 的表面积大得多，随机性也强，所以这里的做法有不同的味道。

今天我要给大家看的例子，确实是一个房地产相关的例子，但类型不同。它来自一家叫 Nurture Boss 的公司。我先共享一下屏幕，给大家看看他们的网站，帮助你们理解这个用例。所以这是我和他们合作过的一家公司，叫 Nurture Boss，它是面向物业经理的 AI 助手，帮助他们管理公寓，涉及各种任务，比如潜在客户跟进、客户服务、预约看房等等。物业经理日常可能做的各种运营工作，它都能帮忙处理。你们可以看到他们的业务范围。这是一个非常好的例子，因为它具有现代 AI 应用的许多复杂性。

它有多种不同的交互渠道——聊天、短信、语音；还有大量的工具调用——预约看房、查询房源信息等等；还有 RAG 检索——获取客户和物业等相关信息。所以作为 AI 应用来说，它相当完整。他们也很大方地允许我使用他们的数据作为教学案例。数据已经做了匿名化处理。今天我要带大家走过的是，好，我们如何开始为 Nurture Boss 构建评估。我们为什么要做这件事？

错误分析：从数据开始

让我们从最初始的阶段开始，也就是我们所说的错误分析——看看应用的数据，首先搞清楚哪里出了问题。我接下来打开一个可观测性工具。这里你用什么工具都可以。我碰巧把这些数据加载到了一个叫 Braintrust 的工具里，但你可以加载到任何工具中。我们并没有偏好哪个工具。在我们和你一起写的那篇博文中，我们用了同样的例子，但用的是 Phoenix Arize，我记得 Aman 在他自己的博文里也用了 Phoenix Arize。还有 LangSmith。这些都是你可以使用的不同工具。

现在你在屏幕上看到的是应用的日志。让我给大家展示一下它是什么样子。你看到的——我把它全屏一下——这是某个客户与 Nurture Boss 应用的一次具体交互，它是所发生一切的详细日志。这叫做一个 trace（追踪），就是一系列事件日志的工程术语。trace 这个概念已经存在很长时间了，但在 AI 应用中它变得尤为重要。

这里包含了 AI 完成其工作所需的全部不同组件、模块和信息，所有内容都被记录下来，我们现在看到的就是这样一个视图。你可以看到这里有一个系统 prompt。系统 prompt 写的是：“你是一个 AI 助手，担任 Retreat at Acme Apartments 的租赁团队成员。“记住我说过这是匿名化的，所以名字是 Acme Apartments。“你的主要职责是回复现有住户和潜在住户的短信。你的目标是提供准确、有用的信息”等等等等。后面还有大量关于行为准则的详细规定。

Lenny Rachitsky： 顺便问一下，这是这家公司实际使用的系统 prompt 吗？

Hamel Husain： 是的，没错。

Lenny Rachitsky： 太棒了，太酷了。

Hamel Husain： 这是真实的系统 prompt。

Lenny Rachitsky： 真了不起，因为很少能看到一个真实公司产品的系统 prompt。那通常被视为他们的皇冠上的珠宝，所以这件事本身就非常酷。

实际 trace 示例

Hamel Husain： 是的，真的非常酷。你可以看到各种不同的功能、不同的使用场景，比如预约看房、处理申请、针对不同角色的沟通指导等等。你可以看到用户直接进来问：“你们有一室一书房的房源吗？我在虚拟看房里看到了。“然后你可以看到 LLM 调用了一些工具。它调用了获取个人信息工具，拉回了那个人的信息，然后又查了社区的可用房源。它实际上是在查询一个数据库，获取那个公寓群的空房信息。

最后 AI 回复说：“我们有好几套一居室，但没有专门标注带书房的。以下是几个选项。”

然后用户说：“有一室一书房的能通知我吗？”

AI 说：“我目前没有一室一书房房源的具体可用信息。”

用户说：“谢谢。”

AI 说：“不客气，如果还有其他问题，随时联系我们。“现在这是一个 trace 的示例，我们正在看的是一个具体的数据点。所以在做 LLM 应用的数据分析时，有一件事非常重要，就是去看数据。你可能会想，“这些日志太多了，乱糟糟的，各种东西都在里面。到底要怎么看这些数据？难道就在数据里淹死吗？怎么分析这些数据？“

错误分析的方法

Hamel Husain： 事实上有一种完全可以驾驭的方法来做这件事，而且不是我们发明的。它在机器学习和数据科学领域已经存在很长时间了，叫做错误分析。具体做法是，征服这类数据的第一步就是写笔记。你得戴上产品经理的帽子——这也是为什么我们要跟你聊这个，因为产品人员必须在场，必须参与到这种工作中来。通常开发者不太适合做这件事，尤其当它不是一个编程类应用的时候。

Lenny Rachitsky： 我复述一下，你说产品人员必须参与的原因是——这就是你产品的用户体验。人们和这个 agent 对话，本质上就是整个产品，所以产品经理深度参与其中是完全合理的。

Hamel Husain： 对。让我们来回顾一下这段对话。用户询问了房源可用性，AI 说：“哦，我们没有这种房源，祝你有美好的一天。“对于一个帮助管理线索的产品来说，这算好吗？你觉得这是我们想要的结果吗？

Lenny Rachitsky： 不太理想。

Hamel Husain： 对，不理想，我很高兴你这么说。很多人会说：“哦，很好啊，AI 做得对。它查了，说了没有可用房源，确实没有嘛。“但戴上产品经理的帽子，你就知道这不对。所以你要做的就是在这里快速写一条笔记。你可以弹出来写一条备注。每个可观测性工具都有写笔记的功能。你不需要去判定到底哪里出了问题——在这个例子中，它确实没有做正确的事——你只需要快速写一条笔记：“应该转交给人工。”

Lenny Rachitsky： 看着这个过程，就像你提到的这点，后面还会展开讲——你这样做，感觉非常手工、不可规模化，但正如你所说，这只是流程的第一步，有一套系统的方法。那只是第一步。

Hamel Husain： 对，而且你不需要对所有数据都这样做。你抽样一部分数据看一下就行，你会惊讶于这样做能学到多少东西。每个这样做的人都会立刻上瘾，他们说：“这是构建 AI 应用时你能做的最有价值的事。“你真的能学到很多，然后你会想：“嗯，这不是我想要的工作方式。好，记下来。“这就是一个例子。

你写完这条笔记，然后我们可以看下一个 trace。这是下一个 trace。我在键盘上按了一个快捷键，让我切回去看一下。

Lenny Rachitsky： 这些工具让你可以很方便地浏览一批数据，快速添加这些笔记。

短信渠道的问题

Hamel Husain： 对。这是另一个例子。类似的系统 prompt。我们不需要再全部过一遍，直接跳到用户的问题。“我一直给你发短信”，是不是很有趣？然后用户说：“请。“好，这个其实是一个应用层面的错误——这是一个短信应用，更准确地说，客户沟通的渠道是短信，所以你会收到一些非常混乱的内容。你可以看到这里内容有点不通。句子被截断了，比如”与此同时”然后就断了，系统不知道怎么回复，因为你知道人们发短信的方式——他们写很短的短语，把一句话拆成四五条来发。所以这个情况下——

Lenny Rachitsky： 那遇到这种情况你怎么处理？

Hamel Husain： 对，这是一种不同类型的错误。

Lenny Rachitsky： 嗯。

Hamel Husain： 这更像是”我们没有正确处理这种交互”，更多是一个技术问题，而不是”AI 没有按照我们的期望去做”这种问题。所以我们也会把它记下来。

Lenny Rachitsky： 但这也很有价值。

Hamel Husain： 对。

Lenny Rachitsky： 在这里能抓到这种问题真的很了不起。否则你根本不知道正在发生这种事。

Hamel Husain： 对，你可能根本不知道有这种情况。所以你只需要说”好的”，写一条笔记，比如”短信导致对话流程体验很差”。

Lenny Rachitsky： 我喜欢你用了”体验很差”这个词，说明这个阶段可以多么不正式。

Hamel Husain： 对，就是要放松。不要想太多。这有一个方法论的。大家总是会问，怎么做？是不是要找出这个 trace 里所有的问题？笔记该写什么？答案是：只写下你看到的第一个错误，最上游的那个错误。不要管其他所有错误，只抓住你看到的第一个问题，然后停下来，继续看下一个。你可以很快上手这个方法。前两三个可能会很痛苦，但之后你可以做得非常快。

幻觉问题

Hamel Husain： 这是另一个例子，我们同样跳过系统 prompt。用户问：“你好，我在找两到三居、一到两个卫生间的房源。你们提供虚拟看房吗？”

然后调用了一堆工具，它回复说：“你好 Sarah，目前我们有一套三居室、两个半卫生间的公寓，租金 2,175 美元。很遗憾目前没有两居室选项。我们确实提供虚拟看房，你可以预约一次看房，“等等。但碰巧的是，虚拟看房根本不存在。

Lenny Rachitsky： 嗯，有意思。

Hamel Husain： 所以它在幻觉（hallucinating）一个不存在的东西。这时候你需要带入你作为工程师甚至产品人员的上下文知识，说：“这有点不对。我们不应该告诉用户有虚拟看房，但我们根本没有这个服务。“

开放编码中 LLM 的局限

Hamel Husain： 所以你会说：“好的，提供了虚拟看房，“然后直接写下笔记。你可以看到我们观察到的错误类型是多种多样的，而且我们实际上在很短的时间内就对应用了解了很多。

Shreya Shankar： 我们在这个阶段经常被问到的一个问题是：“我理解是怎么回事了。能不能让 LLM 来帮我做这个过程？”

Lenny Rachitsky： 嗯，好问题。

Shreya Shankar： 我很喜欢 Hamel 刚才那个最新的例子，因为当我们尝试让 LLM 来做这种错误分析时，通常它只会说这个 trace 看起来没问题，因为它不具备判断某个东西是否有产品层面问题的上下文。比如那个预约看房的幻觉，对吧？我敢打包赌，如果我把这个放到 ChatGPT 里问”有没有错误？“，它会说”没有，做得很好。”

但 Hamel 有上下文，知道”哦，我们实际上没有虚拟看房这个功能”。所以我认为在这些情况下，确保你自己手动做这件事是非常重要的。我们可以稍后再谈什么时候在流程中使用 LLM，但这里头号陷阱就是人们说”让我用 LLM 自动化这个过程”。

Lenny Rachitsky： 你觉得我们会到一个 agent 能做到这一步的阶段吗？就是说它拥有那种上下文？

Shreya Shankar： 哦，不会。不会不会不会。抱歉。错误分析中确实有 LLM 适合做的部分，我们可以在播客后面聊到。但现在，在自由形式的笔记记录这个阶段，不是 LLM 该上场的地方。

Lenny Rachitsky： 明白了。这个步骤就是你们所说的开放编码（open coding），对吗？

Shreya Shankar： 是的，完全正确。

仁慈的独裁者

Lenny Rachitsky： 好。你们在文章中用到的另一个术语我很喜欢，也和这一步相关，就是”仁慈的独裁者”这个概念。也许可以聊聊这是什么，Shreya 你来讲讲？

Shreya Shankar： 好的，这个术语其实是 Hamel 提出来的。

Lenny Rachitsky： 好吧，那还是让 Hamel 来讲。

Hamel Husain： 没问题。而且我们实际上会在这个例子中展示 LLM 自动化，因为我们要把这个例子一路贯穿到底。

Lenny Rachitsky： 太棒了。

Hamel Husain： 仁慈的独裁者只是一个好记的说法，指的是在做开放编码的时候，很多团队会被委员会式的方式拖住。而在很多情况下，那完全没必要。人们会很不舒服，觉得”我们想让所有人都参与进来，我们想让每个人都同意”，等等。你需要穿透这些噪音。在很多组织中，如果你深入观察，尤其是中小型公司，你可以指定一个你信任其品味的人。你可以用很少的人，通常一个人，就能完成这件事。让它切实可行非常重要。你不能让这个过程变得昂贵到无法执行，否则你就亏了。

这就是仁慈的独裁者背后的理念——“嘿，你需要在尽可能多的维度上简化这件事。“我们后面还会谈到另一点，就是构建 LLM 作为评判者的时候，你需要一个二元评分。你不想去想”这是 1、2、3、4 还是 5？“给它打分。你做不到，那会拖慢整个过程。

Lenny Rachitsky： 为了确保仁慈的独裁者这个概念真的很清楚——基本上，这个人就是做笔记的那个人，理想情况下是这个领域的专家。如果是法律方面的，可能是一个法务人员来负责，也可以是产品经理。给我们点建议，这个人应该是什么样的？

Hamel Husain： 对，应该是具备领域专业知识的人。在这个例子中，就是了解公寓租赁业务、有上下文判断这是否合理的人。就像你说的，始终是领域专家。法律方面就是法务人员，心理健康方面就是心理健康专家，无论是精神科医生还是其他人。

Lenny Rachitsky： 明白。

Hamel Husain： 不过通常情况下，是产品经理。

Lenny Rachitsky： 好。所以这里的建议就是选定那个人。可能感觉不太公平，由他一个人说了算、当独裁者，但他是仁慈的，没问题的。

Hamel Husain： 对，没问题的。不求完美。你只是想取得进展、快速获得信号，这样你就知道该做什么，因为一不小心这事可以变得无限昂贵。

更多开放编码的实例

Lenny Rachitsky： 对。好，我们回到你的例子。

Hamel Husain： 好，没问题。这是另一个例子，有人说：“好的，你们有什么优惠吗？“助手或 AI 回答：“我们有 5% 的军人折扣。“用户接着回复，换了话题：“能告诉我有几层楼吗？你们有没有一居室？或者一楼的一居室？“AI 回答：“好的，我们有好几套一居室公寓。“用户想确认：“那些有在一楼的吗？一居室多少钱？“同时，因为这是一个现有住户，所以他们还问”我需要提交一个维修请求。”

你可以看到真实世界的杂乱，而助手直接调用了一个工具说转接电话，但什么都没说。它就突然执行了转接电话，所以我觉得挺糙的。就是——

Lenny Rachitsky： 又一个糙的。

Hamel Husain： 另一种糙，不同类型的糙。所以当你在写开放笔记的时候，你不应该说”糙”，因为我们要做的是理解发生了什么，等我们之后回头看笔记的时候，要知道怎么回事。

所以你只需要写”未与用户确认即转接电话”。不需要完美，你只需要对发生的事有个大概的了解。

理论饱和

Lenny Rachitsky： 好。

Hamel Husain： 那好。假设我们做了，Shreya 和我建议至少做 100 个。问题总是”要做多少个？“所以没有魔法数字。我们说 100 只是因为我们知道，一旦你开始做这件事，做了 20 个之后，你会自动发现它太有用了，你会继续做下去。

所以我们说 100 只是为了在心理上帮你解压，不那么吓人。就像”别担心，你就做 100 个。“实际上有个术语，正确的回答是”持续看 trace，直到你觉得学不到新东西为止。“也许 Shreya 可以讲讲——

Shreya Shankar： 对，确实有个术语——在数据分析和质性分析中叫做理论饱和（theoretical saturation）。意思就是，当你做了所有这些查看数据的过程后，什么时候停下来？就是当你达到了理论上的饱和，或者说你不再发现新的笔记类型、新的概念类型，或者没有什么会对你流程的下一步产生实质性改变的东西了。

培养理论饱和的直觉

Shreya Shankar： 这种直觉的培养需要一点时间，所以通常情况下，人们并不太确定自己是否已经达到了理论饱和。这完全没问题。当你做了两三个例子或轮次之后，你会逐渐培养起这种直觉。很多人会意识到，“哦，好的，我只需要做 40 个，只需要做 60 个。实际上，我只需要做 15 个。” 这说不准，取决于具体的应用场景，也取决于你对错误分析的熟练程度。

Lenny Rachitsky： 你说的”你会想做很多”，我想是因为你会有这样的感觉：“哦，我发现了这么多问题，我得看看还有些什么。”

Shreya Shankar： 没错。

Lenny Rachitsky： 是这样吗？

Shreya Shankar： 没错，而且我保证，到了某个阶段，你就不会再发现新类型的问题了。

Lenny Rachitsky： 好的。假设我们做了 100 个，下一步是什么？

从开放编码到轴心编码

Hamel Husain： 好。你做了 100 个，现在你手里有了所有这些笔记。这时候你可以开始用 AI 来帮你了。不过，就像我们讨论过的，亲自查看数据这个环节很重要，你不希望把这部分过度自动化。

Lenny Rachitsky： 人类仍然会有工作。这是关键收获。太好了。

Hamel Husain： 是的。

Lenny Rachitsky： 就是审查 trace。至少目前还剩这一份工作。很好。

Hamel Husain： 没错。好，你有了所有这些笔记。要把它们变成有用的东西，你可以做基本的计数。基本计数是数据科学中最强大的分析技术，因为它如此简单，而且在很多情况下被低估了，所以对人们来说非常容易上手。

第一件事就是把这些笔记拿过来，用 LLM 对它们进行分类，有很多不同的方法可以做到这一点。就在这期播客录制之前，我试了三种不同的编程 agent 或 AI 工具来对这些笔记进行分类。一种方法是，我把数据上传到一个 cloud project 里，上传了一个包含这些笔记的 CSV 文件，直接从界面导出的。有很多不同的做法，但我展示给你的是最简单、最笨的方法，最基础的做法。

我把 CSV 导进去，说”请分析以下 CSV 文件。“我告诉它有一个 metadata 字段里面包含笔记，但我用的词是”open codes”（开放编码），我说”我有不同的开放编码”——这是一个专业术语。LLM 知道什么是开放编码，也知道什么是轴心编码（axial codes），因为这个概念已经存在很长时间了，所以这些术语帮我快速跳到了我想做的事情上。

Lenny Rachitsky： 太棒了。prompt 的最后是让它创建轴心编码？

Hamel Husain： 对，创建轴心编码。它的作用是——

Shreya Shankar： 也许值得讲讲什么是轴心编码，或者说这一步的意义是什么？你有一堆杂乱的开放编码，你并没有 100 个不同的问题。实际上很多都是重复的，只是因为你用了不同的表述方式。你在开放编码时不应试图创建自己的失败分类体系，你只想把问题记录下来，然后再整理：“最常见的失败模式是什么？”

所以轴心编码的目的，说白了就是一个失败模式。它是一个标签或类别。我们的目标是得到这些失败模式的聚类，找出最普遍的那个，然后去攻克那个问题。

Lenny Rachitsky： 这非常有帮助。基本上就是把所有这些综合起来——

Shreya Shankar： 完全正确。

Lenny Rachitsky： 归纳成类别和主题。太酷了。我们会在节目笔记里附上这个 prompt，这样听众就不用截图再自己打字了。

Hamel Husain： 好主意。然后 Claude 就分析了这个 CSV 文件，决定如何解析它，等等。这些细节我们不需要操心，但它产出了大量的轴心编码。基本上，轴心编码就是类别，就像 Shreya 说的。比如：能力限制、表述不当、流程和协议违规、人工交接问题、沟通质量。它创建了这些类别。

我喜欢所有这些类别吗？并不完全。我喜欢其中一些。这是一个不错的初步尝试。我可能会对它们做一些重命名，因为有些类别太笼统了。比如”能力限制”是什么意思？有点太宽泛了，不够可操作。我希望让它更具可操作性，这样如果我确定它是一个问题，我就知道该怎么处理它。不过这个我们稍后再讨论。你可以用任何工具来做这件事，这是最笨的方法，但有时候笨方法正是一个好的起点。

Lenny Rachitsky： 这正是 LLM 擅长的事情——接收大量信息并加以综合提炼。

Shreya Shankar： 完全正确。帮我们综合提炼以便理解，对吧？注意它并不是自动提出修复方案什么的，那是我们的工作，但现在我们可以更轻松地理清这一堆开放编码了。

在生成轴心编码的这个 prompt 中，还有一个有趣的地方——你可以根据需要写得非常具体。你可以说”我希望每个轴心编码实际上是一个可操作的失败模式”，也许 LLM 会理解并照做；或者”我希望你按照用户故事的阶段来对这些开放编码分组。“所以在这里你可以发挥创意，或者根据你作为产品经理或工程师的具体需求来调整，这将有助于你后续的改进工作。

Lenny Rachitsky： 所以并没有一个确定的 prompt，说”这就是唯一正确的方式”？

Shreya Shankar： 完全没有。

Lenny Rachitsky： 你的意思是你可以迭代，看看什么对你有效？

Shreya Shankar： 完全正确。

Lenny Rachitsky： 有意思的是现有工具并没有做这件事，还是说它们尝试了但做得不好？

Shreya Shankar： 没有，我觉得它们没做。我们一直在到处呼吁，“拜托，拜托——”

Lenny Rachitsky： 哦，真的吗。

Shreya Shankar： “——做这个吧。“我确实觉得这件事有一点难度。Hamel 和我教的评估课程中的经验是，很多人实际上并不知道这些，所以也许是因为人们不了解这些方法，也不知道如何为此构建工具。希望我们能揭开这些魔法的面纱。

Lenny Rachitsky： 再深入确认一下，这并不是所有人都做或都知道的事情。这是你们两位基于在其他公司做数据分析和数据科学的经验总结出来的？

Shreya Shankar： 我想先澄清一下，我们并没有发明错误分析。我们实际上不想发明新东西。那是不好的信号。如果有人向你推销一种全新的方法，而且不以数百年来的理论和文献为基础，那你应该，怎么说呢，对此保持一点警惕。

但我们尝试做的是提炼出：“好的，要理解 LLM 的错误分析，你需要哪些新的工具和技术？“然后我们创建了一套课程或结构化的方法来做这件事。所以这一切都是针对 LLM 的，但开放编码、轴心编码这些术语，都是根植于社会科学的。

Lenny Rachitsky： 太棒了。你们做这件事有意思的地方在于，我也想找个地方试试。我手头并没有什么 AI 产品可以拿来操作，但就是觉得：“这太有意思了。“坐在那里，找出所有遇到的问题，把它们分类，然后尝试修复。

Shreya Shankar： 我很喜欢这个想法。

Lenny Racheshky： Hamel 刚才打开了一个视频。你这里在展示什么？

机器学习中由来已久的传统

Hamel Husain： 对，我打开了一个视频，就是为了印证 Shreya 的观点。我们并没有发明任何东西，所以你在屏幕上看到的是 Andrew Ng，世界上最著名的机器学习研究者之一，坦白说，他教会了很多人机器学习。你可以看到这是一个八年前的视频，他在讲错误分析。这种技术用于分析随机系统已经有很长时间了，我们只是把同样的机器学习理念和原则搬到这里来，因为同样的，这些也是随机系统。

Lenny Rachitsky： 太好了。顺便一提，我们正在联系 Andrew 上我们的播客，正在沟通，所以到时候——

Shreya Shankar： 太好了。

Lenny Rachitsky： ——应该会非常有意思。另外，我很高兴今天刚发布的播客节目出现在你们的推荐信息流里，而且排名很靠前，我对此非常满意。

Hamel Husain： 很不错。推荐算法确实挺好的。

Lenny Rachitsky： 是啊，希望你会点进去。别搞砸我的算法。好，酷。我们已经做了一些综合。我知道我们不会把整个步骤都走一遍，你们有一整套课程，需要好几天才能学完全部流程。关于这个过程，你们还想分享什么？

用 AI 工具完成编码与分类

Hamel Husain： 好的。你可以在任何工具上做这件事，在 ChatGPT 里用同样的 prompt 也完全没问题。你可以看到它生成了轴心编码。我特别喜欢用 Julius AI，这是我最喜欢的工具之一。Julius 是一个使用 notebook 的第三方工具。我个人很喜欢 Jupyter notebook，它更偏向数据科学领域，但现在很多产品经理也在学习使用 notebook，挺酷的。它就像一个有趣的游乐场，你可以在里面写代码、看数据。不过我们不需要深入讲这个，只是想提一下，你可以使用很多工具。AI 在这方面确实很擅长。

那我们进入有趣的部分。好，现在我们有了这些轴心编码。所以我喜欢做的第一件事是——我手上有开放编码，也有轴心编码，假设是从 cloud 项目或 ChatGPT 中生成的——我先把它们收集起来看一眼，这些轴心编码是否合理？我会查看不同轴心编码与开放编码之间的对应关系，然后做一个审视：这些编码好吗？能不能改进？能不能更精细化？能不能让它们更具体、更有可操作性，而不是笼统模糊的？

你可以看到我整理出来的这些编码：行程调度、重新调度的问题、人工交接或转接问题、输出格式错误、对话流程——我们之前在短信场景中看到了对话流程的问题——后续承诺未兑现。

所以基本上，现在你有了这些轴心编码，我把它们收集到一个列表里，这是一个 Excel 公式，把这些编码收集成一个列表，现在我们有了一个逗号分隔的编码列表。然后你只需要做的是：把你记录的那些开放编码拿出来，告诉一个 AI——这里为了简单起见用的是 Gemini——再说一遍，我们尽量保持简单——让它把这些记录分类到以下类别中。

Lenny Rachitsky： 给观看的人说一下，我喜欢你分享的这些不同的 prompt 和公式。这是 Google Sheets 的 AI prompt。

Shreya Shankar： 超级推荐。

Hamel Husain： 基本上，你可以把你的 trace 分类到不同的桶里，我们这里做的就是这件事。我们把我们遇到的所有问题分类到了这些类别中。

Shreya Shankar： 而且这是自动完成的，非常令人兴奋。我的意思是，AI 在做这件事。这再次说明了一点：你的开放编码必须详细。你不能只写一个”糙”，因为如果 AI 读到”糙”，它是没法分类的。即使是人类也不行，对吧？人类得回去回忆你为什么说”糙”，所以在开放编码中保持一定程度的详细很重要。

Lenny Rachitsky： 好的。所以避免使用”糙”这个词。这是个好的经验法则。

Shreya Shankar： 对。或者后面再跟上十个词也行。

Lenny Rachitsky： 哦，好吧。那——

Hamel Husain： 我刚才是在开玩笑。

Lenny Rachitsky： 好。那人们常用的、你觉得不太好的词还有哪些？

Shreya Shankar： 我觉得不是特定词语的问题，而是人们在开放编码中不够详细，所以很难完成分类。

Lenny Rachitsky： 明白了。顺便问一下，之所以要把它们映射回去，是因为比如说 Claude 或 ChatGPT 给了你建议，你做了修改和迭代，所以你不能直接回过头说：“好的，每个桶随便放”——是这样吗？

Hamel Husain： 对，对。

Lenny Rachitsky： 好的。

Hamel Husain： 这个问题问得真的很好。迭代和思考是很有必要的——“我喜欢这些开放编码吗？这些对我来说真的合理吗？“就像 AI 做的任何事情一样，把自己放在中间环节审视一下是很有必要的。

Lenny Rachitsky： 人在回路中。还是有我们发挥的空间。很好。

Shreya Shankan： 如果我想用 AI 来做这个标注，我在这一步还喜欢做的一件事是增加一个叫”以上都不是”的新类别。这样 AI 可以实际输出”以上都不是”这个轴心编码，这会告诉我：“好吧，我的轴心编码不完整。让我们回去看看那些开放编码，找出一些新类别，或者想想怎么重新措辞现有的轴心编码。”

Lenny Rachitsky： 太棒了。而且这个方法很棒的地方在于，你不需要反复做很多次。

Shreya Shankan： 不需要。

持续改进的节奏

Lenny Rachitsky： 对于大多数产品来说，你只需要做一次这个过程，然后在此基础上不断构建，随着时间推移不断调整，对吗？

Shreya Shankan： 完全正确。而且速度会变得很快。人们每周做一次，整个过程三十分钟就能完成，然后你的产品突然就比之前对这些问题一无所知时好了一大截。

Lenny Rachitsky： 是啊。不知道这些问题正在发生，这太荒谬了。看着这个过程进行，我心想：“你怎么能不对自己的产品做这件事呢？”

Shreya Shankan： 很多人完全不知道。

Lenny Rachitsky： 大多数人。是的。这个问题我们后面会聊到，围绕这些内容有一场很值得讨论的辩论。好，酷。你现在有了这个表格。接下来呢？

Hamel Husain： 好的。接下来就是重头戏了。现在是见证奇迹的时刻。我们已经把所有这些编码应用到了我们的 trace 上，都是我们认可的编码。现在，你可以来揭晓答案了——你可以对它们进行计数。

从数据透视表到问题优先级排序

Hamel Husain： 这是一个数据透视表，我们可以直接对这些编码做数据透视，统计各类问题出现的次数。我们发现了什么？在我们分类好的这些 trace 上发现了什么？我们发现了 17 个对话流程问题。我非常喜欢数据透视表，因为你可以做很多很酷的操作。你可以双击这些条目，说”哦，让我看看这些具体内容”，不过这是关于数据透视表有多酷的题外话了。

但现在我们有了一个粗略但清晰的切面，看到了我们的问题是什么。我们从混乱走向了某种有序的思考——“哦，你知道吗？这些是我最大的问题。我需要修复对话类问题，也许是这些人工转接的问题。“不一定数量最多的问题就是最重要的，也可能某个问题虽然数量不多但特别严重，你想优先修复它。但总之，现在你有了一种审视问题的方式，然后可以考虑其中一些是否需要编写评估。

何时需要编写评估

其中有些可能只是低级的工程错误，你不需要为它写评估，因为修复方法非常明显。也许是输出格式错误——你可能只是忘记告诉 LLM 你想要的格式，连 prompt 里都没写。那就直接去改 prompt 就好了，然后我们可以决定：“好吧，要不要为这个写个评估？“你可能还是想写，因为你可以用纯代码来测试。你可以直接检查字符串是否具有正确的格式，而不需要运行 LLM。

所以评估存在成本收益的权衡。你不应该过度沉迷其中，但通常应该以实际错误为出发点。你不想跳过这一步。我之所以在这上面花这么多时间，是因为这正是人们迷失方向的地方。他们直接跳到评估阶段，说”让我来写些测试”，然后事情就脱轨了。

构建 LLM as a Judge

好，假设我们想解决其中一个问题。比如我们想解决这个人工转接的问题，然后我们会想：“嗯，我不太确定怎么修。这涉及到一种主观判断——我们是否应该转接给人工？而且我不能立刻知道怎么修，这不是特别显而易见。是的，我可以改 prompt，但我不确定。我没有百分之百的把握。”

那这可能就是一个适合用 LLM as a judge 来处理的场景。评估有不同的类型。一种是基于代码的，如果可以的话你应该优先尝试这种方式，因为成本更低。LLM as a judge 则是一种元评估——你需要对评估本身再进行评估，确保做评判的 LLM 在做正确的事，这个我们稍后会谈到。

好，LLM as a judge，这是一种方式。那怎么构建 LLM as a judge 呢？

Lenny Rachitsky： 在讲这个之前，为了确保大家完全理解你刚才描述的这两种评估类型——一种是你说基于代码的，一种是 LLM as a judge。也许 Shreya，帮我们理解一下基于代码的评估到底是什么？简单来说就是一个单元测试？可以这样理解吗？

Shreya Shankar： 对。也许”评估”这个词在这里不是最准确的，但可以把它理解为一个自动化评估器。当我们发现这些失败模式后，我们想要的是：“好，现在我们能不能用自动化的方式检查这个失败模式的发生频率，而不需要我手动标注、做所有的编码和分组？我想在成千上万的 trace 上运行，我想每周都跑一遍。“这就是——你应该构建一个自动化评估器来检查那个失败模式。

当我们说基于代码的和基于 LLM 的时候，我们说的是：“好，也许我可以写一个 Python 函数或一段代码来检查某个 trace 中是否存在那个失败模式。“这对于某些情况是可行的，比如检查输出是否为 JSON，或者是否为 markdown，或者是否够简短。这些都是可以用代码捕获的，或者至少近似地用代码捕获的。

当我们谈到 LLM judge 时，我们指的是这是一种复杂的失败模式，我们不知道如何用自动化方式评估。所以也许我们会尝试用 LLM 来评估人工转接这个非常狭窄、特定的失败模式。

Lenny Rachitsky： 为了确认我理解了你描述的内容——你想测试你的 agent 或 AI 产品的输出。你问它一个问题，它返回一些东西。

一种测试它是否给出正确答案的方式是：如果它持续做同一件事，你可以写一段代码来判断结果是否正确。比如，它会不会说有虚拟看房服务？你可以问它。

Shreya Shankar： 是的。

Lenny Rachitsky： “你们提供虚拟看房吗？“它回答是或否，然后你可以用代码根据那个具体答案判断是否正确。

但如果你问的是更复杂的问题，答案不是非此即彼的，在一种情况下你需要一个人来告诉你这是否正确。为了避免每次都需要人工审阅的解决方案就是让 LLM 替代人工判断，你称之为 LLM as a judge——LLM 作为评判者来判断这是否正确。

Shreya Shankar： 完全正确。你说得很准确。

Lenny Rachitsky： 很好。

Shreya Shankar： 很多人总觉得：“哦，这至少和构建原始 agent 的问题一样难。“其实不然，因为你只要求 judge 做一件事——评估一个失败模式——所以问题的范围非常小，而且这个 LLM judge 的输出就是通过或不通过。这是一个范围非常紧密的任务，LLM judge 非常擅长做这种事，而且做得非常可靠。

Lenny Rachitsky： 这里的目标就是拥有一套测试，在你上线到生产环境之前运行，告诉你一切是否按照你期望的方式进行？你的 agent 的交互行为是正确的？

Shreya Shankar： LLM judge 的美妙之处在于，你当然可以在单元测试或 CI 中使用它们，但你也可以在线上用于监控。我可以每天抽样 1000 条 trace，运行我的 LLM judge，用的是真实的生产 trace，看看那里的失败率是多少。这不是单元测试，但我们同样获得了一个极其具体的应用质量衡量指标。

Lenny Rachitsky： 这点非常好，因为很多人只把评估看作一种脱离现实的东西——你在真实世界之前测试的东西。而你说在真实世界中实际发生的，你也应该用完全一样的方式来做？

Shreya Shankar： 是的。

Lenny Rachitsky： 测试你生产环境中实际运行的东西？而且可以是每天、每小时运行的？

Shreya Shankar： 完全可以。

Lenny Rachitsky： 太好了。好，Hamel 这里有一个实际的 LLM as a judge 评估的例子，我们来看看。

一个 LLM as a Judge 评估的实例

Hamel Husain： 我很喜欢 Shreya 帮我把铺垫做好了，非常感谢。我们这里有一个针对这一特定失败模式的 LLM as a judge prompt。正如 Shreya 所说，你应该针对一个特定的失败模式来做，而且要把它变成二元的，因为我们想简化事情。我们不要”嘿，给这个打个一到五的分，看看有多好”。在大多数情况下，那只是一种逃避做决定的狡猾方式。不是的，你需要做一个决定——这够好了吗？是还是否？

Hamel Husain： 想清楚那个标准可能会很痛苦，但你一定要去做。否则这件事会变得非常难以处理，而且当你汇报这些指标的时候，没有人知道3.2和3.7意味着什么。

Shreya Shankar： 是的，这种情况我们见得太多了，甚至网上那些专家策划的内容也是这样，比如”这是你的 LLM judge 评估 prompt，这是一到七分的量表。“我总会给 Hamel 发消息说，“完了，我们又得去纠正那些错误信息了，因为我们知道肯定有人会去试，然后回来跟我们说’我的平均分是4.2’，我们就只能……好吧。”

Lenny Rachitsky： 评估领域的争议真是太多了。我们后面还会聊到这个。天哪。

构建 Judge Prompt 与对齐人类判断

Hamel Husain： 好，这就是你的 judge prompt。没有唯一的正确做法。你可以用 LLM 来帮你创建它，但同样，把自己放在环里。不要盲目接受 LLM 的输出，在我们做的所有这些案例中，我们都是这么做的。借助轴心编码，我们对这个 prompt 进行了迭代。你可以用 LLM 来帮你创建这个 prompt，但一定要读它、编辑它。这不一定是个完美的 prompt。这只是个很简单的示例，只是为了展示思路。就像，“好，针对这个交接失败”，我说，“好，我要你输出 true 或 false”，这是一个二元的 judge。这就是我们推荐的做法。然后我就列出来，“好，什么时候应该做交接？“我就一条条列出来。

明确的、被忽略或循环的人类请求、某些政策规定的转接、敏感住户问题、工具数据不可用、当天的看房或参观请求——这些你需要跟人工沟通，诸如此类。核心思路是，既然我知道数据中存在这个失败，我就有兴趣去迭代它，因为我知道这种情况其实一直在发生。正如 Shreya 所说，如果能有一种方法，不仅在已有数据上评估，还能在生产数据上评估，了解这种情况在什么规模下发生，那就好了。让我找到更多 trace，让我有办法迭代。我们可以拿这个 prompt，再次使用电子表格。第一步是，做这个 judge 的时候……我写了 prompt。

很多人到这里就停了，他们说，“好，我有了 judge prompt，搞定了，直接上线吧。“然后 prompt 说如果 judge 说错了，那就是错了。他们直接把它当作金科玉律，觉得”好，LLM 说错了，那肯定错了。“不要这样做，因为这是让评估和实际情况脱节的最快方式。当人们对你的评估失去信任，他们对你也会失去信任。这一点非常重要，不要这样做。所以在发布你的 LLM as a judge 之前，你要确保它与人类判断对齐。怎么做？你有那些轴心编码，你要拿你的 judge 跟轴心编码比对，看”嘿，它跟我的判断一致吗？我自己的 judge，它同意我吗？“直接测量就行。

我们这里做的是，好，我说”评估这个 LLM trace。“同样，我只是用电子表格，“根据这些规则评估这个 LM trace。“规则就是我刚才展示的那个 prompt。我问它，“好，是否存在交接错误，true 还是 false？“然后这一列，让我放大一点。H 列是”好，这个错误发生了吗？“G 列是——我认为错误是否发生了。你可以看到——

Lenny Rachitsky： 你是手动逐条看的，你是那样做的。

Hamel Husain： 对对，我们已经做过了。我们已经手动过了一遍了。不需要再做一遍，因为我们已经有了轴心编码那个捷径，我们已经做过。如果你需要更多数据，可能需要再过一遍，这里面有很多关于如何正确操作的细节。你要拆分数据，做所有这些事情，确保你没有作弊，但我只是想展示这个概念。基本上，你可以测量一致性。现在有一件事你应该知道，作为产品经理，很多人会直接去看这个一致性。他们说，“好，我的 judge 在一定百分比的情况下跟人类一致。”

这听起来很诱人，但这是一个非常危险的指标，因为很多时候，错误只发生在长尾上，频率并不高，所以如果错误只出现10%的时间，那你只要让 judge 永远说通过，就能轻松达到90%的一致性。明白吗？90%的一致性看起来很好，但可能会有误导性。

Lenny Rachitsky： 因为是罕见错误。对。

Hamel Husain： 作为产品经理，或者即使你自己不做这个计算，如果有人向你汇报一致性，你应该立刻追问，“好，详细说说。“你需要深入看。他们给你更多直觉，这里是这个特定 judge 在 Google 表格中的一个矩阵，同样，这只是一个数据透视表，保持简单。“好，行上是，人类怎么想的？我怎么想的？有没有错误，true 还是 false？然后 judge 有没有错误，true 还是 false？”

Shreya Shankar： 这里的直觉正是 Hamel 说的，你需要看每种类型的错误。当人类说 false 但 judge 说 true，或者反过来，就是这里那些非绿色的对角线格子。如果它们太大了，就去迭代你的 prompt，让 LLM judge 更清楚，这样你就能减少那种不一致。你要达到一个程度，大多数情况……你会有一些不一致，这没关系。我们在课程里也讲了如何用代码纠正那种不一致，但在现阶段，如果你是产品经理，而构建 LLM judge 评估的人没有做这一步，他们只是说”一致性75%，没问题”，但他们没有这个矩阵，也没有迭代以确保这两种类型的错误降到接近零，那就是一个坏味道。去要求他们修复。

Lenny Rachitsky： 太棒了。这是一个很好的提示，告诉你当别人做错了的时候该看什么。

Shreya Shankar： 对。

评估即需求文档

Lenny Rachitsky： 其实，能不能带我们回到那个 LLM as a judge 的 prompt？我想强调一个非常有意思的地方。最近我播客上的一些嘉宾一直在说，“评估就是新的 PRD”，你看看这个，确实正是如此。产品经理、产品团队，这是产品应该是什么样的，这是所有的需求，这是它应该如何运作。他们构建了一个东西，然后测试它。往往是手动的。这个做法厉害的地方在于，它做的完全是一样的事，而且在持续运行。它告诉你，“这个 agent 应该这样回应”，而且是非常具体的方式。“如果是这样、这样、这样，就那样做。如果是这样、这样、那样，就那样做。” 这正是我反复听到的，你可以在这里直接看到。这就是产品需求文档最纯粹的形式——这个评估 judge 在告诉你它应该是什么样，而且是自动化的、持续运行的。

Shreya Shankar： 对，完全同意。它是从我们自己的数据中推导出来的，所以当然，它代表的是产品经理的期望。我发现很多人忽略的一点是，他们先把自己的期望写进去，而不先看数据，但随着我们查看数据，我们会发现更多一开始根本想不到的期望，这些最终都会进入这个 prompt。

Lenny Rachitsky： 这很有意思。你的建议不是在构建产品之前就直接跳到评估和 LLM as a judge prompt，仍然要写传统的单页 PRD 来告诉团队我们在做什么、为什么做、成功的标准是什么。但到了最后，你可以从中提取内容，甚至在使用这个流程迭代产品时改进最初的那份 PRD。

Shreya Shankar： 我甚至更进一步说——你会改进……它会变的。你永远不可能事先知道失败模式会是什么，你总是会发现自己希望产品具备的新感觉。在你亲眼用这些 LLM 看到之前，你并不真正知道自己想要什么，所以你必须保持灵活，必须看数据，必须……PRD 是思考这些问题的一个很好的抽象。但它不是全部，也不是终点。它会变。

Lenny Rachitsky： 说得好。Hamel 刚刚调出了一个很酷的研究报告。这是关于什么的？

Hamel Husain： 如果你想了解评估，这大概是你能读到的最棒的研究报告之一。它的作者是一位名叫 Shreya Shankar 的人。

Shreya Shankar： 天哪。

Hamel Husain： 还有她的合作者。论文题目叫”Who Validates the Validated?”。

Lenny Rachitsky： 这是给研究者的最好名字。

Shreya Shankar： 谢谢，谢谢。

Hamel Husain： 我应该让 Shreya 来讲这个。我觉得这篇论文中最值得关注的一点是标准漂移（criteria drift），以及她的发现。

Shreya Shankar： 我们做了这个超级有趣的研究，当时我们在对一些试图编写 LLM judge 或只是验证自己 LLM 输出的人做用户研究。我觉得那时候是在评估在网上变得极其火爆之前。我们是 2023 年底开始这个项目的。但作为一个研究者，一直在我脑子里燃烧的问题是，“为什么这个问题这么难？我们已经有了机器学习和 AI 这么长时间，它不是新东西，但突然之间，这一次，一切都变得非常困难。” 我们就和一群开发者做了这个用户研究，我们意识到，“好的，新的地方在于你没法事先确定你的评分标准。人们在审阅更多输出后，对好和坏的看法会发生变化，他们只有在看了 10 个输出之后才会想到一些之前根本想不到的失败模式，“而且这些都是专家。这些人之前已经构建过很多 LLM 流水线，现在又构建了 agent，但你永远不可能在最初就把一切都想出来。我觉得这在当今 AI 开发中非常关键。

Lenny Rachitsky： 这确实是个非常好的观点。它非常有力地印证了我们刚才讨论的内容，所以我把它调出来，就是……好的——

Shreya Shankar： 背后是有研究支撑的。

Lenny Rachitsky： 对，好的，没问题。你还是得以同样的方式做产品，但现在你有了一个非常强大的工具，帮助你确保构建的东西是正确的。它不会取代 PRD 流程。好的。那你通常会最终有多少个——比如说——LLM as a judge prompt？我知道这显然取决于产品的复杂度，但根据你的经验，大概是个什么数字？

Shreya Shankar： 对我来说，四到七个之间。

Lenny Rachitsky： 就这些？

Shreya Shankar： 没有那么多，因为很多失败模式，正如 Hamel 之前说的，可以通过直接修改你的 prompt 来修复。你只是没想过把它写进 prompt 里，所以现在把它加进去……你不应该为每件事都做这样的评估，只针对那些棘手的问题——你已经把理想行为写进了 agent prompt，但它仍然会失败的情况。

Lenny Rachitsky： 明白了。假设你发现了一个问题，你修复了它。在传统软件开发中，你会写一个单元测试来确保它不再发生。你这里的观点是不是说，“如果问题已经没了，甚至都不用费心为它写评估”？

Shreya Shankar： 我觉得如果你想写也可以，但这里的关键是关于优先级。你的资源和时间都是有限的，你不可能为所有事都写评估，所以优先处理那些更棘手的领域。

Lenny Rachitsky： 可能是那些如果出了问题对业务风险最大的——比如说了类似 Mecha Hitler 这种话的，Grok。

Shreya Shankar： 哎呀。

Lenny Rachitsky： 好。那这很让人放心，因为这个 prompt 确实花了很大功夫去想清楚所有这些细节。

Shreya Shankar： 但它主要是一次性投入。现在写好了，以后你可以永远在你的应用上运行它。

数据分析的进阶技巧

Hamel Husain： 好，数据分析非常强大，会给你的应用带来非常快速的改进。我们展示了最基本的数据分析方式——计数，这对所有人来说都是可用的。你可以用更复杂的方式来做数据分析。有很多不同的采样和查看数据的方法。我们让它看起来很简单，但要做好其实需要很多技能。需要培养一种直觉和嗅觉来筛选这些数据。比如，假设我发现了对话问题，对话流程的问题。如果我想进一步追踪这个问题，我会想办法找到其他我还没有编码的对话流程问题。我可能会用多种方式深挖数据，有不同的切入路径。这非常类似于——如果不说是完全一样的话——你对任何产品都会做的传统分析技术。

Lenny Rachitsky： 给我们简单说一下接下来是什么，然后我们来聊聊关于评估的争论，还有其他几件事。

LLM judge 的后续应用

Shreya Shankar： 构建好 LLM judge 之后接下来做什么？我们发现人们会尽可能把它用在所有地方——把 LLM judge 放进单元测试里，然后构建出这样的测试集：“这里是一些我们观察到故障的示例 trace，因为我们已经标注过了。现在我们要把它们变成单元测试的一部分，确保每次推送代码变更时，这些测试都能通过。” 他们还用它做线上监控。人们在上面搭建仪表盘，我觉得这太棒了。我认为做到这一点的产品对自身应用的表现有着非常敏锐的感知，但人们不会去谈论这件事，因为这是他们的护城河。人们不会去分享所有这些东西，因为理所当然——如果你是一个邮件写作助手产品，你在做这件事而且做得很好，你不会希望别人也去做一个邮件写作助手然后把你挤出市场。

我真的想强调的一点是：尽量把你构建的这些产物在线上所有能用的地方都用起来，反复使用它们来驱动产品改进。很多时候，Hamel 和我会教人们一路做到这一步，然后他们就会恍然大悟，之后就再也不会回来了。要么是——我不知道——他们辞职了，不再做 AI 开发了，要么就是他们从这里开始已经知道该怎么做了。我觉得是后者，而且我认为这非常强大。

Lenny Rachitsky： 看你们做这件事真的让我大开眼界，让我明白了这是什么，以及这个过程有多么系统化。我以前总是想象你就是坐在电脑前，“好吧，我需要确保哪些东西正常工作？“但你们在这里展示的是一套非常简单的、基于产品中真实发生的情形的循序渐进的方法——如何捕捉问题、识别问题、排列优先级，然后在问题再次发生时抓住它并修复它。

Shreya Shankar： 对，这不是魔法。任何人都能做到，但你需要练习这项技能，就像任何新技能一样，需要练习，但你能做到。我觉得现在非常赋能的一点是，产品经理也在做这件事、也能做这件事，并且真的可以凭借这套技能构建出非常盈利的产品。

关于评估的争议

Lenny Rachitsky： 很好，正好可以过渡到我们前几天在 X 上被卷入的那场争论。我之前没有意识到评估周围有多少争议和风波。很多人持有非常强烈的观点。Shreya，你怎么样？给我们大致讲讲关于评估重要性和价值这场争论的双方立场，然后说说你自己的看法。

Shreya Shankar： 好的。我会稍微和一下稀泥——我觉得所有人其实站在同一边。我认为误解在于人们对评估有着非常僵化的定义。比如，他们可能认为评估就是单元测试，或者认为评估只是数据分析部分，不包括线上监控，也不包括对产品特定指标的监控——比如实际的聊天参与数之类的。我觉得每个人进来时对评估的理解都不一样。另外一点我想说的是，人们过去在评估上栽过跟头。人们做过糟糕的评估。一个具体的例子是他们尝试做了 LLM judge，但它和他们的预期不一致。他们后来才发现这个问题，然后就不再信任它了，于是就说，“我反对评估。”

我百分之百理解这种感受，因为你应该反对基于 Likert 量表的 LLM judge。我完全同意，我们也反对那个。很多误解源于两件事：一是人们对评估的定义过于狭隘，二是人们没做好评估、栽了跟头、然后想避免其他人犯同样的错。然后，不幸的是，X 或者说 Twitter 是一个人们不断误读彼此言论的平台，于是你就看到各种强烈的主张——“不要做评估，那是坏的。我们试过了，不管用。我们是 Claude Code，“或者随便哪个知名产品，“我们不做评估。“这背后其实有非常多的微妙之处，因为很多这些应用本身就是站在评估的肩膀上的。编程代理就是一个很好的例子，Claude Code 就是如此。它们站在 Claude 基础模型……不是基础模型，而是经过微调的 Claude 模型的肩膀上，这些模型已经在很多编程基准测试上经过了评估。这一点是无法否认的。

Lenny Rachitsky： 为了让你说的更清楚——Claude Code 的负责人之一，我想应该是首席工程师，上了一个播客节目说，“我们不做评估，我们只靠感觉。“所谓感觉就是他们只是使用它，凭感觉判断对不对。

Shreya Shankar： 我觉得这是行得通的。这里有两点。第一，他们站在同事们为编程所做的评估的肩膀上。

Lenny Rachitsky： 也就是 Claude 基础模型的评估。

Shreya Shankar： 当然，对吧？我们知道他们公布了这些数字，因为我们能看到基准测试结果，我们知道谁在上面表现好。第二点是，他们在某种程度上可能对错误分析是非常系统化的。我敢打赌他们在监控谁在使用 Claude、有多少人在使用、产生了多少 trace、这些聊天有多长。他们在内部团队中可能也在做 dogfooding。任何时候有什么不对劲，他们可能有一个队列，或者把问题发给开发 Claude Code 的人，这个人就在隐式地做某种形式的错误分析——就是 Hamel 谈到的那种。所有这些都是评估，对吧？不存在一个世界是他们只是在说，“我做了 Claude Code，然后我什么都不看。“而不幸的是，当人们不去思考或谈论这些的时候，我觉得社区……

社区中的大多数人其实是初学者，或者是不了解评估但想学习评估的人，这给他们传递了错误的信息。当然，我不知道 Claude Code 具体在做什么，但我愿意打赌他们在以某种形式做评估。

Hamel Husain： 我还想说，编程代理与其他 AI 产品有着根本性的不同，因为开发者本身就是领域专家，所以你可以走很多捷径。而且，开发者一整天都在使用它，所以有一种 dogfooding 和领域专业性的类型……你可以把这些活动压缩，不需要那么多数据，不需要那么多反馈或探索，因为你自己就知道，所以你的评估流程理应看起来不一样。

Lenny Rachitsky： 因为你能看到代码，你看到它生成的代码。你能判断，“这个很好，这个很糟糕。”

Hamel Husain： 对，对。我觉得很多人把编程代理的做法做了过度推广，因为编程代理是第一批发布到野外的 AI 产品，我认为把它的做法大规模推广到其他领域是一个错误。

Shreya Shankar： 另外还有一点，工程师有 dogfooding 的性格特质。但在很多应用领域，人们在某些领域尝试构建 AI，却没有 dogfooding 的条件——比如面向医生的产品就不行，不可能让医生们出去接受 AI 给出的所有错误建议还对它保持包容和接纳。我认为把这些微妙之处牢记在心非常重要。

Lenny Rachitsky： 有趣的是，Shreya，我从你这里听到的是，如果团队中的人类在做非常细致的数据分析、错误分析、疯狂地 dogfooding，本质上他们自己就是人类评估，而你把这也纳入了评估的范畴。如果你有时间和动力，可以这么做；或者你也可以把这些东西设置成自动化的。

Shreya Shankar： 完全同意，这也关乎技能。在 Anthropic 工作的人非常、非常高素质。他们受过数据分析、软件工程、AI 等方面的训练。当然，任何人都可以通过学习概念达到那个水平，但大多数人目前不具备这种技能。

Dogfooding 的局限性

Hamel Husain： Dogfooding 是一个需要警惕的做法，因为很多人会说自己在做 dogfooding。他们说”对，我们 dogfood 了，“但真的做了吗？很多人并没有在那种真正切身的程度上做 dogfooding，以此来闭合反馈回路。这是我想补充的唯一一点保留。

评估与 A/B 测试之争

Lenny Rachitsky： 还有一个感觉像是稻草人论证的话题——评估（evals）与 A/B 测试之间的对立。谈谈你们的看法？因为这似乎是这场讨论中很大的一部分。人们在争论，“如果你有 A/B 测试在检验生产环境指标，还需要评估吗？”

Shreya Shankar： A/B 测试，我想，同样也是评估的另一种形式，对吧？当你做 A/B 测试时，你有两种不同的实验条件，然后有一个量化某个东西成功与否的指标，你在比较这个指标。同样，在我们看来，评估就是对质量的系统性测量，某种指标。你不可能在没有评估可比较的情况下做 A/B 测试，所以也许我们只是对这个有一个不同的、有点奇怪的看法。

Lenny Rachitsky： 好的。我听到的是你们把 A/B 测试视为所做的一系列评估中的一部分。我想人们想到 A/B 测试的时候，会说我们在产品中改变了一些东西，看看是否能改善我们关心的某个指标。这样够吗？为什么还需要测试每一个小功能？如果它影响的是我们作为企业关心的某个指标，我们有一堆 A/B 测试在持续运行。

Shreya Shankar： 这就引出了一个很好的观点。我认为很多人过早地做 A/B 测试，因为他们根本没做过任何错误分析。他们只是假设性地提出了产品需求，然后认为”我们应该测试这些东西”，但实际上，当你深入数据时，就像 Hamel 所展示的那样，你看到的错误并不是你以为会出现的那些。而是一些奇怪的交接问题，或者，我不知道，文本消息那件事很奇怪。我想说的是，如果你要做 A/B 测试，而且它们是由实际的错误分析驱动的，就像我们今天展示的那样，那很好，去做吧。但如果你只是想做 A/B 测试——我们发现很多人确实在这么做——仅仅基于你假设性地认为重要的东西，那我会鼓励大家回去重新思考，让你的假设有据可依。

Statsig 被 OpenAI 收购

Lenny Rachitsky： 你们对 Statsig 被 OpenAI 收购后要做什么有什么看法吗？有什么有意思的东西吗？这可是件大事，一笔巨额收购。一家 A/B 测试公司被收购了，人们开始说”A/B 测试就是未来。“有什么想法？

Hamel Husain： 先补充一点上一个问题，为什么会有评估与 A/B 测试之争这个讨论？我认为，从根本上说，评估是……人们在试图搞清楚如何改进他们的应用，从根本上需要做的是……数据科学在产品中是有用的。看数据，做数据分析。有很多不同的工具套件，你不需要发明任何新东西。当然，你未必需要数据科学的全部广度，而且使用 LLM 时看起来会略有不同，只是略有不同而已。你的具体策略可能不同，所以本质上就是用分析工具来理解你的产品。现在人们说”评估”这个词，试图划分出一个新领域，然后说评估与 A/B 测试如何如何，但如果你退后一步看，这跟以前的数据科学是一样的。我认为造成困惑的原因就是——“嘿，我们需要数据科学思维，“AI 产品需要这种思维，就像任何产品都需要一样。这是我的看法。

Lenny Rachitsky： 这个观点非常好。我觉得只是”评估”（Evals）这个词现在会触发人们的敏感反应。

Shreya Shankar： 是啊。

Lenny Rachitsky： 如果你只是说，“我们只是在做错误分析，做数据科学来理解我们的产品在哪里出问题，然后设置测试来确保我们知道——”

Shreya Shankar： 那太无聊了，听起来很无聊。不不不。我们需要一个神秘的术语，比如”评估”（Evals），才能真正获得动力。

关于你问的 Statsig，我觉得非常令人兴奋。说实话，我对它了解不多，因为我只是把它想象成这样一家公司——有一个很多人在用的工具，也许碰巧 OpenAI 收购了他们。我确定他们之前就在使用，我确定 OpenAI 的竞争对手也在使用 Statsig，所以也许这次收购有某种战略考量。我完全不知道，我对这方面没有任何信息。但对我来说这些才是更大的问题，而不是”这是否从根本上改变了 A/B 测试，或者让评估变得更加优先？“我认为评估一直都很重要，我认为 OpenAI 一直在做某种形式的评估，而且从历史上看 OpenAI 甚至做得更远——他们会去看所有 Twitter 上的情绪倾向，尝试做一些回顾分析，然后把它与产品关联起来。当然，他们在发布新的基础模型（foundation models）之前会做一定量的评估，但他们走得更远，会说，“好，让我们找出所有抱怨它的推文，所有抱怨它的 Reddit 帖子，然后去搞清楚到底是怎么回事。“这说明评估非常、非常重要。目前还没有人真正搞明白。人们在使用所有能获取的信号源来改进他们的产品。

对评估工具未来的期望

Hamel Husain： 我想说的是，我对这件事抱有很大期望——它也许能在 OpenAI 内部转移或创造一个重心，希望如此。到目前为止，大型实验室（labs）很自然地将注意力集中在通用基准测试（benchmarks）上，比如 MMLU 分数、human eval 之类的，这些对于基础模型来说非常重要。但那些跟产品特定的评估——比如我们今天讨论的交接之类的问题——关联度不高，它们往往不相关。

Shreya Shankar： 对，它们跟数学问题解决能力不相关，不好意思说句实话。

Hamel Husain： 没错。如果你看看那些评估产品，比如说大型实验室直到最近才有的那些，它们没有错误分析功能。它们有一套通用工具——余弦相似度（cosine similarity）、幻觉评分（hallucination score）之类的，但这不奏效。这是第一次尝试，还不错。至少你在做点什么，让人们在看数据。但最终，我们希望看到的是评估过程中融入更多的数据科学思维。希望我们的工具能达到那一步。

Shreya Shankar： 对，Pamela 和我不应该是这个星球上仅有的两个在推广一种结构化的方式来思考应用特定评估的人。这让我觉得不可思议。为什么全世界只有我们两个人在做这件事？这不对劲。我希望我们不是仅有的两个人，希望更多人能跟上来。

评估的需求与市场热度

Lenny Rachitsky： 你们在 Maven 上的课程是 Maven 平台上收入最高的课程，这本身就说明需求是真实存在的，而且我认为站在你们这边的人越来越多。有趣的是，你一直在 Twitter 上分享的一个例子我觉得很有启发——所有人都在说 Claude Code 根本不在乎评估，他们只讲感觉（vibes），然后大家说，他们是最好的编程 agent，所以显然这是对的。但最近，所有人都在谈论 Codex，说 OpenAI Codex 更好，大家纷纷转过去，而他们非常推崇评估。

Shreya Shankar： 我知道。

Lenny Rachitsky： 是啊。

Shreya Shankar： 这每次都让我哭笑不得。互联网上的人太不一致了。我最喜欢的一件事是昨天，我和几个实验室同学出去吃甜品什么的，有人问：“你更喜欢 Codex 还是 Claude？“另一个人说：“我喜欢 Claude。“然后又有人说：“但新版 Codex 更好。“接着第一个人说：“哦，但我上次看是两天前了，所以我的看法——可能我信息不够新了。“我当时心想，天哪。

Lenny Rachitsky： 确实如此，确实如此。这就是我们生活的世界。天哪。好，我想问一下关于评估最常见的误解，以及做好评估的最高效技巧。也许你们各自分享一两条。先从误解开始，我先问 Hamel。人们围绕评估最常见的误解有哪些？

关于评估的常见误解

Hamel Husain： 排第一的是：“嘿，我只需要买个工具，插上去，它就会替我做评估。我为什么要操心这个？我们活在 AI 时代了，AI 不能直接做评估吗？“这是最常见的误解，而且人们太想要这个东西了，以至于真的有人卖这种东西，但它不奏效。这是第一个。

Lenny Rachitsky： 瞎说，人类还是很厉害的。我觉得这是个好消息。

Hamel Husain： 第二个我经常看到的是：“根本不看数据。“在我的咨询工作中，人们带着问题来找我，我第一句话就是：“让我们去看看你的 trace。“你会看到他们眼睛瞪大，“什么意思？“我说，“对，现在就看。“他们很惊讶我会去看单条 trace，而每次——百分之百——都能从中学到很多、找到问题所在。我觉得人们就是不知道看数据有多强大，就像我们在这个播客里演示的那样。

Shreya Shankar： 我同意。

Lenny Rachitsky： 这就是前两个？好的。

Shreya Shankar： 对。然后，我想补充的第三个误解是：做评估没有唯一正确的方法。不正确的方法有很多，但正确的方法也不止一种。你需要思考你的产品现在处于什么阶段、你有多少资源，然后制定最适合你的方案。它总是会涉及某种形式的错误分析，就像我们今天展示的那样，但具体如何将这些指标落地运营，会根据你所处的阶段而变化。

评估的实用建议

Lenny Rachitsky： 太好了。好，有什么技巧和建议想留给大家的？无论他们刚开始接触评估，还是想改进现有的做法？

Shreya Shankar： 第一条建议就是：不要害怕看你的数据，不要感到恐慌。我们尽量把这个流程做得结构化，但不可避免地会有各种问题冒出来，这完全没问题。你可能觉得自己做得不完美，这也完全没问题。目标不是完美地做评估，而是切实改善你的产品。我们向你保证，不管你怎么做，只要你做了这个流程中的部分环节，你就会找到可以切实改进的地方，然后你会在自己的流程上不断迭代。

另一条建议是，我们非常支持用 AI。在整个过程中，用 LLM 来帮你整理思路。这可以是任何事情——从最初的产品需求开始，想清楚如何为自己组织这些需求，想清楚如何根据你创建的开放编码来改进产品需求文档。不要害怕用 AI 来帮你更好地呈现信息。

Lenny Rachitsky： 很好，所以不要害怕，在整个过程中尽可能多地用 LLM。

Shreya Shankar： 但不是用它替代你自己。

Lenny Rachitsky： 对。好，太好了。工作还在，太好了。Hamel？

打造看数据的工具

Hamel Husain： 对。让我分享一下屏幕，因为我想展示点东西。在 Shreya 说的之上，如果你在这期播客里记住了一句话，很可能就是”看你的数据”这几个字。这件事太重要了，以至于我们教学中建议你应该自己创建工具，让这件事变得尽可能简单。之前做现场演示时我展示了一些标注数据的工具。跟我合作的大多数人，他们意识到这件事的重要性后，会用 vibe coding 做自己的工具——或者说，他们自己动手做工具。现在做这个比以往任何时候都便宜，因为 AI 可以帮你。

AI 非常擅长创建简单的 Web 应用——展示数据、写入数据库，都很简单。以 Nurture Boss 的案例来说，我们想消除看数据的所有阻力。你看到的这些截图就是他们自己做的应用的样子。它就是——好，有不同的渠道：语音、邮件、短信；有不同的对话线程；系统 prompt 默认隐藏起来。一些小的体验改进。然后他们还有这个轴心编码的部分，你可以看到红色的错误计数。他们把那部分自动化了，做得很漂亮，而且几个小时就做出来了。要做一个通用的”看数据”工具真的很难，你不必一开始就走到这一步，但值得思考的是：让看数据这件事尽可能简单，因为，再说一次，这是你能从事的最强大的活动，是 ROI 最高的活动。有了 AI，就把所有阻力都去掉吧。

Lenny Rachitsky： 太棒了。再说一次，我觉得 ROI 这一点非常重要，我们甚至还没充分展开。这里的目标是让你的产品变得更好，从而让你的业务更成功。这不仅仅是一个用来抓 bug 之类的小练习。这是让 AI 产品变好的方法，因为用户体验就是用户与你的 AI 交互的方式。

Hamel Husain： 完全同意。甚至可以说，我们教学生的是——“嘿，当你在做这些评估时，如果你看到有什么问题，直接去修。“整个重点不是拥有一套漂亮的评估套件可以指给别人看、炫耀说：“看我的评估。“不是的，直接修你的应用，让它变得更好。如果问题是明显的，直接做。完全同意你。

Lenny Rachitsky： 太好了。还有一个问题我没问，但我觉得大家都在想——做这件事要花多长时间？通常第一次做需要多久？

时间投入与持续性

Shreya Shankar： 我可以就我自己参与的应用来回答。通常，我会花三到四天时间，和相关人员一起做初步的错误分析。大量标注工作，感觉我们到了一个可以创建 Hamel 那种电子表格的阶段，大家都认可并信服了，甚至搭建了几个 LLM judge 评估器。但这属于一次性成本。一旦我搞清楚如何将其集成到单元测试中，或者写了一个自动对样本运行的脚本，再设一个 Cron Job 让它每周自动执行，之后我大概——我不知道，我发现自己可能花更多时间看数据，因为我就是对数据有种饥渴感。我就是太好奇了。我从这个过程中获益良多，它让我在与任何人的合作中都远超他人，所以我想继续做下去，但并不是非做不可。之后大概每周花 30 分钟吧。

Lenny Rachitsky： 所以基本上前期需要一周时间，然后每周花 30 分钟来持续改进和扩充你的评估套件？

Shreya Shankar： 对，真的不需要那么多时间。我觉得人们只是被前期投入的时间吓到了，然后以为必须一直这样做下去。

Lenny Rachitsky： 太棒了。还有什么想分享的，想留给听众的吗？在进入非常令人期待的闪电问答环节之前，还有什么想重点强调的观点吗？

过程中的乐趣

Hamel Husain： 我想说的是，这个过程其实非常有趣。就是——好吧，你要看数据，哦，听起来像是在做标注。实际上，我昨天就在看一个客户的数据，完全一样的流程。那是一个发送邮件的应用，发招聘邮件，试图吸引候选人来应聘职位。我们决定开始看 trace。“来，看看你的 trace。“我们看了一条 trace，我第一眼看到的就是一封措辞为”Given your background，blah blah blah”的邮件。我立刻问了对方，这就是你戴上产品经理的帽子、保持挑剔的时候，也是有趣的部分所在。我说，“你知道吗？我很讨厌这封邮件。你自己喜欢这封’modify your background’的邮件吗？“当我收到一条”Given your background”开头的消息，我直接就删掉了。我心想，“这是什么，‘鉴于你在机器学习方面的背景’之类的？“我觉得这就是模板化的东西。我问对方，“我们能做得更好吗？这听起来像是千篇一律的招聘邮件。“他们说，“哦，对，也许吧。“因为他们之前还挺自豪的，觉得”AI 做的没错啊，发了正确的邮件、正确的信息、正确的链接、正确的名字，一切都对。“有趣的地方就在这里——戴上产品经理的帽子，深入去看：这真的够好吗？

Lenny Rachitsky： 在进入令人期待的闪电问答环节之前，我想确保我们提到一点——这只是做好这件事所需知识的冰山一角。但我认为这是我所见过的关于如何做好评估的最佳入门指南。

Shreya Shankar： 好的。

课程与深入学习

Lenny Rachitsky： 我想我们做到了。但你们两位教授了一门课程，对那些真正想精通这件事、认真对待的人，会深入得多。请分享一下课程中你们教了但我们没涵盖的内容，以及作为 Maven 上你们课程的学生还能获得什么。

Shreya Shankar： 我可以谈谈教学大纲，然后 Hamel 来说课程的各种福利。我们按照一个完整的生命周期来讲：错误分析，然后是自动化评估器，然后是如何改进你的应用，如何为自己建立那种飞轮。我们还有一些专题内容，据我们发现几乎没人听说过、也没人教过，这让人很兴奋。一个是，如何为错误分析构建你自己的界面。我们会展示我们实际构建的界面，还会现场用新数据实时编码。我们展示如何使用 Claude code cursor，或者当天心情想用的任何工具来构建这些界面。我们还广泛讨论了成本优化。我合作过的一些人，他们到了一个阶段：评估做得很好，产品也很好，但一切都非常昂贵，因为他们在用最先进的模型。我们怎样才能在某些场景下把最昂贵的 GPT-5 替换成 5-nano、4-mini 之类的，省下很多钱，同时保持相同的质量？我们也会给一些这方面的建议。Hamel，到你了。我们还有很多福利。

Lenny Rachitsky： 好，说说那些福利。

Hamel Husain： 好，福利。我最喜欢的福利是一本 160 页的书，写得非常细致，是我们创建的，逐步讲解整个评估流程的细节来配合课程。你不用坐在那里做所有笔记。我们已经替你做了所有艰苦的工作，详细记录并整理好了一切。这个真的非常有用。另一个很有意思的东西，也是我从你这里得到的灵感，Lenny——这是一门 AI 课程。教育不应该只是看讲座和做作业。学生应该也能接触到一个帮助他们学习的 AI。我们做的事情是——就像你有 LennyBot 一样。

Lenny Rachitsky： .com。

Hamel Husain： 对，lennybot.com，我们用和你相同的软件做了同样的东西，把我们对评估说过的一切都放了进去。每一节课、每一次答疑、每一次 Discord 聊天，任何博客、论文，我们公开说的和课程内讲的所有内容，全部放进去了。我们找了一批学生测试过，他们觉得很有帮助。我们给所有学生 10 个月的免费无限制访问权限，随课程一起。

Lenny Rachitsky： 太棒了。然后之后会开始收费？

Hamel Husain： 我也不知道。我一个月一个月来。我不知道这个东西会走向哪里。

Lenny Rachitsky： 八个月之后再说吧。我刚才在想，这整个访谈其实可以就让我们的 bot 互相聊天。

Shreya Shankar： 那太有意思了。我会看，但只看 10 分钟，之后我就不知道它们在说什么了。

Lenny Rachitsky： 嗯，可能 30 秒吧。话说你们用语音模式训练了吗？那是 Delphi 产品中我最喜欢的功能。如果没有的话，你们应该试试。

Hamel Husain： 哦，我想——我不记得了，我得去看看。

Lenny Rachitsky： 你们一定要做。现在有了这期播客的内容，你可以用它来训练。是 11Labs 驱动的，效果非常好。好的，那他们怎么才能——我想这样就行——他们报名课程之后就能获得这些。

Shreya Shankar： 对，报名课程后会收到一系列邮件。一切都会很清楚，希望如此。

Lenny Rachitsky： 太棒了。好的。

Shreya Shankar： 我们还有一个 Discord，所有上过课的学生都在里面。那个 Discord 非常活跃。我连度假坐飞机的时候都逃不掉通知。

Lenny Rachitsky： 又甜蜜又痛苦。太不可思议了。好的，到此为止，我们进入了非常令人期待的闪电问答环节。我有五个问题。准备好了吗？

Shreya Shankar： 准备好了。来吧。

闪电问答

Lenny Rachitsky： 开始吧。好的，我在你们两位之间轮流提问。想说就说，想跳过也行。第一个问题，Shreya，你最常推荐给别人的两三本书是什么？

Shreya Shankar： 我喜欢推荐一本小说，因为生活不只有评估。最近我读了 Min Jin Lee 的《Pachinko》，非常棒的一本书。另外我还在读《Apple in China》，作者名字一时想不起来了，但这更像是一部纪实作品，由一位记者撰写，讲述 Apple 过去几十年在亚洲如何开展大量制造流程，非常开眼界。

Lenny Rachitsky： 太棒了。Hamel？

Hamel Husain： 好的，我就带在身边。我是个书呆子。好吧，我没 Shreya 那么酷。我其实最喜欢的是教科书。这本是非常经典的一本，Mitchell 的《Machine Learning》。它是偏理论的，但我喜欢的地方在于，它真正让人深刻理解奥卡姆剃刀原理不仅适用于科学，也适用于机器学习和 AI，还有工程领域——很多时候，更简单的方法泛化能力更强。这是我从那本书里深深内化的一个道理。我还很喜欢这本，又一本教科书。我说了我是个书呆子嘛。这本也很老了，是 Norvig 的《Algorithms》。我喜欢它因为它展现了人类的智慧，里面有大量巧妙而实用的计算技巧。

Shreya Shankar： 他就在街那边，他和 Berkeley。

Lenny Rachitsky： 做那项研究的人？

Shreya Shankar： 对，教科书作者。

Lenny Rachitsky： 太酷了。天哪，书呆子们，我爱了。好，下一个问题。最近最喜欢的电影或电视剧？先从 Hamel 开始。

Hamel Husain： 好的，我是一个两个孩子的爸爸——不好意思，两个孩子。对，我是两个孩子的爸爸，基本上没时间看电视或电影，所以就看孩子们在看什么。上周我把《Frozen》看了三遍。

Lenny Rachitsky： 才三遍？哦好吧，上周。好吧。

Hamel Husain： 这就是我的生活。

Lenny Rachitsky： 很好，Hamel。《Frozen》，我喜欢。好，Shreya。

Shreya Shankar： 我没有孩子，所以能给出精彩的答案。实际上，我和我丈夫最近在看《The Wire》。我们小时候没看过，所以开始看了，真的很棒。

Lenny Rachitsky： 我感觉每个人都会经历这个阶段——人生中总会有一刻决定，我要看《The Wire》了。

Shreya Shankar： 对，我们现在就处于那个阶段。

Lenny Rachitsky： 那基本上要花你一年时间。很棒，真的是一部好剧。天哪，但集数太多了，每集都一小时。

Shreya Shankar： 我知道，我知道。

Lenny Rachitsky： 真是一个巨大的承诺。

Shreya Shankar： 我们一星期能看两三集，进度很慢。

Lenny Rachitsky： 值得的。好，下一个问题。有没有最近发现并且特别喜欢的产品？先从 Shreya 开始。

Shreya Shankan： 说实话，我非常喜欢用 Cursor。还有 Claude Code。我来说说为什么。我首先是一个研究者，我写论文、写代码、搭建系统，什么都做。我发现一个工具……我非常看好 AI 辅助编程，因为我总是需要身兼数职。现在，我对自己构建的东西和写论文的对象可以更有野心了，所以我对这些工具非常兴奋。Cursor 是我的入门点，但我发现自己一直在努力跟上所有这些 AI 辅助编程工具的更新。

Lenny Rachitsky： Hamel？

Hamel Husain： 我也很喜欢 Claude Code，我喜欢它是因为我觉得它的 UX 非常出色。里面倾注了很多心血。作为一个终端应用能做得这么精致，真的令人印象深刻。

Lenny Rachitsky： 讽刺的是，你们两位都爱 Claude Code，而它不过是靠感觉检查做出来的。

Shreya Shankar： 我觉得这是错的，它不只是靠感觉检查。

Lenny Rachitsky： 好吧。还有两个问题。Hamel，你有没有最喜欢的座右铭，在工作或生活中经常回想起来的？

Hamel Husain： 持续学习。像初学者一样思考。

Lenny Rachitsky： 很好。Shreya？

Shreya Shankar： 我喜欢这个。对我来说，就是始终试着站在对方的角度思考。我有时会在网上看到一些争论，比如关于评估竞赛的辩论，然后我会认真想，“好吧，设身处地想一想，也许有一个善意的解读。“我觉得我们团结在一起远比互相争斗更强大。我对评估的愿景不是让 Hamel 和我成为亿万富翁，而是让每个人都能构建 AI 产品，大家达成共识。

Lenny Rachitsky： 以及每个人都成为亿万富翁。

Shreya Shankar： 对。

Lenny Rachitsky： 太棒了。最后一个问题。当我有两位嘉宾时，我总是喜欢问这个问题。先从 Hamel 开始。你最喜欢 Shreya 的哪一点？Shreya，我等下也会问你同样的问题。

Hamel Husain： 好的。Shreya 是我认识的最有智慧的人之一，尤其是考虑到她比我年轻那么多。说实话，我觉得她比我明智得多。她非常脚踏实地，看问题非常平和。我一直对此印象深刻。

Lenny Rachitsky： Shreya？

Shreya Shankar： 我最喜欢 Hamel 的地方是他的能量。我不认识任何人能像 Hamel 那样持续保持冲劲和活力。我经常想，如果不是因为 Hamel，我对评估的热忱可能早就消退了。每个人的生活中都需要一个 Hamel，这是肯定的。

Lenny Rachitsky： 好了，现在我们每个人的生活中都有一个 Hamel 了。这期太棒了，完全是我期望的样子。我觉得这是我见过的最有趣、最深入、最易懂的评估入门。真的非常感谢你们两位抽出时间。最后两个问题。大家在哪里可以找到你们？在哪里可以找到课程？听众怎样才能帮到你们？先从 Shreya 开始。

Shreya Shankar： 你可以通过电子邮件联系我，地址在我的网站上。Google 我的名字就能找到我的网站，这是最简单的方式。课程的话，如果你 Google “AI Evals for engineers and product managers”，或者直接搜 “AI Evals course”，就能找到。我们之后会发一些链接，方便大家找到。如何帮到我们？对我来说一直有两件事。一是有问题时尽管问我，我会尽快回复。另一件是告诉我们你们的成功案例。支撑我们继续做下去的一件事，就是有人告诉我们他们实施了什么、做了什么，一个真实的案例。Hamel 和我看到这些会非常兴奋，真的能让我们继续走下去，所以请多多分享。

Hamel Husain： 找到我很容易。我的网站是 Hamel.dev，我会把链接给你们。也可以在社交媒体上找到我，LinkedIn、Twitter。最有帮助的事情，也是 Shreya 说的——如果教评估的不只是我们两个人，我们会非常高兴。我们希望其他人也来教评估。任何博客文章、写作，尤其是你们在学习过程中想要分享的内容，我们都很乐意帮忙转发和推广。

Lenny Rachitsky： 太棒了，非常慷慨。非常感谢你们两位来到这里。我真的很感激，你们两位事情那么多，谢谢。

Shreya Shankar： 谢谢 Lenny 邀请我们，也谢谢你的所有赞美。

Lenny Rachitsky： 我的荣幸。大家再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留下评论，这真的能帮助更多听众发现这个播客。你可以在 Lennyspodcast.com 找到所有往期节目或了解更多关于节目的信息。下期再见。

术语表

原文中文
11Labs11Labs（语音 AI 公司，保留原文）
agreement一致性（指 judge 与人类判断的吻合程度）
Andrew NgAndrew Ng（知名机器学习学者，保留原名，中文领域亦通行此写法）
axial codes轴心编码
bad smell坏味道（源自软件工程中的 code smell 概念，指值得警惕的信号）
benevolent dictator仁慈的独裁者
bucket桶（分类桶）
CICI（持续集成，Continuous Integration，保留原文）
cohort队群
cosine similarity余弦相似度
criteria drift标准漂移
Cron JobCron Job（定时任务，保留原文）
DelphiDelphi（AI 数字分身平台，保留原文）
DiscordDiscord（社区沟通平台，保留原文）
dogfoodingdogfooding（指团队使用自己开发的产品进行测试的做法，保留原文）
error analysis错误分析
evals评估
failure mode失败模式
flywheel飞轮（指自我强化的正反馈循环）
foundation models基础模型
GeminiGemini
generalize泛化（机器学习术语，指模型在新数据上的表现能力）
hallucination score幻觉评分
HubSpotHubSpot（知名营销与销售软件公司，保留原文）
jank糙（指粗糙、不完善的表现）
Julius AIJulius AI
Jupyter notebookJupyter notebook
Likert scaleLikert 量表（一种常用评分量表）
LLM as a judgeLLM as a judge（用 LLM 充当评判者来评估输出质量的评估方式，保留原文）
MMLUMMLU（大规模多任务语言理解基准测试，保留原文）
moat护城河（商业竞争壁垒）
observability可观测性
Occam’s razor奥卡姆剃刀（科学哲学原则，指在解释同一现象时，假设越少越好）
open coding开放编码
pivot table数据透视表
promptprompt
RAG retrievalRAG 检索
rubrics评分标准
StatsigStatsig（A/B 测试与实验平台公司，保留原文）
stochastic随机的
surface area表面积
taxonomy分类体系
theoretical saturation理论饱和
tracetrace（追踪）
vibe checks感觉检查

此文档由 AI 分片翻译（translate_long_document）