值班的同事盯着一封客户来信。信里没有技术术语，只有一句“你们的机器人让我白跑了一趟”。这不是故障报告，处理起来却更麻烦——系统日志干干净净，没有任何异常。
把生成式人工智能接进客服，麻烦往往不在它答不出来，而在它答得太顺。
流畅本身是一种负担
语言模型的训练目标是把下一句写得像样，不是把这一句写对。于是它用同一种语气说出准确的营业时间，也用同一种语气编出一条并不存在的办理流程。传统系统出错的表现是拒答、空白、红字报错；现在出错的表现是通顺、完整、格式漂亮。
这让验收的动作变了。以前看接口通不通，现在得坐下来读一百条真实提问的回答，读的时候眉头有没有皱一下。写测试用例也不够用——固定的用例覆盖不了用户千奇百怪的表述方式，而恰恰是这些表述，才是当初想让它来处理的部分。
评估这件事，最终落回到人身上
上线前该问的不是“准不准”，而是“错在哪会怎样”。问营业时间答偏了，用户刷新一次就过去了；问退换流程答偏了，对方可能真的跑一趟门店。同一个准确率数字，藏着的后果并不一样。
所以场景更该按出错的代价分层，而不是按调用量分层。这一步判断机器给不了，得由熟悉业务的人来划。谁来看样本、看多少、看完之后改提示词还是改知识库，这些琐碎的安排决定了系统是能用还是摆设。
检索、微调，先把话说清楚
想让回答靠得住，路径不止一条。有人往里挂知识库，让它先查再答；有人反复打磨提示词，把口径和禁忌写进系统设定；也有人选择微调，让语气更像自家客服。
这几件事解决的不是同一个问题。检索缓解的是“不知道却硬答”，微调更多解决“答得对但不像我们的说法”。不少团队一上来就想着训练模型，其实先把内部文档从散落的表格和过期的截图，整理成能被检索的样子，效果会更早显现。这里没有通用答案，只有你手上那份资料有多乱。
允许它说“我不知道”
对生成式人工智能来说，承认无知是件别扭的事。它被训练成继续往下写，而不是停下来。可以用提示约束、可以设置信门槛、可以在识别到敏感意图时转人工，但每一条兜底路径都有成本，也都需要有人维护。
关键在取舍：保留一个能被看见的转人工入口，风险就摆在明处；追求全自动，风险只是被藏起来，直到某天变成一封客户来信。前者要人手，后者要运气。很多团队在这两者之间反复，其实是在权衡自己能不能承受一次沉默的错误。
它擅长的是消化长尾表达——同一个意思的十种说法，人写规则写不完，它接得住。它不适合替你做“错了要担责”的判断，也不该被要求什么都会。把边界划在流程里，比写在宣传页上更实在。
回到那封信。回复里没有提模型，只写了具体的处理方式和一句“下次您可以直接找我们”。技术待在幕布后面，这大概是它该待的位置。