收益：
- 能够将冗长且分散的客户请求转化为结构化、可操作的摘要
- 能够使用固定模式根据类别、紧急程度和客户情绪对请求进行分类
- 能够定义适合批量票据处理自动化的一致输出格式（JSON/表）
想象一下一个支持团队的早晨：一夜之间积累了 220 张新票（tickets）。有些是一句“我忘记了密码”，有些是愤怒的三段抱怨，有些实际上是一个销售机会。通读这一堆文件，将每个病人分配到正确的类别，确定其紧急程度，并将其引导给正确的人（这称为分诊；与急诊室按优先级对患者进行分类的逻辑相同）占用了一天的前两个小时。
人工智能 (AI) 可以在几秒钟内持续完成这项工作。但神奇之处并不在于说“总结这个请求”；而是在于说“总结这个请求”。它在模型上强加了固定的类别列表、明确的紧急级别和不可变的输出格式。在本单元中，我们将建立一个分类系统，从处理单个请求到以自动化就绪的方式标记数百个请求。
注：AI生成的类别和紧急度标签是初步筛选工具。特别是，标记为“紧急”和“投诉”的请求在处理之前必须经过人工确认。
为什么要结构化摘要？
免费摘要（“客户的发货有问题”）无法搜索、排序或自动化。然而，支持经理的需求是明确的以下问题：
- 该请求属于哪一类？ （运输、退货、付款、技术、产品信息、投诉、销售机会）
- 有多紧急？ （严重/高/中/低）
- 顾客的情绪状态如何？ （生气/失望/中立/满意）
- 它的一句话本质是什么？
- 下一步应该做什么？
一旦您提前定义这些问题并将它们作为模式（常量字段和可能的值）提供给模型，所有 220 个请求都可以以相同的格式进行比较和过滤。
循序渐进：建立分诊方案
- 固定类别列表。不要让模型拟合；给出一个封闭的列表。
- 定义紧急程度的标准。 “严重”的具体含义是：服务完全停止、付款丢失、安全风险。
- 识别情绪标签。使用有限且明确的集合。
- 导入输出格式。对于批量处理，JSON（由字段值对组成的机器读取数据格式）适合，对于单个请求，表适合。
- 制定“如果不确定则勾选”规则。如果模型不确定该类别，让它说不确定，人类就会查看。
- 核实。第一批，手动检查标签的准确性并设置提示。
可复制的提示
将单个请求转换为结构化摘要的基本提示：
角色：您是一位经验丰富的支持分类专家。下面分析一下客户的要求。添加评论；只需依靠文本中的内容即可。填写以下字段：- 摘要：（最多 1 句话）- 类别：[运输 | 运输]返回 |付款|技术|产品信息|投诉 |销售机会]- 紧迫性：[严重|高|中等|低]-情绪：[生气|失望|中性|满意]- next_step：（单句话，具体行动）- 不确定：（如果类别/紧急程度不清楚，则为“是”，否则为“否”）请求：“”“{{ request_text }}”“”
对于批处理，提示符会一次性将多个请求转换为 JSON 数组：
处理下面编号的请求。为每个具有以下架构的 JSON 对象生成一个 JSON 对象，并将它们全部作为 JSON 数组返回。超出计划范围：{ "id": "", "summary": "", "category": "", "urgency": "", "emotion": "", "next_step": "", "I'm not certain": "" }仅限类别：运输、退货、付款、技术、产品信息、投诉、销售机会。请求：{{ numbered_request_list }}
澄清紧急标准并教导模型“关键”定义的提示：
根据以下规则确定紧急程度：- 严重：服务完全不可用、付款丢失、安全/数据风险、法律威胁。- 高：重要功能被破坏，但存在解决方法；愤怒的客户。- 中：单一问题，不停止工作流程。- 低：请求信息、建议、一般问题。在“urgency_reason”字段中用一句话写下您做出决定的原因。
捕捉销售机会并建立支持/销售桥梁的提示：
处理请求时，如果客户表现出购买新产品/包装/补充品的兴趣（例如“您有更大的包装吗”、“需要多少用户”），请将类别设为“销售机会”，并在“sales_note”字段中为销售团队添加一句话提示。
弱提示/强提示
弱提示
强大提示
“对这个请求进行总结和分类”
封闭类别列表 + 紧急程度定义 + 固定 JSON 架构
每次生成不同的标签
始终为相同的请求提供相同的标签
他按照自己的意愿使用“紧急”这个词。
应用“关键”的具体标准
他编造了模糊的
emin_degilim：说“是”并将其留给该人
一致性是这里的黄金法则：如果同一投诉在不同的两天不属于同一类别，则任何报告和自动化都不会可靠。
三个迷你箱
案例 1——机密批评家。在一家SaaS（互联网租赁软件）公司，“我无法登录，整个团队正在等待40人”的消息看起来很普通，因为它的长度很短。由于紧急规则（“服务完全不可用”标准），分类提示将其标记为“严重”。请求在 6 分钟内得到处理，而不是在队列中等待 2 小时；已防止违反 SLA（服务级别协议，即承诺的响应时间）。
案例 2——愤怒优先。有一天，当检查 180 个请求的 AI 标签时，发现有 14 个情绪为“愤怒”的请求被放入单独的队列中。这些请求针对经验丰富的代表，当周的负面调查得分（CSAT，即客户满意度得分）与前一周相比显着提高。
案例 3 — 从支持到销售的桥梁。 “我现在的套餐是5人，我需要增加到20人，可以吗？” AI 将消息标记为“销售机会”并添加了销售说明。该请求自动落到销售团队；如果在标准支持队列中丢失的话，追加销售的机会就会被忽视，但现在却变成了一种收获。
提示：使您的类别列表尽可能简短和离散。 20 个类别会让模型（和你的团队）感到困惑； 6-8 个清晰的类别在报告中标记得更加一致且有意义。将两个经常混淆的类别结合起来。
连接到自动化
结构化 JSON 输出的真正强大之处在于它会自动流向下一步：标记为“关键”的请求立即通知经理，“销售机会”进入 CRM（客户关系管理软件），“退货”进入自助服务流程。但自动化的第一条规则：高影响力的操作（退款、账户关闭）永远不会仅基于 AI 标签而触发；有时会得到人类的认可。
注意：情绪分析是一种预测，而不是精确的测量。被模型称为“中立”的顾客实际上可能悄悄地非常生气。使用情感标签来确定优先级；但不要仅依靠它来得出诸如“该客户已经满意”之类的明确结论。
常见错误
- 将类别列表留给模型；每次都会得到不同的、不兼容的标签。
- 留下诸如“紧急”之类的相关词未定义；每个人的要求都很紧急。
- 不固定输出格式；有时会出现段落，有时会出现列表而不是 JSON。
- 不为不确定性提供出口（我不确定）。
- 无需人工批准即可将高影响力交易（退款、账户关闭）链接到 AI 标签。
- 自动化整个流程，无需手动验证第一批。
综上所述
- 分类正在按类别、紧急程度和情绪对一堆传入请求进行快速分类。
- 一致性的关键：封闭的类别列表、具体的紧急程度定义和固定的输出格式（JSON）。
- 紧迫性和情感标签可加快优先级划分；它提出了批评和愤怒的要求。
- 结构化输出可以直接链接到自动化（通知、路由、CRM）。
- 高影响力的行动和模糊的标签应始终经过人工验证。
应用任务
使用上面的 JSON 数组提示批量处理您拥有的 5 个不同的客户请求（或示例）。然后手动检查输出：（1）每个类别是否正确？ (2)那些标记为“严重”的服务是否真的停止了？ (3) 我确实在正确的地方说“是”吗？更正任何不适合的标签并相应地更新提示（特别是类别定义和紧急规则）。通过此练习，您可以养成根据自己的实际情况校准模式的习惯。
清单
- [ ] 我定义了一个封闭且离散的类别列表。
- [ ]我用具体措施描述了紧急程度。
- [ ] 我修复了输出格式（JSON/表）。
- [ ] 为了不确定性，我添加了一个出口门（Im_unsure）。
- [ ] 我手动验证了第一批并校准了提示。
- [ ] 我对高影响力的行动添加了一层人类认可。