为什么 AI 评估正在成为产品构建者最炙手可热的新技能

摘要

评估（Evals）正在成为 AI 产品构建者必须掌握的核心技能。Anthropic 和 OpenAI 的首席产品官都曾公开表示，评估正在成为产品构建者最重要的新能力。Hamel Husain 和 Shreya Shankar 在 Maven 上教授排名第一的评估课程，已培训超过 2000 名产品经理和工程师，覆盖 500 家公司，包括 OpenAI 和 Anthropic 的团队。

评估的本质是对 LLM 应用进行系统化的数据分析与度量。其核心流程包含三个关键步骤：首先，通过错误分析（Error Analysis）和开放式编码（Open Coding）逐条审查应用日志，人工记录问题；其次，利用 LLM 将开放式编码归纳为轴向编码（Axial Codes），即结构化的故障模式分类，并通过计数排序确定优先级；最后，针对顽固性故障构建自动化评估器——可以是基于代码的简单检查，也可以是 LLM 作为裁判（LLM-as-a-Judge）的二元判定，后者需与人工标注对齐后方可上线。整个过程并非一次性完美设计，而是从数据出发、持续迭代改进的飞轮。评估不是目的，改进产品才是。

正文

什么是评估

Hamel 将评估定义为"系统化地衡量和改进 AI 应用"的方法。它的核心并不神秘，本质上就是对 LLM 应用做数据分析——用系统化的方式审视数据，在必要的地方创建指标，从而量化应用的运行状态，支撑迭代和实验。

Shreya 进一步指出，评估是一个很宽的光谱。它既包含类似单元测试的确定性检查，也涵盖对开放式任务质量的衡量，还包括对用户反馈指标（如点赞率）的长期追踪，以及对新用户群体的发现与适应。单元测试只是这个大拼图中的很小一块。

两人共同强调一个常见陷阱：许多团队一上来就想写测试，跳过了数据分析的步骤。在传统软件工程中，系统行为有较多确定性预期；而 LLM 应用的表现空间远更大，随机性更强，因此必须先做数据分析来锚定"该测什么"，再进入测试环节。

错误分析：从真实数据出发

开放式编码

错误分析的第一步是"开放式编码"（Open Coding），即逐条审查应用的追踪记录（Trace），为每条记录写下第一条发现的问题。Hamel 用 Nurture Boss——一个面向物业管理的 AI 助手——作为教学案例。该应用涉及聊天、短信、语音等多渠道交互，包含预约排期、查询空房等工具调用，以及 RAG 检索租户和房源信息，是一个典型的现代 AI 应用。

在 Braintrust 等可观测性工具中，每条追踪记录都包含系统提示词、工具调用链、LLM 回复等完整信息。审查时，需要戴上产品思维去审视：用户问"有没有带书房的一居室？"，AI 回答"目前没有带书房的一居室"然后就此打住——对物业管理而言，这等于白白丢失了一条潜在租客线索，正确做法应是转交人工。此时只需写下一句简短备注："应转交人工"。

审查的原则非常明确：只写第一条看到的错误，写完即走，转向下一条。备注不必完美，但应足够具体，避免使用"很烂"之类的模糊词。比如"未与用户确认即转接电话"比单纯的"janky"有用得多。

仁慈独裁者

在开放式编码环节，很多团队试图让委员会共同决策，Hamel 认为这完全不必要。他提出"仁慈独裁者"（Benevolent Dictator）的概念：指定一位你信任其品味的领域专家，由其独自做出判断。对物业管理应用来说，就是懂租赁业务的人；对法律应用来说，就是法律专家；对心理健康应用来说，就是心理卫生专业人士。很多时候，这个人就是产品经理。核心思路是：不要让流程变得过于昂贵以至于无法执行。你需要快速获取信号，而不是追求完美共识。这一原则同样适用于后续的 LLM 裁判设计——判定结果应为二元（通过/不通过），而非 1-5 分的量表，后者只是逃避决策的借口。

理论饱和

