大模型做分类标注时，最常遇到的不是模型能力不够，而是提示词没有把任务描述成一个可验证的分类问题。比如直接问“这句话的情感是什么”，模型可能返回“感觉有点生气”“语气比较负面”“大概是不满意”等自然语言，后续解析困难；如果把标签集合、判断标准和输出格式提前固定，结果通常会稳定很多。本文从情感分析、主题分类、意图识别三个高频任务出发，拆解分类标注提示词的设计方法。
分类提示词的核心不是堆叠形容词，而是把标注规范翻译给模型。一个完整的分类提示词通常包含角色层、标签层、示例层和输出约束层。下面先给出通用结构，再分别进入三个场景深入说明。
一、先搭好分类提示词的四层结构
角色层负责告诉模型它现在是一个标注引擎，而不是聊天助手。这个设定会显著减少模型在标签之外补充解释的倾向。标签层需要给出完整、互斥且尽量覆盖业务场景的类别集合。示例层通过少量高质量样本让模型理解边界，输出约束层则规定返回JSON或固定字段，避免自然语言结果。
下面是一个通用分类提示词模板，可用于投诉分类、咨询分类等基础任务。
你是一个文本分类标注引擎，只输出JSON对象，不要输出解释。
任务：将用户消息归入以下类别之一。
标签：["complaint","inquiry","feedback","other"]
判断规则：
- complaint：用户明确表达不满、投诉或故障
- inquiry：用户在咨询信息、价格、使用方法
- feedback：用户给出建议或中性体验描述
- other：无法归入以上三类
输出格式：
{"category":"标签值","confidence":0.0到1.0之间的小数}
在实际使用中，标签列表不要只用单个抽象词，最好为每个标签补一句判断规则。比如“complaint”可以写成“用户明确表达不满、投诉、要求赔偿或指出产品故障”，这样模型在遇到“太差了”和“这个怎么用”时更容易区分。输出约束方面，要求模型只返回JSON，可以减少后续正则匹配和字符串截断的工作量。
如果标签之间本身存在包含关系，还需要在提示词中声明优先级。例如用户既在投诉又咨询了退款方式，此时应该优先归入“complaint”，否则模型可能因为两个标签都沾边而随机选择。优先级可以写在判断规则中，例如“如果一个句子同时命中多个标签，优先选择complaint”。这类细节往往比单纯增加示例更有效。
二、情感分析提示词：标签粒度与边界样本
情感分析并不是简单的正面、负面二分。很多业务需要识别中性、混合情感以及情绪强度。比如“这个手机续航一般，但屏幕确实不错”同时包含正面和负面信息，如果只要求输出一个三类标签，模型很容易在正面和负面之间摇摆。因此提示词需要明确标签粒度，并让模型输出一个强度字段。
下面是一个细粒度情感分析提示词模板，适合评论、客服对话和社交媒体文本。
你是情感分析标注器。阅读用户文本，判断整体情感倾向。
标签：["positive","negative","neutral","mixed"]
判断规则：
- positive：整体表达满意、喜欢、推荐
- negative：整体表达不满、失望、批评
- neutral：客观陈述，无明显情感
- mixed：同时包含正面和负面，且两者都明显
输出JSON格式：
{"sentiment":"标签值","intensity":0.0到1.0之间的小数,"keywords":["关键情感词"]}
强度字段的意义在于，同样是负面，“不好用”和“气死我了，必须退款”在业务上需要不同处理。如果只输出离散标签，后续排序和预警会丢失很多信息。让模型同时输出intensity，可以把分类任务升级成可量化的情绪打分任务。关键词字段还能帮助人工抽查模型判断依据。
中性样本是情感分析提示词最容易出错的区域。如果训练语料里正面和负面样本过多，模型可能把所有句子都往两极推。提示词可以通过明确规则压制这种偏差，例如“如果句子只是在描述事实，没有表现出喜好或情绪，应归为neutral”。同时，可以在示例中加入一条中性句子，如“今天收到了包裹”，并标注为neutral，让模型知道中性并不是“情感不强烈”，而是“没有主观评价”。
解析情感分析结果时，建议把JSON字符串解析成字典后再使用，不要直接匹配字符串。下面是一段Python解析示例，假设大模型输出内容保存在response_text变量中。
import json
import re
def parse_sentiment(response_text):
# 去掉可能的代码块围栏或多余空白
text = response_text.strip()
text = re.sub(r"^```json", "", text)
text = re.sub(r"```$", "", text)
data = json.loads(text)
sentiment = data.get("sentiment")
intensity = data.get("intensity", 0.0)
keywords = data.get("keywords", [])
return sentiment, intensity, keywords
# 使用示例
raw = '{"sentiment":"negative","intensity":0.9,"keywords":["气死我了","退款"]}'
print(parse_sentiment(raw))
可以看到，解析层最怕的是模型在JSON前后加解释，所以提示词中必须出现“只输出JSON对象，不要输出解释”的约束，并且可以在代码里先用正则去掉可能的围栏标记。生产环境中还可以对JSON解析失败的情况做一次重试，而不是直接丢弃样本。
三、主题分类提示词：层级标签、多标签与未知类
主题分类常见于内容平台、工单系统和舆情分析。与情感分析不同，主题分类经常需要处理层级标签和多标签。例如一条新闻可能同时属于“科技”和“金融”，而“科技”下面又分“人工智能”“芯片”“互联网”。如果提示词只给扁平标签，模型会把层级信息丢失，后续统计时无法聚合。
层级标签可以用点号或竖线表示，例如tech.ai、finance.bank。多标签则要求输出数组，而不是单个值。下面是一个面向用户反馈的主题分类提示词。
你是主题分类标注器。阅读用户反馈，判断反馈主题。
标签体系：
- product.quality：产品质量、做工、材质
- product.function：功能缺陷、使用问题
- service.delivery：物流、发货、配送
- service.support：客服态度、售后处理
- price.refund：价格、退款、优惠
规则：
- 可以输出多个主题
- 如果没有匹配主题，输出 ["other"]
- 标签必须从上述标签体系中选取，不得自造标签
输出JSON格式：
{"topics":["标签1","标签2"],"main_topic":"最核心的一个标签"}
多标签任务中，容易忽略的是主标签字段。虽然模型可以输出多个主题，但下游分析往往需要一个主分类来画饼图或生成报表。让模型同时输出main_topic，可以把“多个主题”和“最核心主题”分开，避免业务方自己写规则从数组中猜主标签。
未知类处理同样重要。如果提示词不提供other，模型遇到完全无关的文本时会强行塞进某个标签，造成数据污染。可以显式告诉模型“如果没有匹配主题，输出other”，并在评估时统计other占比。如果other比例突然升高，说明业务出现了新的主题类型，需要更新标签体系。
对于层级标签，建议在代码中做一次校验，确保模型输出的是完整标签路径。下面这段Python代码会对标签做白名单过滤，防止模型自行简化或改写标签。
ALLOWED_TOPICS = {
"product.quality",
"product.function",
"service.delivery",
"service.support",
"price.refund",
"other",
}
def clean_topics(raw_topics):
result = []
for t in raw_topics:
if t in ALLOWED_TOPICS:
result.append(t)
if not result:
result.append("other")
return result
这种后处理看似简单，但能在模型输出不符合标签体系时兜底，避免脏数据进入下游数据库。提示词写得再好，模型依然有概率产生幻觉标签，所以白名单校验是分类系统里必不可少的一环。
四、意图识别提示词：分类与槽位抽取不要割裂
意图识别在对话系统和工单路由中非常关键。它的难点在于，用户意图通常不是孤立的一个动作，而是“动作+对象+条件”的组合。比如“帮我查一下明天的订单物流”不仅包含“查物流”这个意图，还包含时间槽位“明天”和对象槽位“订单”。如果只输出一个意图标签，后续业务系统无法直接执行。
因此意图识别提示词应该把分类和槽位抽取放在同一个JSON结构中输出。下面是一个面向客服机器人的意图识别提示词。
你是客服意图识别引擎。阅读用户消息，识别意图并抽取槽位。
意图列表：
- check_order：查询订单状态或物流
- refund：申请退款或退货
- change_address：修改收货地址
- contact_human：转人工
- other：其他意图
槽位说明：
- time：时间表达，如今天、明天、2024年5月
- order_id：订单号
- reason：用户给出的原因或诉求
输出JSON格式：
{"intent":"意图标签","slots":{"time":"","order_id":"","reason":""},"confidence":0.0到1.0之间的小数}
槽位字段即使为空，也要让模型返回空字符串，这样可以固定数据结构，降低解析成本。如果模型在某些样本中省略槽位字段，解析代码就需要写大量容错逻辑。提示词中明确“没有槽位时填空字符串”，可以显著减少字段缺失的情况。
意图识别对Few-shot示例的依赖比情感分析更强。因为意图往往与业务强相关，同一个词在不同场景下可能对应不同意图。例如“改到明天”在订单场景下可能是修改收货时间，在预约场景下可能是改预约时间。给出一两个本业务语境下的示例，能帮助模型快速对齐意图边界。
解析意图识别结果时，除了读取字段外，还需要校验槽位类型。比如order_id应该符合订单号格式，time应该能够被日期解析器识别。下面是一段基础校验示例。
def validate_intent(data):
intent = data.get("intent", "other")
slots = data.get("slots", {})
confidence = data.get("confidence", 0.0)
allowed_intents = {"check_order","refund","change_address","contact_human","other"}
if intent not in allowed_intents:
intent = "other"
if not isinstance(slots, dict):
slots = {}
if not isinstance(confidence, (int, float)):
confidence = 0.0
return intent, slots, float(confidence)
即使模型输出了正确的意图和槽位，也需要在业务层做合法性判断。例如用户说“帮我改到北京”，如果系统只支持修改地址，不支持修改配送城市，那么意图识别结果应当被路由到“other”或触发转人工流程。提示词负责把模型能力变成文本输出，而后续代码负责把文本输出变成可执行动作，两层都要稳定。
五、调试提示词的三个实用方法
设计完提示词后，不应该直接上线。分类标注任务的特点是错误往往集中在少数边界样本上，而这些样本用肉眼检查时最容易被忽略。建议先用一批人工标注好的小规模测试集进行评估，观察每个标签的精确率和召回率，而不是只看总体准确率。
第一个调试方法是固定采样参数。分类任务通常需要低温度，例如把temperature设置为0或0.1，让模型输出更确定。温度越高，模型越容易在标签边界上随机游走，尤其是中性情感和other类。第二个方法是控制Few-shot数量。示例不是越多越好，太多示例会占用上下文窗口，并且可能让模型过度拟合示例中的表面词汇。一般每个标签给一两个典型样本即可，优先选择短文本和边界清晰的样本。
第三个方法是分析输出解析失败率。JSON解析失败往往比分类错误更影响业务，因为分类错误可能只是落到相邻标签，而JSON解析失败会直接导致整个样本不可用。可以统计一段时间内模型输出的原始文本，观察哪些情况下模型会在JSON前后加解释、哪些情况下会漏掉右花括号。针对这些情况，一方面可以在提示词中再次强化输出约束，另一方面可以在代码里增加正则清洗和单次重试。
还有一点需要注意的是标签泄漏。如果你把带有真实标签的测试样本直接写在Few-shot示例里，模型可能只是记住了这些样本，而不是学会了分类规则。评估时应使用示例集合之外的样本，并且最好定期轮换示例，避免模型对固定示例产生依赖。
总结
AI分类标注提示词的关键在于把隐含的标注规范显式化。角色设定降低解释倾向，标签规则消除歧义，Few-shot示例对齐业务边界，JSON输出约束保证结果可解析。情感分析需要处理强度与中性样本，主题分类需要支持层级和多标签，意图识别则需要同时输出分类和槽位。配合白名单校验、低温度采样和解析失败重试，能构建一套稳定可落地的分类标注流程。
写作本文时我们重点拆解了提示词结构，但提示词不是一次性产物。随着业务标签体系变化、新类别出现、模型版本更新，提示词也需要持续回归。建立一个小型标注评估集，每次修改提示词后都跑一遍指标，能帮助你判断某次调整到底带来了提升，还是只是换了一种错误方式。