从0到1做 AI 客服：有赞这条路到底怎么走通的

很多团队做 AI 客服，第一阶段都能很快做出 Demo，第二阶段就开始卡住：响应慢、成本高、线上答非所问、协作混乱。

这篇有赞实践最有价值的地方，不是某个模型参数怎么调，而是它把“从能跑到能长期跑”的工程路径讲清楚了。

客服天然是高频、高重复、但又不能乱答的场景。你会同时面对几个矛盾：

• 想要承接率高，但又要尽量避免错答
• 想要体验自然，但又必须可控、可回归
• 想要快速上线，但后期又要压住成本和稳定性

有赞给出的核心原则很朴素：宁可不答，也不能答错。这个原则看起来保守，实际是把业务风险放在了第一位。

他们在早期用 Dify 快速搭建 MVP，优先验证 PMF。这个阶段最怕的是“还没证明价值就把系统做重”。

所以第一步不是追求最优架构，而是确认：

• 商家是否真的会用
• AI 回答是否能减少人工压力
• 哪些问题最值得优先自动化

业务量上来后，平台化方案会暴露问题：性能、检索实时性、版本治理和发布规范。

这时更稳的做法是混合架构：

• 核心链路（高并发、强实时、强可控）迁到自研工程系统
• 非核心链路仍保留在平台，保持迭代效率

这一步的关键不是“全部重写”，而是“分层迁移”。

当平台在性能、稳定性、可定制度上持续成为瓶颈，就进入全面工程化阶段。

这个阶段看的是长期能力：标准化发布、监控告警、版本回滚、可观测性、评测闭环，而不只是“回答像不像人”。

有赞初期选择了 Workflow，而不是高度自主的 Agent。原因很现实：在客服场景里，结果的可预测性比“智能感”更重要。

可以用一个简单判断：

• 涉及售后、物流、权益、规则解释：Workflow 优先
• 涉及导购、推荐、轻咨询：可逐步引入 Agent

不是二选一，而是主干流程先 Workflow 化，再把局部问题交给 Agent。

原文有一个很实用的经验：有时你花几天改 Prompt，不如换个更适配任务的模型。

另外两点也很关键：

• 模型输出越短，响应越快、成本越低
• 越到后期越不要频繁换模型，因为回归评估成本会明显上升

这背后其实是工程思维：先做模型与任务的匹配，再做提示词微调。

有赞在上下文优化上的路径可以概括为三步：

1. 信息获取：静态知识 + 动态实时信息 + 历史对话 + 多模态商品信息
2. 信息筛选：按入口场景、售前售后路由做定向检索与过滤
3. 信息组装：结构化拼装上下文，并设置知识优先级

他们提到一个常见坑：把所有信息都塞进上下文，模型反而更容易“失忆”或幻觉。

从实践看，至少要拆成三块：

• 商品知识：预学习静态信息 + 实时查询动态信息（库存、状态、物流）
• 历史对话知识：抽取高频 QA，去重分类，独立召回
• 文档知识：通过 chunk_size 和 chunk_overlap 平衡完整性与密度

有赞给出的文档切片参数（chunk_size=600、chunk_overlap=100）不是通用答案，但提供了一个可落地的起点。

AI 客服和传统软件测试最大的不同是：结果有概率性，且受模型、提示词、知识库共同影响。

所以评测不能只看“这次回答看起来不错”，而要建立持续闭环：

• 评测对象：场景、流程节点、知识质量
• 数据集：上线前构造 + 上线后持续沉淀 Goodcase/Badcase
• 评估方式：人工判断 + 相似度/规则评估结合
• 反馈机制：问题识别 -> 根因分析 -> 优化迭代

没有这套机制，系统很容易停在“偶尔表现很好，但不可运营”的状态。

这篇实践最值得借鉴的，不是某个工具，而是研发组织方式的变化：产品、研发、测试围绕 Prompt、逻辑、数据一起迭代。

如果你正在推进类似项目，可以先做三件事：

1. 定义好从平台到工程化的迁移触发条件
2. 把上下文工程和知识工程拆成独立可治理模块
3. 尽早建立可回归的评测体系，不要等线上问题堆积后再补

AI 客服真正的门槛从来不是“能不能回答”，而是“能不能稳定、低成本、可解释地持续回答”。