让 Claude Code 分类客服邮件并写草稿，但不给它发送权
客服邮件自动化里，分类比写回复值钱得多——把几十封邮件按类型和紧急度分好流，人处理起来的顺序就完全不同了。回复草稿要分级：政策类问题照资料答，订单类问题带上具体信息，涉及退款、赔付、责任认定和法律的一律只标记不起草。发送权不给它，理由不是技术不行，是对外承诺的责任落在账号上。用改稿率和转人工比例衡量效果，改稿率长期高说明规则没写清楚。
先讲结论：分类比写回复值钱
一说客服自动化，多数人想到的是「让 AI 帮我回邮件」。
实际做下来会发现，写回复不是瓶颈。真正耗人的是另外两件事：
- 早上打开邮箱，几十封混在一起，你得先一封封看才知道哪封急
- 同一个问题反复回答，但每封都要重新查订单号、查物流、查政策
第一件是分类问题，第二件是查资料问题。这两件解决了，客服效率就上来了；只解决「写字」这一件，收益反而有限——因为改一封写得不对的草稿，花的时间未必比自己写少。
所以这套东西的重心应该放在分流和查资料上。
先定分类维度
分类不是越细越好，够用就行。两个维度交叉：
按类型分：
- 售前咨询：还没买，问参数、问兼容、问发货时间
- 物流查询：已下单，问到哪了、什么时候到
- 退换货：要退、要换、要退款
- 产品问题：收到了但有质量或使用问题
- 投诉与差评关联：情绪明显，或提到要投诉、要留差评
- 供应商与合作：不是客户，是同行或供应商
- 垃圾邮件
按紧急度分：
- 今天必须回：涉及超时会自动升级的、平台有响应时限的、客户已经二次追问的
- 今天内回：多数常规问题
- 可以排队：售前咨询里不影响成交时效的
两个维度交叉之后，早上第一眼就知道该先处理哪五封。这一步的价值比任何一封回复的措辞都大。
回复草稿要分级
不是所有类型都适合起草。按能不能照着资料答，分三级。
一级：照资料答
运费政策、退换货政策、保修范围、产品参数、发货时效。
这类问题的答案在你的资料里是确定的，起草的准确率高，人改动小。可以放心让它写完整草稿。
前提是资料本身要准确、要更新。政策改了没同步到资料里，它会一直用旧政策回答客户——这比不回答更麻烦。
二级：带订单信息答
物流查询、订单状态、修改地址。
这类需要查具体订单，然后把订单信息填进模板。可以起草，但草稿里涉及订单的部分必须标出来源，方便人核对。
有一条硬规则：**查不到订单就不要猜。**没查到就写「未找到该订单，需人工核实」，不要生成一段听起来合理但没有依据的回复。
三级：只标记，不起草
涉及退款金额、赔付、责任认定、法律和监管、平台申诉的邮件。
这类一律不起草，只做分类和摘要，把关键信息提炼出来给人看：客户诉求是什么、订单是哪个、之前沟通过几次、附件里有什么。
不起草的理由不是它写不好，是这类回复的每个字都可能被当成承诺。让人从零开始写，比让人去改一份措辞已经定型的草稿更安全。
四类话绝对不能自动说出口
即使是一级问题，也要在 Skill 里把这几类表述列成禁止项：
- 金额承诺：「我们会退您 XX 元」「补偿 XX」
- 时间承诺：「三天内一定到」——物流时效不由你控制
- 责任认定：「这是我们的问题」「是物流的责任」
- 例外授权：「这次给您破例」——一旦开了口子，后面所有客户都能引用
这四类的共同点：说出去就收不回来，而且会被截图。
正确的写法是让草稿在这些地方留空，用明确的占位提示人来填，比如「此处需人工确认补偿方案」。
多语言怎么处理
跨境客服经常同时面对英文、日文、德文。有两个实务细节：
第一，回复语言跟随来信语言，不要自作主张换语言。客户用德语写来，回英文会显得敷衍。
第二，不要把中文话术直译过去。中文客服习惯的那套铺垫和客气，直译到英文里会显得啰嗦，日文里则可能敬语层级不对。正确做法是每种语言各准备一套原生的模板，而不是翻译。
这件事的工作量在前期，一次做好之后长期受益。
完整的 Skill
---
name: support-triage
description: 对客服邮件做分类、紧急度判断和回复草稿生成。当用户要处理客服邮件、分流工单、准备回复时使用。
allowed-tools: Read Write
---
## 输入
读取 `data/inbox/` 下的邮件导出文件。
政策和话术资料在 `kb/` 目录，订单数据在 `data/orders/`。
## 分类
每封邮件输出：
- 类型：售前 / 物流 / 退换货 / 产品问题 / 投诉 / 供应商 / 垃圾
- 紧急度：今天必须回 / 今天内回 / 可以排队
- 语言
- 是否为二次追问（同一客户同一问题的重复来信）
- 一句话摘要
## 草稿分级
- 一级（政策、参数类）：生成完整草稿，答案只能来自 `kb/`。资料里没有的，写「需人工补充」
- 二级（订单相关）：查 `data/orders/`，生成草稿并标注每条订单信息的来源。查不到订单时写「未找到订单，需人工核实」，不要推测
- 三级（退款、赔付、责任、法律、平台申诉）：不生成草稿。只输出结构化摘要：客户诉求、涉及订单、历史沟通次数、附件内容、建议的处理路径
## 语言
回复语言与来信语言一致。
每种语言使用 `kb/templates/<语言>/` 下的原生模板，不做中文直译。
## 禁止表述
草稿中不得出现：
- 具体的退款或补偿金额
- 确定的送达时间承诺
- 责任归属的判定
- 例外或破例的授权
这些位置一律留空，写明「此处需人工确认」。
## 输出
生成一份 `triage.md`：
1. 今天必须回的邮件，按紧急度排序，附草稿或摘要
2. 今天内回的邮件
3. 可以排队的
4. 垃圾邮件，只列数量
5. 本批统计：各类型数量、三级邮件数量、查不到订单的数量
## 禁止动作
- 不发送任何邮件
- 不修改订单，不发起退款
- 不承诺任何金额、时间或责任
发送权为什么不给
技术上完全可以让它直接发。不给的理由是责任归属。
一封发出去的邮件代表店铺，客户会拿它作为凭据。如果里面有一句不该有的承诺，你事后说「那是 AI 写的」没有任何意义。
现实的做法是分阶段：
- 前一两个月，全部人工确认后发送
- 跑顺之后，可以考虑把一级问题里最标准的几类（比如纯政策咨询）设成自动发送，但要保留完整日志
- 二级和三级永远人工
不要一上来就追求全自动。客服是直接对客户的界面，这里省下的时间，远不如出一次事的代价大。
用两个数判断这套东西行不行
上线之后，看两个指标：
改稿率：人工修改过的草稿占全部草稿的比例。
这个数长期偏高（比如超过一半），说明规则或资料有问题——要么政策资料不准，要么话术模板不对。此时该做的是回去改 kb/，而不是接受「反正还是得改」。
转人工比例：被判为三级、或标注「需人工核实」的比例。
这个数偏高不一定是坏事，说明它在该谨慎的地方谨慎了。但如果大量常规问题也转了人工，说明资料覆盖不够，要补的是知识库。
这两个数每周看一次，比看「省了多少时间」更有指导性。
下一步
客服是被动响应，下一篇讲主动监控：竞品价格和库存变化，什么时候该通知你，什么时候不该。
