仪表盘里的成功，需要先读定义
Microsoft Learn的Copilot Studio官方文档区分用户确认解决与系统推定解决等会话结果，并提供查看具体会话的路径。这个例子提醒我们：统计标签有各自定义，不能只看到一个已解决比例，就认定每条回答均已人工核实。产品功能和权限以当期官方文档为准。
下面是一套本站提出的上线后复查方法，适用于先由少量业务人员维护的服务入口，不要求购买特定产品，也不是对某家客户项目已完成的验收结论。它补充上线前测试，重点解决真实使用中怎样发现和追踪问题。
从可能造成后果的回复开始
人工时间有限时，可以先按业务后果安排复查顺序。涉及价格与交期承诺、客户争议、资料中找不到依据的断言、反复追问以及调用业务动作后的答复，适合优先检查。常规问题也应轮换抽取，避免只看被用户投诉的少数记录。这里没有适用于所有团队的固定抽检比例。
检查一条回复时，先保留必要上下文：用户在问什么，系统依据哪份资料，是否执行了动作，最终由谁结束处理。只看单句回答可能看不出问题。资料应在已获准的用途和访问范围内使用，不为方便复查把所有客户对话复制到无关工具。
一张复查单怎样写
- 任务与依据：问题编号、业务主题、所用知识条目及版本。
- 判断与影响：答案是否有支持，是否遗漏条件，是否已影响后续处理。
- 接手与更正：谁处理客户问题，谁修改知识或流程，哪些结论仍待确认。
- 验证与关闭：修复后重测了哪些问法，何时复核，由谁确认结束。
例如，在一个明确标为模拟的售后场景里，资料写明需要人工确认的时间范围，机器人却给出了确定承诺。复查不应只给回答打一个低分，而要判断是资料版本错误、条件未被检索到，还是回复规则没有约束，并明确客户问题由谁接手。这个示例不是已发生的投诉。
修复必须回到下一次使用
修改知识条目后，重测原问题、换一种问法的问题，以及原本应转人工的边界问题。若只修正页面文字，没有检查系统是否读到新版本，下一次仍可能给出旧答复。每次只记录自己实际测试过的范围，不把单个样例通过写成整体准确率。
每周或按业务节奏汇总问题时，可以比较同类错误是否重复出现、人工接手是否完成、资料修复后能否追溯。记录抽检范围和未覆盖部分，比给出一个没有分母的好评数字更有帮助。
延伸阅读：上线前的FAQ检索测试；AI客服转人工的条件；多客户知识库隔离。