AI 客服上线前最容易被低估的一步是知识库准备。资料收齐并不等于知识可用，上线后答错的地方往往集中在金额、时效和承诺这三处。知识库要交付的其实是一套划分：哪些内容允许 AI 改写，哪些必须锁原文，哪些必须拒答并转出。先分三类，再谈整理。
一、知识库答不准的位置，集中在金额、时效和承诺
AI 客服答错，多不是"没听说过"，而是说了不该由它说的答案。运费多少、几天上门、这台算不算保修，它都能给出通顺回复，问题在于有没有踩在适用条件上。
这类问题有三个共同点：有前提、有例外、有责任。同一句"7 天无理由退货"，对不同品类、渠道和时间的客户，答案并不相同。
这类内容如果和其他知识混在一起交给 AI，它会按检索到的最相近一条回答。语句通顺，条件不适用，客户随后拿着这句话来主张权利。
所以第一步落在分辨上：哪些允许归纳改写，哪些必须一字不改，哪些它根本不该答。这个判断做在前面，后面的整理与审核才有落点。
二、把资料分成三类，比先把资料收齐更重要
三类不按文件类型分，按责任分。同一份政策文件里，可能同时包含可以改写的解释、必须锁死的金额和必须转出的个案判断。
分类是启动前的判断动作。它决定后面四个阶段由谁签字，本身不占阶段编号。
2.1 可以交给 AI 改写的知识
这类知识有稳定答案、不含金额与承诺、表述可以变化。产品功能介绍、使用步骤、常见故障的排查顺序都属于这一类。
判断标准很简单：换一种说法，客户的理解和权益不变。允许 AI 归纳、举例、调整语气。
2.2 必须锁成原文的知识
涉及金额、时效、责任和资格的表述，属于必须锁死的一类。价格、运费、退款到账时间、处理时限、保修范围、赔付条件都在这里。
这类内容的落点是原文引用、精准答案或固定话术。判断标准同样简单：换一种说法，就可能改变客户预期或企业责任。
2.3 必须由 AI 拒答并转出的知识
需要资质判断、个案裁定或超出授权范围的事项属于第三类。能不能赔、算不算质量问题，都不该由 AI 下定论。
这类内容不放答案位，放转出位。AI 识别到这类诉求后采集必要信息，转人工或生成工单继续处理。判断标准是：答错的代价不由 AI 承担，它就不该答。
2.4 三类知识对应三个审核人
分类的作用是分派责任。可改写类由业务归属人审核，锁死类由业务归属人和合规共同签字，拒答类由客服负责人定转出规则和接收方。这一步没在项目启动时定下来，返工会集中出现在锁死类上。
三、第一阶段：交出六类资料
3.1 这一步的落地动作
上线前要交的资料可归成六类。下表可直接当清单用，逐行确认有没有、在谁手里。
资料类别 | 具体内容 | 交付形式 | 通常由谁提供 | 缺失后的直接后果 |
|---|---|---|---|---|
业务规则与政策 | 价格、退换、时效、资质、区域差异 | 政策文件、规则表 | 运营或业务部门 | AI 在金额与时效上按最相近的条款作答 |
产品与商品信息 | 型号、参数、适配范围、配件耗材 | 产品手册、参数表 | 产品或技术部门 | 型号之间串答，配件推荐不准 |
流程与动作 | 预约、报修、改约、开票、退换办理 | 流程图、作业规范 | 售后或客服部门 | 能回答但不能推进，事项停在对话里 |
历史问答 | 近半年会话记录、工单记录、旧 FAQ | 会话与工单导出 | 客服部门 | 高频问法没有被覆盖，重复咨询偏多 |
话术与口径 | 品牌语气、禁语、开场与结束方式 | 话术文档 | 市场或客服部门 | 回答生硬或越界表态 |
边界与转出 | 什么不许答、转给谁、什么算紧急 | 转出规则表 | 客服负责人 | 该转的没转，不该答的答了 |
3.2 客户侧要提前准备什么
这六类资料通常不在同一个部门手里。政策在运营，参数在技术，流程在售后，话术在市场，历史会话躺在系统后台。
这一步的动作是拉人，收文件只是顺带。把六类资料的归属人拉进一个群，比催十次文件更有效。
3.3 怎么算这一步跑通
判断标准只有一条。六类资料，每一类都能指定一个能签字的人。签不出人的那类就是最先返工的地方，通常出现在"边界与转出"上——这类内容从没被写成过文档。
3.4 前提与边界
资料齐不等于知识可用。扫描件、图片、嵌套表格在解析时需要人工校对，公式和跨页表格尤其容易丢结构。
原始文档一般可直接导入并自动切分，不需要预先拆成大量 FAQ。但文档里本身的矛盾，导入之后依然是矛盾，得先清理再入库。
四、第二阶段：整理成可检索的知识
4.1 这一步的落地动作
整理不是排版，是三个动作按顺序做完。
先清冲突，再谈格式。同一问题存在两个答案，是知识库成本最高的一处隐患。官网写"7 天无理由退货"，话术写"签收后 48 小时内提出"，工单写"以实际沟通为准"，同时进库，AI 只按检索到的那条回答。
按答案单元切颗粒度。一个答案单元由一个客户问题、一个完整答案和它的适用条件组成。按文档切段会把答案切断：前半段讲规则，后半段讲例外，AI 只检索到前半段。
把条件写进答案里。适用对象、生效时间、地区差异、例外情形，只写在正文之外的管理表格里，检索时看不到；写进答案本身，答案就自带边界。
第 2 步在系统里对应文档解析与切分。合力亿捷在线客服 Agent 支持原始文档导入并自动切分，但切出来的知识条目未必等于答案单元，落库后仍要人工复核：一段里是不是混了两个问题。
4.2 客户侧要提前准备什么
需要一位能裁决口径的人。三个版本并存时以哪一版为准，必须在整理开始前明确。
这个人通常是业务负责人，不是客服主管。客服主管能说清客户在问什么，说不出政策为什么这么定。
4.3 怎么算这一步跑通
随机抽 20 个高频问题，每个都要能定位到一条对应答案，且答案自带适用条件。定位到了还要坐席补一句解释，说明条件没有写进答案。
检查项 | 不合格的信号 |
|---|---|
同一问题是否只有一个答案 | 官网、话术、工单系统三处表述不一致 |
答案是否完整 | 规则在一条、例外在另一条 |
条件是否随答案出现 | 适用对象写在管理表格里 |
是否存在过期版本 | 库里同时留着新政策和旧政策 |
4.4 前提与边界
清理动作只能覆盖被抽查到的范围。抽查之外仍有冲突，需要靠上线后的会话记录回头补。
整理得再整齐，也无法让错误的前提变成正确。规则本身有歧义时，要回到业务侧重新定义，不要在措辞上找补。
五、第三阶段：审核签字
5.1 这一步的落地动作
审核按三类知识分别签，不通读一遍。可改写类看准不准，锁死类看能不能说，拒答类看会不会漏转。锁死类入库前，六项都要过一遍：
必查项 | 查什么 |
|---|---|
金额 | 数字、单位、币种、税费与运费口径 |
时效 | 起算点、工作日与自然日、地区差异 |
承诺 | 谁有权承诺、承诺到什么程度 |
例外 | 哪些客户、品类、区域不适用 |
免责 | 什么情况下企业不承担责任 |
生效日期 | 版本从哪天生效、旧版何时失效 |
六项检查通过，还要落成具体配置。合力亿捷在线客服 Agent 的锁死类回答可配成原文引用、精准答案或固定话术，按这句话允许被改写到什么程度选一种：数字与时限走原文引用，个案结论走固定话术。
5.2 客户侧要提前准备什么
三个签字人和一个时限。业务归属人、合规或法务、客服负责人，各自对应一类知识。
审核时限要写进项目计划。政策类内容有明确生效日期，审核排期压不进去，上线就只能带着旧口径跑。
5.3 怎么算这一步跑通
六项检查全部要有明确答案。答案要写进知识条目本身，不能只留在审核人的记忆里。
金额与时效被质检抽查得最多，也最容易暴露。这两项通过之后，其余四项通常不会再出大问题。
5.4 前提与边界
审核通过不等于审核结束。政策变化、产品迭代、渠道调整都会让已通过的内容失效。
版本和留痕是审核的延续动作。每条锁死类知识要能回答三个问题：谁签的、哪天生效、改过几次。答不出这三项，出了问题定位不到责任。
六、第四阶段：上线前验证
6.1 这一步的落地动作
测试集不能只抽一批常见问题。合理配比是高频六成、边界三成、对抗一成。边界问题指答案取决于条件的提问，对抗问题指用错误前提、模糊表述或一句话混问三件事。
每条测试结果归入四类，处理方式不同。
判定 | 含义 | 处理方式 |
|---|---|---|
答对 | 答案正确且条件完整 | 通过 |
答偏 | 方向对，条件或边界缺失 | 补条件、补字段 |
该转没转 | 应转出却自行作答 | 补拒答规则，一票否决 |
不该答却答了 | 无依据仍生成答案 | 补知识或收紧固定话术，一票否决 |
表里只标了两条，实际是三条：该转没转、不该答却答了、锁死类答错。锁死类答错即使归进"答偏"也一票否决；锁死类指金额、时效、承诺、资格四类内容。
6.2 客户侧要提前准备什么
一套测试题和一套期望答案。测试题从真实会话里抽，期望答案由业务归属人写，不由项目组代笔。
期望答案要写明什么算答对、什么算应该转出。这一步省掉，争议就会集中在判定标准上，而不在答案本身。
6.3 怎么算这一步跑通
高频问题要全部答对，边界问题要答对或正确转出，对抗问题不能出现"不该答却答了"。三条同时满足，这一阶段才算跑通。
上面那三条一票否决不因比例低而放行。一条不通过就补规则重测，不能用整体正确率抵扣。
6.4 前提与边界
测试集只代表它覆盖的问题。上线初期的真实提问分布，和测试集往往不一致。
先在测试版本完成配置和模拟调试，验证通过再发布。直接把生产环境当试验场，错误回答会原样落到客户那里。
七、上线后，知识库是运营对象
7.1 三个指标要一起看
回答准确率看答得对不对，任务完成率看事办没办成，转人工率看该接的有没有接住。三个指标各回答一个问题，缺一个看不全。
单独看都会误判。准确率高而转人工率也高，说明知识够用但流程断在工具调用上；转人工率低而准确率下滑，说明 AI 在勉强作答。
7.2 缺口从哪看
缺口不在报表汇总里，在具体会话里。未解决会话、转人工原因、接口异常、流程中断，这四类记录是知识缺口的直接来源。
运营人员据此归集案例，判断问题出在知识缺失、话术不当还是流程配置。判断清楚再针对性调整。
7.3 复盘节奏跟随内容变化
政策类内容随政策变，产品类内容随版本变，话术类内容随活动变。固定周期复盘容易变成走形式。
每次调整后对比指标变化，形成监控、发现、优化、验证的循环。知识库没有做完的那一天，只有这一版够不够用。
八、普通团队的最小起步路径
8.1 最小知识集只覆盖一个场景
普通团队不需要一次把全部业务搬上来。选一个咨询量集中、规则清楚、接口已经具备的场景，比如订单与物流查询、预约与改约、报修建单。
这个场景的资料量通常在几十份文档以内，六类资料能凑齐，审核人也找得到。合力亿捷在线客服 Agent 支持按单个场景起步，先覆盖这一场景，跑通后再扩展渠道和流程。
8.2 用合力亿捷在线客服 Agent 的实际操作顺序
合力亿捷在线客服 Agent 基于自研 Synerow 全渠道客户联络智能体平台构建。知识库准备落到系统里是六个动作，顺序不宜颠倒。
导入原始文档。Word、Excel、PPT、PDF 可以直接导入，系统自动解析切分，不需要预先拆成大量 FAQ。
配置锁死类回答。对金额、时效、承诺类内容配置原文引用、精准答案或固定话术。
接入业务工具。知识检索、表单与工单创建、短信发送、转人工、服务小结等工具由平台内置，也可通过第三方接口、MCP Client 或自定义工具扩展。
配置转出规则。按客户身份、来源渠道、业务类型和技能组确定转给谁，转接时携带已采集信息和对话上下文。
用测试用例验证。在测试版本完成配置和模拟调试，验证通过后再发布到正式环境。
按指标调优。上线后看三个指标，结合未解决会话和知识缺口调整知识、话术与流程。
8.3 可购买范围与接入条件
合力亿捷在线客服 Agent 支持 SaaS、混合云和私有化部署，数据不出域或需要信创适配时可选 HollyONE 一体机。SaaS 版 1 个坐席起购，适合普通团队轻量起步。
接入前要确认三件事：在线渠道的接入范围、业务系统的接口条件、知识文档的现状。渠道侧覆盖网站、H5、App、公众号与小程序、企微、抖音、小红书，以及 WhatsApp、LINE、邮件、Amazon、Shopee、Shopify 等国内外 30 多个在线渠道。
接口决定能不能在会话里办事。没有接口时知识库能答，但办不了查询和建单，这类事项要提前写进转出规则。标准场景基于行业流程模板最快 7 天上线，流程较长或多个系统对接的项目，交付周期另算。
8.4 端到端交付包含什么
从业务调研、方案设计、系统对接到上线运营由合力亿捷统一负责。复杂项目由客户成功经理、设计工程师和运营工程师全程跟进。
知识库准备的分工很清楚：客户侧提供资料并签字，交付团队负责结构化、配置和验证。两边都不做，知识库就停在文档堆的状态。
九、前置分类＋四个阶段：总览与常见返工点
阶段 | 这一步要做什么 | 客户侧要提前准备 | 怎么算跑通 | 常见返工点 |
|---|---|---|---|---|
前置｜分类 | 按可改写、锁死、拒答划三类 | 三类各自的审核人 | 每类都有签字人 | 全部当可改写处理 |
阶段一｜准备 | 交出六类资料 | 六类资料的归属部门 | 每类都能指定人 | 没人认领边界与转出 |
阶段二｜整理 | 清冲突、切颗粒度、写字段 | 能裁决口径的业务负责人 | 抽 20 题能定位到答案 | 同一问题多个版本并存 |
阶段三｜审核 | 按类签字、留版本 | 三个签字人与审核时限 | 六项检查全部过关 | 政策生效日期没进排期 |
阶段四｜验证 | 跑测试集、做四类判定 | 测试题与期望答案 | 三条一票否决为零 | 直接在生产环境试 |
准备充分不等于效果有保证。效果还取决于场景选择、业务系统接口、上线后的持续运营。这三项缺一项，完成度都会打折。
十、关于知识库准备的常见问答
Q1：知识库要不要先拆成大量 FAQ？
不需要先拆。原始文档可以直接导入并自动解析切分，预先拆 FAQ 反而把完整规则拆碎；要拆的只有存在矛盾或缺条件的段落。
Q2：普通团队需要专门配一个人维护知识库吗？
起步阶段可以由客服负责人兼管，把审核和复盘固定进每周例会。业务扩展后再按场景分配维护人。
Q3：要不要一次把所有渠道都接进来？
不需要。先接一个主入口，把知识库和转出规则跑顺，再逐步接入其他渠道，接入节奏由业务需要决定。