关于审查多少条追踪记录，两人建议至少 100 条，但这只是心理门槛。真正的停止标志是"理论饱和"（Theoretical Saturation）——当你在审查中不再发现新的故障模式时，就可以停了。这个概念源自数据分析和定性研究的经典理论。Shreya 提到，很多人在前 20 条之后就会上瘾，因为发现的每一个问题都让人恍然大悟。实际所需数量因应用而异：有时 15 条就够了，有时需要 60 条。经过两三轮实践，你会自然培养出何时饱和的直觉。

轴向编码：从混沌到结构

完成开放式编码后，下一步是将零散的备注归纳为结构化的故障类别——即"轴向编码"（Axial Code）。这一步非常适合借助 LLM 完成。Hamel 演示了最简单的方式：将备注导出为 CSV，上传至 Claude 项目，使用"开放式编码"和"轴向编码"这两个源自社会科学的术语来提示 LLM 进行分类。LLM 会返回诸如"能力限制""误报""流程违规""人工转交问题""沟通质量"等类别。

Hamel 强调，LLM 给出的分类只是第一版，必须人工审视和迭代。他会对照开放式编码和轴向编码的对应关系，判断哪些分类过于宽泛（如"能力限制"缺乏可操作性），然后将其改写为更具体、更可操作的版本——例如"预约排程与改期问题""人工转交问题""输出格式错误""对话流程问题""后续承诺未兑现"等。

Shreya 补充了一个实用技巧：在轴向编码中加入"以上皆非"选项。当 LLM 无法将某条备注归入现有类别时，就提示你分类体系尚不完整，需要回头补充或调整。

将最终确定的轴向编码用于自动分类后，即可用数据透视表进行计数。Hamel 在 Nurture Boss 的案例中发现：对话流程问题出现了 17 次，是最高频的故障模式；其次是人工转交问题。从混沌到秩序，只需基本的计数——这是数据科学中最强大也最被低估的分析技术。

两种自动化评估器

确定故障优先级后，需要决定为哪些故障构建自动化评估器。并非所有问题都需要评估器——有些是简单的工程错误（如提示词中遗漏了格式要求），直接修复即可。评估器的选择需要权衡成本与收益。

基于代码的评估器

Shreya 指出，当故障模式可以被代码捕获时，优先使用代码评估器。例如：检查输出是否为 JSON 格式、是否为 Markdown、是否在规定字数内。这类检查可以写成 Python 函数，无需调用 LLM，成本低、速度快。

LLM 作为裁判

当故障模式涉及主观判断时，就需要"LLM 作为裁判"（LLM-as-a-Judge）。以人工转交问题为例：AI 是否应在某次对话中转交人工？这是一个需要领域知识的判断，无法用简单代码判定。

LLM 裁判的关键设计原则：

1. 二元判定：输出只有"通过"或"不通过"，而非 1-5 分的量表。Shreya 和 Hamel 强烈反对 Likert 量表式评分，因为"3.2 和 3.7 之间没人知道区别是什么"，这只会让指标失去可解释性。
2. 聚焦单一故障模式：每个裁判提示词只评估一种故障，而非笼统地问"这段对话好不好"。将问题范围缩窄到极致，LLM 就能非常可靠地完成判定。
3. 来自真实数据：裁判的判定标准应源于你的错误分析，而非凭空想象。正是因为审查了数据，你才能发现"虚拟参观不存在却被告知存在"这类凭空想不到的故障。

校准裁判：对齐人工判断

写完裁判提示词后，最关键的一步是校准——验证 LLM 裁判是否与人工标注一致。Hamel 用 Google Sheets 演示了完整流程：将轴向编码（人工判断）与 LLM 裁判输出逐行对照，构建混淆矩阵（Confusion Matrix），检查两种关键错误类型——人工认为有问题但裁判说没问题，以及人工认为没问题但裁判说有问题。如果这两类错误过多，就迭代修改裁判提示词，直到对齐度达到可接受水平。

Hamel 特别警告：不要只看"一致性百分比"。当某种故障只占 10% 的长尾时，一个永远回答"通过"的裁判也能达到 90% 的一致性——但这完全是虚假的。Shreya 建议：如果有人向你报告"一致性 75%"，立刻追问混淆矩阵；如果对方拿不出来，那就是危险信号。

