原创虚构教学示例，未预填模型结果。
可编辑的起点
- 1 · 要检查的材料
- 我的月度订阅被扣了两次款。能帮我核查一下这两笔付款吗？
- 2 · 你想问的问题
- 这属于哪一类反馈？
- 3 · 定义 2–6 个选项
- 故障或错误
- 功能建议
- 账单问题
- 使用求助
- 正面反馈
- 其他
这些是模型判断的概率，不是实测准确率或保证。“是／否”对应你写的标准，选项概率只在你提供的选项内比较。
先识别冲突来自哪里
标签重叠可能意味着两种不同问题：流程只需要一个去向，但类别定义含糊；或者输入确实同时具有多个属性。重新命名类别不能让一条包含两个问题的消息只剩一个问题。
本教程使用本站原创反馈模板，不复现社区测试，也不声称某组标签表现最好。
不只改名称，还要改规则
需要指定一个负责人时，说明每个标签包含与排除的情况，并明确同时符合两个标签时怎样处理。采用客服团队能够解释的政策。必要时加入范围之外或人工复核选项；这只是给模型一个可选答案，不保证它一定发现不确定性。
如果目标是记录所有符合的属性，应在完整流程里分别做是非检查。本站自定义编辑器可以逐个体验，但不会把 Choice 变成多标签输出。
检查混合问题和信息缺失
用一条同时涉及付款异常和登录失败的虚构消息，比较两条各自只包含一个问题的消息。再试一条没有具体细节的抱怨。先决定应该怎样处理，再运行；修改措辞后要回看之前的错误案例。
概率最高的标签仍然可能错误。概率接近可以提醒人工复核，但结果很确定也不能证明被遗漏的类别没有必要。
明确下一步由谁决定
信息不足时，应用可以请求澄清或转人工，不应编造账户事实，也不能把建议类别当作退款权限。本教程没有给出通用概率阈值。
回到反馈分类方案，或阅读 Choice 与 Noul，明确自己需要一个去向，还是多个独立属性。
来源与延伸阅读
本指南依据官方文档和所链接的社区报告编写。社区观察均注明原作者。
我们如何核查来源可编辑的起点载入这个模板