WordPress 网站 AI 客服上线前，需要分别验证双向消息、知识回答、人工接手和手机端操作。建议先跑通人工收发，再测试 Agent 回答，最后从公开网站走完一次 AI 到人工的接待。每一项都记录预期和实际结果，才能判断哪些业务范围已经可以开放。
本文给已经完成 WordPress 聊天入口安装的团队一份实操方法。不需要先设计复杂的评测系统，一张现有表格、一个测试访客窗口和一位负责接手的同事就能开始。还没安装的读者，可以先看 WordPress 网站接入 AI 客服指南及其中的操作视频。
测试前的准备：网站、Agent、知识和接手人员
测试前记下网站地址、目标工作区、网站渠道、负责接待的 Agent，以及本轮使用的知识版本。如果同时管理几个站点或几位 Agent，这些信息尤其重要：否则一次正常回复可能来自另一份配置，后面很难重现。
选一类已经整理好资料的业务问题，例如产品规格咨询。准备几个有明确答案的问题，再加入一个缺少前提的信息不全问题，以及一个明确要求人工的请求。所有示例都使用虚构测试信息；不需要拿真实客户订单、联系方式或争议事项来证明流程可用。
由一位同事使用访客窗口，另一位同事查看工作台。如果只有一个人，可以同时开普通窗口与无痕访客窗口，明确区分两侧。测试人工离线等分支时，优先使用测试渠道或安排不会打断真实接待的时段，不要直接把在岗同事全部设为离线。
步骤一：确认网站消息能双向收发
从公开网站打开聊天窗口，发一条容易辨认的测试消息，例如“网站验收 A01”。在 YundaDesk 工作台找到它，核对会话中的渠道标识和消息内容。测试编号只用于关联记录，不要在公开文章或共享截图里暴露实际访客身份。
接着由人工接手该测试会话，确认人工接待状态后回复一条短消息。回到访客窗口确认收到，再刷新页面查看消息是否仍然存在。工作台中的发送状态也要一并核对。入站成功只证明访客消息到达了工作台，不能替代回复回到访客端的证据。这一检查顺序与我们的 真实收发验收说明一致。
如果这一步没有通过，先停在消息问题上排查，不必同时调整知识和回复风格。这样拆开测试，是为了知道问题发生在哪一段，而不是让团队把所有设置一起修改，最后无法判断是哪项起了作用。
步骤二：测试知识回答、信息追问和连续对话
在 AI Agents 页打开“测试对话”，选择本轮的 Agent。先输入知识库能直接回答的问题，再用自然表达复问。测试对话适合查看回答过程，不会把这段测试消息发送给真实网站访客。具体使用方式见 测试 Agent 回答并查看详情。
下面是一个虚构的产品咨询测试组。假设资料已经明确：A 型需要外接电源；兼容性需要核对接口；特殊使用环境由业务同事进一步确认。实际测试前，请换成你的有效产品规则。
| 测试输入 | 重点观察 |
|---|---|
| A 型要插电才能用吗？ | 回答与供电说明一致。 |
| 拿到外面就能直接用了吧？ | 仍然说明供电条件，不顺着提问作错误确认。 |
| 我这台电脑能接吗？ | 先确认必要接口信息，不直接承诺适配。 |
| 这和 B 型一样吗？ | 区分型号；没有 B 型依据时说明需要进一步核对。 |
| 帮我找同事确认特殊环境。 | 按配置进入人工处理路径，给出明确下一步。 |
每次打开回答详情，检查它使用的知识是否支持结论。不要把“引用了一份文档”直接当作答案正确；引用的内容可能属于另一个型号，也可能没有支持回复里的附加承诺。测试记录要写出具体错在哪里，例如“漏掉外接电源条件”，而不是只有“效果一般”。
然后测试连续追问。访客第一次说明型号，第二次补充使用场景，第三次问下一步该怎么做，客服应围绕已经提供的信息继续处理。测试独立知识点时使用新对话，测试上下文时保留同一段对话，避免两种目标混在一起。
步骤三：检查真实网站与手机端的 AI 接待
内部测试通过后，核对网站渠道绑定了正确且已启用的 Agent，再用新的访客会话发送同一组核心问题。确认 AI 回复真实出现在网页聊天窗口中，而且没有同一回答重复出现的情况。
网站测试要保留内部测试的关键条件：相同知识版本、相同 Agent 和可识别的测试问题。若测试对话正常、网站表现不同，先核对两者实际使用的配置和会话状态，而不是直接判断模型能力发生变化。
接着用手机打开一个主要入口页和一个产品页。检查聊天按钮是否可点击，输入法弹起后能否看到输入框与发送按钮，聊天窗口能否关闭，关闭后是否回到原来的浏览位置。如果页面上还有询价按钮或固定导航，检查它们是否被聊天入口遮挡。
步骤四：验证转人工和无人在线两条路径
在刚才的访客会话里明确请求人工。核对客户看到的排队或无人在线提示是否符合该渠道实际可接待人员的状态，然后由负责同事进入会话，完成接手并回复。客户侧收到人工回复，才算这个分支走到了需要的终点。
人工应能读到访客前面说过的型号、场景和未解决事项。接手后再发送一条追问，检查是否由人工继续处理，AI 没有重复自动回答。不要只看到“正在转接”文字就结束测试；提示、接待状态和实际回复要对得上。相关规则见 转人工帮助说明。
离线分支单独测试。可以在隔离测试渠道中安排无人可接待的状态，检查提示是否准确，也检查后续由谁处理等待中的会话。提示里只写团队能执行的服务时间和联系方式，不把“马上回复”作为所有情况的默认答案。
验收结果：什么情况下可以开放正式接待？
在原有表格中，为每条测试保留问题、预期结果、实际结果、时间、会话依据及处理人。结果可以标为“通过”“未通过”“未测试”。未测试不是失败，但不能算进已验证范围；仅部分题目通过，也不应写成所有场景已经可用。
本轮上线判断应具体到业务范围：例如“产品规格问答、信息追问和工作时间人工接手已验证；特殊环境咨询继续由人工确认”。这是一种记录方式，不是本文替任何站点作出的实际验收结论。出现错误承诺、消息无法送达或接手后重复回复等关键问题时，先修好受影响路径再开放对应范围。
测试题量取决于业务差异，不存在问完固定几道题就保证可靠的数量。首次可以从一小组代表题开始；产品系列、语言、政策条件越不同，越需要补充相应测试。团队的目标是覆盖会改变处理方式的条件，而不是单纯追求一张漂亮的通过率报表。
失败排查：消息、答案和转人工问题分别怎么查？
访客消息没有进入工作台，先查网站入口和渠道连接；人工回复在客户侧不可见，查发送状态与渠道错误提示；AI 引用了不相关资料，查知识范围与具体引用；人工未能接手，查成员权限、渠道名单和当前接待状态。保存具体提示，能让后续支持更快定位。
修复后先重跑失败项，再复测紧邻的正常项。例如改了产品知识，除了重问错误题，还要确认另一个型号没有被影响；调整了接待范围，除了测试人工接手，也要确认原本的 AI 常见问答仍正常。不要为了看一次成功结果而同时更换问题、资料和 Agent。
完成这一轮后，保留测试记录和问题组。之后更换主题、更新插件、调整知识或接待设置，都能复用它检查受影响部分。YundaDesk智能客服的回答详情与会话记录提供了核对依据；团队负责把这些依据连接成一条真实、可复查的接待过程。
网站客服测试常见问题
测试对话里回答正确，为什么还要测公开网站？
测试对话主要核对所选 Agent 的回答过程；公开网站还涉及渠道绑定、当前会话接待状态、实际消息送达和页面操作。两个测试覆盖的环节不同，内部回答正确不能替代访客侧收到回复的证据。
只有一个人，能完成这一轮验收吗？
可以先用不同窗口区分访客与工作台，完成消息、知识和状态切换检查。换班交接最好再请另一位有权限的同事验证，因为参与了整段测试的人容易把自己已经知道的信息，误认为接手者也能从会话中看到。
上线后什么时候需要复测？
知识版本、Agent、渠道配置、网站主题或插件发生相关变化后，复测受影响路径；发现客户反复追问或回复未送达时，也应把具体问题加入原测试记录。优先复用已经确认过的题目和环境，才能比较变化前后的表现。
把验收清单与知识、人工流程一起维护
如果本轮主要问题来自资料，先按 AI 客服知识库搭建指南整理依据；如果问题发生在接手以后，用 转人工后的团队交接指南核对待办和责任。安装、知识、验收和交接各自有明确检查对象，就不必每次遇到异常都从头重配。
YundaDesk智能客服: https://yundadesk.com