本文目录7可以得到什么适合哪些情况需要准备什么常见做法真实案例与教程限制和检查点相关任务用历史客服对话搭建知识库客服系统 可以得到什么 一个可以先自动处理重复咨询的 AI 客服入口。 配套的意图路由、混合检索、上下文管理与低置信度人工池。 客服知识库与调用日志，便于持续迭代。 适合哪些情况 已有真实客服语料（半年以上历史对话、每天 2—3 小时人工客服规模以上）。 卖方/经营者亲自承担过客服，知道重复问题集中在哪。 希望把客服时间从"重复回答"释放到"处理异常问题"。 不适合从零起步、没有历史对话、且不愿先做真人客服的团队——来源直接表明历史对话是先决条件。 需要准备什么 半年以上真实客服对话积累（来源明确披露）。 产品说明、价格、数据安全和功能边界的明确文档。 一个用于去重和人工审核的知识库管理工具（来源使用飞书多维表格）。 主力与基准模型选择（来源使用 Qwen-plus、GPT-4.1、Qwen3-max 等多模型）。 一份"机器人可回答 / 必须转人工"的清单，包含退款、补偿、封禁、合同、付费权益、确定性功能承诺等高风险事项。 常见做法 先列出机器人可回答和必须转人工的事项，作为系统的安全边界。 从历史对话按批次提取问答对，人工去重、审核后进入知识库。 使用意图三分支路由：产品咨询 → 知识库检索；用户反馈 → 结构化记录；闲聊 → 独立提示词。 对"它、这个"等代词做上下文消解，再送入检索。 检索使用向量 + BM25 混合并精排；最近对话保留原文，较旧内容压缩成摘要。 记录问题改写、意图、召回材料、回答、耗时与模型成本。 把低置信度或无法回答的问题交给人工处理，再回灌知识库。 来源直接披露的失败点： 初版只分"产品咨询"和"闲聊"无法处理大量反馈，应直接采用三分支。 单纯向量检索会召回名称相近但实际不同的功能。 上下文过少丢信息，过多增加延迟、Token 与幻觉。 部分低代码平台（如 Dify）的链路和检索延迟在本项目规模下不适用，作者转自建——这一结论针对本项目规模和延迟要求，不可外推。 真实案例与教程 案例：空气小猪从创始人真人客服到 AI 客服数据飞轮 来源：SRC-BIZ-001：从0到1构建AI客服系统（空气小猪实践记录） 限制和检查点 来源自述"80% 以上自动处理"为作者自述，无独立测试集或人工抽检方法，不应被作为通用基准。 总开发工时、月 Token 账单、维护人时未披露。 历史对话是否匿名化、用户是否被告知用于训练/知识库，来源未说明——属于 PII 与合规风险（历史客服对话中的 PII 与隐私风险）。 退款、补偿、封禁、合同承诺、付费权益、重大投诉必须由有权限的人处理（AI 客服自动裁决退款、补偿、封禁、合同承诺与付费权益的风险）。 低置信度回答必须保留清晰的人工入口（整理者建议）。 相关任务 从历史客服对话中提取 FAQ 与问答对 把低置信度问题转人工审核并回灌知识库