先定义分类规则，再让 Claude 贴标签
客户反馈分类不是简单地把内容分成“好评”和“差评”。你可能希望识别故障、使用困惑、功能建议与价格意见；不同标签会影响后续处理方式。先定义每个标签包含什么，再让 Claude 按规则分类。
本文的反馈与编号均为虚构练习素材，分类流程是本站编写的方法示例。它不能证明某个功能实际存在问题，也不代表任何产品的用户调查结果。
一组可直接练习的反馈
F1：“点击导出后页面一直转圈，我等了两分钟。”F2：“找不到在哪里更换邮箱。”F3：“希望增加按月份筛选。”F4：“同样的操作，有时能完成，有时失败。”F5：“价格对我来说太高，而且我找不到套餐说明。”
先为类别定义边界：“疑似故障”指操作未达到描述中的预期；“使用困惑”指不知道如何操作；“功能建议”指请求新能力；“价格与套餐”指价格或套餐信息意见。对缺乏上下文的反馈，允许输出“待判断”，不要求模型强行分配。
F5同时包含价格意见和说明难找，适合多标签。只允许一个标签会丢掉另一部分信息，所以要先决定一条反馈能否拥有多个标签。
明确输出字段，保留证据
推荐输出反馈编号、标签、证据原句、需补充信息和建议处理动作。证据应是一小段原文，而不是模型重新编造的原因。F1可以归为疑似故障，但不能直接断言服务器超时，因为材料没有提供诊断依据。
F4缺少操作对象与环境，需要补充复现步骤；F2可以先核对功能入口和说明。分类回答“该往哪里处理”，根因分析则需要更多数据，二者不宜混在一起。
为容易混淆的类别准备示例
你可以把几条由人工确认过的反馈作为格式示例，尤其包括同时涉及多个问题、表达含糊和信息不足的情况。示例应遵循你自己的标签定义，不要让示例里的产品事实被移用到新反馈。
每次更改标签规则时，保留版本号。相同反馈在两个版本中得到不同标签，不一定意味着用户需求改变，也可能只是分类标准改变。
不要把记录条数当成用户人数
十条反馈可能来自同一个人，也可能是同一问题被重复导入。统计前需要检查记录编号、来源和重复规则。没有可靠用户标识时，只报告反馈记录数，不报告独立用户人数。
如果记录包含身份信息，应按业务需要脱敏，并只提交分类所需的文本。来源日期也要保留，避免把历史问题和最近故障直接放在同一张趋势表里比较。
优先级需要人工定义
出现频率可以帮助排序，但不能单独决定开发优先级。一个低频故障可能影响关键流程，一个高频建议也可能只来自重复记录。先明确影响范围、严重程度和证据，再讨论处理顺序。
要求 Claude 区分已知事实与待确认事项，不要让它根据一两句描述估算损失金额或受影响人数。材料不足时，输出补充问题比一个没有依据的优先级数字更有价值。
怎样验收分类结果
从每个标签中抽取几条记录，核对标签是否符合定义、引用是否存在、复合问题有没有漏掉。额外检查全部“待判断”记录和涉及关键故障的内容。记录误分类原因，优先修正规则和样例，再重新分类相关记录。
对比新旧规则时使用相同材料，避免把样本变化误认为分类能力提升。本文不提供未经实际测量的准确率数字。
常见问题：能不能直接自动回复客户
分类与对外回复是两个任务。先确认产品事实、解决办法和可承诺的范围，再起草回复；涉及退款、赔偿或交付日期时，应遵循实际业务政策。本文只演示整理方法，不自动向客户发送信息。
下一步：从分类到行动清单
人工确认标签后，再汇总每类问题和需要核实的事实。通用任务组织可参考本站《Claude 中文提示词：一个可复用的结构》；回答漏掉关键条件时，可参考《回答不符合预期？检查这五个提问细节》。