AI客服上线前要做哪些测试？

AI 客服上线前，至少要完成知识答案、身份权限、业务接口、转人工、渠道兼容、压力与故障恢复六类测试。测试不能只问几个顺畅问题，而要固定知识版本和业务系统版本，用真实角色的问题集同时覆盖正常、无答案、越权、接口失败和人工接管场景，并保存输入、引用、动作与回执作为验收证据。

先冻结测试对象和放行条件

企业先要明确本次上线的是网页客服、企业微信入口、小程序客服，还是多个渠道共用的服务。测试记录应写明模型配置、知识库索引版本、提示约束、工具接口版本、账号角色和发布时间；否则同一问题前后结果不同，很难判断是内容变化、权限变化还是模型配置变化。AI 客服通常基于成熟大模型、企业知识库、权限、业务接口和人工复核落地，不是从零训练一个专属模型。

• 问题集：高频问题、表达变体、资料缺失、冲突资料、敏感问题和故意诱导越权的问题分组保存。
• 预期结果：每题标明应回答、应拒答、应追问、应查询系统或应转人工，避免只凭“看起来合理”判定。
• 版本证据：记录引用资料、索引版本、工具参数、接口回执和人工修正，复验时使用同一基线。

知识与权限要一起测试

知识测试不只看答案是否流畅，还要核对引用是否来自当前有效资料、适用对象是否正确，以及资料撤回后旧答案是否失效。权限测试则要使用访客、普通客户、重点客户、客服人员和管理员等真实角色，验证同一个问题在不同身份下是否只返回允许查看的内容。知识库治理与版本方法可参考 企业知识库 RAG。

• 过期制度、未生效活动和被撤回商品资料不能继续进入答案。
• 客户手机号、地址、订单金额和内部备注只在必要且已授权的范围内返回，日志中同样需要脱敏。
• 未登录、跨客户、跨门店或跨租户请求应被拒绝，并留下拒绝原因与审计记录。

业务接口要验证幂等、失败和补偿

订单查询、工单创建、预约变更或退款申请等动作，应通过受控服务端接口执行。测试时不仅验证成功路径，还要模拟超时、重复提交、参数缺失、状态已变化和下游服务不可用。写操作要有业务单号、幂等键、权限校验和操作日志；超时后先查询真实结果，再决定重试或转人工，不能让模型直接重复调用。需要多步骤工具动作时，可同时查看 工作流智能体 的实施边界。

转人工测试要覆盖上下文与队列

1. 命中投诉、合同、价格承诺、隐私、退款争议或多次未解决时，按规则主动转人工。
2. 转接时携带会话摘要、客户身份、已核验信息、引用资料和接口结果，避免客户重复描述。
3. 人工繁忙或无人接待时，给出可验证的排队或留资状态，不虚构“已处理”。
4. 人工结束后把分类、处理结果和待办回写工单；未经审核的人工备注不自动进入知识库。

压力、监控和回滚要按业务后果验收

压力测试应基于预计渠道量、会话长度、知识检索和接口调用组合设定，不套用无依据的通用并发数字。验收要观察排队、超时、限流、转人工、接口成功与失败、资源占用和成本记录。当新知识、模型或接口版本导致错误增加时，应能停止写操作、切回已验收版本，并确认在途会话和未完成工单怎样继续。私有化或混合部署项目还应核对监控、备份和责任边界，相关说明见 大模型私有化部署。

出现这些情况应暂缓正式放量

知识资料没有负责人、客户身份无法透传、跨租户权限未验证、写接口没有幂等与审计、人工队列无人承接，或故障后无法回到已验收版本时，应先保留在内部试用或只读查询阶段。聚匠科技可围绕 AI 客服系统 梳理测试问题集、权限矩阵、接口回执、转人工和回滚材料；正式放行仍由业务、客服、IT 与合规责任人共同确认。

说明：本文为通用实施与验收建议，具体数据处理、渠道规则、模型能力和上线范围以企业制度、合同及平台当期文档为准，不构成效果保证。