在构建卓越的人工智能（AI）产品过程中，错误分析无疑是投资回报率（ROI）最高的活动之一。它能帮助我们深入了解产品的实际表现，发现那些隐藏在数据中的“未知之谜”，从而精准地进行迭代优化。正如Anthropic和OpenAI的首席产品官所强调的，系统化的评估（Evals）与错误分析，正迅速成为产品开发人员必须掌握的最重要的新技能之一。

然而，许多团队在面对AI应用时，仍然依赖于临时的“感觉检查”（vibe checks）——凭直觉修复一两个问题，然后祈祷没有引入新的错误。这种方法在应用规模扩大后会变得难以为继，让团队陷入迷茫。

本指南的目标，正是提供一个结构化的、可操作的框架，帮助产品经理和开发人员摆脱这种被动局面。我们将阐述如何系统地识别、分类和优先处理错误，从而让您能够充满信心地改进产品，将AI应用的质量提升至新的高度。接下来，我们将详细介绍这一从混乱走向清晰的系统化流程。

评估始于严谨的数据分析

在着手构建任何自动化测试之前，我们必须首先通过数据分析来深入了解应用实际出的问题。这是后续所有评估工作的基础，也是确保整个评估体系值得信赖的关键。许多团队恰恰在这一点上走错了方向。您会惊讶于通过这个过程能学到多少东西，而且像许多人一样，您可能会发现，揭示这些洞见的体验本身就令人着迷。

重新定义“评估” (Evals)

首先，我们需要拓宽对“评估”的理解。它是一个宽泛的概念，远不止是编写单元测试。“评估”是一个系统性地衡量和改进AI应用的完整过程，其核心是数据分析。

一个常见的误区是，许多团队直接跳到编写测试的环节，试图用代码来验证一些预设的假设。这种做法往往会导致评估偏离应用的实际问题。当团队发现自动化测试的结果与他们的实际感受不符时，他们很快就会对整个评估体系失去信任，最终回到“反评估”的立场上。正确的起点应该是深入分析应用的真实运行日志，从中发现问题。

人类专家的不可替代性

另一个常见的误解是：“我们生活在AI时代，为什么不能让一个AI来评估另一个AI呢？” 答案是，AI评估器缺乏关键的业务背景和领域知识。

例如，在一个房地产AI助手的案例中，AI可能会主动向用户提供“虚拟导览”功能。如果让另一个AI来评估这次对话，它很可能会认为这是一个成功的交互，因为它成功地提供了有用的信息。然而，它并不知道这家公司实际上并不提供“虚拟导览”功能。只有具备领域知识的人类专家（通常是产品经理）才能识别出这是一个严重的“幻觉”错误，是一个糟糕的产品体验。

因此，在错误分析的初始阶段，拥有领域知识的人类专家的介入是至关重要的。他们能从产品和用户的角度，准确判断交互的真实质量，为后续的评估工作奠定坚实的基础。

在理解了这些核心理念之后，让我们进入评估流程的第一个具体操作步骤。

第一步：通过开放式编码发现未知问题

“开放式编码”（Open Coding）是整个错误分析流程的起点。它是一种探索性的、无偏见的方法，其战略价值在于发现你甚至不知道存在的各类问题，而不是去验证已知的假设。

许多人看到这个手动步骤的第一反应是：“这看起来太费时了，根本无法规模化。” 这是一种常见的误解。请将这个过程视为一次高回报率的、一次性的深度探索。正是这一步为后续所有自动化的工作奠定了坚实的基础。我们发现，几乎所有尝试过的人都会立刻沉迷于这个过程，因为它能带来海量的、意想不到的洞见。

设定执行者：“仁慈的独裁者”

为了确保效率和一致性，这个过程不应由一个委员会来共同完成。委员会式的讨论不仅低效，而且会让整个过程变得异常昂贵，以至于团队望而却步。我们推荐采用“仁慈的独裁者”（Benevolent Dictator）模式：指定一名具备深厚领域知识且其判断力深受团队信任的人来主导此过程。这个人通常是产品经理，因为他们最了解业务目标和用户体验。

编码操作指南

以下是清晰的分步骤操作说明：

1. 抽样: 从应用日志（Traces）中随机抽取至少100个交互样本。
2. 审查: 逐一审查每个样本，就像产品经理审视用户体验一样。
3. 记录: 针对每个样本，只记下你看到的第一个错误，然后就停下来，继续下一个样本。使用非正式但具有描述性的语言进行记录（这即是“开放式编码”），无需立即进行严格分类。关键是要足够详细，以便日后他人或AI能够理解。

记录示例：

