「好听」在 AI 客服里应当作为一组可检查的约束，而不只是形容词：称呼用哪个字、共情句有没有、事实句是否只来自知识库、有没有给出下一步动作。写出来不好听的多数情况，是 system 提示词里只写了一句「语气亲切」，既没给可模仿的例句，也没列禁用词和句长上限。判断方法很直接：把一次真实会话的请求体打印出来，看 system 字段里到底写了什么。
如果 AI 客服回复像说明书，先不要急着换模型，去看请求里的 system 提示词：通常缺三样东西——一条可模仿的例句、一份禁用词表、一条先复述用户问题再回答的顺序约束。做法是把这三样写进 system 字段，并在返回前端之前加一层后处理。验证方式是用同一批历史问题重放，人工检查是否还出现套话。模型名、参数范围和计费额度以你接入的服务商控制台为准。
AI客服话术怎么写好听吸引人
在「AI客服话术」这条链路上，「怎么写好听吸引人」对应的是回复生成前的约束层，也就是 system 提示词加上返回前的文本后处理，不涉及知识库检索那一步。知识库决定答得对不对，约束层决定说得像不像人。两者混在一起调，往往改了半天提示词，问题其实出在检索没召回。
要确认问题是不是出在这一步，有三个可核对的位置：
- 浏览器开发者工具的 Network 面板，找到发送对话的那条请求，展开请求体查看 system 字段或 messages 数组里 role 为 system 的那条内容。如果里面只有「你是一个专业客服」这类一句话，那问题基本就在这里。
- 服务端日志里打印的完整 payload。可以在应用日志中检索 system 关键字，确认最终送给模型的内容和后台配置一致。命令示例：
grep -n 'system' /var/log/ai-chat/app.log | tail -n 5，日志路径按实际部署替换。 - 管理后台的提示词或人设字段，通常叫「机器人设置」「人设与语气」「系统提示词」。注意区分页面上展示的内容和实际生效的内容，二者不一致是常见情况。
AI客服话术之前先确认这三件事
这三件事缺一件，后面改提示词都会白改。
一是版本。要确认的是你实际调用的模型名和接入层的版本，而不是后台显示的默认值。模型名通常在服务商控制台的模型列表页，或调用返回体的 model 字段里核对；SDK 版本可以用 pip show 加包名、或 docker images 看镜像 tag 来确认。限速、额度和计费方式属于会变的信息，需要到服务商控制台的用量或额度页面查看，不要沿用旧的截图。
二是权限。后端调用模型的 API Key 是否具备对应模型的调用权限，后台账号是否具备编辑提示词的权限。后台上保存按钮是灰的、或者提示「无权限操作」，一般就是角色权限问题，需要到「成员与角色」页面核对。Key 的有效期和可用模型范围以控制台的应用详情页为准。
三是入口位置。要搞清楚提示词是在哪一层拼进请求的：前端直接调用、还是走后端网关。查法是看请求域名，是模型服务商的域名说明前端直连，是自己的网关域名说明中间有服务端拼接逻辑，这时要搜代码里 messages 或 system 的拼接位置，否则你在后台改的内容可能被网关覆盖。
AI客服话术：最短可用路径
- 写入人设骨架。在后台提示词框或代码里的 system 常量中粘贴下面的内容并保存。做完这步应该看到保存成功的提示，刷新页面后内容还在。
你是「XX 商城」的售后客服小助手，只回答订单与售后相关的问题。
说话规则：
1. 先用一句话复述用户的问题，确认理解无误。
2. 称呼统一用「您」，不使用「亲」「宝子」「亲爱的」。
3. 每段不超过 2 句，整条回复不超过 80 字。
4. 涉及金额、时效、赔付时，必须引用知识库原文；知识库没有的，回复「这个我需要帮您转人工确认」。
5. 禁用句式：「无法理解您的意思」「作为一个AI」「请您耐心等待」。
示例：
用户：到货碎了。
回复：您的杯子到货破损了，可以直接申请退款或补发。请问您想走哪一种？- 发一条测试请求，确认 system 真的生效。请求体骨架如下，字段名和路径要以你接入的接口文档为准做替换。做完这步应该看到返回内容里出现了「您」的称呼和复述句式。
curl -s https://your-gateway.example.com/v1/chat/completions \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d @body.json{
"model": "CONTROL_PANEL_MODEL_NAME",
"temperature": 0.3,
"max_tokens": 300,
"messages": [
{"role": "system", "content": "这里放上面的系统提示词文本"},
{"role": "user", "content": "我买的杯子到货碎了，能退吗"}
]
}- 加一层返回前处理。在把模型输出回到前端之前拦截禁用词，命中就替换成转人工话术，避免模型偶尔漏掉规则时直接暴露给用户。
- 重放历史问题。取一批真实的历史会话问题逐条发过去，人工看回复是否还有套话、是否出现没有依据的赔付承诺。做完这步应该能整理出一份需要继续补规则的清单。
AI客服话术：一个真实场景的完整做法
假设场景：一个日咨询量在几十条量级的小型电商，售后 FAQ 约 30 条，主要问退款流程、到货破损、发货时效，对象类型是订单类咨询。这个数据量通常不需要引入向量检索，把 FAQ 全文作为上下文塞进提示词就够，先别上复杂方案。
具体取值和位置：
- 提示词文本放在
data/prompt_system.md，或后台的「系统提示词」字段里，二选一，不要两处都改。 - FAQ 整理成三列：用户问法、标准答案、不可承诺事项。文件放
data/faq.md，拼接在 system 内容之后。 - temperature 取 0.3，max_tokens 取 300，这两个值写在请求体里，位置见上一节的 body.json。
- 禁用词表放
config/banned_phrases.txt，一行一条，由返回前处理脚本读取。
BANNED = ["无法理解您的意思", "作为一个AI", "请您耐心等待"]
FALLBACK = "这个问题我需要帮您转人工确认，稍后会有同事联系您。"
def polish(text: str) -> str:
for w in BANNED:
if w in text:
return FALLBACK
return text.strip()这段函数放在服务端返回给前端之前的那一层，用你项目的实际框架接入即可。验证方式是拿 10 条左右历史会话重放，看禁用词是否被拦住、有没有出现未经确认的赔付金额。
这一步最容易踩的坑：在系统提示词里写了「尽量满足用户需求」这类开放式指令。它和禁用词表是冲突的，模型为了「满足」会自行承诺退款时效和赔付金额，而且这种承诺往往不带任何前提条件。写话术时宁可显式列出可以说的范围，也不要给一句鼓励发挥的话。
AI客服话术：跑不通先查这三处
第一处：改了提示词但回复完全没变。常见现象是后台提示「保存成功」，但抓请求体发现 system 内容还是旧的。优先查网关层有没有对配置做缓存，或者前端读的是另一份配置文件。检查位置是 Network 面板里的请求体，以及网关配置文件中的缓存相关项；清掉缓存或重启服务后再发一次请求对比。
第二处：接口报错，提示类似 400 invalid_request_error，并说明 messages 中某条 role 不合法或 system 不能被放在数组里。这类报错说明该接口对 messages 结构有要求，有的服务需要把 system 作为独立字段传。检查位置是对照服务商控制台的接口文档核对 messages 结构，而不是照抄别人的请求样例。修改后再用同一份 body.json 重发，确认返回 200 且内容符合提示词约束。
第三处：提示词已经写得很细，回复仍然生硬或答非所问。多数情况不是话术问题，而是检索没召回或者上下文被截断。检查位置是日志里打印的最终 prompt 长度，以及检索环节命中的 FAQ 条目编号；如果命中为空，先修检索再回来调话术，否则一直在错误的层面上反复改文案。上下文长度是否超限，以服务商控制台标注的模型上下文上限为准。