评估即 PRD

Lenny 指出，LLM 裁判提示词实质上就是"评估即 PRD"（Evals as PRDs）的具体体现——它精确列出了产品应如何表现，在什么条件下转交人工，什么行为属于违规，并以自动化方式持续运行。Shreya 深表认同，同时强调：裁判提示词必须从数据中提炼，而非在动手之前凭空编写。她的研究发现，人们关于"好"和"坏"的判断标准会随着审查更多输出而不断演变，许多故障模式只有在看到第 10 条输出时才能想到——这正是她论文"Who Validates the Validated?"的核心发现。

"谁验证了验证者？"：标准漂移的研究

Shreya 在 2023 年底的这项用户研究中发现：开发者无法预先确定评估标准，他们对"好"与"坏"的判断随着审查更多输出而持续变化，许多故障模式只有在实际看到输出之后才能意识到——即使是经验丰富的 LLM 管道和 Agent 开发者也是如此。这一现象被她称为"标准漂移"（Criteria Drift），它从根本上解释了为什么 AI 产品的评估不能一劳永逸地设计，而必须从数据出发、持续迭代。

评估领域的争议与辩论

"只看氛围"的立场

Claude Code 的负责人曾在播客中表示"我们不做评估，只看氛围"，引发广泛讨论。Shreya 对此有两层回应：第一，Claude Code 站在了其同事对编码基准评估的肩膀上——Claude 微调模型在多项编程基准上的优异成绩本身就是评估的成果；第二，Claude Code 团队很可能在内部进行了系统化的错误分析——监控用户使用数据、追踪对话数量和时长、收集内部内测反馈——这些本质上都是评估的不同形式。

Hamel 补充：编码代理是一类非常特殊的 AI 产品——开发者本身就是领域专家，而且全天候使用自己的产品，形成了极致的内测闭环。这种"领域专家即用户"的特质让编码代理可以省略很多正式评估流程，但不能将这种特例推广到其他 AI 产品。医生不会为了测试 AI 而容忍错误的医疗建议，法律从业者也不会为了内测而接受不合规的法律输出。

评估 vs A/B 测试

有人认为有了 A/B 测试就不需要评估。Shreya 的观点是：A/B 测试本身就是评估的一种形式——它需要先有评估指标才能比较两个实验条件。真正的问题在于：很多人在做 A/B 测试之前，从未做过错误分析。他们基于假设的产品需求来设计实验，但实际数据中的故障模式往往与假设大相径庭——正如 Nurture Boss 的案例所示，最频繁的问题是对话流程和人工转交，而非最初预想的那些。Shreya 建议：如果 A/B 测试的假设来源于真实的错误分析，那很好；如果只是凭空设想，则应先去做数据分析。

Statsig 被收购

关于 OpenAI 收购 A/B 测试公司 Statsig 的消息，Shreya 认为这更多是商业策略层面的动作，而非"评估变得更重要"的信号——评估一直很重要。Hamel 则希望这次收购能让 OpenAI 将注意力从通用基准（如 MMLU、HumanEval）转向产品级评估。目前大型实验室的评估产品往往只提供通用工具（如余弦相似度、幻觉评分），缺乏错误分析能力，而后者才是产品级评估的核心。

常见误区

Hamel 和 Shreya 总结了三大误区：

1. "买个工具就能做评估"：市场上确实有人兜售一键评估方案，但它不奏效。人必须参与审查数据和校准裁判的过程。
2. "不看数据"：在咨询工作中，Hamel 总是首先要求看追踪记录。每次客户都对他的要求感到惊讶，但每次也都能从逐条审查中发现关键问题。
3. "评估只有一种正确做法"：实际上存在多种正确路径，也有许多错误路径。评估的形式取决于产品阶段和资源约束，但错误分析始终是不可或缺的起点。

实用建议

不要害怕

Shreya 的第一建议是：不要被流程吓倒。过程中难免产生疑问，你也不会一次做到完美——但目标从来不是做完美的评估，而是可操作地改进产品。无论你执行了流程的哪一部分，都会找到可操作的改进方向。

