本篇提供公开联调方法，不提供产品源码或可直接运行的业务后端。帮助中心中的示例用于解释契约，真实会员身份和业务动作必须接到你们自己的系统。

第一轮：只接聊天与身份

准备一个测试站、两位测试会员和客服账号。配置允许嵌入的域名，放置聊天容器与脚本。买方后端从真实登录态生成身份，页面执行 identify；退出执行 logout，身份过期触发恢复。

依次验证：进入页面、发消息、刷新、断线重连、换设备、退出后换人。换人不串记录是验收重点，不是“有一条 WebSocket 就算完成”。只验证仍在保留期内的历史，记录当前消息清理配置。

第二轮：选一项读取能力

先接一个记录型看板或 FAQ 源。使用明确字段与稳定测试数据，确认正常响应、空数据、错误类型、超时和无效凭据。

看板验收显示字段是否声明、金额是否整数、时间是否秒；FAQ 验收整批成功、整批拒绝与旧内容保留。两者额外字段的处理规则不同，不能共用一套“多了就忽略”的假设。

第三轮：接写操作和通知

操作测试相同 request_id 两次请求，检查业务记录只执行一次；模拟写入成功但响应中断，检查不会自动重复写。

事件与邮箱保持同一 event_id 重发，检查 replayed 与会员实际消息数；信息用原编号原正文重试，测试到期和冲突。429 必须按 Retry-After 处理。

第四轮：再接 AI 员工

先发布通过校验的专岗流程，再连接其所需的看板、操作和外部服务。逐步记录谁判定、谁读取、谁执行、谁确认结果。技术失败、任务超时、用户取消与结果未知应得到各自出口。

最后让运营与客服用真实工作顺序走一遍：他们是否知道在哪配置、看到什么、出错后找谁。验证的是完整工作流程，不只是接口返回码。

交付记录

保留部署版本、功能开关、接口契约版本、验收场景与结果。测试材料用虚构会员和占位凭据；公开文档不附生产地址、真实日志或业务数据。需要具体工具与交付示例时，通过官网帮助中心协调。

产品与对接入口

本文为 2026-09-22 整理的公开说明；功能使用取决于已部署版本、配置和对接情况。接口实现以对应版本的帮助中心契约为准。