先整理容易核对的资料
准备产品名称与差异、有效价格与计费单位、服务范围、办理步骤、退款或售后规则，以及必须交给人工的问题。每份资料注明适用对象和生效时间，避免同时保留互相冲突的新旧报价。
不要把客户隐私和整段聊天当作公共知识。示例问答可以脱敏整理，但应区分事实资料、接待风格和权限边界。
把职责和回答依据分开
员工职责说明“负责什么、不负责什么”，知识库提供“回答依据是什么”，接待规则决定“什么时候转人工”。例如能介绍套餐，不代表能自行承诺折扣、退款、付款成功或替客户完成账号验证。
云小微的员工配置和资料关联应在试聊验证后发布。网页配置保存、资料发布、员工实际使用是不同状态，检查时不能只看上传完成。
用自己的十类问题检查效果
至少覆盖产品介绍、价格单位、周期优惠、适用限制、办理步骤、模糊需求、资料缺失、旧价提问、特殊承诺和人工接管。问题数量本身不代表质量，重点是检查回答是否有依据、是否说明不确定和是否越权。
把错误回答回到对应资料或规则中修改，再复测相同问题。不要因为一个问题答对，就宣称整套客服已经稳定覆盖所有情况。
上线时先限定范围
先选择明确账号和接待范围，保留人工介入。自动回复与跟进按授权执行，不因升级套餐就自动对历史客户补发消息。客户提出资料未覆盖的特殊方案时，由人工处理更合适。
价格、库存和订单能自动查询吗？
静态知识库适合说明通用政策和产品资料。实时库存、订单状态、付款结果或预约余量，需要有相应数据源和已接通的业务接口；没有对接时不能让AI把推测说成查询结果。
同样，能安排跟进不等于成交、发货和退款全流程已经自动化。购买前应通过真实业务演示确认这些边界。
用自己的微信和业务问题，先体验。
说明账号数量、接待人员和常见咨询，服务人员协助确认版本与演示范围。