用 AI 整理客服知识库：答案要有依据，也要知道何时转人工 - AIPlan

客服知识库最危险的不是答错，是答对过一次就当成规则。一条"这个可以退"的回复，没写清依据哪条政策、从哪天起生效，三个月后就成了全店的隐性承诺。用 ChatGPT 整理，第一步不是写答案，是给每条答案补 3 个字段：依据来源、生效日期、转人工条件。 按这个结构整理的 100 条问答，事后能追溯的接近全部；只整理成"问—答"两列的，通常有 20% 到 30% 在半年内失效且没人发现。 每条答案必须带 3 个字段 把原始话术丢给模型之前，先让它按这 4 列重排： 字段 写什么 反例 用户问法 客户原话，保留错别字和口语 "退款政策咨询" 标准答案 3 句以内，第一句给结论 分 5 段讲历史沿革 依据 政策文件名 + 条款号，或商品页原文 "公司规定" 转人工条件 具体到可判断的情形 "复杂问题转人工" 第 3 列最容易被忽略。写"公司规定"等于没写，因为下一个人无法核对。可用的写法是"《售后规则 v3》第 4.2 条"或"商品页'兑换说明'第 2 段"。模型不能替你编条款号，所以这一步要人先提供文件名，再让模型把答案挂上去。 第 4 列要能被执行。"复杂问题"没人能判断，"订单金额超过 500 元且客户要求退款"就能判断。 一个可以直接用的提示词： 下面是我给你的 20 条客服对话记录。请输出一张表，列为：用户问法（保留客户原话）、标准答案（3 句内）、依据（我提供的政策文件名，不得编造）、转人工条件（可判断的具体情形）。如果某条对话里找不到依据，依据列写"缺失"，不要猜。 "依据列写缺失"这一句是整套流程的关键。它把模型的编造空间压到零，同时给你一张待补清单。 按用户问法归类，不按产品结构归类 技术团队习惯按模块分类：账户、支付、交付、售后。客户不这么问。他们问的是"我付了钱没收到东西怎么办"——这一句同时落在支付和交付两个模块里。 整理时用客户的第一句话做归类依据。可以让模型做一步聚类： 这 200 条咨询按客户的第一句话分成不超过 8 组，每组给一个 6 字以内的组名，组名要用客户的说法，不要用内部术语。列出每组条数和 2 条代表性原话。 分完会发现，通常有 1 组占总量 30% 以上。把这组先做透，比平均用力有效。剩下 7 组里往往有 2 到 3 组每月不到 5 条，可以只保留 1 句通用回复。 组名尽量用动词开头："没收到"、"想退款"、"登不上"、"要发票"。这类名字在搜索框里能被直接命中，客服新人找起来不需要背目录。 用 Projects 把知识库和日常对话分开 知识库材料会越来越长，混在普通对话里，每次都要重新上传。ChatGPT 的 Projects 可以把一组文件和一个对话空间绑在一起，适合放"政策文件 + 历史话术 + 术语表"。 操作路径：左侧栏新建项目 → 上传文件 → 在该项目里开新对话。Project 里的对话默认继承这些文件，不必每轮重新贴。 要提醒一点：项目不是版本控制系统。你更新了政策文件，旧对话里模型引用的仍是旧版本。每次政策变更后，把旧文件删掉再传新文件，并在文件名里带上版本号和日期，例如 售后规则_v3_20261015.pdf。 如果团队多人共用，把"当前有效版本"写进项目说明的第一行，比放在某个文档的第 8 页有效得多。 让模型找出自相矛盾的两条 知识库规模过 50 条之后，矛盾几乎必然出现。人眼很难发现，模型可以： 以下是 80 条问答。请找出互相矛盾的两条，格式为"第 X 条说……，第 Y 条说……，冲突点在于……"。只列真有冲突的，最多 10 组。不要评价哪条更好。 80 条里通常能找出 3 到 8 组真冲突。常见的有两类：退款时限一处写 7 天一处写 15 天；发票开具条件一处写"任意金额"一处写"满 100 元"。 这一步不要一次喂 500 条。分组做，每组 60 到 80 条，模型能逐条读完；一次给太多，它容易只读开头和结尾。分组时可以按上面聚出来的 8 个组来切。 对比两份文档的差异也可以用同一思路，两份文档逐条对比的提示词写法里有更细的模板。 转人工的 5 个触发条件 写不出转人工规则的团队，通常会把"要不要转"交给客服个人判断，结果同样的问题有人转有人不转。可以先用这 5 条兜底： • 客户提到"投诉""曝光""12315""律师" • 涉及金额超过 500 元且要求退款 • 客户已经联系过 2 次以上，同一个问题未解决 • 客户提供了账号、订单号，但系统里查不到 • 客户要求书面承诺或盖章文件 这 5 条写进知识库首页，每条配一句给客户的过渡话术。例如第 3 条："我看您之前联系过两次，这次我直接帮您转到专人，避免再重复描述一遍。" 转人工不等于结束。交接时要把"已确认的事实"和"还没确认的"分开写。让模型生成交接摘要时用这个结构： 请把这段对话压成 5 行：客户要什么、已经确认的事实（含订单号、日期）、客户已尝试过的动作、还没确认的点、建议下一步。不要写客户情绪描述。 第 5 行是给人看的，前 4 行是给接手人核对用的。加上"不要写客户情绪描述"，摘要会短一半。 上线前抽检 20 条 整理完不要整批上线。抽 20 条，按这 4 项打分： 检查项 通过标准 第一句是否给结论 读第一句就知道能不能办 依据是否能核到原文 能在文件里找到对应条款 有没有超出政策的承诺 不出现"一定""保证""全部" 转人工条件是否可判断 换成新人也能照着判断 4 项全过的算可用。20 条里通过少于 15 条，说明原始话术本身缺依据，先补政策文档，别继续改措辞。 抽检还有个副作用值得留意：你会发现自己团队对同一条政策的理解并不一致。这个发现比知识库本身更有价值。 维护节奏：30 天一次，只改 3 类 知识库不是写完就结束的文档。一个能维持的节奏是每 30 天过一遍，只动 3 类内容： • 这 30 天里客户问过但库里没有的问题（新增） • 因为政策变更而失效的答案（替换，并在依据列更新日期） • 抽检里发现的自相矛盾（合并成一条） 其余不动。每次改动在文件头部留一行记录：2026-10-18 更新第 12、27、41 条，依据《售后规则 v3》。这一行让下一个人知道从哪看起。 如果每月新增超过 30 条，说明产品在快速变化，这时候更该做的是把答案里的具体数字改成引用，例如把"7 天内可退"改成"按《售后规则 v3》第 4.2 条"，条款改一次，所有答案同步生效。 什么材料不该进知识库 三类内容不适合交给模型整理：客户身份证号、银行卡号等个人信息的原始记录；涉及具体个人的投诉处理过程；还没定稿、可能变化的价格方案。 第一类在上传前就要脱敏，把手机号替换成 138****0000 这种形式。第二类只保留结论，不保留人名。第三类等定稿再进。 如果知识库要处理大量历史对话，翻查和整理会消耗不少额度。ChatGPT 的剩余额度在 设置 → 用量 看，Plus 和 Pro 同时受 5 小时窗口与周窗口限制（截至 2026 年 10 月 18 日核对）。一个月只整理一次、每次几十条对话，免费版够用；每周都要重跑聚类和矛盾检查，就按包月来算：¥115.50 一个月，比按次购买 API 更好预估成本，兑换后到 ChatGPT 设置 → 账户 能看到套餐名称——Plus 月卡购买页写了完整的账号条件。 一条边界 知识库能回答的是"规则允许什么"，不能回答"这次要不要破例"。破例的判断必须由人做，而且做完之后要决定：这是一次性处理，还是规则该改了。 判断方法很简单：同类情形 30 天内出现 3 次以上，就该改规则，而不是继续在对话里一次次破例。把这个数字写进知识库首页，比写"灵活处理"有用。 参考资料资料核对日期：2026-10-17 • Text generation • Projects in ChatGPT | OpenAI Help Center 延伸阅读• 用 AI 写商品说明：先做事实表，再谈卖点 • 联系客服时发什么？一份能帮助定位的充值问题模板 • 用 ChatGPT 比较两版文档：重点找规则变化，不只找改了哪些字