用 AI 做邮件分类：入站邮件该用规则、LLM 提示还是类型化决策 API

客服工单通常是一段干净的描述；邮件则像一个信封：From、To、Reply-To 头，可能写着“Re: Fwd: 发票”的主题，最上面是最新回复，下面叠着多封引用邮件，再加签名、保密声明，有时还有附件。路由主要取决于最新那段人写的话加上少数几个头信息——发到了哪个别名、发件域名属于客户还是供应商、是不是自动回复或退信。如果直接发送原始邮件，模型会把引用历史和页脚当成证据，常常按三周前那封邮件的话题来分类。意图分类问的是“写信人想要什么”；邮件分类首先要判断“哪一部分才是写信人此刻说的话”。队列设计本身见 support-triage；跨渠道意图标签见 intent-classification。

大多数生产邮箱最终三层都会用：规则处理已知事实，模型处理正文，代码执行阈值。下表比较的是维护成本与失败模式，不是基准测试；任何方案都不能替代用你自己邮件做的带标注测试集。

邮件解析放在你自己的代码里做，然后只发送一个小的 JSON state。保留：去掉“Re:”“Fwd:”前缀的主题、收件别名（billing@、sales@）、发件域名及其是否在客户或供应商名单中、最新一封的正文。删除：引用回复（“>”开头的行，以及“On … wrote:”之后的块）、签名、保密声明、追踪像素和 HTML。对于转发链，保留转发人的附言，再加原发件人第一段的简短摘录，并标注为转发内容。附件只传文件名和类型——JevModel 接受文本或 JSON，不接受文件或图片，所以“附有 invoice.pdf”只是线索，不是 PDF 内容的证据。JevModel 要求序列化后的 state 与完整请求各自不超过 8,000 字符，裁剪后的邮件几乎总能满足。下例用一个 Choice 问题选路由，再用一个 Noul 问题判断是否需要人工立即查看。

{
  "state": {
    "subject": "Invoice 2291 charged twice",
    "to_alias": "billing@",
    "sender_domain": "customer-example.com",
    "sender_known_as": "customer",
    "latest_message": "Hi, our card was charged twice for invoice 2291 this morning. Can you refund the duplicate?",
    "attachments": [
      "receipt.png (not read)"
    ]
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which team should own the newest message in this email? Ignore attachment names as evidence.",
      "criteria": {
        "support": "Product questions, bugs, how-to or account access problems.",
        "sales": "Pricing, plans, demos, procurement or purchase questions from prospects.",
        "billing": "Charges, refunds, invoices, receipts or payment method changes.",
        "vendor": "Messages from suppliers or partners about their own services or invoices to us.",
        "low_value": "Cold outreach, newsletters, automatic notifications needing no action."
      }
    },
    "needs_person_now": {
      "type": "noul",
      "instructions": "Should a person read this email today instead of waiting in a queue?",
      "criteria": {
        "true": "Money, access, legal or a clear deadline is at stake today.",
        "false": "It can wait in the normal queue."
      }
    }
  }
}

每个路由设三个置信带，并用你自己预留的邮件来设定。高置信带：把邮件移到团队文件夹或队列并打标签——低风险、可撤销的动作。中间带：放进共享复核视图，附上排名前两位的建议路由；混合型邮件（“谢谢演示，另外我们的发票有误”）就落在这里。低置信带或两个路由几乎打平：留在通用收件箱。绝不能只凭路由标签就触发不可逆操作，例如退款、合同回复或删除邮件；要在代码里加单独检查，并用 needs_person_now 这样的 Noul 问题把紧急邮件提前，不论它属于哪个路由。每个别名单独调阈值，因为 billing@ 和 info@ 的邮件构成差别很大。通用模式见 confidence-and-abstention。

用真实、已匿名化的邮件构建测试夹具并冻结。覆盖那些专门会搞坏邮件路由的形态：引用历史话题与当前不同的回复；转发人只写了“见下文”的转发链；外出自动回复；投递退信；发到 billing@ 的供应商发票（应归 vendor 而不是 billing）；客户用个人邮箱来信；第二语言写的邮件；以及应落入中间带的混合请求。把解析器和分类器一起跑，因为大多数回归来自裁剪逻辑的改动，而不是模型。在 JevModel 的 Console → Batch 中，可以上传 CSV、TXT 或 JSONL，每行用同一个固定问题，导出逐行答案，再用脚本与标签对齐；Batch 不会替你计算准确率。如果黄金样本的路由翻转，或中间带样本不再弃权，就判定此次改动失败。具体做法见 evaluation 和 batch-text-classification-api。

JevModel 是托管的决策 API：把裁剪后的邮件作为 state，加上 1–8 个具名问题 POST 到 /api/v1/systemone，它会经 OpenRouter 调用固定模型 typesafe/jev-1.13。它适合多个服务——邮件 worker、帮助台、CRM 同步——需要共享同一套带概率的路由定义，并且你希望中间带交给人而不是硬猜。Choice 支持 2–12 个路由，Score 评估紧急度等有序等级，Noul 用概率回答是/否问题。它不适合做垃圾邮件或钓鱼过滤——请把邮件服务商自带的垃圾邮件过滤和发件人认证检查放在它前面。它无法读取附件、图片或扫描版 PDF，不开源、不提供权重下载；已验证免费账号每个 UTC 日 5 次成功运行，所以繁忙的共享邮箱需要付费套餐或批量规划。帮助台场景见 zendesk-ai-ticket-classification。