聊天机器人错误：
查找与修复

从一次具体的失败对话入手

“机器人不好用”不足以帮助修复系统。需要记录输入消息、操作顺序、时间、预期结果和实际结果。检查范围不能只停留在聊天记录：即使机器人已提示成功，咨询仍可能在消息渠道、搭建平台与 CRM 之间丢失。

区分流程逻辑错误、消息投递故障和 AI 回答错误。第一类需要调整逻辑，第二类需要检查连接与事件处理，第三类需要检查回答来源和操作边界。更换模型无法修好失效的集成，新增按钮也不会更新过期价目表。

在开发任务中保存可复现的示例。不要把包含个人信息的完整聊天记录复制到公共工作群；提供匿名化操作顺序，以及供负责人员定位问题的事件标识即可。

错误：把聊天本身当作成果

消息数量只能反映活跃程度，不能说明机器人是否有用。对话很长，可能是用户一直得不到答案；对话很短，可能是任务已完成，也可能是访客立即离开。不能把这些不同结果都归为“成功对话”。

为每个流程明确单独的结果：咨询记录已保存且数据齐全、预约已获预订系统确认，或用户已收到答案且未再请求帮助。不能仅因用户不再发消息，就把咨询标记为已解决。

如果尚未明确机器人的任务，请先阅读聊天机器人创建方案。同时自动化销售、客服、招聘和内部审批，却不制定各自的规则，会让开发和验证都变得困难。

错误：只设计理想流程

开发人员会按正确顺序点击正确按钮；真实用户却可能输入文字而非选择选项、返回旧消息、修改答案、中断后再继续。机器人应说明下一步，并允许用户纠正输入。

1. 使用新账号开始对话：没有设计者提示时，任务是否清楚？
2. 输入意外答案，在允许的地方发送空消息，或发送不受支持的文件类型。
3. 返回上一步并修改选择，检查最终结果是否随之更新。
4. 完成咨询提交后，点击旧消息中的按钮，确认不会创建内容冲突的订单。
5. 分别用自然语言和人工客服按钮请求帮助。

不要为所有任务设定统一且随意的按钮数量上限。更重要的是选项可区分、名称易理解。用户还不清楚下一步去哪里时，“选择办公椅”比“继续”更明确。

单独检查搭建平台中的等待节点和计时器。“未点击按钮”分支不能在用户有机会回答之前启动。操作完成后，应取消或重新计算提醒计时，否则“您还有未完成咨询”的提醒会在提交后才到达。

错误：回答没有来源，也无人负责

过期的配送时间或不存在的折扣，会同时影响普通机器人和 AI 机器人。首先查明说法来自哪里：预设文本、知识库、目录、外部系统响应，还是自由生成。应修复实际被系统使用的来源。

为重要回答建立简明台账：主题、来源、负责人、检查日期和复核条件。商品库存与可预约时段最好从正在使用的系统获取。若没有这种连接，回答应说明需要员工进一步确认。

检查相互矛盾的信息：一份说明承诺七天内换货，另一份写十四天；价目表与商品卡片显示不同金额。机器人不能自行选择方便的版本。将问题交给内容负责人，修复后重新验证。

明确更新如何进入正式运行版本。上传新文件和更新机器人实际使用的知识库，可能是两个不同操作。记录来源版本和重新测试的时间。

错误：让 AI 决定访问权限

模型自由生成回答，与获得修改订单的权限，是两种不同功能。身份核验、访问他人数据、允许的折扣和退款授权，都应由业务系统检查。用户声称“我是管理员”，并不能证明其权限。

OWASP 将提示词注入描述为通过输入文本和模型处理的其他材料干扰模型的风险。接入知识库本身并不能消除此风险。应限制机器人可执行的操作，并在错误可能产生重大后果的环节要求人工审核。

使用教学数据准备安全测试：要求查看他人的订单、承诺未经确认的折扣，或执行允许流程之外的操作。提前定义预期结果：拒绝、澄清或转交员工。不仅要检查文本，还要确认背后没有触发未授权操作。

