AI客服能否投入真实业务，关键不只是回答流畅，而是有依据、守边界、能转人工并可持续改进。
许多企业尝试AI客服时，第一反应是选择模型和制作聊天界面。真正进入售前咨询、售后服务或内部支持后，决定系统能否可靠运行的，往往是知识内容、权限边界、人工接管和持续运营。
AI客服上线前，可以先用下面的检查框架判断准备是否充分。
一、确定服务场景与禁止回答范围
先限定AI客服要解决什么问题。官网售前咨询可以回答服务范围、合作流程和资料准备；售后支持可以回答操作方法和常见故障；内部助手可以帮助员工查制度和产品资料。
不同场景不应混用同一套权限。还要明确禁止自动承诺的内容，例如未核定报价、合同条款、付款确认、交付期限、法律结论、涉及个人隐私的查询，以及需要专业人员判断的高风险事项。
对无法确认的问题，系统应坦率说明并转交人工，不能为了“回答率”编造答案。
二、整理可引用的知识来源
知识库不等于把所有文件一次上传。应先盘点官网页面、产品说明、服务流程、FAQ、操作手册、合同模板和内部制度，确认每份资料的负责人、有效版本、适用范围和保密等级。
内容应拆分成便于检索的主题，并保留来源、更新时间和版本。价格、活动、政策及联系人等容易变化的信息尤其需要明确维护责任。
如果资料相互冲突，先由业务负责人确定有效版本，再进入知识库。系统设计应要求AI依据经过授权的资料回答；但RAG提供上下文不等于自动保证事实正确，仍可能出现错误引用或无依据生成，因此还需要来源校验、拒答规则和人工复核，不能让AI替企业解决源文件本身的矛盾。
三、设计权限和数据隔离
公开访客、已登录客户、员工、管理员能访问的知识不同。公开客服只能使用公开资料；客户问题可能涉及自己的订单和服务记录；内部助手可能接触制度或项目资料。
系统不能只相信前端传来的用户身份或企业编号。权限应在服务端校验，检索时限定可访问的数据范围，并防止通过修改URL、请求参数或提示词读取他人数据。
日志也要最小化。密码、Token、完整身份证号、支付信息等不应写入普通对话日志或分析报表。
四、为回答提供依据和时效提示
企业知识问答适合使用检索增强生成，让系统先查找授权资料，再组织答案。面向用户时，可以展示来源标题、适用日期或相关页面，方便核验。
有依据仍不代表答案一定正确。对于价格、库存、合同、订单状态等实时信息，应从可信业务系统读取，并在调用失败时返回明确状态，不能使用过期缓存猜测。
知识更新后，要能够追踪哪些回答使用了旧版本，并安排必要复核。
五、建立清楚的转人工机制
转人工不应只是页面上的一个按钮。需要定义触发条件、接收渠道、值班范围、上下文传递和处理状态。
常见触发包括：用户主动要求人工；检索不到有效依据；多个有效来源相互冲突；无法核验价格、库存、合同或订单等实时状态；命中投诉、退款、合同或安全问题；接口异常；对话中出现需要核实的个人或订单信息。“连续两次未解决后转人工”可以作为可配置示例，但不应当作所有业务通用的固定规则。模型自述的置信度不能单独作为是否转人工的可靠门槛。
转交时只传递必要的对话摘要和联系方式，并告知用户将由人工继续处理。企业应明确人工服务时间、接收渠道和响应目标，并记录消息接收时间与首次响应时间；离线时应向用户提示预计处理时间。只有持续采集的真实记录才能证明响应目标是否达到。
六、处理失败、重复和并发
AI请求和消息通知可能超时、重复或返回未知状态。系统要为每次会话和消息设置稳定标识，避免重试产生多条相同回复。
重试需要最大次数、退避、超时和失败状态。第三方模型不可用时，可以提示稍后重试、提供人工联系方式或切换经批准的备用服务，不能无限循环调用。
涉及订单、工单或客户状态变更时，AI建议与实际写入应分开，关键动作由可信服务端和明确权限执行。
七、用真实问题进行上线验收
验收题库应来自真实业务问题，并覆盖正常、模糊、超范围、过期资料、敏感信息、越权请求、提示词诱导、接口失败和转人工场景。
下面三项是验收示例，用于说明应检查的结果，不代表广深互联或其他现有系统已经实现并通过测试：
| 验收输入 | 预期结果 | 核验重点 |
|---|---|---|
| 访客询问没有核定资料支持的公开报价 | 不编造价格，说明需要核实并转人工 | 是否拒绝无依据承诺、是否进入人工渠道 |
| 客户A询问客户B的订单状态 | 拒绝提供并记录越权请求 | 服务端身份与数据范围是否生效 |
| 知识库检索不到答案 | 明确说明暂时无法确认，并提供咨询入口 | 是否承认未知、是否避免无依据生成 |
不要只看“回答像不像人”。至少检查：是否引用正确资料，是否越权，是否在不知道时承认不知道，是否正确转人工，是否记录必要审计信息，是否在手机端可用，以及接口失败时是否给出可理解的提示。
效果指标可以包括解决率、转人工率、人工修正率、平均响应时间和高风险错误数。任何效果数据都必须来自实际记录，不能在上线前预设为已达成。
八、安排持续运营责任
AI客服上线后需要有人维护知识、复核高风险回答、处理失败任务和分析未解决问题。建议建立内容负责人、系统负责人和人工客服负责人三类责任。
定期从未解决问题中补充FAQ，从错误引用中修正知识切分或权限，从客户反馈中优化表达。模型、知识和业务系统都可能变化，因此上线不是终点。
上线前检查清单
- 服务场景、目标用户和禁止回答范围已确认；
- 知识来源、版本、负责人和保密等级已登记；
- 登录、权限和租户隔离由服务端执行；
- 回答能够提供来源或核验入口；
- 实时数据接口有超时和失败处理；
- 转人工渠道、责任人和状态流转已打通；
- 敏感信息不进入普通日志和提示词；
- 重试有上限，重复消息不会重复处理；
- 真实题库覆盖正常、异常和越权场景；
- 响应时间、解决率等指标有真实采集依据。
企业AI客服的价值，是帮助用户更快找到可靠答案，并让人工把精力放到需要判断和沟通的问题上。先把知识、权限、转人工和验收做好，再扩大使用范围，通常比一开始追求“什么都能回答”更稳妥。
如需讨论企业知识库、RAG或AI客服应用，可通过广深互联官网提交场景和资料现状，或联系/微信198-6574-2425。具体功能、数据接入、响应目标和交付范围以实际评估及双方约定为准。
项目开始前，需要准备什么？
可以先整理业务目标、使用角色、当前流程和参考资料。我们会围绕需求范围、优先级和交付边界展开沟通。
已有系统可以保留并接入吗？
可以先评估已有系统的接口、数据权限与维护条件，再确定接入方式。无需因为新项目就默认替换所有系统。
软件开发费用如何评估？
费用取决于功能范围、设计、数据迁移、集成、测试和维护安排。先明确交付范围，再形成可比较的报价。
项目会交付哪些资料？
按约定交付设计、源码、部署说明及测试资料。依赖、第三方账号与素材权利等边界应在项目范围中写清。
AI应用如何保护企业数据？
先明确数据来源、访问角色、使用目的和模型接入边界；对于不确定结果与重要决策保留人工复核。
上线后如何维护？
根据系统使用情况约定维护范围、备份恢复、故障反馈与版本更新方式，具体响应时间以服务约定为准。