AI客服答非所问？5个真实故障复盘：从"没生成出内容"到把客户催单判成噪声

几乎每个上线 AI 客服、数字人接待的团队都会经历同一个落差：演示环境里对答如流，一上真机就答非所问。于是第一反应往往是"模型不行，换个更强的"——而我们运维自有数字人接待系统的实际记录显示，这类故障里压倒性的多数跟模型智力无关，全部出在链路的工程细节上。

下面是我们真实踩过、并且已经修完的 5 类故障。每一条都给出现象 → 根因 → 修法，可以直接当排查清单用。

故障一：查天气、查资讯全查不到——依赖悄悄躺在临时目录里

现象：客户问"今天苏州天气怎么样"，AI 客服一律回查不到；问新闻、问资讯，同样全空。而开发机上一切正常。

根因：取数用的中继脚本当初是随手放在服务器的 /tmp 下、用 setsid nohup 拉起来的——没有进程守护、没有开机自启。而业务代码当时只走这一条中继路径。于是服务器一重启、或临时目录被系统清理，中继就静默消失（端口连接被拒），联网能力 100% 失效，且没有任何报警。

修法（双管齐下）：

• 依赖侧：脚本从 /tmp 挪到固定家目录，写成 systemd 服务并设 Restart=always，日志落到明确路径、开机自启。
• 调用侧：把"单路径"改成本机直连优先、中继兜底。先走直连，直连不通再退回中继；并保留一个开关，便于临时切回只走中继做对照实验。

推论：顺便纠正一个想当然的错误结论——我们一度以为"主控机没有外网"，实测发现它有真直连外网。中继只是兜底，不该是唯一命脉。凡是放在临时目录的外部依赖，都是定时炸弹。

故障二：文档/家教任务回"没生成出内容"——推理模型把自己的输出预算吃光了

现象：让 AI 客服写一份文档、做一次家教式讲解，它回的是一句"没生成出内容"。有响应，但正文是空的。

根因：这类任务用的是带"思考"开关的推理模型。开启思考后，推理过程的 token 与最终正文共用同一个输出上限。任务稍复杂，思考就把 max_tokens 吃满，接口返回的 finish_reason=length（因长度截断而非正常结束），正文部分根本没轮到输出。前端看到的就是"空回复"。

修法：

• 对长正文任务单独调高输出上限，别让思考和正文抢同一份预算；
• 或对纯生成类任务关闭思考模式；最稳妥的是把"思考预算"和"正文预算"显式分开配置；
• 同时在代码里判 finish_reason：一旦是 length 且正文为空，要能识别成"预算不足"而不是"模型不会"，给出可诊断的错误，而不是静默的空结果。

故障三（最贵的一个）：客户催单被当成"环境噪声"，数字人直接不理人

现象：展厅里客户说"这个什么时候能发货""帮我叫一下人"，数字人毫无反应；偶尔说一句"没听清，请再说一遍"。客户体验上等于"这不理人"。

根因：为了过滤视频播放声、旁人闲聊等干扰，系统给模型下了一条"遇到环境噪声就输出标记"的指令，代码收到标记便把整条输入丢弃并提示重说。问题在于——模型会把正常的客户提问误判成噪声。我们对同一套噪声判定指令做了实测对比：两个主流模型都会把"这个什么时候能发货"这类正常催单判成噪声，只是概率有高有低（一个约三分之一、另一个约三分之二）。

关键结论：换模型解决不了这个问题。因为噪声判定的标准本身太宽——只要标准宽，换哪个模型都会咬人。这是一个策略问题，不是智力问题。

修法（必须双修）：

• 提示词侧收紧标准：只有"明显与对话无关、且完全不像在跟客服说话"时才判噪声；凡是像提问、催促、抱怨、打招呼的，一律正常回复；拿不准一律按正常回复处理。
• 代码侧加硬保护：即便模型偶发给出噪声标记，也再用一套不含噪声指令的提示强制正常回复一次，只有真噪声才走丢弃分支。
• 回归测试三项都要测：正常输入必须全部被回复、真噪声（字幕、片尾台词等）仍要被过滤、新策略不能因保护客户而放过噪声。

设计原则：两类错误的业务代价严重不对称——漏掉客户真实发言（喊话没反应）远大于多回一句无关台词（显得话多）。所以兜底必须向"不漏话"倾斜：宁可多回，不可漏话。

故障四："后端崩了"其实是假象——控制台编码把排查带偏

现象：回归测试时脚本报 UnicodeEncodeError，看起来像后端整个崩了。

根因：测试脚本向 Windows GBK 控制台打印 emoji 等字符时抛编码异常——崩的是测试脚本的打印，不是后端。

修法：在任何结论之前，先把控制台与 Python 的编码显式设为 UTF-8（如设置 PYTHONIOENCODING=utf-8、PYTHONUTF8=1），再复跑一遍。另外，服务本身若没做日志重定向，排障时不要去找日志，直接看回归脚本的返回值更可靠。

故障五：输出层风格漂移——交付文案忽长忽短、漏掉必要元素

现象：生成内容能出来，但格式不稳定——该带的标记漏了、语气忽冷忽热、同一类任务两次输出结构不一致。

根因：风格要求散落在长提示词里，缺乏确定性的校验与兜底环节。

修法：把风格治理做成独立的后处理层——固定输出骨架、对必要元素做"缺失即补齐"的兜底、把接地信息（如常见问题）挂到确定性的知识片段上，而不是指望模型每次都自觉。风格要求是产品能力，不能靠运气。

归纳：AI 客服上线前的五条纪律

#	纪律	对应故障
1	所有外部依赖必须有开机自启 + 进程守护，绝不放临时目录	故障一
2	每一条依赖路径都要有兜底，禁止单点	故障一
3	推理模型要区分"思考预算"与"正文预算"，并判 finish_reason	故障二
4	兜底策略按错误代价不对称加权：宁可多回，不可漏话	故障三
5	回归测试必须覆盖真实链路与观测工具本身	故障四、五

把这几条落成清单之后，我们的数字人接待系统从"演示能跑"变成了"能在没人看着的情况下自己活着"。这也正是我们做 AI 落地服务的判断标准：能无人值守跑下去的自动化，才算真的上线了。

查看《AI 起步工具包》→