保留这组测试，并在更换模型、指令、工具或知识库后重新执行。对于接入外部系统的 AI 智能体，应同时评估回答质量与已执行操作的正确性。

错误：承诺人工服务，却没有有效接管流程

“呼叫客服”按钮不能证明有人收到咨询。要检查完整路径：请求进入队列、员工被指派、员工可查看上下文、客户知道接下来如何等待，以及员工确实作出了回复。

检查三种情况：工作时间、所有员工都忙、非工作时间。每种情况下，下一步都应清楚。若团队无法兑现，或没有统计响应时间，就不要承诺“一分钟内回复”。

人工接入后，自动回复不能打断对话。明确由谁、通过什么操作将对话交还机器人。检查旧计时器是否会在处理投诉时重新启动销售流程。

在咨询记录中传递问题摘要、已选参数和可用历史记录。如果平台无法传递部分数据，应在流程设计中考虑这一限制，而不是对客服隐藏它。

错误：尚未保存就确认提交成功

“咨询已受理”必须与真实结果一致。CRM 不可用时，可以进入稍后投递的队列，或提示临时故障。提前确定处理方式，不能让用户猜测是否需要再次提交数据。

走完流程，通过测试标记查找 CRM 记录，核对字段、来源、负责人和状态。然后重复提交，检查是否出现重复记录。另在测试环境中模拟集成不可用：恢复后是否重新完成投递，原始咨询是否保留？

在 Telegram 中，标识符update_id有助于识别重复收到的事件，其用途见Bot API。咨询本身还需要稳定的操作标识，因为用户点击两次按钮可能产生两个不同事件。

结合CRM 配置明确数据传递细节和员工职责。修复集成的一端，并不能保证另一端正确处理数据。

错误：连接已中断，却只排查对话流程

Telegram 机器人没有回应时，先从另一个账号打开并点击开始，再在搭建平台中检查渠道是否启用、流程是否发布。通过 BotFather 注册只会创建机器人账号，不会自动提供可运行的回答逻辑。

对于自研实现，请让技术人员检查getWebhookInfo：待处理事件队列，以及最近一次错误的时间和内容。Webhook 与通过 getUpdates 轮询获取更新不能同时使用，具体说明见官方常见问题。

收到 429 响应时，检查频率限制的处理方式。如果响应包含retry_after，则等待指定时间后再重试。无限立即重试只会增加负载。

不要把机器人令牌发送给在线检测服务或无关人员。报告只需提供匿名化诊断结果。项目负责人需要知道投递在哪个环节中断，不需要为此获取访问密钥。

修复连接后，重新测试普通对话、人工接管和咨询保存。开始命令得到回复，不代表所有功能都已恢复。

错误：将所有结果混成一个转化率

区分进入流程、完成流程、转交人工、拒绝、技术错误和中断对话。每项指标都需要明确事件、统计周期和分母，否则很容易把报表变化误认为实际改进。

教学示例：100 人开始选购，保存了 30 条咨询，10 人请求销售人员协助，60 人在不同阶段停止。转化为已保存咨询的比例为 30%。不能宣称其余 70 次咨询都已自动解决，也不能未经核实是否重叠，就将人工接管数与咨询数直接相加。

查找原因时，检查漏斗各阶段和真实对话。如果大量用户在提供手机号前离开，应核实该字段是否必要、是否说明用途，以及用户能否先获得有用答案。

错误：修改正式版本后不重新测试

即便只修改一个节点，也可能破坏流程跳转、CRM 字段，或旧按钮所引用的消息。保存上一版本和变更记录。先在独立测试机器人或测试环境中验证，再发布，并明确回退方法。

每项修复都需要负责人、截止时间和结果证据。重走最初的故障场景，并检查相邻流程后，才关闭任务。“代码已更新”只说明开发人员做了操作，不能证明客户的问题已经消失。

指定专人查看新错误并联系知识内容负责人。即使是小型机器人，也需要持续维护，因为产品、排班、连接系统和团队规则都会变化。

修复后检查清单

聊天机器人错误常见问题