善用 LLM 辅助

整个流程中都可以借助 LLM 来组织思路——从最初整理产品需求，到基于开放式编码改进 PRD，再到生成轴向编码。但有一条红线：不能让 LLM 取代你自己。开放式编码阶段尤其不能自动化，因为 LLM 缺乏领域上下文来判断"产品味道"是否正确——就像 Nurture Boss 案例中关于虚拟参观的幻觉，LLM 会认为 AI 表现良好，因为它根本不知道该物业不提供虚拟参观。

自建数据审查界面

Hamel 强调，"看数据"是整个流程中 ROI 最高的活动，因此应该尽量降低其摩擦。他建议用 AI 辅助编码来构建定制化的数据审查工具——Nurture Boss 团队仅用几小时就搭建了一个内部分析界面，包含按渠道筛选、隐藏系统提示词、自动统计轴向编码等功能。通用工具无法完美适配每个产品的审查需求，而 AI 让定制开发变得前所未有的廉价。

时间投入

Shreya 分享了她的时间安排：初次实施通常需要 3-4 天，完成错误分析、标注对齐、构建 LLM 裁判评估器。这是一次性投入。此后每周约 30 分钟即可维护——运行自动脚本抽样并审查。关键在于：不要被前期投入吓退，它是一次性的，之后回报持续且显著。

评估器通常只需 4-7 个

Shreya 指出，她通常最终只会构建 4-7 个 LLM 裁判评估器。许多故障通过直接修改提示词就能修复，无需专门构建评估器。评估器的构建应聚焦于那些"已在提示词中描述了理想行为但仍然反复出现"的顽固性故障。

从评估到飞轮

完成评估器构建后，Shreya 观察到团队会自然而然地将这些评估器嵌入多个环节：作为单元测试在代码提交时运行，作为在线监控每天抽样生产数据并追踪故障率，甚至构建仪表盘实时可视化应用质量。Shreya 认为，这正是许多顶级 AI 产品的护城河——他们不会公开分享这些评估体系，因为它们直接决定了产品竞争力的上限。

课程与资源

Hamel 和 Shreya 在 Maven 上开设的"AI Evals"课程覆盖完整的评估生命周期：错误分析、自动化评估器构建、应用改进飞轮，以及两个特色专题——用 AI 辅助编码自建错误分析界面、成本优化（如何在保持质量的前提下用更便宜的模型替换最贵的模型）。课程配套一本 160 页的详尽手册，以及一个基于 Delphi 平台构建的课程专属 AI 助手——它被灌入了课程的所有教学内容、办公时间录音、Discord 讨论记录和公开博文，学生可获得 10 个月免费无限制访问。

闪电问答

推荐书目：Shreya 推荐了李敏金的小说《柏青哥》（Pachinko）以及一本关于苹果在中国制造业布局的纪实作品；Hamel 则推荐了 Mitchell 的《Machine Learning》教材（强调奥卡姆剃刀原则在 AI 和工程中的普适性）和 Norvig 的《Algorithms》教材。

近期影视：Hamel 作为两个孩子的父亲，最近一周看了三遍《冰雪奇缘》；Shreya 正在和丈夫一起追《火线》（The Wire）。

喜欢的产品：两人都提到了 Cursor 和 Claude Code——Shreya 认为 AI 辅助编码让她作为研究者能更高效地跨角色工作，Hamel 则赞叹 Claude Code 作为终端应用的 UX 体验。

人生信条：Hamel——"保持学习，像初学者一样思考"；Shreya——"永远试着站在对方的角度思考"，她认为在评估争议中，慷慨地理解对立观点比挑起争斗更有建设性，愿景是让每个人都能构建 AI 产品，而非在争论中消耗。

彼此欣赏：Hamel 钦佩 Shreya 年轻却极为稳重和通透；Shreya 感激 Hamel 持续不断的热情和推动力——"如果没有 Hamel，我可能早就不再关心评估了。每个人的生活中都需要一个 Hamel。"