• 不佳的记录: “对话很蹩脚” (这个描述过于模糊，无法提供有效信息。关键不是语言是否正式，而是内容是否具有描述性。)
• 良好的记录: “本应转接人工，但AI没有执行”
• 良好的记录: “用户通过多条短文本消息提问，导致对话流混乱”
• 良好的记录: “在公司没有该功能的情况下，主动向用户提供了虚拟导览”

确定停止点：“理论饱和”

你应该进行多少次开放式编码？答案是持续进行，直到你达到“理论饱和”（Theoretical Saturation）。这听起来很学术，但实际上非常直观：就是当你感觉不再发现新的错误类型，甚至开始感到有点“无聊”的时候。根据经验，100个样本通常是一个很好的起点，它能帮助你发现绝大多数常见的问题。

在收集了大量原始的错误笔记后，下一步就是将这些零散的信息系统化。

第二步：利用AI辅助进行归类（轴向编码）

本章节的核心任务是，将第一步中收集到的、杂乱的“开放式编码”笔记，转化为结构化的、有意义的错误类别。这个过程在质性数据分析中被称为“轴向编码”（Axial Coding），其产物就是我们常说的“失败模式”（Failure Modes）。

利用LLM进行初步聚类

这项工作非常适合利用大型语言模型（如Claude, ChatGPT）来辅助完成。你可以将所有的“开放式编码”笔记提供给LLM，并要求它进行归纳和聚类。

向LLM提问的范例结构：

“我这里有一系列从AI应用日志中记录的‘开放式编码’（open codes）。请分析这些笔记，并将它们归纳为几个核心的‘轴向编码’（axial codes）类别。这些类别应该能代表主要的失败模式。如果某个笔记不属于任何一个类别，请将其归入‘以上都不是’。”

在提示词中明确使用“open codes”和“axial codes”这样的专业术语，有助于LLM更好地理解任务。此外，加入一个“以上都不是”（none of the above）的类别是一个专家技巧，它能帮助你识别出那些不符合现有分类的笔记，从而发现你的错误类别是否完整。

人工提炼与优化

LLM的输出仅仅是一个初稿。作为“仁慈的独裁者”，你必须亲自审查、重命名和优化这些由AI生成的类别。一个好的错误类别应具备以下特征：

• 具体且可操作：避免使用过于宽泛的描述。
• 例子:
  • 一个由AI生成的宽泛类别可能是**“能力限制”**。这是一个不够理想的类别，因为它不够具体，无法指导下一步的行动。
  • 经过人工优化后，它可以被拆分为更具体的类别，例如：“巡回看房调度问题”、“人工转接失败”“输出格式错误”。这些类别清晰地指出了问题所在，为后续修复提供了明确的方向。

在定义了清晰的错误类别后，下一步便是对这些错误的严重程度进行量化分析，以便确定修复的优先级。

第三步：量化分析与确定优先级

本阶段的战略目标，是将定性的错误类别转化为定量的洞察数据。这能使团队从“混乱”走向“清晰”，并基于数据做出明智的决策，而不是凭感觉猜测哪个问题最重要。

应用数据透视表进行计数

你不需要复杂的工具，一个简单的电子表格就能完成这项工作。将你的所有样本（Traces）和它们对应的“轴向编码”（即失败模式）放在一个表格里，然后使用**数据透视表（Pivot Table）**功能来统计每个失败模式出现的频率。

这是一个非常简单但极其强大的分析技巧。

解读结果并制定行动计划

数据透视表会给你一个清晰的视图，告诉你哪些问题最普遍。

这个简单的计数结果，就是你制定行动计划的依据。现在，你可以清晰地确定优先级。一个实用的技巧是：你可以直接双击数据透视表中的数字，表格软件会自动为你筛选出所有属于该类别的原始日志，让你能立即深入分析具体案例。

• 直接修复: 对于一些简单的问题，比如**“输出格式错误”**，可能只需要直接优化提示词（Prompt）就能解决。
• 构建评估器: 对于另一些更复杂、主观的问题，比如**“人工转接时机不当”**，你无法通过简单的代码逻辑来判断。这类问题正是构建自动化评估器的理想候选对象，以便进行持续监控和迭代。

在确定了需要重点关注的复杂问题后，我们将探讨如何为此类问题构建专门的自动化评估工具。

构建自动化评估器：“LLM作为裁判”

对于那些无法通过简单代码逻辑判断的、主观且复杂的失败模式，我们可以构建一个专门的LLM来扮演“裁判”（Judge）的角色，进行自动化评估。这个“LLM作为裁判”（LLM as a Judge）的方法，能够将人类专家的判断标准规模化。

