AI 回答在离线评测里变好，不等于用户体验和留存真的变好；但直接把每个版本都扔进线上 A/B test，也是在拿真实用户替系统做基础质检。更可靠的顺序是：先用 Evals（评测）验证“它有没有按预期工作”，再用线上实验验证“真实用户是否因此得到更好结果”，最后用实验结果反过来校准 Eval。对 Momcozy APP，这能避免把“模型更会得分”误当成“用户的问题更好地被解决”。
AI 产品为什么需要两套证据？传统确定性功能比较容易检查：点击“绑定”后是否进入下一步、错误码是否正确显示，可以用代码测试。AI 输出却带有概率性：同一个问题可能有多种合理回答。团队于是会建立 Eval（Evaluation，评测），检查回答是否相关、安全、可执行，或工具调用是否正确。
但 Eval 回答的主要是 Verification（验证是否按设计工作）：系统有没有把我们想做的事做对。大白话说，厨师是否按菜谱完成了这道菜。Validation（验证是否真的产生用户价值）问的是另一件事：这道菜端给真实客人后，他们是否更愿意吃、是否吃得安全、是否还会再来。
生活类比是导航 APP。离线测试可以验证路线没有穿墙、距离计算正确、语音清楚；但真实驾驶实验才可能发现，一条理论上更短的路因为频繁变道，让司机更紧张。离线质量更高与真实体验更好通常相关，却不是同一件事。
Momcozy APP 的待验证例子：新版 AI 助手在人工标注样本中，“回答清楚且可执行”的通过率上升。这是好信号，却不能直接推出任务解决率、信任或留存上升。真实用户可能因为回答变长而放弃，也可能在高风险语境中得到更保守却更安全的人工接管。正确链路应是：Eval 先挡住明显错误 → 低风险、小范围实验观察真实任务结果 → 用结果检查 Eval 到底奖励了正确的东西没有。
Spotify：Eval 是实验漏斗的上游，不是 A/B test 的替代品
先用 LLM Eval 淘汰不合格方案，再把少数有希望的方案交给真实实验；这样提高实验命中率，却不跳过因果验证。
关键事实
Spotify 2026 年工程文章披露，其 A/B test 约 12% 最终形成可发布的正向结果，约 64% 产生有效学习；团队约 42% 的已启动实验会因次级指标退化而回滚。文章区分两层：Eval 检查相关性、连贯性、语气或意图匹配，属于 verification；线上实验观察用户行为、留存、崩溃和其他护栏，属于 validation。Spotify 建议把 Eval 跑在实验前筛方案，也跑在实验数据上：若 Judge 偏爱的版本没有带来更好用户结果，这个偏差本身就是校准信号。
编辑视角它证明了什么： 这是一手工程方法与 Spotify 自身实验统计，能证明离线评测与线上实验承担不同职责，也说明次级伤害常常只有生产实验能发现。但它没有证明“12%”应成为其他产品的目标，更不能把音乐推荐的风险等级套给母婴与健康帮助。
OpenAI：真实输入、专家判断与用户结果都要进入 Eval 的更新循环
Eval 不是上线前的一次考试，而是一份会被真实失败持续改写的产品要求。
关键事实
OpenAI 的业务 Eval 指南建议先由技术与领域专家定义端到端工作流，从约 50–100 个输出做 Error Analysis（错误分析），形成 golden set（黄金样本集）；测试环境要尽量接近真实条件，并主动加入“罕见但代价高”的边缘案例。上线后继续记录输入、输出和结果，把模糊或高代价案例交给专家复核，再更新 Prompt、工具、模型和 Eval。文章明确指出：面向外部用户时，Evals 不替代 A/B test 与产品实验，两者互补。
编辑视角它证明了什么： 这是一份平台方实践指南，不是某个具体功能的效果实验。它能支持“标准必须随真实世界更新”的方法，却不能证明只要收集 50–100 条样本就足以覆盖安全风险。母婴、儿童、健康和设备语境需要更严格的分层、专业审核与人工接管。
先认识这次新增的机制
Hamel Husain 与 Shreya Shankar 长期帮助团队建立 AI Evals，并培训过 2,000 多名产品与工程人员。此前我们已经拆过 Error Analysis、开放编码、理论饱和与覆盖度。今天不再重复“如何找错误”，只深读下一步：如何判断一个 LLM Judge（大模型评审）真的会抓错，以及复杂 Agent 到底坏在哪一步。
为什么 99% Accuracy 也可能完全没用
他们在 Lenny 的实战指南中举了一个关键例子：假设 AI 系统 99% 的样本本来就会通过，一个永远回答“通过”的 Judge，也能得到 99% Accuracy（准确率），但它一个真实失败都抓不到。
所以不能只看总准确率，要同时看两种能力。TPR（True Positive Rate，真正例率）看本来应该通过的样本，有多少被正确放行；TNR（True Negative Rate，真负例率）看本来应该失败的样本，有多少被正确拦下。这里“正、负”的命名容易绕，最重要的是直接问：好答案被误杀多少？坏答案被漏掉多少？
对普通创作工具，误杀一个好答案可能主要损害创意；对母婴或健康帮助，漏掉一个危险回答的代价可能更大。因此 Judge 没有脱离场景的“标准好分数”，取舍必须由风险决定，并定期与专业人工标注对表。
Agent 失败不能只看最后一句
复杂 Agent 会经历理解意图、检索知识、调用工具、解释结果、决定是否转人工等多步。最终任务失败只能告诉我们“没做成”，不能告诉我们哪一步坏了。Hamel 与 Shreya 推荐 Transition Failure Matrix（状态转换失败矩阵）：记录最后一个成功步骤，以及紧接着失败的步骤，把故障热点从一团对话变成可定位的流程节点。
Momcozy 的例子：AI 助手没解决设备问题，可能不是文案差，而是检索没拿到正确设备文档、错误码解析失败、工具调用后误读结果，或本该转人工却继续猜。只优化最终回答语气，会掩盖真正根因。
最容易误解的地方
Judge 校准得很好，也仍然只是代理指标。它能证明“更符合我们写下的质量标准”，不能单独证明用户更信任、任务更成功或长期更留存。反过来，线上点击升高也不能推翻安全 Eval。正确关系不是二选一：安全与能力底线先过 Eval，真实价值再过实验；若二者冲突，先查标准、分群和机制，而不是挑一个好看的数字宣布胜利。
以“AI 助手质量—增长校准 Agent”为例：
系统读取什么：经过授权和最小化处理的会话任务类型、关键步骤、检索与工具调用、人工接管、人工 Eval 标签、Judge 分数、实验分组，以及后续任务是否解决、重复求助、负面 VOC 与留存。敏感母婴、儿童、健康内容不能为了提升模型分数被无限保存或跨场景拼接。
形成什么判断：先判断版本是否通过安全、正确性和任务完成等离线门槛；再判断 Judge 的 TPR/TNR 是否足以承担筛选职责；最后比较“Eval 改善”与“真实结果改善”是否同向。若离线分数上升、任务解决率不变，系统标记为代理指标失配，而不是宣布成功。
能做什么：自动挑选高信息量样本、生成状态转换失败矩阵、淘汰明显退化方案、准备低风险实验草案，并把线上结果回写为下一轮 Judge 校准样本。未经明确授权，不向真实用户发送 Push、EDM、站内信，不自动放开高风险回答，也不更改生产策略。
如何看结果并更新策略：同时看 Eval 通过率、坏答案漏检率、任务解决、重复追问、人工接管、设备故障、负面 VOC、隐私投诉和合理周期留存。Judge 偏爱的版本线上表现更好，才提高其代理可信度；若出现偏差，就更新 rubric（评分规则）、样本分层或 Judge，而不是只调 Prompt 追分。
何时交给人：高风险健康或儿童语境、连续设备异常、低置信度、全新失败类型、Judge 与人工严重分歧，以及所有真实实验上线都交给人。自动生成 Eval 报告属于 AI-assisted；“离线筛选 → 线上验证 → 反向校准 → 更新下一轮筛选”形成受治理闭环，才接近 AI-native。
场景一：AI 助手首次问题解决。 待验证假设是，回答“更清楚”与用户“真的解决问题”并不总一致。我们可以先让人工把小样本标成安全、相关、可执行、应否转人工，再校准 Judge；低风险版本通过后，小范围比较任务解决、重复追问与负面 VOC。不能用聊天轮数或点赞作为唯一线上结果，也不能让普通增长实验覆盖高风险健康建议。最先需要的证据是：会话结束后，是否有一个可信且不过度收集隐私的“已解决 / 未解决 / 转人工 / 无法判断”结果。
场景二：设备绑定与故障帮助。 待验证假设是，最终“绑定失败”混合了多种状态转换故障。可用失败矩阵拆成“识别设备 → 权限检查 → 连接 → 错误诊断 → 指导 → 重试 → 稳定成功”，定位是知识、工具还是流程失败。不能因为最终帮助文案得分高，就推断连接成功会提高；设备、固件、网络和系统版本仍需真实旅程证据。最先需要的是把错误码、帮助步骤、重试与最终结果可靠串联。
场景三：BBM/VOC 与人工接管。 待验证假设是，Judge 最容易漏掉的不是明显胡说，而是“语气很像对的，却没有在风险时停下”。可以专门看坏答案漏检率，并把高风险漏检设为上线阻断项。不能为了提升自动解决率压低人工接管；在母婴、儿童和健康场景中，正确转人工本身就是成功结果。
- Verification｜按设计验证：检查系统有没有把预定动作做对。Momcozy 例子：AI 助手是否检索正确设备说明，并在风险场景按规则转人工。
- Validation｜价值验证：检查这个动作在真实环境中是否改善用户结果。Momcozy 例子：通过 Eval 的新回答，是否真的提高问题解决且不伤害信任。
- Evaluation Funnel｜评估漏斗：先用便宜、可重复的 Eval 筛方案，再用线上实验检验少数候选。Momcozy 例子：先淘汰不安全的回答版本，绝不把安全性本身交给真实用户试错。
- TPR / TNR｜真正例率 / 真负例率：分别看该放行的是否放行、该拦截的是否拦截。Momcozy 高风险场景尤其要关注坏答案有没有被漏掉。
- Transition Failure Matrix｜状态转换失败矩阵：记录 Agent 从哪一步走向哪一步时最常失败。Momcozy 例子：定位绑定帮助是错在识别错误码、检索文档，还是重试后的结果判断。
画一张“离线分数—真实结果”对照卡，只选 AI 助手首次问题解决，不运行真实触达：
- 写一个离线 Eval：它具体检查什么；
- 写一个真实用户结果：它不能被什么表面指标替代；
- 写两种分歧：Eval 上升但用户结果不变；Eval 不变但用户结果改善；
- 每种分歧各写一个下一步调查，而不是立刻宣布输赢。
产出物是一页代理指标校准卡。完成后能更新的判断是：我们现在测到的是“AI 更像好答案”，还是“用户真的更好地完成了任务”？最后只回答一个具体问题：如果新版回答的 Eval 通过率明显上升，但用户重复追问没有下降，我们最先怀疑 Judge 奖励错了什么？