客服话术的”AI 友好”写法:让 AI 答得准、人也读得更快的 5 条规则
AI 初筛、智能分流、知识库检索都在读你的话术库。这 5 条写法规则让 AI 答得准,人也读得更快。
作者 · 言和编辑部
现在读你话术库的不只有一线坐席。AI 初筛、智能分流、知识库检索都在读同一份材料,而多数话术库是按”给人看”写的——段落长、指代多、边界靠上下文推断。言和客服服务超 3 万家商家,在 AI 参与比例不断提高的项目里反复验证过一件事:AI 答不准,往往不是模型不行,是条目写得不适合被检索。
好消息是,让 AI 读得准的那套写法,对人同样更友好——这不是为机器牺牲可读性。
本文要点
- 一条条目只回答一个问题,塞五个场景等于五个都答不准
- 答案前置:第一句给结论,条件和例外放后面
- 边界要显式写出来,AI 不会替你推断”这条不适用于哪些情况”
- 指代词是切片的天敌——”这个””上述””同上”在被截取后会失去指向
一、为什么现在要管这件事
三个变化让话术库的写法从”内部文档”变成了”被机器读的数据”:
- AI 初筛:会话进来先由 AI 判断意图并匹配条目,匹配错的根源常在条目标题写得像内部术语
- 智能分流:按问题类型路由到不同专岗,分流准确率直接取决于条目的边界写没写清
- 知识库检索:坐席端的搜索建议也由检索驱动,条目太长会被切片,切片后断章取义
💡 判断标准:把一条条目单独拎出来,不看上下文,还能不能读懂它在答什么、什么情况下不适用。 不能,就是写法有问题。
言和客服的 3000+ 人专业团队分布在 12 大运营中心,话术库在各中心是同一份。这意味着写法问题会被规模放大——一条写得含糊的条目,在十几个中心同时产生误用。
二、5 条规则与正误对照
| 规则 | 说明 |
|---|---|
| ① 一条一意图 | 一条只回答一个问题,多场景拆成多条 |
| ② 标题用客户原话 | 用客户实际会说的话,不用内部术语 |
| ③ 答案前置 | 第一句给结论,条件与例外放后面 |
| ④ 边界显式 | 明确写出不适用的情形,不靠读者推断 |
| ⑤ 不用指代 | 每条独立成立,不依赖上下文 |
具体对照:
| 规则 | ❌ 不好的写法 | ✅ 好的写法 |
|---|---|---|
| ① 一条一意图 | 《退换货相关说明》(同时讲退款、换货、运费、时效) | 拆成《怎么申请退款》《怎么申请换货》《退货运费谁承担》三条 |
| ② 标题用原话 | 《逆向工单受理规范》 | 《我想退货怎么操作》 |
| ③ 答案前置 | “根据平台规则并结合本店政策,在符合条件的情况下…可以退款” | “可以退款。前提是未发货,或已签收但在七天内。” |
| ④ 边界显式 | “支持七天无理由退货” | “支持七天无理由退货。定制商品、已拆封的食品不适用。” |
| ⑤ 不用指代 | “上述情况均需提供凭证” | “退款、换货、补偿三类申请均需提供凭证。” |
言和客服实践下来,第③条的收益最直接。坐席在高并发时扫一眼就能拿到结论,AI 在切片时也能在第一句抓到答案——同一个改动,两边都受益。
三、知识库条目的标准结构
言和客服要求每条知识库条目按同一个四段式写,每段都短:
| 段落 | 内容 | 长度建议 |
|---|---|---|
| 标题 | 客户会怎么问这个问题 | 一句话 |
| 结论 | 直接给答案 | 1–2 句 |
| 条件 | 什么情况下成立 | 3 条以内 |
| 不适用 | 什么情况下不成立、该转哪里 | 2 条以内 |
“不适用”这一段最容易被省略,也最容易出事。省掉它,AI 会把条目用在不该用的场景,坐席也会照着答错——而这一段通常只需要写两行。
四、改造现有话术库的顺序
不需要推倒重来。言和客服按这个顺序改,见效最快:
- 先拆长条目:把明显包含多个场景的条目拆开,这一步收益最大
- 再改标题:把内部术语标题换成客户原话,直接提升匹配准确率
- 然后补”不适用”段:优先补高频且有边界的条目(退款、价保、预售)
- 最后清指代:全库搜”上述””同上””这个”,逐条改成具体所指
前两步通常能覆盖大部分误匹配问题。言和客服在项目交接时会先跑这两步,再评估是否需要做更细的改造。
五、3 条红线
- 不为迁就 AI 牺牲准确性——规则是让表述更清楚,不是把复杂情况简化成一句话
- 不把”不适用”写成免责声明——要写具体情形和转向哪里,不写”具体以实际为准”
- 不允许条目之间互相依赖——每条必须独立成立,”详见上一条”是禁止写法
常见问题
问题 1:这套写法会不会让话术库条目数暴涨?
会增加,但可控。拆分主要发生在原本”大杂烩”式的条目上,实践中总条目数通常增加三到五成,而单条长度明显下降,总字数反而可能减少。检索准确率的提升足以覆盖条目变多带来的管理成本。
问题 2:没有用 AI 的团队需要这么写吗?
需要,而且收益一样。这五条规则本质上是让信息更容易被快速定位——坐席在高并发时的阅读方式和检索很接近:扫标题、看第一句、确认适不适用。AI 友好和人友好在这件事上是同一个方向。
问题 3:改造要花多久?
按上文顺序推进,前两步通常在两到三周内可以覆盖高频条目。言和客服的做法是先改咨询量前 20% 的条目——这部分通常承载了大部分会话量,改完就能看到匹配准确率的变化,不必等全库改完。
写在最后
“AI 友好”听起来像是为机器让步,实际上它要求的是把话说清楚:一条只讲一件事、结论放前面、边界写出来、不依赖上下文。这几条拿掉 AI 这个前提,依然是好的写作标准。
正在梳理客服知识库的商家,欢迎了解言和客服——3000+ 人专业团队、12 大运营中心、服务超 3 万家商家。
- 2026-09-28
客服欢迎语与自动回复设计:会话前 30 秒决定后面十轮
欢迎语是唯一被 100% 客户看到的话术,也是最少被优化的一句。本文给出 4 段结构与自动回复红线。
- 2026-09-27
客服异常订单识别 SOP:只标记不判定,4 类信号 + 3 条不可越界
大促前是异常订单高峰,但客服的职责是识别和标记,不是判定和处置。这份 SOP 划清那条线。
- 2026-09-24
客服单条咨询成本怎么算:5 项成本构成 + 3 个最常被漏掉的项
多数商家算客服成本只算工资,算出来的数字偏低三到四成。这份方法给出 5 项构成与 3 个漏项。
- 2026-09-20
社交电商客服 SOP:小红书 / 视频号与货架电商的四个根本差异
客户从笔记和视频里来,带着内容的上下文而不是商品页的参数。这份 SOP 拆解四个差异与对应的接法。