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