先确定客服负责什么、什么时候转人工
把最近常见的问题整理成三类：可以从公开资料回答的问题，需要登录后查询的问题，以及必须由人员处理的问题。产品使用说明适合知识库问答；订单状态需要已授权的业务接口；投诉、特殊报价和没有依据的问题应进入人工队列。
不要把“模型能生成文字”作为上线标准。客服真正需要的是正确识别问题、找到有效资料，在能力范围外仍能让用户继续获得帮助。
网站、Telegram、WhatsApp入口有什么不同？
| 入口 | 接入前需要确认 |
|---|---|
| 网站聊天窗口 | 前端能否嵌入组件、用户登录态、手机键盘、消息发送失败与人工入口 |
| Telegram | 机器人归属、私聊或群场景、事件接收、群权限、消息身份与业务用户如何对应 |
| 是否具备当前适用的官方接入条件、业务账号和消息权限，先核实再决定是否纳入项目 | |
| 已有在线客服系统 | 是否提供消息接口、工单接口、人工坐席状态和会话接管能力 |
渠道评估不等于承诺所有平台都能直接开通。跨渠道用户身份不能只凭同名合并；初期分别管理会话，确需关联时再设计用户确认和账号绑定。
一套可维护的客服架构
聊天入口
↓
接入层：验证身份、限流、识别渠道与会话
↓
对话服务：问题分类、上下文、转人工状态
↓
知识检索 / 已授权的业务查询 → 模型组织答案
↓
输出检查 → 返回答案与资料来源
↘ 缺少依据、接口异常或用户要求 → 人工队列
全过程：记录必要的状态、耗时、用量与问题反馈这是一种建议架构，可根据规模简化。单一网站 FAQ 通常不需要一开始就建设多渠道工作台；已有客服系统时，也可以优先接入现有人工流程。
知识库不是把所有文件一次性发给模型
- 整理来源：产品说明、有效政策、操作文档与常见问题，标明负责人和更新时间。
- 处理内容：清理重复与冲突，把长文拆成保持语义完整的片段，保留标题和出处。
- 设定权限：区分公开资料、客户专属资料和内部文档，在检索前限制访问范围。
- 检索与回答：先找相关片段，再要求模型根据证据回答；没有合适依据时转人工。
- 维护版本：资料失效后同步撤下或替换索引，避免旧政策继续参与回答。
语义检索可以找到措辞不同但含义接近的内容，这是 RAG 常用的组成部分；检索结果不等于答案一定正确，仍需校验来源、权限和实际问答。原理可参考 OpenAI Retrieval 文档。
上下文与人工接管应作为状态管理
会话应绑定经过验证的用户与渠道，只保留完成任务所需的信息，并设置过期和清理规则。不要让客户端提交任意会话 ID 后就读取历史消息。多轮上下文需要应用或 API 会话机制显式管理，可参考 OpenAI 会话状态说明。
人工接管至少区分“AI处理中、等待人工、人工处理中、已结束”。用户请求人工后，应明确显示当前状态，并阻止 AI 在坐席接管后继续抢答。没有在线坐席时提供可执行的留言方式，不能只显示“已转人工”却没有承接人员。
上线前用这些问题验收
| 测试场景 | 应观察的结果 |
|---|---|
| 资料中明确有答案 | 回答与有效文档一致，可回到资料来源 |
| 没有资料或资料互相冲突 | 说明不确定性，收集必要信息并转人工 |
| 询问另一位用户的数据 | 权限校验拒绝访问，不依赖提示词独自保护数据 |
| 模型超时或额度不足 | 展示可理解的错误与人工入口，记录可追踪的故障编号 |
| 用户要求人工后继续发消息 | 消息进入同一人工队列，AI 不再自动答复 |
| 诱导忽略规则或输出内部资料 | 不扩大数据权限，不执行未授权动作 |
测试问题使用经允许和脱敏的数据。分别记录答案是否正确、依据是否有效、转人工是否成功与响应耗时；不要只看“机器人回答了多少条”。
开发成本和长期成本怎样估算？
开发工作主要来自入口数量、知识整理、身份系统、业务接口、人工工作台和测试范围。运行费用包括模型调用、检索或存储、服务器及渠道实际产生的费用。先估算日会话量与平均轮次，再用试运行的实际用量修正，避免把一次演示的费用当作长期预算。
AI客服常见问题
接入模型后可以马上回答公司业务吗？
不能默认如此。需要提供经过整理的有效资料，并核对答案来源；实时状态还需要业务接口。模型没有依据时应说明限制或转人工。
AI能完全替代人工客服吗？
不应把完全替代作为默认目标。可先覆盖高频、规则明确的问题，把异常、投诉和重要业务决定交给人员处理，再依据试运行数据调整范围。
聊天记录应该全部保留吗？
按业务目的确定必要字段和保留期限，限制查看权限，并安排清理。模型服务、数据库与客服平台的数据设置应分别核实，不能假设关闭一个开关就会删除所有副本。
什么时候需要专业接入？
当客服涉及登录用户、内部文档、订单查询或现有坐席系统时，需要同时处理权限和流程。可以从 AI客服系统开发的单一场景开始，先约定输入、答案依据、转人工方式和验收标准。