构建真正可用的 AI 客服系统

AI 客服里最常见的失败方式，不是模型不够强，而是团队过早把注意力放在“自动回复”这一层，却没有先把回复背后的系统设计清楚。很多项目一开始就是一个 prompt 加一个模型，看起来很快就能出结果，但真正上线之后才会暴露出核心问题：工单如何分流、账号上下文从哪里取、哪些问题必须升级、低置信度要怎么处理、出现错误后怎样追溯。真正影响体验的，往往都是这些外围系统，而不是回复本身写得像不像人。

对小团队来说，目标不应该是“用 AI 替代客服”。更现实的目标是：让首轮响应、分类、重复性处理更稳定，同时保留明确的人类接管路径。这个目标听起来保守，但它会直接改变系统架构。如果一开始就以完全自动发送为目标，设计通常会过度乐观；而如果先以“提高一致性、缩短响应时间、保留审查权”为目标，系统更容易落地，也更容易长期维护。

第一个实际步骤，是把支持请求分成不同风险等级。低风险请求通常包括发货状态、退款政策说明、账户登录帮助、基础设置步骤、价格说明等。高风险请求则可能涉及争议扣费、异常退款、数据删除、合规要求、产品故障、情绪激烈的投诉，或者已经反复来回多轮的问题。如果这两类问题走同一条自动化路径，质量会非常快地下滑。低风险问题可以接受更高比例的自动化，而高风险问题需要更短的人类接手路径，以及更严格的规则控制。

请求分层之后，不要让一个模型步骤同时负责所有任务。更稳定的做法，是把流程拆成几个阶段。第一步做分类，判断请求类型和风险级别；第二步拉取上下文，包括工单线程、账号状态、历史交互、产品使用情况和相关政策片段；第三步再去生成回复草稿，或者为人工客服提供建议。这个拆分很重要，因为它让失败可以被定位。如果一次错误回复被发送出去，你需要知道问题出在分类、检索、上下文拼装，还是生成阶段，而不是把所有问题都归因于“模型偶尔会犯错”。

在客服场景里，上下文组装通常比模型选择更关键。一个强模型如果拿到的是不完整、不相关或不一致的上下文，仍然会表现得不可靠。生成回复前，系统至少应该拉到当前工单历史、用户账号层级、过去交互摘要、当前产品状态，以及与该问题直接相关的政策内容。更进一步，最好还能把原始用户消息整理成结构化内部表示，比如问题类型、紧急程度、涉及模块、是否存在流失风险、是否带有情绪升级信号。这样后续步骤就能更稳定，提示词也不会无限膨胀。

升级规则必须写得足够明确，而且最好能被代码直接执行。仅仅依赖“当模型置信度低时升级”通常不够，因为模型自评置信度往往并不稳定。更有效的是基于业务规则：如果消息里提到法律请求、退款例外、安全问题、多步骤账号异常、缺失必要账户信息、缺少对应政策依据，或者用户已经处于长线程未解决状态，就直接升级给人工。这类基于操作逻辑的规则，往往比模型自我判断更可靠，也更容易向团队内部解释。

对早期团队来说，草稿优先通常比自动发送更合理。系统先分类、拉取上下文、生成建议回复，并且标出依据和相关政策引用，人工客服再快速审阅发送。这样做的好处不是“更省事”，而是能积累真正有用的运营数据。团队可以知道哪些草稿被直接采用，哪些总是被改写，哪些场景模型会持续误解。如果一开始就自动发送，问题虽然也会发生，但你失去了学习和纠偏的缓冲层。

日志与事件记录必须被视为产品的一部分，而不是出了问题再补。一个有用的客服 AI 日志，至少应包含原始用户消息、结构化分类结果、上下文检索输入、命中的政策片段、模型输出，以及最终采取的动作。这里并不要求记录模型内部推理，而是要求保留清晰的事件链。没有这条链路，团队后续调试基本只能靠猜。客服系统一旦靠猜来排错，内部信任会迅速下降，大家会倾向于绕开系统，而不是继续优化它。

版本管理同样很重要。提示词会改，政策会改，路由规则会改，模型也会换。每一张工单都应该知道自己当时使用的是哪一版 prompt、哪一版策略、哪一个模型配置。否则一旦质量回退，团队根本没法回答最关键的问题：这次问题到底是哪个改动引入的。如果出了故障还要靠回忆“最近好像改过一些东西”，那这个系统就还没有进入可运维状态。

指标设计也要务实。“AI 处理了多少工单”几乎总是虚荣指标，除非它同时伴随更关键的数据，比如重复开启率、升级率、首响时间、中位处理时长、人工纠错率。对于草稿辅助型系统，更有价值的指标是草稿采纳率、发送前编辑幅度、重复类问题节省的时间，以及高风险工单的正确升级率。这些指标真正反映系统是否在减轻团队负担，而不是只让报表更好看。

最终，一个可用的 AI 客服系统本质上是“工作流设计 + 模型能力”的结合。模型当然重要，但通常没有分流规则、上下文质量、升级机制和可观测性重要。小团队更适合从窄场景开始，把系统做得可检查、可纠错、可逐步放权。这样的路径没有 demo 那么惊艳，但更接近真实用户环境，也更可能在几个月后仍然持续工作。