如果供应商只提供私有客户端，不能嵌入现有渠道，就要谨慎评估。

第三，看转人工和兜底逻辑。
后台应能设置连续未识别次数达到几次后转人工，以及人工不在线时留资或留言。
没有兜底逻辑的数字人，遇到知识库外的问题容易一直绕圈。

第四，看会话日志和质检。
至少能按时间、渠道、问题关键词筛选会话，并能标记未解决问题。
没有日志就无法验证效果，也无法迭代知识库。

知识库整理和接口对接的实际操作

知识库不是把产品手册整本丢进去。
建议按“用户怎么问”来写，而不是按“公司怎么介绍”来写。
每条答案控制在 3 到 5 句，先给结论，再给条件。

可以按下面的字段整理成 CSV，再导入供应商后台：

问题,标准答案,适用场景,转人工
发货时间,付款后 48 小时内发出，节假日顺延。可在订单页查看物流单号。,实物商品,否
修改地址,未发货可联系人工修改；已发货需联系快递改址。,订单售后,是
发票申请,支持电子普票，下单备注抬头和税号，发货后 3 个工作日内发送至预留邮箱。,财务,否

导入后在后台逐条测试，重点检查同义问法是否能命中。
例如“多久发货”“什么时候发”“发货时间”应尽量映射到同一条答案。
多数后台提供相似问法或关键词配置，把常见变体补进去。

接口对接阶段，如果供应商提供 API，先在自己的测试环境用 curl 验证连通性，再接入正式渠道。
示例仅用于说明检查思路，实际地址和参数以供应商文档为准：

curl -X POST 'https://供应商接口地址/chat' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer 你的Token' \
  -d '{"sessionId":"test-001","question":"多久发货"}'

返回结果里要能看到答案文本、是否转人工、命中的知识条目。
如果只返回一段文本，没有命中标识，后续排错会很困难。

上线前必须做的避坑检查

不要承诺数字人做不到的事。 例如“保证解决所有售后问题”“自动退款”，这类话术容易引发纠纷。
涉及金额、时效、赔付的答案，应由人工复核后再写入知识库。

不要跳过敏感词和边界测试。 至少测试投诉、退款、法律相关、竞品对比、辱骂等输入，确认数字人不会乱答，而是按预设转人工或固定话术回复。

不要忽略渠道差异。 网页挂件、公众号、企业微信的输入长度和消息格式不同，同一套答案在某个渠道可能被截断。
每个渠道都要单独走一遍完整会话。

不要一次性全量切换。 先选一个咨询量适中的渠道灰度上线，保留原人工入口，观察一周会话日志后再决定是否扩大范围。

用三个指标验证外包效果

上线后不要只看“回答了多少条”。
更可核验的指标是：

• 独立解决率：没有转人工且用户没有重复追问的会话占比。可以从会话日志里人工抽样 50 到 100 条估算。
• 转人工准确率：应该转人工的会话是否及时转了，重点看退款、投诉、订单异常三类。
• 知识库缺口：日志里出现但未命中的高频问题，按周整理并补进知识库。

如果独立解决率低但转人工准确，说明知识库覆盖不足；
如果转人工也不准，优先检查兜底规则和意图配置。
连续观察两到四周，再和外包供应商复盘，比上线当天看演示更有参考价值。

AI数字人客服外包的合理定位是承接标准问题、分流复杂问题，不是替代全部人工。
把知识库、转人工规则和日志验证这三件事做扎实，再决定是否扩大使用范围，通常比单纯比较数字人形象更有效。