很多团队做智能客服，上来就想着微调千亿大模型、搭建复杂的Agent框架。结果三个月过去了，连“查订单”都经常答错。我用一个零食连锁的真实案例告诉你：从0到1落地智能客服，最核心的不是模型，而是这三件事。

1. 翻车：我们差点做了一个“万能”的客服

去年我们给一个零食品牌做智能客服，客户的需求是：“能不能做一个什么都懂的客服？用户问啥都能答。”

团队一听很兴奋，马上开始选大模型——GPT-4、通义千问、文心一言，对比了一圈，决定用某大模型做底座，搭建一个全能的对话Agent。

两个月后，demo出来了。

用户问：“我的订单到哪了？”

模型答：“亲，您可以登录APP查看订单详情哦。”（没查接口，纯话术）

用户问：“薯片碎了怎么办？”

模型答：“建议您联系客服处理。”（又把球踢回来了）

用户问：“会员积分怎么用？”

模型答：“积分可在积分商城兑换商品。”（但不知道怎么兑换、链接在哪）

问题出在哪？ 我们一上来就想做“大而全”，却忽略了最基本的场景聚焦、数据准备和系统对接。模型再强，没有业务知识和执行能力，就是个会聊天的花瓶。

2. 反思：MVP应该只做三件事

痛定思痛，我把项目推倒重来。这次我给自己定了一个原则：先做三个最简单、最高频、最标准化的场景，其他的统统砍掉。

我们选了零食客服中最常见的三类问题：

1. 查订单物流：“我的订单到哪了？”“薯片发货了吗？”
2. 查会员积分：“我有多少积分？”“积分怎么用？”
3. 申请退款：“薯片碎了，我要退款。”

就这么三个场景。目标是：让用户在这三个问题上，能完全自助解决，不需要转人工。

为了实现这个目标，我聚焦做了三件事。

第一件事：把业务知识“结构化”

模型不懂业务，需要我们把知识喂给它。但我们不搞复杂的知识图谱，只做了两件简单的事：

1. 整理FAQ文档：把客服团队常用的标准问答，整理成一份 faq.md，每条包含“问题模板”和“标准答案”。例如：

问题模板：[“订单到哪了”, “物流状态”, “发货了吗”]

标准答案：您的订单当前在【XX】仓库，物流单号【XXX】，点击链接查看实时轨迹。

2. 写SOP流程：把“退款”这类需要多步操作的场景，写成标准操作流程。例如：

退款流程：

1. 获取用户订单号
2. 调用订单接口判断订单状态（是否可退）
3. 根据退款原因（破损/漏发/不喜欢）走不同审批流
4. 调用退款接口执行退款
5. 返回结果给用户

这些文档和流程，就是后面所有智能的基础。没有结构化的业务知识，模型再大也是白搭。

第二件事：用大模型做意图识别 + 槽位填充，但只做“轻量级”

我们仍然用了大模型（通义千问），但不是为了生成对话，而是为了做NLU。

具体做法：

把用户问题 + 预定义的意图列表 + 槽位定义，打包成一个prompt，让大模型输出JSON。

例如用户说“薯片碎了，订单号12345，我要退款”，模型输出：

{

“intent”:

“apply_refund”,

“slots”: {

“product”:

“薯片”,

“issue”:

“破损”,

“order_id”:

“12345”

}

}

然后我们写了一个轻量级的对话管理器（状态机），根据意图和槽位，决定下一步：是直接调用API，还是追问缺失的信息。

为什么不直接用大模型生成回复？

因为大模型生成回复不可控、延迟高、成本高。我们只需要它做“翻译”——把用户的话翻译成结构化的指令，剩下的交给确定性代码执行。这样既发挥了LLM的理解能力，又保证了可靠性和实时性。

第三件事：接入真实系统，形成闭环

光回答不行，要能办事。

• 查订单：调用订单系统的API，实时返回物流状态。
• 查积分：调用会员系统的API，返回积分余额和使用链接。
• 申请退款：调用退款API，自动创建工单，走审批流程，完成后通知用户。

闭环的关键：用户说完需求，系统能自动完成全部操作，不需要人工介入。只有遇到异常情况（如订单状态不可退、退款金额超限）才转人工。

3. 数据与技术选型：为什么我选了通义千问而不是其他模型？

提供思路参考：后续如果有新模型需要重新选型，可以根据场景需求进行比对参考。

结论：对于NLU这类结构化任务，不需要最强的模型，够用、快、便宜、安全才是MVP的首选。

4. 上线与反馈闭环：我们是怎么迭代的

1）小范围测试：先在小部分门店的客服入口上线，每天处理 200 条真实咨询。

2）收集badcase：用户说“答错了”或转人工的对话，全部打标。

3）每周迭代：

• 更新FAQ文档（补充新的问法）
• 优化SOP流程（调整退款审批规则）
• 微调prompt（增加few-shot示例）

4）核心指标监控：

• 意图命中率
• 自助解决率
• 转人工率

效果：三个月后，三个核心场景的自助解决率从 50% 提升到 80%，为人工客服 提效50%

5. 坦诚局：哪些场景这套MVP搞不定？

1. 用户一次提多个问题：“薯片碎了，顺便查一下巧克力物流”——我们的单意图模型只能处理第一个。
2. 用户情绪激动：“你们真是垃圾！”——模型识别不了情绪，也无法安抚。
3. 用户问的是“非标品”：“这个糖甜不甜？”——没有结构化知识，需要调商品数据库。
4. 超长上下文：用户聊了10轮才说需求，我们的状态机记不住。

这些问题，我们在后续迭代中逐步解决（多意图、情绪识别、知识库RAG、记忆系统），但MVP阶段不需要。

6. 结语：先做精，再做广

智能客服的0-1落地，不是模型选型竞赛，而是场景聚焦、知识结构化、系统闭环的三步走。

• 别贪大：先选3个高频标准化场景
• 别迷信模型：大模型只做NLU，确定性流程用代码
• 别跳过系统对接：能办事才是客服，不然只是话术机器人

从这三个场景跑通，再到扩展到10个、20个场景，你会走得比那些“一上来就搞大模型”的团队快得多。

下一篇预告：《用户说“薯片碎了”，机器回“要买吗？”意图识别的翻车与救赎》