网站加了 AI 客服，不代表它自然就懂公司的服务。答错价格、把旧政策当新政策、遇到特殊情况仍然编答案，往往和知识来源、检索结果及答复规则有关。要让客服可用，先把“能依据什么回答、资料由谁维护、什么时候必须转人工”设计清楚，再选具体模型或平台。
一、先界定 AI 客服负责的范围
第一期建议从重复、答案稳定、风险较低的问题开始，例如服务范围、营业时间、预约流程、资料准备、常见故障和联系渠道。需要判断具体报价、承诺交付日期、退款争议、身份核验、账户修改或处理个人订单的请求，通常应转交人工或业务系统，不要仅凭一段知识库文字自动作出承诺。
把对话拆成三类：可以直接回答的事实问题；需要补问条件后再回答的问题；必须转人工的交易、投诉、隐私或高风险问题。这个清单决定后续资料该公开哪些、客服应该怎样拒答，也能控制第一期开发范围。
二、盘点“谁有权确认”的一手资料
先找业务负责人收集官网服务页、正式报价说明、服务地区、工作时间、办理流程、售后政策和常见问答。每份资料都登记负责人、适用业务、发布日期、最后核对日期、有效期限和来源链接。没有负责人确认的内部聊天截屏、旧报价单和未签字的草稿，不要直接放进对客知识库。
尤其要处理相互冲突的资料：官网说 5 个工作日，销售表格写 7 天；旧价目表与新报价不一致；一个地区可以上门，另一个地区不支持。由业务方指定唯一的当前版本，并决定旧文档是删除、归档还是加上“已过期”标记。不能让检索系统自己猜哪一份优先。
三、把文件改成容易检索、容易维护的内容
扫描版 PDF、没有标题的表格、图片里的小字和多主题长文档会增加检索难度。把高频规则整理成主题明确的页面或问答条目，一条记录解决一个问题，并补全适用对象、前置条件、例外和更新时间。示例：
问题：哪些区域提供上门服务？
答复：目前为［经负责人确认的地区清单］。区域外暂不承诺上门，可登记所在城市后由客服确认。
适用业务：［服务名称］；负责人：［岗位/姓名］；生效日期：［日期］；来源：［正式页面或文件链接］。
不要为了“喂给 AI”把每份文件切成一样大小的小块。优先保持问题、条件和答案在同一个语义单元里；长表格按业务分类拆开，并在每一部分重复保留必要的产品或地区背景。修改资料后记录版本，测试旧内容是否已经下线或被新版本覆盖。
可以给每条内容加上这些管理字段：主题、产品/服务、适用地区、适用客户、版本、生效日期、到期/复核日期、负责人、状态和来源链接。客服只检索“已审核且当前生效”的条目；改价或改政策时先停用旧条目，再发布新版本，避免两份规则同时进入答案。
一份知识条目的发布标准可以是：问题说法明确；答案包含适用条件和例外；关键数字能回到正式来源；负责人确认有效期；没有混入客户隐私或内部谈判信息。无法满足这些条件的内容先放待审核区，不直接进入对客索引。
四、把“资料检索”和“组织答案”分开验收
知识库客服通常会先从受控资料中检索相关片段，再把问题和片段交给模型组织答案。这意味着失败可能发生在两个位置：检索到的资料不相关或过期；检索正确，但模型漏掉条件、擅自补充或表达得不清楚。OpenAI 的 File Search 文档介绍了用文件检索为模型提供资料的工具方式；Microsoft 的 RAG 评估文档则分别检查检索质量、答案是否依据上下文、相关性和完整性。OpenAI：File Search Microsoft：RAG 评估指标
验收时保存用户问题、检索到的资料片段、最终回答和引用来源。若检索错了，先改知识结构、标签或检索设置；若资料正确但答案走样，再调整答复规则、提示词或输出格式。不要只凭演示时问的两三个问题判断效果。
对客答复规则可以写成明确的产品要求，而不是只写“回答自然一点”：只使用本次检索到的有效资料；回答价格、地区、期限时保留来源中的条件；找不到依据时明确说暂时无法确认并转人工；不要声称已经预约、退款或修改账户，除非对应业务系统确实完成了操作。涉及多个服务或地区时先追问必要条件。
回答前先判断资料是否适用于用户的问题。只根据已审核、当前生效的知识回答，并在可行时附上对应页面或资料名称。没有找到依据、资料互相矛盾、用户问到个案报价或要求执行账户操作时，不猜测、不承诺，说明需要人工确认并提供转接方式。
五、建立一组包含“难题”的测试问法
从真实咨询中挑选代表性问题，给每题标注标准答案要点、允许引用的来源、是否需要追问和是否应转人工。至少覆盖：
- 资料里明确写了答案的问题，检查事实、数字和条件是否准确。
- 用户换一种说法、带错别字或一次问多个问题，检查能否找到相关资料并完整回答。
- 资料没有答案、不同资料冲突、价格已过期或地区不适用的情况，检查是否承认不确定并转人工。
- 用户要求客服忽略规则、透露内部资料、泄露他人信息或保证未经确认的结果，检查是否拒绝。
- 请求投诉、退款、改订单、提供定制报价等业务动作，检查是否进入规定的人工或系统流程，而非只生成一句“已处理”。
逐题记录检索命中、依据是否正确、是否遗漏关键限制、引用是否可打开、拒答/转接是否符合预期。重点看“错误答案率”和“无依据回答”，不要只看平均回复速度或自动解决率。
例如，测试“你们周日能上门吗？”时，检查系统先检索了对应地区和服务的营业资料；如果知识只覆盖工作日，就应说明资料未确认并转人工，不能因为另一个地区周末营业而给出肯定答复。再测试“我上次报过价，按那个价格下单”这类个案，客服应查询有权限的业务记录或转人工，而不能把公开价目表当成用户的历史报价。
第一轮不必追求复杂评分平台，可用表格管理：问题、适用场景、正确来源、必须覆盖的信息、允许省略的信息、预期动作（回答/追问/转人工）、实际结果、修复责任人。每次修改知识或提示规则后重跑受影响的问题，避免修好了一个案例、却让旧案例变差。
六、公开知识、内部资料和客户对话要分区
对客客服知识库只放可以公开给访客的资料。内部价格底线、员工备注、尚未发布的新产品、客户合同和历史对话应单独管理，按实际业务需要设置权限。不要把整份客户聊天记录直接上传到外部 AI 服务；先确认用途、授权、数据保留和服务条款，能用脱敏后的常见问题就不要带入姓名、电话、订单号等不必要信息。
如果系统会读取不同客户或不同账号的私有内容，必须在检索之前按权限过滤，不能仅依赖模型“不要泄露”的提示。记录日志时也要限制敏感字段；定义谁能新增、审核、发布和删除知识，确保过期资料可以撤回。
七、先小范围上线，再根据证据迭代
- 先选一个服务类别和一组常见问题，指定知识负责人和人工接待渠道。
- 用测试集验证检索、答复、引用、拒答和转接；修正后复测并保存结果。
- 试运行期间保留“转人工”入口，并告知访客 AI 回复的适用范围。
- 每周抽查真实问题，标记无答案、误召回、答案过期和不该自动回答的场景。
- 业务规则变化时更新原始资料和版本，重新跑相关测试后再发布。
指定一个业务资料负责人、一个技术维护人和一个人工接待负责人。前者审核答案事实，技术人员检查检索和权限，接待人员反馈新问题。按固定周期检查过期知识，并在价格、服务地区、营业安排等变化时立即触发复核；没有人负责更新的知识库，迟早会重新变成旧资料堆。
一个能持续维护的 AI 客服，核心不是资料上传得越多越好，而是来源可信、权限清楚、答案有依据、未知时能停下来。先把小范围的一问一答做稳，再决定是否接入订单、预约、报价等需要读写业务数据的功能。