从零搭建一个AI客服机器人：完整实操记录
2026-07-30
从零搭建一个AI客服机器人：完整实操记录
上个月老板突然丢给我一个任务：搞一个AI客服机器人，能处理80%的常见问题。预算？零。时间？两周。说实话，我当时第一反应是找现成的SaaS服务，一看价格直接劝退——最便宜的按月收费都要几千，而且数据还得上传到别人的服务器。于是我开始琢磨，能不能用开源工具，自己搭一个能用的。
结果还真让我搞出来了。今天就把这完整过程记下来，从选型到部署，踩过的坑和收获的经验都摊开说。
选工具：为什么是Dify + Ollama + Qwen
最开始我列了几套方案对比，核心需求是：本地部署、中文友好、能对接知识库、支持流式输出。市面上主流的开源方案我筛了一圈：
| 方案 | 部署难度 | 中文支持 | 知识库功能 | 硬件要求 |
|---|---|---|---|---|
| LangChain + 本地模型 | 高 | 中等 | 需自行实现 | 8GB显存起步 |
| FastGPT | 中 | 好 | 内置 | 16GB内存 |
| Dify + Ollama | 低 | 好 | 内置且灵活 | 4GB显存可用 |
| Rasa | 高 | 一般 | 需NLP组件 | 无特殊要求 |
我最后选了Dify + Ollama + Qwen2（7B）的组合。原因很简单：Dify有现成的RAG（检索增强生成）工作流，Ollama一键拉模型，Qwen2中文能力在7B量级里算顶尖的。硬件上，一台带RTX 3060（12GB显存）的台式机就能跑，如果没显卡，CPU推理也能用，就是慢点。
安装过程其实比想象中顺。Dify用Docker部署，一行命令就拉起来了：
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
Ollama更简单，官网下载安装包，或者Linux上：
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2:7b
前后大概半小时，一个能跑的AI客服骨架就有了。不过这时候还只是个空壳，只能聊些通用话题，完全没法回答业务问题。
知识库搭建：这才是核心
很多人以为AI客服就是接个大模型，问啥答啥。实际上，没有业务知识库的AI客服就是个花瓶。你得把产品手册、FAQ、常见问题解决方案喂给它。
我做的第一步是整理数据源。公司有份40多页的《产品使用手册》PDF，还有客服团队过去一年积累的800多条问答记录，格式乱七八糟，有Excel的、有微信聊天记录的、有飞书文档的。我花了整整两天把这些数据清洗成统一的格式——每一条记录包含「问题」和「答案」两个字段，问题尽量简洁，答案要完整。
这里面有个细节：问题要写多种问法。比如用户可能问“怎么退款”，也可能问“要退货怎么办”、“订单取消了钱去哪了”，同一个意思至少准备3-5种表述。我一开始只写了标准问法，结果用户问“你们客服电话多少”，模型直接傻了，因为知识库里只有“如何联系客服”这个条目。
Dify的知识库上传功能支持PDF、Word、Markdown、纯文本等多种格式，上传后会自动做文本分块和向量化。我试了几个分块策略：
- 按段落分：太碎，上下文断了
- 按固定字数分（500字）：容易切在句子中间
- 按语义分（Dify默认）：效果最好，但需要人工微调
最终我选择了按段落+手动调整：先用Dify的自动分块，然后逐条检查，把明显属于同一主题的块合并，把跨主题的块拆开。这个过程有点枯燥，但非常值得，直接决定了检索的准确率。
工作流配置：把机器人调教成能用
知识库上传后，我在Dify里创建了一个「客服助手」应用。核心配置就几项：
提示词（Prompt） 我写了这么一段：
你是一个专业的客服助手，名为「小智」。你的职责是回答用户关于[产品名]的问题。
请严格遵守以下规则：
1. 基于知识库内容回答，不要编造信息
2. 如果知识库中没有相关内容，明确告知用户“这个我暂时不清楚，建议转人工客服”
3. 回答要简洁，不超过200字，避免长篇大论
4. 语气亲切，但不要过于随意
5. 遇到情绪激动的用户，先安抚再解答
变量设置 我加了几个关键变量：
- temperature（温度值）：设为0.3，让回答更确定，减少胡说八道
- top_k（检索数量）：设为5，只取最相关的5个知识片段
- rerank（重排序）：开启，让最匹配的片段排到最前面
对话开场白 我写了个引导语：
你好，我是小智，[产品名]的智能客服助手。你可以直接问我产品使用、订单、售后相关的问题。如果需要转人工，请说“转人工”。
这一步调了大概三天。最开始发现模型经常答非所问，后来排查发现是temperature太高（0.7），回答太发散。降到0.3之后，回答稳定多了。还有个坑是知识库权重——Dify默认知识库和模型知识各占50%，导致模型会用自己的通用知识回答，而不是优先用业务知识库。我把知识库权重调到80%，模型知识降到20%，效果才出来。
部署到实际渠道：微信和网站
光在后台测试不够，得让用户能用上。我接了两个渠道：企业微信和公司官网。
企业微信的接入比想象中麻烦。Dify支持Webhook对接，但企微的开放平台需要申请应用、配置回调地址、验证IP白名单。我折腾了一下午，最后发现关键步骤是：
- 在企业微信后台创建一个自建应用
- 配置接收消息的URL为
https://你的域名/v1/chat-messages - 在Dify的「渠道」设置里，填上企微的Token和EncodingAESKey
- 用Dify提供的签名验证函数做URL验证
官网的接入就简单多了——Dify直接生成一段JavaScript代码，嵌入到网页里，一个浮动气泡聊天窗口就出来了。前后十分钟搞定，连样式都不用自己写。
上线第一天，我紧张地盯着后台日志，生怕出什么幺蛾子。结果还不错，当天收到了127条用户消息，其中83条被机器人成功回答，正确率大概75%左右。剩下的要么是知识库里没有覆盖到的问题，要么是问法太奇怪模型没理解。不过好消息是，没有出现明显的错误回答——至少没有把“怎么充值”回答成“如何注销账号”这种致命错误。
持续优化：那些意想不到的问题
运行一周后，我发现几个问题：
第一，用户喜欢连续追问。 比如问完“怎么充值”，接着就问“充错了能退吗”，然后“退款要多久”。单轮问答没问题，但多轮对话中，模型会逐渐忘记上下文。解决办法是在Dify里开启「对话历史」，把最近5轮对话作为上下文传给模型。
第二，长尾问题处理不了。 有些用户会问很具体的问题，比如“我的订单号是123456，什么时候发货”，这种需要查数据库。目前我的解决方案是：当检测到用户提供订单号、手机号等敏感信息时，自动触发转人工流程。Dify有这个关键词检测功能，配置起来很方便。
第三，模型偶尔会“幻觉”。 有次用户问“你们公司在深圳有门店吗”，模型居然回答“有，在福田区”，实际上我们根本没有线下门店。后来我加强了Prompt里的约束，并且在知识库里加了一条明确的说明：“本公司目前没有线下门店，所有业务通过线上完成。”
现在这个机器人已经稳定运行三周了，处理了大概3000条消息，自动解决率稳定在70%左右。虽然达不到老板要求的80%，但已经帮客服团队减轻了不少压力。最关键的是，整个搭建过程没花一分钱软件费用，只有服务器电费和我的时间成本。
如果你也想从零搭一个，我的建议是：先别追求完美，搞个能用的版本上线，然后根据真实用户反馈慢慢调。毕竟，用户问的问题永远比你想象的更刁钻。