AI 转人工测试，不能止于工单创建成功

AI 助手说「工单已创建」，接口也返回成功，交接就完成了吗？原文提出的检验标准更实际：接手的人能不能继续处理，是否知道哪些事已经做过、哪些结论还没确认，以及下一步由谁决定。

作者给出了一套基于合成测试样例的交接测试设计，重点检查信息能否完整、准确地穿过整个流程。它没有报告实际执行的基准测试，但对正在做 AI 客服、自动升级处理和人工接管功能的团队，有直接参考价值。

工单创建成功，为什么还不够

创建成功只能证明系统里多了一条记录，不能证明接手者拿到了继续工作的必要信息。

作者建议先定义「交接契约」：也就是约定接手者必须知道什么。可以包括用户目标、已确认事实、尝试过的步骤、已完成操作，以及尚未解决的决策。如果应用定义了接收位置和负责人，也应该纳入检查。

契约还要说明哪些内容不能传给接收者。把完整聊天记录塞进工单，并不自动等于合格交接；其中可能包含接收者无权获得的信息，也可能让关键事实淹没在大量对话里。

交接质量取决于必要信息是否准确保留，而不是摘要写得多长。

预期事实也不能从 AI 生成的摘要里反推。假设摘要漏掉了一次已完成操作，再拿这份摘要生成检查标准，遗漏就可能被原样放过。测试样例必须独立维护预期信息。

测试样例要故意放进容易混淆的状态

原文建议构造一个虚构案例，同时放入几组容易被摘要混淆的信息：

• 客户报告了某个症状，但系统只确认了范围更小的事实。
• 对问题有一种解释，但解释尚未验证。
• 一项操作已经完成，另一项只是提议，仍需批准。

这些区别是测试的重点。摘要可能把用户描述写成系统确认，把推测写成原因，也可能把「建议执行」写成「已经执行」。文字读起来很顺，案件状态却已经变了。

因此，测试数据需要包含能辨认、无害的样例值。作者明确建议，不要为了测试交接路径而创建真实客户事件，或发送真实通知；真实外部副作用应当隔离，或限制在明确批准的测试账号内。

这里检验的不是模型会不会复述，而是它能否保住事实的来源、确定程度和操作状态。

要看接手者实际收到什么，也要看客户被告知什么

运行助手直到触发升级处理之后，不能只检查它最后回复的那段话。需要查看持久化后的工单，以及接手者实际使用的界面。

如果通知由另一条流程单独生成，通知也要检查。工单可能准确，通知却可能误导接收者，尤其是多个组件分别总结同一个案件时。案件是否到达预期测试位置，同样属于这次测试。

客户侧的收尾消息也必须与存储状态核对。「创建了工单」不能被说成「同事已经审阅了你的问题」，升级成功也不能让尚未完成的操作变成已完成。

如果产品提供案件编号或下一步操作，要验证它们与存储记录一致；如果承诺后续联系，就要测试产品实际支持的联系路径。生成了一句承诺，不能证明系统具备兑现承诺的能力。

失败时，应保留样例修订版本、预期字段、接收者允许获得的信息范围、持久化输出，以及具体缺失或被改写的事实。证据只需保留到足以让另一位工程师排查的程度。

必填字段、操作状态这类确定性检查，应与生成措辞的重复评估分开。涉及生成步骤时，还要记录相关配置和重复次数，报告测试条件与局限。

我的判断

我认同作者把验收点放在接手者能否继续工作上。对这类流程，只统计升级次数或接口成功率，很容易把「记录写入成功」误当成「工作交接成功」。

与只检查助手回复相比，检查工单、接收界面和独立通知，更容易发现组件之间的信息偏差。但这套方法有个前提：团队得先说清楚接手者需要什么。原文也承认，预期结果取决于具体工作流，没有一份适用于所有业务的统一规格。

它目前是一份测试设计提案，不是经过实测验证的效果结论。作者没有给出对照数据，也没有证明这些检查能覆盖多少真实遗漏。合成样例适合验证已知风险，但一次通过不能代表所有对话都能完整交接。

原文还披露，文章由 AI agent 为 Acadify Solution / Acadify AI Lab 撰写，助手与服务案例均为虚构。可以借鉴方法，不能把它当成真实业务落地报告。

能拿来做什么

• 如果你正在做带人工接管的 AI 应用，先为一个具体流程写出交接契约，明确必需事实、操作状态和禁止传递的内容，再据此设计检查。
• 给 Node 服务的工单集成加入合成案例，刻意区分用户报告、系统确认、未验证解释、已完成操作和待批准提议，核对最终存储结果。
• 验收前端接单页面时，使用接手者实际看到的视图检查信息，同时核对独立通知，确认关键上下文没有在展示或再次摘要时丢失。
• 将客户收尾回复与案件状态放在一起验收，逐项检查创建、审阅、完成和后续联系等表述是否有实际状态或路径支持。