为什么 AI 评测成为产品构建者最热门的新技能｜Hamel Husain 与 Shreya Shankar（排名第一的评测课程创作者）
Why AI evals are the hottest new skill for product builders | Hamel Husain & Shreya Shankar (creators of the #1 eval course)
Guests: Hamel Husain, Shreya Shankar
Full transcript · Read the full conversation in order, with its original context.
Contents1 chapter
§01原文文稿 · 00:00–1:46:05§01原文文稿 · 00:00–1:46:05
要打造出色的 AI 产品，你必须非常擅长构建评估。这是你能开展的投资回报率最高的工作。
这个过程很有意思。每个做过这件事的人都会立刻着迷。构建 AI 应用时，你会学到很多。
妙就妙在，你不必反复做很多遍。对大多数产品来说，只要做一次这个过程，之后就在此基础上继续推进。
目标不是把评估做到完美，而是切实改善产品。
我之前没有意识到，围绕评估竟有这么多争议和风波。很多人的立场都非常鲜明。
过去有人被评估坑过。有人把评估做得很糟，于是大家不再信任它，继而会说：‘哦，我反对评估。’
人们对评估最常见的几种误解是什么？
最常见的一种是：‘我们生活在 AI 时代，难道不能让 AI 自己来评估吗？’但这行不通。
你们在文章中用过一个我很喜欢的词，就是‘开明的独裁者’这个概念。
在做开放式编码时，很多团队会陷入让委员会来完成这件事的困境。许多情况下，这完全没有必要。你不该把流程搞得昂贵到无法执行。可以指定一位你信任其判断的人来负责。他应当具备领域专业知识，很多时候会是产品经理。
今天的嘉宾是哈梅尔·侯赛因和施雷娅·尚卡尔。过去一年里，这档播客最受关注的话题之一就是评估的兴起。Anthropic 和 OpenAI 的两位首席产品官都表示，评估正成为产品构建者最重要的新技能。此后，我邀请过的许多顶尖 AI 构建者也不断谈到这个话题。两年前，我从未听过‘评估’这个词；如今它无处不在。上一次产品构建者必须掌握一项新技能才能成功，是什么时候？（00:01:41）哈梅尔和施雷娅在推动评估从一个晦涩、神秘的主题变成 AI 产品构建者最必备的技能之一方面发挥了重要作用。他们开设了权威的线上评估课程，该课程恰好是 Maven 平台排名第一的课程。如今，他们已为 500 家公司的 2,000 多名产品经理和工程师授课，其中包括 OpenAI 和 Anthropic 团队的大批成员，以及其他所有主要 AI 实验室的人员。（00:02:07）这次对话中，我们会大量展示而非空谈。我们将演示如何开发有效的评估，解释评估究竟是什么、长什么样，回应许多关于评估的主要误解，给出开始为产品构建评估时可以采取的头几步，并分享哈梅尔和施雷娅过去几年积累的大量最佳实践。这一期是你能找到的、关于评估世界最深入却又最易理解的入门讲解。坦率说，即使我没有什么产品可写评估，它仍让我很想亲自去写。我想你看完也会有同感。（00:02:41）如果这场对话让你感到兴奋，一定要看看哈梅尔和施雷娅在 Maven 上的课程。我们会在节目说明中附上链接。购买课程时使用代码 LENNYSLIST，可享课程价格七折五优惠。接下来，让我们欢迎哈梅尔·侯赛因和施雷娅·尚卡尔。（00:02:58）本期节目由客户服务领域排名第一的 AI 智能体 Fin 赞助。如果你的客服工单不断积压，你就需要 Fin。Fin 是市场上表现最好的 AI 智能体，平均解决率为 65%。即便最复杂的客户问题，Fin 也能解决。没有其他 AI 智能体表现得更好。在与竞争对手的正面比拼中，Fin 每次都获胜。更换新工具确实可能让人担心，但 Fin 可在任何客服系统上运行，无需迁移。这意味着你不必彻底改造现有系统，也不必承受面向客户的服务延迟。（00:03:31）超过 5,000 位客户服务负责人，以及 Anthropic、Synthesia 等顶尖 AI 公司都信任 Fin。Fin 由持续改进的 Fin AI 引擎驱动，该系统让你能轻松完成分析、训练、测试和部署，因此 Fin 也能持续改善你的成果。如果你准备好改造客户服务并扩大支持规模，不妨以每次解决仅 99 美分的价格试用 Fin。Fin 还提供 90 天退款保证。访问 fin.ai/lenny，了解 Fin 如何为你的团队服务。网址是 fin.ai/lenny。（00:04:05）本期节目还由 Dscout 赞助。当今的设计团队既要快速推进，又必须做对。Dscout 正是为此而生。Dscout 是专为现代产品和设计团队打造的一体化研究平台。无论你在进行可用性测试、访谈、问卷调查，还是实地研究，Dscout 都能帮你轻松连接真实用户，迅速获得真实洞察。你甚至可以直接在平台内测试 Figma 原型。无需在多个工具之间周旋，也不用苦苦寻找难以联系的参与者。凭借行业内最受信赖的用户样本库和 AI 驱动的分析，你的团队可以在不放慢脚步的情况下，以更清晰的认识和更强的信心打造更好的产品。如果你准备好简化研究流程、加快决策并做出有影响力的设计，请访问 dscout.com 了解更多。网址是 dscout.com。你所需的答案，帮助你充满信心地行动。哈梅尔和施雷娅，非常感谢你们来到这里，欢迎做客播客。
谢谢邀请。
是的，非常期待。
我更期待。好，几年前我从未听过‘评估’这个词。现在，它几乎成了我播客里最热门的话题之一。核心观点是：要打造出色的 AI 产品，你必须非常擅长构建评估。此外，世界上一些增长最快的公司，基本上都在为 AI 实验室构建、销售和提供评估。我刚请 Mercor 的首席执行官上过播客。所以这里正发生一件非常重大的事。我想借这次对话帮助大家深入理解这个领域，但先从基础讲起。评估究竟是什么？对于完全不知道我们在说什么的人，请先简要解释一下评估。我们从哈梅尔开始。
当然。评估是一种系统衡量和改进 AI 应用的方法，一点也不必让人害怕或觉得高不可攀。它的核心，其实就是针对 LLM 应用做数据分析，并系统地查看这些数据；在必要时围绕某些事项建立指标，以衡量正在发生什么。这样你就能迭代、做实验并加以改进。
这是一个很好的宽泛理解。为了让大家对我们所说的内容有更具体、更直观的认识，如果再深入一层来解释，甚至能展示一个例子，就更好了。怎样才能更深入地理解评估是什么？
假设你有一个房地产助手应用，但它没有按你期望的方式工作。它可能没能按你的要求给客户写邮件，可能调用了错误的工具，也可能出现各种其他错误。在有评估之前，你只能猜。你或许会修改一条提示词，同时希望这个改动没有弄坏别的地方；你也可能依赖凭感觉检查，这完全没问题。（00:07:11）凭感觉检查是好的，一开始也应该这样做，但它很快就会变得难以管理，因为随着应用规模增长，很难继续依赖这种检查。你会觉得无从下手。评估能帮助你创建指标，衡量应用的表现，并让你更有把握地改进应用。你拥有了一个可以据此迭代的反馈信号。
为了说得更具体一点，设想这个房地产助手或许在帮人预约房源，或者参观开放日。这个智能体会与人交谈、回答问题、为他们提供指引。作为构建它的人，你怎样知道它给出的建议和回答是否可靠？它会不会说了完全错误的话？（00:08:04）评估的思路，本质上就是建立一组测试，告诉你这个智能体有多频繁地做了你不希望它做的事。‘错误’可以有多种定义，例如凭空编造信息，或以非常奇怪的方式回答。我对评估的理解，告诉我是否不对，就是像代码的单元测试一样。你在笑。你好像在说：‘不，你这个傻瓜。’
不，我不是这么想的。
好，好，好，你说。这个比喻听起来怎么样？
好。我喜欢你先前说的宽泛定义。评估是衡量应用质量的一大类方法。单元测试是其中一种。也许你希望 AI 助手具备某些不可妥协的功能，单元测试能够检查这一点。但因为这些 AI 助手承担的是高度开放的任务，你可能还想衡量一些更模糊或更有歧义的内容，例如它们如何回应新类型的用户请求，或者数据分布是否出现变化，比如出现了原本没想到会使用你的房地产助手的新用户。随后你会意识到，可能需要用不同方式来满足这群新用户。（00:09:24）所以，评估还可以是定期查看数据、发现这些新用户群体的方法。评估也可以是你想长期追踪的指标，例如追踪用户是否说‘是的，点赞，我喜欢你的消息’。你需要的可能是非常基础、未必直接与 AI 相关的东西，但它们都能回到改善产品的这个飞轮中。因此总体而言，单元测试只是这个大拼图中的很小一部分。
太棒了。你们还带来了一个评估实例，可以准确展示我们到底在谈什么。我们一直在谈宏大的概念，不如调出一个例子，让大家看看：‘这就是评估。’
好的，我先稍微交代一下背景。呼应施雷娅刚才所说的，非常重要的一点是，不要把评估只当成测试。很多人会掉进一个常见陷阱，直接跳到测试这一步，心想：‘我来写些测试。’但通常这并不是你该先做的事。你应先做某种数据分析，以确定到底该测试什么。这和软件工程略有不同，因为在软件工程中，你对系统将如何运行有更多预期。LLM 的覆盖范围大得多，且具有很强的随机性，所以这里的情况有所不同。（00:10:47）我今天要展示的是一个房地产案例，不过属于另一类房地产案例，来自一家名为 Nurture Boss 的公司。我可以共享屏幕，展示他们的网站，帮助你稍微了解这个使用场景。我来共享屏幕。这是一家我合作过的公司，叫 Nurture Boss。它是面向管理公寓的物业经理的 AI 助手，协助处理潜在客户咨询、客户服务、预约等各种任务。物业经理会做的各类运营工作，它都能提供帮助。你大致能看出他们在做什么。这是个很好的案例，因为它具备现代 AI 应用的许多复杂性。（00:11:40）你可以通过聊天、短信、语音等许多渠道与 AI 互动；它也会进行工具调用，包括大量用于预约、查询房源可用情况等的工具调用。它还会通过 RAG 检索客户、物业等信息。因此，就 AI 应用而言，它相当完整。这家公司非常慷慨地允许我将他们的数据用作教学案例。我们已经对数据做了匿名化处理。今天我要讲的是：怎样开始为 Nurture Boss 构建评估的第一步，以及我们为什么要这么做？（00:12:36）我们先进入最初阶段，也就是所谓的错误分析：查看应用数据，先弄清哪里出了问题。我接下来会打开一个可观测性工具。这里用什么工具都可以。我只是恰好把数据载入了一个叫 Braintrust 的工具，但任何工具都能载入。我们没有特别偏好的工具。在我们和你一起写的博客文章中，同一个案例用的是 Phoenix Arize；我想 Aman 在你的博客文章中也是用 Phoenix Arize。还有 LangSmith。这些都是可用的不同工具。（00:13:29）屏幕上看到的是应用日志，我来展示一下。这里是某位客户与 Nurture Boss 应用的一次具体交互，我把它全屏显示。它详细记录了期间发生的一切，称为追踪记录，也就是一系列事件日志的工程术语。追踪记录这个概念早已存在，但对 AI 应用尤其重要。（00:14:12）AI 为完成工作所需的各种组件、信息和内容都被记录下来，我们正在查看这些记录。这里有一条系统提示词，写着：‘你是一名 AI 助手，担任 Retreat at Acme Apartments 的租赁团队成员。’记得我说过数据已匿名化，所以才会叫 Acme Apartments。‘你的主要职责是回复现有住户和潜在住户的短信。你的目标是提供准确、有帮助的信息。’诸如此类。随后还有大量细节，规定我们希望它如何行为。
顺便问一句，这是这家公司实际在用的系统提示词吗？
是的，没错。
太厉害了，真酷。
这是真实的系统提示词。
这太了不起了，因为很少能看到一家真实公司产品的系统提示词。很多时候这类东西就像他们的核心机密，所以光这一点就已经很酷。
是的，确实很酷。你能看到各种不同功能和使用场景，例如安排看房、处理申请、如何与不同类型的人交流的指引，等等。用户直接问：‘有带书房的一居室吗？我在虚拟看房中看到过。’接着你可以看到 LLM 调用了一些工具。它调用‘获取个人信息’工具，取回这个人的资料；然后又获取小区的可租情况，也就是查询这个公寓小区的房源数据库。（00:16:01）最后，AI 回答：‘嗨，我们有几套一居室公寓可供选择，但没有明确标为带书房的。这里有几个选项。’（00:16:12）随后它又说：‘如果有带书房的房源，可以告诉我吗？’（00:16:16）接着又说：‘我目前没有关于一居室公寓可租情况的具体信息。’（00:16:23）用户说：‘谢谢。’（00:16:25）AI 回答：‘不客气。如果还有其他问题，欢迎随时联系。’这就是一个追踪记录的例子，我们正在看一个具体数据点。对 LLM 应用做数据分析时，重要的一件事就是查看数据。你可能会想：‘日志这么多，又乱，里面发生了这么多事。究竟要怎么看这些数据？难道要淹没在数据里吗？又该怎么分析？’（00:17:07）事实证明，有一种完全可控的方法，而且不是我们发明的。它在机器学习和数据科学中已存在很久，叫作错误分析。面对这类数据，第一步就是写笔记。好，你得戴上产品经理的帽子，这也是我们为什么要和你聊这个，因为产品人员必须在场，也必须参与这项工作。通常开发者并不适合做这件事，尤其当它不是一个编程应用时。
我理解你这么说的原因，是因为这就是产品的用户体验。人们和这个智能体交谈，基本上就是整个产品，因此产品人员深度参与其中很合理。
对。我们来回顾这段对话。用户询问房源是否可租，AI 说：‘哦，我们没有。祝你愉快。’现在，对一个帮助你管理潜在客户的产品来说，这样好吗？你觉得这是我们希望出现的结果吗？
不太理想。
对，不太理想，我很高兴你这么说。很多人会说：‘哦，很好啊。AI 做对了，它查了以后说没有可租房源，事实也确实没有。’但如果你戴着产品经理的帽子，就知道这不对。所以你只要在这里快速记一笔。你可以点进来写笔记。每个可观测性应用都能写笔记。你不需要试图把所有问题都弄清楚。这个案例中，它确实没有做对，但你只需快速写下：‘本应转交给人工处理。’
我们看着你这样操作时，正如你提到的，你之后还会解释更多。这看起来非常手工，也难以扩展，但如你所说，这只是流程中的一步，背后有一套体系。这只是第一个案例。
是的，而且不必查看全部数据。你只要抽样看一看，就会惊讶于自己能学到多少。每个做这件事的人都会立刻着迷，并说：‘构建 AI 应用时，这可能是你能做的最有价值的事。’你会学到很多，然后发现：‘嗯，我不希望它这样工作。好。’这只是一个例子。（00:19:58）记下这条笔记后，我们可以继续看下一条追踪记录。这就是下一条。我刚按了键盘上的一个快捷键。我回去看看。
而这些工具让你能轻松快速地浏览很多记录并添加笔记。
对。这是另一个案例。系统提示词类似，不必再全部看一遍，直接看用户的问题。用户说：‘好，我一整天都在给你发短信。’这不是挺有意思吗？接着用户说：‘请。’好，这属于应用里的一个错误。更准确地说，这是一个短信应用，客户通过短信这一渠道与系统交流，而这里收到的内容非常混乱。你能看到它有些不合逻辑，词语被截断，比如‘与此同时’，系统就不知道该怎么回答。因为人们发短信时会写很短的片段，常把一句话拆成四五轮发送。所以在这种情况下……
那遇到这种情况该怎么办？
对，这属于另一种错误。
嗯。
它更像是：‘我们没有正确处理这次交互，这是一个技术问题。’而不是：‘AI 没有完全按我们想要的方式行事。’所以这也要记下来。
这依然很酷。
对。
你居然也能在这里发现这个问题，真厉害。否则你根本不会知道这种事在发生。
对，你可能根本不知道这件事正在发生。所以你只需写一条笔记，例如：‘短信导致对话流程很别扭。’
我喜欢你用了‘别扭’这个词。它说明在这个阶段，做法可以非常非正式。
对，本来就该放松一点，别想得太复杂。不过这件事是有方法的。大家总会问：怎么做？要不要找出一条追踪记录里的所有问题？该记什么？答案是：只记下你看到的第一个错误，也就是最上游的错误。不要担心所有错误，只要捕捉第一个发现的错误，然后停下，继续下一条。你会越来越擅长这件事。头两三条可能很痛苦，但之后可以很快看完很多条。（00:22:38）这是另一个案例，我们再次跳过系统提示词。用户问：‘嗨，我想找两到三居室、一到两间浴室的房子。你们提供虚拟看房吗？’（00:22:51）系统调用了一堆工具，随后回答：‘嗨，莎拉。目前有一套三居室、两卫半的公寓，租金为 2,175 美元。很遗憾，目前没有两居室选项。我们提供虚拟看房。你可以预约看房，’诸如此类。可事实恰好是，他们根本没有虚拟看房。
嗯，不错。
所以它在幻觉出不存在的东西。此时你需要带入作为工程师，甚至产品人员的背景知识，然后说：‘这有点奇怪。既然没有提供虚拟看房，就不应该跟用户说有。’（00:23:32）于是你写下：‘声称提供虚拟看房。’就这样记一笔。你会发现，我们看到的错误类型多种多样，而且短时间内就学到了很多关于应用的信息。
在这个阶段，大家常问：‘好，我明白正在发生什么了。能不能让 LLM 替我完成这个过程？’
嗯，好问题。
我很喜欢哈梅尔刚才的例子，因为我们通常发现，当要求 LLM 做这种错误分析时，它只会说这条追踪记录看起来很好，因为它没有理解某件事是否是糟糕产品信号所需的背景知识。比如，关于安排看房的幻觉。如果我把那段内容放进 ChatGPT，问它：‘这里有错误吗？’我可以向你保证，甚至愿意打赌，它会回答：‘没有，做得很好。’（00:24:34）但哈梅尔知道：‘哦，我们实际上并没有虚拟看房功能。’所以在这种场景里，亲自手工做这件事极其重要。之后我们可以再谈谈流程中何时适合使用 LLM，但眼下最大的陷阱就是人们会想：‘让我用 LLM 自动完成这个步骤。’
你觉得未来会不会出现这样的智能体，它拥有那些背景知识，能够完成这件事？
哦，不，不，不，抱歉。错误分析的某些部分适合由 LLM 来做，我们可以在播客后面谈。但现在这个自由形式记笔记的阶段，不适合交给 LLM。
明白了。你们把这一步称为开放式编码，对吗？
对，完全是。
很好。你们在文章中还用过另一个我很喜欢、也很契合这一步的词，就是‘开明的独裁者’。能不能谈谈这是什么意思？施雷娅，也许你来讲？
这个词其实是哈梅尔想出来的。
那还是请哈梅尔来讲吧。
没问题。我们也会在这个案例中展示 LLM 自动化，因为我们会把这个例子完整走一遍。
太棒了。
所以，‘开明的独裁者’只是一个醒目的说法，指的是做开放式编码时，很多团队会因让委员会来完成这项工作而陷入困境。而在许多情况下，这完全没有必要。人们会很不自在，心想：‘好，我们希望每个人都认同，每个人都参与。’诸如此类。但你需要排除这些干扰。深入观察会发现，在许多组织中，尤其是中小型公司，你可以指定一位你信任其判断的人。也可以让少数人来做，而往往一个人就够了。让这项工作切实可行非常重要。你不该把流程搞得昂贵到无法实施，否则会得不偿失。（00:26:36）这就是‘开明的独裁者’背后的想法：尽可能从各个维度简化这件事。稍后我们还会谈到，把 LLM 用作评判者时，你需要一个二元评分。不要想‘这是 1、2、3、4、5 分中的哪一分？’不要给它打等级分，因为那会拖慢流程。
为了确保‘开明的独裁者’这一点说得足够清楚，基本上，这个人就是——
再把‘开明的独裁者’这一点说清楚：基本上，这个人负责做笔记，理想情况下，他是相关领域的专家。比如涉及法律时，可能由法律专业人士负责，也可能是产品经理。对于该由谁来承担这个角色，你有什么建议？
对，应该由具备领域专业知识的人来做。在这个案例中，应当是了解租赁业务、尤其公寓租赁，并有足够背景判断情况是否合理的人。正如你所说，始终应该是领域专家。涉及法律，就由法律专业人士负责；涉及心理健康，则由心理健康专家负责，无论是精神科医生还是其他专业人士。
好。
不过，很多时候这个人就是产品经理。
明白了。所以建议是选定这个人。让他负责、充当独裁者，可能让人觉得不那么公平，但他是开明的，一切都会没问题。
对，会没问题的。这不是追求完美。你只是要取得进展，快速获得信号，从而知道该做什么；因为如果不小心，成本会无限膨胀。
好，很好。我们回到你的例子。
好，没问题。这是另一个案例。有人说：‘你们有什么优惠吗？’助手或 AI 回答：‘我们为军人提供九五折优惠。’用户接着换了个话题：‘你能告诉我有几层楼吗？有一居室可租吗？一楼有一居室吗？’AI 回答：‘好的，我们有几套一居室公寓可租。’然后用户想确认：‘其中有在一楼的吗？一居室多少钱？’而且这位用户还是现有住户，因此他还说：‘我需要提交维修申请。’（00:28:56）你能从中看到现实世界的混乱。助手只是调用了一个名为‘转接电话’的工具，却什么也没说，就突然执行了转接电话。我会说，这相当别扭，完全谈不上……
又一种别扭。
另一种别扭，不同类型的别扭。所以写开放式笔记时，不要只写‘别扭’，因为我们的目标是理解发生了什么，之后回看笔记时也要能理解。（00:29:24）因此只需写：‘未向用户确认电话转接。’不必完美，只要大致表达清楚发生了什么即可。
好。
假设我们开始做了。施雷娅和我建议至少做 100 条。大家总会问：‘要做多少条？’其实没有一个神奇数字。我们之所以说 100，是因为我们知道，一旦开始做，做完 20 条后，你会自动发现它非常有用，于是会继续做下去。（00:30:07）所以我们说 100，只是为了帮你跨过心理障碍，别觉得可怕。就像是：‘别担心，你只需要做 100 条。’对此也有一个术语。正确答案是：‘持续查看追踪记录，直到你觉得再也学不到新东西。’也许施雷娅可以谈谈——
对，这其实有一个术语——
——那个。
在数据分析和定性分析中，这叫作理论饱和。它的意思是，在经历了这些查看数据的过程后，什么时候可以停下来？就是当你达到了理论饱和：不再发现新的笔记类型、新的概念，也没有什么会实质改变流程下一阶段的内容。（00:30:57）这种判断需要培养一些直觉，所以人们通常一开始并不知道自己是否已达到理论饱和，这完全没问题。做两三轮案例后，你会形成这种直觉。很多人会发现：‘哦，好，我只需要做 40 条，只需要做 60 条，实际上只要做 15 条。’我也说不准。这取决于应用，也肯定取决于你对错误分析有多熟练。
你说人们会想多做一些，我想是因为他们会觉得：‘哦，我发现了这么多问题，我得看看这里还有什么在发生。’
正是。
是这样吗？
我保证，到某个时候，你不会再发现新类型的问题。
对，太好了。假设你已经做完 100 条，下一步是什么？
好。你做完了 100 条，现在手头有了这些笔记。这时可以开始让 AI 来帮忙。正如我们讨论的，亲自查看数据这部分很重要，不要把它过度自动化。
人类还是有工作的。这就是这里的结论，很好。
是的。
至少目前，审阅追踪记录这份工作还在。很好。
对，没错。现在你有了这些笔记。要把它们变成有用的东西，可以先做基础计数。基础计数是数据科学中最有力的分析技术之一，因为它简单，而且在很多情况下被低估，所以人们很容易上手。（00:32:33）第一步是把这些笔记交给 LLM 分类，具体有很多做法。就在录这期播客前，我让三个不同的编程智能体或 AI 工具来分类这些笔记。其中一种做法是：我把这些笔记直接从这个界面导出为 CSV，并上传到一个云端项目里。方法很多，但我展示的是最简单、最笨的做法，也就是最基础的做法。（00:33:13）我把 CSV 放进去，然后说：‘请分析下面这个 CSV 文件。’我告诉它，其中有一个元数据字段包含笔记；我使用了‘开放式编码’这个词，说：‘我有不同的开放式编码。’这是一个专业术语。LLM 知道开放式编码和轴心编码分别是什么，因为这些概念已经存在很久了，所以这些词能帮助我简化对任务的说明。
太棒了。提示词最后是在要求它创建轴心编码吗？
是的，创建轴心编码。它所做的是——
也许值得解释一下什么是轴心编码，或者这里的目的是什么。你手上有一堆杂乱的开放式编码，但其实并不是有 100 个截然不同的问题。许多问题是重复的，只是你的表述不同。而且在做开放式编码时，你本不该试图建立一套失败分类法。你只需要记下哪里不对，然后再组织起来，看看：‘最常见的失败模式是什么？’（00:34:19）所以，轴心编码本质上就是一种失败模式，是一个标签或类别。我们的目标是得到这些失败模式的聚类，找出最普遍的问题，然后就可以着手解决它。
这非常有帮助。基本上，就是把所有这些——
完全是。
——综合整理成类别和主题。真酷。我们会在节目说明中附上这个提示词，大家就不用坐在那里截图，再试着自己打出来。
对，好主意。然后 Claude 会分析这个 CSV 文件，决定如何解析它，诸如此类。我们不必操心所有这些细节，但它生成了一批轴心编码。如施雷娅所说，轴心编码本质上就是类别。比如：能力限制、失实表述、流程和协议违规、人工交接问题、沟通质量等。它建立了这些类别。（00:35:18）我是否喜欢所有这些类别？不完全是。有些我喜欢，这是一个不错的初稿。我可能会稍微改名，因为有些太笼统了。比如‘能力限制’究竟是什么？这个范围太宽，无法指导行动。我希望它更具可操作性，这样如果我决定它确实是个问题，就知道该怎么处理。我们稍后会继续谈。你可以用这种方法处理任何事情。虽然这是最笨的做法，但有时候，笨办法恰恰是开始行动的好办法。
这正是 LLM 真正擅长的：接收一大堆信息，并加以综合整理。
完全正确。它负责综合整理，让我们看得明白。注意，它不会自动提出修复方案，那是我们的工作；但现在，我们能更轻松地梳理这一大堆开放式编码。（00:36:05）这个用于生成轴心编码的提示词还有一个有意思的地方：如果愿意，你可以写得非常具体。比如，你可以说：‘我希望每个轴心编码都是真正可操作的失败模式。’LLM 或许就能理解并提出这样的类别。或者你可以说：‘我希望你按这些开放式编码处于用户故事的哪个阶段来分组。’所以，作为参与其中的产品经理或工程师，你可以发挥创意，采用最适合你的方式，这也会帮助你后续做改进。
所以并不存在一个权威提示词，说‘只能这么做’？
完全不存在。
你的意思是，可以迭代，看看什么方式对你有效？
完全可以。
有意思的是，这些工具现在不做这个吗？还是它们试过，只是做得不够好？
不，我不认为它们在做。我们一直在大声疾呼：‘拜托，拜托——’
哦，哇。
——‘做这个。’我确实觉得这有点难。哈梅尔和我在教授评估时发现，很多人实际上不知道这件事。也许是大家不了解它，也不知道该如何为它构建工具。希望我们能揭开其中一些神秘面纱。
再深入一点说，这不是每个人都会做、或者都知道的事。它是你们二人根据在其他公司从事数据分析和数据科学的经验发展出来的吗？
我想先说明，我们并没有发明错误分析。我们其实不希望发明新东西，那是个不好的信号。如果有人拿来一种完全新颖、没有建立在数百年理论和文献基础上的做事方法，我不知道，你应当对它稍加警惕。（00:37:42）但我们试图做的是提炼：为了理解 LLM 的错误分析，需要哪些新工具和技术？然后我们建立了一套课程或结构化方法。这些内容都非常针对 LLM，但开放式编码和轴心编码这些术语都根植于社会科学。
太棒了。你们这样讲，搞得我很想马上找个地方去做这件事。我没有 AI 产品可以用来做，但还是会觉得：‘哦，这肯定很有趣。’就坐在那里，找出自己遇到的所有问题，归类，再试着修复它们。
我喜欢这个想法。
哈梅尔调出了一个视频。你这里要展示什么？
对，我调出这个视频，是为了进一步说明施雷娅的观点：我们并没有发明任何东西。屏幕上是吴恩达，他是世界知名的机器学习研究者之一，也坦率地说，教过许多人机器学习。你能看到这是八年前的视频，他在讲错误分析。（00:38:45）这种技术长期以来一直用于分析随机性系统。我们只是沿用相同的机器学习思想和原则，把它们带到这里，因为这同样是随机性系统。
太好了。顺带一提，我们正在努力邀请吴恩达来上播客，目前在沟通，所以那会——
不错。
——很有意思。第二点，我很喜欢我今天刚发布的播客节目出现在你的推荐流里，而且位置很显眼，这让我很高兴。[听不清，00:39:13]。
很好。对，推荐算法相当不错。
对，就是这样。希望你点开它，别把我的算法搞坏了。好，很好。我们已经做了一些综合整理。我知道我们不会完整走完全部步骤，你们有一门完整课程，得花很多天才能学完这套流程。关于如何推进这个过程，你们还想分享什么？
好，这件事可以通过任何工具来做，在 ChatGPT 里用完全相同的提示词也一样有效。你可以看到，它生成了主轴编码。我很喜欢用 Julius AI，它是我最喜欢的工具之一。（00:39:45）Julius 是一款使用笔记本的第三方工具。我个人很喜欢 Jupyter Notebook，所以它更偏数据科学，不过现在也有很多产品经理在学着用笔记本，这很酷。它就像一个有趣的游乐场，你可以在里面写代码、查看数据。但我们不必深入展开。我只是想说，你可以用很多工具，AI 很擅长做这件事。（00:40:10）接下来进入有趣的部分。开始吧。现在我们有了这些主轴编码。我通常会先拿到开放编码，以及从云端项目或 ChatGPT 分配出的主轴编码，然后把它们汇总起来看看，比如：这些主轴编码是否合理？我会查看不同主轴编码与开放编码之间的对应关系，做一个思考练习：我喜欢这些编码吗？能不能改得更好？能不能进一步精炼？能不能更具体？不要泛泛而谈，而要让它们具体且可执行。（00:40:59）你可以看到，我这里归纳出的编码包括：看房预约安排、改期问题、人工交接或转接问题、输出格式错误、对话流程问题。我们在短信里就看到了对话流程问题。还有承诺会后续跟进却没有兑现的问题。（00:41:18）所以现在你可以做的是，把这些主轴编码汇总成一个列表。这是一个 Excel 公式，把编码收集成列表后，就得到一份由逗号分隔的编码清单。接着，你可以拿自己的笔记，也就是那些开放编码，告诉 AI。这里为了简单起见，我用的是 Gemini。再说一次，我们尽量保持简单：请始终将以下笔记归入下列类别之一。
给正在观看的朋友说明一下，我很喜欢你分享的这些提示词和公式。这是 Google 表格里的 AI 提示词。
我很喜欢。
基本上，你现在可以把这些轨迹归到不同的类别中。这里就是这样做的：我们把遇到的所有问题都归入其中一个类别。
而且这是自动完成的，非常令人兴奋。我的意思是，AI 在替你做这件事。这也说明，你的开放编码必须写得详细，对吧？你不能只写“很别扭”，因为 AI 读到“很别扭”时，没法据此分类。人也一样做不到，对吧？人还得回头想起你当初为什么说它“很别扭”。所以，开放编码写得相对详细很重要。
好，所以避免用“很别扭”这个词。这是个不错的经验法则。
对，或者至少要再配上另外十个词。
哦，好。什么是——
对，我是在开玩笑。
对，好。你们觉得大家还经常用哪些不太好的词？
我觉得问题不在于某些特定的词，而是人们的开放编码写得不够详细，所以很难分类。
很好。顺便问一下，你之所以要把它们重新映射回去，是因为比如 Claude 或 ChatGPT 给过你建议，而你又修改、迭代了这些建议，所以不能在每个类别里直接说“行，就这样，随便吧”，对吗？
对，对。
很好。
这确实是个很好的问题。你应该迭代并稍微想一想：我喜欢这些开放编码吗？它们对我来说真的合理吗？和 AI 做的任何事一样，让自己适度参与其中会很有帮助。
人在回路中。我们还有用武之地。很好。
如果我想让 AI 来做这一步的标注，我还喜欢增加一个新类别，叫“以上皆非”。这样，AI 就可以在主轴编码中回答“以上皆非”，这会告诉我：好，我的主轴编码还不完整。我们去看看这些开放编码，找出应新增哪些类别，或者想想如何改写其他主轴编码。
太棒了。很酷的一点是，你不需要反复做很多次。
不需要。
我想，对大多数产品来说，这个流程做一次后就可以在此基础上继续推进，只需要随着时间不断微调，对吗？
完全正确。而且它会变得非常快。大家每周做一次，30 分钟内就能完成这一整套流程。相比完全没有意识到这些问题，你的产品会立刻好很多。
对。想到自己居然会不知道这些事正在发生，实在太荒谬了。看着这个过程，我会想：你怎么可能不对自己的产品做这件事？
很多人完全不知道。
大多数人都不知道。对，我们会谈到这个。这方面有一整场争论要聊。好，你现在有了这张表，接下来是什么？
好，现在是揭晓的重要时刻，也是神奇的时刻。我们已经把自己认可的编码应用到了这些轨迹上。现在，见证奇迹的时刻到了：你可以开始计数。（00:44:56）这里有一张数据透视表，我们可以针对这些数据建立透视表，计算不同问题发生了多少次。结果是什么？在这些已经分类的轨迹中，我们发现了 17 个对话流程问题。我很喜欢数据透视表，因为你可以做很多很酷的事。你可以双击这些数字，说：“哦，好，我来看看这些记录。”不过这就扯远到数据透视表有多酷了。（00:45:25）但现在，我们已经对问题有了一个清晰的粗略切面，也从混乱中走向了某种思考：哦，你知道吗？这些是我最大的问题。我需要解决对话问题，也许还要解决这些人工交接问题。次数不一定是最重要的。也许有个问题特别严重，你就是想先修复它。但现在，你有了一种观察问题的方式，也可以开始思考其中哪些需要评测。（00:46:07）有些问题可能只是很低级的工程错误，不需要专门写评测，因为修复方法非常明显。比如输出格式错误，可能只是你忘了告诉大语言模型希望它如何格式化，提示词里甚至根本没说。那么，或许直接去修提示词就行。我们可以决定：要不要为此写一个评测？你可能还是想写，因为也许能只用代码测试它。你可以测试这个字符串是否具备正确的格式，而不用运行大语言模型。（00:46:53）所以，评测存在成本效益上的权衡。你不该对此走火入魔，但通常应该立足于实际错误。不要跳过这一步。我之所以花这么多时间讲它，是因为这正是大家容易迷失的地方。他们直接进入评测，说：“我来写几个测试。”事情就是从那里开始失控的。（00:47:24）好，假设我们想解决其中一个问题。比如我们要解决人工交接问题，但会想：“嗯，我不太确定怎么修。这带有主观判断：我们是否应该把事情交给人工？我一下子想不出修复办法。它本身并不特别显而易见。对，我可以改提示词，但我不确定，我没有百分之百的把握。”（00:47:56）那么，这可能就适合用“由大语言模型担任裁判”的方法。评测有不同类型。一种是基于代码的，如果能做，应该尽量做，因为成本更低。由大语言模型担任裁判则有点像元评测：你还得评测这个评测，以确认承担裁判角色的大语言模型判断正确。我们马上会谈到。好，由大语言模型担任裁判是一种方法。那么，怎样构建这样的裁判？
在进入这个话题之前，为了让大家准确理解你描述的两类评测：一种是你说的基于代码，另一种是由大语言模型担任裁判。Shreya，你能帮我们理解一下什么是基于代码的评测吗？本质上就是单元测试吗？这是个简单的理解方式吗？
对。也许“评测”不是这里最准确的术语，可以把它理解成自动化评估器。当我们发现这些失效模式时，我们想要的是：好，现在能不能用自动化方式检查这种失效模式的发生率，而不是让我手动标注、编码和分组？我想在成千上万条轨迹上运行它，还想每周运行一次。那么，你大概就应该构建一个自动化评估器来检查这种失效模式。（00:49:12）所谓基于代码还是基于大语言模型，是指：也许我能写一个 Python 函数或一段代码，检查一条轨迹中是否存在这种失效模式。对于某些情况这是可行的，比如检查输出是否为 JSON，是否为 Markdown，或是否足够简短。这些都可以用代码捕捉，至少也能近似地用代码捕捉。（00:49:38）这里说的由大语言模型担任裁判，指的是一种复杂的失效模式，我们不知道如何自动化评估。因此，我们也许会用一个大语言模型，评估这种非常狭窄、非常具体的交接失效模式。
我试着复述一下你描述的内容。你想测试你的智能体或 AI 产品在做什么。你问它一个问题，它返回一个回答。（00:50:05）测试它是否给出了正确答案的一种方式是：如果它在做某件稳定一致的事，你可以写代码来判断结果为真还是假。比如，它会不会说有虚拟看房？你可以问它。
对。
“你们提供虚拟看房吗？”它回答“是”或“否”，然后你可以针对这个具体回答写代码，判断它对不对。（00:50:27）但如果你问的是更复杂、并非二元的问题，在一种情况下，你需要人来判断它是否正确。为了免去人每次都审核所有内容，就让大语言模型替代人的判断，这就叫“由大语言模型担任裁判”。大语言模型充当裁判，判断它是否正确。
完全正确。你说得很到位。
很好。
大家总会想：“这至少和构建原始智能体一样难。”其实不是，因为你只要求裁判做一件事：评估一种失效模式。所以问题范围很小，这个大语言模型裁判的输出也只是通过或失败。它的范围被限定得非常紧，大语言模型裁判能够非常可靠地做好这件事。
这里的目标，只是拥有一套在上线到生产环境前运行的测试，用来告诉你事情是否按你的预期进行，你的智能体交互方式是否正确，对吗？
大语言模型裁判的妙处在于，当然可以在单元测试或持续集成中使用它，但也可以在线上监控中使用，对吧？我每天可以抽样 1,000 条真实的生产轨迹，运行大语言模型裁判，看看那里的失败率。这不是单元测试，但我们依然能得到一个极其具体的应用质量指标。
很酷。这是个非常好的观点，因为很多人只把评测看成一种脱离现实的东西，是在真正进入现实世界之前进行的测试。而你说的是，在现实世界里实际发生的情况，也应该完全这样做，对吗？
对。
测试你在生产环境中运行的真实产品？而且可以每天、每小时运行？
完全可以。
太好了。Hamel 这里有一个实际的“由大语言模型担任裁判”评测示例，我们来看看。
我喜欢 Shreya 把话题铺垫得这么好，非常感谢。这里是针对这一个具体失效模式的“由大语言模型担任裁判”提示词。正如 Shreya 所说，你应针对一种具体失效模式，而且要把它做成二元判断，因为我们要简化问题。我们不想问：“嘿，请按 1 到 5 分给它打分。它有多好？”在大多数情况下，这只是逃避作决定的狡猾方式。应该说：“不，你必须作出决定。它是否足够好？是或否？”（00:52:50）想清楚这个标准可能很痛苦，但你绝对应该这么做。否则，这件事会变得非常难以处理；而且当你汇报这些指标时，没人知道 3.2 和 3.7 分别意味着什么。
对，我们也经常看到这种情况，甚至是在网上那些由专家整理的内容中：比如“这是你的大语言模型裁判评估器提示词，这是一套 1 到 7 的评分尺度”。（00:53:15）我总会给 Hamel 发消息说：“哦，不。现在我们又得跟错误信息作斗争了，因为我们知道总会有人试一试，然后回来对我们说，‘哦，我的平均分是 4.2。’而我们只能说，‘好吧。’”
评测领域居然有这么多纷争，真是不可思议。我们会讲到这个。天哪。（00:53:37）本期节目由 Mercury 赞助。我使用 Mercury 办理银行业务已有多年，坦白说，我现在无法想象还有其他方式。我从大通银行转了过来，天哪，差别太大了。电汇、跟踪支出、让团队成员获得调拨资金的权限，都轻松得不得了。传统银行的网站和应用大多笨重难用，而 Mercury 经过细致设计，提供直观、简单的体验。
Mercury 经过细致设计，提供直观、简单的体验，并将你使用资金的各种方式整合到一个产品中，包括信用卡、开具发票、账单支付、团队成员报销和融资。无论你是想向承包商付款、让闲置现金获得收益的融资科技初创公司，还是需要向客户开票并确保其按时付款的代理机构，或是需要掌握现金流并获得融资的电商品牌，Mercury 都可以量身定制，帮助你的企业发挥最佳水平。看看超过 20 万名创业者喜爱 Mercury 的原因。访问 mercury.com，在线申请只需 10 分钟。Mercury 是一家金融科技公司，不是银行。银行服务由 Mercury 经联邦存款保险公司承保的合作银行提供。详情请查看节目说明。
好，这就是你的裁判提示词。做法没有唯一答案。可以让大语言模型帮你创建它，但还是那句话，要让自己参与其中。不要盲目接受大语言模型做出的内容，在这些情况中，我们也是这么做的。对于主轴编码，我们进行了迭代。你可以让大语言模型帮你写这个提示词，但务必读一遍、编辑一下，诸如此类。这不一定是完美提示词。这只是一个很粗略、刻意保持简单的例子，用来说明思路。比如，针对这个交接失效问题，我说：“我希望你输出真或假。”这是一个二元裁判，也是我们推荐的做法。然后我逐项说明：“什么情况下应当进行交接？”（00:55:33）好，明确提出的人工请求被忽略或陷入循环、政策规定必须转接、涉及住户的敏感问题、工具数据不可用、无法提供服务、当天到访或看房请求。诸如此类，这些情况需要和真人沟通。思路是：既然我从数据中知道这确实是个失效问题，我就有兴趣对它进行迭代，因为我知道它实际上经常发生。正如 Shreya 所说，最好不仅能用现有数据评估它，也能在生产数据上评估它，以了解它发生的规模。让我找到更多轨迹，也让我能持续迭代。我们可以拿这个提示词，再次使用电子表格。第一步是，好，当我做这个裁判时……我写好了提示词。（00:56:28）现在，很多人就停在这里，说：“好，我有裁判提示词了。完成，很好，直接上线吧。”提示词说什么，他们就照单全收：如果裁判说它错了，那它就是错了。他们把这当成福音，好像“大语言模型说它错了，那肯定就是错的”。不要这么做，因为这是让评测与实际情况不符的最快方式；而当人们失去对你评测的信任时，也会失去对你的信任。这一点非常重要。因此，在发布你的大语言模型裁判之前，要确保它与人的判断对齐。怎么做？你有那些主轴编码，要拿裁判与主轴编码进行比较，问：“嘿，它同意我的判断吗？我自己的裁判，它同意我吗？”直接测量。（00:57:18）这里，我说：“评估这条大语言模型轨迹。”再说一次，我只是用电子表格：“根据这些规则评估这条大语言模型轨迹。”规则就是我刚才展示的提示词。我问它：“好，是否存在交接错误？真还是假？”接着，这一列，让我稍微放大。H 列里是：“好，这个错误是否发生？”G 列是我认为该错误是否发生。你可以看到——
你是手动逐条判断的，你来做这件事。
对，对，我们已经做过了。我们已经手动看过一遍。并不是说还得再做一次，因为主轴编码给了我们这个捷径，我们已经完成了。如果需要更多数据，你可能要再看一遍。怎样正确做这件事有很多细节，比如你要切分数据、做很多安排，以免作弊。但我只想说明概念。基本上，你可以衡量一致性。现在，作为产品经理，你应该知道，很多人会直接看这个一致性指标。他们会说：“好，我的裁判在某个百分比的时间里和人类一致。”（00:58:41）听起来很吸引人，但这是一个很危险的指标，因为错误很多时候只发生在长尾中，并不经常出现。如果错误只在 10% 的情况下出现，那么只要裁判始终判定通过，就很容易有 90% 的一致率。明白吗？90% 的一致率在纸面上看起来不错，但可能有误导性。
它很少见，是一种罕见错误。对。
作为产品经理，或者任何人，即使不是由你自己来计算，只要有人向你报告一致性，你都应该立刻问：“好，告诉我更多。”你需要深入了解。他们会给你更多直觉。这里展示的是 Google 表格中这个具体裁判的矩阵，这同样是一个数据透视表，我们仍然保持简单、直接。行里是：人是怎么判断的？我是怎么判断的？是否存在错误，真还是假？接着，我的裁判判断是否存在错误，真还是假？
这里的直觉完全就是 Hamel 所说的：你需要查看每种错误。人类判断为假而裁判判断为真，或反过来，也就是这里非绿色对角线上的格子。如果它们太大，就去迭代提示词，让大语言模型裁判理解得更清楚，从而减少这种不对齐。你想达到这样一个状态：大多数……总会有一些不对齐，这没关系。我们的课程也会讲如何通过代码校正这种不对齐。但在这个阶段，如果你是产品经理，而构建大语言模型裁判评测的人没有做这一步，却说“它有 75% 的时间和人一致，我们很好”，他们既没有这个矩阵，也没有迭代到确保这两类错误降到零，那就是危险信号。去让他们修正。
太好了。这是一个很好的提示，告诉我们当有人把这件事做错时该看什么。
对。
实际上，可以带我们回到“由大语言模型担任裁判”的提示词吗？我想强调一个很有意思的点。最近我请过一些播客嘉宾，他们说：“评测就是新的产品需求文档。”你看这里，它完全就是这个。产品经理、产品团队会说明产品应该是什么样，列出所有要求，说明它该如何运作。他们做出一个东西，然后测试它，而且往往是手动测试。这里很酷的是，它完全是同一件事，但它会持续运行。它告诉你：“这个智能体应该如何回应”，而且方式非常具体。“如果是这个、这个、这个，就做那个。如果是这个、这个、那个，就做另一个。”我一次又一次听到的说法，在这里都能看到。这是产品需求文档最纯粹的形式：这个评测裁判准确告诉你产品应当如何表现，而且它是自动、持续运行的。
对，完全是这样。它来自我们自己的数据，所以当然体现了产品经理的预期。我发现很多人错在：他们还没看数据，就把自己的预期写了进去。但当我们查看数据时，会发现更多一开始根本想不到的预期，而这些最终都会进入这个提示词。
这很有意思。你的建议并不是在构建产品前，就直接跳到评测和“由大语言模型担任裁判”的提示词。你还是要写传统的一页纸产品需求文档，告诉团队我们在做什么、为什么做、成功是什么样子。但到最后，如果你用这一流程演化产品，大概可以从中提取内容，甚至改进那份原始产品需求文档。
我会说得更进一步：你会改进它……它会发生变化。你永远无法预先知道失效模式会是什么，也总会发现你觉得产品应该具备的新感觉。对于这些大语言模型，你得先看到它的表现，才真正知道自己想要什么。所以你必须保持灵活，必须看数据，必须……产品需求文档是思考这件事的一个很好的抽象，但不是终极答案，它会改变。
我很喜欢这个观点。Hamel 正在调出一份很酷的研究报告，这是关于什么的？
如果你想了解评测，这是你能读到的最酷的研究报告之一。它由一位名叫 Shreya Shankar 的人撰写。
天哪。
还有她的合作者。它叫《谁来验证已被验证的内容？》。
这是研究者能有的最好的名字。
谢谢，谢谢。
这件事应该让 Shreya 来讲。我认为这篇论文最值得关注的是评判标准漂移，以及她发现的内容。
我们做过一项非常有趣的研究。当时我们在做用户研究，参与者尝试编写大语言模型裁判，或只是验证自己大语言模型的输出。我觉得那是在评测在网上变得极其流行之前。这个项目始于 2023 年末。但作为研究者，真正萦绕在我脑中的问题是：“为什么这个问题这么难？机器学习和 AI 已经存在很久了，它们并不新鲜，但为什么这一次一切都这么困难？”我们对一群开发者做了用户研究，意识到：“好，新的地方在于你没法提前想好评判标准。人们在审阅更多输出后，对好与坏的看法会改变；他们往往要在看到 10 个输出之后，才想到原先根本不会想到的失效模式。”而且这些都是专家。他们此前构建过许多大语言模型管线，现在也构建过智能体，但你一开始永远不可能设想到所有情况。我觉得这对今天的 AI 开发非常关键。
这是个很好的观点，非常呼应我们刚才谈的内容。这就是我想调出这个的原因，就是……好——
背后的研究。
对，好，很好。你仍然要用原本的方式做产品，但现在有了这个非常强大的工具，帮助你确保构建出来的东西是正确的。它不会取代产品需求文档流程。很好。通常最后会有多少个，比如说，我不知道，“由大语言模型担任裁判”的提示词？我知道这显然取决于产品复杂度，但按你们的经验，大概是什么数量？
对我来说，大约四到七个。
就这么多。
并不多，因为正如 Hamel 之前所说，许多失效模式只要修一下提示词就能解决。你之前只是没想到要把它写进提示词，现在把它写进去就好。你不该为每件事都做这种评测，只针对那些棘手的情况：你已经在智能体提示词中描述了理想行为，它却仍然失败。
明白了。假设你发现一个问题并修好了。在传统软件开发中，你会写一个单元测试，确保它不再发生。你这里的意思是，如果它已经消失了，就不用费劲围绕它写评测了吗？
如果你想，当然可以写，但这整件事的关键在于排序。你的资源和时间有限，不可能为所有事都写评测，所以要优先处理那些更棘手的领域。
大概就是那些一旦说出类似 Grok 的“机械希特勒”这种话，就会给业务带来最大风险的问题。
哎呀。
很好。这让人很放心，因为要真正想清楚所有这些细节，这个提示词需要做很多工作。
但其中很多都是一次性成本。从现在起，你可以永远在自己的应用上运行它。
好，数据分析非常强大，会很快推动应用的许多改进。我们展示的是最基础的数据分析，也就是计数，人人都能上手。你还可以把数据分析做得更复杂，有很多不同的抽样方式和查看数据的方式。某种意义上，我们让它看起来很容易，但要做好它需要很多技能，需要培养一种直觉和嗅觉，知道如何梳理这些数据。比如，假设我发现了对话问题，也就是对话流程问题。如果我要进一步追查这个问题，可能会思考怎么找到其他我没有编码过的对话流程问题。我可能会从几个角度深入挖掘数据，具体做法有很多。这和你针对任何产品采用的传统分析技术非常相似，甚至几乎完全相同。
请让我们快速了解一下接下来会发生什么，然后我们再聊聊关于评测的争论和另外几件事。
构建好你的大语言模型裁判后，下一步是什么？我们发现，人们会尽可能在所有能用的地方使用它。比如，他们会把大语言模型裁判放进单元测试，建立这样一套机制：“这里有一些我们见过这种失效情况的轨迹示例，因为我们已经标注过它们。现在要把它们纳入单元测试，确保每次推送代码改动时，这些测试都会通过。”他们也会用它做线上监控。大家正在为此制作仪表盘，我觉得这很不可思议。我认为，正在这样做的产品，对自己的应用表现如何有非常敏锐的认识。人们不会谈论这件事，因为这是他们的护城河。这很合理：如果你是一款邮件写作助手，而且把这件事做得很好，你不会希望别人也做一款邮件写作助手，把你挤出市场。（01:08:41）我非常想强调，尽可能在线上使用你构建出的这些成果，并反复利用它们推动产品改进。Hamel 和我常常教大家怎么做到这里。到了这个点，有人突然领会了，然后就再也不回来找我们了。要么他们，我不知道，辞职了，不再做 AI 开发；要么他们从此知道该怎么做。我认为是后者，而且我觉得这非常强大。
只是看着你们这样做，就让我真正明白这是什么，也看清了这个流程有多系统化。我以前总以为你们只是坐在电脑前想：“好，我要确保哪些事情能正常运作？”而你们在这里展示的是一个非常简单、循序渐进的流程，它基于产品中真实发生的事情：如何捕捉问题、识别问题、给问题排优先级，然后在问题再次发生时发现并修复它们。
对，这不是魔法。任何人都能做，只是和学习任何新技能一样，你得练习这项技能，但你能做到。我觉得现在特别令人振奋的是，产品经理正在做、也能够做这件事，并且确实可以凭借这套技能构建非常非常赚钱的产品。
好，这正好引到前几天我们被卷入的那场发生在 X 上的争论。我没想到围绕评测有这么多争议和纷争。很多人的观点都非常强烈。Shreya，先请你简要说说围绕评测的重要性和价值，争论的双方各自是什么看法，然后再谈谈你的观点。
好吧，我会稍微调和一下，说我认为大家其实站在同一边。误解在于，人们对“评测”的定义非常僵化。比如，他们可能认为评测只是单元测试，或者认为评测只是数据分析，而不包括线上监控，也不包括监控产品特定指标，例如实际参与的聊天次数之类。我认为大家一开始对评测的理解都不同。还有一点是，过去人们曾被评测坑过。我觉得有人把评测做得很糟糕。一个具体例子是，他们试图做大语言模型裁判，但它没有和自己的预期对齐。他们到后来才发现这一点，于是不再信任它，然后就说：“我反对评测。”（01:11:14）我百分之百理解这种心情，因为你确实应该反对采用李克特量表的大语言模型裁判。我完全同意，我们也反对那种做法。许多误解来自两件事：人们对评测的定义过窄，以及有人没有把它做好、因此受挫，进而想避免其他人犯同样的错误。不幸的是，X 或 Twitter 这种媒介上，人们总在误解彼此的意思，于是就出现各种强烈观点：“不要做评测，它很糟糕。我们试过，行不通。我们是 Claude Code”，或者其他知名产品说：“我们不做评测。”所有这些背后其实有大量细微差别，因为很多应用都建立在评测的基础上。编程智能体就是个很好的例子。Claude Code 建立在 Claude 模型的基础上……不是基础模型，而是经过微调的 Claude 模型已在众多编程基准上接受过评估。这一点无可否认。
为了准确说明你刚才说的内容，我想 Claude Code 的负责人之一，也许是总工程师，曾上过一档播客。他说：“我们不做评测，我们只看感觉。”这里的“感觉”是指他们就直接使用它，凭感觉判断它对不对。
我认为那样也行。这其中有两点，对吧？第一，他们是站在同事为编程所做评测的基础上。
Claude 的基础模型。
完全正确。我们知道他们会报告那些数字，因为我们看得到基准，也知道谁在这些基准上表现好。另一点是，他们在一定程度上很可能确实系统地做错误分析。我敢打赌，他们会监控谁在使用 Claude、有多少人在使用 Claude、创建了多少个任务、这些聊天持续多久。他们大概也会在内部团队里进行自用测试。每当有地方不对，可能就会有一个提示，或有人把问题发给开发 Claude Code 的人。那个人会隐性地做某种 Hamel 所说的错误分析。所有这些都是评测，对吧？不可能存在这样一种情况：他们只是说“我做了 Claude Code，从此什么都不看”。不幸的是，当你不这样思考或不谈论这一点时，我认为社区……（01:13:39）社区中的大多数人是初学者，或者不了解评测、想要学习评测的人，这会传递错误的信息。当然，我不知道 Claude Code 实际在做什么，但我愿意打赌，他们正在以某种评测形式做这些事。
我还想说，编程智能体从根本上不同于其他 AI 产品，因为开发者就是领域专家，所以可以跳过很多环节。而且开发者整天都在使用它，因此既有一种自用测试，也有一种领域专业能力。你可以压缩这些活动，不需要那么多数据、反馈或探索，因为你自己就知道。因此，你的评测流程应该有所不同。
因为你看得到代码，也看得到它生成的代码。你能判断：“这个很好，这个很糟糕。”
对，对。我觉得很多人把编程智能体的经验泛化了，因为编程智能体是最早进入大众市场的 AI 产品。我认为，试图把这种经验大范围泛化是个错误。
还有一点是，工程师具备自用测试的习惯。很多应用是在特定领域构建 AI，但它们没有办法让医生自用测试。比如，医生不会主动去收集 AI 给出的所有错误建议，并对此保持宽容和开放。记住这些细微差别非常重要。
Shreya，我从你的话里听到的有意思的一点是：如果团队里的人非常密切地做数据分析、错误分析和高强度自用测试，他们本质上就是人工评测，而你认为这也属于评测的范畴。如果你有时间和动力，可以这样做；或者也可以把这些工作设置为自动完成。
完全正确，这也关乎技能。在 Anthropic 工作的人技能非常高。他们接受过数据分析、软件工程或 AI 等方面的训练。当然，任何人都可以通过学习这些概念达到那个水平，但大多数人现在还没有这些技能。
自用测试是个危险的说法，只因为很多人会说自己在自用测试。他们会说：“对，我们自用测试过了。”但他们真的做了吗？很多人并没有真正以形成完整反馈闭环所需的那种深度去自用测试。这是我唯一想补充的保留意见。
还有一种听起来像稻草人论证的说法：评测对比 A/B 测试。谈谈你们对此的想法，因为这似乎是争论的重要部分。大家会问：“如果已经有 A/B 测试来检验生产层面的指标，还需要评测吗？”
我认为 A/B 测试同样是评测的一种形式，对吧？做 A/B 测试时，你有两个不同的实验条件，再用一个量化某项事物是否成功的指标来比较。再说一次，在我们看来，评测就是对质量或某个指标进行系统化衡量。没有可供比较的评测，你实际上无法做 A/B 测试，所以也许只是我们的看法有点不同、很奇怪。
对，好。我听到的是，你认为 A/B 测试属于你们所做的一组评测。人们想到 A/B 测试时，通常是在说：我们在产品中改了某个东西，接着看它会不会改善某个我们在意的指标。这样够了吗？为什么还要测试每个小功能？如果它影响了我们作为企业关心的指标，我们会有一堆持续运行的 A/B 测试。
这就引出了一个很好的观点。我觉得很多人过早做 A/B 测试，因为他们一开始从未做过错误分析。他们只是从假设出发制定产品需求，并相信“我们应该测试这些东西”。但事实是，当你进入数据，就像 Hamel 展示的那样，你看到的错误并不是原本以为会出现的错误，而是一些奇怪的交接问题，或者，我不知道，短信那件事就很奇怪。我会说，如果你做 A/B 测试，而且它们是由今天展示的真实错误分析所驱动，那很好，去做吧。但如果只是像我们看到的那样，人们想依据自己假设中重要的事物去做，我会鼓励大家重新思考，并让假设扎根于现实。
你们对 Statsig 在 OpenAI 会做什么有什么想法吗？其中有什么有意思的地方吗？那是一笔大交易，一次巨额收购。一家做 A/B 测试的公司，大家都说：“A/B 测试就是未来。”你们怎么看？
我想稍微补充一下上个问题：为什么会有“A/B 测试对比评测”这种争论？我觉得，归根结底，评测是……人们正试图理解如何改进自己的应用，而他们本质上需要做的是……数据科学对产品是有用的。看数据，做数据分析。有很多不同的工具组合，你不必发明任何新东西。当然，你不一定需要完整的数据科学体系；在大语言模型情境下，它看起来会略有不同，只是略有不同。你的策略可能不同。所以，它真正的含义是：使用分析工具理解你的产品。现在，人们说“评测”这个词，试图划出一个新的事物，然后把评测和 A/B 测试分开说。但如果你拉远看，它仍然是和以前一样的数据科学。我认为造成困惑的是：“我们需要数据科学式的思考。”在 AI 产品中拥有这种思考方式很有帮助，就像它对任何产品都有帮助一样。这是我的看法。
这是个很好的观点。我觉得现在只是“评测”这个词会触发大家的情绪。
对。
如果你只是说：“我们只是在做错误分析，用数据科学理解产品在哪里出问题，并设置测试来确保我们知道——”
那太无聊了，听上去很无聊。不，不，不。我们需要像“评测”这样神秘的术语，才能真正带动势头。至于你问的 Statsig，我觉得很令人兴奋。坦白说，我不太了解它，因为我只是把它想象成一家公司……它有一个很多人使用的工具，而 OpenAI 或许只是恰好收购了它。我相信他们过去就一直在用它，也相信 OpenAI 的竞争对手也在用 Statsig，所以这次收购可能有某种战略意图。我不知道，我对此一无所知。但对我来说，这些都是比“它是否从根本上改变 A/B 测试，或让评测获得更高优先级”更大的问题。我觉得它们一直都很重要，OpenAI 一直都在做某种形式的评测。从历史上看，OpenAI 甚至会查看所有 Twitter 上的情绪，尝试做一些回顾性分析，再将其和产品联系起来。他们当然正在——
然后把它和产品联系起来。当然，他们会在发布新的基础模型前做一定程度的评测，但他们做得远不止这些。他们会说：“好，我们找出所有抱怨它的推文、所有抱怨它的 Reddit 讨论帖，再弄清到底发生了什么。”这说明评测非常非常重要。还没有人真正完全搞懂它。大家都在利用一切可获得的信号来源来改进产品。
我想说的是，我真的希望这次收购能在 OpenAI 内部带来变化或形成一个重点。到目前为止，很多大型实验室理所当然地专注于通用基准，比如多任务语言理解分数、人类评测之类。这些对基础模型非常重要，但它们与产品特定的评测关联不大，比如我们今天谈的交接这类问题，两者往往没有相关性。
对，它们和数学解题能力没有相关性，恕我直言。
没错。如果看看评测产品，比如直到最近一些大型实验室提供的产品，它们都没有错误分析功能。它们有一套通用工具，比如余弦相似度、幻觉评分之类的，但这行不通。这是一个不错的初步尝试，也还可以。至少你在做点什么，也许能让人们开始看数据。但我们最终希望看到的是，在评测过程中融入更多数据科学式的思考。这也是我们希望工具最终能做到的。
是的，Pamela 和我不该是地球上仅有的两个人，倡导以结构化的方式思考应用场景特定的评测。这让我百思不得其解。为什么全世界只有我们两个人在做这件事？到底哪里不对？我希望不只有我们，也希望更多人能意识到这一点。
你们在 Maven 上的课程是收入最高的课程，显然市场存在需求和兴趣。我想，站在你们这边的人也更多。一个有意思的例子是，你最近在 Twitter 上分享的内容很有启发性：人人都说 Claude Code 不在乎评测，它只讲感觉；大家又说，它是目前最好的编程代理，所以显然这种做法是对的。最近又有很多人在讨论 Codex，说 OpenAI Codex 更好，大家都在转用它，而它们又非常重视评测。
我知道。
对。
这每次都让我感慨。互联网太反复无常了。我最喜欢的一幕发生在昨天，我想是这样：我和几位实验室同伴出去吃甜点，有人问：“哦，你更喜欢 Codex 还是 Claude，或者别的什么？”另一个人说：“哦，我喜欢 Claude。”然后又有人说：“但新版 Codex 更好。”第一个人接着说：“哦，不过我上次看已经是两天前了，所以我的想法可能已经过时了。”我当时想：天哪。
太真实了，太真实了。这就是我们生活的世界。天哪。好，我想问问大家对评测最常见的误解，以及做好这件事最重要的技巧和诀窍。你们每人或许可以分别分享一两个。我们先从误解开始，我先问 Hamel。大家对评测最常见的几个误解是什么？
最常见的误解是：“嘿，我可以买个工具，插上去，它就会替你做评测。我为什么还要操心这个？我们活在 AI 时代，AI 难道不能直接做评测吗？”这是最常见的误解。人们太想要这种东西了，以至于确实有人在卖，但它并不好用。这是第一个。
看来人类依然很擅长这件事。我觉得这是个好消息。
我还经常看到第二种情况：根本不看数据。在做咨询时，人们总是带着问题来找我，我说的第一句话通常是：“我们来看看你们的追踪记录。”你会看到他们睁大眼睛，说：“什么意思？”我会说：“对，现在就看。”他们会惊讶于我真的要去看一条条具体的追踪记录，而每次都一定能从中学到很多，也总能找出问题所在。我觉得大家只是不了解，看数据究竟有多强大，就像我们在这期播客里展示的那样。
我同意。
主要就是这两个？好。
对。
还有别的吗，还是主要就是这两个？
哦，当然还有……我想补充的第三点是，做评测没有唯一正确的方法。错误的方法有很多，但正确的方法也不止一种。你必须考虑产品目前所处的阶段、自己有多少资源，然后找出最适合你的方案。正如我们今天展示的，方案总会包含某种形式的错误分析，但具体怎样把这些指标落地，会随你所处的阶段而变化。
太棒了。对于刚踏上评测之路，或只是想把已经在做的事情做得更好的人，你们想留给他们哪些技巧和建议？
第一条建议是，不要因为看自己的数据而紧张或害怕。我们努力让这个过程尽可能结构化，但难免还是会出现问题，这完全没关系。你可能会觉得自己做得不够完美，这也没关系。目标不是把评测做得完美，而是以可执行的方式改进产品。我们保证，无论你怎么做，只要做了这个过程中的一部分，你都会发现可以实际采取行动的改进方向，然后再从那里迭代你自己的流程。（01:27:14）另一条建议是，我们非常支持使用 AI。在整个过程中，用大语言模型帮助你整理任何想法。这可以涵盖从最初的产品需求开始的一切：想想怎样为自己整理这些内容，怎样根据你做出的开放编码改进那份产品需求文档。不要害怕用 AI 以更适合你的方式呈现信息。
很好，所以不要害怕，在整个过程中尽可能使用大语言模型。
但不是让它取代你自己。
对。好，太好了。看来还是有工作可做，这很好。Hamel。
对。我来共享一下屏幕，因为我想展示一些东西。接着 Shreya 的话说，如果你在这期播客里记住了什么，大概会是“多看数据”这句话。它非常重要，所以我们会教大家自己做工具，让看数据尽可能容易。在刚才的现场示例中，我展示过一些用于标注数据的工具。大多数和我共事的人意识到这件事的重要性后，都会用所谓的“氛围编程”做自己的工具，或者，我们还是别这么说。他们自己做了工具；如今这样做比以往任何时候都便宜，因为有 AI 可以帮忙。（01:28:40）AI 很擅长创建简单的网页应用，用来展示数据、写入数据库，都非常简单。对于 Nurture Boss 这个案例，我们想消除查看数据的一切阻力。你现在看到的是他们创建的应用界面的几张截图。很简单：他们有不同的渠道，语音、电子邮件、短信；有不同的会话线程；默认隐藏系统提示词。这些都是提升使用体验的小改进。然后，他们还有这一部分轴心编码功能，你可以看到用红色标出的不同错误数量。他们很好地自动化了这一部分，而且几个小时内就做出来了。想用一套通用方案满足所有人查看数据的需求很难。你不必立刻做到这一步，但值得记住的是，要让它尽可能容易，因为再说一次，这是你能从事的最有价值的活动，也是投资回报率最高的活动。有了 AI，就尽量消除所有阻力。
太棒了。再说一次，我觉得投资回报率这一点非常重要，我们甚至还没有充分谈到它。这里的目标是让产品变得更好，从而让业务更成功。这不只是为了发现 bug 之类问题的小练习。这是改进 AI 产品的方法，因为体验决定了用户如何与你的 AI 互动。
完全同意。我们教学生的是：“做这些评测时，如果看到哪里有问题，就直接去修。”重点不是拥有一套漂亮的评测体系，可以指着它、编辑它，然后说：“哦，看看我的评测。”不是这样。直接修好你的应用，让它变得更好。如果问题显而易见，就去做。完全同意你的说法。
太棒了。有个问题我刚才没有问，但我想大家会在意：这件事要花多长时间？通常第一次做要多久？
我可以说说我参与的应用。通常，我会花三到四天，和相关人员一起认真做最初几轮错误分析。要做大量标注，直到我们觉得可以像 Hamel 展示的那样建立电子表格，所有人都理解并认可这个方向，甚至再加入几个由大语言模型担任裁判的评测器。但这是一项一次性成本。一旦我弄清楚怎样把它整合进单元测试，或者有一个脚本能自动在样本上运行，我就会创建一个每周运行的 Cron Job。我想说，我自己可能会花更多时间看数据，因为我就是很想看数据，非常好奇。（01:31:23）这个过程让我收获很多，也让我在和他人合作时更有优势，所以我想继续做下去，但并非非做不可。之后我觉得每周大概 30 分钟就够了。
也就是说，前期基本花一周，然后每周花 30 分钟持续改进、补充你的评测体系？
对，真的花不了那么多时间。我觉得人们只是被前期投入的时间吓到了，然后以为必须一直不停地做这件事。
太棒了。在进入非常精彩的快问快答之前，你们还有什么想分享给听众，或者还有什么重点想再强调一下吗？
我想说，这个过程其实很有趣。好像是在看数据，听起来像是在做标注。其实昨天我刚看过一个客户的数据，走的完全是同样的过程。这是一个发送招聘邮件、试图让候选人申请职位的应用。我们决定开始看追踪记录，直接就开始了：“来，看看你们的追踪记录。”我们看了一条记录，我看到的第一件事是一封邮件，措辞是：“鉴于您的背景，诸如此类，诸如此类。”我马上就问了对方。这就是戴上产品经理的帽子、保持批判性思考的地方，也是有趣的部分。（01:32:55）我说：“你知道吗？我讨厌这封邮件。你喜欢‘鉴于您的背景’这种邮件吗？”我收到一句“鉴于您的背景，”开头的消息时，通常直接删除。我会想：“这是什么？鉴于你在机器学习方面的背景，诸如此类？”我会觉得：“这太泛泛了。”我问对方：“我们能做得更好吗？这听起来像一封千篇一律的招聘邮件。”他们说：“哦，对，也许可以。”因为他们对它很自豪，会说：“AI 做对了，它发出了包含正确信息、正确链接、正确姓名和一切内容的邮件。”而有趣的部分就在于，戴上产品经理的帽子，认真追问：这真的好吗？
在进入非常精彩的快问快答之前，我想确保我们谈到一点：我们现在只是触及了做好这件事所需知识的表面。我觉得这是我见过关于如何做好这件事的最佳入门介绍。
不错。
我想我们已经做到了。但对于那些真的想把这件事做好、认真投入的人，你们教授的课程要深入得多。请说说课程里还教了哪些我们没有涵盖的内容，以及学生参加你们在 Maven 上教授的课程还能得到什么。
对，我可以先简单介绍一下课程大纲，然后 Hamel 可以讲讲各种福利。我们会讲错误分析的完整生命周期，然后是自动化评测器，再然后是如何改进应用，以及怎样为自己建立这个飞轮。我们还有几个很特别的话题，据我们所知，几乎没有人听过或教过，这很令人兴奋。其中一个是：怎样为错误分析建立自己的界面？我们会讲解我们实际做过的界面，也会针对新数据现场编写这些界面。我们会展示如何使用 Claude Code、Cursor，或者当天觉得合适的任何工具来构建这些界面。（01:34:49）我们也会广泛讨论成本优化。我合作过的一些人到了某个阶段，他们的评测很好，产品也很好，但成本非常高，因为他们在使用最先进的模型。我们怎样用 5-nano、4-mini 之类的模型，替换最昂贵的 GPT-5 的某些用途，大幅节省成本，同时保持同样的质量？我们也会提供一些建议。Hamel，该你了。我们还有很多福利。
对，讲讲这些福利。
好，说说福利。我最喜欢的一项是，我们精心编写了一本 160 页的书，详细讲解如何做评测的整个过程，作为课程的配套材料。你不必坐在那里记下所有笔记。我们已经替你完成了繁重的工作，把内容详细记录并整理好了，这非常有用。还有一件很有意思的事，灵感来自你，Lenny：这是一门 AI 课程。教育不该只是看讲座、做作业。学生也应该能使用一个帮助他们的 AI。我们做的事情是，就像你有 LennyBot 一样。
点 com。
对，lennybot.com。我们用和你相同的软件做了类似的东西，把我们曾经说过的所有关于评测的内容都放进去了。每一节课、每一次办公时间、每一次 Discord 聊天、任何博客、论文，以及我们曾经在公开场合和课程内部说过的任何内容，全都放了进去。我们找一批学生测试过，他们说很有帮助。参加课程的所有学生都可以免费获得 10 个月的无限次访问权限。
太棒了。那之后你们会收费吗？
我完全不知道。我只是一个月一个月地过，还不知道这件事会走向哪里。
八个月后我们再想办法。我刚才在想，整场访谈本来应该让我们的机器人彼此对谈。
太棒了。我会看，不过只能看 10 分钟，然后我就不知道它们在说什么了。
对，也许 30 秒。顺便问一下，你们有没有用语音模式训练它？那是 Delphi 产品里我最喜欢的功能。如果还没有，你们应该试试。
哦，我想我不记得了，得去看看。
你们绝对应该这么做。现在有了这期播客，就可以用这些内容训练它。它由 ElevenLabs 驱动，效果非常好。好，那他们该怎么获得……我想没关系，等他们加入你们的课程后就会知道了。
对，报名参加课程后，你会收到很多邮件。希望一切都会很清楚。
太棒了。好。
我们还有一个 Discord 社群，里面是所有上过这门课的学生。那个 Discord 非常活跃，我去度假时，连在飞机上都会收到通知。
苦乐参半，苦乐参半。太不可思议了。好，接下来进入非常精彩的快问快答环节。我有五个问题要问你们，准备好了吗？
准备好了，开始吧。
来吧。好，我会在你们两人之间轮流提问。想分享就回答，不想回答也可以跳过。第一个问题，Shreya：你最常向别人推荐的两三本书是什么？
我喜欢推荐一本小说，因为生活不只有评测。最近我读了李敏金的《柏青哥》，是一本很棒的书。现在我还在读《苹果在中国》，作者的名字我一时想不起来了。这本书更像是一位记者写的纪实作品，讲述苹果如何在过去几十年间在亚洲开展大量制造流程，非常令人大开眼界。
太棒了。Hamel。
对，我就在这儿。我是个书呆子。好吧，所以我没有 Shreya 那么酷。我带来的其实是教科书，而且它们是我的最爱。这本是很经典的 Mitchell 的《机器学习》。它偏理论，但我喜欢它的一点是，它真正强调了奥卡姆剃刀原则不仅存在于科学中，也存在于机器学习和 AI 中。很多时候，尤其是在工程中，更简单的方法泛化得更好。这是我从那本书里深刻吸收的一点。我也非常喜欢这本，又一本教科书。我说过我是书呆子。这本也很老，是 Norvig 的《算法》。我很喜欢它，因为它体现了人类的巧思，包含许多聪明又实用的计算方法。
他们都在不远处的伯克利。
做那些研究的人？
对，教科书作者。
太酷了。天哪，书呆子，我喜欢。好，下一个问题：你最近最喜欢的电影或电视剧是什么？我先问 Hamel。
好吧，我是两个父母的爸爸。我有两个父母。抱歉，是两个孩子。对，我是两个孩子的爸爸，基本没什么时间看电视或电影，所以孩子们看什么我就看什么。过去一周里，我已经看了三遍《冰雪奇缘》。
才三遍？哦，好吧，是过去一周里。好。
这就是我的生活。
很好，Hamel。《冰雪奇缘》，我喜欢。好，Shreya。
对，我没有孩子，所以可以给出这些很棒的答案。其实，我和丈夫最近一直在看《火线》。我们小时候从来没看过，所以现在开始看，真的很棒。
我感觉每个人一生中都会经历这么一个阶段：最终决定，我要看《火线》。
我知道，所以我们现在正处于这个阶段。
感觉要占用你一整年的人生，但它很棒，是一部非常棒的剧。天哪，不过集数实在太多了，而且每集都有一个小时。
我知道，我知道。
投入可真大。
我们每周只能看两三集，所以进度很慢。
值得。好，下一个问题：你最近发现过什么特别喜欢的产品吗？我们从 Shreya 开始。
对，说实话，我非常喜欢用 Cursor。现在还有 Claude Code。我说说为什么。我首先是一名研究者，我写论文、写代码、构建系统，什么都做。我发现这类工具……我非常看好 AI 辅助编程，因为我总是得身兼数职。现在，我可以对自己构建的东西和所写的论文更有雄心，所以我对这些工具非常兴奋。Cursor 是我的入门点，但我发现自己总是在努力跟上所有这些 AI 辅助编程工具。
Hamel？
对，我非常喜欢 Claude Code。我喜欢它，是因为我觉得它的用户体验极其出色。能感觉到其中投入了很多用心。作为一个终端应用，它能做得这么好，真的很令人印象深刻。
讽刺的是，你们两个都喜欢 Claude Code，而它据说完全是靠感觉打造的。
我觉得这不对。它并不只是靠感觉打造的。
这就对了。好，还剩两个问题。Hamel，你有没有一句自己常在工作或生活中使用、不断回想的座右铭？
持续学习。像初学者一样思考。
很美。Shreya？
我喜欢这句。对我来说，是始终试着思考对方的论点。有时我会在网上看到一些争论，比如围绕“赶紧做评测”的辩论，并努力想：“好，把自己放在他们的处境里。这里大概存在一种更宽容的理解。”我觉得如果一开始就挑起争斗，我们不会比共同合作更强大。我对评测的愿景不是 Hamel 和我成为亿万富翁，而是每个人都能构建 AI 产品，而且我们都站在同一边。
或者说，让每个人都成为亿万富翁。
对。
太棒了。最后一个问题。每次有两位嘉宾时，我总喜欢问这个问题。我先问 Hamel：你最喜欢 Shreya 的什么？你最喜欢她的什么？我会反过来问她同样的问题。
对。Shreya 是我认识的人里最有智慧的人之一，尤其相对我而言，她还那么年轻。我觉得她真的比我有智慧得多。她非常踏实，对事物有很平和、均衡的看法。这一直都让我非常钦佩。
Shreya？
对。我最喜欢 Hamel 的是他的活力。我不知道还有谁能像 Hamel 一样，始终保持这样的动力和能量。我常常觉得，如果没有 Hamel，我会对评测少上心很多。每个人的生活里都需要一个 Hamel，绝对如此。
现在我们每个人的生活里都有一个 Hamel 了。这太不可思议了，完全符合我的期待。我觉得这是我见过关于评测最有意思、最深入，同时又最容易吸收的入门介绍。非常感谢你们抽时间来。最后两个问题：大家在哪里可以找到你们？在哪里能找到课程？听众又能怎样帮助你们？我先问 Shreya。
对，你可以通过电子邮件联系我，邮箱在我的网站上。搜索我的名字，是找到我网站最简单的办法。如果搜索“面向工程师和产品经理的 AI 评测”，或者直接搜索“AI 评测课程”，就能找到课程。希望这之后我们会提供一些链接，让大家更容易找到。怎样帮助我们？对我来说一直有两件事。第一，有问题时就问我，我会尽快回复。第二，告诉我们你们取得的成功。让我们持续投入的一件事，就是有人告诉我们他们实施了什么、做了什么，分享真实的案例研究。Hamel 和我都会为此感到非常兴奋，这真的会让我们继续前进，所以请分享。
对，找到我很容易。我的网站是 Hamel.dev，我会给你链接。你也可以在社交媒体、LinkedIn 和 Twitter 上找到我。最有帮助的事情，呼应 Shreya 刚才的话，就是如果教评测的不只有我们，我们会非常高兴。我们很希望其他人也教评测。无论是博客文章还是其他写作，尤其是当你在这个过程中学习到一些想分享的内容时，我们都很乐意帮忙转发或扩大传播。
太棒了，非常慷慨。非常感谢你们两位来到这里。我真的很感激，你们事务繁多，所以谢谢你们。
谢谢你邀请我们，Lenny，也谢谢你的诸多赞美。
不用谢。大家再见。非常感谢收听。如果你觉得这期内容有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅节目。也请考虑为我们评分或留下评论，这确实能帮助其他听众发现这档播客。你可以在 Lennyspodcast.com 找到所有往期节目，或进一步了解这档播客。下期见。