给一个 AI 功能做验收，常见的起手式有两种。一种是先列指标：准确率、幻觉率、满意度，再找一批题来跑分。另一种是先去翻它真实跑过的记录，看它到底在哪些地方做砸了，然后再决定要测什么。
这篇以三份材料为主。第一份明确主张先找错，另外两份分别补上分层验收和怎么写进 PRD；把它们串成一条流程，是我们做的整理：
- Hamel Husain 和 Shreya Shankar 在 Lenny’s Newsletter 上的《Advanced evals》（2026 年 9 月 22 日），讲怎么找失败。这篇是付费文，公开部分只到第三步开头，后面的内容我用两位作者自己公开的 Evals FAQ 补齐，没看到的部分不写。
- 人人都是产品经理上王耀亮的《Agent 评测实战》（2026 年 8 月 1 日），讲找到失败之后怎么分层验收。
- 同一网站上 Keating 的《别只会写 PRD 了》（2026 年 5 月 11 日），讲怎么把评测写进需求文档。
下面先讲来源里说了什么，最后一节是我们自己的建议，会单独标出来。
先写指标，容易测错东西
Hamel 和 Shreya 说，他们合作过 50 多家 AI 公司，看到的普遍情况是团队跳过找错这一步，直接写指标。原因不难理解：翻长长的会话记录又慢又难规模化，指标看起来具体、好自动化。但指标写得太早，等于提前假设了什么重要，结果可能测错了对象，或者对象对了但测得不准。
他们把这一步叫 error discovery，直译是“错误发现”，并且类比成产品发现：产品发现告诉你哪些问题值得解决，错误发现告诉你哪些失败值得去测。原话是，如果整个评测流程只来得及做一部分，就先做这一步。
为什么不能先把标准写好？文中给了一个例子。Nurture Boss 是一个帮物业公司回复租客的 AI 租房助手。有一段对话是这样的：
租客：“这超出我的预算了，谢谢。”
助手：“不客气！如果情况有变或者以后有其他问题，随时联系我们。祝您愉快！”
让大多数 AI 来检查，这段算成功，礼貌、完整、没说错话。但这个产品的目标是促成租约，助手应该去找更便宜的房型，或者同一家公司的其他楼盘。作者说，这种“接住客户异议”的失败，得先有人亲眼看到这段记录，才会想到把它写进检查标准。看了数据之后，对“什么叫好”的定义发生变化，这个现象他们称为 criteria drift，可以理解为“标准漂移”。
他们还拿同一个助手的 100 条线上记录做了对比，结论有三条：
- AI 会漏掉那些需要产品判断、或者需要记录之外背景的问题，比如短信里出现了 Markdown 格式符号（# 、* 这类控制排版的符号）、该转人工却没转，以及上面的异议没接住。
- AI 擅长抓记录里一眼可见的矛盾，比如回答和工具返回的结果对不上。
- AI 也能找到人漏掉的问题，但会把好回答误判成失败，带来噪音。
所以他们的意思不是不用 AI 查，而是别一上来就把一堆记录丢给 AI，让它告诉你哪里有问题。
失败是怎么一步步找出来的
这里先解释一个词：trace，可以理解为“执行记录”。一条 trace 是一次用户会话的完整记录，包括用户说了什么、系统提示词、中间查了什么资料、调了哪些工具、工具返回什么，以及最后给用户看的输出。标准是，评审的人拿着这条记录，能还原发生了什么，并判断这次好不好。
还没上线、没有真实记录时，可以用模型造模拟提问。作者的建议是先定几个容易出问题的维度，比如任务类型、提问的人是谁、请求是清楚的还是模糊的，然后组合出场景，每个场景单独调一次模型来生成，这样提问不会千篇一律。他们也说得很明白：模拟数据替代不了真实数据，能拿到真实用户就别靠它。
找错的核心是人先看、人先写。公开部分里能读到的几条规则：
- 用自己的话写下哪里不对，写到同事或 AI 看得懂。“回答不好”没用，“工具显示房子已经租出去了，助手却说还空着”才能拿来改。
- 只写用户角度看到的问题，先不分析系统内部为什么错。
- 一条记录里有好几个问题时，先记最早出现的那个，上游的错往往会连带出下游的错。
- 刚开始只标失败就够了。
人标过一批之后，再让 AI 去剩下的记录里找类似问题，人逐条决定接受还是驳回。这里有个数字要说清楚，两处说法不一样：Lenny 那篇说，他们的插件要求你先自己看 10 条，才开始给建议，整体以 100 条为参考；两位作者的 FAQ 写的是至少自己先标 30 条，再看 AI 的建议，初始池子约 100 条多样的记录，看到新记录不再冒出新的失败类型为止（他们称为“理论饱和”），而且建议至少看 100 条。后者更保守，下面我们按 30 条和 100 条来建议。
标完之后，把零散的批注归成几类失败，再数每类出现了多少次。FAQ 里把前一步叫开放式标注，把归类这一步叫轴向编码，并说归类是最重要的一步，产出就是一张失败分类表（failure taxonomy）。AI 可以帮忙出第一版分组，但要人来改：FAQ 里“哪些环节可以交给 LLM”一问举的例子是，AI 可能把“登录后崩溃”和“登录太慢”都归成“登录问题”，可一个是稳定性问题，一个是性能问题，修法完全不同。
Lenny 那篇的第三步标题是“把失败模式变成产品优先级”，公开部分只写到让 AI 把标注聚类、计数，方便看出规律，后面的内容在付费墙后，这里不展开。
作者还提供了一个免费插件辅助这件事（npx skills add https://github.com/ai-evals-course/evals-skills），会根据你的数据生成一个本地评审页面。页面有两条原则值得照搬：输出按用户看到的样子展示，邮件就像邮件；把渠道这类有用的信息露出来，方便筛选。作者称学会基础之后，整套找错流程大约 30 分钟。按我们的理解，这只算找错本身，不含接日志、整理数据这些准备工作。
找到失败之后，验收分几层看
王耀亮那篇面对的是客服、导购这类对话型 Agent。他举了一个自己项目里的例子：客服 Agent 在测试环境里退款流程很顺，上线后遇到已发货的订单，没查订单状态就答应“能退”。翻执行记录才发现，它根本没调订单查询工具。答案看起来像人话，过程早就偏了，他称为假阳性。
他的判断是，对话型 Agent 不能只给每一轮回复打分再求平均，要四层一起看：
- 单轮（Turn）：这一轮回得合不合理。
- 整段会话（Session）：用户的问题最后解决了没有。
- 执行轨迹（Trace）：工具调没调、顺序对不对、证据齐不齐。
- 业务结果（Outcome）：退款单是不是真的建了，状态是不是真的改了。
他举的反例是，用户先问成人票，接着问“小孩呢”，Agent 忘了前文；中途用户改问订单为什么没发货，它还在卖票。每一轮单独看都及格，整段看不及格。
这四层和前面的找错是接得上的：找错告诉你它会在哪里砸，四层告诉你这些失败该在哪一层被拦住。退款那个例子，单轮回复和表面上的会话都像是解决了，查执行轨迹才看得到它漏了订单查询这一步。
他还提了几个上线门禁会用到的点：
- 指标分优先级。不达标就不能上线的叫 P0，包括任务完成率、工具调用是否正确、幻觉、越界承诺这些；过程质量和成本是 P1；语气、品牌风格这类体验是 P2。
- 同一个任务跑 N 次，分开看“至少成功一次”和“每次都成功”。前者说明能力上限，后者才说明稳定，退款这种场景要看后者。
- 测试题集不要从线上日志里随机捞，那样正常流程占大头，边角问题全被淹没。他用四个来源：专家设计 50 到 200 条核心场景，在此基础上让模型扩写说法，按场景和风险从线上分层抽样，再加上线上失败案例回流，他认为回流这部分最值钱。
写进 PRD，评测才不会悬空
Keating 那篇的出发点是，PRD 只说清楚了要做什么，没说清楚怎样算做得好。他指出几个常见误区：只等用户反馈，可用户只会说“感觉不准”；只看留存、转化这些业务指标，不看意图识别、召回、工具调用这些能力指标；评测题随便凑；只打分不归因，最后所有问题都变成“让算法再优化一下”。
他的建议是写 AI 产品的 PRD 时，在常规内容之外多写四块：
- 能力边界：这个版本能答什么、不能答什么，哪些必须兜底，哪些不能硬答。
- 效果指标：除了业务指标，还要写准确率、召回率、响应时间、工具调用成功率、幻觉率这类能力指标。
- 评测集设计：题目从哪里来、覆盖哪些场景、怎么分层，历史错例要不要进回归测试（回归测试就是每次改提示词、换模型后，把旧题重跑一遍，防止修好的问题又冒出来）。
- badcase 归因机制：线上问题怎么收集、怎么分类、流转给谁、怎么回归验证。
他把整条闭环写成五步：定指标、选方法、造评测集、跑评测、做归因。这里和 Hamel 的顺序有一处值得留意：Keating 把定指标放在第一步，但他的评测集来源里，真实用户日志占大头，历史错例应该进回归。我的理解是两者不冲突，可以先跑一轮找错，再把找到的失败写成第一版指标和第一版评测集。这是我的推断，原文没有这么说。
他也给了自己金融投研项目的数字：把十多个意图收敛成两类、链路固定成四条之后，响应时间从十几秒降到 7 秒内，关键问答准确率约 95%。这是作者对单个项目的自述，不是对照实验，不能当成普遍结论。
放到投放和数字员工上，这周可以怎么做
以下是我方建议，不是来源原文，也不是我们已经跑过的结果。
先说几个示例，帮助理解投放和内容场景里的失败长什么样。这些是假设的例子，不是真实业务数据：
- 投放复盘助手把“消耗涨了”写成“效果变好了”，但点击成本也在上升。光看回答字面不一定能判错，需要结合业务目标判断这算不算失败，属于 AI 容易漏掉、要人先定标准的那类。
- 数字员工说已经调整了预算，可执行记录里调整接口返回了失败。这是回答和工具结果对不上，AI 自动检查就能抓到。
- 内容 Agent 写的小红书笔记，单篇看都通顺，但同一批 10 篇用的是同一个开头。只给单篇打分看不出来，要放到整批里看。
这周能做的最小版本：
- 把记录拿出来。 导出近一两周数字员工或内容 Agent 的会话，能带上工具调用和返回结果最好。如果现在没有完整记录，先把记录补上。这周就想先跑一轮的话，可以按前面说的维度造一批模拟提问做试运行，但结论只能当参考，不能当成线上真实的失败。
- 找最懂业务的那个人，先自己标 30 条。 FAQ 对多数中小团队的建议是，由一位懂领域的人做最终判断。只写用户角度的问题，每条先记最早出现的那个错。
- 再让 AI 帮忙找类似的，人来接受或驳回，慢慢加到 100 条左右，直到不再冒出新类型。
- 归类、计数，得到一张失败分类表，按出现次数和影响排序。
- 每类挑几条代表进回归集，以后改提示词、换模型都重跑一遍。
- 在下一份 PRD 里补上那四块，先写占位也行，至少把“不能硬答的范围”和“错例怎么回流”写进去。
三份材料都没有写广告投放场景，上面的映射和顺序是我们自己的判断。真实效果要等跑完一轮才知道，到时候再写。
参考资料
- Hamel Husain、Shreya Shankar，《Advanced evals: How to find (and fix) hidden AI failures in your product》，Lenny’s Newsletter，2026-09-22（付费文，公开部分读至 Step 3 开头）：https://www.lennysnewsletter.com/p/advanced-evals-how-to-find-and-fix
- Hamel Husain、Shreya Shankar，《AI Evals: Everything You Need to Know》（FAQ）：https://hamel.dev/blog/posts/evals-faq/
- Hamel Husain，《Automating Error Analysis》，2026-06-24：https://hamel.dev/notes/llm/ai-product-engineering/evals-error-analysis.html
- 王耀亮，《Agent 评测实战：别让“感觉还行”毁在上线前》，人人都是产品经理，2026-08-01：https://www.woshipm.com/evaluating/6436624.html
- Keating，《别只会写PRD了：AI产品经理真正该补的是评测闭环》，人人都是产品经理，2026-05-11：https://www.woshipm.com/pd/6392513.html
- evals-skills 插件：https://github.com/ai-evals-course/evals-skills