用 OpenAI API 做客服摘要的最小可行架构

客服团队每天会产生大量对话、邮件、工单和聊天记录。最适合 AI 先落地的场景，不一定是“自动客服机器人”，而是更低风险的“客服摘要”：把一段对话压缩成问题、情绪、优先级和下一步动作。

这篇文章给一个用 OpenAI API 做客服摘要的最小可行架构，适合产品原型和内部工具。

快速结论

客服摘要比自动回复更适合作为 AI 客服第一步。它风险低、价值明确、容易人工验证，也能为后续自动分类、工单分派和知识库补全打基础。

最小架构是：

客服消息 → 清洗文本 → OpenAI 摘要 → 结构化 JSON → 写入工单/表格 → 人工确认

适合谁

• 客服工单量大，但还不敢做自动回复的团队
• 想分析客户反馈主题的产品团队
• 想做 AI 客服 MVP 的开发者
• 需要把聊天记录变成 CRM 或工单摘要的运营团队

输出字段设计

不要只让模型返回一段自然语言摘要。建议返回结构化 JSON：

{
  "summary": "客户反馈导出 CSV 出现乱码，影响多个账号。",
  "issue_type": "bug",
  "sentiment": "negative",
  "priority": "high",
  "next_action": "创建技术排查工单，并回复客户预计处理时间。",
  "needs_human_review": true
}

这样后续可以直接写入客服系统、CRM、Slack 或 Google Sheets。

最小架构

Prompt 模板

你是一个客服工单摘要助手。请阅读客户对话，输出 JSON。

字段：
- summary：三句话以内摘要
- issue_type：bug / billing / how_to / feature_request / other
- sentiment：positive / neutral / negative
- priority：high / medium / low
- next_action：建议客服或产品团队下一步动作
- needs_human_review：true / false

规则：
- 不要编造客户没有说过的信息。
- 如果信息不足，把 needs_human_review 设为 true。
- 涉及退款、赔偿、法律、隐私的问题必须人工审核。

客户对话：
{{conversation_text}}

为什么要加人工审核

客服摘要看起来风险低，但仍然可能误判：

• 把普通抱怨判断成高优先级
• 漏掉退款或隐私问题
• 误解客户真实诉求
• 把历史引用当成当前问题

所以第一版建议只辅助客服，不自动对外回复。

成本估算

假设每天 500 条客服对话，每条平均输入 1200 tokens，输出 250 tokens：

500 × 30 × 1450 = 21,750,000 tokens/月

降本策略：

• 短对话直接摘要，长对话先截断或分段
• 系统通知和无效消息先用规则过滤
• 重复问题走缓存或 FAQ 分类
• 高价值客户工单再用更强模型复核

常见错误

错误 1：直接做自动回复

自动回复涉及品牌、承诺、赔偿和合规。摘要和分类是更安全的第一步。

错误 2：不清洗聊天记录

客服记录里常有系统消息、按钮点击、机器人提示和历史引用。如果不清洗，摘要会变差。

错误 3：没有低置信度处理

如果模型不确定，应该进入人工审核，而不是硬给结论。

上线前检查

• 是否有 50 条真实工单测试集？
• 分类是否符合客服团队实际习惯？
• 高优先级是否有人工确认？
• 是否记录 token 和失败原因？
• 是否避免把敏感信息写入日志？

总结

用 OpenAI API 做客服摘要，是 AI 客服最适合落地的第一步。它不需要替代客服，只需要减少阅读和整理时间。

先做摘要、分类和下一步建议，再考虑自动回复。这样更安全，也更容易证明 AI 的实际价值。

一个落地案例

一个 SaaS 团队可以先选择最近 100 条客服工单做测试。人工先给每条工单标注理想摘要、问题类型和优先级，然后让模型输出同样字段，对比差异。

第一轮不追求完全自动化，只看三个指标：

如果高优先级漏判严重，不要上线自动分派，只能作为人工辅助。

上线前事实核验

待核验：本文可能涉及工具能力、平台限制、价格、搜索政策或当前产品行为。正式上线前需要用官方文档、实际测试或最新数据复查。