让大模型分析热点内容，关键不在模型选型，而在把”读得懂”变成”能入库”。稳妥的做法是用 JSON Schema 约束输出、用少样本示例锚定格式、给每条结论配证据字段，让模型吐出可直接写库的结构化标签。下文给出分析链路、Prompt 设计要点与两种结构化输出落地方式。
一、从原始推文到结构化标签
一条原始内容进入分析模块后，按固定顺序流转：
- 清洗文本，去掉无关链接与 @提及噪声，保留正文与元数据；
- 拼装系统提示与待分析文本，调用大模型；
- 解析模型返回的结构化 JSON，做字段级校验；
- 校验失败则进入重试或修补流程，通过后才写入热点表。
这套流程把”模型可能胡说”的风险挡在入库之前，下游的 WebSocket 推送只消费干净数据。
二、Prompt 怎么设计
系统提示要同时承担三件事：定义角色、声明输出契约、给出示例。下面是一段可直接复用的骨架：
你是一名热点内容分析助手。只输出符合给定 JSON Schema 的内容，不要输出任何解释。
从输入文本中提取：情感倾向、涉及话题、关键实体、一句话摘要、是否疑似热点、置信度。
规则：
- 字段缺失时填 null，不得编造。
- confidence 为 0.0 到 1.0 的小数。
- is_hot 仅当文本含明显传播信号（转发激增、争议、突发事件）时才为 true。
示例输出：
{"sentiment":"negative","topics":["股价"],"entities":["某公司"],"summary":"...","is_hot":true,"confidence":0.82}字段设计要可校验、可分支。常见字段与约束见下表：
| 字段 | 类型 | 约束 | 用途 |
|---|---|---|---|
| sentiment | 枚举 | positive/neutral/negative/mixed | 情感分桶 |
| topics | 字符串数组 | 控制长度避免发散 | 话题归类 |
| entities | 字符串数组 | 可空 | 实体抽取 |
| summary | 字符串 | 限长 80 字 | 概要展示 |
| is_hot | 布尔 | 需证据支撑 | 是否推送 |
| confidence | 数值 | 0.0–1.0 | 阈值过滤 |
把字段名写成业务含义（如 is_hot）而非泛化词（如 result），下游逻辑才好直接判断。
三、结构化输出的两种落地方式
Prompt 约束属于软约束，模型仍可能夹带解释文字。生产环境应优先用 API 层的结构化能力。
| 方式 | 可靠性 | 适用场景 |
|---|---|---|
| 提示词约束 JSON | 低，易夹带废话 | 快速验证、旧版接口 |
| JSON Mode（response_format） | 中高，格式基本稳定 | 单对象抽取 |
| Function Calling / Tool Use | 高，参数受 Schema 校验 | 需触发动作或多工具 |
OpenAI 系可用 response_format 配 json_schema 并开 strict 模式，下面给出调用示例：
import openai
client = openai.OpenAI()
schema = {
"type": "object",
"properties": {
"sentiment": {"type": "string", "enum": ["positive", "neutral", "negative", "mixed"]},
"topics": {"type": "array", "items": {"type": "string"}},
"summary": {"type": "string"},
"is_hot": {"type": "boolean"},
"confidence": {"type": "number", "minimum": 0, "maximum": 1},
},
"required": ["sentiment", "topics", "summary", "is_hot", "confidence"],
"additionalProperties": False,
}
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "分析这条热点：<正文>"}],
response_format={"type": "json_schema", "json_schema": {"name": "hot_analysis", "schema": schema, "strict": True}},
)
record = resp.choices[0].message.content # 已是合法 JSON 字符串不同平台支持度有差异：OpenAI 的 strict 模式约束更强，Anthropic 走 tool_use 但需调用方补校验，部分国产模型需配 few-shot 示例才稳。无论哪家，后端都要做二次 Schema 校验，不能盲信模型输出。
四、质检与兜底
校验分四层：语法（能否解析）、Schema（字段类型与枚举）、约束（长度与范围）、语义（证据是否支撑结论）。任何一层失败都进修复流程。
常见的自愈手段是”修复回写”：把不合规的原始输出连同 Schema 再丢回模型，要求只修格式不补内容。仍失败则降级为低置信记录并送人工队列，绝不把幻觉数据直接推给前端。
批量分析时逐条调用比一次要数组更稳，单条抽取准确率明显更高，代价是请求数增加，可用并发控制抵消延迟。
常见问题（FAQ）
Q1：模型总在 JSON 前后加说明文字？
开启 JSON Mode 或 Function Calling，并在提示里写”只输出 JSON，不要解释”。
Q2：字段名忽而是驼峰忽而是下划线？
在 Schema 显式固定字段名，并设 additionalProperties 为 false 禁止多余字段。
Q3：模型编造不存在的实体怎么办？
把字段设为可空，提示”缺失填 null”，校验层拒绝占位值，必要时送人工复核。