在开始构建之前，请务必设定合理的期望：一个典型的产品最终只需要为那些最“棘手”且风险最高的失败模式构建四到七个“LLM裁判”，而不是为每个问题都创建一个。

设计“裁判”提示词的核心原则

设计一个可靠的“LLM裁判”，其提示词必须遵循以下三大核心原则：

1. 单一职责 (Single Responsibility) 每个“裁判”只评估一种非常狭窄、具体的失败模式。不要试图让一个“裁判”同时判断多个问题。
2. 二进制输出 (Binary Output) “裁判”的判断结果必须是明确的二进制，例如 True/False 或 Pass/Fail。绝对避免使用1-5或1-7分的评分制。评分制是一种“逃避做决策的狡猾方式”，因为没有人真正知道3.2分和3.7分到底有什么区别。这种模糊性无法转化为可操作的决策，最终会导致团队对评估结果失去信任。
3. 明确的规则 (Explicit Rules) 在提示词中，必须详细列出判断该失败模式是否发生的具体标准和场景。规则越清晰，裁判的判断就越可靠。

案例分析：构建“人工转接”评估器

假设我们正在处理“人工转接时机不当”这个失败模式。以下是一个示例性的“裁判”提示词，它遵循了上述三大原则：

裁判提示词示例：

你是一个AI助手交互质量评估员。你的任务是判断在给定的对话日志中，AI助手是否未能在应该进行人工转接时进行转接。

评估规则： 如果出现以下任何一种情况，AI就应该进行人工转接：

1. 用户明确要求与人工客服交谈。
2. 对话陷入循环或AI无法理解用户意图。
3. 涉及敏感的住户问题（如投诉、纠纷）。
4. AI调用的工具无法获取所需数据。
5. 用户请求当天的看房或参观。

输出格式： 请仔细阅读以下对话日志，并根据上述规则进行判断。你的输出必须是 True 或 False。

• True: 表示AI确实未能在需要时转接人工（存在错误）。
• False: 表示AI的行为是正确的，没有发生该错误。

[此处插入对话日志]

创建了“裁判”之后，我们绝不能盲目信任它。下一步的关键是验证其判断的准确性。

验证评估器：“谁来验证验证者？”

验证“LLM裁判”的可靠性，是确保整个评估体系可信的关键一步。如果团队对评估结果本身都心存疑虑，那么基于这些结果所做的一切决策都将是空中楼阁。这个过程回答了一个古老的问题：“谁来验证验证者？”（Who validates the validator?）

对比人类与AI的判断

验证过程非常直接：将“LLM裁判”对一批样本的判断结果，与之前由人类专家（“仁慈的独裁者”）标记的“轴向编码”结果进行对比。

使用混淆矩阵进行深度分析

在对比时，切勿只看总体一致性或准确率。在错误发生率较低的情况下（例如，90%的样本都是正确的），这个指标具有极大的误导性。一个永远只输出“正确”的评估器，也能达到90%的准确率，但它毫无用处。

我们应该创建一个简单的混淆矩阵（可以使用数据透视表实现），来分析以下四种情况：

迭代与优化

分析混淆矩阵的最终目的，是找出“裁判”与人类判断不一致的地方，特别是误报和漏报的案例。仔细研究这些案例，思考为什么“裁判”会做出错误的判断，然后返回去迭代和优化“裁判”的提示词，让规则变得更清晰、更无歧义，直到其判断结果与人类专家高度对齐为止。

这个验证与优化的闭环，是构建一个值得信赖的自动化评估体系的基石。

打造持续改进的飞轮

本指南详细阐述了一个从混乱走向清晰的系统化流程。它终结了依赖“感觉检查”的时代，为AI产品开发带来了纪律和信心。这个流程并非一次性的任务，而是一个可以持续运转的改进飞轮：

1. 数据分析（如开放式编码）揭示了真实世界中的失败模式。
2. 这些洞见指导我们构建自动化评估器（LLM裁判），用于监控最关键的问题。
3. 这些评估器在生产环境中持续运行，生成更多、更精准的数据。
4. 这些新数据又成为下一轮数据分析的输入，形成一个不断强化的闭环。

更重要的是，这个过程重新定义了评估的价值。它不仅仅是用来测试产品是否符合既定的需求文档（PRD），更是一种发现新需求的产品探索工具。通过深入分析真实的用户交互，你将发现那些“你在最初规划时根本无法想象到的”新需求和期望。

最终，这个流程的目标不是追求完美的评估分数，而是为了获得可操作的洞察，从而系统性地、持续地提升AI产品的质量和用户体验。这正是顶尖AI团队秘而不宣的实践——“他们不谈论这个，因为这是他们的护城河。” 掌握这套方法，就是为你的产品构建最坚实的竞争壁垒。