Slack、邮件、微信里的 AI 客服：三个渠道的提示词该怎么分开写

很多团队把客服 Agent 上线后发现一个奇怪的分裂：邮件场景满意度不错，IM 场景用户频繁放弃，Slack 里干脆没人用。检查提示词，是一份——所有渠道共用一条系统提示。

这就是根因。三个渠道的用户预期、信息密度、回复节奏根本不同，用同一套指令必然有一半场景是错配的。

Slack 群里的客服：用户不想读第三行

Slack 里用户提问的实际心理状态是”我在工作中间被打断了，给我一个能立刻用的答案”。特点是：

• 消息极短，常缺少主谓宾：“这个报错了看看”
• 上下文在频道历史里，不在消息里
• 有人围观，回复太长会显得吵
• 期待即时性，超过 30 秒没回应就会去问别人

对应的提示词要点：

你是团队内嵌的支持助手，回答 Slack 频道里的问题。

格式硬约束：
- 首句直接给结论或操作步骤，不超过 25 字。
- 正文最多 3 行，禁止开场问候、禁止"很好的问题"。
- 需要多步骤时用 1/2/3 短列表，每步不超过 15 字。
- 无法确定时，只问一个最关键的澄清问题，不要列问题清单。

行为约束：
- 从频道历史里找线索，但只引用与你判断相关的那一条。
- 涉及账户权限、退款、删除数据，必须 @ 人工同事，不自行处理。

关键点在于”禁止开场问候”。在邮件里，客套是礼貌；在 Slack 里，客套是噪音，用户会在第二行划走。

邮件：要能独立成篇，还要留痕

邮件场景几乎完全相反。用户写一封 400 字的邮件描述问题，期待一封同样完整、能转给同事、能作为记录的回复。特点是：

• 信息密度高，但常夹杂情绪和无关背景
• 受众可能不只有一个人（抄送）
• 回复是要被归档的，格式比速度重要
• 用户往往已经自己试过几件事

对应的提示词要点：

你是邮件支持助手，回复将直接发送给客户。

结构模板（必须按此顺序）：
1. 一句话确认你理解的问题（用自己的话复述，不要照抄客户原句）
2. 直接给解决方案或明确下一步（含具体时间点）
3. 如需要，列出客户需补充的信息，最多 3 项
4. 结尾一句，不用客套长段

内容约束：
- 全文 150-250 字，不超过 3 段。
- 客户已说明尝试过的方案，不得重复推荐。
- 不承诺具体赔付金额或时限，超出权限的一律写"将由专人跟进"。
- 不编造工单号、政策条款编号；不确定就写"我确认后回复"。

“复述问题”这一步是邮件的核心。它同时解决了两件事：证明你读懂了，以及给客户一个纠错机会。测试中加上这一步，客户补充信息的二次往返率下降约三成。

IM（微信/企微/飞书）：要短，但不能断

IM 是两者之间最难的：既要有 Slack 的即时感，又要容忍用户分多条消息、边发边补充。

• 一句一个消息，语义不完整
• 会突然发截图、语音
• 用户追问非常频繁，历史很重要
• 期待像人一样”顺着说”

对应的提示词要点：

你是 IM 客服。用户会分多条发消息，请把最近 5 分钟内的多条消息合并理解为同一个问题。

回复规则：
- 长度 40-80 字，一次只解决一个问题。
- 开头不用称呼，直接接话。
- 需要用户操作时，只给当前这一步，不提前解释下一步。
- 用户情绪明显激烈时，第一句先回应情绪，再给方案。
- 未收到用户确认前，不连续发送两条以上消息。

最后一条是 IM 特有的。AI 连续输出三条长消息，会觉得”刷屏”，用户流失率明显上升。让 Agent 一次只推进一步，反而更像人。

怎么验证分渠道的效果

不要只看整体满意度，按渠道拆开看四个指标：

1. 首条回复解决率：用户看完第一条是否还要追问。
2. 平均轮次：轮次突然变多，通常是提示词没给够上下文。
3. 放弃率：用户发完问题就不再回复，这是最容易被忽略但最重要的负向信号。
4. 人工升转率：过低（Agent 硬扛）和过高（Agent 太保守）都是问题。

建议做法：三套提示词共享同一段”事实与政策”知识块，只在上面的形式约束层分开写。这样知识更新只需改一处，格式差异各自演进。用一个统一的路由层判断渠道并注入对应模板，避免维护三份会漂移的副本。

一个更普适的原则：先想清楚这个渠道里的用户此刻在做什么，再写提示词。 渠道不是传输管道，它决定了对话的社会契约。